Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transmission Time is not accurate when python-can with Kvaser is used. #228

Open
mdabrowski1990 opened this issue Oct 18, 2023 · 4 comments
Labels
bug Something isn't working CAN Related to CAN specific implementation

Comments

@mdabrowski1990
Copy link
Owner

mdabrowski1990 commented Oct 18, 2023

When python-can is used as a CAN bus manager, then timestamps of message are not accurate (not synchronized with local time) therefore attribute transmission_time of CanPacketRecord is not accurate.

Affects:

  • return from PyCanTransportInterface.send_packet and PyCanTransportInterface.async_send_packet
  • return from PyCanTransportInterface.receive_packet and PyCanTransportInterface.async_receive_packet
  • PyCanTransportInterface.n_as_measured
  • PyCanTransportInterface.n_ar_measured
  • PyCanTransportInterface.n_bs_measured
  • PyCanTransportInterface.n_cr_measured
@mdabrowski1990 mdabrowski1990 added bug Something isn't working CAN Related to CAN specific implementation labels Oct 18, 2023
@mdabrowski1990
Copy link
Owner Author

Issue reported in python-can repository - hardbyte/python-can#1676

@mdabrowski1990
Copy link
Owner Author

Response from Kvaser as issue was reported in their system:

There are a couple of misconceptions in your program.

  • That Timer and the timestamps returned with a CAN frame are related.
  • That the time checked on completion of a canWrite call is the time when the CAN frame has been placed on the CAN bus.

The timestamps generated by the Kvaser Hybrid Pro CAN/LIN are based on a counter clock within the unit. This counter is incremented based on a timer function and can drift based on the quality of the oscillator. We do use high quality oscillators to ensure proper bit timing. But no two clocks are exactly the same. This counter is used to increment a time domain associated with a handle to the channel. Each handle by default gets a unique time domain that is reset to zero when the handle goes bus on. The resulting time is the returned time stamp on a frame. Again, has nothing to do with a computer’s system clock or any timer within the PC. So, any clock in the PC can drift independent of the drift in the clock used for the timestamps.

With that said, if you used our direct API you do have the ability to place handles to channels on the same device or handles to channels on multiple Kvaser USB devices that support MagiSync in the same time domain. MagiSync guarantees that a tick on one Kvaser unit’s clock is synchronized with the tick on another Kvaser unit’s clock. Then by placing the handles in the same time domain, the time stamps represent the same moment in time (still not linked to any computer provided clock).

As for checking the time after a canWrite call completes, this does not take into consideration that the canWrite call just places the frame in a transmit buffer of our API. How long the frame sits in the transmit buffer will be dependent on the number of frames being written and received and other calls being placed to the unit. All such commands must be passed over the USB communication before the frame is actually transmitted. The Kvaser Hybrid does have the ability to receive an echo of frames transmitted on a handle in the handle’s receive buffer. The time stamp on this frame would be a better representation of when the frame was actually placed on the CAN bus.

However, you can still get inversion (on a much lower level). If I have two channels that support MagiSync connected to the same CAN bus and their handles are placed in the same time domain, the transmit echo for a sent frame channel 1 may still have a timestamp greater than the same frame received on channel 2. This usually only happens on a CAN bus that has extreme bursts of traffic or is heavily loaded. The reason for this inversion is receive interrupts are given a higher priority than transmit interrupts in our devices. The transmit echo placed in the receive buffer is timestamped when the frame has been successfully placed on the CAN bus causing an interrupt to notify us that we can place the next frame. But if a receive interrupt occurs at the same time, the receive interrupt gets priority and is handled first slowing down the application of a timestamp on the echo.

@mdabrowski1990
Copy link
Owner Author

mdabrowski1990 commented Oct 25, 2023

Python file for reprocuding the problem is located in examples

@mdabrowski1990 mdabrowski1990 changed the title Transmission Time is not accurate when python-can is used. Transmission Time is not accurate when python-can with Kvaser is used. Nov 22, 2023
@mdabrowski1990
Copy link
Owner Author

mdabrowski1990 commented Sep 19, 2024

Proposed a solution on python-can side to solve the problem: hardbyte/python-can#1861

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working CAN Related to CAN specific implementation
Projects
None yet
Development

No branches or pull requests

1 participant