Battery Consumption

Doing nothing still costs some energy since RAM and low frequency clock have to run at all times. This costs about 5.6µA on average. As the mesh implementation is based on timers, different timer intervals have been tested:

The Sleep Power mode should be set to NRF_POWER_MODE_LOWPWR, which is the default and constant latency will consume 1mA on average.

The DC/DC converter should be enabled to save 10-20% when the radio is active.

All further measurements have been made with a 500ms timer.

Different Advertising intervals result in different power consumption. These values have been measured with DC/DC enabled and advertising on all three channels:

This scales mostly linearly.

There’s nothing like scanning when it comes to draining the battery as quickly as possible, even with the DC/DC turned on:

This also scales linearly.

The next test examines the BLE connections with the DC/DC on, both as a Master and as a Slave:

The difference between a Slave and a Master connection is not readily measurable because of the efficient sleep clocks. The Slave probably uses a bit more energy because it has to synchronize to the Master with each connection event.

A connection at 30ms uses 230µA with empty data packets and 270µA with 20 byte payloads. This suggests that each connection adds an almost constant amount of energy consumption. Three connections at 100ms instead of only one consumes a little less than three times the amount of a single connection.

Some results of battery measurements for bulk factory mode are available. The node used for the measurements is flashed with feature set prod_mesh_nrf52 while skipping uicr settings. Results are in the range of 34-36µA.

Measuring mesh discovery consumption is a little tricky because of the SoftDevice scheduling. Sometimes discovery will use less energy while the device has a connection in contrast to a device without connections because the different tasks (scanning/advertising/connection events/…​) will collide. Some important measurements are carried out to evaluate the tradeoff between fast connection and low power measurement of mesh.

If the device is turned off using the DeviceOff feature it will enter a sleep mode and won’t do any of the meshing funcionality. It should draw less than 10uA, the exact current draw depends on hardware itself however. It is useful to use this feature e.g. for transportation of devices where the batteries are already included.

In general, discovery should be switched off after all devices have joined the network. Once a device loses a connection, discovery should be switched on again.

There are different possibilities to achieve this. The best possibility is having a MeshGateway that monitors the mesh and switches discovery on or off. If the clusterSize of the mesh is known, it is possible to switch discovery off or to a very low setting once the target cluster size is reached. Additionally, a timeout has to be implemented to switch discovery to a low setting in case a node is defective and the target cluster size is never reached.

Under good conditions, connections should not break up often, which means that discovery can be switched off most of the time. While everything is connected, every node consumes about 150-250µA at a connection interval of 100ms. If low latency is not a requirement, the connection interval can be set to a very low 4000ms. This results in a power consumption of as low as 20µA once discovery is switched off.

Limited testing has been done in regards to which intervals provide the best balance between power consumption and performance. Be aware that tweaking some parameters may result in the mesh not connecting properly. Work is on-going to optimize the power consumption for a number of generic use cases.

The current consumption can be measured with the Nordic nRF Power Profiler Kit