On Tuesday, 23 Sep 1997, Lawrence Lile <lilel@TOASTMASTER.COM> asked:

>Anybody got a good averaging algorithm?

to which there were many excellent replies suggesting that the problem
was perhaps not so much one of arithmetic averaging but of filtering
'spikes' from the input stream. In particular, Notes_Server_1@KEYCORP.COM.AU
provided a quick-n-nifty tutorial on IIR and FIR filters (thanks Bob!),
and Ross McKenzie <R.McKenzie@NOSP*M.SENCON.COM> described a hardware
implementation:

>His strain gauge sensor output was amplified and then put through an
>adaptive filter before being digitised and displayed. His adaptive filter
>was simply a low pass RC filter with the C being connected to ground via
>4016 transmission gates. The first time on the scale, the filtering was very
>short in time constant, allowing a quick attack.

A solution that worked well for me (in a project involving "decoding"
Morse code signals transmitted by error-prone humans at unpredictable
rates) was a trivially-easy IIR variant that minimizes the number of
data-points to be stored (one) and uses only addition and bit-shifts. In
pseudo-code:

  theSmoothedValue = 0;
  while (NotDoneYet)
    theSmoothedValue += ( getNextSample() - theSmoothedValue) >> 2 ;

or in english, "add to the running smoothed value one-fourth the
(signed) difference between each new sample and the current
smoothed value."

This is sort of the software equivalent of the capacitor-discharge
solution; intermittent large spikes decay quickly enough to have
little effect on the operation [of my application], while long-term
trends (steadily increasing or decreasing values) are tracked with
good accuracy and relatively little latency. The technique works best
for applications in which successive samples aren't really random at
all but tend to vary somewhat about a median (there's that word again)
value. Your sampling rate and the (wallclock) period over which an
"average" is accumulated may dictate changes to the shift-count
(divisor), and the low numerical value of your samples (0-15) may make
the technique ineffective without prescaling upwards. (In my Morse
code reader, the simple approach above allowed the software to "lock
on" to transmissions at rates from 5 to 50 words-per-minute within a
couple of characters or so.)

Interesting topic; thanks to all who replied!

/steve holmes   (lurker extraordinaire)