Reputation: 963
I'm working on a calculation-intensive app that happens to listen to sensor data (acceleration, but also angular velocity). After a couple filters, these vectors are integrated to track displacement.
I have noticed that the timestamps associated to CMDeviceMotion and CMGyroData are late, because my CMMotionManager's handlers aren't fired at 100 Hz as specified by its accelerometerUpdateInterval and gyroUpdateInterval. It starts around 60 Hz and goes up and down. This affects the integrations majorly.
The same code in a stand-alone app does 100Hz like a charm.
So it looks like computation peaks from other modules of the big app make the sensor updates lag. Which surprises me, since the sensor manager is on a thread of its own and I understood from the doc that the sensor events were triggered by the hardware.
My question is: when the timestamp is unreliable as described, can the data still be used? Can it be extrapolated using another clock?
And I'm confused why big, asynchronous computation on other threads can lag the accelerator updates.
Thanks, Antho
Upvotes: 2
Views: 539
Reputation: 58511
Bad timestamps are just as bad as inaccurate data since they have the same effect on the integration.
About 50 Hz is enough to track orientation. I was wondering how you track displacement because it is impossible with current sensors.
Upvotes: 2