Extra byte in Message6?

[festy]

I'm testing some ALDL logger code against a vanilla 12P BLCD bin, with nothing connected to the ECU except the power wires.
Logging message 0 seems fine, I get the expected 60 bytes back at about 11Hz, and the checksum is good.
But message 6 is returning 12 bytes - not the 11 that I'm expecting.

Code: Select all

setting timeout for Mode1Message6 to 200ms
[0 0 12] checksum passed for f45e0100000000018a4900d9
0: Engine RPM 0 0 0
2: Spark Advance 0 0 * .351565 0
4: MAP 1 (1 * 0.369) + 10.354 10.723
5: Target AFR 138 138 * .1 13.8
6: Wideband 73 73 / 10 7.3
7: Knock Counts 0 0 0
****** 0.029996 (33.3377783704494 Hz)

The 5e indicates that it's a 12 byte packet (5e - 52), but the message6 adx only expects 11 bytes.
Have I somehow got a bin with a non-standard message6, or is does the adx in the 12P zip not match the BLCD bin?
I'll read the bin off the memcal next time I'm near the ECU, but it's driving me crazy trying to remotely solve this today

[Holden202T]

use the flashtool against the bin to see whats defined for Message6 in it.

theres an option in the menu for aldl message editor

[festy]

yep will do that - but I'm not near the ECU, and don't have a PC connected to it at the moment to run flashtool from.

[VL400]

I think it will be the ADX that is wrong, it will be 12 bytes total in a standard cal - 8 bytes of data, 3 header bytes and the checksum.

[festy]

I've checked the ADX in the OSE 12P zip and it has 11 bytes for message 6. Message 0 has 60 in the adx, and there's 60 bytes including the checksum in those packets...
Is the second byte of a message 6 packet usually 5e or 5d?
I'll check the bin I'm using before looking any further.

[VL400]

To keep the ADX inline with M0 it should be 12 and 9 not 11 and 8. But could also have 12 and 8 too, offset is always 3 though.

Your bin will be correct, it is 8 data bytes.

[festy]

So you're saying the adx is wrong, and the bodylength should be 12 and not 11?

[VL400]

Correct

[festy]

ok - so I assume that tp5 must use the ALDL stream's byte 2 to determine the incoming message length, rather than using the value pulled from the adx?
I might have to re-work mine to do the same if that's the case.

[VL400]

Not sure why TP did not complain as it does not use byte 2 AFAIK.

In my logger I use byte 2 for frame length, it works better seeing as that is what is on the bus.