Free Windows Based Scan Tool

[MCHdrivesan86GN]

I was trying to home grow a scan tool and while looking for some information I ran across a site that has a free Scan Tool application for download. I installed it on my laptop and it looks like it has potential. A bummer for me though, because it appears that my serial port, DE9, pinout is different. So I might not be able to use it as is and the developer probably will not be willing to fork over the source code for modification. It appears he lives in Sweden. It is probably written in Visual Basic or Visual C/C++.

Anyway, I figured I would post the link for anyone who might be interested. One immediate drawback is that you would have to build the hardware interface in a DE9 connector and wire harness. Schematics and instructions are provided. It looks pretty simple. Most of the parts should be available at Radioshack or other electronic component store or another alternative, the guy list a couple of sites that builds the complete interface cable. The only thing you won't find at Radioshack is male mating ALDL connector on the tool side. I believe it is OBDI. I have not checked the sites listed, but it is possible that they have the mating connector for sale, you would think they would. One other thing the mating connector is not necessary, you can run the wires directly into the terminals of the ALDL connector on the vehicle side.

Hopefully this will be of use to someone. The software portion of it is free, you can't beat that given that it works. I'm not avocating it, since I have not personally used it. So anyone interested, try at your own risk.

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

[413turbo]

i'd like to get ken's input on this, if he is willing to reveal his secrets:pic:

[MCHdrivesan86GN]

Probably not a bad idea to get input from those who have actually developed something similar. Ken obviously qualifies.

Anyway below is the link to the company that builds the interface cables. You can get the cables for about $60. Too me this is ripoff, but I have components and the necessary tools to build the interface cable at my disposal.

http://www.aldlcable.com

[MCHdrivesan86GN]

One other drawback that I forgot to mention, the application was written for RS232 on DB9 (EIA/TIA - 574), which is being phased out in favor of USB. And there could be some compatibility issues depending on the RS232 type. My laptop's serial port appears to be RS232 on DB9 (RS-232D EIA/TIA-561) which has a different pinout. Like I said bummer for me, because the low-level driver in application would need to be changed to make it compatible with my laptop.

[kenmosher]

Looking at the circuit ... it should work, but is extremely simplified and might be subject to a lot of noise and "hash". Also, there's no protection for any kind of spike (like a static zap) so be really (REALLY) careful if you hook this up ... make sure you touch something metal in the car before plugging anything in. If you don't it could fry the serial port.

The resistors are important too ... if you use those schematics, make a switch to switch the various resistors in and out if you want to use it on other cars (TurboLink did this all in the FETs).

The probem I see is that some of the "supported" vehicles may not have some of the sensors accurately decoded.

[MCHdrivesan86GN]

Ken,

Thanks for your input. I myself have not scrutized the circuit, but a LPF might not be a bad idea.

[MCHdrivesan86GN]

Well, I'm going to have one of the techs build up interface cable and I'm going to hook it up tomorrow and see what happens.

[WH1Regal]

I have used this program in the past on my 1991 Chevy S-10 and my 1988 Pontiac Fiero. I've always had Turbo-Link in some version or another, so I've never tried it on the Buick.

It is nice, I made a home-made interface that was very straight forward...literally taped it to a wood board. Not sure if this board supports images, but here goes...

http://www.butchthecat.com/past/s10/s10-40.jpg

You can see the serial connection to the right, some resistors etc followed by two wires marked with tape on the other side. I'd plug those into the respective holes on the ALDL.

http://www.butchthecat.com/past/s10/s10-92.jpg

Above is my computer I ran it on (the WinALDL dash is on the screen). It's an IBM ThinkPad 600, same machine I run TurboLink on with Win98SE. That picture I was adjusting the operation of my new electric fan and using the ECM temperature readout.

I eventually updated to the TurboLink 4.0 version and that pretty much made all of this moot. It was nice though, lots of data you could dump into a spreadsheet.

[MCHdrivesan86GN]

I finally built my interface cable and ran the program. It appears to work just fine. Took me about 5 minutes to build the circuit, I put it inside the DB9 connector housing.

As I play with it a little more, I'll post additional information if anyone is interested or has any questions.

If possible, I going to try and tune my car. This will be an uphill battle, since I'm new at this

[kenmosher]

Just be aware that simple circuit is very susceptible to noise and data "jitter".

[MCHdrivesan86GN]

Ken,

Thanks. I'm going to add a low pass filter to the circuit. Beyond that is there anything else you would suggest? Within reason.

Thanks again,
Charles

[kenmosher]

The low pass will help quite a bit on the super low speed data that the TRs use. There's all sorts of stuff (like optoisolators) that are a good idea for a commercial product, but are overkill for a one off.

The high(er) speed P4 data is a bit more problematic and adds a lot of complexity if designed right, but isn't relevant to the low speed data streams only.

[MCHdrivesan86GN]

Ken,

Do you know what the data transfer rate is from the ECM? According to a GM spec that I seen it is 8192bps. Is this correct?

Thanks,
Charles

[kenmosher]

No. It's equivalent to about 160 baud.

8192 is for the later P4s.

[MCHdrivesan86GN]

Thank you. That bit rate seemed to be a bit faster than what I would expect and when I hooked up an o-scope on the data line, I didn't see that data rate. However, that number came directly from GM.

[kenmosher]

Believe me ... been through all the reverse engineering YEARS ago. :) That's where TurboLink came from over the years ...

It's a bit unusual how the bit patterns and timing are on the old C3 ECMs.

The P4s were much more "typical" UART style data streams (which is where the 8192 comes from).

Again, there are several families of ECMs and they were used differently in different platforms and engine combinations.

The CCC was the first (and was used on the carb'ed stuff until the mid80s.) ... and used about 75 baud 12v signal that ran thru the Check Engine Light.

The C3 was used on the first generation DIS systems up and a lot of the throttle body systems up until about 1992 (later on the trucks than the cars).

Beginning about 1988, you see the second gen DIS systems with the P4 ECMs becoming phased in, since there were some rudimentary dash controllers and transmission controllers coming into play. The earliest P4s were on some of the J cars (such as the turbo Sunbird).

[MCHdrivesan86GN]

Again, thanks for the information.

I did a bit of further investigating, based on the info you posted, and found that the GN falls under GM's Diagnostic Bus Properitary Protocol 1980-?, which I believe is pulse width modulated. Being that you have went through this before, I assume you understand how to decode the signal. One of my questions is, does the modulated signal mimic a UART/RS232 protocol? That would seem plausible. To cut through the chase this is leading to what R and C values I need for the low pass filter. Knowing 160 baud gives me some indication, but what does that equate to in bit rate? I understand in the olden days, baud rate was bit rate. Here I don't think that is applicable, because if the signal is mimicing a UART/RS232 there will be 10 or 11 bits per character/symbol. If I'm understanding baud correctly, baud indicates the number of symbols per second. Given that, a new symbol would come across every 6.25milliseconds and then that would be divided by the number of bits per symbol and that would give the bit rate and then from there that would allow me to derive what the cutoff frequency should be for the LPF. However, the calculated bit rate and comparing the to trace from the o-scope they don't seem to match. So am I missing something here, maybe something simple or am I way off.

Regards,
Charles

[MCHdrivesan86GN]

Again, thanks for the information.

I did a bit of further investigating, based on the info you posted, and found that the GN falls under GM's Diagnostic Bus Properitary Protocol 1980-?, which I believe is pulse width modulated. Being that you have went through this before, I assume you understand how to decode the signal. One of my questions is, does the modulated signal mimic a UART/RS232 protocol? That would seem plausible. To cut through the chase this is leading to what R and C values I need for the low pass filter. Knowing 160 baud gives me some indication, but what does that equate to in bit rate? I understand in the olden days, baud rate was bit rate. Here I don't think that is applicable, because if the signal is mimicing a UART/RS232 there will be 10 or 11 bits per character/symbol. If I'm understanding baud correctly, baud indicates the number of symbols per second. Given that, a new symbol would come across every 6.25milliseconds and then that would be divided by the number of bits per symbol and that would give the bit rate and then from there that would allow me to derive what the cutoff frequency should be for the LPF. However, the calculated bit rate and comparing the to trace from the o-scope they don't seem to match. So am I missing something here, maybe something simple or am I way off.

Regards,
Charles

I found my answer, here baud does equal bit rate.

Link to GM's 160 Baud ALDL data stream definition. This page may be referenced here already.

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