Hi! Right! – in the 1.8.92 update you’re going to get a new set of variables that you can use in the equation parser…

Torque traditionally takes some of the hard work away when dealing with responses (which is why you don’t immediately need to start of with variable D in a lot of cases). The variables starts from A, B, C, for mode 21, 22, 01, etc where the data headers and response status have already been removed for you. (these are also mirrored by variables N0, N1, N2 (etc) for simplicity)

However, with some awkward manufacturers, they may reply with no header at all (with useful information at the start of the packet that you’ll want to get at).

To get the variables for the *whole* raw data reply, you can now use the following variables:

R0, R1, R2, R3 (etc) where in most cases R3/4 would equate to ‘A’ in normal mode21/22/01 messages (depending if you’re using canbus or an iso protocol like 9141)

So, R0 (‘Raw 0’) will get you the absolute start of the message, which should give you access to the bytes you want

So the equation would now look like:

R0 * 5

For the first value in the reply

Very useful.
Thank you!

Cintakc,
do you have any other useful AA PIDs (I saw you mentioned a scanner)?

I discovered other 3 PIDs in mode AA, just looking at the results (and only beeing able to see from the 5th byte on)… it would be nice to have more!

Thanks a lot.
I’m trying to understand how to use it…

Give your answer in the terminal supports requests, I will look

Thanks Ian.
Unluckily if I use ath1 R0 variable starts reading from the very beginning… that is 5e8 in my case.
So reaching the useful data I’m shifted 1 nibble.

If I don’t use ath1 it is not shifted but R0 starts from the second useful byte.

I imagine I could do some bit reading, but I’d avoid it if possible.

Im thinking the 8 is part of the dpid (18)?
and 26 should be first data byte?
32 would be second?

Length doesn’t make sense in this case
with the small number of bytes in the
message… I would think non standard
response.

My comments are based upon my observation
of the bytes of the previously posted responses
to yours. While the values are slightly different
the pattern is similar.

Yep and the test case was with can formatting enabled, and this is obviously chopping a nibble off (you miss the starting’1′ in the formatted version)

I’ll get on and sort this out, though you should still be able to access the valid bytes from R0 in the message in this state as it is the sensor data after the 0:

ie: the

826
0:xxxxxx

is missing the 1 (due to the formatting method) – iirc the 1 was used to signify multiline responses as far as the ELM327 is concerned

7e0 AA0118
7e8 1826xxxxxxxx

The other formatted message obviously isn’t correct so I will setup a test case for that and sort out the off-by-one issue

Might be defective – there’s some very odd adapters out there,… I’ve still gotta make it work reliably though

Yes,
In my case 26 is the first useful byte.
That’s exactly 1 byte before R0.

Tomorrow I might collect some log file.

Thanks