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

[Hung Bui]

Hi Remo,

Could you provide the sniffer trace and maybe the example code that can generate the issue. I tried here but couldn't reproduce that. The BLE_GAP_EVT_DISCONNECTED event came right after the nRF51 sent the LL_TERMINATE_IND.

[Remo]

Hi

I've uploaded the sniffer trace. Can you work with this format? I have to recheck if I can provide you the code. Kind regards

[Hung Bui]

Hi Remo, The sniffer wouldn't tell much. I'm seeing the peripheral didn't start to advertise after disconnection. I assume you added a breakpoint or didn't start advertising when disconnected in your application. When you mentioned "Now it happens sometimes", how often it was ? Have you found a way to reproduce the issue all the time ? I tried several times here but couldn't reproduce. A simple code that can show the issue would be great.

[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'?

[Remo]

The problem with providing a simple code is, that our nRF application is controlled by another controller via commands on the UART interface. E.g. one command starts the advertising and another command terminates the connection. Therefore, would just some particular code snippets be enough?