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.

[Shahar]

Adding my relevant points here,

If you use S140 or S132 you have the option of using the nrf_ble_qwr library, which AFAIK can queue the messages.

This is what being used in the throughput examples.

Further more, if you use enable BLE_COMMON_OPT_CONN_EVT_EXT

void conn_evt_len_ext_set(bool status)
{
    ret_code_t err_code;
    ble_opt_t  opt = {0};

    opt.common_opt.conn_evt_ext.enable = status ? 1 : 0;

    err_code = sd_ble_opt_set(BLE_COMMON_OPT_CONN_EVT_EXT, &opt);
    APP_ERROR_CHECK(err_code);
}

You can chain multiple packets into the same connection

[PRvdO]

Thanks for your input.

I thought that nrf_ble_qwr is for queuing messages written to our characteristic (Rx) whereas I'm talking about us sending a message to other devices (Tx). Is this not the case?

Also, as we are using indications then I'm not sure that this normal write functionality works for us. We have to use sd_ble_gatts_hvx() to send.

Unfortunately I don't think that option will help much either as we want to send messages to multiple devices and I think that chaining them only works for sending multiple messages to the same connection.

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