Bringing TBI and Multi Port Fuel Injection to a New Level.     EFI Conversions and Tuning! Seattle to Portland! E-mail Tuning Consultant!
Page 1 of 3 123 LastLast
Results 1 to 15 of 37

Thread: Looking for asistance with ALDL project...

  1. #1
    Fuel Injected! Quaraxkad's Avatar
    Join Date
    May 2019
    Posts
    32

    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
    Fuel Injected! steveo's Avatar
    Join Date
    Aug 2013
    Posts
    2,879
    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
    32
    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
    Fuel Injected! steveo's Avatar
    Join Date
    Aug 2013
    Posts
    2,879
    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
    32
    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
    32
    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.

  7. #7
    Fuel Injected! Quaraxkad's Avatar
    Join Date
    May 2019
    Posts
    32
    A little more experimentation and research, I think I found what I need...

    I don't have any method of generating a crank signal. The crank sensor signal goes to the ICM, and the ICM outputs a different signal to the PCM. I have no idea what format that signal is in, so that was a dead-end unless I found somebody who already knew... Instead, I found something else I have had all along, a zip file containing a bunch of .ds files, I have no idea where they came from or what they're used for. But it had data stream definitions, and I'm pretty sure this holds the answer of which bytes are RPM.

    Code:
    ..HEAD02L ALDL NORMAL MESSAGE *F9MSG1*
     - MESSAGE ID     = $0A
     - MESSAGE LENGTH = $58
     - DATA       NAME            DESCRIPTION
    
       1          IPMW9           MODE WORD FOR INSTRUMENT PANEL
              0     NOT USED
              1     NOT USED
              2     NOT USED
              3     NOT USED
              4      1 = DIAGNOSTIC ENABLE LINE SHORTED
              5      1 = ALDL MODE
              6      1 = SERVICE ENGINE SOON LIGHT ON
              7      1 = UP SHIFT LIGHT ON
       2          NEWRPM          RPM IN PREVIOUS 12.5 MS (MSB)
       3          NEWRPM+1        RPM IN PREVIOUS 12.5 MS (LSB)
                                      RPM = MSB*256 + LSB
     - CHECKSUM
    Looking at one string of my sample log, I see 0A 58, signaling the beginning of this stream.
    Next is 40, 64 in dec, 01000000 in binary. Bit 6 is 1, meaning the SES light is on, makes sense considering the lack of sensor inputs!
    The next two bytes are 00 00, defined as RPM MSB*256+LB.

    There is more defining the entire stream, but that's all I needed to know! Now I'll order an Arduino, and see if I can output a dummy data stream containing only a value for RPM and see if the gauge cluster responds.

    EDIT: Also, the 3C is the 6000RPM redline. So I can also set that to adjust the gauge display accordingly!

    EDIT2: Oh, I guess i must have found all those files from this very forum! I've had them saved for years though. http://gearhead-efi.com/gearhead-efi/def/aldl/A140.DS
    Last edited by Quaraxkad; 12-09-2019 at 04:07 AM.

  8. #8

  9. #9

  10. #10

  11. #11
    Fuel Injected! Quaraxkad's Avatar
    Join Date
    May 2019
    Posts
    32
    I've ordered an Arduino Uno, it will be here tomorrow. I believe it's C++, not C. First step is basically just the example code shown here: https://www.arduino.cc/reference/en/.../serial/write/. Except I'll swap the hello string for the 0A 58 40 0D AC byte sequence and the proper 8192 baud rate. If I've done my math correctly and it works, that should give me a tach reading of 3500.

  12. #12
    Fuel Injected! steveo's Avatar
    Join Date
    Aug 2013
    Posts
    2,879
    right on

    here's a general function to generate a checksum byte with c or c++, just run it against the array

    Code:
    char checksum_generate(char *buf, int len) {
      int x = 0;
      unsigned int sum = 0;
      for(x=0;x<len;x++) sum += buf[x];
      return ( 256 - ( sum % 256 ) );
    }
    here's a function to test an incoming checksum (not that you should have to for this program)

    Code:
    bool checksum_test(char *buf, int len) {
      int x = 0;
      unsigned int sum = 0;
      for(x=0;x<len;x++) sum += buf[x];
      if((sum & 0xFF) == 0) {
        return true;
      } else {
        return false;
      }
    }

  13. #13
    Fuel Injected! Quaraxkad's Avatar
    Join Date
    May 2019
    Posts
    32
    Ah yes, I had completely forgotten about the checksum! Adding in your checksum function, this is pretty much the entirety of the initial test! I'm leaving out all of the other bytes because I expect they are uneccessary. I'm assuming the gauge cluster will only look at the 5 bytes after 0x0A.

    Code:
    void setup() {
      Serial.begin(8192);
    }
    
    void loop() {
      if (Serial.availableForWrite() > 5) {
        byte b[5] = {0x0A, 0x58, 0x40, 0x0D, 0xAC};
    
        unsigned int x, sum = 0;
        for (x = 0; x < sizeof(b); x++) sum += b[x];
        byte cs = ( 256 - ( sum % 256 ) );
    
        Serial.write(b, 5);
        Serial.write(cs);
      }
    }
    It compiles without errors or warnings, but that doesn't mean my logic is sound!

  14. #14
    Fuel Injected! Quaraxkad's Avatar
    Join Date
    May 2019
    Posts
    32
    Adding a little math to convert an integer RPM into MSB and LSB...

    Code:
    void setup() {
      Serial.begin(8192);
    }
    
    void loop() {
      if (Serial.availableForWrite() > 5) {
        int rpm = 3200;
        byte msb = floor(rpm / 256);
        byte lsb = rpm % 256;
        
        byte b[5] = {0x0A, 0x58, 0x40, msb, lsb};
    
        unsigned int x = 0, sum = 0;
        for (x = 0; x < sizeof(b); x++) sum += b[x];
        byte cs = ( 256 - ( sum % 256 ) );
    
        Serial.write(b, 5);
        Serial.write(cs);
      }
    }
    Now if that works, I will add a potentiometer and read that for input to convert to an rpm reading, and I should be able to control my tachometer in real time!

  15. #15
    Fuel Injected! steveo's Avatar
    Join Date
    Aug 2013
    Posts
    2,879
    looking good

    the third byte in your 'testing' datastream packet is probably 0x40 because your test bench had the check engine light on, so use 0x00

    you'll probably be best off introducing a small delay like delay(10) into your main loop (inside your if()) as most aldl devices can't accept data at such a high rate

    really curious to see if it works on the first try for you

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
  •