BLE Button low power

[SebastianP]

Hello fellow developers,

I am new to BLE applications and I am trying to do a very simple device with three buttons that informs a Android smartphone when one has been pressed. So far, I got everything running: the android part, the nRF51822 application on mbed (BLE_Button) and so far everything connects and every time I press the button the application shows the notification :-D

The problem comes with the power consumption: it's around 0.60 uA when advertising (which seems OK to me) and rises to 160-200 uA when the device is paired with the Android application. I wonder if there is a way to drop that consumption when the device is connected to lower values as it seems to be pretty high to me.

Is there a way to configure the device to sleep as much as possible, while keeping the communication channel open and wake up only to send the notification? Should that configuration be done in the Android part or in the nRF51 code?

If it's not possible to lower the power consumption when connected: would it be a better solution to sleep the device and wake up to send Beacons/GAP to the central device and then sleep again. The information I have to transmit is little enough to fit in that model, I just don't know if it is a valid solution architecture (delivery is not guaranteed).

I have tried by reducing the latency but I did not get any changes. Maybe I need to change something on the Android application? Should these parameters be changed before starting the advertisement or when the device has been connected?

Gap::ConnectionParams_t new_params;

ble.gap().getPreferredConnectionParams(&new_params);

new_params.minConnectionInterval = BLE_GAP_CP_MIN_CONN_INTVL_MAX;
new_params.maxConnectionInterval = BLE_GAP_CP_MAX_CONN_INTVL_MAX;
new_params.slaveLatency = BLE_GAP_CP_SLAVE_LATENCY_MAX;
new_params.connectionSupervisionTimeout = BLE_GAP_CP_CONN_SUP_TIMEOUT_MAX;

ble.gap().setPreferredConnectionParams(&new_params);

Thanks all for your time. Best regards,

P/S: I am not tied to mbed development and I'm OK with trying different APIs or examples if you think that the power consumption would be lower (how little should it be? around 10 uA?).

[Petter Myhre]

Welcome, great that you have your first application working.

The problem comes with the power consumption: it's around 0.60 uA when advertising (which seems OK to me) and rises to 160-200 uA when the device is paired with the Android application.

I think there is something wrong with your measurements. 0.6 uA is only achievable when the chip is in SYSTEM OFF. You need to be in SYSTEM ON to advertise. Please see the nRF51422 product specification, available here. Please see this blog for typical average current for advertising and connection.

160-200 uA could be correct, depends on a lot of parameters as you can see in the blog.

I wonder if there is a way to drop that consumption when the device is connected to lower values as it seems to be pretty high to me.

Is there a way to configure the device to sleep as much as possible, while keeping the communication channel open and wake up only to send the notification? Should that configuration be done in the Android part or in the nRF51 code?

The maximum is connection interval is per Bluetooth specification 4 seconds. In addition you can reduce the number of connetion events in the peripheral by using slave latency. The rest of the time you can sleep.

Please see Vol 6, Part B, Section 4.5.1 in the Bluetooth Core specification v4.2 for more information.

The initial connection parameters are determined by the central/master (Android), these are included in the connection request sent to the peripheral/slave. The connection parameters can be changed if the master sends a connection parameter update. The slave can send a ask the master to change the connection parameters by sending a connection parameter request.

I have tried by reducing the latency but I did not get any changes. Maybe I need to change something on the Android application? Should these parameters be changed before starting the advertisement or when the device has been connected?

setPreferredConnectionParams() only sets the Preferred Connection Parameters in the Peripheral Preferred Connection Parameters (PPCP) characteristic. The master can use these values when/if it wants to update the connection parameters.

It seems you are only using current measurements to test this? I recommend you to use a debugger or a sniffer to figure out what the connection interval actually is, if connection parameters updates are actually performed and so on.

I'm not an expert on Android, but it seems you can set connection priority, please see this.

[SebastianP]

Hello Petter, Thank you very much for your inputs. I have expressed my self wrong: the mbed application starts advertising every 1 second, so it "sleeps" one second consuming 0.6 uA, then wakes up and have a spike when advertising and then sleeps again. That seems good enough to me.

I think I will need more tools to figure out what's happening: a sniffer to check the actual connection parameters and then a master device with a more flexible API than the native Android. I will try to build a simple application in Linux/Windows to have more control on the connection parameters and come back with the results.

As you point in the last link, Android does have an API to update the connection parameters but it's available since API 21 (Lollipop) and my device runs 19 (KitKat)

[SebastianP]

I have also been thinking about redesigning the solution and did some tests. Now the nRF51 sleeps (0.5 uA) until a button is pressed. Then it wakes up, starts advertising, Android connects to it, reads the information and ends the communication as quick as possible so the nRF51 sleeps again. Do you think it's a valid solution? It kind of worked, but Android does not find the device as quick as one would expect and the system has a 1-2 seconds latency, but that's Android's fault... Another solution I was thinking about is to use GAP or beacons directly to inform the central that an event occurred, but that would be broadcasting and the delivery wouldn't be acknowledged, right?

[Petter Myhre]

0.6 uA is only achievable in SYSTEM OFF. In this state the chip can only be woken up from a pin change, by the LPCOMP, or from a reset. It will not go to SYSTEM OFF between advertisements. In SYSTEM ON the minimum current you should see between advertisements should be something like 2.6 uA. In your second comment you talk about using a button to start advertising, this button can be used to go from SYSTEM OFF to SYSTEM ON, then 0.6 uA is achievable. From a power consumption perspective you solution is very valid, if your application can live with the latency.

[Petter Myhre]

If you don't enter a connection you need to put your data into advertising/scan response packets. These will not be acknowledged. Then you need to build your ack mechanism into your application. I'm not sure you are familiar with scan request/scan response. Anyways, if the central does active scanning it sends scan requests when it receives an advertising packet, then the peripheral can send a scan response with additional data. You may be able to use this to make an ack mechanism, where an advertising packet is acked with a scan request, but I don't recommend doing this. I'm not sure if you are doing bonding now, but if not, I would look into that, so that the GATT client on the central avoids doing a service discovery on every connection.

[SebastianP]

I've been playing a little with a Linux machine and gatttool, hcitool, and hcidump and I have done some great progress. As Petter pointed out, the problem was in the connection intervals. The hcidump output when connected to my device showed:

2015-07-27 13:58:47.398017 < HCI Command: LE Create Connection (0x08|0x000d) plen 25
    bdaddr C3:C5:C1:B5:CE:6B type 1
    interval 96 window 48 initiator_filter 0
    own_bdaddr_type 0 min_interval 40 max_interval 56
    latency 0 supervision_to 42 min_ce 0 max_ce 0

Then with the hcitool lecup commands described in this comment I was able to update the connections lowering the current consumption. After that, I changed the mbed code to update the parameters when it connects.