Business Development
sales@steinel.ch
+41 55 418 21 11
Low-power-operation in wireless mesh networks - the microcontroller counts sheep...
Microcontrollers are world champions in low-power-applications. It is fascinating what can be squeezed out of these small computers with just a few microamperes. The most important low-power-trick is to let the microcontroller sleep - for as long as possible. Of course, certain tasks and operations have to be carried out cyclically, but then «quickly back to bed».
Applications with wireless connections are technically exciting and challenging. These often run on a battery and have to be economical with resources. As an example, I would like to report on a current project and its challenges.
In the solution described here, so-called smart buttons are connected to each other in a wireless mesh network. The smart buttons are battery-operated, 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 form themselves into a mesh network. The electronics are designed to minimise power consumption: The power supply runs on battery without a DC/DC converter, all consumers can be switched via low-Q MOSFETs and high-quality components have been used. The 800 mAh battery is designed to provide a service life of two years.
In a mesh network, the nodes are not all directly connected to the master as in a star network, but can forward data from node to node until the desired recipient has been reached. The advantage is that the master does not have to be reached directly by every node. In the example with the smart buttons, the messages can be passed 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 reception, as it should be able to receive and forward data without restriction. Technologies such as Thread, Zigbee or BLE mesh consume 7mA permanently with a Nordic nRF52 device. This is already a very low value compared to other manufacturers, but would drain the battery for the smart button within five days.
Sophisticated low-power-trick
While searching for an alternative, I came across 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 timeslots, i.e. it uses a sophisticated low-power-trick. The nodes are precisely synchronised in their time base and are on reception simultaneously for a maximum of 10 ms. They then deactivate reception and go into low-power-mode for the following 990 ms. 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 due to the local distance to the coordinator. This solution is not suitable for requirements with low latency, but this is not usually relevant for IoT applications.
The idea was good, but things rarely go according to plan in the development of complex projects. During the first tests with Contiki-NG, the measurements showed a power consumption of 480 μA for the nRF52 (calculated service life of only 70 days). In order to achieve the defined battery life requirements of two years, the power consumption with the required peripherals should be around 50 μA.
Let's therefore delve a little deeper into the technology: Frameworks such as Zephyr, FreeRTOS and also Contiki-NG use a periodic SysTick, usually in the range of 1000 Hz, to switch between programme 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.
Through deep research in the Github code of Contiki-NG, I was able to find 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 crystal (HFXO) at 32 MHz. This alone consumes around 500 μA. The disadvantage is that the SysTick cannot be deactivated during low-power-mode, as otherwise only one tick would have elapsed between going to sleep and waking up and the time base on the node would be incorrect.
This raised the question: Do I 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 crystal (LFXO) with 32,768 kHz. Once 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 timeslot in active mode.
451.91μA
Power consumption before the redesign
7.44μA
Power consumption after the redesign
Power consumption before the redesign
Power consumption after the redesign
Microcontroller is almost always asleep
The result was a delight. The microcontroller sleeps 99.79 per cent of the time and requires a modest 55 μA on average. Nevertheless, each smart button is a fully-fledged member of the wireless mesh. In Thread and Zigbee, we would speak of a full function device (FFD) node.
A low-power-solution is always complex to develop. Many exciting and challenging effects only happen in this mode. For example, the HFXO needs a certain amount of time to run stably and must be started a few microseconds before the planned use. 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 in Github.
«Lamps, power supply units, sensors and coffee machines - many of the things in our environment are intelligent and networked. I see my challenge as a developer as ensuring that these things consume less power, not more.»