Is notification data queued if BLE_GATTS_VLOC_USER?

[Elias]

If I am programming a BLE Server device, and I configure a characteristic with BLE_GATTS_VLOC_USER and queue a notification with sd_ble_gatts_hvx(), how soon can I update the characteristic value?

With BLE_GATTS_VLOC_STACK, I know you can call sd_ble_gatts_hvx() and update the characteristic repeatedly until the notification queue is full, and all of the characteristic values will be sent, so long as the function returned NRF_SUCCESS each time.

Does the data still get queued in this way with BLE_GATTS_VLOC_USER, or can I only update the value and call sd_ble_gatts_hvx() after each transmission event?

Furthermore, is this behavior documented anywhere, in case it changes with a future SoftDevice version?

[Hung Bui]

The buffer of sd_ble_gatts_hvx() is the TX buffer and is not related to what you declare your characteristic. Doesn't matter your characteristic is BLE_GATTS_VLOC_USER or BLE_GATTS_VLOC_STACK, its value is queued in the TX buffer the same way. If it return success, the data is copied and queued, if not you have to retry when you have TX_COMPLETE event.

[Elias]

So sd_ble_gatts_hvx() completely avoids the characteristic value? I guess that makes sense, especially if you're sending a lot more data than can be held in a characteristic.

[Hung Bui]

No, it doesn't avoid the characteristic value. It will update the value every time you call the function and NRF_SUCCESS is returned.

[Elias]

And there's no way to avoid the two (internal to the SD) memcpy()'s every time you call sd_ble_gatts_hvx()?

[Hung Bui]

You meant memcpy to update the characteristic value and to put the a packet into TX buffer ? No, I don't think there is a way to avoid that. Could you let me know why you don't want the value of the characteristic to be the most updated one ?

[Elias]

Actually, I just realized that you can call sd_ble_gatts_hvx() with NULL, and it'll use the current characteristic value.

For the record, if you're sending a stream of data via notifications, then the value is going to be constantly updated and you can know at the application level that the Client will never attempt to read the Characteristic manually. In this case, there is no real danger of the Client reading stale data.