sd_ble_gatts_hvx cache

[Stayhungry]

1、how long will it take for me to cache?

Once I call sd_ble_gatts_hvx, assuming tx_queue is large enough, how long can I cache data to softdeivce?

For example, I called sd_ble_gatts_hvx once, and then called again after 5ms. Can I cache successfully,Or the data has been sent out? Why?

2、Cached data and the size of the actual packet sent

If ATT_MTU is set to 247, LL payload = 251, tx_queue = 2, should I get NO_RESOURCE once if I call sd_ble_gatts_hvx(buffer, buffer len = 100) third times ?

This time actually sent the package which payload len = 200byte?

Thanks

[endnode]

1. How long? Doesn't make sense. Tx queue size is partially configurable in Nordic Soft Device and how much time it takes to flush it over BLE that's impossible to say as it depends on how BLE connection link performs at that moment (what is the interval, what is packet loss etc.) So forget about time, there is no guaranteed time when it comes to radio like BLE.
2. Tx queue size in Nordic Soft Device should have "slots" so on (G)ATT layer it can hold certain number of packets regardless the size. So you can get BLE_ERROR_NO_TX_BUFFERS error code in response if you try to push some more outgoing packets but there is no available Tx slot on (G)ATT layer in the SD. The size doesn't matter.

[endnode]

(2/3)

And the story continues from the beginning. You again get whatever data you have ready, slice it to GATT layer packets and try to push as many as possible to the stack. And they will again go out not sooner then at next connection interval (which can be just starting or can be full time ahead - you don't know and you should not assume!) but can be much later depending on how many packets are in the queue, how many packets is your peer able to accept within one interval, what is packet loss etc. Also note that (G)ATT packets like HVX are still pretty high in the BLE stack architecture and what i really exchanged are LL PDUs. So there can be various situations with different PDU and ATT_MTU lengths where the actual data exchange over radio is even more complicated. Again from your APP you should not care, just simply execute your state machine: