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, 

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

[bjorn-spockeli]

Hi Nate, 

Thanks for the trace, this one is much better. 

From the trace it looks like its the switch from 1Mbit to 2Mbit PHY that is the main contributor to the service discovery taking longer time than SDK 11 where 2Mbit was not supported. This PHY change postpones the service discovery, which is not started until after the LL_Channel_Map_Request

You can try to force the nRF52 to stay in 1Mbit mode by modifying the BLE_GAP_EVT_PHY_UPDATE_REQUEST case in ble_evt_handler() in main.c to the following

case BLE_GAP_EVT_PHY_UPDATE_REQUEST:
{
    NRF_LOG_DEBUG("PHY update request.");
    ble_gap_phys_t const phys =
    {
        .rx_phys = BLE_GAP_PHY_1MBPS,
        .tx_phys = BLE_GAP_PHY_1MBPS,
    };
    err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
    APP_ERROR_CHECK(err_code);
} break;

It would also be useful if you could capture a trace of the SDK v11.0.0 application connecting to the same central used to connect to the SDK 14.0.0 application

[Nate]

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.

SDK14_1MBPS_Phy.pcapng

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.

SDK14sampleApp.pcapng

And finally I have a sniffer trace of our application from SDK 11.

SDK11.pcapng