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?

[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.

[Hung Bui]

@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.