The averaging scheme seems overly complicated. Using a "median" instead of a "mean" (average) would automatically reject outliers and would also track the mid-point of a moving signal. There should also be less math involved since you would only be sorting 2 sets of 32 values. In fact, I would recommend sorting the "x" and "y" coordinate separately. BTW, for small sets of values, linear insertion sorting usually beats fancier methods.<br>
<br><div class="gmail_quote">On Wed, 18 Jun 2008 15:51:08 +0100, <<a href="mailto:andy@openmoko.com">andy@openmoko.com</a>> wrote:<br>...<br>Touchscreen on GTA01-02 experiences noise on the channel that serves the<br>
"tall axis" of the LCM. The sample quality of the other axis is good.<br>
The bad samples have a characteristic of one shot excursions that can<br>
reach +/- 20% or more of the sample average.<br>
<br>
Previously, we had a simple averaging scheme going in the touchscreen<br>
driver that summed up 32 x and ys and then divided it by 32. This patch<br>
first tidies up the existing code for style, then adds a new "running<br>
average" concept with a FIFO. The running average is separate from the<br>
summing average mentioned above, and is accurate for the last n samples<br>
sample-by-sample, where n is set by 1 << excursion_filter_len_bits in the<br>
machine / platform stuff.<br>
<br>
The heuristic the patch implements for the filtering is to accept all<br>
samples, but tag the *previous* sample with a flag if it differed from<br>
the running average by more than reject_threshold_vs_avg in either<br>
axis. The next sample time, a beauty contest is held if the flag was<br>
set to decide if we think the previous sample was a one-shot excursion<br>
(detected by the new sample being closer to the average than to the<br>
flagged previous sample), or if we believe we are moving (detected by<br>
the new sample being closer to the flagged previous sample than the<br>
average. In the case that we believe the previous sample was an<br>
excursion, we simply overwrite it with the new data and adjust the<br>
summing average to use the new data instead of the excursion data.<br>
<br>
I only tested this by eyeballing the output of ts_print_raw, but it<br>
seemed to be quite a bit better. Gross movement appeared to be<br>
tracked fine too. If folks want to try different heuristics on top<br>
of this patch, be my guest; either way feedback on what it looks like<br>
with a graphical app would be good.<br>
</div><br>