python-can doesn't appear to be using hardware timestamps with socketcan

オープン

#1,881 2024年10月29日に作成コメント 3 件リアクション 0 件担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度: 4/5
見積もり時間: 3〜5日
初心者へのやさしさ: 35/100

issue の種類: バグ
明瞭さ: おおむね明確
活発さ: 停滞
技術スタック: linux, python
領域: embedded-iot, networking

調査の方向性

まず、標準のカーネルドライバーを使用する Debian 12 上で、candump -ta -H can1 と python -m can.logger -c can1 の比較を再現します。SocketCAN の受信パスと logger のエントリーポイントを調査し、タイムスタンプがどのように取得されるかを確認します。利用可能な場合にハードウェアタイムスタンプが使用され、取得されたタイミングが文書化された動作と一致し、既存のテスト構成で対応できる場合は回帰テストも含まれていれば完了です。

索引モデルが issue の本文から書いたものです。

説明

bug

Describe the bug

To Reproduce

Run two captures at the same time, one using candump with hardware timestamps :

candump -ta -H can1

The other utilising python-can e.g. logger :

python -m can.logger -c can1

If you then dump the output into a spreadsheet and compare frames, the output is quite different. For example, on a cyclic message on our hardware, I can see the cycle with candump -H is stable +/- 5 microseconds. With the timestamps from python-can the variance seems to be +/- 900 microseconds.

Expected behavior

The python can docs say :

The timestamp field in a CAN message is a floating point number representing when the message was received since the epoch in seconds. Where possible this will be timestamped in hardware.

So I'd have expected the hardware timestamps to have been enabled as with candump -H.

Additional context

OS and version: Debian 12 (6.1.112-1)
Python version: 3.11
python-can version: 4.4.2
python-can interface/s (if applicable): Peak PCAN-USB X6

We're using the standard kernel drivers not peak's custom drivers.

Traceback and logs

主要言語: Python
スター: 1.6k
フォーク: 697
PR マージ指標: 30日以内にマージされた PR はありません

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
リポジトリをフォークし、ブランチを切って変更します。
issue 番号を参照したプルリクエストを送ります。

hardbyte/python-can のほかの issue

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

難易度 2/5 1〜3時間初心者へのやさしさ 88/100

hardbyte/python-can#2103 · 2026年9月18日に作成
Unhashable type for Systec interface errors オープン

bug

難易度 1/5 1時間未満初心者へのやさしさ 78/100

hardbyte/python-can#2077 · コメント 1 件 · リアクション 1 件 · 2026年7月13日に作成
New error behaviour when calling `flush_tx_buffer` for several interface types オープン

bug

難易度 1/5 1時間未満初心者へのやさしさ 68/100

hardbyte/python-can#1922 · リアクション 1 件 · 2025年2月22日に作成
Add support for the more efficient ElmüSoft Candlelight Protocol オープン

enhancement

難易度 5/5 1週間以上初心者へのやさしさ 30/100

hardbyte/python-can#2102 · 2026年9月15日に作成
PCAN message timestamps drift after macOS system sleep オープン

bug

難易度 3/5 1〜2日初心者へのやさしさ 68/100

hardbyte/python-can#2092 · 2026年8月21日に作成

hardbyte/python-can の issue をすべて見る

似ている issue

[Bug] reef-hermes tells me to resume with hermes --resume, which does not work from my shell オープン

area: harness bug status: needs-triage

難易度 2/5 1〜3時間初心者へのやさしさ 75/100

Human-Agent-Society/reef#625 · 2026年9月24日に作成
Bump transitive axios to >=1.18.0 to address GHSA-hcpx-6fm6-wx23 オープン

難易度 2/5 1〜3時間初心者へのやさしさ 70/100

coinbase/cdp-sdk#828 · 2026年9月24日に作成
AccessibleResourceCard/AccessibleChannelCard crash when a resource has more than one learning activity (getActivityTags returns an object instead of an array) オープン

難易度 1/5 1時間未満初心者へのやさしさ 80/100

learningequality/kolibri#15351 · コメント 2 件 · 2026年9月24日に作成
audeer.path(): optionally expand environment variables オープン

難易度 2/5 1〜3時間初心者へのやさしさ 75/100

audeering/audeer#212 · コメント 1 件 · 2026年9月24日に作成
Name consistency オープン

難易度 2/5 1〜3時間初心者へのやさしさ 75/100

eellak/triplestore#65 · コメント 1 件 · 2026年9月24日に作成

Python の issue をもっと見る