How to simplify a rolling average in an FPGA

On 10/1/2015 5:59 PM, Tim Wescott wrote:
> On Thu, 01 Oct 2015 16:36:57 -0400, rickman wrote:
>
>> On 10/1/2015 4:27 PM, Tim Wescott wrote:
>>> On Thu, 01 Oct 2015 15:52:09 -0400, rickman wrote:
>>>
>>>> On 10/1/2015 2:08 PM, Tim Wescott wrote:
>>>>> On Thu, 01 Oct 2015 08:11:38 -0500, garengllc wrote:
>>>>>
>>>>>> All, thank you so much for all the feedback and explanations, I
>>>>>> appreciate it!
>>>>>>
>>>>>> I've read through everything once, but I think I need to go through
>>>>>> it a couple more times to make sure I am following everyone's
>>>>>> points/counterpoints.
>>>>>>
>>>>>> Some quick answers (so that you know that I didn't disappear into
>>>>>> the ether) is that I do need the output of rolling_average on every
>>>>>> clock (probably why the original C coder called it a rolling average
>>>>>> even though it isn't exactly acting like it).
>>>>>
>>>>> As Rick pointed out, "Cumulative moving average" is probably a better
>>>>> name to use, if for no other reason than that's the name that
>>>>> everyone else uses.
>>>>>
>>>>>> The rolling_average_num_max is an odd value to me.  It is a constant
>>>>>> variable that will not change once the FPGA is built. What it looks
>>>>>> like to me is that rolling_average_num keeps track of the depth of
>>>>>> window average from [0,rolling_average_num_max].  So even in the
>>>>>> beginning when the average only has a few values in it, it will
>>>>>> compute the average based on that.  Once the system has been running
>>>>>> for a while, rolling_average_num will always be equal to
>>>>>> rolling_average_num_max, and that variable in the averaging equation
>>>>>> will be a constant.  That make sense?
>>>>>
>>>>> Yes it does.  The "pure" cumulative moving average would be optimal
>>>>> to estimate a value that never changes, but would eventually run into
>>>>> word-
>>>>> width limitations.  Capping the divisor by a maximum will both help
>>>>> with the word-width limitations, and will allow the algorithm to
>>>>> follow a slowly moving (with respect to the sample rate) value.
>>>>
>>>> I'm not following what you mean by "capping".  The OP sounds like he
>>>> wants to use the max value in the calculations instead of the current
>>>> value of the sample count.  I don't see how that can produce anything
>>>> useful.  In fact, at that point it has become a low pass IIR filter.
>>>>
>>>> By "capping" do you mean to reset the count and sum and start a new
>>>> average calculation?
>>>
>>> https://en.wiktionary.org/wiki/cap#Verb, definition 5.  Sorry if I'm
>>> being too obscure.
>>
>> Let *me* be clear on this.  If you set an upper limit to just the
>> divisor, you will have a corrupt calculation with a value that rises
>> above the average.  In other words you will have created an integrator,
>> not a filter or an average.
>
> No.  Review your math.  If you use any variation of the OP's code you'll
> start with a cumulative running average, and end up with a plain old 1st-
> order IIR lowpass.

Which is not what was spec'd.  Your math or your description is not 
correct.  But since you won't explain it I can't say which.


>> Is that what you are proposing?  If I misunderstand, perhaps it would be
>> better if you were more explicit.
>
> "Cap" = "set maximum limit", just like both the dictionary definition and
> the OP's post.  I'm sorry that I confused things by using a different
> word.
>
> When I talked about "capping" I meant using exactly the algorithm as the
> OP described in C: you do all the math with his divisor variable, but you
> only allow the divisor equal the actual count up to the maximum value
> (i.e., the cap, because to most native English speakers "cap" and
> "maximum value" can easily mean the same thing), after which the divisor
> is held to the maximum value.

You know what you think you are saying, but that isn't what you *are* 
saying.  The divisor is just the divisor.  I think you mean the sample 
count variable, which is not what you said.


> By just about ever variation of the equation that he posted, the filter
> starts out as a cumulative running average, and then transitions to a
> simple linear IIR lowpass.

???

Ok, we have reached a point of non-productivity.  Enjoy.

-- 

Rick