I2C SPI USB CAN eSPI Cable Testing View All Videos Quick Start Guides Software Downloads App Notes White Papers User Manuals Knowledge Base Sales Support About Us
Products Blog Sales Support Contact Search
How Do I Determine the Latency Between CAN Ports?
Rena Ayeras

Question from the Customer:

How can I accurately determine the latency when sending data from one CAN port to another?

I am working with the Komodo CAN Duo Interface. Using strace with the Python loopback code, I see that the time between send and read is about 100 microseconds. The Komodo Software API command settings I am using are km_latency = 0 and timeout_ms = infinite. However, with a bitrate of 250 kHz, I expect it would take longer: at least 512 microseconds to send 8 bytes of data (8 bytes over CAN with ext ID = 128 bits).

Response from Technical Support:

Thanks for your question! There are considerations to factor in for latency, which are described in the following sections.

Setting Latency

Latency can be set to 0. When the latency is set to 0, the function sends the appropriate value to the firmware such that the firmware terminates the USB Request Block (URB) for each CAN packet sent back to the OS. This ensures the smallest latency possible.  You can also set the latency for a specific time value.  In this case, measure the time is takes for the CAN packet read in km_can_read() to execute, and then set the latency with an appropriate value.

Here are examples of setting the latency with the timeout_ms command:

  • If timeout_ms is set to KM_TIMEOUT_IMMEDIATE, then km_can_read() becomes non-blocking and returns immediately.
  • If timeout_ms is set to KM_TIMEOUT_INFINITE, then km_can_read blocks indefinitely until data is received.

For more information, please see the API Documentation section of the Komodo CAN Interface User Manual.

USB Traffic and Inherent Latency

There is an inherent latency when managing USB traffic as asynchronous USB Request Blocks (URBs) on the host PC. This occurs because the OS only sees data when an URB is either entirely filled, or the USB packet is short (terminated before the URB size is reached).

For this example, we will assume the size of the URBs is 100 bytes and each CAN packet only consumes 20 bytes of USB data. In this case, to fill the URB with 100 bytes, the URB would need to see 5 packets to get any USB data back to the OS. However, seeing 5 packets may take some undefined amount of time.

In order to determine the latency, a short packet will be issued by the Komodo interface once the latency timeout has elapsed.  This allows the data to be visible to the OS and API.

We hope this answers your question. Additional resources that you may find helpful include the following:

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

Request a Demo