James, that is great to know, thanks for clarifications on both parts! I did not see the details of the driver body itself in the patch hence questions :)
As for a kalman filter, the equation itself looks heavy [1] and would understandably have to be recalculated every frame unless an incremental variation can be created. The version I did initially with just taking fractions of each sample was easily achieved [2] and lightweight enough to be useful without consuming battery. I bet for the use I did it wouldn't make much difference, but in scientific situations it would be good to try. Regards, Gary [1] C implementation http://www.its.washington.edu/software/kalman_fil.html [2] Maemo wiki with Accelerometer smoothing http://wiki.maemo.org/Accelerometers#Smoothed_C_interface On Tue, Aug 31, 2010 at 5:23 PM, James <jketr...@linux.intel.com> wrote: > On 08/31/2010 05:34 AM, Gary Birkett wrote: > >> James, >> >> A question about the patch for capacitive >> >> " cy8ctmg110: Added fuzz to ABS_X and ABS_Y to remove jitter" >> >> I cannot determine from the patch what it does, does it reduce the >> resolution down to 4 unit blocks, or does it still allow single unit >> sensitivity whilst removing jitters from around it? >> > You can see drivers/input/input.c input_defuzz_abs_event() for > implementation details on how fuzz is used internally within the input > system. > > The result is that jitter around a stable point is reduced; the device > still retains the same total sensitivity, but once a contact point is made, > the data has a tendency to stick to that value until the threshold is > crossed. > > >> If it it indeed the resolution limiting, perhaps something I did in the >> past to remove jitter from the very noisy accelerometer might be another >> alternative. >> >> At each new reading from the sensor, I would move the "cursor" a >> percentage fraction closer to that point rather than directly using it. >> > A kalman filter (or similar predictive algorithm) is also a great way to > remove noise from an accelerometer, without introducing latency into the > sensor read path. > > James >
_______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
