SDK 14.0 BLE Connection slower than SDK 11.0

RE: SDK 14.0 BLE Connection slower than SDK 11.0

bjorn-spockeli — Thu, 02 Aug 2018 12:07:42 GMT

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

RE: SDK 14.0 BLE Connection slower than SDK 11.0

bjorn-spockeli — Tue, 24 Jul 2018 14:48:38 GMT

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

RE: SDK 14.0 BLE Connection slower than SDK 11.0

Nate — Fri, 06 Jul 2018 19:32:24 GMT

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.

devzone.nordicsemi.com/.../SDK11_5F00_trace2.pcapng

devzone.nordicsemi.com/.../SDK14multiperipheral.pcapng

devzone.nordicsemi.com/.../SDK14_5F00_NokeApp.pcapng

RE: SDK 14.0 BLE Connection slower than SDK 11.0

bjorn-spockeli — Fri, 06 Jul 2018 13:31:43 GMT

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

RE: SDK 14.0 BLE Connection slower than SDK 11.0

Nate — Thu, 05 Jul 2018 16:16:18 GMT

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.

devzone.nordicsemi.com/.../SDK14_5F00_1MBPS_5F00_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.

devzone.nordicsemi.com/.../SDK14sampleApp.pcapng

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

devzone.nordicsemi.com/.../SDK11.pcapng

RE: SDK 14.0 BLE Connection slower than SDK 11.0

bjorn-spockeli — Wed, 04 Jul 2018 10:48:44 GMT

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

RE: SDK 14.0 BLE Connection slower than SDK 11.0

Nate — Tue, 03 Jul 2018 15:18:28 GMT

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.

devzone.nordicsemi.com/.../Discovery_5F00_sniffer_5F00_trace4.pcapng

RE: SDK 14.0 BLE Connection slower than SDK 11.0

bjorn-spockeli — Tue, 03 Jul 2018 15:02:52 GMT

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

RE: SDK 14.0 BLE Connection slower than SDK 11.0

Nate — Mon, 02 Jul 2018 20:44:12 GMT

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

devzone.nordicsemi.com/.../Discovery_5F00_sniffer_5F00_trace3.pcapng

RE: SDK 14.0 BLE Connection slower than SDK 11.0

bjorn-spockeli — Mon, 02 Jul 2018 14:01:41 GMT

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.

RE: SDK 14.0 BLE Connection slower than SDK 11.0

Nate — Thu, 28 Jun 2018 16:42:31 GMT

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.

devzone.nordicsemi.com/.../Discovery_5F00_sniffer_5F00_trace2.pcapng

RE: SDK 14.0 BLE Connection slower than SDK 11.0

bjorn-spockeli — Wed, 27 Jun 2018 14:01:22 GMT

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.

RE: SDK 14.0 BLE Connection slower than SDK 11.0

Nate — Tue, 26 Jun 2018 21:56:31 GMT

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?

RE: SDK 14.0 BLE Connection slower than SDK 11.0

bjorn-spockeli — Tue, 26 Jun 2018 09:19:01 GMT

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.

RE: SDK 14.0 BLE Connection slower than SDK 11.0

Nate — Tue, 26 Jun 2018 05:10:39 GMT

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

devzone.nordicsemi.com/.../Discovery_5F00_sniffer_5F00_trace.pcapng

RE: SDK 14.0 BLE Connection slower than SDK 11.0

bjorn-spockeli — Mon, 25 Jun 2018 14:04:00 GMT

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

RE: SDK 14.0 BLE Connection slower than SDK 11.0

Nate — Wed, 20 Jun 2018 09:38:37 GMT

The central is doing a service discovery and then a characteristic discovery. After timing these operations on the central side it appears these two actions are the ones that are much slower than they were with the past SDK (and acompanying Soft Device). The problem that I am seeing though is that as far as I can tell there is no action on the part of my application during these processes, that it is all handled by the Soft Device. Are there settings that could be affecting this or maybe advertising paramaters that would help speed this up?

RE: SDK 14.0 BLE Connection slower than SDK 11.0

bjorn-spockeli — Tue, 29 May 2018 14:40:26 GMT

Hi Nate,

I apologize for the late reply.

the connection is established when you get the BLE_GAP_EVT_CONNECTED event and the BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST is not apart of the connection setup, see Peripheral Connection Establishment and Termination. The BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST propagated to the application when the peer has sent a ATT Write/Read Request with authorization to the nRF device, see the GATTS Read Request with Authorization or GATTS Write Request with Authorization Message Sequence charts in the S132 v5.0.0 API documentation.

Hence, the time between the BLE_GAP_EVT_CONNECTED and the BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST event is determined by the peer that is issuing the write or read request with authorization.

Could you explain what the central that is connected to your peripheral is doing after the connection is established? Is it writting to one or more characteristics?

Best regards

Bjørn

RE: SDK 14.0 BLE Connection slower than SDK 11.0

Nate — Fri, 25 May 2018 16:23:08 GMT

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.

RE: SDK 14.0 BLE Connection slower than SDK 11.0

bjorn-spockeli — Fri, 25 May 2018 14:21:19 GMT

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