zephyr: Bluetooth Ext Adv:Sync: While simultaneous advertiser are working, and skip is non-zero, sync terminates repeatedly

Describe the bug Using the https://github.com/zephyrproject-rtos/zephyr/pull/41091 (force-pushed on 2 Feb), I tested 10 simultaneous advertiser (AoA tag) with one scanner (AoA locator). The source codes are based on “connection-less direction finding” examples, by adding simultaneous tag support to scanner code. The advertiser are working with extended adv interval = 80ms, legacy adv interval = 150ms. All devices are nRF52833DK board.

Successful Scenario: If at receiver side, “skip” parameter is a non-zero value, then “synchronization” is made successfully and the probability of losing the sync is low.

struct bt_le_per_adv_sync_param param;
param.skip = 1;
param.timeout = 2000;
...
bt_le_per_adv_sync_create(&param, synch);

The output log is something like this:

try to sync tag1
tag1 synced
try to sync tag2
tag2 synced
try to sync tag3
tag3 synced
try to sync tag4
tag4 synced
try to sync tag5
tag5 synced
try to sync tag6
tag6 synced
try to sync tag7
tag7 synced
try to sync tag8
tag8 synced
try to sync tag9
tag9 synced
try to sync tag10
tag10 synced

(after 30minutes no sync lost was seen)

Failure Scenario: But if, “skip” parameter is set to zero, at the beginning of the program, syncs are made normally like above condition, but after a while it start to lose the sync with tags, and it usually must retries more than once to make the sync again. in most retries, it terminate eventually exactly after calling the bt_le_per_adv_sync_create function.

struct bt_le_per_adv_sync_param param;
param.skip = 0;
param.timeout = 2000;
...
bt_le_per_adv_sync_create(&param, synch);

The output log could be:

try to sync tag1
tag1 synced
try to sync tag2
tag2 synced
try to sync tag3
tag3 synced
try to sync tag4
tag4 synced
try to sync tag5
tag5 synced
try to sync tag6
tag6 synced
try to sync tag7
tag7 synced
try to sync tag8
tag8 synced
try to sync tag9
tag9 synced
try to sync tag10
tag10 synced

tag3 sync lost
try to sync tag3

tag3 sync lost
try to sync tag3

tag3 sync lost
try to sync tag3

tag3 sync lost
try to sync tag3
tag3 synced

(the above retries occur for other tags too and it is very common to lose the sync, 
which makes the whole system functionality unstable) 

In both cases timeout value is same. I supposed that “skip” parameter can not affect on sync termination as I asked this question in nordic devzone, but seems it is not. https://devzone.nordicsemi.com/f/nordic-q-a/84232/more-information-about-skip-and-timeout-parameters-of-ble-5-advertising

To Reproduce Steps to reproduce the behavior:

1. use “connection-less direction finding” examples
2. Add simultaneous tag support to the scanner source code
3. west build -b nrf52833dk_nrf52833
4. west flash
5. See error

Expected behavior The termination is only dependent on “timoute” parameter, changing “skip” should not change the behavior of losing sync between scanner and advertiser.

Impact System is not stable when skip=0 and multiple advertiser try to sync with the scanner.

Logs and console output as you can see in the bug description (above)

Environment (please complete the following information):

• OS: Linux
• Toolchain: Zephyr SDK
• Commit SHA or Version used: https://github.com/zephyrproject-rtos/zephyr/pull/41091/commits/9749514d83887d1dedde9966a0dc2a5d401aca97

Additional context In addition to the above problem, sometime this assertion failure happens too

ASSERTION FAIL [next] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/nordic/lll/lll.c:649