Bluetooth cannot send data packets within the connection interval.

[HHJ]

Our company has previously used the NRF52840, and we know that by modifying the GAP event length (NRF_SDH_BLE_GAP_EVENT_LENGTH), we can enable Bluetooth to transmit multiple data packets within one connection interval. Currently, our NRF5340 is encountering a similar issue: when its transmission speed is greater than the connection interval, it can send normally, but when its transmission speed is less than the connection interval, there will be cases where data packets fail to send (just like packet loss). We want to know what parameters can be configured in NRF5340 with nrf connect v3.1.0 to achieve the effect of GAP event length. We hope you can help us

[Edvin]

Hello,

So when you are saying that you are seeing packets are being failed to send, you mean that you are not able to queue them properly? If a packet is queued, it will be sent, however many retries it uses. This is according to the Bluetooth specification.

So you should see it in the API that you are using to send packets. At some point, it should stop returning 0, and it will start returning an error value. 

But the root problem here is that the bluetooth connection doesn't have enough throughput, I guess. You are queuing up packets faster than the device is able to send them, and eventually, you will have packets that are not able to be queued properly.

I can recommend that you check the sample:

v3.1.0\nrf\samples\bluetooth\throughput

Relevant for the nRF5340 are the files:

boards\nrf5340dk_nrf5340_cpuapp.conf
prj.conf
Kconfig.sysbuild
sysbuild\ipc_radio\prj.conf

Note that it is in the last file, sysbuild\ipc_radio\prj.conf that the parameters for connection event length and increased MTU is set. All the parameters that belongs to the radio core on the nRF5340.

This is also described in our DevAcademy Bluetooth Low Energy Fundamentals course. Particularly Lesson 3 is describing how to change the connection parameters.

Best regards,

Edvin

[HHJ]

Thanks bro

According to your suggestions, our performance has been improved.

We have set the connection interval to 7.5ms and the transmission timing to 3ms. We found that Bluetooth can send data packets normally within the 7.5ms interval. However, after sending the second data packet, Bluetooth will force the next transmission to wait until the end of the 7.5ms connection interval, which causes blockage on the transmitting end.

Currently, we have configured the connection event extension with CONFIG_BT_USER_DATA_LEN_UPDATE=y, CONFIG_BT_CTLR_DATA_LENGTH_MAX=251, and the GAP event interval with CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=7500.

Are we missing any key configurations such as the "Connection event length extension" in nRF52840, like setting opt.common_opt.conn_evt_evt.enable=true; err_code=sd_ble_opt_set(BLE_COMMON_OPT_CONN_EVT_EVT,&opt);? Or are there any existing configurations that need to be enabled in the main function?

[Edvin]

Sorry, I forgot this was the nRF5340. You need to add this config to the sysbuild\ipc_radio\prj.conf. Is that the one that you sent me?

Will I be able to reproduce the behavior that you are seeing if you zip the applications (peripheral and central)? Do I need any external HW, other than a couple of DKs?

Best regards,

Edvin

[HHJ]

Thanks bro

Sorry, I forgot to send you the prj.conf for ipc_radio. I might be missing key configurations in the prj.conf of ipc_radio, so could you please help me check it? I will send it to you right away. You don't need any other hardware; a central device and peripheral devices are sufficient.81441.prj.conf

[HHJ]

I have checked the prj.conf of my ipc_radio, and all the key configurations from the file at v3.1.0\nrf\samples\bluetooth\throughput\sysbuild\ipc_radio\prj.conf have been included in mine.

Interestingly, when my timer K_MSEC() is set to 4 and the connection interval is set to 7.5ms, data packets do not queue (-12), but the rate is 3.8ms, which does not meet our target of 3ms. When K_MSEC() is set to 4 and the connection interval is 15ms, data packets start to queue (approximately 2 out of every 5 packets are queued). When K_MSEC() is set to 3 and the connection interval is 7.5ms, data packets also queue (roughly 1 out of every 3 packets is queued). If K_MSEC() is set to 3 and the connection interval is 15ms, even more data packets will queue.

This seems very much like a blockage at the TX (transmit) end. Regrettably, however, adjusting the value of CONFIG_BT_BUF_ACL_TX_COUNT does not result in any observable changes.

[Edvin]

Can you please zip and upload your peripheral and central application, so that I can have a look?

HHJ said:

approximately 2 out of every 5 packets are queued

When you list numbers like this. Does 3 out of every 5 packets return -12 when you try to queue them?

BR,
Edvin

[HHJ]

Thanks bro

Our problem has been solved.

BR

kevin