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

[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

[Emil Lenngren]

"The extra time to the callback is mostly host side handling delays."

I find it weird that it would take 1 extra connection interval from the acknowledgment has been received to just process the disconnect event. The CPU is fast and there is no reason to take such long time.

[kpreiss]

Emil, I agree.  I understand that the time required from calling the bt_conn_disconnect() to when the LL_TERMINATE_IND packet gets transmitted may take up to one connection interval.  However, when the ACK by the slave occurs I would think the BLE stack on the central would immediately call the "disconnect" callback?  As I mentioned previously, there is no other traffic occurring on the connection prior to the LL_TERMINATE_IND packet being transmitted.  So, I believe the max latency between calling bt_conn_disconnect() and processing the disconnect callback should be one connection interval plus the time required to transmit the LL_TERMINATE_IND packet plus the time required to receive the ACK from the peripheral.  

Does this make sense?