has anyone used this? it is free diagnostic tuning software I think it will work on my car, havn't tried yet, would be handy it seems, possibly some tuning, especially if having problems. Anyway screen shots and some info are at: http://www.customefis.com/winaldl.html

Here'* a pic of the custom 9 pin serial to aldl cable they call it that would need to be built, i'd like to do this..jusy hoping someone may have tried before

This has been around for a while. It was designed for the really old ECM'* used in the Fiero, 3rd Gen F-body, and others from the 1980'*.

If it works, then I guess it is usefull. However, a lot of modern laptops and PC no longer use a serial port that can be driven at the baud rate of the ALDL data port.

There'* a revised circuit using a MAX232 chip and a buffer in the converter cable. It can store and forward the ALDL data at a baud rate the PC can handle, making the data capture a bit more reliable.

Last issue is figuring the data bytes in the ALDL stream. It varies from one ECM type to another. The winALDL software (what a hoot, it was written for Windows 3.1 years ago..I guess he recompiled it for 98/2000 finally) may be able to interpret it for you if he has the type in the table. Otherwise you have to do a raw data capture and pick the bytes in the data apart by hand.

Follow up...

I checket the support site for winALDL and did not find a Type 253 ECM listed in the table of supported ECM'*

The software might still work, but it may be only partially functional.

If this sounds a little crazy, then a history lesson in GM car computers is in order.

General Motors refers to the connector under the dash as the ALDL connector. The anacronym stands for Assembly Line Data Link. It was never intended to be used as a diagnostic tool interface in the field. At the time it was created (Early 1980'*), home computers were a new concept and most car service techs, including dealerships, didn't have them or access to them. GM never released documentation on the actual data stream comming out of the ECM, as it was never intended to be used outside the factory doors. The only thing published was the flashing codes on the SES lamp.

It was only later that companies like OTC came up with a scanner that could read the data. I don't know if they bought the information from GM, or simply reverse engineered it by looking at the data from a live ECM. All of the home brew code readers that followed are the product of reverse engineering the data from looking at live ECM'* in use. (The Pontiac Fiero community were the pioneers of this, followed by the F-bodies and Y-body groups...my little contribution years ago was for the 87 MPFI V6 in the Camaro/Firebird)

The data comming out of the ALDL port is serial in nature, but it doesn't follow the RS232 standard. It is more like Teletype data. Originally it was very load speed..approx 148 baud, but has gotten faster over the years. It isn't a standard..there isn't a clock generator inside the ECM just for driving the ALDL port at a specific baud rate..GM is using simply using the ECM'* clock to drive the serial data, hence the strange non-standard baud rates. It is half-duplex..there'* no handshakes between the listening device and the ECM, it'* a one-way continous dump of data. The actual data bits are also different from RS232..the ALDL uses 0 VDC as the "0", where RS232 uses -12VDC as a "0". Hence the need for a conversion circuit if you want to use the serial port of an IBM PC to read the data. Because of the weird baud rates and framing, it'* a crap-shoot at best to get them to read it. The serial port chip in your PC will either read it, or it will not.

Last, comes the data itself. When you get your PC to see the data bits and store them in a file, you start looking at the file for a repeating pattern with a hex editor. IIRC every block of data comming from the ECM starts with a pair of bytes that are allways the same (Check sum of the EPROM) to identify the ECM'* PROM chip. What follows is a fixed number of data bytes with sensor data. Following that is a variable length block of data with the trouble codes in them. The pattern then repeats. (Forgive me, it'* been about 15 years since I last tried to pick apart ECM data...memory is a little fuzzy on it)

As a fun project for a few weeks, it can be ammusing. The drill to figuring it out is to test data capture with the engine off, then move/disconnect one sensor at a time to locate which byte in the data represents that sensor. You'll also be throwing trouble codes on the ECM so you'll see a new value pop up at the end of the variable length portion of the data block.

IIRC, you used to be able to modify the winALDL software'* supporting INI file and create tables for ECM'* that weren't supported. I don't know if that is still the case.
When I went to a Haltech ECM on the '87 Camaro, I really didn't need to figure out GM'* ALDL anymore. Then OBD-II came along and it is actually a "standard" with published codes and standardized communications.

You may be able to intercept the data, but you will be able to do ZERO tuning.

No, but you can see what it is doing, which is the first step in tuning the car.

For a 90 Buick 3800 I'd suggest using one of Craig Moates cable kits along with TunerCat software to look at the prom. (The 90 LN3 is one of the configs it supports) You'll need an eprom reader/ burner, a UV eraser, and a couple of spare 27C256 EPROM chips. Then make your changes and test them out in the car to see how it runs and how the data stream changes.