Occasional Slow Disconnect

[karl]

We have an application that requires a fairly quick disconnect (under 250msec) when the RSSI exceeds a threshold, for example -80db. Unfortunately, around 1 out of every 4 disconnects is taking over 4sec. This is the time from when the Peripheral executes sd_ble_gap_disconnect to the receiving of the BLE_GAP_EVT_DISCONNECTED event.

I know the RSSI is up to date because our application is transferring data every 256msec.

I'm running SDK 10.0.0 with nRF51 devices.

Any ideas as to what may be causing the intermittent slow disconnect? Unfortunately I'm having problems using your nRF Sniffer tool, so I'm not able to see what going on over the air.

Thanks.

--karl

[FormerMember]

When using sd_ble_gap_disconnect(..) the disconnect should be immediate. Which error code does sd_ble_gap_disconnect() return?

If it takes 4s before the BLE_GAP_EVT_DISCONNECTED occur, a timeout could be the reason for the disconnect. What is the connection supervision timeout?

When the BLE_GAP_EVT_DISCONNECTED occur, which disconnect reason does it contain? (ble_evt_t -> ble_gap_evt_t -> ble_gap_evt_disconnected_t )

What goes wrong when you try the sniffer? Which version of Wireshark do you use? The sniffer works best with version 1.10, not one of the newer versions. The older versions can be downloaded here:

• www.wireshark.org/.../
• www.wireshark.org/.../

[karl]

You are correct, it appears a timeout is occurring. The connection supervision timeout is set to 4sec and I do see the reason code 0x22 in the disconnect event when the problem happens.

Also, sd_ble_gap_disconnect never returns an error.

I've noticed the timeout appears to never happen if the RSSI is below -70db. So that could indicate either the disconnection request or response packets are getting lost. Whats your logic for the disconnect? How robust is it?

[FormerMember]

In BLE, all packets have to be ACKed in the link layer. If a transmitted packet hasn't been ACKed, the transmitted packet will be re-transmitted until an ACK or until connection supervision timeout. It seems likely that too far distance is the reason for the slow disconnect.

At which device do you measure the -70 dBm RSSI? At the nRF51 or the other device?

[karl]

Both Central and Peripheral devices are nRF51. I'm measuring the RSSI on the Peripheral device. The reason I was suspicious of the disconnect logic is because 200ms before the disconnect, I'm able to successfully transfer 12 20-byte data packets. So if it was a weak signal issue preventing the disconnect packets from getting across, why are the data packets able to make it!?

[FormerMember]

Okay, I see. If you are able to transfer data, you should be able to disconnect the link as well. In that case, it would be very nice to use the sniffer, to check what is being transferred over the air. What goes wrong when you use the sniffer?