BLE scanning: How complex is it to force scan on only 1 BLE channel?

For a beacon ranging application, we use function NRF.setScan() to scan for beacons (TX every 1 second), with some appropriate filtering.
We experienced some particular behaviour: Scanned packets are not equally spread over time. For some couple of seconds, every beacon advertising packet is beeing received, then nothing for the next few seconds, then again almost every packet received and so on. It seems like a stroboscopic effect, due to scanning window (https://academy.nordicsemi.com/wp-conten­t/uploads/2023/03/blefund_less2_adv_proc­ess-1024x576.png).
We want to try scanning on only 1 channel, thus avoiding dead time switching between channels 37, 38 and 39, but it seems that setScan method doesn't allow for such parameter.
How complex would it be to modify setScan method to force receiving channel(s)? Would it make sense to add it as a feature to the official Espruino build?

Not sure this is possible to do with softdevice (here is old post where it is solved outside of BLE stack by running custom code in radio timeslot https://devzone.nordicsemi.com/f/nordic-­q-a/8902/scan-in-a-single-channel ) but recently at least the scan window and interval became configurable if that helps a bit https://github.com/espruino/Espruino/blo­b/0325da029cc828c377a76c5dea684a8d7520e1­b0/ChangeLog#L8

Would it make sense to add it as a feature to the official Espruino build?

Well those three channels is how BLE Advertising works, there is a reason for advertising on multiple channels. You risk missing some packets when your selected channel becomes temporarily unusable due to noise.

BTW there is interesting related technology called PAWR in BT 5.4 https://devzone.nordicsemi.com/guides/nr­f-connect-sdk-guides/b/software/posts/pe­riodic-advertising-with-responses-pawr-a­-practical-guide that improves advertising for better timing and bidirectional communication to avoid using connections but have similar features. Sadly using 5.4 means moving away from SoftDevice and classic SDK.

but recently at least the scan window and interval became configurable if that helps a bit

Seems at least promising, I will have a try once available as a feature. As far as I understand it will be pushed in 2v22...

Well those three channels is how BLE Advertising works, there is a reason for advertising on multiple channels. You risk missing some packets when your selected channel becomes temporarily unusable due to noise.

Well that's for sure, it is generally not a good idea to limit advertising on a single channel only, however in our application we will use specific beacons in outdoor, countryside context, therefore 2.4GHz interference will probably be very limited.

Thank you for your response and also for the work you did at providing scan window and interval to Espruino (not mentioning coded phy, BTW)

As far as I understand it will be pushed in 2v22...

Yes - you should be able to use cutting edge builds for now though?

Was thinking about it a bit and maybe setting scan window and iterval and stopping and starting scanning can do what you want, see this answer https://devzone.nordicsemi.com/f/nordic-­q-a/11377/how-can-i-decide-scan-window-i­nterval-for-continuous-scanning

..... after each scan interval where it will change frequency to the next advertisment channel, during this period it can't receive any advertisement packet. It will rotate between the 3 advertisment channels after each scan interval.

so you could let the scan run only one or two scan interval(s) and then stop it and start it again to let it scan only one or two channels. EDIT: well unless softdevice won't alllow to stop it until all 3 channnels are scanned

It is also described in article https://academy.nordicsemi.com/courses/b­luetooth-low-energy-fundamentals/lessons­/lesson-2-bluetooth-le-advertising/topic­/advertising-process/ you've probably seen already since it contains the picture you linked.

Also if you remember when exactly you got first advertising packet from the device you could schedule starting/stopping the scan and tune the window and interval to not miss it (+/- the 10ms random delay). If the advertising interval is longer like 500ms or even 1s or more, then such scheduling could save power while scanning when the window is shorter and interval would match advertising interval of the device.

However it becomes more complicated when there are more advertising devices to scan for which is probably your case. Well unless you manage to sync time between your beacons and start advertising on all of them in some synchronized way.

Yes - you should be able to use cutting edge builds for now though?

I should be able, however I am running the application on a NRF21540 dev board (including PA+LNA chip) and it seems that cutting edge builds do not cover NRF52 dev boards anymore.

I actually managed to compile 2v21.84 for NRF52840DK, however I don't really know how to benefit from window/interval in NRF.setScan. Is there any way of consulting Espruino API reference (in a human readable manner) for a specific commit? As far as I understand, most of it is generated from comments in source code.

Is there any way of consulting Espruino API reference (in a human readable manner) for a specific commit?

sure - you just check it out and then run make docs :) Currently that isn't done by Github actions though

don't know about specific commit but
https://www.espruino.com/Reference#l_NRF­_setScan is the documentation,for options it points to
https://www.espruino.com/Reference#l_NRF­_requestDevice

So like there is "phy" or "extended" option there is new "window" and "interval" options with value in miliseconds
https://github.com/espruino/Espruino/blo­b/master/targets/nrf5x/bluetooth.c#L3008­
so something like

NRF.setScan(function(d) {
  console.log(d.manufacturerData);
}, { "interval":1000, "window":1000});

should probably scan one channel for 1 second. Once you find the device in the callback you may record current time, stop the scanning NRF.setScan(); and start it again somehow synchronized to expected advertising interval. like if that is 1 second then start after 900ms and scan e.g with window of 200 for interval 1000 if that improves things and packets will hit the 200ms window every second. I did not actually try this idea yet.

Thank you @fanoush for your help. I will definitely try to play with interval and window settings to see if I can increase the packet RX rate, however for my application, trying to synchronize with beacons's advertising interval will probably be too complicated for now.

For those who are interested, after some endurance tests (1 week) with continuous scan, the packet RX rate was around 47%, with a beacon advertising sequentially in all 3 channels every 2 seconds.
If I can increase this number thanks to interval and window settings, I will post result here.

What I don't understand is that the raspberry Pi I am using for Home Assistant, achieves nearly 100% RX rate for Espruino devices advertising with BTHome. I guess the BLE advertising mechanism should be reliable enough to achieve 80%+ RX rate at least, maybe something is wrong with the way I am using setScan.

Are you using active or passive scan (options.active = 1)? With active scan for every device found it tries to request scan response from it. So when doing this I am guessing it may miss other device advertising at the same time? The scan response request/response is done on same channel as the advertising packet received. And I think it is done immediately after receiving the packet since the advertising device waits only short window for scan response request after sending advertising packet. Anyway, changing scan to passive could IMO help to just listen for the whole window instead of transmitting into the same channel for every device that is found possibly increasing noise and missing something.

BTW just found interesting document about active scanning and its issues "Anti-Collision Adaptations of BLE Active Scanning for Dense IoT Tracking Applications" https://zaguan.unizar.es/record/75799/fi­les/texto_completo.pdf?version=1

Unfortunately I already restricted myself to using passive scan only, and the 47% RX rate is therefore for passive scan as well.