High BLE activity for 15 seconds after connection

[jumpingfool]

I am developing a BLE peripheral application on nRF52832 and SDK 14.3.

I have been power profiling my application and quite happy with the results, except for when the peripheral first connects. Power usage goes crazy for about 15 seconds before calming down again - see below screenshot of the output from the power profiler:

What is the device doing when this happens? The peripheral is connecting to an iPhone and is bonded.

This is clearly BLE activity but I'm pretty sure it has nothing to do with my application!

[MartinBL]

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.

[jumpingfool]

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.

[Matt]

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?

[jumpingfool]

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?

[David Edwin]

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