Best solution to count RPM

Option 1. For sure. This is what the the timer capture pins are for. It will be far more accurate and use less hardware and less CPU resources than your other option.

If your processor has a timer capture function, run the crank sensor to the timer capture. If your processor doesn't have a timer capture function then consider another processor, or the cost of implementing a timer capture in external logic.

I rarely find that going from digital to analog and back to digital is 'clean' in the least.

Un bel giorno N1 digitò:

Professional/decent systems use the solution 1. Often you can set up how many teeth to count before calculating the RPM; this is useful with phonic wheels with a missing or an asymmetric tooth, which is usual.

No. Solution 2 is sometimes the lesser evil (for example when you have to pick the RPMs directly from the spark cable) but when you have a phonic wheel to use, there is no reason to do that.

I don't see how doing pulse->freq->A/D is "cleaner" than just simply counting the pulses.

If you examine the mathematics, you'll find the operations are not the best for producing a well-behaved output. It is no worse than any other velocity measurement, but it's no better. You are taking a count (n) and dividing by a time period (dt) and producing a frequency (f). Since dt is quite small, you are in effect multiplying by a quite large number (1 / dt). The accuracy is a function of the accuracy of the dt measurement.

You need to check your arithmetic -- 18000 RPM is 300 Hz. for a 1 pulse per revolution signal.

Depending on the intended use of the RPM number, 100 RPM is quite good enough resolution for a human user display. A five-digit display would have the lower two digits dancing around so much as to be unreadable at any reasonable display refresh rate. Also, as with any velocity measure- ment, the RPM value is a reading of what the elapsed time was for the previous period and is not necessarily a good indication of what the value is now or will be in the near future.

I give up. What does "phonic" mean? All I could find was something to do with audio which didn't sound right to me (sorry, couldn't resist :-). And I assume it wasn't a typo since you used it twice.

Alan Nishioka

Just count the pulses. It requires the application programmers to write a utility function to turn the counter value into RPM but they have have raw data and can do whatever they like, inclusive control over the averaging/lag ect. If you first go from pulse to voltage and then A/D the result back into a CPU you'll introduce some kind of lag that can't be compensated. That might be ok for most applications but why do it in the first place?

Wrap-arounds on your pulse-counter can be detected. Time can be measured ect.

Please - give the software guys all the freedom possible. I'm a software guy and I don't mind writing some lines of code if I can decide how I'd like to have latency and all.

Nils

Counting pulses can lead to very long sample times at low rpms if more than a digit or two of precision is desired.

I know. But tell me how a Frequency to Voltage converter can increase the precision?

Nils

if you measure the pulse width instead, you don't run into long sample times at low rpms.

Another solution I've seen is to use a PLL frequency multiplier. :-)

That depends on just how long the pulse is.

If you end up in that situation though you probably need to take another look at the sensor.

Robert

Right. Which is why you want to count the interval between pulses.

Which is not how most F to V converters work -- do you have a suggested part number for a chip that does work this way? And why is it better than using a digital timer?

Which would have to have a bandwidth much narrower than the lowest expected pulse rate, which would lead to...

Yes, I'd second that. But it may need a lot of averaging since the trigger point will flop around a bit in the usual engine environment.

Coincidentally that was exactly what I was working on this morning. Not my design, just had to find out what caused field problems. Turned out the circuitry worked rather nicely and it was the sensors causing some grief but that's history now. This was an older uC and it wouldn't be able to stomach another routine plus timer so they did the double conversion. Not sure if it even has a timer.

It can be, but only if the input signal is of very low jitter, IOW "worth" the increased precision. And only if the ADC resolution dwarfs the timer resolution. For example, for a full 16-bit resolution at

F/V and V/F chips can be remarkably precise in short term resolution but not in absolute precision. It all depends what you want to measure, short micro-trends or absolute.

That's fairly low target. If you need higher precision, and wide dynamic range, then a reciprocal frequecy counter will give you that. Not all uC cope with reciprocal frequecy counter designs.

If you want 3Hz LSB, and 600Hz FullScale, then a 1/3 second tick will give 200 counts in that time. A simple 8 bit counter, read 3 times a second will do that.

If the 1/3s is too slow for your requirements, you can flip to measuring time : Now your Max RPM is the coarsest resolution, but at 600Hz, you need better than ~8.37us timer LSB, and a 16 bit timer (~39801) will resolve down to the same 3rpm of the 8 bit counter. The uC need to do an inversion, to get RPM from period.

-jg

I'm not sure why people are suggesting that the period between pulses be measured and then perform a divide operation to calculate the RPM. If you only want accuracy to 100 RPM, it should be a simple matter to count the number of pulses that happen in 1/100th of a minute or 0.6 seconds. This count will be the number of RPM in hundreds. If you count for 1.2 seconds you will get the measurement accurate to 50 RPM which is typically about the level of accuracy used in RPM readings, especially at the low end(750 or 1250 RPM for example).

This can even be done in a very, very simple MCU without a counter function. With a max pulse rate of 300 Hz, an interrupt could be used or even polling! A simple timer loop can count machine cycles to establish the time base and polling the pulse input in that same loop will give you the pulse count. If you want to get fancy, you can even perform debounce or spike rejection to help exclude noise. A hardware counter would have a lot more difficulty with that.

A very small and simple processor can do this job easily and cheaply.

Rick

Un bel giorno Alan Nishioka digitò:

It's just a gear mounted on a shaft (for example the engine cam/crank shaft for the ECU, or the wheels for the ABS). Usually it's made of a ferromagnetic material, so that you can detect the passage of each tooth by using an inductive sensor or a hall sensor.

I have absolutely no idea why it's called "phonic" wheel. :)

Imprecavo contro il nuovissimo ordinamento quando snipped-for-privacy@mojaveg.nodomain (Everett M. Greene) ha detto :

Imprecavo contro il nuovissimo ordinamento quando rickman ha detto :

Because in this way you'd have an update every 0.6s and it's enough for almost every application.