Bug report: RC fails intermittently with large 0x22 rspns payloads (159 bytes)

Cali_Chuck

Hi @aol. OK so with my workaround to remove the OBD response prefix from the bug report I filed earlier today I was able to proceed and then ran into the next issue.

I am using Claude to break down various multi-byte LID blobs coming back from my ECU. We're making very fast progress. The first four blob types are working just fine with mode 0x22 DID response payloads of up to 26 bytes.

However, when I moved on to the biggest blob which is 159 bytes I get random behavior from RC. On the PID definition screen with live data activated, It does show me a large block of rapidly updating bytes for a couple of seconds, then freezes. after several more seconds there's another batch up updated, then the freeze/update/freeze/update cycle just keeps going.

I followed a structured debugging process with Claude with simultaneous CAN packet captures to observe. We pulled out all the other OBD PID definitions, then removed & rebuilt this definition, power cycled the phone, redid my BT pairing to OBDLink, etc.

The odd thing is that it does work for several transactions, then fails due to NRC 0x13 ("incorrectLengthOrInvalidFormat")``. So clearly what I'm attempting is possible it's just running into some internal limit in RC.

From what I'm seeing on the live data screen, the full ISO-TP aggregated frame is being reassembled properly at the driver level and displays in RC.

Long story short, I'm guessing that your working buffer to receive ISO-TP payloads is somewhere between 64 and 100 bytes, and I'm overflowing it. I'll upload the relevant part of the Claude dialog to this note, but it wants me to tell you:

Either result would be useful, concrete evidence to hand RaceChrono's developers. And still consistent across all three captures: the occasional correct request (03 22 19 07) does still slip through at a steady ₄% rate in every test — worth mentioning to them too, since a bug that's consistently wrong 96% of the time but correct 4% of the time is a stronger clue about the underlying mechanism than an all-or-nothing failure would be.

So dunno if this is a bug or an RFE. If you're expecting 160 byte ISO-TP payloads to work then it would be a bug. If you know the working buffer is much smaller, then I guess I'm asking for an RFE to handle ISO-TPs of at least 160 bytes. Perhaps 250 would be more useful.

Here is a link to a PDF of the relevant part of the Claude RC debug session. LMK if you want pcaps or anything else. Happy to test out a cbuild, if this is as easy as just recompiling with a bigger buffer for this.

https://www.dropbox.com/scl/fi/yzopzkw13oslqlcckdwis/Claude-debug-session-on-RaceChrono-intermittent-failures-with-159-byte-OBD-mode-0x22-payloads.pdf?rlkey=snboqvq4gijtv425pdcbex9vz&st=4u10fkos&dl=0

aol

There's no intentional limit other than 4096 bytes that I can see.

Would you be able to provide me with a TCP/IP simulator script for this, along with vehicle profile, and test instructions? It's very hard to construct a proper test for this, with my limited knowledge of the issue, and of what you're trying to do.

The TCP/IP script would basically emulate OBDLink for the ECU you're using. I'd connect to it using the "WiFi" selection on the app. I think you should be able to build it using the data logs (from "Save device output") and Claude.

This approach would help me to find the other bug too.