> This sort of goes back to what the intent is.  I don't really expect to
> see high frequency noise (but this may be way wrong on my part, of
> course).  What I wanted to smooth out was variations in crank rotational
> speed (if any) caused by the cylinders firing.  That might cause the
> readings displayed on the LCD to be unstable and/or inaccurate.  So I
> guess it's intended as a ripple filter and not a HF noise filter, though
> on reflection I may need both.

What you describe is high frequency noise in this context.  You don't want
the display to jump around.  In otherwords, you don't want to bother the
user with the high frequency content of the rotation speed, just the "trend"
over a few hundred milliseconds.  That IS low pass filtering.  The advantage
of expressing your problem in signal processing terms is that many people
have been there before.  There are many well understood standard techniques
for achieving various results.  Once you admit you have a signal processing
problem you tap into this.

> But I see another question.  With my method ("box filter" - interesting
> term, hadn't seen that one before),

Again, think signal processing.  Think of what the convolution window of a
sliding average looks like - a box.  Yes, this is actually a standard term
for that kind of filter.  A box filter might sound reasonable in time
domain, but its frequency characteristics are far from optimal as a low pass
filter, especially given the amount of computation and state required.

> I know that as long as my indicator
> flag is good (meaning the array is full) I can get the average of the last
> n tach pulses.  I can also "flush" the filter if I need to and know when
> it's ready for use again.

Why would you want to flush the array?  This opens you up to higher aliasing
effects in case there is some periodic high frequency signal (like one
cylinder doesn't fire as well).

> If I understand your suggestion correctly, the interrupt routine would
> convert the period value to a speed value,

No, I never said this had to happen in the interrupt routine.  In fact, I
like doing as little as possible in the interrupt routine.  I've done a
bunch of similar tachometer-type PIC applications.  I only handle the
immediate CCP interrupt in the interrupt.  This includes saving the captured
timer 1 value and adding the time delta into an accumulator, then bumping a
counter to indicate that the accumulator represents one more period.  The
foreground loop does the period to frequency conversion whenever it
discovers at least one period in the accumulator and it gets around to it.
This allows you to handle much higher frequencies with less time spent in
the interrupt routine.  Pulses can come in faster than they can be converted
to frequency.  No matter, since all unconverted pulses are handled at once
whenever the conversion is done.

> then add that to the filter
> variable for "n" (maybe 32) samples, then I'd divide that (shift it,
> whatever) to get the average.

That's very different from what I had in mind.  You are back to a box filter
with this approach.  I suggested a simple single pole low pass filter.  If
FILT is the filtered value to update with a new reading and NEW is the new
reading, then a single pole filter is:

  FILT <-- FILT*(1-F) + NEW*F

F is the filter fraction.  It is convenient to have F be 2**-N, like 1/8 or
1/16.  In that case multiplication by F becomes a right shift by N bits.
Multiplication by 1 - F is the original value right shifted N bits
subtracted from itself.  Note that this type of filter is computationally
simple and only requires one state value.  Smaller values of F produce more
filtering.  Note that the filter never changes when F = 0, and there is no
filtering (filter output is always the most recent value) when F = 1.

> Would that not have to be done to completion
> for each reading?  In other words, any time I want to read RPM, I always
> have to wait n tach pulses before I can calculate the average, right?

I would decouple the display update from the frequency calculation from the
pulse capturing.  The pulse capturer maintains the total pulse period and
the number of pulses since the last conversion.  The frequency converter
checks the pulse capture state periodically and does a conversion whenever
it finds at least one pulse has been captured.  It filters the result and
maintains the Official Frequency.  The display update runs 2 to 4 times per
second and writes the current Official Frequency to the display.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olin@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu