2018-04-25

Understanding GM's 160 Baud ALDL

I've spent a good deal of time investigating the ALDL/OBD1 data stream emitted by the ECM in our early C4's and have focused on the 160bps data stream. Before anyone scoffs, and asks why not use the faster more data rich 8192bps data stream? Well, there's a goodly amount of useful information in the 160bps data stream and so I'm starting there. Once I'm satisfied that I've got the 160bps stream handled I'll move on to the 8192bps stream. In fact I'd like to explore the data stream that no one talks about, namely the smaller data stream that feeds data continually to the digital dash for things like the MPG readout etc.

So after reading about all the really hacky things people have done to fit the square peg of ALDL data into the round hole of RS232 UARTs I decided to take a different tack. I decided to employ an Arduino to sample the ALDL data and convert it to a stream of easily read and easily parsed ASCII 1's and 0's.

I purchased an ALDL breakout cable from aldlcable.com

View | Download ALDL Cable Pinout (1.2 KB .txt file)

Then I cobbled together a perf board to tap into the various ALDL connections and added a 10k resistor with an enable/disable jumper. From there the ALDL data line and ground were attached to the arduino. And finally, the Arduino is plugged into the Raspberry Pi which reads the incoming data and also powers the Arduino.

Here's an O-Scope image of the 160bps ALDL data stream coming from the ECM:

As you can see, there's a bunch of activity in between two quiet periods. All those blips at the bottom of the trace are the data bits. The amount of time the voltage stays at zero volts determines whether the bit is a 0 or a 1.

After several hours of contemplating and coding, my Arduino finally read the ALDL stream. Success! Or so I thought. When I started the engine the data became garbled. Another look at the ALDL stream with the engine running revealed that there were some small, random voltage spikes present. The scope image below shows the tiny spikes:

Since the ALDL line wasn't as clean as I had hoped, it was time to rewrite my code to allow it to ignore minor glitches on the data line. A few hours later I had a working program.

This has worked out really well. I now have an Arduino doing what it does best (which is handling real-world time-critical events). Then it transmits the data to the Raspberry Pi to do what it does best (which is processing raw data and presenting it graphically).

This video shows the ALDL data stream from the ECM being displayed on the Raspberry Pi touch-screen. If you enlarge the video, you can see that when I press the over-drive button on my shifter, one of the bits changes from a 0 to a 1. Pretty cool stuff.

The background music (Neil Young's "Computer Age") from the early 80's seems particularly fitting given the car and the project.

The image below shows the exact bit that flips when the over-drive button is pressed or released:

Now I have to take all those 1's and 0's (which represent things like the TPS voltage, BLM counts, MAF air flow rate, IAC position etc.) and translate them into a digital/analog/barchart/graph that can be displayed on the touch-screen.

If you're into binary, you can also see the PROMID's in the top row, 3rd and 4th bytes (fyi: the ECM always sends a start bit (0) followed by 8 data bits so the leading zero is not part of the data). These values indicate the version of the Programmable Read Only Memory chip installed in the car:

   PROMIDA   PROMIDB
  000011110 010101011
   |      |  |      |
   +-1Eh--+  +-ABh--+
   |                |
   +-----7851d------+
        

My car has a PROMID of 1EAB Hex or 7851 Decimal.

Get the Comvette 160 Baud ALDL Reader Sketch