This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SD132 sd_ble_gap_disconnect - missing event

Dear Nordic, 

we are using s132_nrf52_3.0.0_softdevice.hex on nRF52832, nRF5_SDK_12.2.0_f012efa

We have noticed, that sometimes after issuing sd_ble_gap_disconnect(m_device_conn_handle, BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION) we do not get disconnect event (BLE_GAP_EVT_DISCONNECTED). It is happening 1 out of 40 cases. What can we actually expect that will happen for sure/probably after this command?

We have designed our application, that it relates on that signal to be emitted (when in connection state), like clearing connection handles and so. And it usually happen, but as I wrote we documented cases when this fails. In both cases we get no error from the command. Our test case is to run continuous connections/disconnections in rounds for several hours.

Is this something that sounds familiar?

Our workaround is to wait limited time after and if the event won't happen, we will do the action manually. 

Thank you for any advice, Jan

  • I would like to add few more info, mainly after studying this:

    https://devzone.nordicsemi.com/f/nordic-q-a/26355/delayed-disconnect-with-sd_ble_gap_disconnect

    in our case, the test is running between Nordic chip and Android device. So there can be some uncertain action on Android side. We haven't seen that up to now so far with connection to central device with SD132.

    Anyway it is important to understand if in theory there is chance not to emit disconnected event from SD132 under some circumstances. Maybe little more info:

    • we are not blocking events
    • we wait about 3 seconds for that event to clear handles
    • if that not happens, we do it manually and we can start advertising (that shows btw, that stack thinks we are disconnected and no error is returned like WRONG_STATE or so)

    Thank you, Jan

  • Hi Jan,

    The disconnect event shall always come through, but it may get delayed (until supervision timer expires) if the disconnect request packet is not acked by the connected peer as discussed in this post : https://devzone.nordicsemi.com/f/nordic-q-a/68038/ble_gap_evt_disconnected-taking-too-long-after-ble_hci_remote_user_terminated_connection.

  • Hi Vidar, 

    thank you for answer. After some more investigation I have come up with this:

    • I have found out, that DISCONNECT event will really come, but in 5 seconds, it was very confusing to me, since my supervision timeout has been set much lower. Originally I had set up 5 seconds watchdog, so I wasn't alive up to that point already. 
    • I was very confused where this 5 seconds came from, so I have print out some more debug  information and I have found this:
    • Android device immediately after connection (event BLE_GAP_EVT_CONN_PARAM_UPDATE) will give timeout 500 (5 secs)
    • after 2 more negotiations I get what I needed, but it takes about 3 seconds minimum or even more. 
    • This does not happen on iOS - it gives ok to original connection parameters - I have tested values from 20 to 400 
    • Since the communication from connection usually takes about 300ms, sd_ble_gap_disconnect() is issued when the timeout has been set from central (Android) to value 500 (5secs).
    • This is very confusing for me, since I did not expect that this value is possible to change from the central. And it seems like I can get way higher values without any control.
    • In case the event is not acked I am getting additional 5 seconds of power consumption and I can not start new advertising, only scan. I would be able to start advertising if I have more links available, but the code does not count with them now. So it is issue. 
    • I was trying to use sd_ble_gap_ppcp_set(...) with modified values before the disconnect, but it has no affect at all. 
    • Can you advice if there is way, how to speed up disconnection if the ack is not send from peer. It actually happens quiet often at some devices and generally it can happen randomly. And I also would be happy to know if there is correct way to force modification of actual used supervisor timeout. 

    Thank you very much, any help is appreciated,

    Jan 

  • Hi Jan,

    The central always has the final say when it comes to the connection paramaters, which means you can request a specific timeout, but it's not guaranteed it will get accepted.

    bodlak said:
    after 2 more negotiations I get what I needed, but it takes about 3 seconds minimum or even more. 

    Some Android phones will only accept connection param update after the Service discovery is complete. This may explain why the request is non accepted on the first 2 requests. In that case, you may be able to reduce this delay by skipping service discovery (controlled by the presence of the Service changed characteristic).

    Does your device required bonding and do does it include the Service changed characteristic?

    Best regards,

    Vidar 

  • Hi Vidar, 

    thank you for all help. I will check the stuff with bonding. I would like also to post here, someone might be interested this article. We have found out same solution:

    https://blog.classycode.com/a-short-story-about-android-ble-connection-timeouts-and-gatt-internal-errors-fa89e3f6a456

    Thank you again for great support.

    Jan

Related