ALDL 8192 (GM ODB-I)

Hello,

First I want to ask, has anyone has done a project with arduino (or compatible chip mega32u4 etc) and 8192 baud ALDL?

There are plenty of schematics for interfacing a com port to the ALDL port:

However, I found this project interesting and it is sort of on the track I want to go:

If you scroll down to "3.2 Circuit Design:" It shows 3 transistors (plus resistors) to control the sending/receiving on the bi-directional ALDL line. They also have some code.

Unfortunately, with the ALDL stream each ECU/ECM and prom have a slightly different data stream. I can work around that.

My Goal:
I want to log this data to SD Card (not a problem), Display important information on a LCD (not a problem), and decode the data. The decode the data is where I am having issues.

So has anyone done something similar to this? (maybe different hardware for the interfacing circuitry)
IF so, How can I detect the start of a sync frame? 9 1s followed by a 0.

I intend to keep all circuits and code open source as this evolves.

Thank you,
J.C. Woltz

I have modified code running somewhat. It is too big to post. Forget what I said about sync earlier.
My current issue is syncing when to send the ALDL mode one command. My ECU spits out F0 55 BB, I am not getting a reliable connection. When I add code to look for that, then I cannot sync. If I leave that code out, eventually it syncs up. There has to be a better way.

Hello,

Here is where my code is at currently. It is ugly and a mess. I at least want to post this in case someone is looking for it in the future. I will continue to work on it.

At the moment I am using NewSoftSerial on d2 and d3 to see the output. My final implementation will wither be on an atmega644 or atmega32u4. For now this is on an atmega328p.

Things to change/improve:

  • Continue library development, so that it is easy to import different aldl definitions
  • Switch to a ISR(USART0_RXC_vect) to receive data, will take major re-working of Get_Car_Raw()
  • Change ALDL library to handle the generic ALDL and then select different definitions. Currently 034 as that is my vehicle
  • Work out some timing/synchronization issues. I do have code to wait for the 0xF0 sent out by the ECU to start sync. However things will get out of sync every now and then.

Personally, I want want to use a Graphics and Text based LCD for final implementation. Possible microsd based on existing atmega32u4 boards I have made.

Hopefully this will help someone. Any comments to help on code are welcome.

aldl_test2_int.zip (5.5 KB)

Thanks for posting what you have so far! I am interested in OBD1 and 2 communication. Among my list of projects I am trying to do something similar.

I hope you have success,
Mark

cyclegadget:
Thanks for posting what you have so far! I am interested in OBD1 and 2 communication. Among my list of projects I am trying to do something similar.

I hope you have success,
Mark

Thank you cyclegadget. I have made progress. I am trying to clean up the serial aspect of this, and that is why I am asking programming questions in this thread: http://arduino.cc/forum/index.php/topic,77772.0.html

I didn't think it was cross-posting since I am only asking about the serial aspect of it.
Here is my spaghetti mess of code that works! (ardl_test3) Now it is meant for my vehicle which uses A034.ds
ardl_restart is an attempt to use only arduino commands. But it wastes time waiting on serial data. BUT it can get readings and move them out in 119 ms.
ardl_restart2 is an attempt to make better use of serial available. It works, but it takes about 6 seconds to get a lock and get new readings.

ardl_restart* have the calculations and display stripped out of them to focus on optimizing the data collection.

As I have mentioned before, I am moving to a 644p or 32u4, but I will try to keep an atmega328p version always available.
Once I have the serial loops worked out, I want to make an ALDL library. That way my vehicle is not hard coded into the code. That way others can add/update definitions.

aldl_test3_ard.zip (7.23 KB)

aldl_restart.zip (1.39 KB)

aldl_restart2.zip (1.67 KB)

Thanks for posing this. I am looking to make and OBD-I reader/data-logger for the GM TPI computers. Initially I hope to data-log to a Memory card. Once that works, I hope to then have the board communicate with Android phones. I will have to review and check these examples out.

amargari:
Thanks for posing this. I am looking to make and OBD-I reader/data-logger for the GM TPI computers. Initially I hope to data-log to a Memory card. Once that works, I hope to then have the board communicate with Android phones. I will have to review and check these examples out.

You're welcome amargari. I have since developed it further, but stopped posting online for lack of interest. Thats a real killer in the OSS community where there is a topic that not many people are interested in.

Current setup is customer atmega328p board, (big waste of micro, but due to timing issues...), that uses newsoftserial to feed a teensy (had it laying around). Logging to uSD, and the Teensy controls the 2* 4x20 LCD Character displays. I'm willing to post code, but the earlier stuff may be more beneficial to you. Since the code now is VERY specific to my vehicle. but if you want it, I will post it. (In all its ugly hacks)

JC

Hi JC

Do you have any updates on this project? I would like to implement a similar setup in an old GMC Sierra.
Best regards

Thanks for posting this @jcwoltz - I recently purchased a 1989 GM Corvette with TPI and L98 engine, which is having some issues, but not always throwing codes. I am hoping to get more data from the ALDL stream than I can get from the SES blinking light method with A&B shorted and engine stopped. I'd also like to monitor data while the engine is running, if that be possible. I have the factory service manual but there is nothing in it about the protocol. Here is the start of a GitHub repo for this project and share any progress which I might base on your code. I will be using a Teensy 3.2 or 3.5 as the controller with a small ILI9341 color touchscreen since we have a lot of those at hand. Here is a Google Doc with related information about my efforts, specific to this vehicle.