Measurement Range

Measurement range refers to the span of measurement values the sensor can record between the lowest and highest possible values. Dynamic range of a sensor refers to the span between the largest and smallest values two consecutive samples can take. Some sensors have dynamic ranges that cover their whole measurement range; for others, dynamic range is a subset of the total measurement range (see figure). In the latter cases, the bias can be charged either through register settings or be adjusted automatically by an intelligent sensor based on the recent history of the incoming signal levels.

Many sensors offer a number of preset options of measurement and dynamic ranges that designers can select based on the signals they are trying to observe. A previous article gave the recommended range settings for common use cases for mobile devices.

Sensitivity

Often designers would talk about using a 12-bit sensor versus an 8-bit sensor as shorthand to represent the sensitivity they wish to deploy. Sensitivity refers to the smallest signal resolvable by a sensor. It is affected by dynamic range, quantization level and the noise of a sensor.

Characterizing a sensor as a 12-bit sensor is to say that it has 4096 (nominally uniform) quantization levels across its dynamic range. Sensor sensitivity is rarely limited solely by the size of its quantization level. The determinant usually lies with the measurement noise of the sensor.

The RMS measurement noise of a sensor is the product of its noise power spectrum density and the square root of its measurement bandwidth. Hence the following equation gives the sensitivity of a sensor.

Zero-Offset Drift

Sometimes zero-offset drift is simply called “drift” of a sensor. By the nature of their design, the zero reference of a sensor changes slowly over time. Drift occurs due to a combination of reasons stemming from the design of the sensing element and the associated electronics. Drift increases over the life of a sensor so it is important to understand if the drift performance specified in a datasheet represent zero-offset shift over a ten year product life or just the initial value when the device is fresh off the manufacturing line.

Among inertial sensors, drift in gyroscopes are most significant. However, that can be mitigated by intelligent algorithms which, for example, can use magnetometer and accelerometer data to mitigate against gyroscope drift.

                                                      Sampling Scheme and Bandwidth

Sensor bandwidth can often be configured through a register. As Nyquist Theorem teaches, a sensor subsystem using a uniform sampling scheme must sample at twice the frequency of the desired bandwidth. Some sensors provide a mechanism for an external device to trigger the taking of a sample. That can be useful when the system sampling scheme requires all sensors to be sampled synchronously. Alternatively, sensors can provide sample at a regularly period based on its own time base. This mode is easier to configure but algorithms and system designs need to allow each sensor to free run on its own time base.

Abstracting over Sensor Component Differences

Understanding datasheet specifications can help designers differentiate among sensors from different vendors. However, designers need the freedom to use sensors from multiple suppliers without materially affecting the user experience of their systems. This challenge can only be answered by intelligent sensor fusion algorithms, like that offered as part of our FreeMotion™ Library.

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.

The two classes of use-cases normally considered for inertial sensors on handheld devices are user interaction and pedestrian navigation.  The former includes normal user interface to access phone, email, and browser functions as well as scenarios involving motion or augmented reality games.  The latter refers to using inertial sensors to augment other location services, like Wi-Fi and cell tower tri-lateration, to determine indoor positions.

The bandwidth of user movement ranges from near DC up to frequencies reaching 15Hz with biological signals such as muscle tremors (see Fig. 1).  So overall, measuring sensor signals up to 20Hz is sufficient to capture human generated movements.  The Nyquist-Shannon sampling theorem states a uniform sampling rate of 40Hz is needed to capture this information.

Increasing sampling much beyond this for user interaction could be a detriment as it leads to more integrated noise without gaining more information.  For example, take an accelerometer with a white noise density of 0.2mg/√Hz. Sampling at 50Hz leads to an RMS noise of 1.4mg but sampling at 1000Hz leads to an RMS noise of 6mg, or a loss of over two bits of accuracy without gaining any more information regarding user generated movements.

Noise density is the primary measurement of a sensor’s performance.  It can be visualized as representing sensor measurement jitter.  The larger this is, the less accurate sensor fusion results can be.  For example, if a magnetometer’s measure of North jumps around by 5 degrees, then the orientation output can also be off by 5 degrees.  Taking the Earth’s field to be 30µT (near the Equator) this means a magnetometer with an RMS noise of 30µT tan(5°)/ √2 = 1.9µT cannot achieve heading accuracy better than 5 degrees.  Note this is a noise density of 0.65µT/√Hz at 8Hz output data rate (ODR).

As human motion occurs within a 20Hz bandwidth, a magnetometer with an 8Hz ODR would not be able to capture most of the movement.  Using sensor fusion, gyroscope data can be combined with the magnetometer data to cover for the missing high frequency data.  However, activating a gyroscope adds significantly to power consumption.  So an alternative is to cover more frequency spectrum with the magnetometer.  Sampled at 40Hz, the magnetometer will be able to capture all human movements at significantly lower power consumption than using a gyro.  But to maintain the same 5 degree accuracy, the magnetometer noise must be kept at 1.9µT (RMS).  Consequently, the magnetometer noise density should be better than 0.13µT/√Hz.

Noise density also constrains the ability of a gyroscope to provide orientation dynamically.  A gyroscope with a noise density of σ introduces an orientation error of σ √(t/2) over time t.  If the magnetometer can be trusted, this integrated drift can be zeroed out periodically using sensor fusion.  But in the case of operating in an anomalous magnetic field (such as in a tall building or subway station) this error increases.  Requiring 5 degrees of heading accuracy after 2 minutes of free running gyro implies the noise density should be 0.06dps/√Hz at 200Hz ODR.

The sensor digital resolution should be enough to at least allow the desired noise floor to be achieved.  For example, a gyroscope with RMS noise of N₀ and range of ±2000dps requires log₂(2000/N₀) bits + sign bit + margin bit.  So if the gyroscope requirement is a noise density of 0.06dps/√Hz running at 200Hz, that indicates a 14-bit or better part is needed.  Depending on the use-case of the angular rate, it may be acceptable to saturate at 500dps, which would allow a 12-bit part to be used.

One other important sensor requirement is measurement repeatability. That is the variation in the sensor measurement against the same input signal.  For example, a sensor that exhibits hysteresis or some other non-linear effect degrades the ability to trust the measurement.  Although not reported in sensor datasheets, this repeatability error is sometimes a major contributor to the overall noise level.  It can only be neglected if it is at least 3dB less than the static noise.

The above analysis provides a method to estimate the resultant orientation accuracy for user interaction based on sensor noises.  Sensor performance in a system can also be affected by the properties of the specific sensor component and its environment.  We shall discuss in a future article how these can be eliminated by an algorithm performing an accurate background calibration.

The simplest sensor subsystems simply connect sensors to the application processor.  This arrangement has the benefit of being the lowest cost but it requires designers to have good control over the architecture of system software.  We have previously shown sampling a sensor at 100 Hz from the Java layer of Android results in so much time stamp jitter as to degrade the performance.  So doing would also takes up 50% of the application processors computing bandwidth and could cause other performance problems for the application.  Using native methods in Android drops the time stamp error to a manageable ±15% and CPU bandwidth to below 10%.  Better results are possible but only by replacing the Sensor Manager in Android to connect the hardware interrupts directly to software callbacks.

The most significant drawback of the simple architecture is power consumption.  Many sensor tasks like context or complex event recognition, step counting, and background sensor calibration needs to occur continuously in the background.  Waking the applications processor periodically to process background tasks can be expensive for battery life.

An architecture alternative often suggested involves a sensor hub.  A sensor hub is a processing element that can be dedicated to dealing with real-time demands from sensors.  It could be a standalone IC, integrated with sensors as a system in package (SIP), or implemented as a low-power core in a multi-cored application processor.  A sensor hub can better perform sensor tasks near real time and would consume significantly less power than the application processor when left running continuously for background tasks.  It can also combine sensor data and interpret them as events and interrupt the applications processor as warranted, infrequently.

The sensor hub adds cost to the system solution.  Their utility could also be limited by the amount of memory or computing resources available to the hub.  However, sensor hub implemented as a low-power core can leverage system memory and avoid memory limitation.

An intelligent sensor contains some or all the processing needed to convert sensor data to meaningful information.  Touch sensors, for example, have integrated controllers that convert capacitance changes into position information.  Smart sensors can support very fast sampling rates and be customized to the needs of the integrated sensor elements.  As such, they can perform context feature set detection or reduce sensor startup latency in ways unavailable to sensor hubs.  However, processing deployed on smart sensors are typically less flexible in function than those performed in sensor hubs.

Readers interested in reading more about sensor subsystem architecture should also look at the article Using available sensors in the Android Platform published in Mobile Developer Magazine.

• Java Activity using a SensorEventListener: the standard method to access sensors.
• NativeActivity using a ASensorEventQueue: provides a way to bypass the Java overhead, but requires activity registered in Manifest and utilization of android_native_app_glue.
• ALooper using ASensorEventQueue: little known method to add sensor sampling to any thread at the native level.

Java sensor sampling is easiest to implement but has large sampling time stamp uncertainties as covered in a previous blog entry.  It also can take over 50% CPU usage on a 1GHz processor to sample 9-axes of sensors at 100Hz.  This becomes prohibitive for heavy sensor usage.

In contrast, native sensor sampling on the same device takes less than 10% CPU usage to sample 9-axes of sensors at 100Hz.  Furthermore, the sampling is much more regular as shown in the figure.  Note that compared to Java-level access, virtually all the large deviations from nominal sampling are removed.  Furthermore, native-level access provides finer control over sensor sampling rate.  Rather than specifying a device-dependent SENSOR_RATE_GAME, it is possible to specifically request a sampling rate, such as 100Hz.  (Of course, whether the device can provide such sampling is still dependent on the underlying hardware.)

The Java method for sensor acquisition is well known and the NativeActivity method is provided as an example with the Android NDK.  Therefore, only the ALooper method will be discussed in some detail  here.  The ALooper method allows a shared library to access sensors without the Java side having to reference them at all.  This is how the Android version of the FreeMotion™ Library accesses sensors.

The steps to native-level access without a NativeActivity are:

1. Identify the looper associated with the calling thread, or create one if it does not exist.  A looper is a message loop for a thread and will handle the sensor event callbacks.
   
   ALooper* looper = ALooper_forThread();
   if(looper == NULL)
   looper = ALooper_prepare(ALOOPER_PREPARE_ALLOW_NON_CALLBACKS);
    
2.  As in a NativeActivity, get an instance of the Sensor Manager and each sensor
   
   sensorManager = ASensorManager_getInstance();
   accelerometerSensor = ASensorManager_getDefaultSensor(sensorManager, ASENSOR_TYPE_ACCELEROMETER);
    
3. Create a sensor event queue from the sensor manager and register it with the looper.  This needs to have a callback method (e.g. get_sensor_events) which is called when an event occurs.
   
   sensorEventQueue =   ASensorManager_createEventQueue(sensorManager, looper,  LOOPER_ID_USER, get_sensor_events, sensor_data);
    
4. Implement the callback method with the logic to use the sensor data.  It must have the following
   
   typedef int (*ALooper_callbackFunc)(int fd, int events, void* data);
    
5. Register the sampling frequency of the sensorEventQueue.
   
   ASensorEventQueue_setEventRate(sensorEventQueue, accelerometerSensor,
   (1000L/SAMP_PER_SEC)*1000); 

Regular sampling and low computing overhead are the foundations of a sophisticated sensor library.  Although this provides a much better method to access sensors, there is still room for improvement.  Sensors are built to provide regular sampling of data.  Therefore it is natural to use an interrupt-based method.  While it seems that is being done in Android, the callback is performed by the Sensor Manager (step 3) which itself uses polling to access the sensor (step 5).  To get the best sampling performance, our FreeMotion™ library replaces the libsensors.so sensor library and work with the sensor drivers directly in embedded Linux.

In an earlier article, we discussed that sensors and sensor subsystem architecture can be a major source of fragmentation that would continue to frustrate app developers for smart phone and mobile devices.  As the industry embarks on creating a new class of situation aware mobile devices, it is key to establish and improve sensor system standards.

For example, the Khronos Group through its StreamInput working group has identified “system-wide sensor synchronization for advanced multi-sensor applications” as an area in which standards is lacking. Indeed, for an application to, say, use inertial sensors to track camera angles it is necessary for the accelerometer, magnetometer, and image sensors to share the same timing reference.

Each sensor, today, runs on its own free-running clock and relative timing among samples are not defined.  Synching up sensor data with video would mean that every set of sensor data is tagged with a corresponding video frame number.  At 60 frames per second, this would be a relatively simple task that can be handled using only software.  However, if the application requires synchronization to occur at a scan line, or about 64kHz, it will require some hardware support to generate a time stamp for each set of sensor data.

Establishing a timing standard is but one fundamental area an open standards group like Khronos can contribute.  A minimum guaranteed sensor performance is another aspect that needs to be established.  Performance characteristics such as sensor bandwidth, accuracy and repeatability and latency are different among smartphone models running the same operating system.  We are hopeful that new operating systems like Android and Windows 8 will start to establish some of these requirements.

Going beyond minimum performance, an open standard is necessary to allow innovators access to richer sensor content.  For example, a smart algorithm might be able to use inertial sensors to detect when a smartphone is inside an elevator.  Such a new function would be released in a sensor library and an open standard will have to establish a method by which a mall map application can see that the capability exists and use it to serve up different maps to the mobile user.

We receive many recurring questions from Android developers.  This is a series of articles to help with clarification.

Developers often ask for clarification with respect to the list of sensor types list in Android documentation (see below).  The list can be confusing because it includes both physical sensors and sensor types with values derived from physical sensors, sometimes these are called virtual sensors.

Physical sensors include the accelerometer, gyroscope, light sensor, magnet field sensor (often called magnetometer), pressure sensor, proximity sensor, and temperature sensor.  The values from these sensors are provided by hardware components directly measuring changes in the physical property of their environment.

The quality of data from these sensor types depends fundamentally on the accuracy, resolution, inherent noise, and repeatability of the physical sensors.  However, proper system implementations such as sampling scheme and calibration are necessary to take advantage of the full potential of the underlying hardware.

The virtual sensors types (gravity, linear acceleration, and rotation vector) provide values derived by combining the results from physical sensors intelligently.  The rotation vector is a combination of the accelerometer, the magnetometer, and sometimes the gyroscope to determine the three-dimensional angle along which the Android device lays with respect to the Earth frame coordinates.  By knowing the rotation vector of a device, accelerometer data can be separated into gravity and linear acceleration.

The quality of virtual sensors depends not only on the quality of physical data but also on the sophistication of the algorithms used to derive them.  Because the rotation vector depends on accelerometer and magnetometer values, its accuracy is affected by user movements and ambient magnetic anomalies.  Gyroscopes can be used to mitigate these issues at the expense of higher system cost and higher power consumption.  Heuristics and better models of human body dynamics can also be used to overcome these problems for normal usages.

Cameras, GPS, WiFi and the microphones can all be used to sense movements and locations.  However, they do not have any influence on the results from the sensors.  It remains for applications, or for intelligent middleware like our FreeMotion sensor library, to combine all the sensory data available on an Android platform to provide the best available information.

Pedestrian maps are becoming more useful.  Not long ago, mobile mapping applications like Google Maps in pedestrian mode often gives the same directions as in vehicle mode except it would ignore one-way traffic restrictions.  Now, pedestrian mode direction will take the user to overpasses and underpasses to cross a street.  Of course, indoor maps are still emerging and a standard way to handle maps for multi-storied buildings remains lacking.  However, proprietary and open source libraries of indoor maps and 3D mirror worlds continue to increase.

Sensor and RF hardware used for position tracking are inexpensive and becoming prevalent in smartphones and tablets.  Although the primary location provider on these devices today is GPS, GPS signals are not reliably available.   While designers are improving the sensitivity of GPS receivers to make them work better indoors, the mobile industry is also investing in alternatives to GPS for location services.

One alternative to GPS is to use the cellular signals to estimate the users’ distance from nearby cell towers.  Using estimated distance from three or more cell towers, users can trilaterate and estimate locations.  However, cell phone users, already frustrated by poor coverage and dropped calls, understand that cellular signals are not always reliable either.  Signal reflections can also result in large position estimate errors.

Another alternative is to use Wi-Fi fingerprint matching.  There are many databases that record the Wi-Fi signatures of physical locations.  A program can compare the Wi-Fi signature detected by a smartphone against one of these databases, and make an educated guess on the user’s location.  This method is obviously limited by the coverage and accuracy of the fingerprint databases.  Accessing the fingerprint databases could also be expensive depending on the users’ data plans.

A third alternative  is to use sensors (accelerometers, magnetometers, gyroscopes, and soon, barometers) on smartphones to implement dead reckoning, which is the process of estimating a user’s current position based upon a previously determined position, and then advancing that position based upon known or estimated speeds over elapsed time and course.  The advantage of dead reckoning over cell tower trilateration, or Wi-Fi fingerprint matching, or even GPS, is its always-on availability to the user.  However, since the new position is calculated solely based on the previous position, the estimation error accumulates over time.  Today, dead reckoning solutions are commonly deployed with first responders; for example, to guide a rescuer in a fire scene.  In these applications, sensors used for dead reckoning are securely attached to the clothing or footwear of the users.  Moving the sensors to a smartphone will require a dead reckoning solution to differentiate between movement of the users’ travel from extraneous and incidental hand motions.

As none of the three alternatives above alone can resolve all the challenges, the final and necessary ingredient to bring pedestrian navigation to fruition is an intelligent algorithm.  GPS, cellular signals and Wi-Fi can be used to put an upper limit on the estimation error from dead reckoning, while dead reckoning can fill in the gaps when the other methods are unavailable.  While each method by itself can be prone to errors and outages, a smart algorithm can use all the methods together to compensate for the weakness of each other.  It can also leverage maps and even camera images to further refine and pin point the user’s location.  As these pieces come together, true pedestrian navigation will be at hand.

Today, smart phones and tablets use sensors to understand user context in a few primitive ways.  Turn the tablet from portrait to landscape orientation and the content of the display reorganizes to try and fit the display.  Bring the smart phone to your ear and the touch screen turns off (OK, many phones still needs to work on that one).  But with more sophisticated algorithms and heuristics, the sensors can do much more.

How about a smart sensor system that knows when you are getting in or getting out of a car?  For starters, users can send all incoming calls, except those coming from their families, to voicemail while they are driving.  Then there are those “car finder” apps today that can bring a driver back to his car if he starts the app after he has parked.  We have been suspicious of the utility of such an app: if we had the presence of mind to start an app when we left the car, we would probably be able remember where we has left it without any navigation aid.  So it would be more useful if smart sensors automatically trigger the navigation system to remember the location where we got out of our car for those absent minded moments we all have.

A new smart phone now contains two cameras, an accelerometer, a magnetometer, a gyroscope, a proximity sensor, a light sensor, and two or more microphones.  These sensors capture a huge amount of data that can be used to inform and entertain consumers.  At the same time, these data also capture the reality surrounding the users.  Applications running on the phone can process the data and mine for information that help them adjust their configurations automatically to better match where the users are and what they are doing.

Concerns for privacy notwithstanding, consumers do look forward to smart phones that can become truly smart, mind-reading, assistants.  The first step towards that is having smart phones that can automatically infer user context.  Kenneth Noland, the America abstract painter said it well, “context is the key – from that comes the understanding of everything.”

This series has previously touched upon the importance of system architecture and intelligent algorithms in providing optimal sensor performance in a smartphone or a tablet.  To complete the discussion of the sensor system, platform designers also need to select good sensor components.  This article uses the magnetometer to highlight the impact of these three factors.

The magnetometer is commonly found on mobile devices such as smart phones and tablets, but it is one of the most difficult sensors to interpret.  It is commonly called a compass since it measures the strength of the magnetic field in three dimensions, but does not necessarily point north.  In fact magnetic interference can cause it to behave unpredictably, as often seen in augmented reality apps.

In an environment free of magnetic interference, the magnetometer measures Earth’s magnetic field which combined with gravity (measured by an accelerometer) can be used to determine the 3-dimensional orientation in which the phone is being held.  The cardinal directions with respect to any orientation of the device can then be determined and used to display contextual information, such as tracking the nearest subway stations as a phone is moved around.  If the phone also knows its rough geographical location, a compass app can translate magnetic north into true north.

The figure above shows the power spectral density (PSD) of two stationary magnetometers measuring the same ambient magnetic field.  Yet, their results look different in many ways:

• The two sensors have different noise floors (sensitivities).
• The maximum measurable frequency for magnetometer A is 25 Hz but for B is 50 Hz.
• The shape of the PSD is completely different.  The spectrum from Magnetometer A shows a 3.3 Hz ripple.  The spectrum from Magnetometer B is largely flat (as expected for white noise).

Differences in sensor physics account for the noise disparity.  Magnetometer A is a Hall effect sensor, a transducer that varies its output voltage in response to changing magnetic fields.  Hall effect sensors are inexpensive to make but consume higher power and provide less precision than many alternative sensing technologies.  Magnetometer B is an anisotropic magneto-resistive (AMR) sensor.  AMR sensors use a thin film of ferromagnetic alloy that changes resistance according to an ambient magnetic field.  They offer better accuracy, higher bandwidth, and more temperature stability than Hall effect sensors.

The PSD plot for Magnetometer A shows noise density envelope higher than -65 dB at 5Hz.  In contrast, the noise density for Magnetometer B is around -80dB.  Since human movements occur at low frequencies, noise spectral density below 10 Hz is an important performance determinant.  Higher noise power will interfere with the sensors ability to detect small changes, or fine movements.  Furthermore, filtering or averaging to reduce noise limits the utility of the sensors: a point we shall discuss later in this article.

Second, the upper limits of the PSD plots reflect the sampling rate used for each sensor.  Magnetometer A is sampled at 50 Hz while Magnetometer B is sampled at 100 Hz.  Higher sampling rates can improve filter and algorithm responsiveness but could also consume more power.  An optimal system design should include an intelligent resource manager that throttles sampling rate based on application demand to conserve system battery life.

Third, the ripple in Magnetometer A’s spectrum is the result of an averaging filter.  Apparently, to reduce the effect of sensor noise, each data point provided by the sensor is actually a running average of the current raw sample and the 14 preceding raw samples.  This results in a low passed signal that erodes motion data faster than 3.3 Hz and makes Magnetometer A poorly suited to measure user movements.  As Magnetometer A is commonly used in many smartphone models, this averaging filter contributed to the erroneous conception that magnetometer has low bandwidth.

Indeed, the spectrum for Magnetometer B is largely flat.  It suggests that the sensor data has not been artificially altered in any way and high frequency response has not been compromised.  Incidentally, the peaks at 20 and 40 Hz are the aliases of the first and third harmonic of the magnetic field created by 60Hz A/C currents (in the United States).

So far, we have focused on the noise and bandwidth of the magnetometer measurements.  However, even with the cleanest sensor data, a compass app still requires an algorithm to interpret them to find magnetic north.  Specifically, calibration is needed to remove the effects of ferromagnetic materials in a mobile device so that Earth’s magnetic field can be properly detected.  These materials include the maganese found in the battery (which constitutes hard-iron effects) and nickel found on the printed circuit boards and on component leads (which constitute soft-iron effects).  The magnetic alignment of these materials change when exposed to external magnetic fields, such as electro-magnetic field of a refrigerator motor or the permanent magnet on the buckle of a smartphone holster.  Many smartphones in production today, feature inferior calibration algorithms that can be confused by external magnetic fields and lose their compass heading (video link).

In summary, this article has illustrated some of the key sensor system considerations to create a useful compass app.  Good sensor performance relies on proper designs in three aspects: sensor component selection, sensor system architecture, and intelligent sensor algorithms.  Failure in any one will compromise the utility of the sensor.