Arduino ...

[BertieWells]

@IanandLins, taking a signal from the lead coming from the coil to the dizzy would potentially work. If you are indeed getting 2 sparks per plug per revolution then you would see 8 spikes per revolution onthis lead (i think). The longer the time between spikes the more accurately i belive i would be able to calculate the RPM. So assuming you don't have a horrible missfire from the point of view of writing the code it would make more sence to take the signal from a single HT lead.

To elaborate assumeing you you have 1 revolution per second. On the "coil lead" you would have 8 spikes per second. In this case (1/8=125ms) As apposed to (1/2=500ms). To count a spike you need to "read" from a pin and the code has to be in position to wait for a spike. So the code might do something like this
if there is a spike then{
Take a note of the time (during this part of the code you can not detect another spike)
Add one to a counter (during this part of the code you can not detect another spike)

if the counter is equal to 8 then{
Calculate how long it took to do 1 rev (during this part of the code you can not detect another spike)
Calculate RPM (during this part of the code you can not detect another spike)
Print this to a display (during this part of the code you can not detect another spike)
}
}

So if you have 1 rps all that code has to run in 125ms so as not to miss a spike
in reality you might be running at 3000RPM
50 Revolutions per second
each revolution = 1/50 = 20ms
20/8 = 2.5ms to run the code
or
20/2 = 10ms to run the code

Having just worked that out it is still very very fast and i might have a rethink if this is the best way to aproach the counting ....

Let me know if i have donesomething stupid with my maths. Tobe honest i realy have no idea what the rev ranges of differnt engines are, isthere somewhere i can get this info?

[marlinowner]

Each plug sparks every other engine revolution, so the spike rate per plug per minute is half the rpm. On the coil ht lead its twice the rpm. So at 3000 rpm you have 40ms between spikes on a plug lead and 10ms on coil ht lead.

[BertieWells]

Completely right, thankyou! That makes it all seem much more manageable

[CJH]

If you are indeed getting 2 sparks per plug per revolution then you would see 8 spikes per revolution onthis lead

Other way round - you get one spark per plug per two revolutions (see here). So if you wrap a wire round a single plug lead you'll have to multiply the pulse rate by two to get rpm.

The king lead (coil to distributor) will run four times as fast (for a 4 cylinder engine) so you'll have to divide by two instead. I think the green low tension wire to the coil pulses at the same rate as the king lead - once per spark - but I don't know what the electrical characteristics of that pulse are. I believe it's more conventional to use this green wire for tacho connections. The factory tacho in later models uses this green wire, so if you were to develop a solution for this wire then owners of later vans wouldn't need to run a new wire from the engine bay.

I'd be inclined to just count the number of pulses per 100ms (so the update rate is 10Hz) and then scale accordingly - if you're counting pulses on the green wire then accumulate them for 100ms then multiply by 5 - i.e. multiply by 10 (1s/100ms) and divide by 2 (4 pulses per 2 revolutions).

E D I T: D'oh - beat me to it.

[BertieWells]

Haha no CJH you beat me to it. Just as i was writing my last post i was thinking "hang on it would be far better to count the number of pulses in a given time"

[CJH]

Haha no CJH you beat me to it. Just as i was writing my last post i was thinking "hang on it would be far better to count the number of pulses in a given time"

Yes - less to do per cycle I think. I've never coded for Arduino - can the counter be set up as an asynchronous event that does nothing except accumulate total pulses, so that you could set up a timer to go off and read the counter every 100ms? You'd then just have to subtract the value you read 100ms ago, and cope with jumps for every time the counter overflows.

[marlinowner]

The problem with counting pulses in a given time is the rpm accuracy. If you count over 100ms intervals, there are only three pulses from the coil at 1000rpm, rpm calculation could be 33% out (roughly, haven't calculated it). If you increase the sampling time to increase accuracy then responsiveness to changing rpm becomes unacceptable.

[CJH]

Good point - so accumulate over a longer period (say 1s - around 30 pulses) but update faster, say four times a second - means storing 4 values in the main code loop. So the accuracy improves (subject to how much the rpm has changed over a 1-second interval), but the lag increases.

So maybe timing the interval between pulses is better after all, maybe with a bit of smoothing.

[BertieWells]

It super simple ... a derivetive of C. It has the capability to call the time in milli or micro seconds the code has been running for. I think this rols over every 12 hours or 50 days depending which counter you are using so more than long enough.

If it were me id do something like this:

CodeForRPM.png

It could be a little more involved but you get the idea.

In terms of responsiveness my argument would be (in my bus atleast) im not seeing how fast i can get the revs of the engine to change for me once a second update time would be about my limit. But 1/5 second is still pretty quick or would you still consider this too slow?
So if we read off the king lead
1000RPM (lowest accuracy)
16.6 RPS
33.2 SPS
6.6 S/200Ms

I think this would work quite well no?

You could use running averages to increase accuracy. There would be a very slight delay (possibly unoticeable) when the revs are increasing/decreasing but when chugging along at constant speed the reading would be more accurate.

in terms of accuracy nothing on my van is accurate So maybe its not neccessary to go too crazy unless someone was to use this for diagnostics?

I guess alot of this would come down to personal preference. In which case it would be quite easy to change the refresh rate using a variable resistor or something similar.

Sorry for the ramble there

[CJH]

in terms of accuracy nothing on my van is accurate So maybe its not neccessary to go too crazy unless someone was to use this for diagnostics?

Good point! Maybe you make it bounce around by 20% or so (to match my speedo), or take a couple of minutes to reach a true reading (like my fuel gauge). Or maybe you could fit an accelerometer so it doesn't start working till you tap the display

[BertieWells]

Using that code i worked out i can
read a value on a pin
save it as a variable
go into an if statement dependant on that variable
Add 1 to a counter
come out of the if statement
Check the time

75 times in 200 ms

so if we say we should be able to check for a pulse every 40ms with out too much trouble that allows us too deal with engine speeds up to 6000 RPM which i think would be about acceptable.

[BertieWells]

Good point! Maybe you make it bounce around by 20% or so (to match my speedo), or take a couple of minutes to reach a true reading (like my fuel gauge). Or maybe you could fit an accelerometer so it doesn't start working till you tap the display

I was thinkng more of a sound sensor so you have to swear at it to get it going ... oh wait that wont work because its so bloody noisy in my cab xD

[discipleofsketch]

I was reading up on ways to get a pulse for RPM a while back, for a diesel - I found a website where someone had a sensor mounted in a hole drilled in the plastic cover over the crankshaft pulley, which had a white paint dot on it. Just had a quick search and couldn't find it, but that might be a potential solution for people with diesel engines if they wanted to play around with an Arduino tachometer?

[BertieWells]

I was thinking about this earlier. A small magnet on the crank pulley would work just as well. It would work like a bicycle speedo then. The reason i didnt mention it is because i aim to make something that would work for everyone with minimal installation hastle. Although it leaves diesel out of the question for now, wrapping a wire around an ht lead and splicing into a 12v supply somewhere is fairly straight forward. Reading off the crank pulley would indeed work but it could be a bit fiddely for people to setup? Im not sure

[discipleofsketch]

I was thinking about this earlier. A small magnet on the crank pulley would work just as well. It would work like a bicycle speedo then. The reason i didnt mention it is because i aim to make something that would work for everyone with minimal installation hastle. Although it leaves diesel out of the question for now, wrapping a wire around an ht lead and splicing into a 12v supply somewhere is fairly straight forward. Reading off the crank pulley would indeed work but it could be a bit fiddely for people to setup? Im not sure

Sure, don't get distracted by the diesel owners! I actually now have a feed from the ECU for RPM on my tdi conversion - not sure what type of signal it gives and how I would use it with an arduino.

I just did a bit of googling and found this guy has built an ecu for a tdi engine using an arduino

http://dmn.kuulalaakeri.org/dmn-edc/" onclick="window.open(this.href);return false;

Now that looks like fun!