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

[<pad...@ob...>]

Adding an RC (effective low pass filter) is a trick that works
because of the TTL (or CMOS) thresholds. Bounce can be seen as
high frequency contamination.
 
Hysteresis is not a phenonemon that concerns us, nor is it
a significant property of RC which can be considered linear
for all but the most pathological components.
 
However, of course the lowpass adds a small delay to all
operations, since the rise time is finite. Since bounce can
be considered above a couple of hundred Hz, the slugging
time of the switch will be at worst a few milliseconds.
(Nothing that ever bothered us on old consoles)
 
With regard to the LSB innaccuracy: I'm sorry that I
didn't fully understand the OP question, but the first
thing that popped in to my mind was that this is a dither
problem. Dither only works when you add a _known_ noise
source (predictable in spectral terms) to swamp the (unknown)
LSB errors. 
 
Andy
 

 

On 08 June 2010 at 07:38 Robin Green <rob...@gm...> wrote:

> On Mon, Jun 7, 2010 at 9:12 PM, Jon Watte <jw...@gm...> wrote:
> > 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?
>
> The idea comes from Jack Ganssle's article on Software Debouncers:
>
>    http://www.ganssle.com/debouncing-pt2.htm
>
>
> > 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!
>
> An R/C Network on the input, isn't that just another form of
> hysteresis? And one that's subject to the astonishing inaccuracies of
> electrolytic caps?
>
>
> > 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.
>
> The solution I ended up using records the previous ADC value in it's
> full 10-bit value. A new ADC value has to exceed this old sample by
> more than the Hysteresis amount before I allow it through to
> truncation. The insight was to keep the comparison values at full
> resolution, discard values below the H threshold and truncate the
> samples only just before they are used. Values are now rock solid.
>
> The problem was that the premature truncation was discarding important
> information.
>
> > 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.
>
> Linear POTs seem to have dead space at either end built in, but the
> dead center is a good idea - but should it be circular or square?
>
> - Robin Green.
>
> ------------------------------------------------------------------------------
> 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
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list