21 Aug 2013 Pizza   » (Master)

ALDL hackery, oh my!

One of the upsides to my truck's recent woes is that I ended up with a cable capable of interfacing to its onboard computer. Unlike the "modern" mostly-standardized OBD2 spec (that all 1996+ vehicles were mandated to support) this thing utilizes a GM-specific interface called Assembly Line Diagnostic Link, or ALDL.

General Motors used ALDL between 1982 and 1995, through two major revisions -- 160 baud unidirectional, and 8192 baud bidirectional.

Unfortunately, the physical interface is where the standardization ended -- The logical datastream could be specific to a particular computer, year, model, and drivetrain combination. Oh, there were sometimes additional streams (on physically different pins) for the antilock brake and transmission computers.

All in all, it is quite a mess to deal with, and one that not even General Motors cares about any more. The old Tech1 testers they used to use (and the even rarer data cards) command a pretty steep premium on eBay these days. Cue the aftermarket!

The CD that came with the data cable included various windows-based tools and a pretty comprehensive list of datastream definitions. Initially I used WinALDL to decode the ALDL stream out of my truck. It is fairly old and no longer maintained, which was a problem given that it didn't support the exact datastream my truck spat out. More advanced tools exist (such ass TunerPro), but they target an entirely different audience -- folks trying to reprogram the PROMs in the PCM.

But that's enough background information. Not wanting to have to fire up a Windows instance to talk to my vehicle, I got to thinking that someone out there had to have written an open-source ALDL tool, I did a little poking around and came across LinuxALDL. Unfortunately it turned out to be woefully incomplete -- Its author got things to the point where they WorkedForHim(tm) on his re-engined '88 Fiero, then pretty much abandoned things as they stood.

LinuxALDL was written for the newer 8192 baud bi-directional interface, and while some effort was made to support multiple stream definitions, it wasn't quite completed. It also lacked support for all data types that the ALDL interface exposed.

So, I picked up the code and started hacking away. I've already completed a pile of code cleanups (with more to come), partially implemented support for the low-speed 160-baud interface, and am currently improving the data stream support so I can get niceties like decoded coolant temperature and open-/closed-loop operation flags.

These two things are my main motivation for this work, since the dashboard's temperature gauge isn't linear and I need to know what the actual temperature is, and if the computer is transitioning to closed-loop operation. Even though the PROM I have in there now is tuned for lower temperatures, the truck may actually be running too cool with the electric fans I put in after the radiator blew out last summer. We shall see.

I hope to have things in shape to plug it into the truck tomorrow and see if anything useful comes out. Given that my truck uses the old 160-baud interface, I'll never be able to do anything other than watch/log the data coming out, so once I have both the GUI and command-line datalogging working, I'll probably walk away once I fully expose/decode the my truck's datastream.

Oh yeah, the code. If anyone is intereted, here's my work-in-progress fork of LinuxALDL:


Syndicated 2013-08-21 04:08:59 from Solomon Peachy

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!