BLE throughput differs between NCS v2.6.0 and v2.9.2.

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

Edvin — Wed, 10 Jun 2026 06:28:04 GMT

Yes. 20000 would be 20ms per connection interval.

BR,

Edvin

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

chiba — Wed, 10 Jun 2026 04:37:23 GMT

> To make lock_5340dk_ncs292 behave the same as lock_5340dk_ncs260, should it be changed to 2000?

I was wrong. It's 20000.

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

chiba — Tue, 09 Jun 2026 23:55:08 GMT

Got it. Thanks.

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

Edvin — Tue, 09 Jun 2026 11:48:55 GMT

yes.

BR,
Edvin

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

chiba — Tue, 09 Jun 2026 08:02:05 GMT

Hi,

I understand the description of CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT.

I would like to know how to configure it so that it behaves the same as lock_5340dk_ncs260.

For lock_5340dk_ncs260 and lock_5340dk_ncs292, CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT is set to 7500.

To make lock_5340dk_ncs292 behave the same as lock_5340dk_ncs260, should it be changed to 2000?

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

Edvin — Tue, 09 Jun 2026 07:18:32 GMT

Yes, as well as:

CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=20000

[µs] Adjust this one to as long as the maximum amount of time you want the device to spend on the BLE connection. Remember that it will not spend this time unless the other device has data to send. But if the connected device has a lot of data, it may spend up to this amount of µs for BLE on every connection interval (meaning this amount of time will not be spent on Matter/Thread).

Best regards,

Edvin

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

chiba — Tue, 09 Jun 2026 00:57:28 GMT

Hi,

Thanks, I understand now.

To make it behave the same as NCS262, should I just add the following setting?

CONFIG_BT_CTLR_SDC_CONN_EVENT_EXTEND_DEFAULT=y

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

Edvin — Fri, 05 Jun 2026 14:08:06 GMT

I do see that there have been some changes to the SoftDevice controller regarding the reset state of the softdevice controller between these versions, which probably explains the difference in behavior.

In v2.9.2 changelog, there is an explicit change:

Extended Connection Events are not re-enabled on HCI Reset; previous state is preserved.

See v2.9.2/nrfxlib/softdevice_controller/CHANGELOG.rst

In v2.6.2 API docs, conn event extend says that after HCI Reset, Extended Connection Events are enabled by default.

Please see these:

https://github.com/nrfconnect/sdk-nrfxlib/blame/v2.9.2/softdevice_controller/CHANGELOG.rst#L100

https://github.com/nrfconnect/sdk-nrfxlib/blob/v2.6.2/softdevice_controller/include/sdc_hci_vs.h#L980

That should explain the difference in behavior. Now that you know how to configure it in v2.9.2, you can tune it to work the way that you want it to work in your application.

Best regards,

Edvin

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

chiba — Fri, 05 Jun 2026 10:24:51 GMT

HI,

I understand that the state changes with CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT.

However, the default value is set to 7500 for both NCS260 and NCS292.

- NCS292: build\ipc_radio\zephyr\include\generated\zephyr\autoconf.h

- NCS260: build\multiprotocol_rpmsg\zephyr\include\generated\autoconf.h

Why do they behave differently?

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

Edvin — Fri, 05 Jun 2026 08:15:04 GMT

I realized something.

While yes, there were retransmissions, I thought it was because the radio was reserved for Thread, and perhaps the default value did change between 2.6.2 and 2.9.2.

Try adding this to your lock_5340_292 application:

sysbuild\ipc_radio\boards\nrf5340dk_nrf5340_cpunet.conf:

CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT_OVERRIDE=y
CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=20000

What this does is that it tells the device that it can spend more time each connection interval handling one BLE connection. In this case 20ms. It does not mean it will spend 20ms in cases where there is no more data being sent. It does however mean that when there is a lot of data on BLE, it will spend less data on Thread, leading to poorer Matter performance. Retransmissions will handle this, so you shouln't ultimately loose any packets. It is simply a tradeoff whether you want to prioritize radio time on BLE or Matter.

Using this, I see that all 8 packets are sent within one connection interval, as you can see in the attached trace, but feel free to check this yourself:

devzone.nordicsemi.com/.../new_5F00_trace_5F00_2_5F00_292.pcapng

FYI: I used a slightly modified version of your sample while working on this, so that it uses a static address on every boot, to easier find it on the BLE sniffer:

devzone.nordicsemi.com/.../lock_5F00_5340dk_5F00_ncs292_5F00_mod.zip

Look for a device advertising using the address: C0:DE:DE:AD:DE:AF (the advertising name is still the same.

Best regards,

Edvin

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

chiba — Fri, 05 Jun 2026 03:03:25 GMT

Hi,

I believe the underlying throughput issue stems from differences in MD packets.
It appears that the NCS292 can transmit fewer MD packets per CI.
The sample project I provided is intended solely for verifying these differences in MD packets.
I am not concerned with throughput or data loss in this project.

> From your ...292.pcapng trace I saw that there wass a lot of packet loss, but the traces themselves can't tell why the central didn't try to send more packets.

This is exactly what I want to check.

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

Edvin — Thu, 04 Jun 2026 13:20:17 GMT

Hello,

So I looked at your applications, and captured a sniffer trace between the lock_5340_ncs292 and the central_52840dk applications, and this is what I got in my office environment:

devzone.nordicsemi.com/.../new_5F00_trace_5F00_292.pcapng

From what I can tell, there is no degrade in performance. From your ...292.pcapng trace I saw that there wass a lot of packet loss, but the traces themselves can't tell why the central didn't try to send more packets.

If you do have a certain amount of data that you need to send, you need to check the return value of your bt_fts_client_send_data(), which does indeed return a value:

/* Function to send data to the discovered FTS RX handle */
int bt_fts_client_send(const uint8_t *data, uint16_t len)
{
	if (!btconn || !fts_rx_handle) {
		printk("FTS RX handle not discovered or not connected\n");
		return -EIO;
	}

	int err = bt_gatt_write_without_response(btconn, fts_rx_handle, data, len, false);
	printk("bt_gatt_write_without_response len:%d 0x%04x: %d\n", len, fts_rx_handle, err);

	return err;
}

So if it returns 0, it means that the packet was successfully queued, and will be transmitted (when the link has capacity).

If it returns anything other than 0, it means that the packet was not queued, and will not be sent. In those cases, you need to look at the return value to see why these were not able to be queued.

I see from your 262 trace that it always sent 5 packets, so I suspect that you did change the central application after capturing this trace, before sending the central application, since the central application always sends 8 packets once every second.

Best regards,

Edvin

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

chiba — Thu, 28 May 2026 00:18:55 GMT

Hi,

> sending the large arrays containing 0x00's'

I believe this is the code on the central_52840dk side.

static void timeout_handler( struct k_timer *timer )
{
    static uint8_t data[155] ={0};
    static uint16_t count=0;
	
    if (fts_rx_handle) {
        printk("send sequence %d\n", count);
        data[0] = count++;
        bt_fts_client_send(data, sizeof(data));
        bt_fts_client_send(data, sizeof(data));
        bt_fts_client_send(data, sizeof(data));
        bt_fts_client_send(data, sizeof(data));
        bt_fts_client_send(data, sizeof(data));
        bt_fts_client_send(data, sizeof(data));
        bt_fts_client_send(data, sizeof(data));
        bt_fts_client_send(data, sizeof(data));
    } else {
        printk("Waiting for handle discovery...\n");
    }
}

```

This packet is received by either lock_5340dk_ncs260 or lock_5340dk_ncs292.

[central_52840dk]---ble_packet--->[lock_5340dk_ncs260]

[central_52840dk]---ble_packet--->[lock_5340dk_ncs292]

The sender is central_52840dk.
The receiver is either lock_5340dk_ncs260 or lock_5340dk_ncs292.
lock_5340dk_ncs292 has fewer MD packets.

It appears that lock_5340dk_ncs292 is not returning an ACK.

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

Edvin — Wed, 27 May 2026 13:59:49 GMT

I am struggling to find where you are sending the large arrays containing 0x00's. Perhaps you can help me locate them.

BR,

Edvin

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

chiba — Tue, 26 May 2026 09:24:53 GMT

Hi,

This project is based on a Matter sample project, but it concerns Bluetooth communication.
Matter is not running, and commissioning has not been performed.
Additionally, the project I provided is a modified version of the sample project provided by NCS, but the changes are minimal.
Please compare it with the original NCS sample code.

Project Details (Repeat)

central_52840dk
- Description: Central-side project for the nRF52840 DK.
- Base: ncs292/zephyr/samples/bluetooth/central
lock_5340dk_ncs260
- Description: Peripheral-side project for the nRF5340 DK (NCS 2.6.0).
- Base: ncs260/nrf/samples/matter/lock
lock_5340dk_ncs292
- Description: Peripheral-side project for the nRF5340 DK (NCS 2.9.2).
- Base: ncs292/nrf/samples/matter/lock

[central_52840dk]---ble_packet--->[lock_5340dk_ncs260]

[central_52840dk]---ble_packet--->[lock_5340dk_ncs290]

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

Edvin — Tue, 26 May 2026 09:03:00 GMT

Hello,

Yes. Samruddhi asked if I could have a look at your ticket.

Can you please clarify for me where you are sending the packets? The reason I ask is that most of us who are familiar with Bluetooth are not that familiar with the Matter stack, and since this is all written in C++, I need some help navigating. So can you please point me to where you are sending/queuing the packets, so that I can speed up the investigation to help you solve your issues quicker?

Best regards,

Edvin

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

chiba — Fri, 22 May 2026 00:18:51 GMT

Hi,

Both ncs2.6.0 and ncs2.9.2 are being operated on the same DK board. I have sent the project files, so could you please perform a packet capture on the Nordic side as well?

Here is the background regarding this issue:

We discovered that the throughput differs between ncs2.6.0 and ncs2.9.2 in a certain product, with ncs2.9.2 being slower. After capturing the BLE packets, we confirmed that the number of "More Data" packets differs between ncs2.6.0 and ncs2.9.2. This was the starting point of the DevZone topic.
Samruddhi Jadhav requested that we provide the project.
I have created and provided a test project for the DK board so that the issue can be reproduced on your end.

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

Edvin — Thu, 21 May 2026 12:06:55 GMT

Hello,

Is the ncs260 device and ncs292 device running on the same exact HW, and under similar conditions? The reason I ask is that I can't seem to see any difference in behavior, but there seems to be a bit more packet loss in the latter trace.

That said, it seems like both traces show a chunk of 158 byte long messages. Sometimes 6 packets, sometimes 5 and sometimes 4. Not an awful lot of data.

Do you mean that they should always be the same? E.g. 5 or 6 packets?

Where in your application (both in 2.6.0 and 2.9.2) do you transmit this data?

Regardless of packet loss, the data should go through, as long as it is queued with a return value of Success (0).

Can you confirm that this is the case? That you check the return value when you queue up the data for TX?

Best regards,

Edvin

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

chiba — Wed, 20 May 2026 02:17:50 GMT

Hi,

I am sending you the project, including the build directory.
You should be able to reproduce the issue by flashing this to the DK board.

I am also sending you the capture data from the NRF Sniffer

devzone.nordicsemi.com/.../8154.lock_5F00_5340dk_5F00_ncs260.zip

devzone.nordicsemi.com/.../2620.lock_5F00_5340dk_5F00_ncs292.zip

devzone.nordicsemi.com/.../7360.central_5F00_52840dk.zip

devzone.nordicsemi.com/.../ncs260.pcapng

devzone.nordicsemi.com/.../ncs292.pcapng

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

Edvin — Tue, 19 May 2026 12:42:08 GMT

Hello,

Samruddhi asked if I could have a look at your ticket.

Can you please try to capture a sniffer trace of the connection (both with v2.6.0 and with v2.9.2) using the nRF Sniffer for Bluetooth LE?

Also, which configuration should I use to reproduce what you are seeing? just the default prj.conf? I don't see any logs.

What MTU and Data length do you actually see in your connection? To see how it is negotiated, please see:
https://academy.nordicsemi.com/courses/bluetooth-low-energy-fundamentals/lessons/lesson-3-bluetooth-le-connections/topic/blefund-lesson-3-exercise-2/?version=v2.9.0-v2.7.0

Best regards,

Edvin

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

chiba — Mon, 18 May 2026 04:33:53 GMT

HI, I've created a project so you can reproduce it on a DK board.

Overview

Packets are periodically transmitted from the Central to the Peripheral.
Once both devices are powered on, they connect automatically and transmit packets at 1-second intervals.

Project Details

central_52840dk
- Description: Central-side project for the nRF52840 DK.
- Base: ncs292/zephyr/samples/bluetooth/central
lock_5340dk_ncs260
- Description: Peripheral-side project for the nRF5340 DK (NCS 2.6.0).
- Base: ncs260/nrf/samples/matter/lock
lock_5340dk_ncs292
- Description: Peripheral-side project for the nRF5340 DK (NCS 2.9.2).
- Base: ncs292/nrf/samples/matter/lock

devzone.nordicsemi.com/.../8055.lock_5F00_5340dk_5F00_ncs292.zip

devzone.nordicsemi.com/.../7624.lock_5F00_5340dk_5F00_ncs260.zip

devzone.nordicsemi.com/.../1856.central_5F00_52840dk.zip

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

Samruddhi Jadhav — Thu, 07 May 2026 08:45:37 GMT

Hello,

Can you please upload your whole application in v2.9.2?

Best Regards,

Samruddhi

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

Samruddhi Jadhav — Tue, 05 May 2026 14:55:36 GMT

Hi,

Thanks for providing the files. I am working on this with the team and will get back to you soon with an update. You can expect a response by this week.

Best Regards,

Samruddhi

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

chiba — Fri, 01 May 2026 00:39:12 GMT

Hi, thanks for your reply.
I’m attaching the prj.conf file.
Version 2.6.2 uses multi-image-build.
(Just to be safe, I’m also attaching the prj.conf from the sysbuild side.)
Neither the prj.conf for version 2.6.0 nor the one for version 2.9.2 specifies CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT.
I confirmed in autoconf.h that the default value is set to 7500.

- ncs v2.6.0
build\multiprotocol_rpmsg\zephyr\include\generated\autoconf.h(126): #define CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT 7500

- ncs v2.9.2
build\ipc_radio\zephyr\include\generated\zephyr\autoconf.h(138): #define CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT 7500devzone.nordicsemi.com/.../project_5F00_ncs260.zip devzone.nordicsemi.com/.../project_5F00_ncs292.zip

RE: BLE throughput differs between NCS v2.6.0 and v2.9.2.

Samruddhi Jadhav — Thu, 30 Apr 2026 13:20:41 GMT

Hi,

Yes, there are a few changes since sysbuild was introduced from 2.7.0. Please note that the configs of radio core are now in sysbuild\ipc_radio\prj.conf
Is it possible for you to share your sysbuild\ipc_radio\prj.conf file as well as the Kconfig.sysbuild file?

Best Regards,

Samruddhi