Bluetooth transmission blocking issue

[HHJ]

Previously, when our NRF5340 was transmitting at a 3ms interval, we encountered issues where the transmission speed failed to meet requirements, with data packets being discontinuous or, in other words, experiencing packet loss. Typically, dozens of packets would be lost between two consecutive packets (which appeared to be a congestion issue). By adjusting the CONFIG_BT_CTLR_RX_BUFFERS parameter from 2 to 18, we significantly improved performance. Now the transmission speed meets requirements, and the packet loss rate has reduced to only one packet lost between two consecutive packets. Unfortunately, 18 is already the maximum parameter value. However, we want to achieve zero packet loss. Currently, this can only be achieved by reducing the transmission speed – when set to 10ms intervals, there is no packet loss. But we need the speed to be 3ms. We still believe the issue is related to RX_BUFFERS. We would like to know which similar RX_BUFFERS configurations can achieve the same effect. It seems that RX_BUFFERS is a large family of configurations. Please help us with this.

[Einar Thorsrud]

Hi,

Can you elaborate more about your system? You write 3ms, what exactly happens at this interval? (I ask as the minimum connection interval in Bluetooth is 7.5 ms). Also, when you write packets is lost, what do you mean by that? Is it lost on air (if so it would be retransmitted, and a sniffer trace would also be useful. Or could it be that buffers are full, and you are attempting to send data (perhaps as a notification) and that fails? If so, do you check return values so that you would know that it failed?

Regarding adjusting buffers, you can refer to the pro.conf from the Throughput sample for the app core and the also this one for the net core.

[HHJ]

Thanks bro

We have refined our configuration based on the one you provided, but this appears to have had no effect. I suspect the issue lies with the buffer configuration—specifically, the RX_buffers setup remains inadequate.

I transmitted 242 bytes of dummy data at 3ms intervals. For details on packet loss and error return value checks, I will share this with you via images. Notably:

• 64 serves as the packet header;
• The byte immediately following is the packet sequence number (consecutive sequence numbers indicate no packet loss);
• The remaining data in each packet is identical.

Previously, we saw substantial improvements by adjusting the value of CONFIG_BT_CTLR_RX_BUFFERS. We therefore hypothesize that resolving the current issue still requires focusing on the buffer. This is particularly evident when reflashing: typically, the first 10-13 packets arrive consecutively, but losses occur thereafter.

[Einar Thorsrud]

Hi,

I see form the log that you get a lot of -12 errors, which is -ENOMEM. And the rest of the log also indicate that you are attmepting to notify faster than what is actually transmitted.

What is the connection parameters of the link? I am mostly interested in connection interval, but also of course that you have data length extension with long enough packets and the event length. As you have a new chunk of data every 3 ms that means you need to transmitt multiple packets per connection event event. It may also sense to use longer ocnnection events in this case to reduce overhead (though this means you will likely loose more data after a packet loss at retransmissions always happen on the next connection event).

To be honest, you are pushing the limits of what is possible with a 1 Mbps BLE link as 242 bytes per 3 ms is about 645, so this will requiere well thought out parameters and it will be prone to data loss whenever there is packet loss. If you have not allready, you should consider using 2 Mbps PHY for this reason.

[HHJ]

Thanks bro

I'll show you the configurations related to connection intervals, data length extension, and sending multiple packets in one transmission interval via images. As a matter of fact, we've been using the 2M PHY all along.

Fortunately, we've discovered a more interesting issue than the RX_BUFFERS problem. When capturing data packets with the nRF sniffer, we noticed that the data packet is split into smaller ones (27 bytes per packet) for transmission. This causes the entire transmission process to take 4ms, while our transmission timing is set to 3ms, ultimately resulting in a stack overflow on the transmitting end.

How can we increase the single transmission size, and which configuration allows us to send a 242-byte data packet in one go?

[Einar Thorsrud]

Hi,

If packets are 27 bytes, data length length extension is not used for some reason. If the peer does not trigger it, you can do it with a call to bt_conn_le_data_len_update().

Some questions to understand more:

• Can you share the actual sniffer trace (not just a screenshot) so we can see the packet exchange to understand more about the paramters that is used and why?
• Regarding configs, can you share the files and prefrably also the generated .config so we see the configuration parmaters actually used in the build?
• What is the peer device you are testing with? (this also need to be configured for and supprot the desiered parameters).