Re: [Algorithms] Truncate then average? Or average then truncate?
Brought to you by:
vexxed72
From: Jeremiah Z. <Jer...@vo...> - 2010-05-28 16:20:02
|
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? -----Original Message----- From: Robin Green [mailto:rob...@gm...] Sent: Friday, May 28, 2010 2:24 AM To: Game Development Algorithms Subject: [Algorithms] Truncate then average? Or average then truncate? Got a bit of a brain block, and I'd welcome someone with a clearer picture of what's the correct thing to do. I have a hardware controller that I'm writing firmware for, specifically debouncing button presses. That's gone fairly well by using a word for each sample of the keystate. An interrupt timer fires and I sample the button states, one bit per key, dumping the current state into a ring buffer of N words. At key scanning time I AND all the words in the buffer together and if any of the bits in each "column" are set I register it as a keypress. So I get instant reaction to a keydown and an N-iteration delay before the columns clear so I can register a keyup. This deals with noisy bounces on key depressions and releases just fine. I am now attempting to "debounce" an analog input. The issue is that the ADC reads the input and returns a 10-bit value, the bottom two bits of which are subject to noise, but that's fine as I only need a value in the range 0..127. So my current effort is to read the ADC value several times, sum them, divide by the number of samples and then lose the bottom 3 bits. This works great for most values in the range, except for the smallest values - 0, 1, 2, ... As you move the controller through the range down to the smallest values, they exhibit the noise and become like an unordered list. Other values where a lot of bits flip, like the boundary between 63 and 64, also allow the noise to propagate up to affect the value. Technically, there should be no reason for even the smallest numbers to show the noise - only the bottom two bits exhibit noise and we're removing three bits of the final value. What order should I be doing this and why? Why am I amplifying the noise to the point where it's a problem? - Robin Green. ------------------------------------------------------------------------------ _______________________________________________ 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 This message, including any attachments, may contain privileged and/or confidential information. Any distribution or use of this email by anyone other than the intended recipient(s) is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and delete all copies. Thank you. |