Any interest in ALDL support?

Developer Projects
#1

Since it looks like I will be getting involved in getting the J1850 VPW support going I am curious if there would be any interest in ALDL support? This would be GM’s pre 1996 ODBI protocol. Since it will run off a standard TTL -> USB adapter at roughly 8192 baud with the RX/TX lines combined I have to believe it could be done with the M2.

I have seen mention that ALDL runs at 7 volts but apparently 5 volts is close enough if people are using TTL -> USB adapters.

To make work with the M2 I could use 1 pin as I/O or use combo of 2 pins with one being in and the other being out. The main issue I see with this is the difference in voltage. if the M2 triggering voltage for the input is 4 volts or more I could likely just use a diode to protect the ALDL from the 12 volt outputs of the M2 and use a resistor to drop the M2’s 12 volts to the desired voltage of the ALDL.

But again, not worth doing if there is no desire for it. Not sure how far back GM’s used the ALDL protocol but I know my '94 has it and as late as the Pontiac GTO used it to communicate within the vehicle and possibly others newer. And then again if a $10 interface already works with it does it make sense to add to the M2. I can see value in it since it could be included in the new Lawicel V2 protocol and be used with common utilities. Not to mention would require minimal additional hardware to make work assuming the M2 can trigger a digital input on 4 volts or higher.

And since some vehicles with J1850 or possibly even canbus still contain ALDL data buses it could make things easier if all is included in same device.

#2

I’ve got a 1995 GMC with a 454 and a 1989 GMC with a 350 that I want to tinker with. Both are definitely pre-OBDII. I haven’t seen many others posting about pre-OBDII, but hopefully they’ll come out of the woodworks.

#3

There are two different versions of “ALDL” that GM used. 160 baud, and 8192 baud.

Both of your GMC’s are TBI…the '89 is definitely 160-baud. Not sure about the 1995. 1996 would have gone to Vortec/J1850.

They are both somewhat different. 160-baud came first obviously, and was uni-directional. The ECM could only output info to a scan tool. Obviously the refresh rate was painfully slow, and there was only about 25 PIDs, but considering they introduced it in the early 1980’s, it was impressive for the times.

8192 is bi-directional, but as far as I know, its still request-driven and there are some annoying/complex master-slave relations to work through…so its a little trickier to work with and reverse engineer than the later J1850 and CAN…

Plenty of info out there about it though, if you google it.

Im sure two of the GPI/O’s on the M2 could work great with 160baud and 8192 baud…but i doubt the Macchina team would want to put much effort into writing software for it (understandably)…so you’d be on your own writing an Arduion program to interface.

#4

I forgot about the older 160 baud version, My '94 is most definitely 8190 as I have played with it in the past. The caprice moved to ODBII/J1850 in late 1995 for the PCM but based off what I have seen so far apparently it only involved the PCM since people have downgraded '96 vehicles to the '95 PCM and vise versa. Since I have access to the 8192 baud version that will likely be the only version I would be interested in getting to run.

Looks like I will be heavily involved in creating the J1850 protocol so I should be able to build the software for ALDL as well. Enough information out there to get it working well. Likely will have to have a Lawcel version and a legacy compatibility later for it so it can be used by software already in existence.

#5

Since I’ll probably (understandably) be on my own regarding the pre-OBDII stuff, could you point me in the right direction of where to start with my '89? Or would googling be sufficient?

#6

Googling might work… Eehack is a project based on the ALDL protocol so you could start there. You might be surprised that there are forums out there covering your vehicle. Since the Caprice came with an ODBII connector and was really ODBI you may find the same thing.

Also there is likely information on https://pcmhacking.net/forums/index.php

Rodney

#7

Thanks! I’ll check out that link and see about trolling some forums. What I’ve found is that there’s a lot of anecdotal experience, no single repository anywhere.

#8

@scarint What exactly do you want to tinker with? ALDL is very very well hacked, even to the level of emulators. The main issue with the TBI ecm is that it uses EPROMS that aren’t exactly common anymore, though you can adapt a more common EEPROM to them.

#9

I want to experiment with different fuel mappings for different driving styles with an aim towards high fuel efficiency (because efficiency trumps emissons).

I read about hydrogen boosters some years ago and feel there could be some bolt-on benefit gained by them (my own experiment showed an improvement from ~25mpg to 50mpg in a Kia Optima). I’m not sure if the booster was working as intended or if it was basically performing water injection, but would like to test more and see about tuning it.

Manufacturers have, I believe, gone the wrong direction for a number of years. They’re too stuck in their ways (https://books.google.com/books?id=a-kG_hoAvQkC&lpg=PA186&ots=AtM6Q6tsHT&dq=bill%20ford%20jr%20insular&pg=PA186#v=onepage&q=“we’re%20an%20insular%20company”&f=false)

I think by looking at what they did in the past, “fixing” it, and then looking at what they’ve got now, a better understanding can be had of the systems as a whole.

Also, the older vehicles are what I’ve got to play with at the moment. My '02 Jeep is coming along nicely, though.

#10

hydrogen boosters. lol.

That garbage is nothing but snake oil except with a larger than average cult following.

Automotive engineers spend millions of dollars and hundreds of thousands of man hours just searching to get that extra 1 mpg out of cars.

If a cars fuel economy could REALLY be improved 2-3x using hardware store parts cobbled together by some random idiot hillbilly in his/her garage, the car mfg’s would have done it years ago.

But hey, if you got an extra TWENTY-FIVE mpg, and now think you can get even more using a Macchina and something whipped up in Arduino, then all the power to ya…

#11

That’s what I thought, too, but the numbers don’t lie, I got what I got: about 96 miles, just under 2 gallons of fuel. I just don’t know why. If I only accomplished water injection, that could explain some, and there WOULD be negative consequences.

But in the scope of Macchina, I’m more interested in playing with the computer.

#12

Your trucks dont have EEPROM that is flashable/tunable via OBD…the macchina is literally going to do nothing for you…

Buy a chip burner, check out https://www.thirdgen.org/forums/, and start learning how to tune in hex/assembly…

#13

Then I’ll play with my other vehicles then, I suppose. And I will check that site out, thanks.

#14

Hi I am interested in ALDL support! I was just wondering if you ever went forward with this and if so did you write up how to do it with the M2?

#15

Not really. There is someone interested in Australia in these and realistically a large number of GM vehicles used ALDL well into the 2000’s for things like clusters and such. I believe the GTO for instance has an ALDL cluster in 2004.

I also requested support for the hardware as an option in an update but never got an answer if ALDL needed to be given voltage or take it away for sending. Sounds like ALDL may maintain a 7 volt steady state and pull down to 0 volts. If so then the M2 hardware is currently compatible through the external IO ports. If it needs to be sent a positive 7 volts then you would use a different output pin and a voltage divider. I have too many other things on my plate right now to do anythign with this but I may down the road. My Caprice has ALDL and I have some spare PCM’s and wire harnesses laying around. I MAY decide to build support into the M2 firmware for it.

#16

So I will revive this thread. Someone I am working with on another project that desires support for ALDL will be doing some proof of concept stuff for it. When you research how many ODBII vehicles still use ALDL for other stuff such as clusters and such there are a large number of them out there. And prior to 1996 GM used 8192 based ALDL in all of their vehicles for a while so there should be some interest in it. As I already mentioned a bunch of Holden vehicles were using ALDL well into the 2000’s

Rodney

#17

Lets dive straight into it.
Here is an example ALDL circuit
ALDL_Circuit

Not much needed, two PNP Transistors and a resistor.

I have connected up to the 26pin connector on the M2 to use RXD3 and TXD3 as the ALDL read and write from the M2.
And also used SCL0 (Pin80 SAM) to control the ALDL reading control pin which I have labelled as pin11 in the above circuit which was used on a different processor.

The purpose of the ALDL read control pin is to disable reading when writing an ALDL frame to the bus. This is important to do otherwise the M2 will receive the exact frame you have just written since both RX and TX lines are tied together.

The library I have been putting together includes:

  • Read/Write ALDL frames
  • Receive bus sync (by silence or heartbeat)
  • Receive Frame filtering
  • Searching for heartbeats
  • Searching for silence before writes
  • Auto calc and verify checksums
  • Error handler
  • Time out parameters (Wait between bytes ect)

Annnnd, heres a quick pic of some ALDL frames being received by an ALDL BCM I have on bench (Forum prevents me from displaying image in post as a new user…)
ALDLReading_Demo|450x376

Will look at making a fork on the github master to add in support for ALDL, be good to see it merged into the master. Even better, possibly add ALDL hardware into a later revision… or beta hardware!!! :wink:

#18

Oh, and while Im thinking of it.

ALDL is on pin 9 of the OBD2 connector. I have just soldered a single wire to this pin and run it back to the circuit.

I have a very small SMD PCB design for the ALDL circuit which I will tuck into the M2 (And case) for now so theres no protruding wires and parts, just solder to the required interface board pins.

#19

I’m just wondering how this project is going? Have you been able to test it out yet?

#20

Been a bit bogged down other bits and bobs, but the concept setup worked perfectly. Left it running over night without any problems or hickups.

I was suggested to open up a Git repo for it and post a link up. Ill probably make a dedicated dev thread for this and post a link in here to it.

Just need to make some time for putting together commented examples for others to begin off of.
In short, the following happens:

  • Startup ALDL protocol with desired Baud rate (ie. 8192)
  • Set desired filters if required
  • Set any other optional settings such as heartbeat or silence waits
  • Enable protocol to begin reading from bus and allow writing