zephyr: Bluetooth: Controller: Periodic adv. sync. degraded performance on latest main branch

Describe the bug In the below table it can be seen that current main branch of Zephyr is not working as we expect. We expect the performance to be as with nRF Connect 2.0 or better. This is tested with https://github.com/zephyrproject-rtos/zephyr/pull/49429 code, which is a small addition to the main branch as of today.

15 Tags nRF Connect 2.0	15 Tags Zephyr main

20 Tags nRF Connect 2.0	20 Tags Zephyr main

One difference I can see in the logs are that for Zephyr main branch I get many prints as below. That is sync_term callback but the le address is invalid (garbage).

PER_ADV_SYNC[4]: [DEVICE]: 00:D9:AC:00:00:00 (public-id) sync terminated reason: 62
[00:00:17.917,205] <err> u_df_scan: Got sync_term from none queued tag!

Please also mention any information which could help others to understand the problem you’re facing:

What target platform are you using? - Zephyr SDK and NRF52833
Is this a regression? - Bisect is in progress…

To Reproduce Build below application based on the direction_finding_connectionless_rx sample (the application does not enable CTE sampling by default but can still reproduce the issue). aoa_receiver_multiple_configureable.zip

There are some options in the top of the main.c file, default is using periodic adv. list. which is also from where the images above are taken using.

NOTE if you build for other commits than https://github.com/zephyrproject-rtos/zephyr/pull/49429 the line CONFIG_BT_CTLR_SYNC_PERIODIC_SKIP_ON_SCAN_AUX=y needs to be commented out in prj.conf

Have about 10 tags sending periodic advertisements (I used about 50ms interval and about 30 bytes per. adv. data payload, this is probably not needed) for example use direction_finding_connectionless_tx sample, the periodic_adv should also work, but I have not tried.

Expected behavior Equal behaviour or better in Zephyr main branch compared to Zephyr version used in nRF Connect 2.0

Impact Degraded performance when tracking many tags in an application

Logs and console output ncs_2-0-20-tags.log ncs-2-0-15-tags.log zephyr-main-15-tags.log zephyr-main-20-tags.log

Environment (please complete the following information):

OS: Windows
Toolchain: Zephyr SDK
Commit SHA or Version used: Used the code as in https://github.com/zephyrproject-rtos/zephyr/pull/49429

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 25 (22 by maintainers)

Most upvoted comments

@cvinayak @Thalley I think I found the issue. Since I’m using perioidic adv. list the current get_pending_per_adv_sync() will have a none populated le addr.

struct bt_le_per_adv_sync_param sync_create_param;
sync_create_param.options = BT_LE_PER_ADV_SYNC_OPT_USE_PER_ADV_LIST;
sync_create_param.skip = 0;
sync_create_param.sid = 0; // Not used but needs to be 0 otherwise error
sync_create_param.timeout = SYNC_LOST_TIMEOUT_10MS_UNIT;
memset(&sync_create_param.addr, 0xFF, sizeof(bt_addr_le_t)); // <= Added this now
err = bt_le_per_adv_sync_create(&sync_create_param, &syncForList);

With memset(&sync_create_param.addr, 0xFF, sizeof(bt_addr_le_t)); part and the address in sync_term is now 0xFF … 0xFF… Previously I did not touch the sync_create_param.addr, hence the random bytes.

So the problem is here https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/host/scan.c#L910 that term_info.addr = &pending_per_adv_sync->addr; should be populated with the address coming from the HCI event instead of pending_per_adv_sync =>

term_info.addr = &evt->adv_addr;
term_info.sid = evt->sid;

The term_info.sid should also come form the HCI event as that is not used in bt_le_per_adv_sync_param when options is BT_LE_PER_ADV_SYNC_OPT_USE_PER_ADV_LIST

jakkra on Aug 25, 2022

@cvinayak Yes sure, I’ll do that, thanks.

jakkra on Sep 1, 2022

Larger window widening = higher power consumption. Radio is listening earlier and longer to detect missing PDUs than when the clock accuracy is better. Hence, lower clock accuracy means each radio event needs higher event length to use.

What does this mean for Zephyr Controller, the time reservation is fixed (minimal by default). If a PDU arrived late in the window , overflows beyond the time reservation and with a chance to overlap with another event, then the just-in-time negotiation would get used.

Also what I mean is with low clock accuracy more radio event would slide into each other to overlap often.

cvinayak on Aug 30, 2022

@cvinayak I have now tested https://github.com/zephyrproject-rtos/zephyr/pull/49579 with my sample application (attached to this issue) and it looks promising. Will test with our main application on monday also. 250ms per adv interval and 45 tags. 45_tags_250_ms_interval__cte

jakkra on Aug 26, 2022