zephyr: Bluetooth Controller: Not able to find extended advertising until after a few minutes after no BLE devices in the area for ~30 minutes
Describe the bug If we leave the scanner in an area without BLE devices for about 30 minutes and then turn on an advertiser with extended advertising it takes about 2-4 minutes until the extended advertiser is seen. Even adding 20+ advertisers, none are found until after this 2-4 minute delay.
The applications here use periodic advertising and syncing. Periodic advertising may not be needed, as the issue seems to be with extended scanning, however it could be caused due to periodic syncing.
It’s not enough to leave the scanner without BLE devices for just a few minutes, about 30 minutes it has to be left idle/without BLE devices.
Please also mention any information which could help others to understand the problem you’re facing:
- What target platform are you using?
- nRF52833
- What have you tried to diagnose or workaround this issue:
- Been debugging and looking around a bit in the BLE controller when it happens and it seems as the scanner finds the
ADV_EXT_INDbut fails moving to and looking for theAUX_ADV_IND.
- Been debugging and looking around a bit in the BLE controller when it happens and it seems as the scanner finds the
- Is this a regression?
- Issue both in Zephyr 3.3 and main branch
To Reproduce Right now I can only reproduce in our BLE AoA Locator application only. It’s based on Zephyr 3.3, however I have successfully replaced the BLE Controller from Zephyr main and can still reproduce the issue. So I think it’s safe to say the issue still exists in Zephyr main.
I’m in progress of trying to create a sample application based on samples/bluetooth/direction_finding_connectionless_rx to reproduce the issue but so far have not succeeded.
Below is the steps to reproduce
- Put a scanner and an advertiser inside a shielded box.
- Turn on advertiser.
- Wait for it it sync.
- Turn off advertiser
- Wait ~30 minutes
- Turn on advertiser
- Now it will take 3-4 minutes until the scanner prints out scan info and manages to sync with the advertiser.
Expected behavior Finding extended advertising without large delay.
Impact What impact does this issue have on your progress (e.g., annoyance, showstopper):
- We have customer in field with this issue so for us important to find a solution as soon as possible.
Environment (please complete the following information):
- OS: Linux
- Commit SHA: main as of day of issue creation 72c6ffb2d04bf1d9c23e0ef71464b3693d96ba98
Other Initially discussed here with @cvinayak: https://discord.com/channels/720317445772017664/733036837576376341/1187715776690524190
About this issue
- Original URL
- State: closed
- Created 6 months ago
- Comments: 35 (35 by maintainers)
@cvinayak with https://github.com/zephyrproject-rtos/zephyr/pull/67817 I have so far not been able to reproduce any issues with this fix, fantastic!
@jakkra sorry, I submitted the PR from airport and did not compile for AoA sample… the PR updated now.
When continuous scanning is used, the ticks anchor used for scheduling the auxiliary PDU is picked from the RTC compare register, but as RTC was not used to restart the scan window (for 37, 38, 39 radio channels indices), after a RTC rollover the used RTC compare value is not sane.
I am running your application now… hope I do not encounter more bugs!
Hi @cvinayak still getting assert after having transmitter off for ~30 minutes and then starting it. I cherry-picked this commit you can see the commits matching in the screenshot also.
@cvinayak Running it now
I’m not 100% sure if “radio silence” is needed or if it’s enough to not have any extended/periodic advertisers around.
I have no simple way to test as there are so much BLE stuff in the office, many doing extended/periodic adv. But I’ll bring a setup home today and test if it’s possible without a shielded box.
Nevermind, my fault 81632507 is in microseconds. In 30.517 us units, it is 2674984 is 0x28D128 and within the 24-bits.
I think i found something that can explain this, but the issue is a pattern all over the code, will try to send a PR to address this first. Then lets try to reproduce the issue of not receiving adv reports after 30 mins of idle.