BLE scanning: How complex is it to force scan on only 1 BLE channel? #4325
Replies: 1 comment
-
Posted at 2024-04-08 by @fanoush 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/blob/0325da029cc828c377a76c5dea684a8d7520e1b0/ChangeLog#L8
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/nrf-connect-sdk-guides/b/software/posts/periodic-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. Posted at 2024-04-09 by @yerpj
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 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) Posted at 2024-04-09 by @gfwilliams
Yes - you should be able to use cutting edge builds for now though? Posted at 2024-04-09 by @fanoush 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-interval-for-continuous-scanning
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/bluetooth-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. Posted at 2024-04-11 by @yerpj
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. Posted at 2024-04-16 by @yerpj I actually managed to compile 2v21.84 for NRF52840DK, however I don't really know how to benefit from window/interval in Posted at 2024-04-16 by @gfwilliams
sure - you just check it out and then run Posted at 2024-04-16 by @fanoush don't know about specific commit but So like there is "phy" or "extended" option there is new "window" and "interval" options with value in miliseconds
should probably scan one channel for 1 second. Once you find the device in the callback you may record current time, stop the scanning Posted at 2024-04-17 by @yerpj 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. 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. Posted at 2024-04-17 by @fanoush 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/files/texto_completo.pdf?version=1 Posted at 2024-04-17 by @yerpj Unfortunately I already restricted myself to using passive scan only, and the 47% RX rate is therefore for passive scan as well. Posted at 2024-06-21 by @yerpj Well after some experiments with setScan window and interval parameters I am still struggling at increasing the RX probability. For a given beacon I have like 99% RX probability with Android's NRF Connect, while staying below 50% probability with Espruino setScan on a NRF52DK. Maybe it is due to interpreter taking some time to set things up or IDK but it looks like I will have to try another method at Receiver'side to reach greater RX probability Posted at 2024-06-24 by @gfwilliams If you're scanning all the time, what probability do you get? Also, are you connected by BLE at the time? If so, it's probably in high-bandwidth mode with a poll interval every 7.5ms which is very likely to overlap with any received packets Posted at 2024-06-24 by @yerpj I am scanning all the time, yes:
Results seems better when laptop is not connected to the receiving node but the statistics previously given have been established in disconnected mode. It makes me think that I did not try to stop the receiver from advertising itself, or at least limiting the advertising, I will definitely give it a try and share my results. Posted at 2024-06-24 by @yerpj increased the advertising interval up to 4227ms (arbitrary value) and I have now a RX probability of 92%. It was definitely the issue I had... the receiver was advertising every 100ms.... Posted at 2024-06-24 by @gfwilliams Great! Glad that fixed it for you! edit: Well, it didn't - but glad it at least gave you some ideas ;) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2024-04-08 by @yerpj
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-content/uploads/2023/03/blefund_less2_adv_process-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?
Beta Was this translation helpful? Give feedback.
All reactions