BLE Button low power

RE: BLE Button low power

SebastianP — Thu, 30 Jul 2015 18:05:26 GMT

Thanks a lot, Peter. Now I just need to test it for longer times and tweak the timeouts. As you say, I'm pretty sure that I saw it disconnected and the clock drift sounds like a good explanation.

RE: BLE Button low power

Petter Myhre — Wed, 29 Jul 2015 12:05:05 GMT

I added a question that I hope explains this.

RE: BLE Button low power

SebastianP — Tue, 28 Jul 2015 10:04:35 GMT

Answering to myself. According to this mbed Wiki Page the constrain is: (conn_sup_timeout * 8) >= (max_conn_interval * (slave_latency + 1)) However, it seems to refer to softdevice S110 while in mbed IDE it seems to be using S130. In S130 I can't find any reference to this constrain, but it seems that it's been changed to conn_sup_timeout * 4 instead of conn_sup_timeout * 8, but it's an empirical finding. So far, it's good to me. When I have something more stable (and less ugly) I'll share both an mbed and Android projects.

RE: BLE Button low power

SebastianP — Mon, 27 Jul 2015 16:57:57 GMT

Now I have some problems with the connection parameters, sometimes I get an OUT_OF_RANGE error and I don't get why. The following works:

new_params.minConnectionInterval = 304 ;
new_params.maxConnectionInterval = 320;
new_params.slaveLatency = 5;
new_params.connectionSupervisionTimeout = 600;

But this one doesn't:

new_params.minConnectionInterval = BLE_GAP_CP_MIN_CONN_INTVL_MAX; //0xC80
new_params.maxConnectionInterval = BLE_GAP_CP_MAX_CONN_INTVL_MAX; //0xC80
new_params.slaveLatency = BLE_GAP_CP_SLAVE_LATENCY_MAX; //0x1F3
new_params.connectionSupervisionTimeout = BLE_GAP_CP_CONN_SUP_TIMEOUT_MAX; //0xC80

If I lower the Latency to 2 it works but it always disconnects after 32 seconds. I guess there are some formulae that I'm missing for validating the parameters. It seems that the key is in the latency, I would like it to be as high as possible.

RE: BLE Button low power

SebastianP — Mon, 27 Jul 2015 16:49:48 GMT

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.

RE: BLE Button low power

Petter Myhre — Mon, 27 Jul 2015 11:01:22 GMT

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.

RE: BLE Button low power

Petter Myhre — Mon, 27 Jul 2015 10:56:30 GMT

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.

RE: BLE Button low power

SebastianP — Mon, 27 Jul 2015 10:10:25 GMT

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.

RE: BLE Button low power

SebastianP — Sat, 25 Jul 2015 11:38:24 GMT

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?

RE: BLE Button low power

SebastianP — Sat, 25 Jul 2015 11:27:27 GMT

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)

RE: BLE Button low power

Petter Myhre — Fri, 24 Jul 2015 13:48:43 GMT

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.

RE: BLE Button low power

Locky — Thu, 23 Jul 2015 23:38:40 GMT

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