On Wed, 11 Apr 2001, Olin Lathrop wrote:

> > Now, since I want to smooth out any jitter in the tach pulse signal, I
> > average out the most recent 20 pulses. I have a CCP1 interrupt function
> > that populates a 20-element array with the value of the CCP1 capture
> > register.  Once that array is full, I average the values in the array and
> > use that number as the pulse width.  You could adjust or eliminate this
> > based on how many teeth you have on your tach pickup, how fast you want it
> > to respond to changing RPM, etc.
>
> I see no reason why this won't work as you intended, but I think there are
> better strategies.  Why is a box filter better than a single or double pole
> filter?  The latter require much less state and are easy to compute,
> especially if the filter fractions are 2**-N.  This can usually be the case
> when all you want to do is get rid of some high frequency noise.  If you are
> going to use a box filter, why not 2**N samples so that the divide to find
> the average turns into a right shift?

Good idea,I hadn't thought of that.  Of course in C it's just as simple to
do one as the other in source code, but the assembly code result would be
a lot faster, more elegant and more compact than a floating point divide.

> Another observation is that you are doing the filtering on the periods.  The
> speed value probably has a more predictable dynamic range, making single
> pole low pass filtering easier there using fixed point.
>
> In short, I would convert each period to its speed value, then low pass
> filter the speed values.  If you don't need a new speed reading as each
> tooth goes by, you can set up the timer 1 prescaler to give you only every
> Nth pulse.  I doubt you really need 1 part in 6M.

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.

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

If I understand your suggestion correctly, the interrupt routine would
convert the period value to a speed value, then add that to the filter
variable for "n" (maybe 32) samples, then I'd divide that (shift it,
whatever) to get the average. 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?

One of my goals was also to keep the interupt routine as short as
possible.  I'm using both the internal hardware USART and a software UART
as well as I2C, and I don't want the CCP interrupt service to cause errors
on the software serial sde.  I have not fully explored that quite yet,
though, and there may be a simple wayto avoid it (like disabling
interrupts while sending with the bit-bang serial routine).

Dale
---
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
                -- Isaac Asimov

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