On Thu, 12 Apr 2001, Andrew Warren wrote:
> Dale Botkin <RemoveMEPICLISTEraseMEEraseMEMITVMA.MIT.EDU> wrote:
>
> > > FILT <-- FILT*(1-F) + NEW*F
> >
> > Man, here is where I run into a wall. I am totally unfamiliar
> > with digital filtering techniques. What is F? Is it the inverse
> > of the number of samples added to the accumulator? I keep thinking
> > I can see how this works, but then I plug it into Excel and it
> > doesn't work. Should've gone for that engineering degree.
>
> Dale:
>
> The people who've been posting on this subject presumably have
> engineering degrees, yet they haven't been able to explain the filter
> clearly enough for you to understand. Don't wish for a degree; it'll
> only make you part of the problem.
I have a great deal of respect for most of those who have invested the
time, money and effort into earning a degree. I also know that there's a
top 10% and a bottom 10% in every class, all of whom get the same diploma.
Around the PICList I think it's heavily weighted toward the top half at
least, and I appreciate the opportunity to learn the theory behind some
of the methods I've learned the hard way.
8< [massive snippage of excellet explanation]...
{Quote hidden}> Old Sum - Old Mean + New Sample
> New Mean = -------------------------------
> Window Size
>
> The old sum is equal, of course, to the old mean times the window
> size, so we can rewrite it as:
>
> (Old Mean * Window Size) - Old Mean + New Sample
> New Mean = ------------------------------------------------
> Window Size
>
> Simplifying:
>
> Old Mean * (Window Size - 1) + New Sample
> New Mean = -----------------------------------------
> Window Size
>
> So for my example, it's:
>
> Old Mean * 7 + New Sample
> New Mean = -------------------------
> 8
>
> At this point, it'd probably be instructive to notice that this is
> equivalent to:
>
> New Mean = Old Mean * 7/8 + New Sample * 1/8
>
> and if we call the mean "FILT" and assign a constant F to the value
> 1/8, it becomes:
>
> FILT <-- FILT * (1-F) + NEW*F
>
> which is the equation which you (previously) didn't understand.
But I sure do now!! Of course it's absurdly simpe now, to paraphrase Mr.
Holmes. Thanks for that.
{Quote hidden}> Anyway, the point of all this is that if you pick a window size
> that's a power of 2, the division by window size and the
> multiplication by (window size - 1) are trivially easy, AND... It
> doesn't matter how big your window size is; you can have an
> arbitrarily-large window size without suffering more than a tiny
> penalty in RAM usage and code complexity.
>
> In fact, if you choose a window size of 256, the division completely
> DISAPPEARS; it doesn't take ANY code to perform. To see the code
> required to perform this filtering algorithm with a window size of
> 256 (as I recall, it required less than 20 words of non-looped code),
> search the PICLIST archives; I posted it a few months ago.
That applies only to 8-bit sums, though, correct? I'll have a 16-bit sum,
whether dealing with pulse length or RPM. But that's moot; now that I
understand the method (thanks to Olin's suggestion and your explanation),
I bet I can save a lot of code space for some other feature I'm sure will
seem like a good idea <grin>. But of course I probably will appreciate
this exercise even more the next time I need this.
Thanks, guys, you're aces. It does my aging brain good to hurt once in a
while.
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: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads