andy at openmoko.com
Thu Jun 19 10:13:13 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
| On 19.06.2008 01:14, Andy Green wrote:
|> Somebody in the thread at some point said:
|> | On 18.06.2008 22:46, Dale Schumacher wrote:
|> |> The averaging scheme seems overly complicated. Using a "median"
|> instead of
|> |> a "mean" (average) would automatically reject outliers and would also
|> |> the mid-point of a moving signal. There should also be less math
|> |> since you would only be sorting 2 sets of 32 values.
|> | Exactly what I suggested as well. I don't understand why people
|> | absolutely want to use averages and throw away outliers based on
|> | calculations. Maybe because the concept of "mean" is easier to grasp
|> | than the concept of "median". A median solves all these problems of
|> | having outliers with less math and better accuracy.
|> It's not a bad idea at all. You're quite right it "automatically
|> rejects outliers". But, it's going to get a bit slow as the number of
|> samples held in whatever the sorting structure is increases,
| The secret is to keep the number of samples exactly at 5. You remove the
There's also a question about how noisy one of the axes is, the hardware
may not play ball with this nice idea -- it is a nice idea -- of magic
number 5. Oldstyle averaging has good performance for "averaging
noise", jitter in the result can still come with this method if generic
noise is present and skews one set of 5 one way, and another the other.
~ Maybe some combination of mean and median gets the best result. I
don't think what ails the bad axis is quite as simple as perfect results
disturbed occasionally by an excursion, the raw samples seem to be all
over the shop anyway (hidden a bit by mean averaging) and occasionally
|> but if someone wants to send patches I'll be happy to be wrong.
| As I indicated before, I won't have time in the next 3 weeks, but if
| there is something to be done afterwards, why not? I lack the hardware
| to test, though, so I can only send untested patches.
I'm going to leave mine in until then, pending any complaints about
performance or a better implementation turning up.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel