Add packets during a BLE connection interval?

[ubat]

Hi there,

 there is so many questions regarding BLE connection intervals, yet I couldn't find a precise answer to this basic question.

It seems to me, that multiple packets are sent in one connection interval only if they were all queued up at the start of the connection interval.

Let's say we have a connection interval of 100ms.

We queue packets at 0.01s, 0.02s, 0.03s and 0.09s.

These will all be sent when the next connection interval starts at 0.10s. One packet will follow as quickly as few 100us after another.

A packets that is being queued at 0.101s - which is during the time of the transmission of the previously queued packets - will only be sent with the connection interval at 0.20s.

Is that understanding correct, or is there a possibility to add packets, while the previously queued packets for this connection interval are still being processed?

Thank you and best regards,

Uli

[Kazi Afroza Sultana]

Hello Uli,

''A packets that is being queued at 0.101s - which is during the time of the transmission of the previously queued packets - will only be sent with the connection interval at 0.20s. 

Is that understanding correct, or is there a possibility to add packets, while the previously queued packets for this connection interval are still being processed?''

Yes there is a possibility of add new packets to the queue that will be sent in the current connection event, as long as the current connection even is not timed out.

Thanks.

Best Regards,

Kazi Afroza Sultana

[ubat]

Hello Kazi,

I ran some more tests but cannot add packets to an up and going connection interval.

For the following tests, I used 2x nRF5340DK and a modified "throughput" example, where I modified the data sending while() loop with some waits.

There are burst of 7 packets transmitted with close to 2.5ms from one packet to the next.

There is a 333ms gap from one burst of packets to the next.

Every time I'm calling bt_throughput_write, I'm raising a GPIO pin, and a 3rd uC board catches the rising slope.

Every time the receiver receives a packet I'm raising a GPIO of the RX board, and the same 3rd uC board catches that.

This is an example of what will happen. The connection interval is set to 30.

...

TX1   365.867140 - Burst of 7 packet starts here ~365.867
TX2   365.869490
TX3   365.871840
TX4   365.874130
RX1   365.875740 - connection interval starts here at ~365.875. 4 packets were queued before.
RX2   365.876740
TX5   365.876760
RX3   365.876860 - last packet received in this connection interval. Only 3 packets were received.
TX6   365.879130
TX7   365.881420
RX4   365.913240 - next connection interval starts at ~365.913, ~37.5ms after the previous CI.
RX5   365.914300
RX6   365.914420
RX7   365.950400

This will happen repeatedly. This means, even shortly before the receiver actually receives the first packet of a connection interval, I cannot add more packets.

The maximum delay - even without retranmission - is therefore slightly bigger than the connection interval.

Is there a way to change this, so I can still add packets during a connection interval?

Best regards,

Uli

[Kazi Afroza Sultana]

Hello,

Sorry for late reply. I have talked to team and got the insight of this case.

The default value for TX packets number queued during one connection interval is set to 3. (https://github.com/nrfconnect/sdk-nrf/blob/main/subsys/bluetooth/controller/Kconfig#L115) . If a throughput increase is required, then this config can be changed accordingly. You can see that only 3 packets were received at RX3 (RX3 365.87860-last packet received in this connection interval. Only 3 packets were received.). This is because of the limitation provided by the kconfig as you can see in the line 115 of the Kconfig file.

config BT_CTLR_SDC_TX_PACKET_COUNT
	int "Number of Link Layer ACL TX buffers"
	default 3
	range 1 20
	help
	  The number Link Layer ACL TX packets reserved per connection.
	  With the default count, the application is able to refill the buffers during a connection event.
	  That is, non-default values should only be used if reduced throughput is accepted, or when the CPU
	  utilization is so high that the application is not able to provide data fast enough during connection events.

Thanks.

BR

Kazi

[ubat]

Dear Kazi,

thank you for getting back to me!

I noticed the limitation to 3 packets also - however, with longer connection intervals, there are more packets transmitted in my tests.

I'll run some more tests with the information you provided, thanks!

[Kazi Afroza Sultana]

You are welcome. The set value 3 can be changed from kconfig and set the application accordance to that. However, You can run your test first and feel free to share us the result. :)