Hi - mentioned this briefly in a prior post but working on this specific topic today and have a reproducible bug in IOS. Maybe Android but I don't run that.
To be clear - this query is on OBD not CAN.
I am able to use mode $01 queries with standard single byte OBD PIDs just fine over an OBDLink MX+ on the OBD port. So far so good.
I am in the process of mapping out the deeper two byte UDS DIDs for my engine with Claude's help. We have 60+ DIDs mapped so far.
When I turn on "Test with Live Data" and go into formula screen, I am correctly seeing RC properly decode both single frame (<=8 byte payloads) and multi-frame payloads properly. However, whenver I use a mode 0x22 request, no RaceChrono formula will actually recover the "raw" data to operate on despite showing me the real actual data coming in just fine.
Here is an example for a two-byte DID 0x22 10 40 returning a single frame with a one byte payload.
https://www.dropbox.com/scl/fi/fm34t415svaj21bn17krl/IMG_6782.PNG?rlkey=ddp9d8wre73zg34998ozvlmzz&st=iu6u0f8s&dl=0
And here is an example for a DID 0x22 40 10 returning a multi-frame ISO-TP reply which amazingly RC properly interprets and passes up the entire blob.
https://www.dropbox.com/scl/fi/bkcgr8gpp8klyguba65yu/IMG_6783.PNG?rlkey=dlscx8djkqy5oy48az7a2fp9c&st=vtyz7189&dl=0
Both scenarios are correctly returning live data that is changing in realtime as expected.
In both screen shots you will see I have a formula defined but the value is "0" even though clearly the formula result should be nonzero. I conclude that "raw" is not working for mode 0x22 queries.
When I switch back to any mode 0x01 query the formulas work just fine.
I have attempted both "bytestoUint" and "bitstoUint" derivatives. I have attempted to move the start point sequentially in 2 byte/16 bit increments from a start position of 0 out to position byte 32 but always returns 0x0000.
So RC is properly decoding but not passing the result into the "raw" buffer for the formula.
What's crazy is that RC is doing all the heavy lifting of letting me do bespoke UDS queries and handling reassembly of AMPDUs. Perhaps that's the driver you're using. Nonetheless, the reason we need to fix this ASAP is that I have successfully identified transmission gear and brake pressure over OBD instead of CAN. Which would obviate the need for users who are unable or uncomfortable doing CAN taps to obtain these two channels which are not normally available on many makes/models via OBD - as discussed ad nauseum here and on various car-specific fora.
