Sometimes the computed gravity value is above normal (one instance it was about 12m/s^2). This isn't suppose to happen since the situations where the accelerations the phone is exposed to are above G, aren't common.
The proposed cause is as follows:
Based on how the Timer class works, a delayed call causes future calls to be invoked in rapid succession. It could be that because of a delay, multiple samples are taken in rapid succession, and they just happen to be within the high peak of a step (which can be upto 0.1s long). At 2-5ms per sample call, up to 50 calls could be made in the 0.1s period leading to a significant increase in the mean.
Proposed solution:
Include a feedback channel from the computation thread, so as to reinitiate sampling when the previous sample is deamed unusable, without waiting for the 30s delay to end.
Sometimes the computed gravity value is above normal (one instance it was about 12m/s^2). This isn't suppose to happen since the situations where the accelerations the phone is exposed to are above G, aren't common.
The proposed cause is as follows:
Based on how the Timer class works, a delayed call causes future calls to be invoked in rapid succession. It could be that because of a delay, multiple samples are taken in rapid succession, and they just happen to be within the high peak of a step (which can be upto 0.1s long). At 2-5ms per sample call, up to 50 calls could be made in the 0.1s period leading to a significant increase in the mean.
Proposed solution:
Include a feedback channel from the computation thread, so as to reinitiate sampling when the previous sample is deamed unusable, without waiting for the 30s delay to end.