BLE Throughput and Timing Issues

RE: BLE Throughput and Timing Issues

Kyrre Aalerud — Thu, 08 Aug 2024 14:14:34 GMT

This was actually very interesting! I can see an asymmetric link here!
[00:00:09.012,756] <inf> Lesson3_Exercise2: Data length updated. Length 27/27 bytes, time 2120/328 us

Somehow I can't reproduce it but I really want to for maximizing TX time.

RE: BLE Throughput and Timing Issues

Susheel Nuguru — Mon, 09 Oct 2023 06:31:16 GMT

I retried your please_work_this_time.zip, removed the build folder and prestine built it (clean build) with a configuration of the merge flash to both APP and NET core. The usual way and it still works at my end

Not sure why you see the difference but atleast you have a working setup for now. So yes, please mark your previous reply as verified so other forum members can see the alternative build configuration when needed.

RE: BLE Throughput and Timing Issues

blue_dew — Fri, 06 Oct 2023 17:43:20 GMT

Another update! This one is great news. I get the expected behavior from the nRF5340 when I flash the application core and THEN flash the net core with the hci_rpmsg image manually. I did this in order to try and debug the hci_rpmsg tx_thread and I realized that we get the expected behavior!!! YAY! Here are the attached screenshots to show the actual/expected behavior:

^ slave, nRF5340 requesting the correct TX data length of 251 octets.

^ the application core updating the ble host connection object with the negotiated 251 LL data length!!!

Because flashing the app then net core images one at a time fixed the issue I am inclined to believe this is a build/linking issue. This is something I can work around for now so I will mark this as resolved if you would like.

---
Tools Used:

tool chain and SDK are both v2.4.1
Windows 11, Version 10.0.22621 Build 22621
nRF5340-DK, PCA10095
nRF Connect for VS Code v2023.9.336
Pixel 7 Pro, android version 13, build #TQ3A.230901.001.C2
Entire Project zip w/ build: devzone.nordicsemi.com/.../please_5F00_work_5F00_this_5F00_time.zip

RE: BLE Throughput and Timing Issues

blue_dew — Fri, 06 Oct 2023 05:05:23 GMT

To reiterate, the issue I'm observing is within the zephyr hci code because the call to create the hci command is correct and the created net buf is correct but the network core is not honoring the parameters passed. I see tons of messages dropped when I enable CONFIG_BT_HCI_CORE_LOG_LEVEL_DBG. This issue does not happen for me when I use the nRF52840 even though my code and configs are the exact same. It is just a problem going from the application core to the network core on the nRF5340. Could this be a memory issue? Attached are the info and dbg logs from the hci on the application core.

[00:00:00.263,366] <dbg> bt_hci_core: bt_hci_driver_register: Registered RPMsg
*** Booting Zephyr OS build v3.3.99-ncs1-1 ***
--- 98 messages dropped ---
[00:00:00.301,849] <inf> Lesson3_Exercise2: Bluetooth initialized
--- 306 messages dropped ---
[00:00:00.304,138] <dbg> bt_hci_core: send_cmd: calling net_buf_get
[00:00:00.304,138] <dbg> bt_hci_core: send_cmd: calling sem_take_wait
[00:00:00.304,168] <dbg> bt_hci_core: send_cmd: Sending command 0x2009 (buf 0x200105fc) to driver
--- 3 messages dropped ---
[00:00:00.304,534] <dbg> bt_hci_core: bt_recv: buf 0x200105fc len 6
[00:00:00.304,565] <dbg> bt_hci_core: hci_cmd_complete: opcode 0x2009
[00:00:00.304,595] <dbg> bt_hci_core: hci_cmd_done: opcode 0x2009 status 0x00 buf 0x200105fc
[00:00:00.304,656] <dbg> bt_hci_core: bt_hci_cmd_send_sync: rsp 0x200105fc opcode 0x2009 len 1
[00:00:00.304,687] <dbg> bt_hci_core: bt_hci_cmd_create: opcode 0x200a param_len 1
[00:00:00.304,718] <dbg> bt_hci_core: bt_hci_cmd_create: buf 0x200105fc
[00:00:00.304,748] <dbg> bt_hci_core: bt_hci_cmd_send_sync: buf 0x200105fc opcode 0x200a len 4
[00:00:00.304,779] <dbg> bt_hci_core: process_events: count 2
[00:00:00.304,779] <dbg> bt_hci_core: process_events: ev->state 4
[00:00:00.304,809] <dbg> bt_hci_core: send_cmd: calling net_buf_get
[00:00:00.304,840] <dbg> bt_hci_core: send_cmd: calling sem_take_wait
[00:00:00.304,840] <dbg> bt_hci_core: send_cmd: Sending command 0x200a (buf 0x200105fc) to driver
[00:00:00.304,870] <dbg> bt_hci_core: bt_send: buf 0x200105fc len 4 type 0
[00:00:00.304,901] <dbg> bt_hci_core: process_events: ev->state 0
[00:00:00.304,931] <dbg> bt_hci_core: hci_tx_thread: Calling k_poll with 2 events
[00:00:00.305,358] <dbg> bt_hci_core: bt_recv: buf 0x200105fc len 6
[00:00:00.305,389] <dbg> bt_hci_core: hci_cmd_complete: opcode 0x200a
[00:00:00.305,419] <dbg> bt_hci_core: hci_cmd_done: opcode 0x200a status 0x00 buf 0x200105fc
[00:00:00.305,480] <dbg> bt_hci_core: bt_hci_cmd_send_sync: rsp 0x200105fc opcode 0x200a len 1
[00:00:00.305,511] <inf> Lesson3_Exercise2: Advertising successfully started
[00:00:00.335,296] <dbg> bt_hci_core: bt_recv: buf 0x2000eab0 len 68
[00:00:00.335,327] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
[00:00:00.335,327] <dbg> bt_hci_core: rx_work_handler: buf 0x2000eab0 type 1 len 68
[00:00:00.335,357] <dbg> bt_hci_core: hci_event: event 0x3e
[00:00:00.335,388] <dbg> bt_hci_core: hci_le_meta_event: subevent 0x08
[00:00:00.335,388] <dbg> bt_ecc: bt_hci_evt_le_pkey_complete: status: 0x00
[00:00:08.565,673] <dbg> bt_hci_core: bt_recv: buf 0x2000eab0 len 33
--- 30 messages dropped ---
[00:00:08.567,047] <dbg> bt_hci_core: send_cmd: calling sem_take_wait
[00:00:08.567,108] <dbg> bt_hci_core: send_cmd: Sending command 0x2022 (buf 0x2001061c) to driver
[00:00:08.567,108] <dbg> bt_hci_core: bt_send: buf 0x2001061c len 9 type 0
[00:00:08.567,169] <dbg> bt_hci_core: process_events: ev->state 0
[00:00:08.567,169] <dbg> bt_hci_core: process_events: ev->state 0
[00:00:08.567,199] <dbg> bt_hci_core: hci_tx_thread: Calling k_poll with 3 events
[00:00:08.567,443] <dbg> bt_hci_core: bt_recv: buf 0x2001061c len 8
[00:00:08.567,474] <dbg> bt_hci_core: hci_cmd_complete: opcode 0x2022
[00:00:08.567,504] <dbg> bt_hci_core: hci_cmd_done: opcode 0x2022 status 0x00 buf 0x2001061c
[00:00:08.567,535] <dbg> bt_hci_core: bt_hci_cmd_send_sync: rsp 0x2001061c opcode 0x2022 len 3
[00:00:08.567,596] <dbg> bt_hci_core: bt_hci_cmd_create: opcode 0x2016 param_len 2
[00:00:08.567,626] <dbg> bt_hci_core: bt_hci_cmd_create: buf 0x200105fc
[00:00:08.567,657] <dbg> bt_hci_core: bt_hci_cmd_send_sync: buf 0x200105fc opcode 0x2016 len 5
[00:00:08.567,687] <dbg> bt_hci_core: process_events: count 3
[00:00:08.567,718] <dbg> bt_hci_core: process_events: ev->state 4
[00:00:08.567,718] <dbg> bt_hci_core: send_cmd: calling net_buf_get
[00:00:08.567,749] <dbg> bt_hci_core: send_cmd: calling sem_take_wait
[00:00:08.567,779] <dbg> bt_hci_core: send_cmd: Sending command 0x2016 (buf 0x200105fc) to driver
[00:00:08.567,810] <dbg> bt_hci_core: bt_send: buf 0x200105fc len 5 type 0
[00:00:08.567,840] <dbg> bt_hci_core: process_events: ev->state 0
[00:00:08.567,871] <dbg> bt_hci_core: process_events: ev->state 4
[00:00:08.567,901] <dbg> bt_hci_core: bt_send: buf 0x20011d7c len 11 type 2
[00:00:08.567,962] <dbg> bt_hci_core: hci_tx_thread: Calling k_poll with 3 events
[00:00:08.568,237] <dbg> bt_hci_core: bt_recv: buf 0x200105fc len 6
[00:00:08.568,267] <dbg> bt_hci_core: hci_cmd_status: opcode 0x2016
[00:00:08.568,298] <dbg> bt_hci_core: hci_cmd_done: opcode 0x2016 status 0x00 buf 0x200105fc
[00:00:08.568,328] <dbg> bt_hci_core: bt_hci_cmd_send_sync: rsp 0x200105fc opcode 0x2016 len 0
[00:00:08.652,557] <dbg> bt_hci_core: bt_recv: buf 0x20010314 len 7
--- 3 messages dropped ---
[00:00:08.742,095] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
[00:00:08.742,095] <dbg> bt_hci_core: rx_work_handler: buf 0x2000fff0 type 3 len 11
[00:00:08.742,126] <dbg> bt_hci_core: hci_acl: buf 0x2000fff0
[00:00:08.742,126] <dbg> bt_hci_core: hci_acl: handle 15 len 7 flags 2
[00:00:08.742,187] <inf> Lesson3_Exercise2: MTU exchange successful
[00:00:08.742,218] <inf> Lesson3_Exercise2: New MTU: 244 bytes
[00:00:08.742,218] <dbg> bt_hci_core: bt_hci_host_num_completed_packets: Reporting completed packet for handle 15
[00:00:08.742,248] <dbg> bt_hci_core: bt_hci_cmd_create: opcode 0x0c35 param_len 5
[00:00:08.742,248] <dbg> bt_hci_core: bt_hci_cmd_create: buf 0x200105fc
[00:00:08.742,279] <dbg> bt_hci_core: bt_hci_cmd_send: opcode 0x0c35 len 8
[00:00:08.742,279] <dbg> bt_hci_core: bt_send: buf 0x200105fc len 8 type 0
[00:00:08.787,292] <dbg> bt_hci_core: bt_recv: buf 0x2000fff0 len 15
[00:00:08.787,322] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
[00:00:08.787,322] <dbg> bt_hci_core: rx_work_handler: buf 0x2000fff0 type 3 len 15
[00:00:08.787,353] <dbg> bt_hci_core: hci_acl: buf 0x2000fff0
[00:00:08.787,353] <dbg> bt_hci_core: hci_acl: handle 15 len 11 flags 2
[00:00:08.787,506] <dbg> bt_hci_core: bt_hci_host_num_completed_packets: Reporting completed packet for handle 15
[00:00:08.787,536] <dbg> bt_hci_core: bt_hci_cmd_create: opcode 0x0c35 param_len 5
[00:00:08.787,536] <dbg> bt_hci_core: bt_hci_cmd_create: buf 0x200105fc
[00:00:08.787,567] <dbg> bt_hci_core: bt_hci_cmd_send: opcode 0x0c35 len 8
[00:00:08.787,567] <dbg> bt_hci_core: bt_send: buf 0x200105fc len 8 type 0
[00:00:08.787,628] <dbg> bt_hci_core: process_events: count 3
[00:00:08.787,658] <dbg> bt_hci_core: process_events: ev->state 0
[00:00:08.787,658] <dbg> bt_hci_core: process_events: ev->state 0
[00:00:08.787,689] <dbg> bt_hci_core: process_events: ev->state 4
[00:00:08.787,719] <dbg> bt_hci_core: bt_send: buf 0x20011d7c len 22 type 2
[00:00:08.787,780] <dbg> bt_hci_core: hci_tx_thread: Calling k_poll with 3 events
[00:00:08.922,454] <dbg> bt_hci_core: bt_recv: buf 0x20010314 len 7
[00:00:08.922,454] <dbg> bt_hci_core: hci_num_completed_packets: num_handles 1
[00:00:08.922,485] <dbg> bt_hci_core: hci_num_completed_packets: handle 15 count 1
--- 3 messages dropped ---
[00:00:08.922,668] <dbg> bt_hci_core: hci_event: event 0x3e
[00:00:08.922,668] <dbg> bt_hci_core: hci_le_meta_event: subevent 0x04
[00:00:08.967,102] <dbg> bt_hci_core: bt_recv: buf 0x2000fff0 len 15
[00:00:08.967,132] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
[00:00:08.967,132] <dbg> bt_hci_core: rx_work_handler: buf 0x2000fff0 type 3 len 15
[00:00:08.967,163] <dbg> bt_hci_core: hci_acl: buf 0x2000fff0
--- 13 messages dropped ---
[00:00:09.012,664] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
[00:00:09.012,664] <dbg> bt_hci_core: rx_work_handler: buf 0x2000eab0 type 1 len 13
[00:00:09.012,695] <dbg> bt_hci_core: hci_event: event 0x3e
[00:00:09.012,695] <dbg> bt_hci_core: hci_le_meta_event: subevent 0x07
[00:00:09.012,725] <dbg> bt_hci_core: le_data_len_change: max. tx: 27 (2120us), max. rx: 27 (328us)
[00:00:09.012,756] <inf> Lesson3_Exercise2: Data length updated. Length 27/27 bytes, time 2120/328 us
[00:00:09.057,434] <dbg> bt_hci_core: bt_recv: buf 0x20010314 len 7
[00:00:09.057,434] <dbg> bt_hci_core: hci_num_completed_packets: num_handles 1
[00:00:09.057,464] <dbg> bt_hci_core: hci_num_completed_packets: handle 15 count 1
[00:00:09.057,556] <dbg> bt_hci_core: bt_recv: buf 0x2000fff0 len 15
[00:00:09.057,586] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
[00:00:09.057,617] <dbg> bt_hci_core: rx_work_handler: buf 0x2000fff0 type 3 len 15
[00:00:09.057,647] <dbg> bt_hci_core: hci_acl: buf 0x2000fff0
[00:00:09.057,647] <dbg> bt_hci_core: hci_acl: handle 15 len 11 flags 2
[00:00:09.057,769] <dbg> bt_hci_core: bt_hci_host_num_completed_packets: Reporting completed packet for handle 15
[00:00:09.057,800] <dbg> bt_hci_core: bt_hci_cmd_create: opcode 0x0c35 param_len 5
[00:00:09.057,800] <dbg> bt_hci_core: bt_hci_cmd_create: buf 0x200105fc
[00:00:09.057,830] <dbg> bt_hci_core: bt_hci_cmd_send: opcode 0x0c35 len 8
--- 7 messages dropped ---
[00:00:09.147,186] <dbg> bt_hci_core: bt_recv: buf 0x2000eab0 len 12
[00:00:09.147,247] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
[00:00:09.147,247] <dbg> bt_hci_core: rx_work_handler: buf 0x2000eab0 type 1 len 12
--- 2 messages dropped ---
[00:00:09.200,286] <dbg> bt_hci_core: bt_send: buf 0x200105fc len 8 type 0
--- 14 messages dropped ---
[00:00:09.200,347] <dbg> bt_hci_core: process_events: count 3
--- 16 messages dropped ---
[00:00:09.230,072] <dbg> bt_hci_core: bt_hci_cmd_send: opcode 0x0c35 len 8
--- 18 messages dropped ---
[00:00:09.245,300] <dbg> bt_hci_core: bt_hci_cmd_send: opcode 0x0c35 len 8
[00:00:09.245,300] <dbg> bt_hci_core: bt_send: buf 0x200105fc len 8 type 0
--- 24 messages dropped ---
[00:00:09.260,498] <dbg> bt_hci_core: hci_tx_thread: Calling k_poll with 3 events
--- 18 messages dropped ---
[00:00:09.275,238] <dbg> bt_hci_core: bt_hci_cmd_send: opcode 0x0c35 len 8
--- 18 messages dropped ---
[00:00:09.290,222] <dbg> bt_hci_core: bt_hci_cmd_send: opcode 0x0c35 len 8
[00:00:09.290,252] <dbg> bt_hci_core: bt_send: buf 0x200105fc len 8 type 0
--- 17 messages dropped ---
[00:00:09.305,206] <dbg> bt_hci_core: bt_hci_cmd_send: opcode 0x0c35 len 8
--- 19 messages dropped ---
[00:00:09.320,251] <dbg> bt_hci_core: bt_send: buf 0x200105fc len 8 type 0
--- 4 messages dropped ---
[00:00:09.320,404] <dbg> bt_hci_core: bt_send: buf 0x20011d7c len 13 type 2
--- 18 messages dropped ---
[00:00:09.335,418] <dbg> bt_hci_core: bt_send: buf 0x2001093c len 31 type 2
[00:00:09.335,479] <dbg> bt_hci_core: bt_send: buf 0x20011d7c len 25 type 2
--- 15 messages dropped ---
[00:00:09.357,727] <dbg> bt_hci_core: bt_hci_cmd_send: opcode 0x0c35 len 8
--- 4 messages dropped ---
[00:00:09.357,849] <dbg> bt_hci_core: process_events: ev->state 4
[00:00:09.357,879] <dbg> bt_hci_core: bt_send: buf 0x20011d7c len 13 type 2
[00:00:09.357,940] <dbg> bt_hci_core: hci_tx_thread: Calling k_poll with 3 events
[00:00:09.372,283] <dbg> bt_hci_core: bt_recv: buf 0x20010314 len 7
[00:00:09.372,314] <dbg> bt_hci_core: hci_num_completed_packets: num_handles 1
[00:00:09.372,314] <dbg> bt_hci_core: hci_num_completed_packets: handle 15 count 1
[00:00:09.372,436] <dbg> bt_hci_core: bt_recv: buf 0x2000fff0 len 13
[00:00:09.372,467] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
[00:00:09.372,497] <dbg> bt_hci_core: rx_work_handler: buf 0x2000fff0 type 3 len 13
[00:00:09.372,497] <dbg> bt_hci_core: hci_acl: buf 0x2000fff0
[00:00:09.372,528] <dbg> bt_hci_core: hci_acl: handle 15 len 9 flags 2
[00:00:09.372,619] <dbg> bt_hci_core: bt_hci_host_num_completed_packets: Reporting completed packet for handle 15
[00:00:09.372,619] <dbg> bt_hci_core: bt_hci_cmd_create: opcode 0x0c35 param_len 5
[00:00:09.372,650] <dbg> bt_hci_core: bt_hci_cmd_create: buf 0x200105fc
[00:00:09.372,680] <dbg> bt_hci_core: bt_hci_cmd_send: opcode 0x0c35 len 8
[00:00:09.372,680] <dbg> bt_hci_core: bt_send: buf 0x200105fc len 8 type 0
[00:00:09.372,772] <dbg> bt_hci_core: process_events: count 3
[00:00:09.372,772] <dbg> bt_hci_core: process_events: ev->state 0
[00:00:09.372,802] <dbg> bt_hci_core: process_events: ev->state 0
[00:00:09.372,802] <dbg> bt_hci_core: process_events: ev->state 4
[00:00:09.372,833] <dbg> bt_hci_core: bt_send: buf 0x20011d7c len 14 type 2
[00:00:09.372,894] <dbg> bt_hci_core: hci_tx_thread: Calling k_poll with 3 events
[00:00:09.387,268] <dbg> bt_hci_core: bt_recv: buf 0x20010314 len 7
[00:00:09.387,298] <dbg> bt_hci_core: hci_num_completed_packets: num_handles 1
[00:00:09.387,329] <dbg> bt_hci_core: hci_num_completed_packets: handle 15 count 1
[00:00:09.432,312] <dbg> bt_hci_core: bt_recv: buf 0x2000eab0 len 12
[00:00:09.432,342] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
[00:00:09.432,373] <dbg> bt_hci_core: rx_work_handler: buf 0x2000eab0 type 1 len 12
[00:00:09.432,373] <dbg> bt_hci_core: hci_event: event 0x3e
[00:00:09.432,403] <dbg> bt_hci_core: hci_le_meta_event: subevent 0x03
[00:00:09.432,403] <dbg> bt_hci_core: le_conn_update_complete: status 0x00, handle 15
[00:00:09.432,434] <inf> Lesson3_Exercise2: Connection parameters updated: interval 45.00 ms, latency 0 intervals, timeout 5000 ms

The above screenshot is showing that the slave is requesting the wrong data length. This is clearly a problem with the nRF5340's hci command not being honored when it is parsed by the network core.

I've tried this with the ncs v2.4.1 and v2.3.0 and the issue is present in both versions for me. If you could get this working with ncs v2.4.1 that would be preferable for me. If you get this working please send your working code over in a zip.

Further proof that my phone is able to do DLE below. This is an issue with the nRF5340.

Thank you,

Brady

RE: BLE Throughput and Timing Issues

blue_dew — Fri, 06 Oct 2023 01:11:33 GMT

I am using the nRF5340 dev kit, PCA10095, as the server, and my phone is a Google Pixel 7 Pro which supports DLE. As stated earlier, the server is the one who is refusing to update the link layer's data length according to the ble sniffer logs from Wireshark. Are you sure you're running the code from the zip file I linked earlier? Our logs do not look the same.

Current SDK: 2.4.2
Current Toolchain: v2.4.1

My log from dev kit:
```

*** Booting Zephyr OS build v3.3.99-ncs1-1 ***
[00:00:00.263,458] <inf> Lesson3_Exercise2: Starting Lesson 3 - Exercise 2

[00:00:00.269,104] <inf> fs_nvs: 2 Sectors of 4096 bytes
[00:00:00.269,104] <inf> fs_nvs: alloc wra: 0, fd0
[00:00:00.269,134] <inf> fs_nvs: data wra: 0, 1c
[00:00:00.291,870] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.291,870] <inf> bt_hci_core: HW Variant: nRF53x (0x0003)
[00:00:00.291,900] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 224.11902 Build 2231721665
[00:00:00.292,724] <inf> bt_hci_core: No ID address. App must call settings_load()
[00:00:00.293,762] <inf> bt_hci_core: Identity: EA:68:F4:23:65:77 (random)
[00:00:00.293,792] <inf> bt_hci_core: HCI: version 5.4 (0x0d) revision 0x2077, manufacturer 0x0059
[00:00:00.293,823] <inf> bt_hci_core: LMP: version 5.4 (0x0d) subver 0x2077
[00:00:00.295,745] <inf> Lesson3_Exercise2: Bluetooth initialized
[00:00:00.297,912] <inf> Lesson3_Exercise2: Advertising successfully started
[00:02:32.456,878] <inf> Lesson3_Exercise2: Connected
[00:02:32.456,909] <inf> Lesson3_Exercise2: Connection parameters: interval 45.00 ms, latency 0 intervals, timeout 5000 ms
[00:02:32.614,135] <inf> Lesson3_Exercise2: MTU exchange successful
[00:02:32.614,166] <inf> Lesson3_Exercise2: New MTU: 244 bytes
[00:02:32.884,735] <inf> Lesson3_Exercise2: Data length updated. Length 27/27 bytes, time 2120/328 us
[00:02:33.019,470] <inf> Lesson3_Exercise2: Connection parameters updated: interval 7.50 ms, latency 0 intervals, timeout 5000 ms
[00:02:33.146,392] <inf> Lesson3_Exercise2: PHY updated. New PHY: 2M
[00:02:33.311,828] <inf> Lesson3_Exercise2: Connection parameters updated: interval 45.00 ms, latency 0 intervals, timeout 5000 ms
```

Everything in green is something from my log which is not present in your log. The timeout in orange is also different between our logs. Thanks again for your help.

RE: BLE Throughput and Timing Issues

Susheel Nuguru — Thu, 05 Oct 2023 06:41:18 GMT

Brady,

I compiled your project and flashed it to nRF53 DK. I had a throughput central example flashed to another nRF DK and I can see that the data length is updated as normal to 251

I also tried to run it against the central which is nrf Connect for mobile app and I still get the data length updated to 251

So I am not sure why you are seeing those results. Which central are you testing it with when you see the data length is negotiated and set to 27 bytes. Are you use that this central supports DLE?

RE: BLE Throughput and Timing Issues

blue_dew — Thu, 05 Oct 2023 02:17:10 GMT

Hey Susheel,

Attached is the minimum amount of code required to recreate the issue. This is the Lesson 3 exercise 2 nordic academy code and proj configs which can be found at this github link:
https://github.com/NordicDeveloperAcademy/bt-fund/tree/main/lesson3/blefund_less3_exer2_solution

and attached is my version of it with no changes from the github link above:

devzone.nordicsemi.com/.../min_5F00_example.zip

This has been implemented on the nRF5340 dev kit and the logs are as follows when connecting from my phone using the nRF Connect mobile application:

VCOM1:
```

*** Booting Zephyr OS build v3.3.99-ncs1-1 ***
[00:00:00.251,861] <inf> Lesson3_Exercise2: Starting Lesson 3 - Exercise 2

[00:00:00.257,659] <inf> fs_nvs: 2 Sectors of 4096 bytes
[00:00:00.257,659] <inf> fs_nvs: alloc wra: 0, fe8
[00:00:00.257,690] <inf> fs_nvs: data wra: 0, 0
[00:00:00.280,456] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.280,487] <inf> bt_hci_core: HW Variant: nRF53x (0x0003)
[00:00:00.280,517] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 224.11902 Build 2231721665
[00:00:00.281,341] <inf> bt_hci_core: No ID address. App must call settings_load()
[00:00:00.282,318] <inf> bt_hci_core: Identity: EA:68:F4:23:65:77 (random)
[00:00:00.282,348] <inf> bt_hci_core: HCI: version 5.4 (0x0d) revision 0x2077, manufacturer 0x0059
[00:00:00.282,379] <inf> bt_hci_core: LMP: version 5.4 (0x0d) subver 0x2077
[00:00:00.285,034] <inf> Lesson3_Exercise2: Bluetooth initialized
[00:00:00.287,231] <inf> Lesson3_Exercise2: Advertising successfully started
[00:11:32.408,050] <inf> Lesson3_Exercise2: Connected
[00:11:32.408,081] <inf> Lesson3_Exercise2: Connection parameters: interval 45.00 ms, latency 0 intervals, timeout 5000 ms
[00:11:32.556,610] <inf> Lesson3_Exercise2: MTU exchange successful
[00:11:32.556,640] <inf> Lesson3_Exercise2: New MTU: 244 bytes
[00:11:32.827,148] <inf> Lesson3_Exercise2: Data length updated. Length 27/27 bytes, time 2120/328 us
[00:11:32.962,371] <inf> Lesson3_Exercise2: Connection parameters updated: interval 7.50 ms, latency 0 intervals, timeout 5000 ms
[00:11:33.081,268] <inf> Lesson3_Exercise2: PHY updated. New PHY: 2M
[00:11:33.224,304] <inf> Lesson3_Exercise2: Connection parameters updated: interval 45.00 ms, latency 0 intervals, timeout 5000 ms
[00:11:44.751,922] <inf> Lesson3_Exercise2: Disconnected. Reason 19
```
nRF Connect Mobile Application Log:
```
nRF Connect, 2023-10-04 Nordic_Peripheral (EA:68:F4:23:65:77) V 22:07:08.299 Connecting to EA:68:F4:23:65:77... D 22:07:08.299 gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M) D 22:07:08.467 [Callback] Connection state changed with status: 0 and new state: CONNECTED (2) I 22:07:08.468 Connected to EA:68:F4:23:65:77 V 22:07:08.476 Discovering services... D 22:07:08.476 gatt.discoverServices() D 22:07:08.495 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED I 22:07:09.007 Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms) I 22:07:09.077 PHY updated (TX: LE 2M, RX: LE 2M) D 22:07:09.162 [Callback] Services discovered with status: 0 I 22:07:09.163 Services discovered V 22:07:09.168 Generic Attribute (0x1801)

Service Changed [I] (0x2A05)

Client Characteristic Configuration (0x2902)

Client Supported Features [R W] (0x2B29)
Database Hash [R] (0x2B2A)

Generic Access (0x1800)

Device Name [R] (0x2A00)
Appearance [R] (0x2A01)
Peripheral Preferred Connection Parameters [R] (0x2A04)

Nordic LED Button Service (00001523-1212-efde-1523-785feabcd123)

Button [N R] (00001524-1212-efde-1523-785feabcd123)

Client Characteristic Configuration (0x2902)

LED [W] (00001525-1212-efde-1523-785feabcd123)

D 22:07:09.169 gatt.setCharacteristicNotification(00002a05-0000-1000-8000-00805f9b34fb, true) D 22:07:09.172 gatt.setCharacteristicNotification(00001524-1212-efde-1523-785feabcd123, true) I 22:07:09.266 Connection parameters updated (interval: 45.0ms, latency: 0, timeout: 5000ms) V 22:07:19.672 Disconnecting... D 22:07:19.672 gatt.disconnect() D 22:07:19.683 [Callback] Connection state changed with status: 0 and new state: DISCONNECTED (0) I 22:07:19.683 Disconnected D 22:07:19.684 gatt.close() D 22:07:19.688 wait(200)
```

Expected behavior is updated Data length to 251 as defined on line 74 of main.c. Actual behavior is seen in red text of VCOM1 output above of data length 27. Can you try to recreate this issue on your end? Thank you again for all of your help Susheel.

Respectfully,

Brady

RE: BLE Throughput and Timing Issues

blue_dew — Wed, 04 Oct 2023 21:33:03 GMT

Hey Susheel,

Thank you for the quick reply. I've learned a few new things by following the nordic dev academy lesson 3 exercise 2:
https://academy.nordicsemi.com/courses/bluetooth-low-energy-fundamentals/lessons/lesson-3-bluetooth-le-connections/topic/blefund-lesson-3-exercise-2/

I linked my wireshark capture in the original post by using the nRF BLE sniffer I created from an nRF52840 dev kit. The capture starts with some malformed packets, but that is because I didn't have the sniffer close enough to both devices. If you scroll down, you can see the advertising restarts, and then a good connection is made. You can see in packet no. 845 that my PC (ble client, master) requests data length extension but the embedded system, nRF5340 w/ the above configs shown in the original post, replies in packet no. 856 with a max TX & RX octet of 27.

By following the nordic dev academy lesson 3 exercise 2 I was able to initiate another data length extension request from the server side and the call to bt_conn_le_data_len_update() doesn't return an error but my own server doesn't honor its own request because when I debug and set a break point in le_data_len_change() in the hci_core.c file the net_buf param doesn't contain the expected values for length and time which are set correctly in the bt_conn_le_data_len_update(). Its just reverting back to the default len and timing values of 27 bytes as seen in the attached wireshark capture. If you could help me understand this problem first I think I might be able to get more throughput regardless of the master repsonse times I first highlighted in the original post.

Greatly apprciated,
Brady
---

Functions from the academy lesson 3 exercise 2 used to request and monitor data length extension requests/updates:

static void update_data_length(struct bt_conn *conn)
{
	int err;
	struct bt_conn_le_data_len_param data_len = {
		.tx_max_len = BT_GAP_DATA_LEN_MAX,
		.tx_max_time = BT_GAP_DATA_TIME_MAX,
	};
	err = bt_conn_le_data_len_update(conn, &data_len);
	if (err) {
		LOG_ERR("data_len_update failed (err %d)", err);
		return;
	}
	LOG_INF("Data length update successful");
}

void on_le_data_len_updated(struct bt_conn *conn, struct bt_conn_le_data_len_info *info)
{
    uint16_t tx_len     = info->tx_max_len;
    uint16_t tx_time    = info->tx_max_time;
    uint16_t rx_len     = info->rx_max_len;
    uint16_t rx_time    = info->rx_max_time;
    LOG_INF("Data length updated. Length %d/%d bytes, time %d/%d us", tx_len, rx_len, tx_time, rx_time);
}

BT_CONN_CB_DEFINE(conn_callbacks) = {
	.connected = connected,
	.disconnected = disconnected,
	.le_phy_updated = le_phy_updated,
	.le_param_updated = on_le_param_updated,
	.le_data_len_updated = on_le_data_len_updated,
};

---

Console output:

```
Connected
TX power level: 0
[00:00:21.158,142] <inf> app: PHY update successful
Connected as peripheral
Conn. interval is 6 units
[00:00:22.158,905] <inf> app: MTU exchange successful
[00:00:22.158,905] <inf> app: New MTU: 244 bytes
LE PHY updated: TX PHY LE 1M, RX PHY LE 1M
[00:00:22.158,996] <inf> app: Data length updated. Length 27/27 bytes, time 2120/2120 us
[00:00:22.376,495] <inf> app: Connection parameters updated: interval 15.00 ms, latency 0 intervals, timeout 9600 ms
[00:00:24.176,300] <inf> app: Connection parameters updated: interval 7.50 ms, latency 0 intervals, timeout 420 ms
```

RE: BLE Throughput and Timing Issues

Susheel Nuguru — Wed, 04 Oct 2023 05:53:47 GMT

Hi Brady,

Fine tuning throughput is no easy business. But it looks like you have been on the right track all along. You seems to understand the need to calibrate connection interval, parameters and buffer sizes.

In terms of child image, the below config should be enough with the rest set to defaults

CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=4000000

CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_BUF_ACL_RX_SIZE=502
CONFIG_BT_BUF_ACL_TX_SIZE=502

CONFIG_BT_MAX_CONN=2

I strongly recommend you to take sniffer log of the throughput sample as well and compare that with the sniffer log you got. If the connection interval,

There can also be bottlenecks in pre and post processing of the data/buffer you are trying to transfer on your peripheral side. I use SystemView to get a visual understanding of timings of each thread/ISR running. It can be possible that you have all the configs set correctly but your peripheral pre/post packet processing is the bottle neck. you can compare the timings of threads by running Throughput example in systemview and also your application to see if you have introduced any processing bottlenecks in some contexts.