Disconnect latency after calling bt_conn_disconnect()

[kpreiss]

Hi,

Our application is running in the central role connected to a peripheral.  The app disconnects from the peripheral by calling the bt_conn_disconnect() function.  It appears to take from 1 to 2 seconds before the "disconnected" callback handler is called.  There is no data being pushed out over the link prior to calling the disconnect function. The connection interval is 1 second, 0 latency with a 4 second supervision timeout.  I would expect the worst case latency would be 1 second.  Is this expected?

nrf Connect SDK 2.4.4
nrf5340

Thank you

[Turbo J]

No, you would expect 2 seconds here.

One second to get the "disconnect" packet out, another second to get the answer "packed received" in. Its unusual for hosts to be able to reply within the very few µs between BTLE packets in a single connection exchange step.

[kpreiss]

Hi,

Thank you.  It appears that the disconnect command is transmitted by the central and gets "ACKd" immediately with the empty PDU packet.  I don't see the peripheral respond with an acknowledgement other than the Empty PDU packet.  The disconnection occurs after the peripheral responds to the LL_TERMINATE_IND packet which I think should occur immediately.....

[Simonr]

Hi Kurt

Based on the very small snippet there I think the timings you refer to from the sniffer trace are from the sniffer itself that might deviate from the actual timing of the events. If you open the tab to select more filters, you can select a Delta time from end to start that will show the actual time between each packet on air. Please confirm whether that also shows the packets are in the same connection event.

Best regards,

Simon

[kpreiss]

Thank you Simon,

I expanded the "nRF Sniffer for Bluetooth LE" field and see a delta time (end to start) of 999679 us for the LL_TERMINATE_IND packet and a delta time (end to start) of 150usec for the Slave to Master Empty PDU packet, indicating it's the same connection interval.

Kurt

[Susheel Nuguru]

Kurt, The controller can only send LL_TERMINATE_IND during a connection event. It is not sent immediately when the host calls bt_conn_disconnect(), worst case scenario, the controller may have to wait up to almost 2 connection intervals if anything was attempted to exchange right after the connection event ended. 

Your sniffer shows that the LL_TERMINATE_IND aligned to the next connection event and seems to confirms over the air behavior is correct. The extra time to the callback is mostly host side handling delays. If you need faster disconnect indication, the only guaranteed way is to use a shorter connection interval or maybe  call bt_conn_disconnect() iin your app itself