BLE Timing Variation While Streaming Live Microphone Data

RE: BLE Timing Variation While Streaming Live Microphone Data

Sigurd — Tue, 24 Mar 2026 13:15:55 GMT

Hi!
In your application directory, create this file:

your_app/
├── prj.conf
├── sysbuild.conf              ← (optional, for sysbuild-level config)
└── sysbuild/
    └── ipc_radio.conf         ← Network core overlay

sysbuild/ipc_radio.conf contents:

CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_BUF_ACL_RX_SIZE=251
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251

Verify Your App Core prj.conf

# DLE & Buffers
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_BUF_ACL_RX_SIZE=251
CONFIG_BT_USER_DATA_LEN_UPDATE=y

# PHY
CONFIG_BT_CTLR_PHY_2M=y

# Throughput tuning
CONFIG_BT_BUF_ACL_TX_COUNT=20
CONFIG_BT_L2CAP_TX_MTU=247
CONFIG_BT_ATT_TX_COUNT=20

# Connection parameters
CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=n

Do a clean build, after building, check the network core's generated config is correctly set.

in build/ipc_radio/zephyr/.config

Search for:

CONFIG_BT_CTLR_DATA_LENGTH=y          ← must be 'y'
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251    ← must be 251
CONFIG_BT_BUF_ACL_TX_SIZE=251

If CONFIG_BT_CTLR_DATA_LENGTH_MAX=27 or CONFIG_BT_CTLR_DATA_LENGTH is not set, the overlay isn't being picked up.

RE: BLE Timing Variation While Streaming Live Microphone Data

G vandana — Mon, 23 Mar 2026 12:11:31 GMT

Hi sigurd
Description:
I am developing a high-throughput application on the nRF5340 (custom board/DK) aiming for 250–400 kbps.
While MTU and PHY updates are successful, the Data Length Extension (DLE) update consistently fails, bottlenecking the throughput.

Environment:

SoC: nRF5340

SDK: nRF Connect SDK (v3.1.0)

Peer Device: Samsung A54 (Android 14)

Current Status & Test Logs:

MTU Negotiation: Success (MTU 247 / Payload 244).

PHY Negotiation: Success (2M PHY enabled).

DLE Negotiation: Fails. Calling bt_conn_le_data_len_update returns Error -5 (EIO).

Observed Timings:

Data Size: 32,000 bytes

Total Time: 5,587 ms

Effective Throughput: ~45 kbps

Analysis: The 45 kbps speed at a 7.5ms interval suggests the link is falling back to 27-byte fragments because DLE is not active.

Code Implementation:
I am using an asynchronous queuing model with bt_gatt_notify_cb and a TX callback to manage in_flight packets.
The in_flight count stays at my limit (55), proving the stack is saturated, but it is processing tiny packets.

Configuration (prj.conf):

Makefile
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_BUF_ACL_RX_SIZE=251
CONFIG_BT_USER_DATA_LEN_UPDATE=y
CONFIG_BT_CTLR_PHY_2M=y
CONFIG_BT_BUF_ACL_TX_COUNT=80
Attempted Fixes:

Created child_image/hci_rpmsg.conf with matching DLE/ACL buffer sizes to ensure the Network Core is configured.

Performed "Pristine Builds" to ensure the Controller child-image is rebuilt.

Verified with nRF Connect Mobile; the phone supports DLE, but the nRF5340 returns Error -5 locally.

Question:
Why would the nRF5340 Controller return -EIO (-5) when the App Core requests BT_LE_DATA_LEN_PARAM_MAX,
even though the ACL_TX_SIZE and DATA_LENGTH_MAX are set to 251 in both the App and Net core configurations?
How can I verify if the Network Core is actually accepting these memory allocations?
How to achieve max throughput of 250kbps?

RE: BLE Timing Variation While Streaming Live Microphone Data

Sigurd — Wed, 18 Mar 2026 11:36:42 GMT

For sending large amount of data, I recommend having a look at how the throughput sample is configured. That sample show-cases maximum throughput performance

https://github.com/nrfconnect/sdk-nrf/blob/v3.2.0/samples/bluetooth/throughput/sysbuild/ipc_radio/prj.conf

RE: BLE Timing Variation While Streaming Live Microphone Data

G vandana — Tue, 17 Mar 2026 11:53:13 GMT

“Can you help me configure BLE to send the maximum number of packets within a connection interval? I have set the connection interval to 15 ms, and I want to minimize the time required to transmit a large amount of data (12 KB)

RE: BLE Timing Variation While Streaming Live Microphone Data

Sigurd — Thu, 12 Mar 2026 13:50:47 GMT

Hi!

bt_gatt_notify does not transmit data immediately. It only queues data into the BLE stack's TX buffer, and then it's sent in the next BLE connect event (if there is nothing else already queued up). So the time here will vary between when you call bt_gatt_notify() in relation to when the next BLE connect event is.