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.

[Stayhungry]

Thanks,endnode.

If ATT_MTU = 23, ignoring packet retransmission, if the connection interval is 50ms, tx_queue is large enough and the MCU is running at the beginning of interval

When I call sd_ble_gatts_hvx (buffer, buffer len = 20) continuously for 3 times within 10ms, then delay 5ms for other processes to run, then call sd_ble_gatts_hvx (buffer, buffer len = 20) 3 times within 10ms, Is it possible to send 6 pakcets in a connection event?

If ATT_MTU = 23, tx_queue = 3

Case 1, I call in a row: sd_ble_gatts_hvx (buffer, buffer len = 20), sd_ble_gatts_hvx (buffer, buffer len = 10), sd_ble_gatts_hvx (buffer, buffer len = 8), sd_ble_gatts_hvx (buffer, buffer len = 15),

Case 2, I call in a row: sd_ble_gatts_hvx (buffer, buffer len = 20), sd_ble_gatts_hvx (buffer, buffer len = 20), sd_ble_gatts_hvx (buffer, buffer len = 20), sd_ble_gatts_hvx (buffer, buffer len = 20),

I think the two cases of the fourth call sd_ble_gatts_hvx will return BLE_ERROR_NO_TX_BUFFERS, the result is that I send packets in both a connection event number is 3, but the total length of the data sent is not the same, may I ask Understand right? If my understanding is correct, I have to consider the buffer len for each call to sd_ble_gatts_hvx for optimal throughput

[endnode]

You seems to be missing how BLE stack works: it needs to have all the packets prepared before connection interval starts. If you have 50ms interval then at the start SD will try to send as many packets as possible (meaning they must be already in the queue, SD must have certain bandwidth configured for the link and also the peer on the other side must be able to proceed with multiple PDUs) but then whatever you will try to push through TX buffers won't get transmitted before next connection interval. So I don't get what you fiddle with 10ms and 5ms delays if your interval is 50ms. Moreover the Link Layer inside the stack is more or less asynchronous to what you do in your application on top. The fact that you got callback on TX_COMPLETE even doesn't mean that packet was sent NOW. There are many timing differences which can take long milliseconds, don't try to measure time like this.

[endnode]

Btw. are these just theoretical examples or you really has this in your FW and you have some real observations? If you just speculate then simply stop and start to play with simple examples (with two nRF5x boards it should be quite easy). You will learn much more from that...

[Stayhungry]

Thanks for your detailed reply.

You mean before the start of the connection event, I have to fill in the tx_queue, and SD will make some necessary preparations for that. At some point, I will receive the TX_COMPLETE event, but this does not mean this time the connection event Has been completed, not even started, but I can already fill the tx queue for the next connection event, so you think time is meaningless, may I understand it?

What do you think of my question 2?

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