Many system designers have faced the challenge to optimize sensor components selection based on use cases they plan to support. This article examines the key classes of use cases and discusses their demands on the resolution, bandwidth and dynamic range of various sensors.
The resolution of a sensor refers to the finest measurement it can discern. This depends on two factors: the number of quantization levels available to a digital measurement and the noise experienced by the sensor. For example, a 12-bit sensor can cover a 72dB range while a 16-bit sensor covers a 96dB range. But if background noise for a sensor is higher than -72dB, a 16-bit sample would not capture any more useful information than a 12-bit sample.
Bandwidth refers to the frequency range a sensor measures with fidelity. For inertial sensors, low bandwidth measurements result from slow motions. A sensor set to capture low bandwidth data will distort the result of a fast movement. As discussed in our previous blog, it is prudent to optimize inertial sensor bandwidth to the movement it is expected to capture.
The dynamic range of a sensor determines the largest amplitude the device can capture. If the dynamic range of a sensor is set too high, part of the available precision would be wasted. If the range is set too low, the sensor could be saturated in normal operations and negatively affect output fidelity.
Use cases for inertial sensors in a mobile device fall broadly into three categories. The first class of use cases monitors largely an infrequently changing status, for example, landscape or portrait screen orientation. Conventionally, Android refers to this class of use cases as “UI.” The second class of use cases involves user interaction for which the user is actively moving the mobile device. Conventionally, Android refers to this as “gaming.” The third class of use cases involves dead reckoning (DR), estimating a user’s position based on a cumulative series of estimated motions over time.
The table at the end of this article summarizes the sensor component selection criteria driven by each class of use cases. The bandwidth requirement for the first classes (“UI”) of use cases is very low, because the status they monitor rarely changes. The bandwidth needed for user interaction (“gaming”) is 20 Hz (see the previous blog). If an application allows users to move the mobile device when it is performing dead reckoning, it must conform to the “gaming” bandwidth requirement, 20 Hz. Similarly, the amount of movements anticipated in a use case also affects the accelerometer dynamic range required.
The magnetometer should have sufficient dynamic range to handle any ambient magnetic anomaly, 0.6mT regardless if the use case includes any significant movement. It should be noted that most mobile devices contain a large magnetic field bias due to hard and soft iron on their bodies. Consequently, magnetometers often need to accommodate a large static offset in addition to the 0.6mT dynamic range.
Resolution requirements are use case dependent. For example, if an application expects to resolve orientation of 1°, it will require 10-bit resolution. However, many games and user interaction use cases can be satisfied with much coarser resolution. Because of dead reckoning error accumulates over time, a useful dead reckoning application will typically require 16-bit or better resolution.
Our future articles will discuss implementation and validation best practices to turn optimal sensor selection into optimal sensor systems.
