Toward a solution for the iPhone 5S accelerometer problem

Eagle Jones, PhD, CEO, RealityCap

Update: It turns out that Chipworks misidentified the accelerometer in the iPhone 5S, so some of our conclusions may not be supported. Please see this post for an update.

There has been a ton of speculation in the media and in user forums over what’s going on with the iPhone 5S accelerometer: see CNET, Gizmodo, ExtremeTech, Apple Support Communities, or MacRumors. In short, apps that use the accelerometer to sense device tilt are showing errors of as much as 5-6 degrees off level, when these apps worked fine with previous iOS devices. This can be seen in many games as well as tools like level apps, including Apple’s built-in compass/level app.


Left: iPhone 4S; Right: iPhone 5S

People are asking whether this is a hardware shortcoming, manufacturing issue, or software problem. Quite definitely, the answer is that these issues exist due to hardware design. The Chipworks teardown of the iPhone 5S identified the accelerometer as the Bosch Sensortech BMA220. Previous Apple devices have been reported to use ST parts, such as the LIS331DLH in the iPhone 5 (according to iFixit).

Accelerometers have two key numbers that tell you the quality of their outputs. Note: in the spec sheets, and the next couple paragraphs, the abbreviation mg refers to milli-g, or one one thousandth of standard gravity, not milligram. The first key spec is the noise density (ST) or output noise (Bosch). This tells you how much random jitter you will see in measurements. At first it looks like the spec for the Bosch part is much worse, but this is deceiving as these numbers are reported for a specific measurement rate (bandwidth), and the ST datasheet doesn’t specify that rate. In our measurements, the noise output of the accelerometer in the iPhone 5S is reasonably similar to that of previous iOS devices.

The second key spec for accelerometers is the zero-g offset, or bias. This indicates the range for a roughly constant offset that will be added to every output sample of data due to manufacturing variance. This can also change over time due to mechanical stress or temperature variation. This is where we find the problem: the typical bias for the ST part is +/- 20mg, while the Bosch part lists +/-95mg. This almost 5x greater offset range is confirmed by our measurements, and is absolutely consistent with the failures being reported by users and the media. Specifically, a +/- 20mg offset range would translate to around a +/-1 degree accuracy range in tilt detection, and a +/-95mg offset translates to +/-5 degrees in tilt.

Here are the ST LIS331DLH datasheet, and the Bosch datasheet.

Both parts cost about $1 in quantity, so it’s hard to believe Apple would make this design choice due to cost. Perhaps Apple chose the Bosch part based on power consumption in conjunction with background motion processing on the M7 coprocessor? Both parts consume 250μA in normal mode and offer low power modes that consume 10μA or less. The Bosch part takes a 1.8V supply versus the ST chip’s 2.5V supply. Therefore, in normal mode the Bosch part uses 450μW and the ST part uses 625μW. Even if the accelerometer were fully powered up at all times, this 175μW difference would make less than a 0.1% difference in the iPhone 5S battery life (assuming the 5.92Wh battery normally lasts for 24 hours of mixed usage). If the ST accelerometer were the only part in the phone that required a 2.5V supply, then it might make sense. However, even this seems like poor justification for the inaccuracy that can clearly be seen in Apple’s built-in compass/level app.

So what can developers who depend on reasonable accuracy from the accelerometer do? The good news is that a large component of the bias error in the accelerometer doesn’t change. Thus it is possible to work around the problem by incorporating a calibration procedure into apps. This procedure would ask the user to place the device in different orientations to determine the accelerometer bias. Apps can then subtract this measured bias from the data coming from the accelerometer to get a corrected reading.

Stay tuned to our blog – we’ll have a new post with more specifics on how to implement this solution in the near future.