Comparing CAN interface transfer delays

In this article, “Comparing CAN interface transfer delays”, I will test and compare four different types of Kvaser CAN interfaces.

• PCIe interfaces mounted on the motherboard
• USB connected external interfaces
• Ethernet connected interfaces
• WLAN (WiFi) connected interfaces

The goal is to measure and compare the difference in transfer delay between interface types.

The CAN-BUS I used for testing is built using four Kvaser T-Cannector v2s and is terminated at each end. During the tests I had 7 interfaces connected with a total of 13 channels.

All interfaces are connected to the same computer. I use a Router to make sure that I isolate the Ethernet interfaces from unwanted traffic. The Router is also a Wi-Fi access point.

One of the PCIE interfaces is used as a receiver. (The PCIE interfaces were shown to be the fastest ones, with variation between the different PCIE cards extremely low).

The target is to measure the Transfer Delay Time. I define this delay as: 

The time needed from when the software has a package that shall be transmitted, until the time when the software has received it (on another channel).

Sending a standard CAN message, 11 bit ID and 8 byte data payload.

With a 1MBit/s bitrate, this message takes approximately 110 µs to transfer on the CAN bus (measured with an oscilloscope). Please note that I am actually sending many messages, and calculating the mean time of transfer delay.

Sending and receiving with a Kvaser PCIEcan 4xHS, I measure a total delay of 225µs. (From pressing the TX button until the software has used the CANRead command).

The CAN msg occupies appr 110µs on the CAN-bus. The CANWrite command takes appr 25µs.

225 minus 110 minus 25 is 90µs.

So we need to find out what happens during these 0.090ms. The message is stored somewhere in the electronics. Most probably it spends 45µs in the transmit queue and after that, 45µs in the receiving queue. (I have no method of checking that without doing some advanced measurements on the card, so I assume that both processes take the same amount of time).

According to this analysis, the PCIE interface delay is 45µs.

I use the values from [1.1. Checking internal interface delay] and the measured delay times and calculate the TX queue times for the different interface types.

PCIE connected interface

As seen in the tables above, the delays are extremely low and it is most probably the fastest method available for connecting a CAN interface.

USB connected interface

I used our most popular product, the Kvaser Leaf Light HS v2. This is not our fastest USB CAN interface, but it is a good example of a typical USB interface. As we can see in the table above, it adds an extra delay of 100µs when compared to a PCIE interface.

LAN connected interface

I used two of our LAN connected products, the Kvaser DIN Rail SE400S-X10 and the Kvaser Ethercan HS.Both show almost the same results. Compared to the PCIe cards, they add an extra delay of 225µs when compared to a PCIE interface.

WLAN (WiFi) connected interface

I used the Kvaser BlackBird v2 to test WLAN interfaces. I connected it in two different modes. The standard infrastructure mode and the Windows Hosted Mode. I measure a total delay of 1ms and 2ms when compared to a PCIE interface

Conclusion

If you need very fast response times, then you should select the PCIe or USB connected interfaces. They provide a stable and secure connection to your CAN bus. The LAN connected interfaces are also a good choice, but it is important to understand that the increased transfer delay can cause problems in some applications. When using the WLAN interfaces, it is important to remember that the WiFi environment can cause long transfer delays.

What happens if we use 250kBit/s and 29 bit ID?

An 8 byte CAN message with 29 bit ID takes approximately 520 us to transfer. I adjust the table from [1.2. Comparing interface types] :

When looking at the SUM, the PCIE, USB and LAN interfaces, give almost the same result. So in this case, selection of which interface family to use more or less depends upon how you want to connect to your CAN-bus.

PCIE interfaces require stationary hardware, USB interfaces allow you to be more flexible and the LAN interfaces make it possible to extend the distance between the CAN-bus and the client. The WLAN interfaces are also a good choice, especially in situations where the user is “monitoring” an object.

To be able to detect the delays between sending and receiving data, I made a very simple program that detects the time when sending a package and the time of package receipt.

I wrote the basic test program in DELPHI (Pascal) and it uses Kvaser CANLib. It is not super optimized.

Timer resolution

I am using the Performance Counter provided by the Windows operating system and the CPU. On my hardware, the frequency of this counter is 10MHz. That gives me a resolution of 0.1us. 

Precision of results

Please note, the variance of the results can be quite high, ±50% is not uncommon, so be a bit careful when using the results. Use the numbers more as a guideline.

Procedure in word:

• Something triggers the TX sequence. In most cases, it is me clicking on a button.
• As quickly as possible, readout the performance counter. This value is T0 (Time Zero).
• Add this T0 into a CAN message, and transmit it via the desired interface (channel).
• Now the software has to wait until CANlib sends an event, “CAN DATA available”.
• As quickly as possible, readout the performance counter. This value is T1.
• Read the CAN message from the CANlib buffer.
• Now we have: A CAN message, where the ID identifies the sender, and the payload contains T0.
• We can now subtract T0 from T1, and get the transfer delay, dT=T1-T0.

Now we know the sender’s ID and the transfer delay.

When I send a CAN frame, or “package”, I use an 11 bit identifier and 8 data bits.

At 1MBit baud rate, a package like this is approximately 110µs long.

(The size differs a bit because of the stuff bits that are added).

The ID will hold the HANDLE of the transmitting interface.

The 8 data bytes will hold the value of the Performance counter (UINT64). 

This makes it possible for the receiving procedure to determine who sent it, and most important, when it was sent.

2.3.1 CAN interfaces used

• Kvaser PCIEcan HS v2 (0866-3)
• Kvaser PCIEcan 4xHS  (0693-6)
• Kvaser Mini PCI Express HS v2 (1038-3)
• Kvaser Leaf Light HS v2 (0685-0)
• Kvaser BlackBird v2 (0671-3)
• Kvaser DIN Rail SE400S-X10 (1059-8)
• Kvaser Ethercan HS (0976-9)

2.3.2 CAN test equipment used

• Kvaser T-Cannector v2 (0776-5)

2.3.3 Computer

The computer is a standard Windows 10 machine.

• Processor: Intel Core i7 4770 3.4GHz
• Motherboard: Gigabyte Z87X-UD5H-CF

2.3.4 Router

• Dovado TINY AC
• This is a typical home router, I used it as a WiFi router, DHCP server and LAN provider.

2.3.5 Switch

• Netgear GS105E
• Standard 5 Port Gigabit EthernetSwitch