How to increase the number of packets sent in a single TX transmission?

[HHJ]

I sent a 242-byte data packet, and using the NRF sniffer to capture the packets, I found that this packet was split into (27-byte per packet) for transmission. This caused the entire sending process to take 4ms, while our transmission timing is 3ms, ultimately leading to 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?

[SwRa]

HHJ said:

ms 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.

That is expected.  In BLE, data can only be transmitted during a connection event, which occurs at intervals defined by the connection interval parameter. See here: https://academy.nordicsemi.com/courses/bluetooth-low-energy-fundamentals/lessons/lesson-3-bluetooth-le-connections/topic/connection-process/ 

Connection Event Length Extension is enabled by default in the nRF Connect SDK (SoftDevice Controller). You do not need to manually call a function like  sd_ble_opt_set(BLE_COMMON_OPT_CONN_EVT_EXT, &opt) as you would in the nRF5 SDK. Refer: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrfxlib/softdevice_controller/doc/scheduling.html#connection_timing_with_connection_event_length_extension 

CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=7500 sets the maximum connection event length (in microseconds), which is correct for controlling the event window duration.
CONFIG_BT_USER_DATA_LEN_UPDATE=y and CONFIG_BT_CTLR_DATA_LENGTH_MAX=251 are the correct settings for enabling Data Length Extension and setting the maximum data length.

Best Regards,

Swathy

[HHJ]

I'm sorry, I think I didn't express myself clearly earlier. My timer generates and sends a set of data every 3ms. However, regardless of whether the connection interval is 7.5ms or 15ms, Bluetooth will reply in the next connection interval after receiving the second data packet. Especially with the 15ms connection interval, Bluetooth will reply after more than 10ms. I believe this situation is abnormal and does not conform to our Bluetooth logic. Currently, we are not sure where the problem lies. These are the pcapng files captured by nrf niffer for the 7.5ms and 15ms connection intervals respectively. We look forward to your reply.1172.15ms.pcapng0676.5ms.pcapng

[HHJ]

I sent the wrong file for the 15ms connection interval earlier. This one is the correct file for the 15ms connection interval.15MS_2.pcapng