Changes in accelerometer / gyroscope limitations for iPhone 5 / 5th Gen iPod Touch?

Question

Back when the iPhone 4 and 4th Generation iPod Touch came out, I was toying around with Apple's Core Motion sensor fusion algorithms to see if I could get any interesting results for very local dead reckoning (over the range of a few inches or feet). I didn’t expect anything spectacular, given the relatively low specs of the MEMS sensors. And although Apple’s CMDeviceMotion gravity property uses a decent (though opaque) sensor fusion algorithm, the complementary userAcceleration property isn’t exactly targeted at dead reckoning. Still, I thought there might be enough there to have a bit of fun.

The iPhone 4, iPhone 5, 4th Gen iPod Touch, and 5th Gen iPod Touch all apparently use the STMicroelectronics LIS331DLH accelerometer and L3G4200D gyroscope. (Actually, I haven’t seen the part number for the iTouch-5 gyro yet, so it could be different.)

Teardowns: iPhone-4, iTouch-4, iPhone-5, iTouch-5

The ST specs show that accelerometer could sample at 1000 Hz up to ±8g. And that gyroscope could sample at 800 Hz up to ±2000 dps.

Specs: LIS331DLH, L3G4200D

But, playing with my 4th Gen iPod Touch (both iOS 5 and iOS 6), I can only crank the sampling rates up to 100 Hz. If I set CMMotionManager deviceMotionUpdateInterval any lower than 0.01, it automatically resets to 0.01. Same for accelerometerUpdateInterval and gyroUpdateInterval.

Further, the accelerometer output always seems to be capped at about ±2g.

I've seen others remark on similar bounds for the iPhone 4.

Both these bounds severely limit the local acceleration calculations I can squeeze out the device (experimenting with my 4th Generation iPod touch). I presume Apple has set these bounds low to reduce power consumption. Though I don’t know if they’re set in the hardware, or in iOS somewhere.

Has anyone played with these accelerometer and gyroscope bounds on the iPhone 5 or 5th Generation iPod Touch? (Or any iPads for that matter?) Any sampling rates higher than 100 Hz? Any accelerometer measurements outside the bounds of ±2g?

Answer 1

I was testing techBASIC on an iPhone 5 and noticed an anomaly that led me to this discussion. Apparently the accelerometer in the iPhone 5 is set to the 8G range! While I can't find any references to confirm it, techBASIC's accelerometer demo showed this when I shook the iPhone 5 up and down:

That's pretty exciting for physics applications. I used a SensorTag to measure the acceleration in a model rocket because it has an optional 8G range, and the iPhone did not--you can now dispense with the SensorTag and just use the iPhone.

http://www.youtube.com/watch?v=8YNjwcNXOK4iPhone Rocket

Answer 2

Of the reading I have done you usually have 2-3 choices when determining what min/max readings an accelerometer will read. 2G is an extremely common choice for accelerometers because the next step (8G) is usually to coarse a reading to get the fine measurements needed when working with a hand movement. If you were dropping it off a building to measure the force of hitting the ground you would want to use the 8G (or 16G as some offer).

It looks like the Hz is intentionally capped at 100Hz according to the folks at Corona Labs. It is to keep from abusing the battery apparently. I had read that the accelerometer is the least power hungry sensor but I guess it's all relative or there is a sharp increase in power use at some point around 100Hz.

Answer 3

To help answer the other half of your question, I am using an iPad Mini and when I use Warren Whipple's suggestion, I find that the accelerometerUpdateInterval and gyroUpdateInterval would be reset to 0.01 immediately if I set them to any lesser value.

However, when I run diagnostic tests on the device I find that the real rate at which the accelerometer or gyro data is updated is closer to 0.02 s, i.e. if I set the accelerometerUpdateInterval to 0.01 s and query accelerometer data at 0.01 s, I get a unique reading on every other fetch, but if I set it to 0.02 s (or query at 0.02 s) then I get unique reading on every fetch.