Disconnecting after sending read response

[FormerMember]

I have a project where specification requires disconnecting immediately after sending a response to a BLE read request. I'm using authorized reads.

Currently, I'm using sd_ble_gatts_rw_authorize_reply to send the read response, and then follow with a sd_ble_gap_disconnect. However, in this case, the disconnect is processed before the response is actually sent.

Is there an event of some kind to get notified after the reply has been sent to the central?

[Michael Dietz]

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

[Michael Dietz]

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

[FormerMember]

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.

[FormerMember]

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

[Hung Bui]

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.