Hello supporters and enthusiasts,
I'm developing a BLE product which mainly works as central role for all scenarios. The steps how the central controls to a peripheral device are very simple.
- the central connects to a peripheral device.
- the central sends a command.
- the central disconnects to the device.
However, I found that whenever the central disconnects to the peripheral by using API, sd_ble_gap_disconnect, disconnected reason extracting from coming disconnected event can be possibly different, 0x22 or 0x16. With regards to time performance, 0x22, which represents BLE_HCI_STATUS_CODE_LMP_RESPONSE_TIMEOUT, is not what I expect.
The late coming disconnected event due to 0x22 can make users annoyed because of unexpected longer waiting-time and non-smooth operation on smart phone APP which mean the users cannot consecutively, smoothly control a peripheral.
And according to my experiments, longer SUPERVISION_TIMEOUT I set, longer waiting-time for disconnected event the central should take, when 0x22 happened.
So, my question is: Is there any aspect I should concern, so that the central can avoid BLE_HCI_STATUS_CODE_LMP_RESPONSE_TIMEOUT happening when doing disconnect operation ??
All my experiments were under GOOD radio environment and the distance between the central and the peripheral was within 30 cm. The kind of peripheral device I’ve tested are various. The rate of reproducing 0x22 is not low, roughly 30%. By using sd_ble_version_get, the version i'm working on is 8 103, which are version_number and subversion_number respectively.
From this case slow-disconnect, it is quite similar to mine. But the thread eventually seems to end without an exact answer.
I sincerely appreciate you can be some of help to me.
daruei.L