Wearable Electronics: Four Approaches to Implement a Sensor Hub and Save Power
As more sensors are added to nearly every electronic device including smartphones, tablets and wearables, more power is needed to run sensor data and turn it into useful information. Data retrieved from multiple sensors — including accelerometers and gyroscopes — is becoming much more complex to manage.
Sensor hubs have been making their way into mobile devices and wearable electronics due to power-hungry application processors and battery power limitations. Delivering longer battery life is one of the most important requirements for wearable devices. Sensor hubs are used to run sensor fusion algorithms to offload these tasks from the application processor, enabling longer battery runtimes.
Newer ARM-based applications processors that integrate a low power Cortex-M microcontroller core on same SoC device as Cortex-A applications processors, can also be applied to sensor hub applications. NXP is one manufacturer that has been particularly innovative in this area, with this type of heterogeneous architecture now also being added to their popular iMX6 family where a lower power Cortex-M4 microcontroller core offloads the ARM Cortex-A9 Applications Processor from the sensor data collection and processing tasks.
Ultra-low power is becoming even more important for “always-on” applications such as contextual awareness and gesture recognition used in many mobile devices and wearable electronics.
Designers have a choice of four approaches for sensor hub implementation:
1) A dedicated microcontroller (MCU) that typically offers ultra-small footprints and ultralow power
2) An application processor-based hub with integrated sensor
3) A sensor-based hub with an integrated MCU
4) FPGA-based solutions
It must be noted that these approaches are not all mutually exclusive, and sensor fusion done in a tablet or smartphone will often be very different from what is done in a wearable device such as a watch. A design can potentially use two, three or four of these solutions at the same time, particularly for power and latency, depending on requirements.
Depending on the application, designers will give different levels of importance to power and performance, which will drive the decision-making process. Design engineers typically select the solution that best meets price, power efficiency and minimum performance requirements. In a smart watch, for example, a designer may select an application processor, or a high-end microcontroller, or even a separate MCU or ASIC solution as a sensor fusion device to keep the high-performance MCU asleep.
For health- or fitness-monitoring devices that count steps or measure contextual awareness, design engineers need to take a number of factors into account, including the maximum amount of processing power needed to run the applications and the battery being used. It is unlikely that an application processor will be used for a typical activity monitor. However, wearable devices vary greatly from basic step counters to something that integrates a pulse monitor, which can be power hungry and needs a display, which also uses a lot of power. Other issues include size and design cost.
This approach uses an external hub, which is a dedicated MCU. A few examples include TI’s MSP430 MCUs and Atmel’s SAM G series. Mobile devices currently using this approach include Apple iPhone 5s, Samsung Galaxy S5 and Motorola Moto X.
This discrete component solution offers better power usage, greater design flexibility and lower latency when handling data coming directly from the sensor compared to an application processor-based solution. The biggest benefits may be achieved in “always-on” applications because of the power usage. This is where the extra power savings come into play because an application processor does not have to be woken up regularly. It can be used for a wide range of sensor hub and battery-operated consumer applications including smartphones, tablets and wearable devices.
Fig. 1: Texas Instruments’ MSP430 uses the dedicated MCU approach. (Source: Texas Instruments)
Application Processor-Based Sensor Hub
This integrated solution uses a low-power sensor hub as part of an application processor. Currently, there are several solutions available, including Qualcomm’s Hexagon DSP embedded in the Snapdragon platform and Intel’s Merryfield (Z34XX) architecture.
The benefits of this approach include low-power sensor processing and one less line item on the bill of materials (BOM). Convenience is a plus because there is no extra design work required in placing and routing a discrete MCU.
One of the biggest drawbacks is the lack of maturity in the market. In many cases, the application processor subsystem solution is not flexible enough for OEMs to customize to make their solutions more competitive. Another barrier is the longer time to market using the solution because DSP programming is an entirely different skill set than programming an MCU. Many more OEMs have software developers that can work with MCUs than with DSP functionality. However, analysts believe that this will change over time as the application processor world develops better tools and engineering staffs develop the skill sets required.
Sensor-Based Hubs with MCU
This third approach combines a low-power processor, typically an MCU, and one or more sensors, typically an accelerometer and gyroscope. The accelerometer and gyroscope are the most common sensor combinations, allowing for various levels of activity and motion tracking, ranging from step counting to contextual awareness. Suppliers in this market include STMicroelectronics and InvenSense, and one example is STMicroelectronics’ iNEMO-A LIS331EB.
One of the advantages of this solution is that it offers designers a convenience factor by integrating the sensors with the processor. It is also likely to be a less expensive overall solution thanks to the integration. This approach reduces the BOM and has the potential for lower power. In addition, suppliers ship the sensor fusion algorithms along with the sensors and in some instance claim Android KitKat compatibility. This approach could be used as part of a series of solutions in a high-end handset as an example.
However, the integration, or all-in-one solution, can also be considered a drawback because it’s not the best at any one function, but it offers good enough performance to service a big section of the market. This approach may not appeal to OEMs that want to squeeze the best possible performance out of their designs and would rather have the ability to pick and choose which sensors and MCUs they put into their package for the best optimization.
FPGA-Based Sensor Hub
Although still a niche application, the FPGA-based sensor hub delivers very low power, which makes the wearable electronics market potentially the biggest application for this approach.
The greatest benefits of this solution are the extremely low power and reprogrammability of the device. The drawback is the design approach, which requires a set of skills not widely available, such as C language coding skills used for typical MCUs or application processors. FPGA devices use hardware description language like Verilog or VHDL (VHSIC Hardware Description Language). The average handset OEM may have more resources for coding an MCU or application processor than properly coding or designing for an FPGA. There is also a perception that an FPGA is just a prototyping device, which automatically eliminates the solution as a choice for those companies.
Which approach is best?
Currently, the MCU approach is said to be the most flexible solution for high-end handsets and tablets, while the application processor solution is the most convenient because of the reduced design efforts, whether used alone or in combination with other sensor hub implementations. However, analysts believe that low-power sensor hubs, like a dedicated MCU or a FPGA-based solution, will soon become the most critical for low-power capabilities in applications such as wearable electronics.
Insights into the benefits and drawbacks of each approach for sensor hubs for this article were provided by IHS analysts Marwan Boustany and Tom Hackenberg, who extensively cover MEMS, sensors, microprocessors and microcontrollers.