1. Tried to use event.timestamp instead of System.currentTime
Still the same result: device skips some measurements. Many times,
this is detrimental
to being able to produce an accurate drawing of the phone motion.
Some important acceleration
peaks are missed. One way to combat this problem may
I'm not 100% familiar with this aspect of the G1, but I know Nintendo
had a similar problem with their Wiimotes. That's why they have the
sensor bar set up: they couldn't get their accelerometers to be
accurate enough to track position.
On Jul 9, 2:23 pm, dilit dmit.lit...@gmail.com wrote:
D, I'm having many of the same issues, though my app is a little
different in nature ... i don't know that this will help much, but
here's my thoughts so far:
- when determining the sample time rate use event.timestamp in your
sensor listener callback. you'll see more or less the same results,
Just in case,
We did calibrate our phones.
E.g. My phone's Gravity value is more like 8.7 vs 9.81.
While static, the phone's accel values were acceptable.
As soon as the phone was in motion, the acceleration (position)
data went out to lunch.
FYI, marketing = lying 99% of the time. IMO
On
Sounds like some signal processing/filter math is in order.
http://www.cs.unc.edu/~welch/kalman/
Anyone with experience?
D
On Jul 9, 1:18 pm, dilit dmit.lit...@gmail.com wrote:
Just in case,
We did calibrate our phones.
E.g. My phone's Gravity value is more like 8.7 vs 9.81.
While static,
5 matches
Mail list logo
