SW based BLE Link Layer Random Advertise delay not as expected

[jakkra]

Describe the bug
I have a very simple Zephyr application that advertises with a configureable interval.
On my receiver NRF52833 I have a custom radio driver that I scan with and I need to get all 3 adv packets ch 37, 38 and 39. According to BT spec between each advertise packet there shall be a 0-10ms random delay. Changing the frequency on the NRF52833 radio takes about 120us (+ some overhead by our code, but still <~200us), so after I receive adv packet on ch 37 I have radio switched to ch 38 within 120-200us. So I should be able to receive all 3 adv packets most of the time, as the risk of the random delay is lower then ~120us i small.

I am almost always missing packets on ch 38 and 39 when I use Zephyr BT LL. If I switch and use
Nordic proprietary BLE Link Layer I am able to 95% of the time receive all 3 adv packets. I have also made a test application advertising using NRF52 Softdevice and with it my baremetal receiver also successfully receives all 3 adv packets.

So:

• Software-based BLE Link Layer - Does not work
• Nordic proprietary BLE Link Layer - Works

My conclutions are that the Zephyr Software-based BLE Link Layer have a very small delay between the 3 advertising packets and therefore I'm not able to receive them.

I looked here

zephyr/subsys/bluetooth/controller/ll_sw/ull_adv.c

Line 1629 in 03df709

lll_rand_isr_get(&random_delay, sizeof(random_delay));

and found what seems to be some kind of random delay, checking this value it's almost always <300us. I tried hardcoding it to 1000us, but it doesn't seem as it changed the time BETWEEN the adv packets. So I'm unsure this is the correct location for the code controlling the random delay between packets, Can someone point me to where that may be?

To Reproduce
Steps to reproduce the behavior:

1. Build some advertising example application
2. Check the time between advertsing packets on ch 37->38 and 38->39.

Expected behavior
I expect the time between adv packets to follow BT spec and be a random delay between 0 and 10ms.

Impact
We need to use the Software-based BLE Link Layer for custom Direction Finding until it's officially supported.

Environment (please complete the following information):

• OS: Windows
• Zephyr V2.3.1-RC1
• NRF Connect v1.3.0
• NRF52833

Thank you

[cvinayak]

Expected behavior
I expect the time between adv packets to follow BT spec and be a random delay between 0 and 10ms.

By BT Spec. "The advDelay is a pseudo-random value with a range 0 ms to 10 ms generated
by the Link Layer for each advertising event."

The 10 ms random delay is between "advertising event" consisting of channels 37, 38 and 39.

There is no specification limit as to how low the three channels can be placed together (closer the better for optimal timespace utilization).

Zephyr LL controller switches non-connectable advertising channels in as low as 62 us between 37, 38, and 39. The nRF Sniffer (downloadable from Nordic's website) too is able to switch in the similar timings and be able to sniff Zephyr LL controller traffic.

[carlescufi]

Changed from bug to question as per this comment. I think that you'll find that the open source Link Layer is just very fast at switching.

[jakkra]

Thanks, sorry then I missunderstood the spec. Guess I'll need to try get my receiver quicker so that I can switch channel faster than ~62us.

[joerchan]

@jakkra You will have to change the ramp-up. Have a look at the MODECNF0 register in the radio peripheral.
The radio should start in 40 us, so you just have to keep your processing overhead less than 22 us.

[jakkra]

@joerchan Thanks for the tip, I'll take a look at the ramp-up in MODECNF0 and see if I can optimize the processing time.