nrf52840 - Scan start delay

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).

Parents Reply Children
  • 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.

    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! :)