touchscreen sampling

[Dale Schumacher]

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.

On Wed, 18 Jun 2008 15:51:08 +0100, <andy at openmoko.com> wrote:
...
Touchscreen on GTA01-02 experiences noise on the channel that serves the
"tall axis" of the LCM.  The sample quality of the other axis is good.
The bad samples have a characteristic of one shot excursions that can
reach +/- 20% or more of the sample average.

Previously, we had a simple averaging scheme going in the touchscreen
driver that summed up 32 x and ys and then divided it by 32.  This patch
first tidies up the existing code for style, then adds a new "running
average" concept with a FIFO.  The running average is separate from the
summing average mentioned above, and is accurate for the last n samples
sample-by-sample, where n is set by 1 << excursion_filter_len_bits in the
machine / platform stuff.

The heuristic the patch implements for the filtering is to accept all
samples, but tag the *previous* sample with a flag if it differed from
the running average by more than reject_threshold_vs_avg in either
axis.  The next sample time, a beauty contest is held if the flag was
set to decide if we think the previous sample was a one-shot excursion
(detected by the new sample being closer to the average than to the
flagged previous sample), or if we believe we are moving (detected by
the new sample being closer to the flagged previous sample than the
average.  In the case that we believe the previous sample was an
excursion, we simply overwrite it with the new data and adjust the
summing average to use the new data instead of the excursion data.

I only tested this by eyeballing the output of ts_print_raw, but it
seemed to be quite a bit better.  Gross movement appeared to be
tracked fine too.  If folks want to try different heuristics on top
of this patch, be my guest; either way feedback on what it looks like
with a graphical app would be good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080618/ad271ed3/attachment.htm