Battery Consumption
Using a mesh atop of Bluetooth Low Energy does only make sense when it can operate on low energy. Simple, isn’t it? Well, not too simple. There are tons of settings that affect the performance of FruityMesh and some use-cases will require different settings for some of these parameters. Many of these settings have been benchmarked with the current implementation. Measurements were done with the nRF51 DK with chip version QFACA1. The system consumption for many of these cases are detailed in this document. The same test applications on a nRF52 consume a little less energy.
Sleeping
Doing nothing will still cost some energy because the RAM and the low frequency clock must be running at all times. This costs about 5.6µA on average. But because the mesh implementation needs some timers, different timer intervals have been tested:
-
Every 1000ms: 6.3µA
-
Every 500ms: 7µA
-
Every 100ms: 11.5µA
The Sleep Power mode should be set to NRF_POWER_MODE_LOWPWR which is the default because constant latency will consume 1mA on average.
The DC/DC converter should be enabled to save 10-20% during radio activity.
All further measurements have been made with a 500ms timer enabled.
Advertising
Different Advertising intervals will result in a very different power consumption. These values have been measured with DC/DC enabled and advertising on all three channels:
-
Advertising every 25ms will consume 770µA
-
Advertising every 100ms will reduce the system consumption to 222µA
This does mostly scale linearly.
Scanning
There’s nothing like scanning when it comes to draining the battery as quickly as possible, even with DC/DC on:
-
Scanning at 50% duty cycle: 5.4mA
-
Scanning at 100% duty cycle: 10.8mA
Again, we can see that this scales nicely.
Connections
Next up, we tested the BLE connections with the DC/DC on, both as a Master and as a Slave:
-
1 Connection with an interval of 100ms: 77µA (empty PDUs), 134µA (20 byte each connection event)
-
2 Connections with 100ms each: 142µA (empty PDUs)
-
3 Connections: 211µA
The differences between a Slave and a Master connection were not directly measurable because of the good sleep clocks but the Slave will probably use a bit more energy because it has to synchronize on the Master at each connection event.
A connection at 30ms used 230µA with empty data packets and 270µA with 20 byte payloads. This suggests that each connection adds a rather constant amount of energy consumption and having three connections at 100ms instead of only one will consume a little less than three times the amount of a single connections.
Mesh Discovery
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 were carried out to evaluate the tradeoff between fast connection and low power measurement of mesh.
NRF51
Ultra High Discovery with:
-
100ms advertising on all channels
-
40ms scan interval
-
20ms scan window
-
3s in DISCOVERY state
-
1s + 1 random second in BACK_OFF state
-
⇒ 2.2mA with one connection and 2.6 mA without a connection
NRF52
Battery measurement were calculated for prod_mesh_nrf52 featureset. Measurement for both High and Low discovery are as follows:
High Discovery
-
Consumes on average 890 uA when in mesh.
-
Consumes on average 760 uA when not in mesh.
-
Scan 50-55 packets of all the nearby nodes every 30 sec.
-
Scan 10-12 joinMe packets every 30 sec from a single device advertising at interval 100ms.
-
time to connect to other node = 100 ms - 400 ms.
Low Discovery
-
Consumes on average 460 uA when in mesh.
-
Consumes on average 220 uA when not in mesh.
-
Scan 15-20 packets from all the nearby nodes every 30 sec.
-
Scan 1-2 joinMe packets every 30 sec from a single device advertising at interval 200ms.
-
time to connect to other node = 700 ms - 30 s.
By selecting the appropriate parameters for discovery, we can balance between fast connection vs. energy consumption.
What does that mean?
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. But 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 after some time 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 off at most times. While everything is connected, every node will need about 150-250µA at a connection interval of 100ms. If you do not need low latency, you can easily set the connection interval to a very low 4000ms. This should give you a power consumption as low as 20µA once discovery is switched off.
Measuring the Power Consumption
We have not yet done many tests which intervals provide the best balance between power consumption and performance. Be aware that tweaking some parameters might result in the mesh not connecting properly. We are still working on optimizing the power consumption for most general use-cases.
The current consumption can be measured with the Nordic nRF Power Profiler Kit