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

[chiba]

Hi,

BLE throughput differs between NCS v2.6.0 and v2.9.2.
v2.9.2 appears to have fewer MoreData packets.
(Both have CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT set to 7500)

In v2.9.2, I confirmed that setting `CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=15000` changes the number of more data packets.
Is there a difference in how `CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT` is handled between v2.6.0 and v2.9.2?

- Using the nrf5340
- Configured for multi-protocol communication with Matter (At the time of this test, commissioning had not been performed, and no Matter communication was taking place)

[Samruddhi Jadhav]

Hello,

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

Best Regards,

Samruddhi

[chiba]

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

8055.lock_5340dk_ncs292.zip

7624.lock_5340dk_ncs260.zip

1856.central_52840dk.zip

[Edvin]

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

[chiba]

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

8154.lock_5340dk_ncs260.zip

2620.lock_5340dk_ncs292.zip

7360.central_52840dk.zip

ncs260.pcapng

ncs292.pcapng

[Edvin]

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

[chiba]

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:

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

2. Samruddhi Jadhav requested that we provide the project.

3. I have created and provided a test project for the DK board so that the issue can be reproduced on your end.

[Edvin]

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

[chiba]

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]

[Edvin]

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

BR,

Edvin