When the tortoise beats the hare... a real life example!
So.. anyone that has used OBDX on J2534 knows its fast. It will max out the CAN network at actual baud rate limits if you pop a scope on and monitor.
This is due to the way I have optimized the code to have the data ready to send instantly. Whereas when comparing with other tools such as a GM MDI, those kinda of scantools run entire operating systems which will inherently have delay from other running systems causing delays between frames to always be longer then actually requested by the module.
Now.. this does actually cause problems in such a scenario as below.
When following the iso-15765 standard, the flow control messages tell you how fast you are allowed to send a message.
For example:
7E8 30 00 00 AA AA AA AA AA
Where:
30 = flow control (Continue sending data)
00 = block size, continue sending no limit
00 = Separation time, where 0 means go as fast as possible.
Another example is:
7E8 30 00 05 AA AA AA AA AA
Where:
05 = Separation time, where 5 means wait 5 milliseconds between each consecutive message.
And finally:
7E8 30 00 F1 AA AA AA AA AA
Where:
F1 = Separation time, where F1 means wait a
minimum 100microseconds between frames.
Between F1 to F9, the timing goes to microseconds. Where F1=100micros and F9=900micros.
The key word here, is "minimum" time between frames.
Now, I have a bench GM ECU which keeps failing to flash. All the data is there, but the ECU fails to respond as if its somehow missed the data. And.... thats exactly what is happening!
Even though the OBDX is meeting its obligations exactly and using 100micro delay between each frame, the ECU is missing data being sent to it as it is unable to keep up!
I had the scope up and I am exactly 100 to 102microseconds between each frame.
When monitoring the GM MDI, its up around the 300-600microseconds, so theres quite a difference which also varies between frames.
All is not lost though, it just means that another firmware is inbound for the OBDX tools to deal with this situation exactly.
The plan is to set the 'actual' minimum delay between frames to be 500micros. Anything less then this will be set to 500 as a bit of a safety barrier.
Even though we are talking about a fraction of a single millisecond, every delay makes a big difference on the total flash time.
Going from even 1ms to 500us means its technically sending 2x as fast, which results in shaving of several minutes on big flashes.
This is the difference between a 6min flash at 1ms, and 3min flash at 500us.
Amazingly, I have not had issues when dealing with modules which say "send as fast as possible". These are obviously prepared to deal with the high speed and process through. But it appears to be situations where modules already require additional time where using the recommended minimum time is not actually a good idea.
So... thats my show and tell for the day!
