Re: Truncate then average? Or average then truncate?

Jon Watte <[email protected]> Tue, 8 Jun 2010 11:09:41 -0700
Newsgroups gmane.games.devel.algorithms
Message-ID <[email protected]>
>
> > 2) You definitely want to sum first, and then divide. In fact, if you
> want a
> > value from 0 .. 127, and have 10 bit numbers (0 .. 1023) coming in, I
> would
> > sample four times at evenly spread intervals into a ring buffer, and
> > calculate the output values as the sum of the last four samples, shifted
> > right five bits. (your range will be 0 .. 4092, which divided by 32 ends
> up
> > as 0 .. 127)
>
> This was exactly the form that caused the problem around values with a
> lot of bits set. You're trying to discard the random bottom bits, but
> you include their influence by summing before removing them by
> truncation.
>
>

Signal theory says you can't possibly be more noisy after summing and
truncating than you were before. There is no way for the low 2 bits of input
to "leak" into higher values on the output.

There *is* a way for the outcome to toggle between, say, 63 and 64, at your
sample rate, if there is a signal component present at (or close to) your
Nyquist frequency. There's basically nothing you can do against that. And it
will "flip the bits" for all the bits -- but, seen as a value, that's not
really a problem.

Basically, what I hear you saying is that, when you go from 10 bits input to
7 bits data using oversampling and summing, you will still get noise in the
lowest bit of the 7-bit data, which means that you have at least 4 noisy
bits in the input, not just two. The way to fix that is to make the input
less noisy. There are many things that can make the input noisy. The input
to the ADC is one -- that's where you want a good filter if possible (the RC
was one suggestion which is cheap, there are better :-). Perhaps your ADC
already has an adjustable anti-aliasing filter, in which case you can just
lower the cut-off of that.

The reference voltage for the ADC is another source of noise. If you can't
get that steady, you're in trouble. Again, some RC goodness on that input
might help.

Another option is to apply real DSP. Summing values just implements a simple
FIR filter with very shallow slope. You can get better response by designing
a four-pole IIR filter and feeding it the inputs (assuming you can get
integer quantization to stay stable -- else do it as two bi-quad filters).
Set the cut-off at something significantly lower than your sampling rate.
For example, if you sample at 4 kHz (4 samples per tick for USB 1 ms tick
rate, say), then you can set the cut-off frequency (-3 dB point) to 200 Hz
and nobody will feel any lag.

But, really -- 7 bits is such low dynamic range (~43 dB), it should be
easily addressable using cheap components.

Sincerely,

jw

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo

_______________________________________________
GDAlgorithms-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list