IXXAT: timestamps read 1.5 x wall time plus adapter uptime (misplaced parenthesis in _timeoffset; start tick never captured in vcinpl2)
还没有人认领这个 Issue。
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 88/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- python
- 领域
- backend, networking
调研方向
从 can/interfaces/ixxat/canlib_vcinpl.py 的第629行和第705行附近开始,然后对比 can/interfaces/ixxat/canlib_vcinpl2.py 的第735行和第843行附近,重点关注 epoch offset 的设置和 CAN_INFO_START 的处理。使用 IXXAT 流量运行提供的 bus.recv 复现,并验证时间戳与 time.time 对齐,同时硬件得出的帧间隔保持不变。
由索引模型根据 Issue 内容生成。
描述
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.
- 主要语言
- Python
- 星标
- 1.6k
- 派生
- 697
- PR 合并指标
- 30 天内没有已合并 PR
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
hardbyte/python-can 的其他 Issue
-
bug
难度 1/5 1 小时以内 新手友好度 78/100
hardbyte/python-can#2077 · 1 条评论 · 1 个 reaction ·
-
bug
难度 1/5 1 小时以内 新手友好度 68/100
hardbyte/python-can#1922 · 1 个 reaction ·
-
enhancement
难度 5/5 一周以上 新手友好度 30/100
hardbyte/python-can#2102 ·
-
bug
难度 3/5 1-2 天 新手友好度 68/100
hardbyte/python-can#2092 ·
-
bug
难度 3/5 1-2 天 新手友好度 68/100
hardbyte/python-can#2091 ·
查看 hardbyte/python-can 的全部 Issue
相似的 Issue
-
enhancement
难度 2/5 1-3 小时 新手友好度 70/100
canonical/paas-charm#368 · 1 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
-
tech debt
难度 2/5 1-3 小时 新手友好度 75/100
-
难度 1/5 1 小时以内 新手友好度 90/100
StevenBlack/hosts#3256 ·
-
难度 1/5 1 小时以内 新手友好度 90/100
qualcomm/qai-appbuilder#275 ·