I'm working on a data acquisition system for byke/car engine.
I'm trying to figure out which would be the best way to count RPM and 
I've thought to two different ways:
1- using an interrupt routine attached to a digital input to count, say, 
10 revolution and then look how much time passed between the first and 
the tenth to figure out ho many would they be in a minute.
2- using an IC to transform frequency to voltage and then read it from an 
analog input.

I think that solution 2 is better and cleaner but I'd like to keep 
everything on the same board. On the other side I don't know if the 
solution 1 would be accurate enough.

Max value would be 18000rpm that is 600hz for a 4 cylinder, 4 stroke 
engine...pretty low for most MCU. It'd be ok to have a resolution of 
100rpm (3HZ). 

-- 
Nuno on zx-6r '04 & CRe 250 '99 working in progress...
La riforma della scuola è pronta
dieci casse Marshall dentro ogni aula
*** www.gladio.org ***

N1 wrote:
> I'm working on a data acquisition system for byke/car engine.
> I'm trying to figure out which would be the best way to count RPM and 
> I've thought to two different ways:
> 1- using an interrupt routine attached to a digital input to count, say, 
> 10 revolution and then look how much time passed between the first and 
> the tenth to figure out ho many would they be in a minute.
> 2- using an IC to transform frequency to voltage and then read it from an 
> analog input.
> 
> I think that solution 2 is better and cleaner but I'd like to keep 
> everything on the same board. On the other side I don't know if the 
> solution 1 would be accurate enough.
> 
> Max value would be 18000rpm that is 600hz for a 4 cylinder, 4 stroke 
> engine...pretty low for most MCU. It'd be ok to have a resolution of 
> 100rpm (3HZ). 
> 

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.

</A>

N1 wrote:
> I'm working on a data acquisition system for byke/car engine.
> I'm trying to figure out which would be the best way to count RPM and 
> I've thought to two different ways:
> 1- using an interrupt routine attached to a digital input to count, say, 
> 10 revolution and then look how much time passed between the first and 
> the tenth to figure out ho many would they be in a minute.
> 2- using an IC to transform frequency to voltage and then read it from an 
> analog input.
> 
> I think that solution 2 is better and cleaner but I'd like to keep 
> everything on the same board. On the other side I don't know if the 
> solution 1 would be accurate enough.
> 
> Max value would be 18000rpm that is 600hz for a 4 cylinder, 4 stroke 
> engine...pretty low for most MCU. It'd be ok to have a resolution of 
> 100rpm (3HZ). 
> 
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.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html

Un bel giorno N1 digitò:

> 1- using an interrupt routine attached to a digital input to count, say, 
> 10 revolution and then look how much time passed between the first and 
> the tenth to figure out ho many would they be in a minute.
> 2- using an IC to transform frequency to voltage and then read it from an 
> analog input.

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.

> I think that solution 2 is better and cleaner

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.

-- 
emboliaschizoide.splinder.com

N1 <i...@me.it> writes:
> I'm working on a data acquisition system for byke/car engine.
> I'm trying to figure out which would be the best way to count RPM and 
> I've thought to two different ways:

> 1- using an interrupt routine attached to a digital input to count, say, 
> 10 revolution and then look how much time passed between the first and 
> the tenth to figure out ho many would they be in a minute.

> 2- using an IC to transform frequency to voltage and then read it from an 
> analog input.
> 
> I think that solution 2 is better and cleaner but I'd like to keep 
> everything on the same board.

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

> On the other side I don't know if the solution 1 would be accurate
> enough.

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.

> Max value would be 18000rpm that is 600hz for a 4 cylinder, 4 stroke 
> engine...pretty low for most MCU. It'd be ok to have a resolution of 
> 100rpm (3HZ). 

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.

On Aug 4, 10:32 am, dalai lamah <antonio12...@hotmail.com> wrote:
> 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.

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

N1 wrote:
> I'm working on a data acquisition system for byke/car engine.

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

On Mon, 04 Aug 2008 23:21:52 +0200, Nils <n...@cubic.org> wrote:
>N1 wrote:
>> I'm working on a data acquisition system for byke/car engine.

>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.

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

AZ Nomad wrote:

> 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

On Tue, 05 Aug 2008 00:09:12 +0200, Nils <n...@cubic.org> wrote:
>AZ Nomad wrote:

>> 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?

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. :-)