• State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 73 subscribers
  • Views 2410 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 124761
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Disconnection time

Guillaume76

Hello,

I'm trying to optimize my application :

I have a central (nRF52832 s132) which communicates for a short time to a peripheral (nRF51822 s130) and then disconnect. The connection interval is 7.5ms, the communication last around 60ms.

After that the central has what it needs and calls sd_ble_gap_disconnect but then I need to wait for another 15ms to get the BLE_GAP_EVT_DISCONNECTED.

Is there something I can do to get the BLE_GAP_EVT_DISCONNECTED faster ?

Thanks

Guillaume

Parents
  • 0

    Hi, disconnecting in Bluetooth LE requires you to send the disconnect to the peer, and then get an ack for that disconnection. The SoftDevice will not give the BLE_GAP_EVT_DISCONNECTED until the ACK is received.

    This can take 1 or more connection intervals. You are seeing that it takes two connection intervals, which might be because the SoftDevice has a simplified logic where it will delay sending the disconnect by one event. What version of the SoftDevice are you using?

    You can consider (carefully!), to not do disconnect() on your central application. But just disable the SoftDevice. This will cause your peer (slave application) to wait until whatever you have configured for supervision_timeout, before it gets the Disonnected event with reason BLE_HCI_CONNECTION_TIMEOUT. This might be acceptable, depending on your usecase.

Reply
  • 0

    Hi, disconnecting in Bluetooth LE requires you to send the disconnect to the peer, and then get an ack for that disconnection. The SoftDevice will not give the BLE_GAP_EVT_DISCONNECTED until the ACK is received.

    This can take 1 or more connection intervals. You are seeing that it takes two connection intervals, which might be because the SoftDevice has a simplified logic where it will delay sending the disconnect by one event. What version of the SoftDevice are you using?

    You can consider (carefully!), to not do disconnect() on your central application. But just disable the SoftDevice. This will cause your peer (slave application) to wait until whatever you have configured for supervision_timeout, before it gets the Disonnected event with reason BLE_HCI_CONNECTION_TIMEOUT. This might be acceptable, depending on your usecase.

Children
Related
Terms of service