Bluetooth Controller with Extended Advertising

[LingaoM]

Hi,

i'm use Zephyr Bluetooth Controller to develop bluetooth extended advertising application, but found the secondary advertising pdu aux offset too big than Nordic Connect SDK.

For example, ncs sdk aux offset almost 400us, but the current zephyr sdk bigger than 10ms

[LingaoM]

ncs_ext_adv_demo.zip

[cvinayak]

In the Zephyr Controller design, the scheduling of AUX_ADV_IND PDUs are different to ensure that they can be placed non-overlapping with other states and roles, and the ADV_EXT_IND PDUs would be scheduled with the required random_delay.

[LingaoM]

For Mesh Relay messages, time conflicts will inevitably occur, resulting in packet loss.

[LingaoM]

Imagine that multiple Mesh Relay nodes receive a message and Relay at the same time, even if ADV_EXT_IND is random, but in Zephyr's implementation, ADV_AUX_IND is timed, so multiple Relay messages cannot be received by the same device, because they Time all collides.

[cvinayak]

I agree that when multiple nodes advertise at the same moment, the AUX_ADV_IND would overlap but each one will use random radio channel index (uses CSA#2). Devices listening would receive ADV_EXT_IND at random time and listen to AUX_ADV_IND at the specific radio channel idx.

[LingaoM]

Although channel differences, but the time is same, so only one aux advertisement can received, other message will be discarded unexpectedly.

[cvinayak]

It is the same when all the ADV_EXT_IND overlap when multiple nodes advertising at the same time. Only one primary channel PDU is received hence one AUX_ADV_IND when there are overlap.

I do not disagree that current Zephyr Controller takes worst case delay in receiving all the advertising from multiple nodes.

Zephyr Controller's is focused towards maximizing the radio utilization for audio uses cases where each radio use be smallest to increase available radio for ISO radio events. No optimization (controller) for Mesh stack is planned yet.