Low-power operation in wireless mesh networks – the microcontroller is counting sheep...

Microcontrollers are world champions in low-power applications. It is fascinating what can be squeezed out of the little computers with a few microamperes. The most important low-power trick is to put the microcontroller to sleep – and keep it asleep for as long as possible. Of course, certain tasks and operations have to be performed cyclically, but then it's "back to bed" as quickly as possible.

Applications with radio connections are technically exciting and challenging. These often run on a battery and have to use resources economically. I would like to use a current project and its challenges as an example.

In the solution described here, so-called smart buttons are connected to each other in a wireless mesh network. The smart buttons are battery-powered, have an e-paper display, an NFC scanner and three mechanical buttons to register user input and transmit it wirelessly to the backend.

The buttons are distributed at various locations in the building. They automatically form a mesh network. The electronics are designed for minimal power consumption: the power supply runs on a battery without a DC/DC converter, all consumers can be switched via low-Q MOSFETs and high-quality components are used. The 800 mAh battery should last for two years.

In a mesh network, the nodes are not all directly connected to the master as they are in a star network. Instead, they can forward data from node to node until the desired recipient is reached. The advantage of this is that the master does not have to be reached directly by each node.

In the example with the smart buttons, messages can be forwarded from device to device until the message finally reaches the gateway. The disadvantage is that each node in a wireless mesh must normally be permanently on receive, because it should be able to receive and forward data without restriction.

Technologies such as Thread, Zigbee or BLE mesh consume 7mA continuously from a Nordic nRF52 device. This is already a very low value compared to other manufacturers, but it would drain the battery of the smart button within five days.

Sophisticated low-power trick

A whimsical illustration of a sleeping microcontroller, depicted as a tiny robot character with integrated circuits and wires, all tucked up cosy. Created by DALLE.

In search of an alternative, I discovered the open-source Contiki-NG framework. Contiki-NG implements the IEEE 802.15.4-2015 specification and sends the data in a mesh in small time slots, using a sophisticated low-power trick. The nodes are precisely synchronised in their time base and are simultaneously on receive for a maximum of 10 ms. After that, they deactivate reception and switch to low-power mode for the following 990 ms. The time synchronisation is not very complicated. However, the nodes must be continuously synchronised and calculate a time deviation (drift) to the coordinator so that the signal propagation time can be compensated for based on the local distance to the coordinator. This solution is not suitable for low-latency requirements, but this is not usually relevant for IoT applications.

The idea was good, but in the development of complex projects, things rarely go according to plan. During the first tests with Contiki-NG, the measurements showed a power consumption of 480 µA for the nRF52 (calculated lifespan of only 70 days). To achieve the defined battery lifespan requirements of two years, the power consumption with the required peripherals should be around 50 µA.

So let's delve a little deeper into the technology: frameworks such as Zephyr, FreeRTOS and Contiki-NG use a periodic SysTick, usually in the range of 1000 Hz, to switch between program tasks with precise timing and to simulate multi-threading. With Contiki-NG, this SysTick must be very precise, otherwise the nodes would not switch to active reception at exactly the same time.

After a lot of research in the Contiki-NG GitHub code, I was able to identify the reason for the high power consumption. The implementation for the Nordic microcontroller uses the TIMER peripherals as the basis for the SysTick, which in turn activates the high-frequency quartz (HFXO) at 32 MHz. This alone consumes about 500 µA. The disadvantage is that the SysTick cannot be deactivated during low-power mode, because otherwise only a tick would have passed between falling asleep and waking up and the time base on the node would be wrong.

This raised the question for me: do we have to live with the high power consumption, or is there an alternative to the TIMER and the HFXO? In fact, the Nordic MCU offers the option of using an additional low-frequency quartz (LFXO) at 32.768 kHz. As soon as this is fitted, the RTC (real-time clock) can be used for a sufficiently accurate SysTick, and we can reduce the activation of the HFXO and TIMER to the short time slot in active mode.

451.91μA

Power consumption before redesign

7.44^μA

Power consumption after the redesign

Power consumption before redesign

Power consumption after the redesign

Microcontroller almost always asleep

The result was pleasing. The microcontroller is in sleep mode 99.79 per cent of the time and requires a modest 55 µA on average. Nevertheless, each smart button is a full member of the wireless mesh. In Thread and Zigbee, we would speak of a full-function device (FFD) node.

Developing a low-power solution is always fundamentally complex. Many exciting and challenging effects only occur in this mode. For example, the HFXO needs a certain amount of time to run stably and it must be started a few microseconds before it is needed. Our redesign of the Contiki-NG Nordic implementation was more extensive than initially thought, with around 1,000 lines of code, and is now fully integrated in the current version on Github.

"Lamps, power supplies, sensors and coffee machines – the things around us are often intelligent and networked. As a developer, I see my challenge in making these things consume less rather than more energy."

Marcel Graber, former hardware and firmware developer at STEINEL Solutions AG