Disconnection procedure after LL conn. parameter update leads to supervision timeout

[Remo]

Hi all

We use the nRF51822 with the S130 V1.0.0 in the peripheral role and a Galaxy S5 in the central role. As soon as the S5 connects to the nRF, we send a connection parameter update request (L2CAP) to the S5 for increasing the communication speed. This request is accepted by the S5 and it sends afterwards the corresponding LL connection update request with an Instant value of 0x0011.

Now it happens sometimes, that we have to close the connection before the new connection parameters take effect (before the instant). The nRF sends the LL_TERMINATE_IND packet and waits for the BLE_GAP_EVT_DISCONNECTED event. But this event occurs first after the supervision timeout has expired (7000ms).

With a BLE sniffer I can see that the S5 sends an empty PDU after the LL_TERMINATE_IND which confirms the connection termination procedure. Therefore I don't see any reason why the disconnected event doesn't occur immediately.

When our application doesn't send the connection parameter update request after connection establishment, the BLE_GAP_EVT_DISCONNECTED event occurs right after the nRF has sent the LL_TERMINATE_IND packet.

Does anyone know this behavior?

EDIT: Added sniffer trace from Frontline BPA sniffer. supervision_timeout_at_disconnect.zip

EDIT: Another sniffer trace in which the last try was successful. supervision_timeout_at_disconnect_S5_2.zip

EDIT: Added sniffer trace in which the connection is terminated before the instant. disconnect_successful_S5.zip

Kind regards

[Remo]

Hi. I have uploaded another sniffer trace in which the last connection was terminated successfully (the disconnected event was received immediately). All previous connections were terminated and the disconnected event occurred first after the supervision timeout. The phrase "Now it happens sometimes" means that the supervision timeout occurs in most cases. That is, when the 'instant' of the connection parameter update applies after the connection should be terminated, as you can see in the second sniffer trace file.

The occurrence of the problem depends on the timing when the connection update request is sent (and the instant signaled by the central) and when the terminate request is sent. When you tried to reproduce it, could you verify with the sniffer that the terminate request was sent before the 'instant'?