IXXAT: timestamps read 1.5 x wall time plus adapter uptime (misplaced parenthesis in _timeoffset; start tick never captured in vcinpl2)
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 88/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- python
- Lĩnh vực
- backend, networking
Hướng nghiên cứu
Bắt đầu trong can/interfaces/ixxat/canlib_vcinpl.py quanh các dòng 629 và 705, sau đó so sánh với can/interfaces/ixxat/canlib_vcinpl2.py quanh các dòng 735 và 843, tập trung vào việc thiết lập epoch offset và xử lý CAN_INFO_START. Chạy bản tái hiện bus.recv được cung cấp với lưu lượng IXXAT và xác minh rằng các dấu thời gian khớp với time.time, trong khi khoảng cách giữa các frame có nguồn gốc từ phần cứng vẫn không thay đổi.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Describe the bug
On the IXXAT backend every received Message.timestamp reads about 28 years in the future, plus the adapter's uptime. Measured on a USB-to-CAN V2 compact (VCI V4 driver 4.1.264.0, fd=False, python-can 4.6.1, Windows 11, Python 3.12): the first frame after Bus(interface="ixxat", channel=0, bitrate=500000) stamped 2684545240.8 while time.time() read 1789696744.2 — a ratio of 1.5000001. The excess over 1.5 * time.time() grew from 142.4 s to 146.5 s across two opens 4.1 s apart, i.e. it is the adapter's own tick counter since power-up, never rebased.
Two lines cause it, both present on main today:
-
A misplaced parenthesis in the epoch offset, in both backends:
can/interfaces/ixxat/canlib_vcinpl.pyline 629can/interfaces/ixxat/canlib_vcinpl2.pyline 735
self._timeoffset = start_begin + (start_end - start_begin / 2)This evaluates to
1.5 * start_begin + start_endinstead of the midpointstart_begin + (start_end - start_begin) / 2. Hence the 1.5 x wall-clock epoch. -
The start tick is never captured in
canlib_vcinpl2.py(line 843): theCAN_INFO_STARTcheck is anelifsibling of theCAN_MSGTYPE_INFObranch rather than nested inside it, so an INFO message is consumed by the firstelifand_starttickoffsetstays0. Every timestamp then carries the adapter's uptime.canlib_vcinpl.pyonmainhas this check nested correctly (line 705); the FD backend does not.elif self._message.uMsgInfo.Bits.type == constants.CAN_MSGTYPE_INFO: log.info(...) # Handle CAN start info message elif self._message.abData[0] == constants.CAN_INFO_START: # never reached for INFO messages self._starttickoffset = self._message.dwTime
The spacing between frames is correct and hardware-derived (10.014 s of frame time against 10.014 s of wall time over 10 s, never a step backwards, 9 µs resolution), so this is purely the epoch.
To Reproduce
import time, can
bus = can.Bus(interface="ixxat", channel=0, bitrate=500000)
msg = bus.recv(5)
print(msg.timestamp, time.time(), msg.timestamp / time.time())
# 2684545240.8 1789696744.2 1.5000001
Any bus with traffic reproduces it; the ratio of timestamp / time.time() is 1.5 rather than 1.0.
Expected behaviour
Message.timestamp should be Unix time to within the open call, as the other backends provide, with the adapter's own tick spacing preserved.
Additional context
- python-can 4.6.1 (also present on
mainat the lines cited above) - IXXAT USB-to-CAN V2 compact, HMS VCI V4 4.1.264.0, Windows 11, Python 3.12
- Working around it downstream by adding one constant settled from the first frame's arrival when the bus's offset lies outside the open call; happy to open a PR for the two one-line fixes if that is welcome.
- Ngôn ngữ chính
- Python
- Star
- 1.6k
- Fork
- 697
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của hardbyte/python-can
-
bug
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 78/100
hardbyte/python-can#2077 · 1 bình luận · 1 reaction ·
-
bug
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 68/100
hardbyte/python-can#1922 · 1 reaction ·
-
enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 30/100
hardbyte/python-can#2102 ·
-
bug
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
hardbyte/python-can#2092 ·
-
bug
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
hardbyte/python-can#2091 ·
Tất cả issue của hardbyte/python-can
Issue tương tự
-
bug confirmed issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
open-webui/open-webui#30750 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
OpenwaterHealth/openmotion-bloodflow-app#604 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
good first issue
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100