Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

IXXAT: timestamps read 1.5 x wall time plus adapter uptime (misplaced parenthesis in _timeoffset; start tick never captured in vcinpl2)

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#2,103 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
88/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
python
Bereich
backend, networking

Rechercherichtung

Beginnen Sie in can/interfaces/ixxat/canlib_vcinpl.py bei etwa den Zeilen 629 und 705 und vergleichen Sie anschließend can/interfaces/ixxat/canlib_vcinpl2.py bei etwa den Zeilen 735 und 843. Konzentrieren Sie sich dabei auf die Einrichtung des Epoch-Offsets und die Behandlung von CAN_INFO_START. Führen Sie die bereitgestellte bus.recv-Reproduktion mit IXXAT-Datenverkehr aus und überprüfen Sie, dass die Zeitstempel mit time.time übereinstimmen, während der aus der Hardware abgeleitete Frame-Abstand unverändert bleibt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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:

  1. A misplaced parenthesis in the epoch offset, in both backends:

    • can/interfaces/ixxat/canlib_vcinpl.py line 629
    • can/interfaces/ixxat/canlib_vcinpl2.py line 735
    self._timeoffset = start_begin + (start_end - start_begin / 2)

    This evaluates to 1.5 * start_begin + start_end instead of the midpoint start_begin + (start_end - start_begin) / 2. Hence the 1.5 x wall-clock epoch.

  2. The start tick is never captured in canlib_vcinpl2.py (line 843): the CAN_INFO_START check is an elif sibling of the CAN_MSGTYPE_INFO branch rather than nested inside it, so an INFO message is consumed by the first elif and _starttickoffset stays 0. Every timestamp then carries the adapter's uptime. canlib_vcinpl.py on main has 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 main at 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.
Vorherrschende Sprache
Python
Sterne
1.6k
Forks
697
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus hardbyte/python-can

Alle Issues in hardbyte/python-can

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.