From ubc-cs!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!fauern!faui43.informatik.uni-erlangen.de!orscholz Mon Jan 6 11:05:45 PST 1992 Article: 30417 of rec.autos.tech Newsgroups: rec.autos.tech Path: ubc-cs!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!fauern!faui43.informatik.uni-erlangen.de!orscholz From: orscholz@immd4.informatik.uni-erlangen.de (Oliver Scholz) Subject: Re: GM's ALDL info Message-ID: <1992Jan5.084232.22926@informatik.uni-erlangen.de> Organization: CSD., University of Erlangen, Germany References: <1992Jan3.192410.12029@informatik.uni-erlangen.de> <1992Jan4.190655.26721@bnlux1.bnl.gov> Date: Sun, 5 Jan 1992 08:42:32 GMT Lines: 33 Ven Polychronakos writes: >Could you post a summary of the replies you got? >Thanks, Ven Considering the interest in the information, it think a summary is justified. Here's what I know: The ALDL uses a TTL level output (1=H=5V, 0=L=0V) with 8192 Baud. A word consists of 10 Bits, the startbit (L), 8 data bits (LSB first) and one stop bit (H). The line is idle high. The ECM sends packets that look like this: 1 byte device code 1 byte: 85+N (N being the length of the data part of the packet) N data bytes 1 byte checksum between two packets the line goes idle (H) for at least 10 bit times. Information still missing includes: A list of device codes, the interpretation of the data bytes and how to compute the checksum (which I probably could find out myself... I guess it's just adding up the data part of the package. So, once again, if anyone has any further information, please let me know (or better yet, post to the net. I know a *bunch* of people is interested in this!) -Oliver ---------------------------------------------------------------------------- This is a little misleading, from what I've seen on the 8192 format. It may be correct for the ALDL data output in 10k mode. It should read: 1 Byte message ID 1 Byte Length (85 + 1 + N - The next byte counts too!) 1 Byte Mode Specifier ( Usually ranges from 0 to 7) Data bytes 1 Byte checksum (two's complement of sum of the previous bytes) > >Information still missing includes: A list of device codes, This is defined in the Cal section of the PROM, and can be anything from 0-255. The ones I've seen seem to like to use 0xF0, and it normally will be the same as the value of the heartbeat sent out in normal mode. Dig sdbartho@hwking.cca.rockwell.com ---------------------------------------------------------------------------- Thanks for posting this information. I had figured out (the hard way) the basic protocol but had (and still do) trouble interpreting what I was reading. At least now I can stop trying to decipher the checksums and device codes. So here is my minor, I'm afraid, contribution towards solving the puzzle. Below is a record of what the serial link on my '88 Celebrity (2.8L, v6,VIN W engine) tells me. Car at "PARK", engine idling. All digits hexadecimal. 0A 58 00 03 53 48 0A 58 00 03 61 3A 0A 58 00 03 6A 31 05 5F 00 00 00 3C 8C 39 62 01 EC 72 DA 0A 58 00 03 69 32 F0 55 BB The first line, for example, shows device code 0A (10 Decimal), 3bytes of data (58 hex=88 decimal, therefore 88-85=3), then the three bytes of data follow and ,finally, the checksum byte 48. By the way these three bytes are zero when ignition is ON but engine not running.This device code seems to be repeated 3 more times in the same record!? The device code 05 gives 10 bytes of data from which the only one I was able to figure out is the fifth one (8C= 140) which looks like the battery voltage, 14.0 V, when interpreted as tens of millivolts. When engine is not running it becomes about 12.0 V.Finally the device code F0 has zero data(55) and seems to be some sort of end-of-record marker (BB by the way is the checksum of F0 and 55). The checksum byte is the two's complement of the 8-bit sum of all bytes in a given packet (except the checksum itself) not only the data part. In plain english if you sum all bytes now including the checksum the eight least significant bits of this sum should be all zero. If anyone has more information on the contents of these packets, I would appreciate hearing it. Thanks in advance, Ven. --------------------------------------------------------------------------------- From ubc-cs!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!fauern!faui43.informatik.uni-erlangen.de!orscholz Mon Jan 6 11:05:45 PST 1992 Article: 30417 of rec.autos.tech Newsgroups: rec.autos.tech Path: ubc-cs!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!fauern!faui43.informatik.uni-erlangen.de!orscholz From: orscholz@immd4.informatik.uni-erlangen.de (Oliver Scholz) Subject: Re: GM's ALDL info Message-ID: <1992Jan5.084232.22926@informatik.uni-erlangen.de> Organization: CSD., University of Erlangen, Germany References: <1992Jan3.192410.12029@informatik.uni-erlangen.de> <1992Jan4.190655.26721@bnlux1.bnl.gov> Date: Sun, 5 Jan 1992 08:42:32 GMT Lines: 33 Ven Polychronakos writes: >Could you post a summary of the replies you got? >Thanks, Ven Considering the interest in the information, it think a summary is justified. Here's what I know: The ALDL uses a TTL level output (1=H=5V, 0=L=0V) with 8192 Baud. A word consists of 10 Bits, the startbit (L), 8 data bits (LSB first) and one stop bit (H). The line is idle high. The ECM sends packets that look like this: 1 byte device code 1 byte: 85+N (N being the length of the data part of the packet) N data bytes 1 byte checksum between two packets the line goes idle (H) for at least 10 bit times. Information still missing includes: A list of device codes, the interpretation of the data bytes and how to compute the checksum (which I probably could find out myself... I guess it's just adding up the data part of the package. So, once again, if anyone has any further information, please let me know (or better yet, post to the net. I know a *bunch* of people is interested in this!) -Oliver ---------------------------------------------------------------------------------- From ubc-cs!uw-beaver!zephyr.ens.tek.com!uunet!sun-barr!olivea!mintaka.lcs.mit.edu!hal.gnu.ai.mit.edu!lusky Mon Jan 6 11:07:17 PST 1992 Article: 30434 of rec.autos.tech Path: ubc-cs!uw-beaver!zephyr.ens.tek.com!uunet!sun-barr!olivea!mintaka.lcs.mit.edu!hal.gnu.ai.mit.edu!lusky From: lusky@hal.gnu.ai.mit.edu (Jonathan R. Lusky) Newsgroups: rec.autos.tech Subject: Re: GM's ALDL info Message-ID: <1992Jan6.073457.28814@mintaka.lcs.mit.edu> Date: 6 Jan 92 07:34:57 GMT References: <1992Jan4.190655.26721@bnlux1.bnl.gov> <1992Jan5.084232.22926@informatik.uni-erlangen.de> <1992Jan5.200542.2617@bnlux1.bnl.gov> Sender: news@mintaka.lcs.mit.edu Organization: ^ Lines: 22 Other values that the ECM sends back include manifold air temp and pressure, spark advance, rpm, throttle position, as well as several fuel injection related numbers (block learn multiplier is the only one that comes tomind at the moment). You might try finding someone with some type of scan tool so you know what values you are looking for. RPM, TPS, and MAP you should be able to pick out pretty easy. RPM will vary with rpm, TPS will vary with throttle position (even when engine isnot running), MAP will vary with vacuum (even when engine is not running... get an "assistant" to suck on a vacuum line connected to the MAPsensor while you sample packets). Jon Lusky lusky@gnu.ai.mit.edu > ------------------------------------------------------------------------------------- From ubc-cs!alberta!aunro!lll-winken!elroy.jpl.nasa.gov!usc!wupost!spool.mu.edu!umn.edu!math.fu-berlin.de!fauern!faui43.informatik.uni-erlangen.de!orscholz Mon Jan 6 11:07:49 PST 1992 Article: 30436 of rec.autos.tech Path: ubc-cs!alberta!aunro!lll-winken!elroy.jpl.nasa.gov!usc!wupost!spool.mu.edu!umn.edu!math.fu-berlin.de!fauern!faui43.informatik.uni-erlangen.de!orscholz From: orscholz@immd4.informatik.uni-erlangen.de (Oliver Scholz) Newsgroups: rec.autos.tech Subject: Re: GM's ALDL info Message-ID: <1992Jan6.081558.9803@informatik.uni-erlangen.de> Date: 6 Jan 92 08:15:58 GMT References: <1992Jan3.192410.12029@informatik.uni-erlangen.de> <1992Jan4.190655.26721@bnlux1.bnl.gov> <1992Jan5.084232.22926@informatik.uni-erlangen.de> <1992Jan5.200542.2617@bnlux1.bnl.gov> Organization: CSD., University of Erlangen, Germany Lines: 39 polychron@bnldag.ags.bnl.gov (Ven Polychronakos) writes: >0A 58 00 03 53 48 >0A 58 00 03 61 3A >0A 58 00 03 6A 31 >05 5F 00 00 00 3C 8C 39 62 01 EC 72 DA >0A 58 00 03 69 32 >F0 55 BB My guess would be that device code 0A is the engine RPM: in your example: 851, 865, 874 and 873. Could you verify that? >of data follow and ,finally, the checksum byte 48. By the way these >three bytes are zero when ignition is ON but engine not running.This Because the rpm is 0 ? >device code seems to be repeated 3 more times in the same record!? Because it's changing constantly ? >The device code 05 gives 10 bytes of data from which the only one >I was able to figure out is the fifth one (8C= 140) which looks like >the battery voltage, 14.0 V, when interpreted as tens of millivolts. Makes sense. That would be the sensory readings of A/D converters of some kind. The leading zeroes could be non-installed sensors, unused or reserved... Thanks for posting that information, I think it helped a lot! You might try disconnecting different sensors (Start with the TPS) and see which byte becomes zero (Or $FF). Try to force a trouble code (by disconnecting that sensor). Maybe the last packet is not the "End of Record" (which would be useless) but the stored trouble codes? (in your case: none) ?? Just a (more or less good) guess... -Oliver