I've been relatively miffed lately that every decent-looking scantool on ebay keeps jumping from $50 to $180 in a matter of minutes, so I've been researching some into PC-based scantools. A fairly simple two-transistor circuit, three resistors, and some wire later, I have what seems like a pretty decent interface between my Bonneville'* ECM and my PC.

Unfortunately, this probably won't help anyone but the owners of the weird '94-'95 OBD-I hybrids with the 8192 bps ALDL datastream, but maybe some of this information can be extrapolated to earlier models too; OBD-II owners will have to do their own research

The interface I built is here:

http://www.home.aone.net.au/techedge/vehicle/2tran.gif

The interface cable basically consists of two RJ45 (modular telephone plug) pigtails, two inline couplers, 50 ft of CAT3 telephone cable, two ECG289A transistors (any generic transistors will do -- 2N2222, 2N3904, etc), three 10kohm resistors, and a DB9 (serial) plug housing (all off-the-shelf from Radio Shack). My interface circuit is sitting in a breadboard at the moment -- I guess I'll get around to soldering it all together and putting it in a pretty box eventually.

The pinout for the '94-'95 OBD-II style connector can be seen here:

http://www.home.aone.net.au/techedge...e/con16pin.gif

Those three pins (5, 9, and 16) are then connected to the corresponding terminals in the circuits shown in the first link, and three connections are made in that circuit from the DB9 (PC) side. Wire everything up correctly, and the PC and the ECM will talk to each other.

I'm currently trying to get CarBytes to work, since it'* free -- I've had some luck translating the ECM datastream into useful information from a couple of resources I've found during my research, but I'm still working the bugs out of it and getting all of the interesting data correctly displayed. I'll keep everyone posted on how that'* going, and I'll happily provide my definition file (without warranty, of course!) to anyone that'* interested.

CarBytes can be found here:

http://www.efilive.com/downloads/index.html

Also on that same site is a little program called Probe -- it'* a DOS-based program that'* pretty useful when all you want to do is make sure the car is talking, and don't particularly care what it'* saying. EFILive might be pretty good, but a) it costs money, and b) the evaluation version won't even start up without giving me 30 DLL error windows.

I'll try any post some pictures of my cable, the circuit, and some of the preliminary results of this testing as soon as my girlfriend brings her digicam back from Indiana.

-b

Here are a couple of screenshots of data I've captured while my car was idling hot outside. Most of the numerical values work out okay, but some of the status flags I'm not so sure of -- the reference I was using didn't have great labels for a lot of the flags, so for about half of them I'm not really sure what status they represent

Assorted numerical readings:



Assorted flags:



More assorted flags:



The following graph is the oxygen sensor readings, short term fuel trim, and long term fuel trim. The spikes to zero result from communications errors -- the ECM was trying to talk at the same time my PC requested the next set of data. Tweaking the request timing will get rid of those, hopefully.



From this graph, it looks like my oxygen sensor is getting kinda lazy -- I'll probably replace it shortly after I get my upper intake manifold replaced.

Is anyone actually interested in any of this? If so, please post something so I know I'm not just talking to myself

-b

Will it work on OBD I vehicles? All i've seen is PRICEY stuff....

No, actually you're not talking to yourself here actually this stuff is pretty interesting.

I've been doing some experiments myself on my own car, but with not much luck. I tried a different circuit, composed of some sort of a comm. chip (forgot the exact name), and a few capacitors and resistors.

I was using EFLive. It kinda worked, I was seeing some datastreasm received from the ECM, but I don't think that the computer was able to send anything (requests for data, etc.) in the other direction. The software was not able to distinguish one packet from the other btw.

I was getting the impression that many different kinds of data packets were sent over the comm. bus, and I couldn't relate that fact to the documentation I was able to find online.

I gave up the project actually, I spent many hours on this without real results and I got too frustrated. Perhaps I'll give it another try with the software and circuit you're suggesting. My car is a '92 btw, I believe things were still relatively simple that year.

Forgive me if I repeat anything you already know Some of the straight OBD-I vehicles (pre-'94) use the same 8192 baud serial ALDL (Assembly Line Data Link) datastream as my hybrid, so the same circuit I described above would work. (This probably applies to model years 1989 to 1993 or so.) The datastream may differ though, so I don't know if my definitions file would work perfectly. These cars generally have the 12-pin ALDL connector shown here:


(Images courtesy of http://www.techedge.com.au/vehicle/aldl8192/8192hw.htm)

Earlier models (say, pre-'89) used a 160 baud serial ALDL (Assembly Line Data Link) datastream, and the mode of the ECM output is controlled by a resistor between two of the pins of the ALDL connector. (These are the same two pins you'd shove a paperclip into to get the malfunction code flash on the MIL lamp.) I think these models use a 6-pin ALDL connector, like the one shown here:



(This particular diagram is for an Australian GM-equivalent model, so the pinouts may differ in the US. Mine turned out to be basically the same as the Aussie model, but I can't guarantee they all are )

To interface with one of these earlier model 160-baud ALDL links, you'd need a different circuit from the one I described above, like this:



Again, the pinouts may vary, so you might want to doublecheck with a service manual, a dealership, or (like me) a multimeter and an oscilloscope.

There'* a plethora of software written for 160-baud ALDL streams that could probably be adapted to early model Bonnevilles -- I'm not entirely sure, though, as that hasn't been a focus of my research WinALDL seems to be one of the most popular 160-baud readers, and info on it can be found here:

http://w1.601.telia.com/~u60113744/*...dl/winaldl.htm

The Bonneville isn't one of the "supported vehicles," so it might or might not be feasible.

A *really* simple program for the 160-baud ALDL streams can be found here:

http://www.techedge.com.au/vehicle/aldl160/aldl_sw.htm

This one displays the *raw* ALDL data, so you can (after finding appropriate references) configure the program such that it displays each quantity correctly.

In short, if you have a 12- or 16-pin connector, everything I'm doing will probably work for you too with only slight modifications; if you have a 6-pin connector, it might be a little more difficult.

-b

Yeah, probably one of the Maxim MAX232 family. I considered doing that until I happened upon the two transistor circuit, and since I didn't really want to wait a week or two for a MAX232 to get here, I thought I'd try the simple one and see what happened. I'm pretty impressed, actually.

I had similar troubles with CarBytes until I tweaked the timing settings of the program -- there'* a fine line between not waiting long enough after chatter ends and waiting too long after chatter ends before sending any data. The default wait setting was 100ms, and outgoing packets from the PC to the ECM would collide with ALDL chatter almost every time. I cut the wait time to about 50ms, and I'd get about 20 collisions per 1000 requests. At 40ms, I haven't had a collision yet.

Yeah, all kinds of electronic systems apparently chatter on the ALDL bus (it'* apparently a feature -- they broadcast a "heartbeat" to show that they're still alive). To get them all to shut up for a second so you can talk, you might have to send a "halt chatter" command to the ECM, and they all hush up for a few seconds so you can send a diagnostic command. Each packet starts with an identifier byte to, er, identify which module the packet'* coming from. Apparently most GMs with the 8192-baud datastream have an ECM ID of 0xF4, and that'* generally the only one I pay attention to.

It took me an hour or so to rig up the cable and the circuit, and I've spent most of time I've been home over the weekend trying to tweak the software settings. If you do try any of this, let me know, and I'll send you a copy of my CarBytes ALDL definition file.

-b

I have a quick question here. My laptop (which would be great in the car) does not have com ports (or LPT input either) just USB and firewire. Is is possible to to adapt a com port to a USB port?

I think Belkin makes a serial-to-USB dongle-style connector; will probably run you about $20US or so on eBay. I'm not sure if it'* transparent, though -- the program I'm using needs to think it'* using an actual serial port, so you'd have to check to see if the serial-to-USB dongle emulates a serial port in Windows or if it just replaces it with Something Else.

I would have used my laptop too, but it exploded about three months ago. So the next logical step in my experimentation is to rig up my PDA (an HP Jornada 54 as a serial datalogger, so I can capture data on the road, then bring it home and analyze it. Will keep everyone posted on that too -- but it'll be a while, as I'm waiting on delivery of a serial cable for my PDA. (Plus I'm gonna have to remember how to write code. Ugh.)

-b

Thanks I found one online for 18.99 CAD and it comes with a driver disk as well. I think I may give this a shot.

So I struck a veritable gold mine of ALDL information a few minutes ago: a 1.1MB zip file of about 260+ ALDL datastream specs, for varying engines and model years. Anyone interested can find it here:

http://www.missouri.edu/~bcc5zb/bonn...LDLstreams.zip

There'* an MS Word index (!!_INDEX.DOC) ordered by engine (in my case, L36), VIN (ie, K), model year (ie, 1995), and body styles (ie, 3,4C, 2,3H, 4G). So my car uses datastream A280. So I open up A280.DS in my favorite text viewer, and I can see byte for byte all the different command types (parametric running data, stored codes, ROM dumps, code resets, etc), and then a bit-by-bit breakdown of the responses that the ECM will send in response. It'* really pretty simple (if tedious) to go from a list like this to a CarBytes definition file, and I've already done it once -- I'll be happy to answer any questions regarding any such conversions.

-b