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

[Stayhungry]

As you just said some of tx_queue principle on SD, I do not know, I think it should be my view of the information is still not enough, in order to improve throughput, I have rewritten the uarte driver, and these questions are my doubts .

[endnode]

Yes, you are closer. The SD with link management lives in its own time and you as application have only indirect evidence about what is happening and when. You should think from opposite side: your APP wants to send some data so you provision as many Tx packets (depending on what role you have it might be WRITE or HVX or something else) as possible to SD and wait. They should go out in time frame of 0 to +-2 connection intervals but you are not sure where exactly in that time sequence you are (because precise timing of the link is known only to lower layers). As soon as stack frees some buffers (= they are acknowledged by LL from the other side as successfully transferred) and as soon as it has time to let APP to do some processing you get asynchronous event call-back to your even t handler with TX_COMPLETE class of events (which one depends on which methods you use).

(1/3)

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

[endnode]

(3/3)

1. Once data re ready to be sent make GATT packets from them (= you might need to fragment) and push to SD queue through the API until it will say no TX buffers available.
2. Wait for TX complete event and try to push again.
3. Repeat steps 1 and 2 until all packets are left from your APP. Then wait for new data to be sent and go to step 1 again.

So you actually should manage your own queue in APP layer on top of similar queue in Soft Device.

[Stayhungry]

Thanks again for your patience to answer, it helped me a lot, and made me have a new idea.

I do not seem to need to think about the size of the package each time tx_queue is put in. Because the concept of the tx_queue is in (G)ATT layer, I can set the tx_queue cache depth to be longer than the payload of 6 LL packets by ensuring that the length of the cached tx_queue is greater than 6 LL pakcet payloads, I guess the SD should be properly split tx_queue, and in the next connection event sent 6 full payload LL packets, if the peer master device can only receive 6 LL packets.