if (RPM < 7000)
module1.setDisplayToDecNumber(RPM,0, false); //Display RPM on TM1638
Hmm... This might be a minor thing, but why is there an conditional statement on the display command? You already are already imposing an upper limit of 9000 RPM by discarding pulses shorter than 3378 ?s due to your logic during the pulse detection. As currently written the code counts the pulses that indicate an RPM of 7000 to 8999 valid inputs but won't output these corresponding values to your display.
module1.setDisplayToDecNumber(RPM,0, false); //Display RPM on TM1638
Hmm... This might be a minor thing, but why is there an conditional statement on the display command? You already are already imposing an upper limit of 9000 RPM by discarding pulses shorter than 3378 ?s due to your logic during the pulse detection. As currently written the code counts the pulses that indicate an RPM of 7000 to 8999 valid inputs but won't output these corresponding values to your display.
Yeah I noticed that already.
Changed it to match with pulses shorter than 4292 ?s (aka 7000rpm)
Any ideas to further filter the signal with hardware, so I can actually use the time between pulses that pulseIn gives me?
It would make for a more accurate display.
I plan on building some limited engine management off of this system, so accuracy is important.
Using one of the plug wires or the wire directly into the ignition coil could work some ignition coils have a plug for a tach even though the car didn't come with a tach. If you measure off of the plug wire you'll be measuring on the voltage peaks but if your going off the coil power you'll be measuring on the voltage drops.
Panici:
Any ideas to further filter the signal with hardware, so I can actually use the time between pulses that pulseIn gives me?
It would make for a more accurate display.
The way you are using pulseIn() is giving you the length of the tach pulse, which is the main information you need. However, if you want work with the time inbetween pulses you could have a separate timer that is reset everytime a pulse is read (I wouldn't use another pulseIn() because of the way it delays the rest of the sketch).
As far as a hardware filter you'd want either a low pass (set just above the frequency you are limiting to in the sketch) or a band pass filter (with the low end of the band being the frequency correlating to under 1 RPM or whatever minimum value you are interested in), and a passive first-order implementation could be sufficient.
PeterH:
Firstly, if you're using an MVR sensor the signal amplitude will be proportional to speed.
Not using a seperate MVR sensor. Using the tachometer pulse supplied to the gauge cluster.
Please read the first part of this thread for details. I 'scoped the tach pulse as well.
Signal frequency is proportional to RPM here.
Have you obtained a clean square wave at TTL levels, or are you still trying to clean up the signal in software?
Far-seeker:
The way you are using pulseIn() is giving you the length of the tach pulse, which is the main information you need. However, if you want work with the time inbetween pulses you could have a separate timer that is reset everytime a pulse is read (I wouldn't use another pulseIn() because of the way it delays the rest of the sketch).
As far as a hardware filter you'd want either a low pass (set just above the frequency you are limiting to in the sketch) or a band pass filter (with the low end of the band being the frequency correlating to under 1 RPM or whatever minimum value you are interested in), and a passive first-order implementation could be sufficient.
Ah, I meant to say the length of the pulse.
Actually right now i'm not using that for my calculations. I'm just counting how many pulses per 200ms.
PeterH:
Have you obtained a clean square wave at TTL levels, or are you still trying to clean up the signal in software?
I don't have access to a 'scope anymore, so I don't know how my waveform looks right now. I'm using the circuit purposed earlier in this thread by dc42:
(but with the addition of a diode between the tach signal and resistor.
dc42:
I'd use a small signal NPN transistor. Connect emitter to ground, collector to the Arduino pin (configured as an input with pullup resistor enabled), and base to the tach signal through a 100K resistor. The resistor will protect the transistor from the positive going spike, also from any excessive negative-going voltage (although from your scope trace it looks like it only goes to -2V, which is insufficient to cause the emitter-base junction to avalanche anyway).
Panici:
Ah, I meant to say the length of the pulse.
Actually right now i'm not using that for my calculations. I'm just counting how many pulses per 200ms.
Alright, if you want to use the length of the pulse directly there are at least a couple different ways to do it. First, you can do a direct calcuation using the value in the pulse variable. Second, since each pulse length corresponds to one RPM value in a linear fashion it would be possible to do the math ahead of time to figure what pulse length correlates to the nearest integer value of RPM. Then just use the map() function to convert pulse right after reading it.
Psuedo code example as follows (you would have to use of course have exact numbers or constant/variable names where I have bracketed labels)...
RPM = map(pulse, , , , );
Mapping the value can be faster and use less space than conversions through direct calculation, but in this specific case might not yield a significant improvement.
Panici:
Actually right now i'm not using that for my calculations. I'm just counting how many pulses per 200ms.
That sounds far more practical and less error prone.
I don't know how you proposed to count the pulses, but I suggest the simplest way is to poll the input in loop() and the next simplest is to attach an interrupt and have the handler increment a counter which is read and reset periodically by the loop(). I wouldn't view pulseIn() as a good way to count pulses since it may consume two pulses depending on timing.