c-d.hailfinger.devel.2006 at gmx.net
Wed Jun 18 18:51:01 CEST 2008
On 18.06.2008 16:51, Andy Green 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.
Clever, but it will spoil your average if there are two subsequent bad
samples. From your description, it will even fail if the two subsequent
ba samples deviate in opposite directions.
> 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.
Unfortunately, I won't have time in the next 3 weeks to code up my
suggestion, but I think my suggestion of a 5-value median at 5 times the
rate or a 5-value running median at the normal rate should handle two
subsequent erratic samples a lot better. The only disadvantage of my
method is a 2-sample delay for movements (to be honest, for any
"natural" movement the delay is more like 1 sample). AFAICS the
computational cost should be even less than the averaging method because
my methods do not need division which is quite costly on some processors.
More information about the openmoko-kernel