DSP, Micros & Memory


Four approaches to implement a wearable sensor hub

23 October 2019 DSP, Micros & Memory

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 the same SoC (System-on-Chip) device as Cortex-A applications processors, can also be applied to sensor hub applications. NXP Semiconductors is one manufacturer that has been particularly innovative in this area, with this type of heterogeneous architecture now also being added to its 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 ultra-low 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 smartwatch, 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.

1) Dedicated microcontroller

This approach uses an external hub, which is a dedicated MCU. A few examples include Texas Instruments’ MSP430 MCUs and Atmel’s (now Microchip) SAM G series. Mobile devices using this approach include the 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.

2) 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 customise 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.

3) 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 consumption. 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 optimisation.

4) 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.




Share this article:
Share via emailShare via LinkedInPrint this page

Further reading:

The 8-bit survival syndrome – Part 2
DSP, Micros & Memory
Just like the 4-bit pre-microcontroller, the 8-bit MCU has been finding ways to stick around. Their features and speeds have been improving, offering competitive reasons to work with them.

Read more...
Enhanced code protection for USB µC portfolio
Future Electronics DSP, Micros & Memory
To help easily incorporate USB power and communication functionality into embedded systems, Microchip Technology has launched the AVR DU family of microcontrollers.

Read more...
General-purpose MCU with RISC-V architecture
EBV Electrolink DSP, Micros & Memory
Renesas has released a general-purpose MCU to enhance its existing RISC-V portfolio, and this is its first MCU using a RISC-V core developed internally at the company.

Read more...
8-bit MCU with I3C support
Avnet Silica DSP, Micros & Memory
The PIC18-Q20 8-bit microcontrollers from Microchip easily interface with devices operating in multiple voltage domains, and the built-in I3C interface supports higher-speed and lower-power data transfers than I2C.

Read more...
An evolutionary step in customisable logic
Altron Arrow DSP, Micros & Memory
Microchip Technology is offering a tailored hardware solution with the launch of its PIC16F13145 family of microcontrollers, which are outfitted with a new Configurable Logic Block module.

Read more...
MCU for battery-powered applications
Altron Arrow DSP, Micros & Memory
Included in ST’s family of devices is the STM32U031, an ultra-low-power MCU featuring an ARM Cortex-M0+ 32-bit core running at up to 56 MHz.

Read more...
Serial SRAM up to 4 MB
EBV Electrolink DSP, Micros & Memory
The chips are designed to provide a lower-cost alternative to traditional parallel SRAM products, and include optional battery backup switchover circuitry in the SRAM memory to retain data on power loss.

Read more...
SiP supports LTE/NB-IoT and GNSS
RF Design DSP, Micros & Memory
The nRF9151 from Nordic Semiconductor is an integrated System-in-Package that supports LTE-M/NB-IoT, DECT NR+ and GNSS services.

Read more...
Qi2 dsPIC33-based reference design
DSP, Micros & Memory
Powered by a single dsPIC33 Digital Signal Controller, the Qi2 reference design offers efficient control for optimised performance.

Read more...
MIKROE’s IDE now includes MPLAB XC compilers
DSP, Micros & Memory
MIKROE has announced that the latest version of its multi-architectural IDE, NECTO Studio 6.1, now includes Microchip’s MPLAB XC compilers for 8-, 16- and 32-bit MCUs.

Read more...