GM ALDL Project - Library and Hardware

Developer Projects
#1

ALDL is an old GM protocol, used since the early 90’s through to about 2004ish. It was implemented on millions of vehicles, and is possibly the only single missing protocol that the macchina does not have implemented natively.

This projects purpose is to add in this missing protocol to the M2, with a very simple (And cheap!) hardware, and a library which should suit most vehicle applications.

Here is a link to the current github repo
Tested and working for 5v ALDL circuits at 8192 baud on pin9 of the standardized OBD2 (J1962) connector.

Next to add into the repo/thread is the hardware diagram + parts list which is basically a couple PNP transistors and resistor.

Any interest in ALDL support?
#2

It’s great to see someone add support for another missing protocol! I don’t have any vehicles to test with but I can see this being a big benefit to lots of other people.

#3

Would you just have to change the ALDLhandler and ALDLcontroller to 160 so it will work with older vehicles? Or is there other changes that would need to take place for it to work with this other buad rate?

#4

A little more to it unfortunately.

Some useful information about 160baud ALDL devices can be found here: https://www.techedge.com.au/vehicle/aldl160/160serial.htm

Using the VN as the example (As explained in above link), these don’t follow the same ALDL protocol as the modern vehicles at 8192.
A normal ALDL frame has the following:
ID byte (or header byte)
Length Byte
Data bytes
Checksum

In the old 160baud style, theres no standard to them… it appears they just spit out a chunk of data every so often. The length of that data will depend on the car, the link above explains the VN outputs 20bytes… plus an additional 1 byte which is used so a scantool can sync with the vehicle.

The library could be adapted to suit.
Off the top of my head, the following would need to be implemented:

  1. Flag to indicate a non-standard ALDL frame is to be received
  2. Sync byte information
  3. End Of Frame (EOF) timeout

Last part is probably most important as this will determine when the end of the data is received, and also means we dont need to know how long the data is before hand.