standby power consumption

[sandstorm412]

Hello,

I have a few questions regarding power consumption of the BLE modules

With regards to the nRF52810:

The data sheet lists the following as specifications for current consumption in both Tx and Rx

4.6mA – TX at 0dBm output power, 4.6mA – RX at 1Mbs

Is this the consumption when the module is actively transmitting or receiving? 

Is it the consumption when the Tx/Rx radio is enabled?

What is the consumption when the radios are active but not receiving/transmitting data? 

my main concern is standby current consumption of the units when they're waiting to receive data. If there is a spike to 4.6mA when receiving it is not a big concern, but continuous 4.6mA is too high consumption for a long life application.

the application I am developing is powered by coin cell batteries and must minimize current consumption.

there will be approximately 15 units, each unit when powered on will by default be in Rx mode. each unit has 1 button, when the button is pressed, the unit begins transmitting a message to the other units, for simplicity lets say it changes the color of a LED. 

if unit 1 is pressed it transmits to all 9 units and they turn the LED red then goes back into Rx mode

if unit 2 is pressed it transmits to all 9 units and they turn the LED green then goes back into Rx mode

if unit 3 is pressed it transmits to all 9 units and they turn the LED blue then goes back into Rx mode

etc...

can this be done with simple advertising? since advertising can transmit 31bytes of data, that is more than enough to toggle some bits and change the status of some LED.

[Jørgen Holmefjord]

Hi,

The data sheet lists the following as specifications for current consumption in both Tx and Rx

4.6mA – TX at 0dBm output power, 4.6mA – RX at 1Mbs

Is this the consumption when the module is actively transmitting or receiving? 

Is it the consumption when the Tx/Rx radio is enabled?

For TX, the current is for when the packet is actually transmitted (since radio is stopped after the transmit finishes). For RX, the current is for whenever the RX mode has been enabled and started. The current is approximately the same if the radio is actually receiving data, or if it is listening for valid packets.

my main concern is standby current consumption of the units when they're waiting to receive data. If there is a spike to 4.6mA when receiving it is not a big concern, but continuous 4.6mA is too high consumption for a long life application.

the application I am developing is powered by coin cell batteries and must minimize current consumption.

I understand your concerns, but this is what the radio can offer. You will see similar or higher numbers for most other devices in the market as well. You may have to look into alternative options to having the devices in RX mode most of the time.

there will be approximately 15 units, each unit when powered on will by default be in Rx mode. each unit has 1 button, when the button is pressed, the unit begins transmitting a message to the other units, for simplicity lets say it changes the color of a LED. 

if unit 1 is pressed it transmits to all 9 units and they turn the LED red then goes back into Rx mode

if unit 2 is pressed it transmits to all 9 units and they turn the LED green then goes back into Rx mode

if unit 3 is pressed it transmits to all 9 units and they turn the LED blue then goes back into Rx mode

etc...

can this be done with simple advertising? since advertising can transmit 31bytes of data, that is more than enough to toggle some bits and change the status of some LED.

This could be done with advertising, but that would require the devices to be in RX mode/scanning most of the time to receive the advertising packets, which will cause the devices to have high current consumption. There is also no way to know if the packets was received by the scanners when doing advertising, and it may introduce latency into the application if you have long advertising/scan intervals.

One option could be to use BLE connections. Our softdevices support up to 20 concurrent connections, meaning you can connect each of the 15 devices to all other. Connections provides acking mechanisms to make sure the recipient receives the packet correctly. The devices still have to do scanning for devices occasionally if not all expected devices are connected, but at least you will not have to scan all the time. Note that having 15 concurrent connections may also introduce some latency into the application. BLE can only send data at predetermined intervals (connection events), which needs to be longer with that many connected peers.

Another option could be to introduce a main-powered "central device" that handles the scanning and initiate connections to all the 15 devices. The devices then only need to do advertising, which does not cause high current consumption. Once the devices are connected to the central, it can send packets to the central, which will forward to the other nodes. This will give the lowest current consumption in the coin-cell powered nodes, but it will also introduce some latency by the extra transmit-hop. The central device would also become a single-point-of-failure, meaning that if this device is failing for some reason, none of the nodes will be able to communicate with each other.

Best regards,
Jørgen