Bob Beuge wrote:
>
> I think you're getting real close. Unfortunately, no matter how you
> try to round the answer you will introduce errors because you don't
> have infinite precision with any digital representation of the
> average. By comparing AVGLO to 128 and rounding you are just moving
> the probable error by one place. Eventually the errors will cause
> drift.
>

I think my approach works great if you are only interested in 256
data points.  Bombs if you are interested in the long term average.
Clear out the average after 256 points, start over from zero.  The
application I am working on will work fine with this approach.


> Instead of trying to fight the unbeatable battle for accuracy, you
> would be better off trying to achieve stability. You can do this by
> giving a slight additional weight to the new number. Perform your
> calculation just as you described and then add or subtract 1 bit to
> your 16 bit average to make the average closer to the new number.
>
> DIFFERENCE = NEW - AVEHI
> If DIFFERENCE  = 0  don't do anything.
> If DIFFERENCE > 0 add 1 to 16 bit average
> If DIFFERENCE < 0 subtract 1 from 16 bit average
>
> If you want even more stability, you can give a higher weight to the
> new number and simplify the code by eliminating the comparisons
> altogether. Just add the difference directly to the average. Note
> that if DIFFERENCE < 0 you will have to decrement AVGHI to keep the
> math correct.

I've used a similar technique, assigning a number of weights to
possible data points and adding or subtracting from an average to get
to a setpopint.  With a lot of fiddleing and hand tuning, this can be
VERY stable in the face of HORRENDOUS noise.  Maybe even better than
averaging from a theoretical standpoint.

>
> By adding more weight to the new number you will also make the
> average more responsive. You won't have to wait for 256 numbers
> before the average is meaningfull.
>
> You can still round the average according to the high order bit of
> AVGLO if you want to. Just do your rounding to a copy of AVEHI and
> not to AVEHI itself so you don't introduce errors into your average
> which can accumulate and cause drift.
>
> Good luck on your project.
>
> Bob
>




>Lawrence Lile wrote:
> >  One of the ways to implement a running averaging algorithm is
> >
> >  (Old average) *256 - (Old Average) + (New data point)
> >
> >  This gives a result that is 256 times the actual average, which
> >  would be quite useful in my case.  Why divide? Or, if I really
> >  need the divided result, just use the high byte of the result.
> >
> >  Multiplication by 256 is just shifting left 8 times, right?  In
> >  this case a one byte number shifted left 8 times becaomes a two
> >  byte number with the low byte being zero.  No actual shifting
> >  required.
> >
> >  If (Old average)*256  is stored in AVGHI,AVGLO
> >
> >  the formula becomes
> >
> >  AVGHI,AVGLO  -  AVGHI + (NEW DATA POINT)
> >
> >  It would be a teensy bit more accurate if I could add in a single
> >  digit based on rounding  (AVGLO/256).  This could be computed by
> >  comparing AVGLO to 128 decimal and setting 1 or 0.
Best Regards,

Lawrence Lile