Retrieving ECM data with PC

[Dale Ulan]

> oversampling.  The TTL voltage should drive an RS232 port with a very short 
> cable, if not a MAX level shifter could be used. I have no information on how 
> the data is partitioned, not even if it lies on byte boundaries or not.  I 
> would assume it does.

Yes, you need a level shifter. Also, the data line is bidirectional, so you need
an open-collector driver on the line. Note that the ALDL data is like the data
right out of the UART, so it must be inverted as well. Basically, you need
to run it through a MAX232. The 'transmit' (TTL out of the MAX232) should
go through a diode to simulate an open-collector line. Normally, the ECM stays
quiet until you ask it to talk.

The data is actually sent in response to a poll request, and is just various
bytes and words of the ECM's RAM. This implies that byte-derived data is
aligned normally. Some things, like all of the I/O ports and flag bits are
sent as a byte as well. ie. one byte may have the following flags in it:
  CLOOP  RICH  CLONCE  UNFLOOD  PUSHSTART  LOWVOLTAGE  LEARN-EN  ASYNC-PLS

This is just an example. I don't know if I got the bit order right... and
that 'PUSHSTART' is just a guess as well... :-)

 
> You have to know what type of engine computer you are dealing with.  The 
> computers in the buick GN-ttype cars uses a much lower baud rate, about 110 or 
> so, and it is self clocked in some manner.  Apparently the computer does not 
>send data continuously, but sends a bit whenever it finds the time.  I believe 

It is sent at 160 baud, and is sent almost immediately after the pace/heartbeat
interrupt is received by the processor. There are about 160 lines of code
between the interrupt and the actual data, so the baud rate appears to
drift. This is pretty much only bit skew, as far as I can tell. This 160 lines
of code can vary in execution time quite a bit, but that 160 Hz heartbeat
appears to occur in a very regular fashion.

> Here is what I know/have guessed from the corvette service manual.  ALDL data 
> is present all the time.  The engine computer can be in one of three modes, 
> ALDL, 10K, and backup.  ALDL mode is normal mode, ie you can collect data 
> while you are driving, etc.  10K maintains engine rpm at 1000, and disables 
> some features, like O2 feedback, etc.  Backup mode cuts the ECM out all 
> together, and simulates the fallback mode that takes over should the ECM 
> totally bug out.  I am not sure how to set these modes, but I believe 
> different resistances from the test pin to ground will do it.

There are several modes:
0K mode:  engine off: blink codes
	  engine on: blink CHECK ENGINE with RICH/LEAN flag

3.9K mode: fuel backup mode
10K mode: as described above
Open mode: normal operation.

This goes between 'A' and 'B' on the ALDL connector.

In addition, the bidirectional data bus on the 8192 ECMs can place the ECM
in many strange test modes. I haven't traced any of them out yet...

ALDL data on the 8192 ECMs doesn't get spewed out all of the time... as
far as I can tell, anyways. The ECM spits out its data stream only when
the device at the other end of the wire interrogates it. This can occur
any time the CPU is running normal code. I don't think the CPU stops even
when you are in fuel backup mode, but don't quote me on that. As far as I
could tell, it only stops the fuel watchdog.

> wants to talk about it.  I have tried calling GM about it, but haven't ever 
> managed to get ahold of someone who knows what I am talking about, much less 
> knows if the info can be released or not.

Yea, I know the feeling.

-Dale