Disconnecting after sending read response

RE: Disconnecting after sending read response

Hung Bui — Mon, 31 Aug 2015 09:28:28 GMT

Hi Etan, You are welcome. If you are OK with the answer, please mark it as correct so we can close the case :)

RE: Disconnecting after sending read response

FormerMember — Sat, 29 Aug 2015 10:59:57 GMT

First workaround sounds okay - second one looks a bit hackish ^^ Thanks!

RE: Disconnecting after sending read response

Hung Bui — Thu, 27 Aug 2015 12:13:59 GMT

@Etan: If you can't send another write request, you can think of using a timer to disconnect after few connection interval. This won't guarantee that the write response has been received. But if you set the timer time out larger than the connection timeout, then you can be sure, it will be either the write response has been received (then disconnect), or the connection will be timed out.

Another option is to queue several (more than 7th) notification on the peripheral until it's full, if you can add more notification after it's full, you can safely disconnect, because you can only send more notification when the write response is finished.

RE: Disconnecting after sending read response

FormerMember — Thu, 27 Aug 2015 12:04:13 GMT

But thanks for the suggestions! <3 You guys are awesome for the fast support you provide!

RE: Disconnecting after sending read response

FormerMember — Thu, 27 Aug 2015 12:03:55 GMT

Unfortunately, I don't have control over the central. So I cannot change the way the protocol works.

RE: Disconnecting after sending read response

Hung Bui — Thu, 27 Aug 2015 12:01:58 GMT

Hi Etan,

I think it makes sense on what you have observed. When calling sd_ble_gatts_rw_authorize_reply() returns NRC_SUCCESS , it only means the reply is queued. It queued and prepared to be sent in the next connection event. However, you call sd_ble_gap_disconnect() right after that. This call won't wait untill both the application buffer and stack internal buffer are free before sending the connection terminate command. It will be executed in the next event. So what queued in the buffer(s) will be discarded.

My suggestion for you is to do write request 2 times. So that when you got the first write request, you reply and then set a flag. On the client, when you have the reply, and want to disconnect, you send another write request. On the server, when receive the second write request, and if the flag is set, you can simply disconnect. The reason we do this because, with BLE protocol, only one write request can be performed at a time. When the first one is not done, write response successfully received, the next write request won't be executed.

By waiting for the next write request, we can be sure the first one have been replied and can disconnect, without replying to the second write request.

RE: Disconnecting after sending read response

FormerMember — Wed, 26 Aug 2015 18:33:55 GMT

I call sd_ble_gatts_rw_authorize_reply with NRF_SUCCESS. The response is properly queued up if I remove the disconnect call.

RE: Disconnecting after sending read response

FormerMember — Wed, 26 Aug 2015 13:10:43 GMT

Maybe some more generic events, like the "Number of Completed Packets" event could help? I know that there's no documented event for what I want, but maybe there's a trick to achieve my goal.

RE: Disconnecting after sending read response

Michael Dietz — Wed, 26 Aug 2015 13:10:25 GMT

where response is queued upon app returning NRF_SUCCESS - which seems to be where your problem arises.

RE: Disconnecting after sending read response

Michael Dietz — Wed, 26 Aug 2015 13:08:27 GMT

Quick answer: based on this message sequence chart it doesn't look like there are any events being generated after the reply has been sent to the central.

gatts_read_request_with_authorization.png

Maybe someone else can help though.

-Mike