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.

[FormerMember]

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