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,
That is very interesting. I have tried this change in the past to no avail and I tried it again and am seeing no change. I have a sniffer trace of this connection with the phy set to 1MBPS.
It is also interesting because the sample application also uses the Auto Phy parameter and doesn't have the slow discovery. Here is a sniffer trace of that.
And finally I have a sniffer trace of our application from SDK 11.
HI Nate,
comparing SDK14sampleApp.pcapng and SDK14_1MBPS_Phy.pcapng I see that all the L2CAP transfers are completed after 1.15seconds and1.55seconds respectiveley. This is much less than the Discovery_sniffer_trace4.pcapng trace, where I am seeing ~1.86seconds. But you're saying that the sample application from our SDK 14( which one is it by the way?) finishes service discovery much faster than your custom example based on SDK 14?
The SDK14_1MBPS trace is also missing the LL_VERSION_IND sent from the slave to the master. Could you re-do this capture?
I also see that both the Feature set of the Master(LL_FEATURE_REQ) and the feature set of the Slave(LL_FEATURE_RSP) are different for both traces.
To me it looks like two different centrals have been used as the Master in SDK14_1MBPS supports nearly everything, while the one in SDK14sampleApp only supports LE Encryption and LE Ping. Are you using two different central devices?
If we look at the slaves the only difference is that the slave in SDK14_1MBPS supports LE 2M PHY and the other does not, which is weird as I do not think this is configurable from the application in SDK 14.x.x. Can you confirm that you're using the same SoftDevice in your application as the one used in the SDK 14 example?
Best regards
Bjørn
Bjorn,
The sample application I am comparing against is the multiperipheral app. I have taken all the traces again and done the connection process at least twice in each one. I was using two different phones (both iPhones, but different generations) but this time used the same phone for all three scenarios. The softdevice is the same for both SDK 14 applications (S132 v5.0.0).
In this process I noticed some very interesting behavior. The SDK 11 app took 1.02s for the first connection (after cache had been cleared) but then following connections only took 0.32s. The multiperipheral sample app took a little longer for the first time with 1.18s but then following connections only take 0.59s, which makes some sense because the newer SDK supports more Bluetooth settings and these have to be negotiated. But then our custom app takes 1.35s on the initial connection and then 1.42s on all following connections which is the long period we have been observing. I will note that for both SDK apps I have set the PHY to use the 1MBPS phy to avoid the phy reconfiguration time.
Hi Nate,
I have been on vacation so I apologize for the late reply.
I will look into the attached traces and come back to you with my finding as soon as possible.
Best regards
Bjørn
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
