ALDL data logging

[YakkoWarner]

I would love to have a conversation with the folks at GM who designed the ALDL system - preferrably with a selection of medieval weapons at hand. It seems like they designed it specifically to be hard to communicate with. 160 baud rate? Even in the 1970's almost every device that used serial communications worked on a multiple of a 300 baud rate (300/600/1200/2400/4800/9600/19200/38400 and so on). Why in the heck did they design a system using a communications speed that nothing else on the planet could talk to? The newer ALDL systems used 8192 baud, which is STILL not a standard rate.

GM would have had to have custom UARTS made that communicated at that rate, not just in the ECU installed in each vehicle but also in the test equipment these were designed to communicate with. That had to be more expensive than just using off the shelf components. Even with the technology available in the early 1980s, they could have made the interface a lot more usable.

 

[idahovette]

HUH????...............sorry, I'm old

 

[gmbellew]

I dont know why the data stream is so slow, and i agree it is frustrating sometimes. the ECM is adjusting things and using data much faster than what is reported out via the ALDL. they must have thought they were saving money by not reporting out all of the data? or maybe they were saving money on the diagnostics tool equipment and/or software? or maybe they intentionally made it difficult, at more expense, to protect the proprietary systems from being copied?

 

[Ricko1966]

We have to remember in 1981 just having on board diagnostics was an accomplishment. In the early 80s a commodore 64 was a bad ass computer. Sure that old 1981 stuff we can wonder now why it was so weak but then it was state of the art. And computer tech stuff wasn't cheap then like now,a commodore 64 was like 600 bucks,that was 10 percent of a stripper trucks new price.

 

[YakkoWarner]

No question the concept was very advanced for its day, and the system works well internally for doing its job. I just can't get my mind around why they used such a weird serial communication speed when it would have been easier and likely cheaper to use standard (even for the time period) stuff... Unfortunately I don't expect any of us here will ever know exactly why that choice was made.

 

[Fat 454]

That's why the Snap On 2500 series readers were so popular,expensive but popular,by changing out the cartridge like an atari cartridge you could use it on multiple different manufacturers.

so did the MT2500 with the right cartridge read ALDL GM outputs?

Anyone have any direct experience with the Snap On system ?

Maybe ( another ) dumb question - I am assuming all the scanner hook up gear is to enable graphing real time data ?, as you can read the stored flash codes using a paperclip..

 

[Ricko1966]

so did the MT2500 with the right cartridge read ALDL GM outputs?

Anyone have any direct experience with the Snap On system ?

Maybe ( another ) dumb question - I am assuming all the scanner hook up gear is to enable graphing real time data ?, as you can read the stored flash codes using a paperclip..

The SnapOn with the correct cartridge will read anything you want on in the Older GMs ,it was the shop scanner at 3 shops I worked at and love them. If I had more need I'd own my own, but I don't have the need anymore. Random you tube video but on pre OBD2 Corvette.

xc_hide_links_from_guests_guests_error_hide_media

 

[YakkoWarner]

I saw one of those SnapOn devices many years ago being used on a Ford vehicle - but in a fairly well equipped professional shop. I expect the price tag of the device exceeded the sticker price of the vehicle being tested....

Staying in the realm of "things actual people can afford", I was able to do a 1st test of the Moates cable last night since my laptop batteries came in, allowing me to actually run the laptop long enough to get a reading. The Moates cable works exactly as advertised - I installed the FTDI device driver pulled directly from FTDI's web site, configured TunerRT to listen on the simulated com port displayed in the Windows10 device manager for the FTDI interface, and it cheerfully connected and started displaying data (very slowly) on its dashboard summary.

Now the next learning curve comes into play. I really need to get a deep-dive into how to configure and use TunerPro. The dashboard summary worked and told me things - some of which were in the realm of believable, some that would violate the laws of physics and some that didn't seem to have any connection at all to actual reality:

It had a reading for vehicle speed, which I'm not sure how it could since the RPO codes for my truck clearly indicate "D1F - gear driver speedometer". I was testing this close to midnight last night so didn't actually drive around to verify if this actually reads anything or not.

The reading for TPS seemed to be based in reality (and showed me that I need to do some adjusting on that) - 0.65 with pedal full up and 4.xx (varied slightly between 4.00 and 4.10) with pedal full down. From what I've ready it should be 0.5 pedal full up and around 4.5 pedal full down.

The reading for engine RPM also seems to be in touch with reality, it was very close to what I get with an actual tach connected.

The reading for engine coolant temp indicated 198 degrees centigrade before even starting the truck (on a cool 63 degree night). The sensor, coolant hoses, and possibly the intake would likely melt at that temp - 198C=390F. And once I started the truck this reading started to decrease.

The MAP sensor reading was just nonsense - it showed 128. Didn't indicate 128 of what. It did decrease with the engine running but its kind of a meaningless reading. I expect this should show in inHg as a barometric value, or PSI as a manifold pressure value.

All of that to me indicates a software config mismatch - from what I can scrape up through the internet my understanding of this software is that it gets a raw set of values from the ECU, a simple list of "property id"="reading" which is repeated over and over on about a 2 second interval (due to the 160 baud rate), and the software takes that list and interprets it into meaningful information. Each vehicle type can have a different list, so you need a matching "ads" and "xdf" file for your specific vehicle to tell the software how that data is to be interpreted. I expect I have files for a similar but not exact match of vehicle, which is why some things look right and some dont.


I tried to see if it could show me the IAC counts, since an overly fast idle is one of the things I want to investigate with this device, but I didn't have time in the short timeframe I had last night to dig too deeply into the software. My next step is going to be be to bungee the cable up to the bottom of the column so its not draped across the pedals, bungee the laptop down so it doesn't go sliding around the cabin and then do a short test drive. Ideally I'd like to figure out how to get the software to start logging data first. My hope is that the software logs the "raw" data coming off the ECU before applying the ads and xdf file interpreters, which would let me then test various ads and xdf files againts the raw data to find one that matches my vehicle.

 

[Ricko1966]

People's budgets and needs,and capabilities all differ. MT2500s can be picked up used in the vicinity of 300 bucks,easy to use and works on a multitude if vehicles. It's not worth 300 to me anymore but if I was messing with more than 1 brand vehicle and more than once a month it would probably be worth it

 

[YakkoWarner]

People's budgets and needs,and capabilities all differ. MT2500s can be picked up used in the vicinity of 300 bucks,easy to use and works on a multitude if vehicles. It's not worth 300 to me anymore but if I was messing with more than 1 brand vehicle and more than once a month it would probably be worth it

I remember finding a couple for sale around that price (and in truth might have been tempted had the Moates alternative not been available), but it was never clear whether the seller had all the correct cables and software cartridges. I would have been highly angry to spend that much only to find it came with the Honda or Nissan connectors, and then had to start digging again for the missing pieces.

 

[Fat 454]

GM used 4 different protocols between 1981 and 1995. OBD2 is 1996 up. OBD1 wasn't even thought of until 1988 and wasn't mandated until 1991 only on California cars,even then it wasn't a standard system like OBD2.

I had figured ALDL ( in its various forms ) from 1981 up

OBD1 ( non standard ) 1982 through 93/95?

OBD2 - 1996 on

I think that's what you listed above - it would be real nice to have a definitive timeline / table of the different protocols, and the tools /options required to talk to each one. Maybe I'll have a go at putting something together that others can correct ..

Reading some of the comments above, it doesn't seem to be that easy to organise / predict what any given truck will have, however the tools required should remain the same, once the correct version is identified for any given truck ?

 

[Ricko1966]

I had figured ALDL ( in its various forms ) from 1981 up

OBD1 ( non standard ) 1982 through 93/95?

OBD2 - 1996 on

I think that's what you listed above - it would be real nice to have a definitive timeline / table of the different protocols, and the tools /options required to talk to each one. Maybe I'll have a go at putting something together that others can correct ..

Reading some of the comments above, it doesn't seem to be that easy to organise / predict what any given truck will have, however the tools required should remain the same, once the correct version is identified for any given truck ?

OBD1 didn't come about until 1988 and that was for California. Gm got OBD1.5 in 94 and 95 prior to that it was different versions of GM ALDL. OBD2 96 and later.

 

[Ricko1966]

I had figured ALDL ( in its various forms ) from 1981 up

OBD1 ( non standard ) 1982 through 93/95?

OBD2 - 1996 on

I think that's what you listed above - it would be real nice to have a definitive timeline / table of the different protocols, and the tools /options required to talk to each one. Maybe I'll have a go at putting something together that others can correct ..

Reading some of the comments above, it doesn't seem to be that easy to organise / predict what any given truck will have, however the tools required should remain the same, once the correct version is identified for any given truck ?

What truck are you trying to get live data on. I just read your bio it says you have 73 c20 there is no on board diagnostics for 73. Earliest for GM I'm aware of is 1980. And I think that's only Cadillac Sevilles

 

[Ricko1966]

I remember finding a couple for sale around that price (and in truth might have been tempted had the Moates alternative not been available), but it was never clear whether the seller had all the correct cables and software cartridges. I would have been highly angry to spend that much only to find it came with the Honda or Nissan connectors, and then had to start digging again for the missing pieces.

Did you get your laptop battery straightened out? Rumor has it you can use the moates cable a USBc cable adapter and run aldl Droid on your Android phone.

 

[YakkoWarner]

Did you get your laptop battery straightened out? Rumor has it you can use the moates cable a USBc cable adapter and run aldl Droid on your Android phone.

Yes I did - and was even able to take the whole setup for a litlle trip thru the side roads last night. Then realized I had no idea how to actually log data with the software, spent a good 30 minutes sitting in the driveway fiddling with it and then took ANOTHER little ride down the side roads to actually get a data stream sample.

The Moates cable works really good - I am less convinced I have the correct definition files for the software since the coolant temp reading reported by the software is backwards (software says almost 200 degrees C on inital startup and comes down as the truck warms up). I don't think my sensor is bad because the truck wouldn't run right at all with the sensor that badly out of whack, I fully expect its just the software mis-interpolating what the computer reports.

Other values seem to all be in believable ranges even though the units reported don't always make sense (short term fuel trim starts as "128" but we don't know what its 128 of, MAP sensor is reported as voltage but without any indication of what the expected low and high values should be, that doesn't really help).

Oddly enough, spark control isn't something that the ALDL data seems to be able to report, even though the computer is controlling it internally. It does not show up as a monitorable/loggable value (unless again, I could have incorrect config files for the software).

It does report IAC counts and TPS voltage which already is helpful - I was able to readjust my TPS sensor to be at .47 with pedal fully up vs. the .69 it was when I first connected the scan cable. After my 7-8 minute ride through the neighborhood, I already starting seeing trends that I don't understand in the relationship between the IAC, TPS. The IAC really seems to want the idle to be around 950, when you shift into reverse or drive the idle momentarily drops, but then the IAC counts start clicking up until again its at around 950-975. Likewise when you shift back into park, the engine RPM surges up to around 1700 and stays there for right around 60 seconds before the IAC counts start clicking down, again settling around 950-975 RPM. The weird thing is, while driving the IAC counts closely mirror the TPS voltage with almost instant response up and down. I didn't think the IAC was supposed to operate in unison with the TPS, but maybe it does. I know nothing about how all this is supposed to work. The goal is to record, learn what is and isn't right and then make right what is wrong.