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:
http://git.shaftnet.org/cgit/users/pizza/public/linuxaldl.git/
Syndicated 2013-08-21 04:08:59 from Solomon Peachy