Supplement: Power
Introducing a new power-saving architecture for wireless endpoint devices
By Jan Frode Bergsø, business development manager, Nanopower Semiconductor W
ith its powerful CPU, fast memory and high-speed internal data bus, a wireless microcontroller or SoC is optimised
for the high-performance execution of data processing and signalling instructions, and control of a wireless system such as a Bluetooth Low Energy or Zigbee radio. The silicon architecture on which these devices are based makes it hard to optimize at the same time for ultra-low power consumption in sleep mode, when the full capability of the compute engine and RF circuit is not required. Despite MCU manufacturers’ best efforts at implementing power-saving modes, frequency scaling and other techniques, there is a floor below which the power consumption of a wireless MCU will not fall.
For many endpoint IoT devices and wireless sensors, this base level of power consumption can have a significant impact on battery life, forcing the device designer into a painful trade-off between battery size, weight and cost on the one hand, and battery cycle life on the other. What these applications typically need in quiescent or sensor monitoring mode – in the intervals when the MCU is not required to process any data, make any decisions, or communicate wirelessly – is power consumption measured in nanowatts. What they get in an architecture based on an MCU which directly controls sensors, is microwatts or even milliwatts of power consumption. But this drawback of conventional IoT system architectures can be overcome with a different architecture: a dedicated monitoring controller, optimised for ultra-low power consumption rather than for high processor performance, can be used to orchestrate a power-sensitive system that includes a wireless SoC or MCU, and one or more sensors (see Figure 1).
This is the promise of the nPZero from Nanopower Semiconductor, a power-saving companion chip which can interface to any I2C- or SPI-capable MCU or sensor. Drawing
34 July/August 2025 Fig. 1: the nPZero IC operates as a companion chip to the SoC
less than 100nA of operating current and enabling power-saving duty-cycling of sensors, the nPZero can achieve system-level average power savings of up to 90 per cent compared to a typical wireless MCU-based architecture.
nPZero: sharing the role of system controller
This new power-saving architecture contrasts with the typical approach to endpoint or edge system design. The MCU is normally treated as the central component of the system: it controls peripheral input devices such as sensors and keypads, makes decisions based on the sensor inputs, and then performs output operations such as displaying a message to the user on a display screen, or sounding an alarm. In this architecture, the MCU is required to be always on, even if, for periods between polling sensors or actuating an output device, the MCU can operate in a relatively low-power sleep mode. And since the MCU’s silicon architecture and transistor design are optimised for compute performance, the device’s base level of energy usage and current
Components in Electronics
leakage raise the floor for sleep mode power consumption.
This means that running a high-end CPU to monitor a quiescent system is a wasteful use of battery energy resources. The processing power of the CPU is certainly required to operate wireless communications such as the Bluetooth Low Energy, Zigbee or Lora RF protocols, and to perform complex data processing operations. But in the periods between transmissions or data processing operations, the CPU is grossly over- specified and power-hungry.
And in some applications these quiescent periods can be long. For instance, in an application such as cold-chain logistics, the main parameter of interest – ambient temperature – rarely moves outside its target zone, and so the controller is rarely called on to process or transmit data or to make a decision. In this kind of application, nearly all power consumption is quiescent mode power consumption. The introduction of the nPZero monitoring controller enables designers
of endpoint IoT devices to adopt an architecture which optimises the system for the lowest possible power consumption in quiescent, monitoring mode. In this architecture, the system controller role is shared between the nPZero and the wireless SoC or MCU. In monitoring mode, the nPZero directly controls up to four sensors, while the MCU is switched off.
When a sensor value crosses a pre-set threshold – in the cold-chain logistics example, for instance, this might mean the temperature rising above or falling below
the required temperature for refrigeration – the nPZero wakes up the MCU, reports the relevant sensor value, and triggers the MCU to take over system control temporarily. The nPZero is always the interface between the MCU and sensors. This means that the nPZero operates alternatively in either controller or peripheral mode. When monitoring with the MCU switched off, the nPZero is the controller: it controls the sensors, and decides (with reference to the pre-set thresholds) when an action requires the operation of the MCU. With the nPZero as controller, the MCU is effectively a peripheral device managed by the nPZero. When a sensor value crosses a threshold, the nPZero switches on the MCU and goes into peripheral mode. The nPZero is now operated by the MCU as a sensor hub: sensor values are reported to the MCU via the nPZero, and not directly from the sensor to the MCU.
This peripheral mode continues until the MCU has completed its operations, at which point it hands off system control to the nPZero, which then switches the MCU off again.
www.cieonline.co.uk
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64
