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,

do mean the time from the peripheral receiving the connection request from the central to the  BLE_GAP_EVT_CONNECTED event is received in the peripheral application? Or are you measuring this in another way?

Best regards

Bjørn 

[Nate]

I'm measuring the time between BLE_GAP_EVT_CONNECTED to the time of BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST when all the handshaking and discoveries have been completed. Maybe I'm wrong to refer to this as "connection" but this is the time that is taking much longer and causing issues.

[bjorn-spockeli]

HI Nate, 

I apologize for the late reply. 

Are you testing this with the generic SDK examples or are you using custom application examples?

Are you able to provide sniffer traces of the transactions so that we can compare the packets that are sent on air and their timing? Adjusting the advertisment interval will not affect the service discovery procedure as this is controlled by the central. 

Which type of central device are you using? Are you seeing the same behaviour with different central devices?

Best regards

Bjørn 

[Nate]

Bjorn,

We are using our own custom application which we based off the uart and multiperipheral examples. I tested those two examples and they work just fine. I'm thinking this means that we have some configuration parameters set incorrectly, but I have no idea which parameters control this behavior.

I am attaching a sniffer trace of the slow discovery. Our device is the one with address f3:fd:35:fb:c1:5e and the central device is address Apple_97:bd:b8.
We use both Android and Apple devices for the central devices and have seen the same behavior out of both of them.
Thanks for your help

Discovery_sniffer_trace.pcapng

[bjorn-spockeli]

OK, if the SDK 14.0.0 examples show the correct behaviour then I think its likely that there is some event that is propagated to the application by the SoftDevice, but its not handled. 

How did you capture the trace? I opened it using Wireshark, but I am not getting any protocol information, hence its a bit hard to see whats going on. Alternatively, we could make the case private and you could share the application code so that I could debug and perform sniffer traces. This is of course provided that the code runs on  NRF52 DK.

[Nate]

I have been looking to see if I can find any unhandled events, but as far as I can tell we are handling all the events that the examples handle.

I captured the trace with the nordic sniffer v2 and Wireshark, but I have never used it before this. Do you have any recommendations for how to set it up to capture the connection traffic as well?

[bjorn-spockeli]

HI Nate, 

turns out I had not enabled NORDIC_BLE as an Enabled Protocol under Analyze-> Enabled Protocols, so now I am able to see the protocol information in the trace you attached, which is all advertisement packets.

Yes, you need to select the peripheral device in the Device drop-down menu in Wireshark, it will then follow the device from advertising into the connect state. 

[Nate]

Here is another sniffer trace where I selected our peripheral device and then did the connection. I can't seem to see the connection traffic, so I think there may still be something I need to do with the sniffer to get it to see that traffic.

Discovery_sniffer_trace2.pcapng

[bjorn-spockeli]

HI Nate, 

it should be as simple as selecting the device in the highlighted drop-down menu when it is advertising and then initiate the connection request from the central.

You should then see the CONNECT_REQ packet and the Source and Destination field should indicate which device is the link master and slave. 

[Nate]

Ok, I have generated another sniffer trace and in this one I can finally see CONNECT_REQ packets.

Discovery_sniffer_trace3.pcapng

[bjorn-spockeli]

Ok I have taken a look at the trace. Your application is acting as a broadcaster while its in a connection right? As I am seeing a lot of advertisement packets and scan requests/ responses in the trace.

I see the connection request, but its a bit wierd that the sniffer does not recognize the empty PDUs and instead sets them as unknown. 

I can also not see any service discovery procedure in the trace either, i.e. like GATTC Primary Service Discovery (note this is for a nrf5x device acting as a central, but we should see the same in the trace when the smartphone performs the discovery) . It could be that the iOS/Android device has cached the services/characteristics so you can try to disable and then re-enable Bluetooth on the smartphone and then perform a new trace. 

Best regards

Bjørn 

[Nate]

Yes, we are broadcasting while in a connection to enable multiple devices to be able to connect.

I have a new trace that seems to have all the connection information in it now.

Discovery_sniffer_trace4.pcapng