MEMS, MCUs and Tradeoffs for Sensor Fusion
An explosion in the use of inertial MEMS and sensors in consumer and industrial applications begs the question: Where is the best place to process and interpret data from those sensors?
The last couple of years have seen an explosion in the use of inertial MEMS and related sensors in the consumer and industrial spaces. Along with that has come the need to interpret data from those sensors. Where to do that processing can be a complex question. There is no one correct answer, as each system designer may have different priorities. You, as system designer, need to determine how you rate each of the following in terms of overall importance to your product and business:
- Accuracy of fusion outputs
- Area / space considerations
- Ease of integration
- Cost and flexibility in your supply chain
Let’s start in reverse order. In the gray market, the number one priority is often either cost and/or supply chain flexibility. In this case, the OEM will often go with a least common denominator in terms of both sensor and MCU selection. In phones and tablets, the MCU might be omitted entirely in favor of doing fusion directly on the apps processor.
|Figure 1: Least-common denominator sensor fusion relies on the apps processor.|
Individual sensors (accelerometers, gyroscopes, magnetometers, etc.) may be a checkbox item, and one vendor’s sensor may be swapped out for another to ensure lowest cost or uninterrupted supply chain. The consumer will normally pay for this by having to accept higher power consumption and limited functionality. Apps processors (APs) consume a fair amount of power when operating, and take a significant amount of time when transitioning to and from low power states. Separate interrupts from each sensor exacerbate this problem. In addition, the OS running on the apps processor normally doesn’t support real-time processing, thereby limiting the types of applications that can make use of sensor data.
The easiest integration is normally supported with a sensor hub, which encapsulates real-time processing of sensor fusion. A first-generation system is shown in Figure 2.
|Figure 2: First-generation MCU sensor hub encapsulates real-time sensor data processing.|
Fast transitions to and from low-power states, as well as low interrupt latency, should factor into the choice of MCU for this system. Because fusion occurs on the MCU, the apps processor can access data on an as-needed basis. The reduced power demands on the AP more than make up for the power consumed by the standalone MCU. However more board space is consumed and the system cost will go up by the cost of the MCU and associated passive components.
Developing the system of Figure 2 can be a daunting task for those attempting to design their first system incorporating sensor fusion. Fusion algorithms are complex, and require a lot of engineering effort to create. But it can be a very easy system from an integration perspective if the sensor manufacturer supplies the fusion software running on the MCU. It’s even easier if that manufacturer supplies schematics and layout information for the subsystem (see Figure 3).
|Figure 3: Freescale’s 12-Axis Xtrinsic sensor reference platform for Windows 8.|
Advances in MEMS and packaging technology have allowed sensor manufacturers to combine some of the sensor types shown in Figures 1 and 2. If cost and/or board space are most important, more sensors in a common package will often make sense. If accuracy is most important, you may want to keep the magnetometer packaged separately from the accelerometer and gyro. Magnetic interference will typically be least at the edges of your PCB, whereas accelerometers and gyros operate best when at the center of gravity of the device. Similarly, your pressure sensor will want to be placed where it can be vented to the outside world (possibly near your microphone).
The system of Figure 2 can further evolve into two different directions. The most efficient from a power perspective may be to add a separate MCU, equipped with its own power and clock management, onto the same die as the AP. This generally is not an option today. Even when (and if) it is offered by AP manufacturers, you still have the question of who provides the software for the fusion subsystem.
The alternate approach is to integrate the MCU with one or more of the sensors. Freescale calls this an “intelligent sensor hub,” and introduced the concept with the announcement of the MMA955x family of devices in 2011. Other vendors (notably Bosch and ST) recently announced devices with integrated MCUs; and Freescale is expected to announce an additional product shortly.
|Figure 4: Intelligent sensor hub integrates the MCU with one or more of the sensors|
When selecting an intelligent sensor hub, you want to check to see if the vendor simply bolted on an MCU to an existing sensor, or optimized the system for sensor fusion. Generally, this is synonymous with optimizing for power. Let’s look at some of those optimizations in the context of the system shown in Figure 4.
Memory: Intelligent sensor hubs will tend to operate from Flash memory. Both Flash and RAM are expensive resources in terms of die area and cost. Do you have enough memory to do the job? Alternately, are you paying for more memory than you need? Is the RAM/Flash ratio appropriate for your application? Fusion algorithms typically need more RAM than basic control applications. One KB of RAM to every three or four of Flash is probably appropriate for fusion applications. You won’t want to go with less. It’s easy to want more. Flash memory tends to be the slowest memory in the system. Is the performance of your system hobbled by Flash access? Or do you have some type of Flash cache or look-ahead buffer?
Clock domains: Can the slave port interface, responsible for communication with your system master, work even when the sensor hub is in a low-power state? And just how low is low? Ideally, you would like the ability to shut down all clocks on the hub. That implies your serial port needs to be externally clocked. Most standard MCUs treat serial port clocks as data, sampling them at 2X or 4X the data rate. This chews up power, but guarantees no issues when data crosses clock domains inside the hub. An MCU optimized for the hub will not force you to make this choice.
Clock rates: How fast can you transition the system from a slow clock rate to a fast one, or back? Phase locked loops are common functions used by MCUs to multiply slow clock frequencies up into a useful range. They work great, but consume (by sensor standards) gargantuan amounts of power and take a while to lock onto the final frequency. The system shown in Figure 4 utilizes a single oscillator that switches between two frequencies on an as-needed basis. Internally derived clocks often vary by 1% to 3% over temperature. Depending on your application, you may not care. But if you do (and you do if you are integrating a rate), consider using a slow external time base as input to one of the on-chip timers. Measure the external clock in terms of internal clock cycles, and dynamically adjust your frame rate based on the observed ratio.
Sample rates: How do you manage your sample rates? The system of Figure 4 includes a custom frame interval counter that ensures a constant frame rate, regardless of the amount of time spent in high/low frequency modes of operation. If your device has a crystal oscillator, is it of a modest frequency (32KHz) so as to not burn excessive power?
ADC accuracy: How many effective bits of resolution do your converted results have? Is there a tradeoff for conversion accuracy versus speed of conversion?
Hardware accelerators: Does your intelligent sensor hub offer any options to perform (in hardware, with no CPU intervention) recognition of key motion events? How general is the engine? Similarly, if portions of algorithms are implemented in hardware, are they generic enough for you to use, or do they require that you use a specific fusion library?
Other devices: Are there limitations in terms of what other devices can be mastered by your intelligent sensor hub? Do you have sufficient bandwidth? RAM for buffering? MIPS for computation?
Openness: Is your hub fixed-function, or do you have the ability to customize the code on it? Are the libraries and tools necessary to do this available? If using Android, are drivers and custom Hardware Abstraction Layers (HALs) available? If using Windows 8, does the hub manufacturer provide HID/I2C or HID/USB interfaces?
Generally all of the above will drive system designers into one of two directions: the minimalist vanilla set of sensors relying upon higher level software functions for fusion; or highly integrated sensor sub-systems and reference designs created by sensor manufacturers for ease of integration and customization. Your job as system designer is to know what questions to ask to ensure you select the right solution.
Mike Stanley manages the consumer Systems & Product Definition team in Freescale’s Sensors & Actuators Solutions Division. He blogs on sensor topics at http://blogs.freescale.com/author/michaelestanley/.