One of the most common questions we hear from mobile applications developers is, “how good are the sensors on my phone?” This article is part of a series that provides a framework to understand sensor performance.
In the last blog article, we discussed methods to interpret the physical state of a mobile device based on sensor measurements. Most algorithms fundamentally rely on regular simultaneous sampling of the sensor data. For example, navigation-grade inertial measurement units often employ 100Hz sampling of all 10 axes. This creates a real-time data flow requirement for sampled sensor data.
Many smartphone system architectures that do not sufficiently account for sensor data flow can degrade performance. Common problems are:
- Sensor interrupts are handled by the application processor. Smartphone operating systems like Android or iOS are not real-time operating systems. Using a non real-time operating system to acquire sensor data often leads to incorrectly recorded sampling timestamps and fictitious timing jitter. In some cases, timestamps can seem to go backwards making the resulting data unusable by most applications. Refer to the figure to see an example in a commercial Android device with sensors set to sample at 100Hz. The nominal period between two consecutive samples should be 10 ms but some timestamp values show intervals from -50 ms to 230 ms!
- Sensor data collection task priority is set too low. For example, in Android, when the Dalvik garbage collector kicks in, sensor data can be missed for as long as 200ms. This can disrupt motion tracking or game response.
- Sensor bandwidths are set too low to meet applications requirements. Just because sensors have 12-bit precision (or better) does not mean they provide that level of accuracy. In some sensors, a low-pass filter is applied in hardware to filter out the “noise.” Consequently, higher bandwidth sensor data is lost, making it difficult to track even moderate bandwidth signals, like normal hand motion, with such sensors.
Intelligent algorithms can mitigate these system level issues. Sample timing can be tracked, data gaps can be estimated and sometimes interpolated, and less effective sensors can be supplemented and results improved using data from other sensors as the last article described. These algorithms run as drivers on a small portion of one core, providing a way to overcome system limitations and differences.
To support the broadest application requirements, smartphone system architecture can be supplemented with hardware to assist in real-time sensor sampling. Hardware assistance can be a sensor hub, with dedicated computational resources for the sensors, or just a smart DMA engine to perform the real-time data collection. This is analogous to what hardware accelerators and GPUs do for gaming and video applications. Hardware-assist resolves cases such as 1 and 2 above. Cases such as (3) above still require good, efficient algorithms. In fact, even when all sensors can be sampled reliably, algorithms are useful to ensure seamless repeatable performance of sensors across different manufacturers and overcome variations in sensor performance.
