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. Regards, Carl-Daniel -- http://www.hailfinger.org/