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?).

[Locky]

A couple things to check: What are your Interval settings min and max set to?
Do you specify a preferred initial connection parameter? If a connection parameter update fails do your have retries?

A few things to note: 1) Android typically only allows one connection parameter update per connection. So make sure you don't send a preferred connection parameter. Also make sure that the parameters you are specifying are acceptable to the device. There is an Apple Developer Guide which is also a good rule of thumb for setting connection parameters on Android.

-K

[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?

[SebastianP]

Thanks for answering Locky! As I commented in Petter's answer, I will need to gather more information on the connection parameters with an sniffer. I hope to have more information soon. Best regards.