Walter Banks 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).
> 
> Use period to measure low speed RPM and frequency to measure
> high speed RPM. That way you will get response and accuracy that
> you will need.
> 
> Most of the current engine controllers now are measuring the engine
> speed from the crank sensor 60 -2 or 36 -1 (60 index markers with
> 2 gaps for synching)
> 
> At low speeds the acceleration in an engine on firing can be impressive.
> 

Especially on motorcycles which the OP mentioned. Some of those can go 
from zero to 60mph or 100km/h in slightly over four seconds, revving the 
engine through several gears and up to 12000rpm peaks or higher. No idea 
how long an engine will last under that kind of stress but people do that.

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

N1 wrote:
> 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)
> 
Actually, this is not correct.  Let's assume that the sender (sensor) 
is the distributor high side, the number of firing pulses would be as 
you describe.  However, the engine is still revolving between pulses, 
so the older tachometers take this into account as many have to be set 
up for number of cylinders.

On the other hand, if the sender (sensor) is the flywheel home pulse, 
then you will get a pulse each revolution.

Either way, 6000 RPM means the engine revolved 6000 times in 1 minute, 
or 100 times in a second.  This is independent of firing pulses.

One of the best ways to create a tach. using a micro controller is to 
count 100 pulses, then see how long that took, then use a lookup table 
to determine the engine speed (MCHC11 for example -- used by many G.M. 
engine controllers up through 1998).

The number is actually an average because what is happening is a form 
of integration.  If you are looking for min and max RPM, then count 1 
pulse, get its time, etc.

Hope this helps.

Dave,

On Aug 5, 12:00 pm, Tim Wescott <t...@seemywebsite.com> wrote:
> rickman wrote:
> > 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
>
> 600ms wouldn't even be acceptable for a tachometer, it _certainly_
> wouldn't be acceptable for a tachometer so cheesy it could only show
> increments of 100RPM, and it just plain wouldn't work at all for a
> governor application or an electronic ignition system.

I don't follow your logic here.  Why would a 100 RPM resolution imply
that 0.6 sec update rate is not adequate?  Who said anything about an
electronic ignition or governor?  Actually the OP said he wanted it
for a data acquisition system in which case the requirements are very
different.  What is the update rate???  It may be that he is only
storing data on 1 sec increments or longer.

All techniques have some lag to them, no measurement is
instantaneous.  Without a spec on the measurement time, there is no
basis for saying that 0.6 sec is too long.


> Hence the suggestion that gives an answer with (hopefully) a usefully
> low delay.

And what delay would that be???

Rick

On Aug 5, 11:16 am, Joerg <notthisjoerg...@removethispacbell.net>
wrote:
> rickman wrote:
> > 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.
>
> Now how would that timer loop count precise machine cycles?

That would be an exercise for the student!  ;^)

Actually, are you serious that you don't know how to count machine
cycles in an MCU?  All of the small MCUs have deterministic timing.
So your code can be measured to have a loop delay of Mn + B where M
and B are constants and n is the repeat count for the loop.  For
sections of the code that have conditional branches, you can add fill
code (NOPs) to make the timing of each branch equal.  The loop checks
the input to see if it has toggled and if so, increments a counter in
memory or a register.  When n iterations of the loop have completed
the register is read to get the RPM, the value read is saved or
transmitted, the register is cleared and the loop started again.

I'm not saying that this is something you would put in an MCU that is
doing 10 things.  But a $1 MCU with some 8 pins could be dedicated to
this task and the code specifically designed for this.  This is likely
smaller, cheaper and lower power than many other solutions.  Depending
on the accuracy required, you might even be able to use an MCU with an
internal RC oscillator or a very low power, low cost 32 kHz crystal.

Rick

rickman wrote:
> On Aug 5, 11:16 am, Joerg <notthisjoerg...@removethispacbell.net>
> wrote:
>> rickman wrote:
>>> 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.
>> Now how would that timer loop count precise machine cycles?
> 
> That would be an exercise for the student!  ;^)
> 
> Actually, are you serious that you don't know how to count machine
> cycles in an MCU?  All of the small MCUs have deterministic timing.
> So your code can be measured to have a loop delay of Mn + B where M
> and B are constants and n is the repeat count for the loop.  For
> sections of the code that have conditional branches, you can add fill
> code (NOPs) to make the timing of each branch equal.  The loop checks
> the input to see if it has toggled and if so, increments a counter in
> memory or a register.  When n iterations of the loop have completed
> the register is read to get the RPM, the value read is saved or
> transmitted, the register is cleared and the loop started again.
> 
> I'm not saying that this is something you would put in an MCU that is
> doing 10 things.  But a $1 MCU with some 8 pins could be dedicated to
> this task and the code specifically designed for this.  This is likely
> smaller, cheaper and lower power than many other solutions.  Depending
> on the accuracy required, you might even be able to use an MCU with an
> internal RC oscillator or a very low power, low cost 32 kHz crystal.
> 

Sure I know but it would be rather wasteful to block a MCU for pretty 
much any other task that way. Typically in an application like this your 
MCU needs to also calculate the RPM value, maybe do red range alerting, 
package it nicely in a format some display understands and then send it 
out via a link to an HD44780 chip. Or directly to glass.

Using a timer would be the smart thing to do.

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

rickman wrote:
> On Aug 5, 12:00 pm, Tim Wescott <t...@seemywebsite.com> wrote:
>> rickman wrote:
>>> 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
>> 600ms wouldn't even be acceptable for a tachometer, it _certainly_
>> wouldn't be acceptable for a tachometer so cheesy it could only show
>> increments of 100RPM, and it just plain wouldn't work at all for a
>> governor application or an electronic ignition system.
> 
> I don't follow your logic here.  Why would a 100 RPM resolution imply
> that 0.6 sec update rate is not adequate?  Who said anything about an
> electronic ignition or governor?  Actually the OP said he wanted it
> for a data acquisition system in which case the requirements are very
> different.  What is the update rate???  It may be that he is only
> storing data on 1 sec increments or longer.
> 
> All techniques have some lag to them, no measurement is
> instantaneous.  Without a spec on the measurement time, there is no
> basis for saying that 0.6 sec is too long.
> 

The OP mentioned motorcycles and he is in Italy. Have you ever seen a 
Ducati or Moto Guzzi revv through several gears and go from zero to 
freeway speed in just a few seconds? Some guys won't even stay in one 
gear for 0.6 seconds.

> 
>> Hence the suggestion that gives an answer with (hopefully) a usefully
>> low delay.
> 
> And what delay would that be???
> 

Desire (or command) to fetch the value versus actually receiving the 
value. On a motorcycle 0.6sec is an eternity.

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

On Wed, 06 Aug 2008 11:13:01 -0700, in comp.arch.embedded Joerg
<n...@removethispacbell.net> wrote:

On a motorcycle 0.6sec is an eternity.

Especially when falling off at 80mph


martin

rickman wrote:
> On Aug 5, 12:00 pm, Tim Wescott <t...@seemywebsite.com> wrote:
>> rickman wrote:
>>> 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
>> 600ms wouldn't even be acceptable for a tachometer, it _certainly_
>> wouldn't be acceptable for a tachometer so cheesy it could only show
>> increments of 100RPM, and it just plain wouldn't work at all for a
>> governor application or an electronic ignition system.
> 
> I don't follow your logic here.  Why would a 100 RPM resolution imply
> that 0.6 sec update rate is not adequate?  Who said anything about an
> electronic ignition or governor?  Actually the OP said he wanted it
> for a data acquisition system in which case the requirements are very
> different.  What is the update rate???  It may be that he is only
> storing data on 1 sec increments or longer.
> 
> All techniques have some lag to them, no measurement is
> instantaneous.  Without a spec on the measurement time, there is no
> basis for saying that 0.6 sec is too long.
> 

Ok, as an add-on, let me show you one reason. This is a Ducati 
accelerating pretty much at full bore, quite impressive:
http://www.youtube.com/watch?v=-g_3ILrWFio

Here is a clip of a Hayabusa where you can actually see the RPM gauge 
and how fast it has to be:
http://www.youtube.com/watch?v=XJDk7uQMuz4&NR=1

Now don't do this at home:
http://www.leechvideo.com/video/view3709580.html

AFAIK the Hayabusa can get from zero to 100km/h in less than 3secs and 
it looks like the rider in the last video at times doesn't even spend 
those 0.6secs in one gear before shifting up. 0.6secs would not work at 
all for a machine like this.

[...]

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

"Joerg" <n...@removethispacbell.net> wrote in message 
news:gPlmk.19292$R...@flpi146.ffdc.sbc.com...
>
> The OP mentioned motorcycles and he is in Italy. Have you ever seen a 
> Ducati or Moto Guzzi revv through several gears and go from zero to 
> freeway speed in just a few seconds? Some guys won't even stay in one gear 
> for 0.6 seconds.

(Actually, 2nd gear on that class of bike will get you illegal in almost 
every jurisdiction.) I don't recall ever watching the tach while twisting 
its nuts off, partly for the lag or just perceived possibility of lag, but 
mostly because the eyes and mind are already a hundred yards ahead of the 
bike.

If I were to build a tach for myself, I'm interested in 3 ranges of use. The 
first function is as you say. Timing between pulses and lighting a sequence 
of LEDs as it gets close to fuel shutoff is serves this need best. Minimum 
lag is required here. A little flicker between lights is OK, expected, and 
possibly useful of itself.

Near idle, I really do want good resolution, perhaps as fine as 10 or 25 
rpm, to check the idle point, more out of idle curiousity while waiting for 
a light rather than any real need. Some smoothing to help readability is 
good, but it really should show the variability.

In a droning cruise, the case for almost all road miles, I want a dead 
smooth and readable response. Some lag is OK. 100 rpm resolution is 
sufficient. I use the tach rather than the speedometer to maintain speed. 
The speedometer has a built in 8.5% error and lags full seconds behind. The 
ears do a fine job of picking up small changes. The tach, substituting for 
the speedo, simply serves as a do-not-exceed reference point for that 
stretch of road. I might even like to toggle between the tach function and a 
digital pseudo speedo display calibrated for top gear only. (I doubt I would 
ever bother to toggle it to use it, though.)

It should be easy to build now. ;)

MikeWhy wrote:
> "Joerg" <n...@removethispacbell.net> wrote in message 
> news:gPlmk.19292$R...@flpi146.ffdc.sbc.com...
>>
>> The OP mentioned motorcycles and he is in Italy. Have you ever seen a 
>> Ducati or Moto Guzzi revv through several gears and go from zero to 
>> freeway speed in just a few seconds? Some guys won't even stay in one 
>> gear for 0.6 seconds.
> 
> (Actually, 2nd gear on that class of bike will get you illegal in almost 
> every jurisdiction.) I don't recall ever watching the tach while 
> twisting its nuts off, partly for the lag or just perceived possibility 
> of lag, but mostly because the eyes and mind are already a hundred yards 
> ahead of the bike.
> 

Out here I have the impression that biker don't give much of a hoot WRT 
jurisdiction. Especially the guys on the rice rockets. Surprisingly only 
one major crash so far but that one was really bad.


> If I were to build a tach for myself, I'm interested in 3 ranges of use. 
> The first function is as you say. Timing between pulses and lighting a 
> sequence of LEDs as it gets close to fuel shutoff is serves this need 
> best. Minimum lag is required here. A little flicker between lights is 
> OK, expected, and possibly useful of itself.
> 
> Near idle, I really do want good resolution, perhaps as fine as 10 or 25 
> rpm, to check the idle point, more out of idle curiousity while waiting 
> for a light rather than any real need. Some smoothing to help 
> readability is good, but it really should show the variability.
> 
> In a droning cruise, the case for almost all road miles, I want a dead 
> smooth and readable response. Some lag is OK. 100 rpm resolution is 
> sufficient. I use the tach rather than the speedometer to maintain 
> speed. The speedometer has a built in 8.5% error and lags full seconds 
> behind. The ears do a fine job of picking up small changes. The tach, 
> substituting for the speedo, simply serves as a do-not-exceed reference 
> point for that stretch of road. I might even like to toggle between the 
> tach function and a digital pseudo speedo display calibrated for top 
> gear only. (I doubt I would ever bother to toggle it to use it, though.)
> 
> It should be easy to build now. ;)
> 

If you are a biker (I am not, but maybe some day ...) you might enjoy 
the tach in the video links I posted. The third one really gave me the 
chills, hoping the rider is still among the living.

-- 
Regards, Joerg

http://www.analogconsultants.com/

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