Occasional Slow Disconnect

RE: Occasional Slow Disconnect

FormerMember — Tue, 12 Apr 2016 06:34:44 GMT

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?

RE: Occasional Slow Disconnect

karl — Mon, 11 Apr 2016 15:08:26 GMT

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!?

RE: Occasional Slow Disconnect

FormerMember — Mon, 11 Apr 2016 07:06:54 GMT

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?

RE: Occasional Slow Disconnect

karl — Fri, 08 Apr 2016 19:18:01 GMT

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?

RE: Occasional Slow Disconnect

FormerMember — Fri, 08 Apr 2016 08:57:52 GMT

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: