PCAN message timestamps drift after macOS system sleep

Open
#2,092 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
68/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
embedded-iot

Research direction

Start at the PcanBus timestamp calculation and reproduce the controlled macOS sleep test with a PCAN adapter. Verify that received CAN message timestamps remain aligned with wall-clock time after wake, before the BLF writer or CSV converter, and that reconnecting the adapter does not affect the result.

Written by the indexing model from the issue text.

Description

bug
Describe the bug

On macOS, CAN message timestamps from PcanBus drift behind the current wall-clock time after the computer sleeps.
PcanBus combines the Mac boot time with a PCAN elapsed-time counter. The counter pauses while macOS sleeps, so every sleep cycle increases the timestamp error.
The incorrect timestamp is produced before BLF or CSV logging. Both log formats preserve the timestamp received from python-can.

To Reproduce
  1. Connect a PCAN adapter on macOS.
  2. Start receiving CAN messages and record their timestamps.
  3. Put the Mac to sleep, then wake it.
  4. Receive another CAN message.
  5. Compare its timestamp with the current wall-clock time.

The CAN timestamp will be behind the wall clock by approximately the amount of time the Mac spent asleep.
Unplugging and reconnecting the PCAN adapter does not reset the drift.

Expected behavior

CAN message timestamps should match the current wall-clock time after the Mac wakes from sleep.
System sleep should not cause timestamps to drift backward.

Additional context

OS and version: macOS 26.5.1, build 25F80
Python version: 3.13.14
python-can version: 4.6.1
python-can interface/s: pcan via PCAN/MacCAN
The issue has been confirmed on macOS. Potential impact on Windows has not been tested.

Traceback and logs No exception is raised. The problem appears in the timestamps assigned to received CAN messages.

During a controlled sleep test:

Wall-clock elapsed time: 73.6 seconds
PCAN elapsed counter: 60.9 seconds
Difference: 12.7 seconds
Recorded macOS sleep: 12.7 seconds

The difference between the wall clock and PCAN counter matched the macOS sleep duration.
The incorrect timestamps were present before reaching the BLF writer and CSV converter, so those components were ruled out.
Disconnecting the PCAN adapter for 60 seconds did not reset the elapsed counter or correct the timestamp.

Dominant language
Python
Stars
1.6k
Forks
697
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from hardbyte/python-can

All issues in hardbyte/python-can

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.