• State Not Answered
  • +1 person also asked this people also asked this
  • Replies 20 replies
  • Subscribers 74 subscribers
  • Views 4923 views
  • Users 0 members are here
Attachments (10) Download All
Nordic Case Info
  • Case ID: 207327
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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.

Parents
  • 0

    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 

  • 0 in reply to bjorn-spockeli

    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.

  • 0 in reply to Nate

    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 

  • 0 in reply to bjorn-spockeli

    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?

  • 0 in reply to Nate

    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 

  • 0 in reply to bjorn-spockeli

    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

  • 0 in reply to Nate

    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.

Reply
  • 0 in reply to Nate

    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.

Children
Related
Terms of service