PEAK-System Forum

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 ...

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 ...

Hi,

Please consider the following comments

A) Enhance PCAN-Basic Documentation on TPCANTimestamp
So far it is noted
"Calculation of total of microseconds : micros + 1000 * millis + 0xFFFFFFFF * 1000 * millis_overflow"

I suggest to explicit hint the reader to overflow issues. For usage in C/C ...

Hello Keneth,

Thanks for your fast resonse.

In fact you are right after another test. If I power off of the sender, I do not see these unexpected messages.
If the sender is still powered, it seems it will keep trying to re-send those messages until they get read as you wrote.
That is what I ...

Hello,

If a user program is ended without calling CAN_Uninitialize (e.g. due to forced termination from task manager) at high bus loads on restart (e.g. also visible in PCAN View) the receive buffer contains false messages (i.e. theses messages are not currently on the bus - instead this is traffic ...

peak-linux-driver-7.12 is online with still the same problem