Empty connection intervals after sending/receiving a complete packet

[marklander]

Hi guys,

 i show you an image here where I am sending from my board a text file ( about 75KB ) to nordic toolbox via nus, I use notify to send ( but I have similar situation when receiving from nrf toolbox).

Basically I see some empty connection interval ( 3 usually ) between a notify indication and the next one, also if probably data could be sent also in that period. I am using an MTU of 259 ( i will attach also sniffer log).

All is working, but obviously that silent of 3 connection intervals slows my data rate. Could that be an Android limitation? I tried with 3 android phones and seems identical, they all force my connection interval to 11.25 ms.

In red the event id 2938 with full packet incoming and notified, the 3 empty intervals in blue.

Full log:

empty_intervals.pcapng

[Einar Thorsrud]

Hi,

If the stack has data to send, I would not expect empty packets. How are you pushing the data in your implementation?

Also, if you want a higher throughput I would consider using data length extension so that you can send longer packets also at the GAP layer and avoid fragmentation.

[marklander]

Ok some details more:

• I am using a 100KB text file copied inside a macro in nrf toolbox to send an I am using write_without_response to send from master ( android device ) to slave ( my embedded board ) and notify in the other direction.
• Due to my small microcontroller i am on s112 which not have the possibility to use DLE, but i tried also with that and I cannot see a big improvement. I can try again with s113 anyway which supports DLE.

I was reading something similar here...post.

Thanks for your support Einar Thorsrud and if I can send some more infos to get more data rate tell me if you need some logs...now I am still around a rough 9 to 11 KB/s

Did another round activating DLE with S113:

Also in the pic above you can see that some connection intervals are empty. Sniffer log below.4048.sniffer.pcapng.

Here parameters of connection:

And DLE req:

Res:

[Einar Thorsrud]

Hi,

As you have multiple empty packets here and also the more data field is not set to false this indicate to me that you are not providing data fast enough to the stack. Can you share more details about your implementation? Generally, for maximum thoughput you should push data with sd_ble_gatts_hvx() until you get an error (NRF_ERROR_RESOURCES). And then wait for BLE_GATTS_EVT_HVN_TX_COMPLETE and continue calling sd_ble_gatts_hvx() until you get an error, and so on. That way, you can ensure that the BLE stack always have data to send.

[marklander]

Hi Einar Thorsrud ,

first of all thanks for your kind answer. Regards your doubts I can agree, but... what you're lookin at is the flow from mobile app (nrf connect) to my embedded app, so I have not any kind of control on how data is sent from NrfConnect.

As I pointed out in another post I am trying to send a file ( about 80KB/s ) from a macro button of the app. I don't know if it's a good way to do that, but It seems to that there are no other tools with a send file option.

From my side i am using rust for the embedded application.

Let me know I misunderstood something in your answer, but I think that kind of fragmentation is related to mobile app imo.

Thanks!

[Einar Thorsrud]

Hi,

marklander said:

Let me know I misunderstood something in your answer, but I think that kind of fragmentation is related to mobile app imo.

You are right, I was reading it too quickly and assumed the nRF was senidng notifications (though the sniffer trace shows it is the central sending write commands). On the mobile app side there is nothing you can do (that is not available in source). Also, the bluetooth stack in both iOS and Android will have to prioritize traffic and also schedule other 2.4 GHz activity like Wi-Fi, and there is power optimization considerations that are enforced by the OS.

[marklander]

Uh sorry, could be my fault:

• 4048.sniffer file indeed have master sending data (Nrf Toolbox).
• empty_intervals file has slave sending and probably there is indeed some improvement to do, I have the opposite path, an UART sending data to ble and I know I am running in NO_RESOURCES error many times, probably need to better manage it.

Around same topic I can show you another log from my wife POCO x3 phone where you can see event 2642 here below:

Lot of packet in the same event, this made me crash for low buffering I suppose, still sending from NRF toolbox...many many different behaviours, below the log of image, you will  see lot of tx before event 2642, that is sending a lot of tx inside.

poco-crash.pcapng

From my side of embedded board, can you confirm me that this variable hvv_tx_queue_size is the one related to the max number of packet I can bufferize on my side before getting no resources available?

[Einar Thorsrud]

Hi,

The empty packets here are acknowledgments. So tings seem quite optimal here? (I see retransmissions in the end of the trace which I assume is due to the crash you describe, but nothign in the trace before that which indicate an issue)

[marklander]

Right Einar Thorsrud , last part with no ACK is due to the crash 100% Yes in that log tx is good and I have peaks of data rate of 20KB/s which is not bad.

May I ask you a  confirmation about this below... it's related to the other direction of the flow. From my embedded app to nrf toolbox.

marklander said:

From my side of embedded board, can you confirm me that this variable hvv_tx_queue_size is the one related to the max number of packet I can bufferize on my side before getting no resources available?

[Einar Thorsrud]

Regarding hvn_tx_queue_size that is a bit complicated. The hvn_tx_queue_size can be used to configure the size of the dedicated HVN queue. However, internally ther eis also a shared link layer queue, and that is used first. So the hvn_tx_queue_size will be the minimum amount of packets that can be queued, but the maximum (and typical) will be higher.

[marklander]

Thanks...so that's not a so improving tweak let me say...

[Einar Thorsrud]

No, and in any case this is only relevant when sending notifications (so when you are sending from the GATT client to the GATT server). The hvn queue on the nRF is not relevant when the peer is sending write commands.