High BLE activity for 15 seconds after connection

RE: High BLE activity for 15 seconds after connection

David Edwin — Thu, 01 Feb 2018 13:36:05 GMT

>even when paired/bondedto the peripheral the app is required to discover services, characteristics and set CCCD values each time a connection is established.

That would be incorrect. If the link is encrypted using keys shared during bonding ,the iOS should not re-discover the Services. You can try to get a sniffer trace and update your question so you can be certain. Only a ServiceChanged Indication should trigger re-discovery and re-subscribing to CCCD, when the link is encrypted with key shared during bonding.

Can you specify which example you are using in SDK 14.2 (I assume you are using SDK 14.2)

RE: High BLE activity for 15 seconds after connection

jumpingfool — Thu, 01 Feb 2018 12:50:05 GMT

Hi - I have now uncovered what is behind this. My central is an iOS app and it appears that even when paired/bondedto the peripheral the app is required to discover services, characteristics and set CCCD values each time a connection is established. This seems to be the case even when re-establishing an existing connection through the background execution modes using retrievePeripherals(withIdentifiers: ) - the retrieved peripheral object does not contain the service details (the services object is NULL).

Is that expected behaviour from the core bluetooth iOS framework or could it point to some configuration issue?

RE: High BLE activity for 15 seconds after connection

Matt — Sun, 28 Jan 2018 15:06:15 GMT

Does the bluetooth 5.0 spec say anything about the message flow (i.e. any message sequence charts) for the reconnection of previously bonded device to the GAP central?

RE: High BLE activity for 15 seconds after connection

jumpingfool — Sun, 28 Jan 2018 04:22:58 GMT

Thanks for your help!

I am already using both the connection parameters negotiation library and the peer manager in my application. I have managed to get some more information on the data that is being exchanged while investigating another issue with the peer manager - see devzone.nordicsemi.com/.../.

Can you comment on whether the event flow at the bottom of this question is usual when connecting to a previously bonded device? It sure does seem like a lot of data to be exchanging each time a connection is established!

That said, my suspicion is that the majority of the power usage we see here is in the peer data being written to flash, not usage of the BLE radio.

RE: High BLE activity for 15 seconds after connection

MartinBL — Fri, 26 Jan 2018 12:49:48 GMT

You can look into the Connection Parameter Negotiation library. That will help you do the initial connection procedures as fast as possible and then you can throttle down the parameters to save power.

Then you could look into the Peer Manager library. With that you can bond your devices to avoid the service discovery on every connection.

RE: High BLE activity for 15 seconds after connection

jumpingfool — Fri, 26 Jan 2018 12:37:10 GMT

I think you may be on the right track there - here are my connection parameters:

#define MIN_CONN_INTERVAL (SECOND_1_25_MS_UNITS / 100) * 30 /*300ms*/
#define MAX_CONN_INTERVAL (SECOND_1_25_MS_UNITS / 100) * 39 /*390ms*/
#define SLAVE_LATENCY 4
#define CONN_SUP_TIMEOUT (6 * SECOND_10_MS_UNITS) /*6s*/

These connection intervals are set to be the maximum allowable for iOS - our application is not time sensitive but is range sensitive, so we have upped the connection interval and added the PA to our design to try to maximise the range while keeping a handle on power consumption.

I'm away from the lab at the moment so can't check but my guess is the spikes will line up with the connection interval.

Given the services and characteristics in our application never change is there some way I can instruct the central not to re-scan every time it connects?

RE: High BLE activity for 15 seconds after connection

MartinBL — Fri, 26 Jan 2018 11:24:22 GMT

Could it be that the devices are doing service discoveries, but using an unfortunate bandwidth configuration? What are the period between the spikes in the crazy period? What are the connection parameters in your application?

RE: High BLE activity for 15 seconds after connection

jumpingfool — Fri, 26 Jan 2018 04:31:37 GMT

I am profiling a custom design with on-board Power Amplifier, so the 60mA peaks during radio activity are not a concern. The graph makes it look worse than it is - even during the "crazy" period the average current over the 15 sec is only around 500uA so not catastrophic. I'm still keen to know if it's necessary though as my application will require relatively frequent connect/disconnect cycles.

The screenshots above are showing a connection from nRF Connect on iOS - I did try to run nRF Connect on the desktop to see if it changed anything but wasn't able to get it to run at the same time as the power profiler.

I also spun up a sniffer today to see if that gave any clues - I can see a few scan/responses going back and forth while this activity is happening but I wouldn't have thought that service discovery would have taken this long to complete?

RE: High BLE activity for 15 seconds after connection

Matt — Thu, 25 Jan 2018 14:32:17 GMT

Is it possible to try connecting using the master control panel on the pc side i.e. just connect, bond, discover service and see if you get the same 60mA current drain on your end.

RE: High BLE activity for 15 seconds after connection

MartinBL — Thu, 25 Jan 2018 14:05:34 GMT

Those currents seem pretty crazy indeed. 60mA is a lot and probably wrong or caused by something else than the nRF52 alone? What are you measuring on? A development kit or do you have a custom board?