Re: [Algorithms] Truncate then average? Or average then truncate?
Brought to you by:
vexxed72
From: James R. <ja...@fu...> - 2010-05-28 08:13:38
|
Are you reading the ADC three times a frame and averaging, or are you reading once per frame and then averaging over the last few frames? Is there a deadspace for the source input that you should be taking into consideration too? (Most analogue inputs have some form of dead space towards zero you should ignore, if possible.) Robin Green wrote: > 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 > > |