Problem with data receive on nRF5340

RE: Problem with data receive on nRF5340

Einar Thorsrud — Wed, 13 Nov 2024 15:12:23 GMT

Hi,

Good, that confirms that scanning is the problem. Thanks for letting us know. As long as you don't need more devices, this also seems like a good fix in your case (and scanning withotu reason also waste energy). An alternative would be to look into the scannig paramters (window and interval), scanning for a smaller ammount of time, leaving more time for the connections.

RE: Problem with data receive on nRF5340

..... — Tue, 12 Nov 2024 16:32:01 GMT

Hi,

I found a problem.

The problem was with this code in discovery_complete function

	int err = bt_scan_start(BT_SCAN_TYPE_SCAN_ACTIVE);
	if (err) {
		LOG_ERR("Scanning failed to start (err %d)", err);
	} else {
		LOG_INF("Scanning started");
	}

Scanning to connect to additional devices caused a delay in transmission with already connected devices.

I modified discovery_complete function in this way:

static size_t x_device = 2; // maximum number of connected devices
static size_t connected_devices = 0;

static void discovery_complete(struct bt_gatt_dm *dm,
                               void *context)
{
    struct bt_nus_client *nus = context;
    LOG_INF("Service discovery completed");

    bt_gatt_dm_data_print(dm);

    bt_nus_handles_assign(dm, nus);
    bt_nus_subscribe_receive(nus);

    bt_gatt_dm_data_release(dm);

    connected_devices++;

    if (connected_devices < x_device) {
        int err = bt_scan_start(BT_SCAN_TYPE_SCAN_ACTIVE);
        if (err) {
            LOG_ERR("Scanning failed to start (err %d)", err);
        } else {
            LOG_INF("Scanning started");
        }
    } else {
        LOG_INF("Reached the maximum number of connected devices: %d", x_device);
    }

    // Send a message to the new NUS server informing it of its ID in this mini-network
    size_t num_nus_conns = bt_conn_ctx_count(&conns_ctx_lib);
    size_t nus_index = 99;

    for (size_t i = 0; i < num_nus_conns; i++) {
        const struct bt_conn_ctx *ctx = bt_conn_ctx_get_by_id(&conns_ctx_lib, i);

        if (ctx) {
            if (ctx->data == nus) {
                nus_index = i;
                char message[3];
                sprintf(message, "%d", nus_index);
                message[2] = '\r';
                int length = 3;

                int err = bt_nus_client_send(nus, message, length);
                if (err) {
                    LOG_WRN("Failed to send data over BLE connection (err %d)", err);
                } else {
                    LOG_INF("Sent to server %d: %s", nus_index, message);
                }

                bt_conn_ctx_release(&conns_ctx_lib, (void *)ctx->data);
                break;
            } else {
                bt_conn_ctx_release(&conns_ctx_lib, (void *)ctx->data);
            }
        }
    }
}

When the central device is connected to a smaller number of devices than defined in the x_device variable, it works as before (there is a delay in every fifth frame), but when it is connected to the maximum number of devices (defined in the x_device variable), it no longer scans, and therefore there is no delay.

RE: Problem with data receive on nRF5340

Einar Thorsrud — Tue, 12 Nov 2024 11:39:22 GMT

Hi,

I am not sure I understood this experiment. The unofficial Multi NUS sample is a central, and it needs BT_CONN_CTX_DEF etc to keep track of the multiple connections. And ble_peripheral_uart is a peripheral (and single link before potential modifications).

Could there be other things that cause problems with the scheduling? Which scan parameters are you using? The controller needs to fit both scanning and connections in, so an alternative could be to reduce the scan window and scan frequency and see if that changes aything. That can be done by populating a bt_le_scan_param struct that you refer to in the bt_scan_init_param struct you pass to scan_init() on the central side (see this post on that).

RE: Problem with data receive on nRF5340

..... — Fri, 08 Nov 2024 15:48:40 GMT

I was searching for problematic code in Multi NUS, so I copied code fragments from Multi NUS project to ble_peripheral_uart sample (which were modified as I described above). So I add BT_CONN_CTX_DEF(conns, CONFIG_BT_MAX_CONN, sizeof(struct bt_nus_client)); line to ble_peripheral_uart and I replaced uart_init, gatt_discover, connected, disconnected functions in ble_peripheral_uart by their versions from Multi NUS project.

In this point transmission was OK. But when I replaced discovery_complete function, the ble_peripheral_uart project was working like multi NUS, so it was possible to connect to multiple devices, but there was also a problem with transmission.

The discovery_complete function (from Multi NUS file) gives the ability to connect multiple devices, but it also causes a delay of every fifth frame in the transmission.

Is it possible to modify this function to eliminate the transmission problem and retain the ability to connect with multiple devices?

PS: I don't need to connect with 20 devices, I only need to be able to connect with (up to) 3 devices in the same time (with data transmission in both directions).

RE: Problem with data receive on nRF5340

..... — Fri, 08 Nov 2024 11:00:39 GMT

I changed it in prj.conf file.

I also tried it on nRF52840 and it is in build (I tried it with different values but problem still occurs).

RE: Problem with data receive on nRF5340

Einar Thorsrud — Wed, 06 Nov 2024 14:55:16 GMT

Where did you make this change? This config is relevant on the controller side, so the network core application (hci_ipc/hci_rpmsg depending on SDK version).

RE: Problem with data receive on nRF5340

..... — Wed, 06 Nov 2024 14:38:45 GMT

Hi,

You previously suggested me to use CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT , and I wrote then that result was the same.

Now I noticed that this is not defined in build.

I also tried with:

CONFIG_BT_LL_SOFTDEVICE=y
CONFIG_BT_CTLR=y

But it isn't work

Is there any configuration that needs to be added to make it work?

RE: Problem with data receive on nRF5340

Einar Thorsrud — Tue, 05 Nov 2024 15:10:10 GMT

Hi,

The last trace is short and encrypted and does not show much, but looking at Multi_NUS_Wireshark__2.pcapng I notice that every 5 packets are delayed (looking at the delta) and then the subsequent packet has the more data field set, as there is more buffered data. So this points to scheduling not being ideal for your use case. iMost likely what you want is short "slots" for each connection so that you can exchagne packets with little delay? Refering to Advanced Central connection timing, this means that you need to configure a short event length (but long enough to fit the longest packet you intend to send). This can be configured with CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT.

RE: Problem with data receive on nRF5340

..... — Thu, 31 Oct 2024 12:47:40 GMT

Hi,

Below are wireshark files.

Multi NUS:

devzone.nordicsemi.com/.../Multi_5F00_NUS_5F00_Wireshark.pcapng

devzone.nordicsemi.com/.../Multi_5F00_NUS_5F00_Wireshark_5F005F00_2.pcapng

central_uart

devzone.nordicsemi.com/.../central_5F00_uart_5F00_Wireshark.pcapng

In Central_uart case you don't see incoming packets (but transmission between devices is OK).

RE: Problem with data receive on nRF5340

Einar Thorsrud — Wed, 30 Oct 2024 08:34:19 GMT

Hi,

Thank you for the information. I was not clear enoguh, but what I think we need is to look at the traffic on air. Can you make a sniffer trace of both cases so that we can compare? You can use the nRF sniffer for that. I hope we will understand more from that.

PS: The Multi NUS project you refer to is not an official sample, and while can be usefull to demonstrate a central with multiple concurrent connections, you will need to adapt it to your needs.

RE: Problem with data receive on nRF5340

..... — Tue, 29 Oct 2024 18:03:27 GMT

Hi,

I'm not sure that this is what you want, but below are screenshoots from j-link with connection parameters. I also send configuration files in one of previous posts.

from device with modified ble_central_uart program:

from device with modified Multi NUS program:

Below are logs from receiving device. One is from modified ble_central_uart program (and it is OK), second one is from modified Multi NUS program (and it is NOT OK).

log from modified ble_central_uart program:

devzone.nordicsemi.com/.../COM23_5F00_2024_5F00_10_5F00_29.17.57.18.478.txt

log from modified Multi NUS program

devzone.nordicsemi.com/.../COM11_5F00_2024_5F00_10_5F00_29.17.52.34.361.txt

If you analize this logs with python script (that I send before) you will see the difference and what is wrong with Multi NUS app.
                                            [ Remember to change Path in script and log name ]

Problem with Multi NUS: every fifth packet has a bigger timestamp than it should have - (timestamp is in data packet and is from peripheral device, so it looks like it takes longer for the peripheral device to send every fifth data packet, but when peripheral device is sending data to ble_central_uart or to the phone everything is OK).

That's how it look like after script analysis (this is the analysis of the above logs):

difference between timestamps in subsequent data packets:

ble_central_uart (left image)                                      Multi NUS (right image)


summary:

ble_central_uart

Multi NUS

So as you see every fifth pachet has much bigger timestamp and average difference between timestamps of subsequent data packets in ble_central_uart case is about 8ms but in Multi NUS case is about 12ms (in the ideal case it should be equal to 8ms). It is worth mentioning that ble_central_uart and Multi NUS are only receiving data and both were connected to the same device that sends data (of course not in the same time).

So there is something wrong with Multi NUS sample.

RE: Problem with data receive on nRF5340

Einar Thorsrud — Mon, 28 Oct 2024 13:12:04 GMT

Hi,

I am not able to fully understand what is going on there. What are the actuall connection parameters that are used on the connections? Can you make a sniffer trace that shows everyting starting with the connection both with a phone as central and the nRF as central (as that behaves as you expect)? (you may only be able to sniff one of the connections if you use nRF Sniffer, but focusing on one of the connections should be OK as at least then we can see what is happening on the link that may cause the delays you are seeing).

RE: Problem with data receive on nRF5340

..... — Fri, 25 Oct 2024 15:07:37 GMT

I tested communication on porgram based on "ble_central_uart" sample (instread of program based on "Multi NUS" sample) and it works properly. [In this case i tested it with one connected device (Peripheral UART device) - in Central UART case it was OK, but in Multi NUS case there was the previously described error]

Central UART sample was modified in the same way as Multi NUS sample.

So problem is in Mutli NUS.

Can you help me to identify this problem in Multi NUS or help me to modify the Central UART sample so that it can receive data (and send data) from several devices connected to it simultaneously ?

RE: Problem with data receive on nRF5340

..... — Fri, 25 Oct 2024 09:01:50 GMT

Hi,

I add this line [CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=2500] (I tried also with different parameters: 10, 2500 and 1000000) but result is the same.
I tested it in 2 cases:
- when I added this line only to Multi NUS
- and when I added this line to both Multi NUS and Peripheral devices
and nothing changed.

Below are my config files:

Peripheral UART:
prj.conf

#
# Copyright (c) 2018 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

# Enable the UART driver
CONFIG_UART_ASYNC_API=y
CONFIG_NRFX_UARTE0=y
CONFIG_SERIAL=y

CONFIG_GPIO=y

# Make sure printk is printing to the UART console
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y

CONFIG_HEAP_MEM_POOL_SIZE=2048

CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="Nordic_UART_Service"
CONFIG_BT_MAX_CONN=1
CONFIG_BT_MAX_PAIRED=1

# Enable the NUS service
CONFIG_BT_NUS=y

# Enable bonding
CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y

# Enable DK LED and Buttons library
CONFIG_DK_LIBRARY=y

# This example requires more stack
CONFIG_MAIN_STACK_SIZE=1152
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

# Config logger
CONFIG_LOG=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_UART=n
CONFIG_LOG_PRINTK=n

CONFIG_ASSERT=y


CONFIG_NRFX_TIMER1=y
CONFIG_NRFX_TIMER2=y

CONFIG_PRINTK=y

CONFIG_PINCTRL=y



CONFIG_FPU=y


CONFIG_BT_GATT_CLIENT=y


CONFIG_BT_PERIPHERAL_PREF_MIN_INT=6
CONFIG_BT_PERIPHERAL_PREF_MAX_INT=6
CONFIG_BT_PERIPHERAL_PREF_LATENCY=0

CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=y

CONFIG_BT_USER_PHY_UPDATE=y


CONFIG_BT_USER_DATA_LEN_UPDATE=y    # enabling the data length extension

prj_minimal.conf

#
# Copyright (c) 2021 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

# Enable the UART driver
CONFIG_UART_ASYNC_API=y
CONFIG_NRFX_UARTE0=y
CONFIG_SERIAL=y

CONFIG_HEAP_MEM_POOL_SIZE=2048

CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="Nordic_UART_Service"
CONFIG_BT_DEVICE_APPEARANCE=833
CONFIG_BT_MAX_CONN=1
CONFIG_BT_MAX_PAIRED=1

# Enable the NUS service
CONFIG_BT_NUS=y

# Enable bonding
CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y

# Enable DK LED and Buttons library
CONFIG_DK_LIBRARY=y

# Drivers and peripherals
CONFIG_I2C=n
CONFIG_WATCHDOG=n
CONFIG_SPI=n
CONFIG_GPIO=n

# Power management

# Interrupts
CONFIG_DYNAMIC_INTERRUPTS=n
CONFIG_IRQ_OFFLOAD=n

# Memory protection
CONFIG_THREAD_STACK_INFO=n
CONFIG_THREAD_CUSTOM_DATA=n
# CONFIG_FPU=n

# Boot
CONFIG_BOOT_BANNER=n
CONFIG_BOOT_DELAY=0

# Console
CONFIG_CONSOLE=n
CONFIG_UART_CONSOLE=n
CONFIG_STDOUT_CONSOLE=n
CONFIG_PRINTK=n
CONFIG_EARLY_CONSOLE=n

# Build
CONFIG_SIZE_OPTIMIZATIONS=y

# ARM
CONFIG_ARM_MPU=n

# In order to correctly tune the stack sizes for the threads the following
# Configurations can enabled to print the current use:
#CONFIG_THREAD_NAME=y
#CONFIG_THREAD_ANALYZER=y
#CONFIG_THREAD_ANALYZER_AUTO=y
#CONFIG_THREAD_ANALYZER_RUN_UNLOCKED=y
#CONFIG_THREAD_ANALYZER_USE_PRINTK=y
#CONFIG_CONSOLE=y
#CONFIG_UART_CONSOLE=y
#CONFIG_SERIAL=y
#CONFIG_PRINTK=y

# Example output of thread analyzer
#SDC RX              : unused 800 usage 224 / 1024 (21 %)
#BT ECC              : unused 216 usage 888 / 1104 (80 %)
#BT RX               : unused 1736 usage 464 / 2200 (21 %)
#BT TX               : unused 1008 usage 528 / 1536 (34 %)
#ble_write_thread_id : unused 688 usage 336 / 1024 (32 %)
#sysworkq            : unused 1912 usage 136 / 2048 (6 %)
#MPSL signal         : unused 928 usage 96 / 1024 (9 %)
#idle 00             : unused 224 usage 96 / 320 (30 %)
#main                : unused 568 usage 456 / 1024 (44 %)
CONFIG_BT_RX_STACK_SIZE=1024
CONFIG_BT_HCI_TX_STACK_SIZE_WITH_PROMPT=y
CONFIG_BT_HCI_TX_STACK_SIZE=640
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=1536
CONFIG_MPSL_WORK_STACK_SIZE=256
CONFIG_MAIN_STACK_SIZE=864
CONFIG_IDLE_STACK_SIZE=128
CONFIG_ISR_STACK_SIZE=1024
CONFIG_BT_NUS_THREAD_STACK_SIZE=512

# Disable features not needed
CONFIG_TIMESLICING=n
CONFIG_MINIMAL_LIBC_MALLOC=n
CONFIG_LOG=n
CONFIG_ASSERT=n

# Disable Bluetooth features not needed
CONFIG_BT_DEBUG_NONE=y
CONFIG_BT_ASSERT=n
CONFIG_BT_DATA_LEN_UPDATE=n
CONFIG_BT_PHY_UPDATE=n
CONFIG_BT_GATT_CACHING=n
CONFIG_BT_GATT_SERVICE_CHANGED=n
CONFIG_BT_GAP_PERIPHERAL_PREF_PARAMS=n
CONFIG_BT_SETTINGS_CCC_LAZY_LOADING=y
CONFIG_BT_HCI_VS_EXT=n

# Disable Bluetooth controller features not needed
CONFIG_BT_CTLR_PRIVACY=n
CONFIG_BT_CTLR_PHY_2M=n

# Reduce Bluetooth buffers
CONFIG_BT_BUF_EVT_DISCARDABLE_COUNT=1
CONFIG_BT_BUF_EVT_DISCARDABLE_SIZE=43
CONFIG_BT_BUF_EVT_RX_COUNT=2

CONFIG_BT_CONN_TX_MAX=2
CONFIG_BT_L2CAP_TX_BUF_COUNT=2
CONFIG_BT_BUF_ACL_TX_COUNT=3
CONFIG_BT_BUF_ACL_TX_SIZE=27


CONFIG_HW_ID_LIBRARY_SOURCE_DEVICE_ID=y



CONFIG_LOG=y

CONFIG_NRFX_TIMER1=y
CONFIG_NRFX_TIMER2=y

CONFIG_PRINTK=y

CONFIG_PINCTRL=y



CONFIG_FPU=y


CONFIG_BT_GATT_CLIENT=y


CONFIG_BT_PERIPHERAL_PREF_MIN_INT=6
CONFIG_BT_PERIPHERAL_PREF_MAX_INT=6
CONFIG_BT_PERIPHERAL_PREF_LATENCY=0

CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=y

CONFIG_BT_USER_PHY_UPDATE=y


CONFIG_BT_USER_DATA_LEN_UPDATE=y    # enabling the data length extension

prj_cdc.conf

#
# Copyright (c) 2021 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

# Enable the UART driver
CONFIG_UART_LINE_CTRL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_BT_NUS_UART_ASYNC_ADAPTER=y
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_REMOTE_WAKEUP=n
CONFIG_USB_CDC_ACM=y
CONFIG_USB_CDC_ACM_LOG_LEVEL_OFF=y

# Disable the UARTE0 enabled in default project configuration
CONFIG_NRFX_UARTE0=n
CONFIG_UART_NRFX=n



CONFIG_LOG=y

CONFIG_NRFX_TIMER1=y
CONFIG_NRFX_TIMER2=y

CONFIG_PRINTK=y

CONFIG_PINCTRL=y



CONFIG_FPU=y


CONFIG_BT_GATT_CLIENT=y


CONFIG_BT_PERIPHERAL_PREF_MIN_INT=6
CONFIG_BT_PERIPHERAL_PREF_MAX_INT=6
CONFIG_BT_PERIPHERAL_PREF_LATENCY=0

CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=y

CONFIG_BT_USER_PHY_UPDATE=y


CONFIG_BT_USER_DATA_LEN_UPDATE=y    # enabling the data length extension

Multi NUS:
prj.conf

#
# Copyright (c) 2018 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-BSD-5-Clause-Nordic
#

# Enable the UART driver
CONFIG_UART_ASYNC_API=y
CONFIG_NRFX_UARTE0=y
CONFIG_SERIAL=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y

# Enable the BLE stack with GATT Client configuration
CONFIG_BT=y
CONFIG_BT_CENTRAL=y
CONFIG_BT_SMP=y
CONFIG_BT_GATT_CLIENT=y
CONFIG_BT_MAX_CONN=20
CONFIG_BT_MAX_PAIRED=20
CONFIG_BT_CONN_CTX=y

# Enable the BLE modules from NCS
CONFIG_BT_NUS_CLIENT=y
CONFIG_BT_SCAN=y
CONFIG_BT_SCAN_FILTER_ENABLE=y
CONFIG_BT_SCAN_UUID_CNT=1
CONFIG_BT_GATT_DM=y
CONFIG_HEAP_MEM_POOL_SIZE=2048

# This example requires more workqueue stack
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

# Enable bonding
CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y

# Config logger
CONFIG_LOG=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_UART=n
CONFIG_LOG_PRINTK=y

CONFIG_ASSERT=y


CONFIG_FPU=y


CONFIG_BT_PERIPHERAL_PREF_MIN_INT=6
CONFIG_BT_PERIPHERAL_PREF_MAX_INT=6
CONFIG_BT_PERIPHERAL_PREF_LATENCY=0

CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=y

CONFIG_BT_USER_PHY_UPDATE=y


CONFIG_BT_USER_DATA_LEN_UPDATE=y    # enabling the data length extension

RE: Problem with data receive on nRF5340

Einar Thorsrud — Thu, 24 Oct 2024 12:56:22 GMT

Hi,

As this works with a phone as central but not the nRF I suspect there may be somethign scheduling related (assuming you test with the same ammount of peripherals). What are the connection parmaeters? Does it help if you set a shorter default event length with CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=2500 (or similar)?