Under good radio env., BLE_HCI_STATUS_CODE_LMP_RESPONSE_TIMEOUT likely(30%) happens

[daruei.L]

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.

1. the central connects to a peripheral device.
2. the central sends a command.
3. 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

[David Edwin]

I suggest that you look at the release notes of the softdevice that you are using and the next releases of the softdevice (so you can get the bugs found in the version that you used). I think there are known issues listed in the release notes that report a disconnect due to a supervision as a LMP_RESPONSE_TIMEOUT. In addition there is also a known issue on some alpha softdevices that the LENGTH_REQ is not handled correctly and will result in a LMP_RESPONSE_TIMEOUT.

Please mention the softdevice version and IC version that you are using.

[Jean-Baptiste]

Hello,

I'm facing the same issue with IC revision 0x4430 and SD version 7.2.0 and 6.0.0.

In the release note there's indeed a bug fix ( DRGN-8837 ) referring to this LMP response timeout in s140_nrf52840_6.0.0-6.alpha but it's anterior to the 2 softdevices version with which I reproduced it. I received the same hci status code 0x22 instead of the expected 0x16 code, the softdevice call sd_ble_gap_disconnect returns correctly when this happen.

The reproduction rate is not as high as daruei ( I would say 10% ).

Devices are close when this happens and radio environment is also good, connection interval and supervision timeout are relatively slow but when I exchange some ATT packets between client and server, there's no additionnal delay due to some missing ack in link layer ...   

Thank you for you support,

JB W