How does sd_ble_gatts_hvx() queue messages?

[PRvdO]

Does `sd_ble_gatts_hvx()` queue indications and if so then when does the next message get sent; after the previous one is sent or after the receiver acks the previous one?

We are using `sd_ble_gatts_hvx()` in our application to send BLE indications to connected devices.
The documentation for this function mentions that there is a queue for sending these messages set by `ble_gatts_conn_cfg_t::hvn_tx_queue_size`.
However, when calling `sd_ble_gatts_hvx()` multiple times we just get back a NRF_ERROR_BUSY response until the previous message has been acknowledged no matter how large we make the queue.

From the documentation I was under the impression that we could call `sd_ble_gatts_hvx()` and the messages will be added to the queue and SD would handle the sending of the indications once the previous one has been sent, this does not seem to be the case.

[Amanda Hsieh]

Hi, 

Note that NRF_ERROR_BUSY is sometimes a symptom on a function that is not used as intended. Example; if you use sd_ble_gatts_hvx() to send an Indication, but calls the sd_ble_gatts_hvx() again before you receive confirmation from GATT client on the previous Indication, you will get NRF_ERROR_BUSY. In this case, the solution is to wait for confirmation in the BLE event BLE_GATTS_EVT_HVC before calling sd_ble_gatts_hvx() again. See the GATTS Handle Value Indication documentation:

Only one indication procedure can be ongoing per connection at a time. If the application tries to indicate an attribute value while another indication procedure is ongoing, the function call will return NRF_ERROR_BUSY. A BLE_GATTS_EVT_HVC event will be issued as soon as the confirmation arrives from the peer.

-Amanda H.

[PRvdO]

Hi Amanda, thanks for the reply.

I read "Only one indication procedure can be ongoing per connection at a time." to mean that we can have multiple indication procedures at a time as long as they are to a different connection and that is what seems to not work. Am I miss-reading this or should we be able to have n indications at a time as long as they are all going to a different conn_handle?

Currently we have:

1. Indication to conn 0.
2. Waiting for ack.
3. Ack from conn 0.
4. Indication to conn 1.
5. Waiting for ack.
6. ...

We would like to have it so that we don't have to wait on conn 0 to ack before we send to conn 1.

1. Indication to conn 0.
2. Indication to conn 1.
3. Ack from conn 0.
4. Ack from conn 1.

Is this possible? Does sd_ble_gatts_hvx() handle this?

Thanks for the help!

[Amanda Hsieh]

You would need to wait for the confirmation of the peer after you send the first indication (BLE_GATTS_EVT_HVC event) before you can send the next indication. See the GATTS Handle Value Indication documentation.

-Amanda H.