SDK 14.0 BLE Connection slower than SDK 11.0

[Nate]

I recently upgraded from SDK 11.0 to SDK 14.0 and am seeing much slower connection speeds from the new SDK. The old version would connect in about 400ms, but the new SDK takes over 1000ms for the connection to complete. I think I'm probably missing some configuration changes in the SDK, but I have been unable to identify any discrepancies between my old project and the new one.

[bjorn-spockeli]

Hi Nate,

the reduction in the time from the CONNECT_REQ packet to the last L2CAP Data packet on the subsequent connections are likely due to GATT table caching, i.e. the central is not performing the Service Discovery as it already has a up-to-date GATT table stored.

However, I would expect that to happen with your application as well. Do you have a trace of the custom app for one of the following connections after the initial one where the central cache was wiped?

I compared the response time for the various LL packets sent between the Master and Slave after the CONNECT_REQ packet for SDK14multiperipheral and SDK14_NokeApp traces

SDK14multiperipheral.pcapng

LL_Version_IND: 0.0165s

LL_Feature_REQ -> RSP: 0.2168s

LL_PHY_REQ -> RSP: 0.1446s ( LL_PHY_RSP packet is retransmitted once, first is sent 0.1358s)

LL_PHY_UPDATE_IND ( Master to Slave only) : Retransmitted once

LL_LENGTH_REQ -> RSP: 0.0309

LL_LENGTH_REP -> Last L2CAP packet: 0.6981 seconds

SDK14_NokeApp.pcapng

LL_Version_IND: 0.01432s

LL_Feature_REQ -> RSP: 0.03300s ( LL_Feature_REQ is retransmitted once, most likely due to the first LL_Feature_RSP being missed by the Master)

LL_PHY_REQ: 0.1365s ( LL_PHY_RSP packet is retransmitted once, first is sent 0.1236s after LL_PHY_REQ )

LL_PHY_UPDATE_IND ( Master to Slave only) : Retransmitted once

LL_LENGTH_REQ -> RSP: 0.1406s

LL_LENGTH_RSP -> Last L2CAP packet: 0.8950 seconds

There arent any big differences if you take into account the retransmitts. The only odd one out is the LL_LENGTH_REQ -> RSP, which takes longer in the custom app trace. Why, I do not know, but I expect that this might vary from connection to connection depending on how many connections the nRF52832 have going on concurrently and their connection intervals etc. 

Best regards

Bjørn