Power consumption for BLE module nRF8001

[udi]

Hi, I would like to ask a question about the power consumption specified in nRF8001 datasheet: the graph on page 40 shows that the average current consumption is about ~5uA for connection interval of ~3sec. My questions are:

I am currently developing a system that has two devices, one is a base-station, the other a sensor, I only need to send a "keep alive" message every 5 seconds (less than 20 bytes) from the sensor to the base station- can I assume that after the initial pairing, my sensor will be able to send one packet (as described in the datasheet in figure 17 paragraph C), and than go back to sleep(assuming that one packet is 5uA, as described in graph)? and also- will the other side (the base-station) be able to be passive, i.e. not send any acknowledge at all, and only consume RX power for the connection interval?

Appriciate any of your help. Thanks Udi

[Stefan Birnir Sverrisson]

Hi

There is a choice of delivering your data in a advertising packet or a connection packet.

You can put your data into an advertising packet as a broadcast, but all BLE receivers in vicinity can pick up your data. An advertising is TX only and expects no acknowledgement. In this case the receiver can be RX only, i.e. only an observer. Advertising is however more power demanding than a connection as the advertiser needs to advertise the same packet on three channels, i.e. each packet is transmitted three times. The receiver can be RX only (observer only) but it needs to scan for a long time because it does not know when the transmitter sends the advertising packet, i.e. it is not power efficient, not for the advertiser or the observer. Also, data delivery time is not deterministic as the sender and receiver are not synchronized.

The other possibility is to send data when in a connection. That is more power efficient. The sender and receiver are synchronized, which means the receiver knows when the sender is going to send a packet, and will turn its receiver on momentarily, and then turn it off when the packet is received, therefore optimizing power consumption. Each packet will be acknowledged and both sender and receiver will use RX and TX. If acknowledgement is lacking for a packet it will be retransmitted.

Note: The nRF8001 can only act as a peripheral device, i.e. it can only be on the sensor side, not the base-station side. If you need a BLE chip on both sides, you could use the nRF51 series, which both have peripheral and central BLE stacks. The nRF51 is a System-On-Chip device, but it can also be used as a connectivity chip, like nRF8001. An option is to choose the latest nRF52 chip which is the successor for nRF51, but with better performance, e.g. lower current consumption than both nRF51 and nRF8001.

Update 16.9.2015 Yes, you could in theory use real time clocks on both sides to start the advertiser and observer simultaneously. A BLE advertiser is not meant to be synchronous however. The advertising interval is not entirely accurate. The device will add 0-10ms random delay to each advertising packet transmission. Therefore you will have to have the receiver enabled at least 5ms on average on the receiver side without receiving anything. Just that will add around 20uA average current consumption on the receiver side.

If you are thinking about lowest possible power, use connection state. Yes it needs to send packets both ways but the current consumption penalty is not an issue. BLE is designed for very low power applications and is really thought through in terms of efficiency. The packet overhead is minimal. You will not get same efficiency in a connection less state as in a connection. The acknowledgement is just on link layer, the application does not need to acknowledge anything. In fact if your intention is just to send keep alive message, you do not have to send any data. BLE will by default send packets in each connection interval to keep the connection alive and synchronized. When you get a disconnected event with a disconnect reason: TIMEOUT, that could be your "not alive" signal

Furthermore, if you control both central and peripheral side, you can balance the current consumption of peripheral and central during the advertiser/scanner state . If the central is power sensitive, you can let it scan infrequently but instead let the advertiser advertise more frequently, and still have similar "get-connected" time. Another option is to set up the server on the central and the client on the peripheral. The server will send notifications and the client will receive them. But here I am talking about the flexibility of the nRF51/nRF52 devices, not the nRF8001 which is peripheral only.

If you have nRFgo Studio installed, you can estimate current consumption for nRF8001, both in the advertising state and connection state. Choose nRF8001 Configuration on the left side, then choose the Current Consumption tab

For the nRF51/nRF52 devices, you can also choose a proprietary protocol, which is a valid option if you do not have inter-operability requirements.

[udi]

Hi Stefan,

Thank you for your answer, that is very very helpful to me.

I have just a couple of questions to your comment: Regarding your comment "The receiver can be RX only (observer only) but it needs to scan for a long time because it does not know when the transmitter sends the advertising packet..." If I use a real time clock on both sides- I will be able to open the receiver synchronized with the transmitter (taking into account the crystal deviation and so on), in this case I will need to open the receiver to TX_TIME x 3 (assuming 3 channel transmission), is that correct?

Second, if I send the data in " connection mode", can't I send it without acknowledge (Notifications?), and this way use only RX mode in the receiver side- which is the more power sensitive component?

Thanks Udi