Searching \ for '[PIC] RPM measurement question' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'RPM measurement question'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] RPM measurement question'
2011\02\14@124849 by Andre Abelian

picon face
Hi all,

this is for VW bug engine.
I have square wave pulse. I use function generator to generate it. every 4th pulse is  1 cycle. I am using pic12f683 capture input to read this pulse and I setup to read every 4th pulse. some thing basic I am not picturing right. I need to find out how fast this engine (pulse) is running so engine is based on RPM
revolution per minute. in this case I have to setup a time and count pulses to determine the speed. Since it is RPM
counting 1 minute makes no sense so my question is how fast I should count pulses to determine RPM? another words
lets say RPM shows 1000 revolution per minute if break it down will be  in 1 second 16.666 revolution so
should I count for 1 second and expect 16 or 17 counts?
I do not know for some reason I am not picturing  it right...

any suggestion ?


thanks

Andre


2011\02\14@131140 by enkitec

picon face
On 14-Feb-11 15:48, Andre Abelian wrote:
{Quote hidden}

        Just measuring the time between pulses and doing the math, perhaps?

        MJ

2011\02\14@131259 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: spam_OUTpiclist-bouncesTakeThisOuTspammit.edu [.....piclist-bouncesKILLspamspam@spam@mit.edu] On
Behalf
> Of Andre Abelian
> Sent: 14 February 2011 17:49
> To: Microcontroller discussion list - Public.
> Subject: [PIC] RPM measurement question
>
> Hi all,
>
> this is for VW bug engine.
> I have square wave pulse. I use function generator to generate it.
every
> 4th
> pulse is
> 1 cycle. I am using pic12f683 capture input to read this pulse and I
setup
> to
> read every 4th pulse. some thing
> basic I am not picturing right. I need to find out how fast this
engine
> (pulse)
> is running so engine is based on RPM
> revolution per minute. in this case I have to setup a time and count
> pulses to
> determine the speed. Since it is RPM
> counting 1 minute makes no sense so my question is how fast I should
count
> pulses to determine RPM? another words
> lets say RPM shows 1000 revolution per minute if break it down will be
in
> 1
> second 16.666 revolution so
> should I count for 1 second and expect 16 or 17 counts?
>
> I do not know for some reason I am not picturing  it right...
>
> any suggestion ?

This depends entirely on your application.  If this going to be for a
tachometer, then one second update rate will not be anything like fast
enough, and you won't get very good resolution at low engine speeds.

Instead of counting the number of pulses within a fixed gate period,
also consider measuring the period of the pulse and taking the
reciprocal.  This gets you a new frequency measurement for every pulse,
at the cost of a (possibly large) division operation.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2011\02\14@131445 by David VanHorn

picon face
Count the pulse width or time between pulses in microseconds, or some
other conveniently small time interval

2011\02\14@131651 by Isaac Marino Bavaresco

flavicon
face
Em 14/2/2011 15:48, Andre Abelian escreveu:
{Quote hidden}

You will get better resolution if you not count the pulses, but instead
measure the interval between the start or the end of two consecutive
pulses (indeed the total length of one pulse = low period + high period).
You may use the same CCP module you are using now. You should be able to
get a resolution better than 1us.

Measure the time T of the pulse and calculate the frequency F = 1 / T.


Best regards,

Isaac

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com

2011\02\14@131656 by Bob Blick

face
flavicon
face
On Mon, 14 Feb 2011 09:48 -0800, "Andre Abelian" wrote:

> this is for VW bug engine.

2 coil pulses per revolution.

> counting 1 minute makes no sense so my question is how fast I should
> count
> pulses to determine RPM? another words
> lets say RPM shows 1000 revolution per minute if break it down will be
> in 1
> second 16.666 revolution so
> should I count for 1 second and expect 16 or 17 counts?
Hi Andre,

There are two ways to do it.
The hard way is to measure the time period between coil pulses. You can
get an immediate and accurate measurement of RPM that way but it
requires division.

The other way is to count the number of coil pulses within a fixed time
period and then multiply them by a constant (different constant
depending on number of pulses per revolution and how long your time
period is). This is easy but not instantaneous and not super accurate.

I usually use the second method. But I also do a trick. I use 1/4 second
as the time period and store one second's worth of them (four counts) in
a circular buffer. Normally I sum the buffer and use that to display,
four times per second. But I always compare the two most recent counts
and if the difference between them is greater than (some amount,
experiment), then I only use the new count.
So the display updates four times per second always but normally it is
the average over the last second. For rapidly changing RPM it is the
most recent 1/4 second.

Now you know my secret method :)

Cheerful regards,

Bob

-- http://www.fastmail.fm - The professional email service

2011\02\14@133702 by David VanHorn

picon face
Depending on the accuracy you need, and the code space available,
lookup tables can be your friend.  Do the hard math externally, and
just look up the answer.

I used LUTs when taking Shannon's entropy for 10 different analog and
digital sensors in a security sensor application.  MUCH faster than
computing it all from scratch.

Also, scale your variables.  Normally Shannon's entropy is expressed
as 0-1 in floating point, but expressing it as 0-255 in integer was
plenty good enough for my application, and much faster.

Do you NEED to know 1999 vs 20000 rpm

2011\02\14@133735 by David VanHorn

picon face
> Do you NEED to know 1999 vs 20000 rpm?
>

Fumblefingered that obviously... 1999 vs 2000 rp

2011\02\14@134219 by Andre Abelian

picon face
Mike,

Lets say to measure each period I still need to setup a fixed time right? in whatever time frame the measurement is ?
like frequency counter is based on per second. the result  displays every 1 second.
AA



________________________________
From: Michael Rigby-Jones <Michael.Rigby-JonesspamKILLspamoclaro.com>
To: Microcontroller discussion list - Public. <.....piclistKILLspamspam.....mit.edu>
Sent: Mon, February 14, 2011 10:12:56 AM
Subject: RE: [PIC] RPM measurement question



> {Original Message removed}

2011\02\14@134902 by Olin Lathrop

face picon face
Andre Abelian wrote:
> Since it is RPM
> counting 1 minute makes no sense so my question is how fast I should
> count pulses to determine RPM?

That depends on the update rate and resolution you need.  If both are high
enough, counting pulses won't do it.  Usually these kinds of things are
easier to do by using a CCP module in capture mode.  This can very
accurately measure time between successive pulses.  Apply a little low pass
filtering, then invert.

If you just want to detect whether the speed is above or below certain
thresholds, then you don't need to invert.  You can pre-compute the measured
period values for each threshold of interest.

> I setup to read every 4th pulse

Bad idea.  Count every pulse, and you get 4x more resolution or update rate,
or some combination of the two.

Keep in mind that signals in cars can be noisy.  Even if the 0 and 1 levels
are fine, the noise will cause jitter on the edges.  Pulses within a single
revolution may not all be symmetric or spaced exactly evenly.  Always do a
little low pass filtering on the period in these cases.  Fortunately this is
easy to do with a reasonable time constant since you get a new measurement
every pulse, and usually you don't need to update the speed anywhere near
that fast.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2011\02\14@135112 by Andre Abelian

picon face
David,

sorry I am not familiar with your method at all. I know what LUT is but I do not know how you did it? can you give brief explanation?
thanks

Andre



________________________________
From: David VanHorn <EraseMEmicrobrixspam_OUTspamTakeThisOuTgmail.com>
To: Microcontroller discussion list - Public. <piclistspamspam_OUTmit.edu>
Sent: Mon, February 14, 2011 10:37:01 AM
Subject: Re: [PIC] RPM measurement question

Depending on the accuracy you need, and the code space available,
lookup tables can be your friend.  Do the hard math externally, and
just look up the answer.

I used LUTs when taking Shannon's entropy for 10 different analog and
digital sensors in a security sensor application.  MUCH faster than
computing it all from scratch.

Also, scale your variables.  Normally Shannon's entropy is expressed
as 0-1 in floating point, but expressing it as 0-255 in integer was
plenty good enough for my application, and much faster.

Do you NEED to know 1999 vs 20000 rpm

2011\02\14@135213 by Andre Abelian

picon face
Thanks Bob. Now I know your secret method lol:



________________________________
From: Bob Blick <@spam@bobblickKILLspamspamftml.net>
To: Microcontroller discussion list - Public. <KILLspampiclistKILLspamspammit.edu>
Sent: Mon, February 14, 2011 10:16:55 AM
Subject: Re: [PIC] RPM measurement question

On Mon, 14 Feb 2011 09:48 -0800, "Andre Abelian" wrote:

> this is for VW bug engine.

2 coil pulses per revolution.

> counting 1 minute makes no sense so my question is how fast I should
> count
> pulses to determine RPM? another words
> lets say RPM shows 1000 revolution per minute if break it down will be
> in 1
> second 16.666 revolution so
> should I count for 1 second and expect 16 or 17 counts?
Hi Andre,

There are two ways to do it.
The hard way is to measure the time period between coil pulses. You can
get an immediate and accurate measurement of RPM that way but it
requires division.

The other way is to count the number of coil pulses within a fixed time
period and then multiply them by a constant (different constant
depending on number of pulses per revolution and how long your time
period is). This is easy but not instantaneous and not super accurate.

I usually use the second method. But I also do a trick. I use 1/4 second
as the time period and store one second's worth of them (four counts) in
a circular buffer. Normally I sum the buffer and use that to display,
four times per second. But I always compare the two most recent counts
and if the difference between them is greater than (some amount,
experiment), then I only use the new count.
So the display updates four times per second always but normally it is
the average over the last second. For rapidly changing RPM it is the
most recent 1/4 second.

Now you know my secret method :)

Cheerful regards,

Bob

-- http://www.fastmail.fm - The professional email service

2011\02\14@135313 by Olin Lathrop

face picon face
David VanHorn wrote:
> Do you NEED to know 1999 vs 20000 rpm?

A factor of 10?  Yeah, I need to know that.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2011\02\14@135846 by David VanHorn

picon face
On Mon, Feb 14, 2011 at 11:51 AM, Andre Abelian <RemoveMEabelian.andreTakeThisOuTspamyahoo.com> wrote:
> David,
>
> sorry I am not familiar with your method at all. I know what LUT is but
> I do not know how you did it? can you give brief explanation?
> thanks

Basically it just means taking some part of the computation that you
find to be difficult or time consuming, and creating a lookup table
for the range of input variables, with the output precomputed.  Index
the base of the table, add the variable to the base, and read the
result.

For a thermal printer, I had eight LUTs for different parameters in a
13 term equation that had to be computed during a 300uS interval,
while dealing with other events on interrupts.   In your case, I'm
thinking you may not need to know the exact RPM number, just whether
it's in some defined range

2011\02\14@135915 by David VanHorn

picon face
On Mon, Feb 14, 2011 at 11:53 AM, Olin Lathrop
<spamBeGoneolin_piclistspamBeGonespamembedinc.com> wrote:
> David VanHorn wrote:
>> Do you NEED to know 1999 vs 20000 rpm?
>
> A factor of 10?  Yeah, I need to know that.


I suppose you didn't see the correction I posted seconds later.

2011\02\14@140127 by David VanHorn

picon face
> Bad idea.  Count every pulse, and you get 4x more resolution or update rate,
> or some combination of the two.
>
> Keep in mind that signals in cars can be noisy.  Even if the 0 and 1 levels
> are fine, the noise will cause jitter on the edges.  Pulses within a single
> revolution may not all be symmetric or spaced exactly evenly.  Always do a
> little low pass filtering on the period in these cases.  Fortunately this is
> easy to do with a reasonable time constant since you get a new measurement
> every pulse, and usually you don't need to update the speed anywhere near
> that fast.

Very much in agreement.
You can also "sanity-check" your data, knowing that the engine can't
instantly change its speed by a large amount.  If the input has
changed more than is reasonable, you can make a decision on whether or
not to ignore it.

2011\02\14@140443 by Olin Lathrop

face picon face
Andre Abelian wrote:
> Lets say to measure each period I still need to setup a fixed time
> right?

No, you set up a free running counter that is incremented at a fixed known
rate.  On smaller PICs like a PIC 16, this will be timer 1.  The CCP module
then captures a snapshot of timer 1 whenever a pulse comes in.  In the CCP
interrupt, you subtract the new reading minus the previous reading to get
the timer counts between them.

Most engines idle around 700 RPM, or 12 Hz.  Let's say you want this
tachometer to work down to 4 Hz.  That means timer 1 must not overflow
faster than 4 Hz, which means it must be clocked no faster than 262 KHz.  So
clocking timer 1 at 250 KHz works just fine.  At 8000 RPM = 133 Hz, that
still gives you a resolution of over 1 part in 1800.  Even if you clocked
the timer off of a 32768 Hz watch crystal, you still get 1 part in 246
resolution at 8000 RPM.  With a little low pass filtering, you sortof
combine period of recent pulses and get a bit more resolution.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2011\02\14@140809 by Olin Lathrop

face picon face
David VanHorn wrote:
> I suppose you didn't see the correction I posted seconds later.

Not until seconds later, of course.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2011\02\14@141130 by Andre Abelian

picon face
thanks Olin.
I have hall effect sensor connected to CCP module and power supply
has some filters. I will try every cycle and all suggestions I received from other members.
you guys are great.

thanks

Andre



________________________________
From: Olin Lathrop <TakeThisOuTolin_piclistEraseMEspamspam_OUTembedinc.com>
To: Microcontroller discussion list - Public. <RemoveMEpiclistspamTakeThisOuTmit.edu>
Sent: Mon, February 14, 2011 10:49:14 AM
Subject: Re: [PIC] RPM measurement question

Andre Abelian wrote:
> Since it is RPM
> counting 1 minute makes no sense so my question is how fast I should
> count pulses to determine RPM?

That depends on the update rate and resolution you need.  If both are high
enough, counting pulses won't do it.  Usually these kinds of things are
easier to do by using a CCP module in capture mode.  This can very
accurately measure time between successive pulses.  Apply a little low pass
filtering, then invert.

If you just want to detect whether the speed is above or below certain
thresholds, then you don't need to invert.  You can pre-compute the measured
period values for each threshold of interest.

> I setup to read every 4th pulse

Bad idea.  Count every pulse, and you get 4x more resolution or update rate,
or some combination of the two.

Keep in mind that signals in cars can be noisy.  Even if the 0 and 1 levels
are fine, the noise will cause jitter on the edges.  Pulses within a single
revolution may not all be symmetric or spaced exactly evenly.  Always do a
little low pass filtering on the period in these cases.  Fortunately this is
easy to do with a reasonable time constant since you get a new measurement
every pulse, and usually you don't need to update the speed anywhere near
that fast.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2011\02\14@142846 by PICdude

flavicon
face
Andre,

LUT is short for Look-Up Table.

There are two primary ways to measure the frequency -- (1) as you were  thinking, count the number of cycles that occur in a given amount of  time, and (2) as others suggested, have some timer counting at fixed  intervals and count how many of those occur in one pulse of your  engine tach signal.  (1) works better for higher frequencies, and (2)  is better for low frequencies.  I've done a frequency counter before,  using a hybrid of both.

For a four-stroke engine, you should have 1 pulse per cylinder for  every 2 crank cycles, so for a 4-cylinder 4-stroke engine, you'll get  2 pulses every crank cycle.

I think you understand (1), but for (2), setup a time that triggers an  interrupt every say 1/1,000th of a second, (so 0.001 seconds between  pulses).  So 800 rpm ==> 1600 pulses/min = 26.67 pulses/sec (or 26.67  Hz).  So the period of each pulse is 1/26.67 = 0.0375 sec.  With your  interrupt interval, you should be able to count 37 or 38 pulses in  this time.

Then you can calculate the reciprocal of that (1/37) to get the  frequency, and multiply by ((60 x 1000) / 2) to get the rpm.  Ex: (60  x 1000) / (2 x 37) = 810 rpm.  You can change the timer interrupt  interval to get more resolution if you need it.

For that last part (the division), you can use a look-up table, and  not have to do the math in a PIC.

Cheers,
-Neil.



Quoting Andre Abelian <abelian.andreEraseMEspam.....yahoo.com>:

{Quote hidden}

>

2011\02\14@150710 by N. T.

picon face
Olin Lathrop wrote:
> Andre Abelian wrote:
>> Lets say to measure each period I still need to setup a fixed time
>> right?
>
> No, you set up a free running counter that is incremented at a fixed known
> rate.  On smaller PICs like a PIC 16, this will be timer 1.  The CCP module
> then captures a snapshot of timer 1 whenever a pulse comes in.  In the CCP
> interrupt, you subtract the new reading minus the previous reading to get
> the timer counts between them.
>

That's a good point. And you could take not the first previous
reading, but also, say, N-th previous reading, depending on the
mechanical properties of the system. This would average readings on
last N values.

2011\02\14@152209 by Olin Lathrop

face picon face
N. T. wrote:
> That's a good point. And you could take not the first previous
> reading, but also, say, N-th previous reading, depending on the
> mechanical properties of the system. This would average readings on
> last N values.

Not a good idea.  Now the timer must not wrap for at least N pulses.

What you are really describing is low pass filtering the series of pulse
periods, although you're not thinking about it that way.  Your average of
the last N periods is a low pass filter, just not a particularly good one.

There is one advantage in applying a box filter in this case, which is that
if you box filter one whole engine revolution of pulses any irregularities
in when the pulses occur within a revolution cancel out.  In this case,
there are two pulses per revolution, so working with the sum of the last two
pulses might make some sense.  However, I would still compute the period of
each pulse separately, just keep the previous period around too.  Then do a
real low pass filter each pulse on the sum of the last two pulses.  That
should give you a high quality result.

The OP hasn't said what resolution and update rate he needs.  Most likely
something like a simple two pole low pass filter will be just fine.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2011\02\15@104953 by N. T.

picon face
Olin Lathrop wrote:
> N. T. wrote:
>> That's a good point. And you could take not the first previous
>> reading, but also, say, N-th previous reading, depending on the
>> mechanical properties of the system. This would average readings on
>> last N values.
>
> Not a good idea.  Now the timer must not wrap for at least N pulses.
>

Not a big deal do extend the timer in software.


> What you are really describing is low pass filtering the series of pulse
> periods, although you're not thinking about it that way.  Your average of
> the last N periods is a low pass filter, just not a particularly good one..
>

You may call it whatever you want, but it is "A simple moving average
(SMA) is the unweighted mean of the previous n data points". It can be
good and it is widely used in the industry. If you need 10
measurements per second and rotation is 100 per second, that is 400
pulses per second for 4 cylinder engine, why not taking a "simple
moving average" over last 16 readings? It's cheap - you need just to
shift the value 4 bits.

2011\02\15@112816 by Olin Lathrop

face picon face
N. T. wrote:
> You may call it whatever you want, but it is "A simple moving average
> (SMA) is the unweighted mean of the previous n data points".

Yes, which is also known as a box filter.  The properties of such a filter
are well known.  It has one important characteristic in that the gain at one
particular frequency and its integer multiples is zero.  But otherwise, its
high frequency rolloff and step response properties are not particularly
great for most simple noise filtering applications.

> It can be good and it is widely used in the industry.

This only shows how few people paid attention in digital signal processing
class.  Tell a filter-ignorant engineer to do something to reduce high
frequency noise, and you get a box filter most of the time.  That only shows
it's conceptually obvious, not that there aren't better tradeoffs for most
applications.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2011\02\15@155351 by Andre Abelian

picon face
Thanks Neil appreciate your help



________________________________
From: PICdude <RemoveMEpicdude3spam_OUTspamKILLspamnarwani.org>
To: RemoveMEpiclistTakeThisOuTspamspammit.edu
Sent: Mon, February 14, 2011 11:28:44 AM
Subject: Re: [PIC] RPM measurement question

Andre,

LUT is short for Look-Up Table.

There are two primary ways to measure the frequency -- (1) as you were  thinking, count the number of cycles that occur in a given amount of  time, and (2) as others suggested, have some timer counting at fixed  intervals and count how many of those occur in one pulse of your  engine tach signal.  (1) works better for higher frequencies, and (2)  is better for low frequencies.  I've done a frequency counter before,  using a hybrid of both.

For a four-stroke engine, you should have 1 pulse per cylinder for  every 2 crank cycles, so for a 4-cylinder 4-stroke engine, you'll get  2 pulses every crank cycle.

I think you understand (1), but for (2), setup a time that triggers an  interrupt every say 1/1,000th of a second, (so 0.001 seconds between  pulses).  So 800 rpm ==> 1600 pulses/min = 26.67 pulses/sec (or 26.67  Hz).  So the period of each pulse is 1/26.67 = 0.0375 sec.  With your  interrupt interval, you should be able to count 37 or 38 pulses in  this time.

Then you can calculate the reciprocal of that (1/37) to get the  frequency, and multiply by ((60 x 1000) / 2) to get the rpm.  Ex: (60  x 1000) / (2 x 37) = 810 rpm.  You can change the timer interrupt  interval to get more resolution if you need it.

For that last part (the division), you can use a look-up table, and  not have to do the math in a PIC.

Cheers,
-Neil.



Quoting Andre Abelian <EraseMEabelian.andrespamspamspamBeGoneyahoo.com>:

{Quote hidden}

>

2011\02\15@194206 by IVP

face picon face
Andre, long time no hear

you would be interested in this 16F88 tachometer project

http://www.siliconchip.com.au/cms/A_107675/article.html

Part 1 images

dl.dropbox.com/u/18683201/SC_1006_tacho_01_sm.gif
dl.dropbox.com/u/18683201/SC_1006_tacho_02_sm.gif
dl.dropbox.com/u/18683201/SC_1006_tacho_03_sm.gif
dl.dropbox.com/u/18683201/SC_1006_tacho_04_sm.gif
dl.dropbox.com/u/18683201/SC_1006_tacho_05_sm.gif
dl.dropbox.com/u/18683201/SC_1006_tacho_06_sm.gif
dl.dropbox.com/u/18683201/SC_1006_tacho_07_sm.gif
dl.dropbox.com/u/18683201/SC_1006_tacho_08_sm.gif
http://dl.dropbox.com/u/18683201/SC_1006_tacho_09_sm.gif

The software and PCB layout files can be downloaded from

http://www.siliconchip.com.au/cms/attachments/show.html?year=2006&month=October

Unfortunately I can't lay my hands on the Part 2 issue right now
(test and set-up) but there are enough comments in Part 1 and the
..asm file to help you to understand how it does what it does - despite
how some of the s/w is written ;-))

Joe

2011\02\16@094045 by Jens M. Guessregen

flavicon
face
"You can also "sanity-check" your data, knowing that the engine can't
instantly change its speed by a large amount."

Maybe this engine cannot, but others can.  
Audi's actual 3.0 TFSI engine takes 2.5 seconds to speed up from 750 RPM to
6500 rpm under load. On engine dynamometer, it takes less than 0.5 second for this speed change
(less than 0.1 second for a delta of 1000 rpm).

But measuring coil signals, is only an estimation anyway.
Even with older engines without full electronic coil system, the ignition
point is not fixed to crank position. It is dynamic, controlled by speed of
the crank (centrifugal force) and engine load (vacuum actuator). With to
influences, the ignition point may change much faster as the speed of the
crank itself. The ignition point may vary from +6° up to +45° relative to
crank (Golf GTI from early 80's). And with older engines, speed limiter is
done with ignition breaks (no ignition pulses, so this measurement would
show 0 rpm at real 6000+ rpm ;-) and even when speeding down, some engines
stop ignition pulses (older Golf/Rabbit engines have this feature to save
fuel). Newer engines may stop complete cylinders from working (fuel saving),
the first BMW V12 in the late 80's (still without computer controlled
ignition) was able to stop a complete bank of 6 cylinders from working. Not
to forget multipoint injection and ignition systems ...

I think the best way would be (as all modern engines are doing now) to have
a separate hall sensor on the crank itself. Nearby all engines have a
visible hole in the clutch housing for adjusting ignition points during
maintenance work. I have seen some years ago solutions with plug in hall
sensors, using the marking on the clutch pressure plate to add electronic
ignition and injection system to older engines.
This would work even with engines without ignition system (Diesel) or multi
coil ignition system (like the first 2 generations from BMW M5 engine, one
coil per spark direct build-in in spark-holder).

Just my 2 cents

Jens

2011\02\16@095256 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: spamBeGonepiclist-bouncesSTOPspamspamEraseMEmit.edu [KILLspampiclist-bouncesspamBeGonespammit.edu] On
Behalf
> Of Jens M. Guessregen
> Sent: 16 February 2011 14:41
> To: 'Microcontroller discussion list - Public.'
> Subject: RE: [PIC] RPM measurement question
>
> "You can also "sanity-check" your data, knowing that the engine can't
> instantly change its speed by a large amount."
>
> Maybe this engine cannot, but others can.

If you are looking at the period between consecutive spark events, then
you shouldn't see a dramatic delta even in very high revving/low inertia
engines i.e. the engine isn't going to halve or double it's speed
between one spark and the next.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2011\02\16@102401 by Michael Watterson

face picon face
On 16/02/2011 14:40, Jens M. Guessregen wrote:
> I think the best way would be (as all modern engines are doing now) to have
> a separate hall sensor on the crank itself. Nearby all engines have a
> visible hole in the clutch housing for adjusting ignition points during
> maintenance work. I have seen some years ago solutions with plug in hall
> sensors, using the marking on the clutch pressure plate to add electronic
> ignition and injection system to older engines.
Is it possible to detect the frequency of the Alternator with a small sensor coil near it

2011\02\16@171411 by Chris Pearson

picon face
My company makes a part which attaches to the alternator output, designed to
simulate a tachometer signal for remote starters. I doubt it's useful to the
OP though. (This part tends to only be used on large diesel engines)

http://www.directedstore.com/manuals/454T.pdf


On Wed, Feb 16, 2011 at 7:23 AM, Michael Watterson <EraseMEmikespamEraseMEradioway.org>wrote:

> Is it possible to detect the frequency of the Alternator with a small
> sensor coil near it?
>

2011\02\19@101707 by Jens M. Guessregen

flavicon
face
> On 16/02/2011 14:40, Jens M. Guessregen wrote:
> > I think the best way would be (as all modern engines are doing now) to
> > have a separate hall sensor on the crank itself. Nearby all engines
> > have a visible hole in the clutch housing for adjusting ignition
> > points during maintenance work. I have seen some years ago solutions
> > with plug in hall sensors, using the marking on the clutch pressure
> > plate to add electronic ignition and injection system to older engines.


> Is it possible to detect the frequency of the Alternator with a small
sensor coil
> near it?

You should check, if there is Diesel Version of this type of engine is
available. Most alternators for older Diesel engines had a dedicated output for rpm
signaling.
Best Jens

2011\02\19@101859 by Jens M. Guessregen

flavicon
face
> > "You can also "sanity-check" your data, knowing that the engine can't
> > instantly change its speed by a large amount."
> >
> > Maybe this engine cannot, but others can.
>
> If you are looking at the period between consecutive spark events, then
you
> shouldn't see a dramatic delta even in very high revving/low inertia
engines
> i.e. the engine isn't going to halve or double it's speed between one
spark
> and the next.

40° degree difference are not nothing, but even not half or double speed.
But if you ignore 40° difference, you do not need to think about 10, 12 or
14 bit resolution of a counter ...

Best Jens

2011\02\19@102254 by Jens M. Guessregen

flavicon
face
> My company makes a part which attaches to the alternator output, designed
> to simulate a tachometer signal for remote starters. I doubt it's useful
to the
> OP though. (This part tends to only be used on large diesel engines)
>
> http://www.directedstore.com/manuals/454T.pdf

That is the way, older Volkswagen (and other brands) Diesel engines
generated a tacho signal of the engine, before the µcontroller based
injection systems made this job.
You just have to calculate the relation between crank rpm and alternator rpm
und you have your crank rpm.

Best Jens


2011\02\21@044419 by Michael Rigby-Jones

flavicon
face


{Quote hidden}

Sorry but that makes no sense at all:

1) Why would you want to ignore cycle to cycle phase changes?
2) Why would you need to throw away resolution?

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2011\02\24@031001 by Andries Tip

flavicon
face
Dear Andre,

I used to build a datalogger for motorcycles. It measures speed, RPM and
several analog channels too.
When the revolution pulses keep away the RPM rate drops automatically. I
extended the 16-bit timer
to be able to measure low revs and speed.

I just posted the code on the PIClist web site. It is the complete listing,
including memory handling
and communications and may therefore be a bit overwhelming. I suggest you
have a look at the interrupt
code first. The comments should help you on your way. Please have a look and
see if you can use it:

http://www.piclist.com/Techref/member/AT-planet-T9/datalogger.htm

With kind regards,
-Andries

2011\02\24@081602 by Olin Lathrop

face picon face
Andries Tip wrote:
> http://www.piclist.com/Techref/member/AT-planet-T9/datalogger.htm

To the OP:  This may be good to look at to get the logic.  He seems to have
done a reasonable job of documenting that.

However, do NOT try to emulate this structure.  This code lumps everything
into a single file, hard codes variables to specific addresses, hard codes
assumptions about variable banks in the code, manually allocates routines to
pages then hard codes assumptions about what pages routines are on, and on
top of that it's all absolute code.  These are all bad practises.  Imagine
the mess if you ran out of room in a bank and needed to move some variables
around.

There are better ways of doing this, even with native MPASM tools.  The
BANK0 - BANK3 macros in this code are particularly silly since they have no
advantage over the built in BANKSEL.  Both always set both bank bits, so
there is no efficiency gained by using his BANKn.  However, BANKn requires
you to know what bank a variable is in, something that the tools have no way
to known you are doing and therefore no way of checking.  BANKSEL at least
sets the bank according to the known address of the thing you are trying to
access.  If you move a variable around, BANKSEL will follow whereas BANKn
becomes a subtle bug with symptoms usually appearing in unrelated areas.

The PAGEn macros are similarly silly, with PAGESEL being the built-in
equivalent of BANKSEL for pages.

There are more examples of bad programming in this code, but hopefully this
is enough to scare you away from anything but the logic embodied in it.
Given the general level of programming structure though, I would look at the
logic very carefully before just using it.  Stone age thinking in one place
is often a indication of stone age thinking elsewhere too.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

More... (looser matching)
- Last day of these posts
- In 2011 , 2012 only
- Today
- New search...