Results 1 to 15 of 40

Thread: Looking for asistance with ALDL project...

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Fuel Injected! Quaraxkad's Avatar
    Join Date
    May 2019
    Posts
    37

    Looking for asistance with ALDL project...

    I've got a project I need to get started on now that my car is running thanks to the help provided here in a previous thread! I have a 92 Cutlass with an L67 swapped in. I also have a gauge cluster from an earlier model Cutlass International, which takes the ALDL input from the PCM to determine the RPM. But now that I've swpped over to OBDII L67, I don't have ALDL and therefore I don't have a working tachometer! So what I want to do is take a tachometer signal (presumably from the ICM?) and with either a Raspberry Pi or Arduino, simulate a fake ALDL stream containing only the RPM signal so that the cluster reads it and displays engine RPM. All the research I've done I have only found people who made ALDL stream *readers* out of Arduino's and Pi's, but I need information on the protocol to simulate *writing* an ALDL stream. The rest of the project I think I can handle myself, I just need the assistance of someone familiar with the ALDL protocol to walk me through that! Anybody interested in helping?

  2. #2
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    yes that's a wicked project, i'd be glad to help, 100% on board. i have many projects that have completed that parallel this one we can reuse code or ideas from, and can code c and c++ fairly well, and understand how the obd-i gm datastreams roll.

    an arduino would be a cool basis for it, super minimal, fast, and low power consumption. i've done intermediary instrumentation interfaces with arduinos (take analog and digital data intended for a proprietary dashboard, and spit it out on segment LED displays.. it was really pretty fun and easy) but never done any actual serial arduino stuff myself. it might get complicated on the serial end of things but i'm sure its' doable if you want to go that way, sure we could make it work.

    a raspberry pi with linux is fun, you can use an FTDI based serial interface over USB with it to save time and effort, very cheap. the raspberry pi is also multitasking and powerful and you can use it as a car PC at the same time. i wrote a project i called aldl-io a long time ago for linux that used a cool method of serial comms, it uses the FTDI interface in raw USB mode with libftdi, so basically the program has truly direct control over the serial port, so setting the oddball 8192 baud rate and communicating with minimum latency is effortless. highly recommended.

    as far as the aldl comms go,

    there are kind of two distinct modes for aldl on most ecms i've seen.

    first mode is 'idle traffic' and that is usually in effect during normal vehicle operation, the bus master (usually the ECM but sometimes the CCM/BCM/whatever) has 'the stage' and every other device is 'the audience' but really the bus master just sends out some crazy poorly defined array of bytes containing data about the current vehicle state. generally other devices on the bus listen but do not respond to this data. this mode is likely where you get your dashboard data from.

    the second mode is usually used by diagnostic equipment (dataloggers/scanners) where the 'tester' becomes the bus master and all idle traffic is silenced, the tester then requests data from any device it feels like, and the device responds to it.

    standard aldl messages are in a certain format: http://fbodytech.com/misc/ee-aldl-communications/ (some parts of this are EE specific but the first part applies to your car for sure

    if you send me a private message, i have some really cool documents on ALDL comms i can give you to read for fun.

    now the problem is, the idle traffic stream is NEVER well documented. if you started by getting a serial log of your original ECM while twiddling the VSS input i'm sure we could derive the proper idle traffic, figure out the checksums, and away we go. a bench setup should not be hard to build

    let me know how i can help further or what you figure

  3. #3
    Fuel Injected! Quaraxkad's Avatar
    Join Date
    May 2019
    Posts
    37
    Great, thanks for the support!

    It sounds like you think a Pi would be the easier than Arduino. I have seen that the Arduino also has an FTDI addon available, so that might level the playing field? I have no experience with either, so I'm open to whichever would work best. I don't know any C, but I am familiar with a few languages and write a lot of PC software but never anything on a device like this. I have also written software that does serial communications with Acura Legend and NSX ECU's, so I have a *very* basic familiarity with serial coms.

    I think step 1 will be for me to set up a test bench for my old PCM, and more than that I suspect I'll have to simulate a running engine condition (rather than just 12v/Gnd to power it on) to make sure it's getting an RPM reading. Step 2, capture and decode the idle traffic to figure out where the tach signal is. Step 3, write a simple program to output a dummy signal and make sure the gauge cluster responds to it. Step 4, find a suitable input from the 04 Impala engine/PCM that can be converted to a tach signal. Those 4 steps make it sound pretty easy! What am I forgetting?

    BTW, this is the gauge cluster doing its startup bulb-check sequence:
    https://s3.amazonaws.com/Quaraxkad/C...1559_clip.webm

  4. #4
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    i love that dashboard !

    i did for some reason think we were dealing with vehicle speed when i wrote that post. no idea why i misread that.

    i doubt you'll have to truly simulate a running engine to get an RPM reading, but we'll find out. i would think just fiddling around whatever it uses for engine rotational reference will work. if you really want to get hacky just grab an old distributor or cam sensor or whatever it uses, and hook it up to a drill or something.

    what you'll want to do is connect whatever datalogger (tunerpro RT would be good then we have an adx to play with) to your bench setup and get datalogging working, and ensure that the RPM moves in the datastream. then restart that ECM without the datalogging in place and do the same thing, so we can get an idea of what the idle datastream looks like, and what byte represents the rpm (and to see if the conversion is the same in the datalogging definition, it should be).

    after that simulating it should be somewhat trivial

  5. #5
    Fuel Injected! Quaraxkad's Avatar
    Join Date
    May 2019
    Posts
    37
    I set up a test bench, wired up the PCM and my ALDL adapter. I was able to get some datalogging going in TunerPro so I know it's working.

    I grounded terminals A and B of the ALDL DLC, and used a serial port monitor (Realterm) to save a ~30s raw hex log of the traffic, which should be the ALDL diagnostic stream: https://s3.amazonaws.com/Quaraxkad/C...pture_diag.txt

    Then I grounded only terminal A and recorded another log, which should be the idle stream: https://s3.amazonaws.com/Quaraxkad/C...pture_idle.txt

    Assuming I did all that right... Are you able to learn anything from these? If not, what do I need to do next?

  6. #6
    Fuel Injected! Quaraxkad's Avatar
    Join Date
    May 2019
    Posts
    37
    On further inspection, I think that both of those logs appear to be the same repeating pattern with only a few bytes changing. I think they might both be ALDL diag or idle chatter, I have no idea which.

    I tried to format it in a way that looked right Here's a quick snippet:
    Code:
    0A 58 00 00 00 9E 0A 58 00 00 00 9E 0A 58 40 00 00 5E 05 5F 40 20 00 3C 81 00 00 02 00 01 7C 0A 58 40 00 00 5E F0 56 F4 C6 
    0A 58 40 00 00 5E 0A 58 40 00 00 5E 0A 58 40 00 00 5E 05 5F 40 20 00 3C 81 00 00 02 00 01 7C 0A 58 40 00 00 5E F0 56 F4 C6 
    0A 58 40 00 00 5E 0A 58 40 00 00 5E 0A 58 40 00 00 5E 05 5F 40 20 00 3C 81 00 00 02 00 01 7C 0A 58 40 00 00 5E F0 56 F4 C6 
    0A 58 40 00 00 5E 0A 58 40 00 00 5E 0A 58 40 00 00 5E 05 5F 40 20 00 3C 81 00 00 02 00 01 7C 0A 58 40 00 00 5E F0 56 F4 C6 
    0A 58 40 00 00 5E 0A 58 40 00 00 5E 0A 58 40 00 00 5E 05 5F 40 20 00 3C 82 00 00 02 00 01 7B 0A 58 40 00 00 5E F0 56 F4 C6

    The first line begins with 0A 58 00 00 00 9E repeated twice and then 0A 58 40 00 00 5E once, all following lines begin with 0A 58 40 00 00 5E repeated three times.

    Then all lines are 05 5F 40 20 00 3C.

    Next byte varies between 81 and 84. (This might be voltage, 81-84 hex is 129-132 dec, using the x*0.1 conversion formula set in the A1.adx TunerPro definition that's 12.9-13.2 volts, which is exactly what TunerPro reports as the voltage while logging)

    Then 00 00 02 00 01 on all lines.

    Then between 7A and 7C.

    And finally all end with 0A 58 40 00 00 5E F0 56 F4 C6.

    Those two bytes are the only changes, which I assume are voltage readings and something else?
    Last edited by Quaraxkad; 12-08-2019 at 01:34 AM.

Similar Threads

  1. New guy old project
    By The Stickman in forum Introductions
    Replies: 1
    Last Post: 04-24-2015, 05:26 AM
  2. Need help on new project
    By SuperHbody in forum GM EFI Systems
    Replies: 0
    Last Post: 01-05-2015, 06:45 AM
  3. new here...odd project and need help
    By travisr1988 in forum GM EFI Systems
    Replies: 5
    Last Post: 04-19-2014, 06:30 PM
  4. Another TPI Project..
    By ezobens in forum GM EFI Systems
    Replies: 16
    Last Post: 01-20-2014, 05:49 PM
  5. 85 k5 project?
    By mjc in forum GM EFI Systems
    Replies: 0
    Last Post: 12-24-2013, 01:50 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •