Consecutive Frame timing

[setteZ]

Hi,
I am not sure about the root cause, but let's start from here.
Is there a way to configure a delay between Consecutive Frames?
I am facing a problem with the UDS flashing sequence, in particular during the Transfer Data stage. The payload is correctly divided into separated frames, but they are sent with a delay of 0.5-0.6ms between each other, and for the device I am tring to update it is probably near to the limit. What I am experiencing is that in a random way I do not get a response at the end of the last trasmitted frame.
Following an example of timing (with positive response):

Chn Identifier Flg   DLC  D0...1...2...3...4...5...6..D7       Time     Dir
 0    18DA12F1 X       8  10  C2  36  01  91  90  00  F8      52.391420 R
 0    18DAF112 X       8  30  00  00  00  00  00  00  00      52.392530 R
 0    18DA12F1 X       8  21  D9  FF  28  A6  DC  0F  00      52.393900 R
 0    18DA12F1 X       8  22  00  00  00  00  00  FF  FF      52.394500 R
 0    18DA12F1 X       8  23  FF  FF  FF  FF  FF  FF  FF      52.395010 R
 0    18DA12F1 X       8  24  FF  FF  FF  FF  FF  FF  FF      52.395600 R
 0    18DA12F1 X       8  25  FF  FF  FF  FF  FF  FF  FF      52.396200 R
 0    18DA12F1 X       8  26  FF  FF  FF  FF  FF  FF  FF      52.396800 R
 0    18DA12F1 X       8  27  FF  FF  FF  FF  FF  FF  FF      52.397400 R
 0    18DA12F1 X       8  28  FF  FF  FF  FF  FF  FF  FF      52.397990 R
 0    18DA12F1 X       8  29  FF  FF  FF  FF  FF  FF  FF      52.398510 R
 0    18DA12F1 X       8  2A  FF  FF  FF  FF  FF  FF  FF      52.399100 R
 0    18DA12F1 X       8  2B  FF  FF  FF  FF  FF  FF  FF      52.399700 R
 0    18DA12F1 X       8  2C  FF  FF  FF  FF  FF  FF  FF      52.400300 R
 0    18DA12F1 X       8  2D  FF  FF  FF  FF  FF  FF  FF      52.400900 R
 0    18DA12F1 X       8  2E  FF  FF  FF  FF  FF  FF  FF      52.401410 R
 0    18DA12F1 X       8  2F  FF  FF  FF  FF  FF  FF  FF      52.402000 R
 0    18DA12F1 X       8  20  FF  FF  FF  FF  FF  FF  FF      52.402600 R
 0    18DA12F1 X       8  21  FF  FF  FF  FF  FF  FF  FF      52.403200 R
 0    18DA12F1 X       8  22  FF  FF  FF  FF  FF  FF  FF      52.403800 R
 0    18DA12F1 X       8  23  FF  FF  FF  FF  FF  FF  FF      52.404390 R
 0    18DA12F1 X       8  24  FF  FF  FF  FF  FF  FF  FF      52.404910 R
 0    18DA12F1 X       8  25  FF  FF  FF  FF  FF  FF  FF      52.405500 R
 0    18DA12F1 X       8  26  FF  FF  FF  FF  FF  FF  FF      52.406100 R
 0    18DA12F1 X       8  27  FF  FF  FF  FF  FF  FF  FF      52.406700 R
 0    18DA12F1 X       8  28  FF  FF  FF  FF  FF  FF  FF      52.407300 R
 0    18DA12F1 X       8  29  FF  FF  FF  FF  FF  FF  FF      52.407890 R
 0    18DA12F1 X       8  2A  FF  FF  FF  FF  FF  FF  FF      52.408490 R
 0    18DA12F1 X       8  2B  FF  FF  FF  FF  FF  FF  55      52.409000 R
 0    18DAF112 X       8  02  76  01  00  00  00  00  00      52.411050 R

Thanks in advance.

[pylessard]

yes, it is possible. It is in fact, one of the main feature of the ISOTP protocol.
The receiver (the server) must inform the sender about it's speed capabilities by providing a STMIN value (Minimum Separation Time).

In your case, your server impose no constraint on the timing, therefore, your client just go as fast as it can.
Look at the 2nd message 30 00 00 00. This is a flow control message. The 3rd byte is STMIN.

If you have no control over the server. you can most likely override that value depending on the isotp layer you use. Isotp sockets supports that. The pure python implementation in my isotp package also has a parameter to override it.

Hope that helps.

[setteZ]

thank you very much for the note, I was able to change stmin in the flow control message and indeed the timing of the following frames has changed.