In article <s...@ip70-176-155-130.ph.ph.cox.net>, AZ 
Nomad says...
> 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.

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
** Posted from http://www.teranews.com **

AZ Nomad wrote:
> 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.
> 
Right.  Which is why you want to count the interval between pulses.

-- 

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

AZ Nomad wrote:
> 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.

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?
> 
> Another solution I've seen is to use a PLL frequency multiplier. :-)
> 
Which would have to have a bandwidth much narrower than the lowest 
expected pulse rate, which would lead to...

-- 

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

Tim Wescott wrote:
> 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.
> 

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.


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

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.

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Tim Wescott wrote:
> AZ Nomad wrote:
>> 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.
> 
> 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?


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 
18000rpm the timer would have to run at almost 20MHz. Not every uC can 
do that. Then again, most 16-bit ADC don't hold their water when they 
are on the chip. AVG plus dual-slope can though.

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.

[...]

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

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

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

Joerg wrote:
> Tim Wescott wrote:
> > 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.
> >
>
> 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.

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ò:

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

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

-- 
emboliaschizoide.splinder.com

Imprecavo contro il nuovissimo ordinamento quando m...@mojaveg.nodomain 
(Everett M. Greene) ha detto :

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

18000(rpm) / 60 (seconds) * 4 (number of cylinders) / 2 (revolutions for a 
spark)

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

Imprecavo contro il nuovissimo ordinamento quando rickman 
<g...@gmail.com> ha detto :

> it should be a simple matter to
> count the number of pulses that happen in 1/100th of a minute or 0.6
> seconds

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

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