Observer/Advertising/Peripheral: Scan window is canceled after advertising/peripheral event

[puz_md]

Good evening and a happy new year to everybody.

Now it's time to work again, and I already stumbled about a little twouble while implementing a peripheral with concurrent observer functionality.

I use the nRF52-DK (Preview version), s132_nrf52_2.0.0-4.alpha_softdevice.hex and SDK v0.9.2.

The observer functionality is running in background, scanning at 100% or almost 100% of the time. First I decided do make the scanning window ~2 seconds long to save BLE stack overhead. In this configuration, I detected a strange behavior: Each time an advertising packet is sent, the observer doesn't receive any advertising packets for a while. It seems like the scan functionality is interrupted by the advertising event and does not resume until the end of the scan window / scan interval is reached. This way, I lost a lot of data (up to 2 seconds which is the scan interval).

As a workaround, I decided to make the scan interval smaller using 0x80 (~80 ms). This seems to work much better for my requirements (losing single broadcasting packets is not so bad as losing 2 seconds of consecutive packets).

I have two questions:

1. Will ther be performance issues if I make the scan window very small, like 10ms, to minimize the packet loss and observing latency? I have enough energy so this is not a problem.

2. Is the observed behavior a bug? In my opinion, after an advertising packet (or connection packet) has been sent, the previously interrupted scan should be resumed as long as the scan window is still active. It doesn't make sens to switch to idle for the rest of the scan window/interval. Don't you agree?

Here are my scan parameters (currently both interval and window is replaced by 0x0080):

static const ble_gap_scan_params_t scan_param =
{
    0,                                 // Active scanning set
    0,                                 // Selective scanning not set
    NULL,                              // No whitelist provided
    0x0D80,                            // Scan interval
    0x0C80,                            // Scan window
    0                                  // No scan timeout (scan infinitely)
};

And my advertising parameters:

ble_gap_adv_params_t adv_params;
memset(&adv_params, 0, sizeof(adv_params));
adv_params.type        = BLE_GAP_ADV_TYPE_ADV_IND;
adv_params.p_peer_addr = NULL;
adv_params.fp          = BLE_GAP_ADV_FP_ANY;
adv_params.interval    = 1600;
adv_params.timeout     = 0; // 0 = no timeout;

Thanks a lot!

[Anders Strand]

Hey.

At the moment, this is how the internal scheduler handles this. I have reported the issue, and it might be improved in a future release.

You should not experience any problems with having a low scan window/interval.

[puz_md]

Thanks for the feedback.