I'm using an nrf52840 devkit but I'm assuming this behavior happens on all nrf52 devices. I'm trying to control the scanner using app_timer because I need a higher scan interval than the maximum supported interval (BLE_GAP_SCAN_INTERVAL_MAX). When calling nrf_ble_scan_start I'm observing that the softdevice does not start immediately scanning but waits m_scan.interval before it starts the actual scan. In theory, this would be simple a case of adding that delay into my timer code which seems to be working fine, but it takes a while before the advertising starts back up. What is happening in my code:
I set scan_window to BLE_GAP_SCAN_WINDOW_MAX. I set scan_interval to 1000ms.
1. I start a timer that fires every 10 seconds.
2. The timer fires, I call sd_ble_gap_scan_stop, I start a second stop-timer which I set to 1000ms+ my requested window (184ms in this case)
3. After 1000ms, the scan starts. (see screenshot)
4. After 184ms the stop-timer fires, after which the scan ends by calling sd_ble_gap_scan_stop, but advertisements seem to cease for about another second;
5. Only after about 1000ms the advertisements start back up.
Is there a way for me to get the advertisements to start sooner? Decreasing the scan_interval partly resolves the issue (the advertising delay is only 300ms when I set scan_interval to 300ms), but causes the radio to briefly switch off and back on when scanning for a longer time, causing a % packet-loss received from other advertisers. Ideally, if there was a way to immediately start scanning when calling nrf_ble_scan_start, this would resolve my issue (this seems to happen with the first scan, but subsequent scans have the delay).
I will check with the SoftDevice team if this behavior is to be expected, and if there is some way to change it.
Can you confirm which version of the SoftDevice you are testing on?
Thanks! I'm using S140
Which version? s140 v7.0.1?
Are there any active central connections, or are you only doing advertising and scanning?
Hi! No active connections of any kind. Just advertising and scanning.
Apparently the delayed scanning is caused by the fact that scanning is scheduled repeatedly from the moment you start a scan, with an interval set by the scan interval.
The very first scan interval will be blocked by the advertisements, since they were already scheduled by the time scanning is started. On the next available scan window one scan interval later the scanning will get priority over advertising, since it was blocked previously.
If you stop advertising before you start scanning (and then re-start advertising afterwards) you should be able to start scanning immediately.
When you say you drop a percentage of packets when using a shorter scan interval, have you quantified how many packets you drop?The switch between channels should be quite quick, and I would be surprised if the percentage of dropped packets is high.
ovrebekk said:If you stop advertising before you start scanning (and then re-start advertising afterwards) you should be able to start scanning immediately
Correct, I just implemented that and now it seems to start instantly and does not have the advertising-delay behind the scan! Thank you so much.
ovrebekk said:When you say you drop a percentage of packets when using a shorter scan interval, have you quantified how many packets you drop?The switch between channels should be quite quick, and I would be surprised if the percentage of dropped packets is high.
I was dropping about 50% of the packets, but now I come to think of it this was probably because I set scan_interval to BLE_GAP_SCAN_INTERVAL_MIN, which was a couple ms. I just thought that if I advertised on only one channel it wouldn't switch. I've read a couple of times on these forums the following rule: "set scan_interval to scan_window to get 100% duty cycle.", so because I was getting that delay I set the interval to the lowest possible (but by using the PPK and looking at the scan-window I saw that it was still "switching" channels even though I had whitelisted the other two).
In any case, with your solution, I'm dropping about 0% of the packets so thanks for clearing this up! :)
I am happy to hear that you got it working well.
The best of luck with your project