PUDS_PARAM_SEPARATION_TIME

[MaxenceD]

Hello,
The UDS API documentation reads:

Description: This value is used to set the SeparationTime (STmin) parameter defined in the ISO‐TP standard: it
indicates the minimum time the sender is to wait between the transmissions of two Consecutive Frames.

Possible Values: 0x00 (unlimited) to 0x7F (range from 0ms to 127ms). Note: as set in ISO‐TP standard, values
from 0xF1 to 0xF9 should define a range from 100µs to 900µs, but due to system time resolution limitation
those value are defaulted to 1ms. Other values are ISO reserved

Two questions:

- Is this information up to date? So it is not possible to have a separation time shorter than 1ms, even though when using a separation time of 0 the CAN dongle successfully sends messages at a faster rate than 1ms?

- When using value 0xF3 in my current SW the API defaults to 1ms, however the timestamps show a quite inconsistent transmission time. The average is around 1ms for TP-ISO messages, but there are often messages send at a faster rate while later messages seem to "compensate" the rate by being send at a slower rate than 1ms. Is this behavior normal/expected in TPISO, or is it some weird behavior due to the transmission rate being shorter than 1ms, or is it just the timestamps being not accurate ?

One example of Transmission Time / Delta Time (data interpreted directly from the PCAN-UDS API DEbug log file):

187.779394 (0.001681)Rx 0x7e8 30 00 F3 AA AA AA AA AA
187.779840 (0.000446)Tx 0x7e0 21 B9 F4 A8 A8 91 70 00
187.781265 (0.001425)Tx 0x7e0 22 68 D9 66 1C 20 82 35
187.782348 (0.001083)Tx 0x7e0 23 91 10 00 F7 39 F6 D2
187.783350 (0.001002)Tx 0x7e0 24 38 91 70 00 78 D9 77
187.783792 (0.000442)Tx 0x7e0 25 DC 52 02 57 6D FF 33
187.784178 (0.000386)Tx 0x7e0 26 F3 09 A3 00 08 3C 05
187.784488 (0.000310)Tx 0x7e0 27 91 10 00 F7 79 F3 FA
187.784814 (0.000326)Tx 0x7e0 28 38 91 70 00 F8 39 F0
187.785644 (0.000830)Tx 0x7e0 29 6F 63 91 10 00 F7 91
187.786417 (0.000773)Tx 0x7e0 2A 10 00 27 39 F1 FC 38
187.786831 (0.000414)Tx 0x7e0 2B 39 22 DA 68 42 10 BA
187.787217 (0.000386)Tx 0x7e0 2C 02 8B F0 0F 43 EE 07
187.787612 (0.000395)Tx 0x7e0 2D 76 26 DA 80 7F 4F 0B
187.788437 (0.000825)Tx 0x7e0 2E 00 55 55 55 55 55 55
187.790023 (0.001586)Rx 0x7e8 02 76 56 AA AA AA AA AA
187.791626 (0.001603)Tx 0x7e0 10 62 36 57 02 F4 3C 08

[K.Wagner]

Hello,

- Is this information up to date?

No, it is not. The current version does take into account STmin values between 0xF1 and 0xF9. The help file was unfortunately not updated. We are preparing a new version of the API as well as a reviewed help file.

... So it is not possible to have a separation time shorter than 1ms, even though when using a separation time of 0 the CAN dongle successfully sends messages at a faster rate than 1ms?

By setting STmin to 0, the API will try to send packets as soon as possible. Packets are passed to the device driver and the device writes packets to the CAN bus as fast as it can.

- When using value 0xF3 in my current SW the API defaults to 1ms, however the timestamps show a quite inconsistent transmission time. The average is around 1ms for TP-ISO messages, but there are often messages send at a faster rate while later messages seem to "compensate" the rate by being send at a slower rate than 1ms. Is this behavior normal/expected in TPISO, or is it some weird behavior due to the transmission rate being shorter than 1ms, or is it just the timestamps being not accurate ?

First of all note the following:

• Windows is not a real time system. The small period of time used and recognized is 1 millisecond.
• Timing varies depending on the kind of hardware used
• The ISO-15765 norm states that the time to wait starts after a package has been sent.

Due to the points described before, the API needs time until it gets confirmed, that a package was sent (at leas 300µs). For this reason, when STmin is <= 300µs, it is same as if you specify 0 for it. Added to this, when using a USB device, this time grows up to 800µs. Only a PCI card would response between 400µs and 900µs. That is why you see this time behavior.