aldl message length byte

[steveo]

through a bit of raw searching, i'm guessing that the 'message length' field (the second byte of practically any aldl communication that tells the ecm how long the message will be) is calculated as the total length of a packet plus 82 (decimal)

i'm wondering two things;

1. am i correct
2. are there any cases that '82' isnt the magic number?
3. are there any cases where an ALDL message could be longer than 173 bytes, in which case, what happens?

[steveo]

... that was three things. you can tell how horrible at math i am.

[RobertISaar]

1. looks like it.
2. no, or at least, none that i've ever seen.
3. that kind of packet length isn't in any way practical(which is probably why it was never even considered). update rates would be about 1/3 of what they are with a typical 64ish byte response(plus header and checksum), so now instead of near 10.5Hz, now it's around 4Hz. if something like this were to be attempted..... i would hope that the code would account for the Carry bit being set during the subtract function and function as normal. however, i wouldn't count on it. this is why GM started implimenting multiple messages per mode, rather than one monsterous stream.

if you were dumping huge amounts of data that didn't need to be updates quickly, like throwing the entire calibration out through the ALDL connector, then it could make sense. but there are already mode 2 or 3(i can never remember which) commands that will dump 64 bytes of data per request already setup. you basically give the ECM the header and the start address of where you want the dump to start and a checksum and then you have 64+header+checksum sent back. you could effectively read the BIN out of anything without ever pulling the MEMCAL.

[steveo]

thanks for confirming my assumptions.

i looked at a bunch more 8192 baud aldl stuff today and couldn't find any different length bytes.

byte 2 of any aldl data = length of message + 0x52