BlindAssassin111:
I just left the “-1” there to be the baseline for 1 pulse, I will change it if what I thought about the number of pulses increasing frequency is correct.
You mean the -1 in …
rpm = ( numPulses < 2) ? 0 : ( 60 * 1000000.0 * (float)(numPulses - 1) ) / (float)( lastPulseTime - firstPulseTime );
That’s correct and independent of the number of pulses/rev. The ‘timings’ record the 1’st and last pulse times and so if there’s 1 pulse/rev what those times mean can be thought of this way;
-
the number of pulses is set/reset = 0.
-
the 1’st pulse comes in and it’s time of arrival is recorded. Pulse count now = 1.
-
the second pulse comes in and signals the end of the 1’st rev, start of the 2’nd rev. Pulse count is now 2 but there’s only been 1 revolution and the ISR has recorded it’s start and stop times, aka it’s period (= 1/frequency).
-
the third pulse comes in and now the pulse count = 3 and you have got 2 periods recorded, the start and the end times after 2 periods.
-
more and more (perhaps) pulses come in and you always have 1 pulse more than you have periods.
Now it comes time to use that data to compute the RPM. RPM = 60*frequency. The end time - the start time is the total time for N periods. Divide that total time by the number of periods (= pulse count -1) and you have an average period. Do a 1/(ave period) … and account for the fact that you measured in usecs … and you’ve got frequency of pulses (pulses/second). Multiply by 60 to get pulses/minute = RPM. Now if you double or quadruple the pulses per rev then the above will yield an RPM that’s 2x or 4x too high. So the -1 stays and, perhaps, an additional division will be needed to get true RPM.
At least that’s my thinking. :twisted: