TX timestamps using PCAN-USB-Adapter with SocketCAN

[H.Mueller]

Hi,

I use a PCAN-USB-Adapter with SocketCAN API. To measure timestamps I use similar code as in candump.c from https://github.com/linux-can/can-utils

I notice the time difference for transmitted messages is only a few microseconds (let’s assume I feed 2 frames in the socket without delay, the resulting small differential time is identical in candump and own code). But from the chosen bitrate the actual frame difference on the CAN bus is much larger (about 1 millisecond). Can you please provide a hint on how to measure actual timings on the CAN bus.

PS: I'm using Linux within a Virtual Machine.

Best Regards
H.Müller

[M.Maidhof]

Hi,

the timings in a virtual machine are always a critical aspect, please try again in a real Linux system.

regards

Michael

[H.Mueller]

Hello,
I gave it a try on a real linux machine. With kernel 3.16 and bitrate of 83.3 kbit/s I obtained similiar results:

> candump -dextz any
...
(017.891362) can0 TX B E 12F40292 [8] 04 00 12 31 20 11 20 55
(017.891368) can0 TX B E 12F40292 [3] 30 12 1C
(017.944361) can0 RX - - 12F40212 [3] 2A 32 20
(017.946352) can0 RX - - 12F40212 [8] 73 4E 52 3A 30 36 FF 33
(017.946363) can0 RX - - 12F40212 [6] 39 38 31 31 17 00
(017.999360) can0 RX - - 11200112 [4] 00 00 00 81
(018.043353) can0 RX - - 12F40212 [3] 2A 32 20
(018.044356) can0 RX - - 12F40212 [8] 3D 3D 3D 3D 3D 3D 20 42
...

From my point of view, both Tx and Rx timings cannot be real bus timings, since the delay of only a few microseconds is too short.

Regards H.Müller

[M.Maidhof]

Hi,

please contact the SocketCAN user group for help. This looks like a SocketCAN issue, not related to our hardware or driver. Looks like it is the driver queue timestamp.

regards

Michael

[O.Hartkopp]

Hi,

I use a PCAN-USB-Adapter with SocketCAN API. To measure timestamps I use similar code as in candump.c from https://github.com/linux-can/can-utils

Hello H.Mueller,

which driver are you using?

Do you use the PEAK driver from the PEAK Website (with netdev support) OR do you use the Linux mainline driver which comes with your Linux distribution?

The big difference is that the mainline driver echo's the CAN frame into the host system after the frame has been sent successfully on the CAN bus. The PEAK (from the PEAK website) driver does not support the CAN frame echo on driver level (e.g. like slcan and the default vcan setup) - so the echo is created in the network layer (at transmission processing time). Therefore the tx frame timestamps can stick together in an unusual way.

If you have a recent Linux kernel I would suggest to use the mainline driver.
What's you Linux version?

You can get it with 'uname -a'

Regards,
Oliver

[O.Hartkopp]

Hello,
I gave it a try on a real linux machine. With kernel 3.16 and bitrate of 83.3 kbit/s I obtained similiar results:

Ah, Linux 3.16 => please use the mainline driver and not the PEAK driver to get the correct TX timestamps with the correctly echo'ed CAN frames.

> candump -dextz any
...
(017.891362) can0 TX B E 12F40292 [8] 04 00 12 31 20 11 20 55
(017.891368) can0 TX B E 12F40292 [3] 30 12 1C

Smells like the non-mainline driver ...

(017.944361) can0 RX - - 12F40212 [3] 2A 32 20
(017.946352) can0 RX - - 12F40212 [8] 73 4E 52 3A 30 36 FF 33
(017.946363) can0 RX - - 12F40212 [6] 39 38 31 31 17 00
(017.999360) can0 RX - - 11200112 [4] 00 00 00 81
(018.043353) can0 RX - - 12F40212 [3] 2A 32 20
(018.044356) can0 RX - - 12F40212 [8] 3D 3D 3D 3D 3D 3D 20 42
...

From my point of view, both Tx and Rx timings cannot be real bus timings, since the delay of only a few microseconds is too short.

The timestamps (017.946352) and (017.946363) are very close indeed.

Probably the PCAN USB adapter sent two CAN frames in an USB bulk message - and after decoding the message inside the driver the two CAN frames are stamped directly after another.

AFAIK the PCAN USB adapter provides some hardware timestamp, which you can get with some HWSTAMP control message too. Don't know if this is feasible for you.

Regards,
Oliver