Bluetooth will force the next data packet transmission to wait until after the 7.5ms connection interval.

[HHJ]

We are using the NRF5340 with a Bluetooth transparent transmission example routine. We have set the connection interval to 7.5ms and the transmission timing to 3ms (sending a 242-byte dummy data packet). We observed that Bluetooth can send data packets normally within the 7.5ms interval, but after sending the second data packet, Bluetooth forces the next transmission to wait until after 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" found 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?

[Turbo J]

Check .config file in build/zephyr, the default only has 3 TX buffers enabled:  CONFIG_BT_BUF_ACL_TX_COUNT=3

That won't do for high throughput, try to increase to 10. Careful: Must be in sync with the net core firmware config IIRC. Note that this will increase RAM footprint on both cores.

[HHJ]

Thanks bro

In fact, I've already set the value of CONFIG_BT_BUF_ACL_TX_COUNT as large as possible, setting it to 18. I'm not sure about its specific impact; it might take up more space, but right now I just want to solve the problem.

[dejans]

Hi HHJ 

I can see that you have asked the same question in this ticket 
devzone.nordicsemi.com/.../bluetooth-cannot-send-data-packets-within-the-connection-interval
I also see that you have already provided sniffer logs in that ticket. Therefore, I suggest that if needed you continue with further inquiries in that thread.

Best regards,
Dejan