Sorry if this is a stupid question (most probably is!) but I'm not quite sure how to tackle this challenge.
Ok, a bit of background on the project. I do allot of engine conversions in many different vehicles, problem is usually getting the tachometer to work. On the newer vehicles with CAN it's a pain in the but! I have hacked open many instrument clusters and used L293D's and Atmega 328's to drive the air cores, but that takes way too much time and fiddling to get it just right.
So I thought why not just send a signal to the original ECU CAS input which in turn would operate the tach! The CAS reads a toothed gear attached to the crankshaft which is in turn read by the ECU. These gears comes in a wide variety of tooth combinations like 36-1, 36-2, 60-2 etc. 36-1 meaning a total of 35 teeth with the 36th one missing to determine engine position.
So what I would like to do is build a "CAS (crank angle sensor) adapter" that receives a variable frequency from the new aftermarket ecu, anything from 1 to 60 pulses per engine revolution. All the adapter has to do is count the pulses while also toggling another pin High and Low to simulate the gear pattern.
So for example on a 36-1 setup it would have to read a pin and while reading that pin toggle an output high and low for 35 times, mirroring the input pin, pause the output for the last incoming pulse to simulate the missing tooth and then start over!
I hope this makes sense to all you smart people out there!
Any and all suggestions welcome!!!
I'm not sure I entirely understand what you're trying to achieve.
So you have your missing tooth CAS signal (Eg a 36-1 or something) being fed into the aftermarket ECU, but the aftermarket ECU can't output the CAN signal required to drive the OEM tacho. You want to retain the original ECU and have it driving the tacho instead, but not doing anything else. Is that right?
If that is the case, why not just feed the CAS signal into both the aftermarket ECU and the original ECU in parallel? This should work either with hall sensors or VR and the two won't interfere with each other (remembering that if it's a hall sensor, you won't need the pullup on the aftermarket ECU as there will be one on the original ECU to do that)
I can't see a need for the arduino if all you're wanting to do is have the same CAS signal going into 2 ECUs.
There's a lot of these units around. I'm surprised you haven't come across them since you're obviously in that line of business. They're usually called a "speedo corrector" as the speedometer is the primary instrument that needs correction in many conversions.
Here's one: Speedo Corrector Module | Jaycar US Site
Hi thanks for the replies!
Noisymime your solution sounds good, but the problem is the engines we fit crank gear patterns rarely match the cars original crank gear pattern. For example we fit an engine with a 36-1 gear into a car that used a 60-2 setup. The other problem is most cars that uses a VR sensor use ground as the reference voltage and the aftermarket ECU uses a 5 volt reference voltage. So no go unless you use extra hardware and then we still have a problem if the gears don't match up.
MorganS I have seen those units, but I love DIY and I love saving money even more!
Ahhh gotcha, I understand now. I missed that you need to translate from one count of teeth to another.
Certainly this is possible. If it was me, I'd be starting with an existing sketch called ArduStim: LibreEMS Suite / ardu-stim · GitLab
This can output pulses in MANY different patterns, including 36-1 and 60-2. It would be relatively straightforward to rip out all the serial code from it and simply set the rpm in it based on the pulses you're receiving on another pin. As far as reading the input rpm goes, here is a missing tooth reader that I've written: https://github.com/noisymime/speeduino/blob/master/decoders.ino#L36
You add an external interrupt that calls triggerPri_missingTooth() whenever the input goes high or low, then simply call getRPM_missingTooth() whenever you want to know the current RPM. You'll need to muck around a little with the variables that you need, but the logic behind that missing tooth detection is well tested and very fast.
Noisymime thank you!
I will have a look at it tonight, but your plan seems spot on! Will let you know how I get on.