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?

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

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

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

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?

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?

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

oh man that's like cheating!

you should try to 0xff some of the unused bytes just for fun to see if any undocumented stuff lights up

have you decided what you’re going to write the code with? arduino c?

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.

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; } }

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!

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!

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

Quote:

F0 56 F4 C6 0A 58 00 00 00 9E 0A 58 00 00 00 9E 0A 58 00 00 00 9E 05 5F 00 20 00 3C 7F 00 00 02 00 01 BE 0A 58 00 00 00 9E

That is the message and here is the decoding

F0 56 F4 C6 -message 1 broadcast message of bus master F4 indicates the id of the master
0A 58 00 00 00 9E -message 2 to module ID $0A 3 bytes long
0A 58 00 00 00 9E -repeat
0A 58 00 00 00 9E - repeat
05 5F 00 20 00 3C 7F 00 00 02 00 01 BE message 5 to module ID $05, 10 bytes long
0A 58 00 00 00 9E -repeat

The structure of message is as
[05]first byte recieving module ID
[5F]second byte length
[00..01]message data
[BE]checksum of message

Decoding the 10 byte length message will get you want you need.
I bin disassembly might get the decoding pretty fast than trying to reverse the datastream.

i guess one question is does the dash even care about that initial broadcast message to go into some kind of receiving mode, or is it a simple device unaware of anything but 0A messages..? never really thought about that part of how aldl slaves work. there must be a reason for announcing broadcast mode but i always assumed their comms logic was pretty simple

ahh so what it looks like it's actually doing is updating the dash with both messages. it uses the shorter message for updating RPM quickly and then periodically sends this longer message to update other parts of the dash. might want to handle both messages to update some other things on the dashboard

Code:

..PAGE ..HEAD02L ALDL NORMAL MESSAGE *F9MSG2* - MESSAGE ID = $05 - MESSAGE LENGTH = $5F - 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 IPMW8 MODE WORD FOR INSTRUMENT PANEL 0 NOT USED 1 1 = FUEL SYSTEM DISABLED BY VATS 2 NOT USED 3 1 = MALF 24 DETECTED 4 NOT USED 5 1 = LOW COOLANT 6 1 = MALF 14 OR 15 DETECTED 7 NOT USED 3 FILTMPH VEHICLE SPEED MPH = N 4 KREDLINE REDLINE RPM RPM = N*100 5 ADBAT BATTERY VOLTAGE VOLTS = N/10 6 ACUMFUEL ACCUMULATED FUEL FOR DRIVER DISPLAY (MSB) 7 ACUMFUEL+1 ACCUMULATED FUEL FOR DRIVER DISPLAY (LSB) MSEC = (MSB*256 + LSB)/65.536 8 KDISF SINGLE INJECTOR FLOW RATE IN GALLONS/HOUR (MSB) 9 KDISF+1 SINGLE INJECTOR FLOW RATE IN GALLONS/HOUR (LSB) G/H = (MSB*256 + LSB)/6144 10 COOLDEGA COOLANT TEMPERATURE DEG C = N*.75 - 40 - CHECKSUM

alternatively if the car had a second display unit somewhere for driver warning messages, maybe the second message was exclusively for that module?

The tachometer is the only part of the panel that is controlled by the ALDL stream. All other gauges and lights on the panel are handled by the "traditional" method. That's why I made my initial test as only that one short message block. The $05 $5F message includes the redline, which I will want to use also so I'll be including that in the final code. And yes, there is an optional Driver Information System that displays things like fuel efficiency, which I presume it gets the data for from that $05 $5F message, and also a HUD that projects messages onto the windshield. If I ever get either of those options, now I'll know how to make them work!

Regarding the delay, I thought that making sure the write buffer had space would slow it down. Is that not the case?

0A 58 00 00 00 9E message is also streamed on an 94 f-body. The first 2 bytes are some 16 bits rpm derived and the third is empty.
F-bodies got only abs and sir modules on the line. Abs message is with id $91 so $0A could be targeted only to SIR module.

With eehack raw mode you can send fake aldl message and see how the dash reacts to them.

It is very likely that the obd2 pcm can stream aldl data. Gm keep the aldl modules upto 2002+ year and most of the newer pcms stream data on the aldl to integrate with the older modules. Do you have the p/n of the pcm.

There is no sir module on the international cutlass. The logs that you have are made by a 92 pcm? It is very likely the dash you have to use different pcm message from an ealier model pcm.

Quote:

Originally Posted by kur4o

It is very likely that the obd2 pcm can stream aldl data. Gm keep the aldl modules upto 2002+ year and most of the newer pcms stream data on the aldl to integrate with the older modules. Do you have the p/n of the pcm.

It's a 2004 PCM. The service number is 12583827

1 Attachment(s)

Got the Arduino this morning, uploaded the code, plugged it in:

https://s3.amazonaws.com/Quaraxkad/C...210_162010.jpg

That dashboard is sick.
The 2004 pcm is not likely to have built in aldl line. Hacking that is another topic.
However it will stream rpm data over obd2. It uses VPW protocol.

Why not just make a vpw -> aldl transciever.

VPW, that's the Class 2 stream, right? I was looking into that as a possible source of input to get the RPM signal.

But first, I think I may have a math problem in the code above... I attached a pot to use for input, and I get a whole sweep from 0 to 7000, but it happens in large chunks rather than one segment at a time. Almost like it's only reading the MSB.

Code:

int potPin = 2; int potVal = 0; void setup() { Serial.begin(8192); } void loop() { delay(100); if (Serial.availableForWrite() > 5) { potVal = analogRead(potPin) * 7; int rpm = potVal; byte msb = floor(rpm / 256); byte lsb = rpm % 256; byte b[5] = {0x0A, 0x58, 0x00, 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); } }

I added the longer delay so I could see the onboard TX LED flashing, too short a delay and it just looks like it's *on*. The potentiometer input should be 0-1023, so multiplying that by 7 gives me something closer to my 0-7000 gauge. Am I calculating the lsb correctly?

The whole conversion might be wrong

Code:

ldd #$168 RESERVED:90BF ldx word_1C3 minorloop reference RESERVED:90C2 fdiv RESERVED:90C3 cpx #$168 RESERVED:90C6 bhi loc_90CB RESERVED:90C8 ldx #0 RESERVED:90CB RESERVED:90CB loc_90CB: ; CODE XREF: BYTE_d1_SOME_SPEEDO_RELsub_8FEB+DBj RESERVED:90CB stx word_1B26 RESERVED:90CE xgdx RESERVED:90CF lsrd RESERVED:90D0 lsrd RESERVED:90D1 lsrd RESERVED:90D2 adcb #0 RESERVED:90D4 adca #0 RESERVED:90D6 std word_15D streamed word

This is the pcm calculation from 94 pcm $0A 58 message. It is some kind of high res rpm, but time based than revolution based.

To get a better picture of the dash conversion start dumping 0a 58 xx xx xx messages with raw mode in eehack program and look how it is interpreted by the dash.

It could also be

Quote:

byte b[5] = {0x0A, 0x58, msb, lsb, 0x00};

I tried manually setting numbers for all three values after 0x58 one at a time, and the second one is the only one that causes the gauge to respond. Even if my MSB and LSB calculation is correct, the LSB doesn't do anything! I can *not* imagine that's how the gauge works with only ~27 steps between 0 and 7000.

I could play with eehack, but that's just another thing I don't understand and would have to learn how to wire up and use...

Success! I changed my code to this and got a smooth sweep from 500 up...

Code:

byte msb = 0; byte lsb = 0; void setup() { Serial.begin(8192); } void loop() { delay(10); lsb++; if (lsb > 254) { msb++; lsb = 0; } byte b2[5] = {0x0A, 0x58, 0x00, msb, lsb}; unsigned int x = 0, sum = 0; for (x = 0; x < sizeof(b2); x++) sum += b2[x]; byte cs2 = ( 256 - ( sum % 256 ) ); Serial.write(b2, 5); Serial.write(cs2); }

Now to figure out what I was doing wrong to begin with. It's gotta be the LSB math?

it worked already!?
that byte order thing always screws me around too.
the uno int is 16 bit so you can probably just cast it.

b2[3] = (unsigned int)rpm;

Something is weird here... I had the cluster out of the car because I was tired of walking back and forth to the garage for every tiny code change... That's when I got the smooth sweep. The gauge starts at 600, increases by one segment up to 3000, then two segments the rest of the way to 7000. I thought I was done with the precariously alligator-clipped bench setup, so I put it back in the car, may or may not have made changes to the code, can't remember... And now we're back to 5-7 segment chunks instead of 1-2. I'm finished fiddling for the day. Here's where I ended:

Code:

int rpm = 0; void setup() { Serial.begin(8192); } uint8_t get_cs(uint8_t *barray) { int x = 0; int sum = 0; int len = *(&barray + 1) - barray; for (x = 0; x < len; x++) sum += barray[x]; return ( 256 - ( sum % 256 ) ); } void loop() { if (Serial.availableForWrite() > 0) { delay(10); rpm++; uint8_t msb = (byte)((rpm >> 8) & 0xFFu); uint8_t lsb = (byte)(rpm & 0xFFu); //byte msg1[12] = {0x05, 0x5F, 0x00, 0x20, 0x00, 0x3C, 0x80, 0x00, 0x00, 0x02, 0x00, 0x01}; //byte msg1_cs = get_cs(msg1); uint8_t msg2[5] = {0x0A, 0x58, 0x00, msb, lsb}; uint8_t msg2_cs = get_cs(msg2); //byte msg3[4] = {0xF0, 0x56, 0xF4, 0xC6}; Serial.write(msg2, 5); Serial.write(msg2_cs); } }

i don't think this is working code:

Code:

int len = *(&barray + 1) - barray;

you could use the length byte in the datastream message itself

Code:

int len = barray[1] - 0x51;

I wasn't sure if sizeof(barray) was working, so I found that with a google search... Most of this code is copy/pasted from google searches. I don't really understand c-like syntax, I'm a VB.net programmer! Anyway, I got it working again with a potentiometer input, I can control the display perfectly.

Code:

void setup() { Serial.begin(8192); } void loop() { delay(10); int rpm = analogRead(2) * 7; byte msb = ((rpm >> 8) & 0xFFu); byte lsb = (rpm & 0xFFu); byte b2[5] = {0x0A, 0x58, 0x00, msb, lsb}; unsigned int x = 0, sum = 0; for (x = 0; x < sizeof(b2); x++) sum += b2[x]; byte cs2 = ( 256 - ( sum % 256 ) ); Serial.write(b2, 5); Serial.write(cs2); }

Now comes the part I will definitely need help with: finding a tachometer input source. The car this PCM came out of (04 Impala) sends a Class 2 signal to its gauge cluster for the tach. Is that a viable RPM source? Would I have to code an entire OBDII interface system to use it?

totally viable. it would be a bit of a pain from the ground up and you'd need to build some hardware

other people have already made solutions for that: https://freematics.com/store/index.p...&product_id=83

it has an api

Code:

int value; obd.read(PID_RPM, value);

40 bucks, though, and all the extra hardware, doesn't seem very elegant.

personally i'd get an input connected to maybe the coil trigger wire or even the crank or cam sensor, then sample it.

that's what i did when i needed to tap a VSS sensor to make the speedo interface for my bike.

you could even do inductive pickup if you wanted to, i think an optocoupler and a simple coil would suffice? never tried but then your arduino could take the rpm of anything that sparks, given the number of hits per engine revolution, which means your project could be re-used by anyone that possesses this dashboard and has swapped ECMs.

there are lots of ways to do it on the software end

i personally used the analog input as my signal ended up being a bit too noisy for the digital input to be reliable, and did my own sampling. the logic i used was kind of like this,

if pin is low, and voltage above (switching point + x), pin is high
if pin is high, and voltage below (switching point - x), pin is low

you can then tune x to a sufficiently large threshold to filter any noise around the switch point

then you just need to determine how many milliseconds have passed between switch events to derive the frequency of the input.

there's the millis() function that returns an always increasing counter, so you can just have a millis_at_last_switch variable, then subtract current millis() to get the elapsed time since the last event.

I feel like using a full-fledged OBD protocol is a bit overkill... Seems like a short term diagnostic thing rather than something that's supposed to be in use all the time. But... I don't really know anything about electronics beyond the basic voltage, ground, resistance! If I were to tie into a signal wire at the ICM, should I get an oscilloscope to measure what it's putting out? And what kind of circuitry would I need to protect the Arduino? Surely I can't just hook anything straight up to it, too much voltage or a spike would fry the thing.

thats the fun of a project like this

google pull up and pull down circuits

they are 100% required knowledge for making an arduino do anything fun

circuit isolation is easy too just look at optocouplers

Time to resume this project! I moved, and am now settled into the new house. After some thought, I realized that the stock cluster already has a "regular" tachometer signal, so I've already got the wiring in place for it. After comparing all three service manuals (04 Impala engine, 98 Lumina engine harness, 92 Cutlass interior/instrument panel harness), I discovered that my ICM is already outputting an engine speed signal on pin E, which goes through the engine harness to the firewall connector, and from the firewall straight to pin 2 of my stock instrument panel connector which remains unused because I re-pinned the cables using the digital cluster connector and left the spares pinned in the old connector. For some reason I thought I was going to have to run new wiring from either the ICM or the PCM into the cabin.

I bought a cheap-o oscilloscope and attached it to that wire and ground:

https://s3.amazonaws.com/Quaraxkad/C...1455_clip.webm

So I've confirmed I have a valid source signal for engine speed. Now how do I determine how many pulses per second is X RPM? I have no idea how to read an oscilloscope! I should be able to plug this wire straight into my Arduino and the code I posted above will do the conversion to a simulated ALDL stream.

EDIT: Perhaps this is the code I need? https://github.com/deepsyx/arduino-t...aster/code.cpp. Instead of calling the setLedState function, I would use my own function from the code above to take the integer RPM value, convert to ALDL, and output to serial. Could it be that easy?

It seems I have completely forgotten how to get even my initial test working! I have no idea what pins are supposed to be connected to what...

It works!

Using this code:

Code:

volatile int iSparkCounter = 0; const int SPARK_PULSE_IN_PIN = 2; const int UPDATE_INTERVAL = 200; unsigned long lLastUpdate = 0; void incrementSparkCount () { iSparkCounter++; } void setup() { pinMode(SPARK_PULSE_IN_PIN, INPUT_PULLUP); attachInterrupt(digitalPinToInterrupt(SPARK_PULSE_IN_PIN), incrementSparkCount, RISING); Serial.begin(8192); } void loop() { if ((millis() - lLastUpdate) > UPDATE_INTERVAL) { int iRPM = (iSparkCounter * (1000 / UPDATE_INTERVAL) * 60) / 3; byte bMSB = ((iRPM >> 8) & 0xFFu); byte bLSB = (iRPM & 0xFFu); byte bStream[5] = {0x0A, 0x58, 0x00, bMSB, bLSB}; unsigned int i = 0; unsigned int iT = 0; for (i = 0; i < sizeof(bStream); i++) iT += bStream[i]; byte bChecksum = ( 256 - ( iT % 256 ) ); Serial.write(bStream, sizeof(bStream)); Serial.write(bChecksum); iSparkCounter = 0; lLastUpdate = millis(); } }

I got the following result:
https://s3.amazonaws.com/Quaraxkad/C...24_222755.webm

I should be able to get a faster response by reducing the update_interval value. And I can add a second ALDL message string that includes the fuel cutoff (stock is 5950), which will add a red line on the outer ring of the tachometer.

It's late enough tonight that I don't want to floor it and piss off the neighbors, so I'll do a more thorough test tomorrow. Idle speed is roughly 750rpm, confirmed with OBDII scanner, so that checks out. We'll see what happens on the drive to work tomorrow morning. Then the next step will be assembling a circuit board with an optocoupler isolation and power input (it's currently battery powered), packing it into a nice neat box with connectors to plug in where needed, and finding a place to mount it.

I did already notice one quirk though... I tapped the horn and the tach shot up to 7000RPM!