Re: [Algorithms] Truncate then average? Or average then truncate?

[Jon W. <jw...@gm...>]

I don't get the AND thing -- you can't get instant key response that way,
because you need to wait for all the words to have the bit set before it
registers as a "key down." Is there more state there than the description?

When it comes to the ADC, there are a few things I would think about, FWIW:

1) Put a capacitor and resistor on the analog input before the ADC. I don't
care what they say; it's cheap, and very helpful!

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)

3) You probably also want to implement some dead space at both ends in the
hardware. This means, if the summed range is 0 .. 4092, you might actually
want to treat 0 .. 100 as 0, and 3093 .. 4092 as 127, and spread the rest of
the interval between the two values, assuming you have efficient
multiplication or division. If this is for a thumb stick (game controller
style) you also want a dead space in the center, although that could
potentially be applied in the software driver rather than firmware.

Sincerely,

jw



--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world. Nevertheless,
whether we get there willingly or not, we shall soon have lower consumption
rates, because our present rates are unsustainable.



On Fri, May 28, 2010 at 3:18 PM, Tom Forsyth
<tom...@ee...>wrote:

> Not sure I understand what answer you want out of the last example. The
> value is 63.5 +/- 0.5. You can either get back 63 or 64, but no matter how
> you filter it, that value will still oscillate slightly at some ADC
> setting.
>
> If you literally want no change if there's only a noise variance, just do a
> threshold trick - do the filtering the way you're doing it, and then if the
> filtered result is within some epsilon of the previously-returned value,
> keep returning that previous value. Otherwise, send the new value. It's a
> standard trick for things like analogue joysticks. It works OKish, but has
> bizarre stair-step response to slow movement (whereas a properly-filtered
> answer will also move slowly).
>
> TomF.
>
>
> > -----Original Message-----
> > From: Robin Green [mailto:rob...@gm...]
> > Sent: Friday, May 28, 2010 10:02 AM
> > To: Game Development Algorithms
> > Subject: Re: [Algorithms] Truncate then average? Or average then
> > truncate?
> >
> > OK, imagine this. We have a noisy two lowest bits, so we're removing
> > the bottom three bits of the value and averaging four samples. If the
> > value is around 180 we get:
> >
> >         10110101b
> >       + 10110100b
> >       + 10110110b
> >       + 10110101b
> >   ---------------
> >       1011010100b >> 2
> >   ---------------
> >       = 1011010b
> >
> > But if the value is close to a power of two, e.g. 64, we get unstable
> > values:
> >
> >       1000000b
> >     + 0111111b
> >     + 1000001b
> >     + 0111111b
> >   ------------
> >      11111111b >> 2
> >   ------------
> >     = 0111111b
> >
> > The noise in the LSBs ends up bits flipping bits high up in the number
> > in a way that truncating doesn't solve. Mr Bunnell is right, I should
> > probably look more into numerical filtering rather than bit tricks.
> > Duh.
> >
> > - Robin Green.
> >
> >
> > On Fri, May 28, 2010 at 9:06 AM, Jeremiah Zanin
> > <Jer...@vo...> wrote:
> > > Broken divider? I don't see how the noise bits can bleed into the
> > other bits after dividing unless it's rounding up. Have you tried
> > taking a power of two samples and shifting instead of dividing?
> > >
> >
> > -----------------------------------------------------------------------
> > -------
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-
> > list
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com
> > Version: 8.5.437 / Virus Database: 271.1.1/2861 - Release Date:
> > 05/28/10 06:25:00
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>