nrf52840 - Scan start delay

RE: nrf52840 - Scan start delay

ovrebekk — Thu, 02 Jul 2020 06:45:58 GMT

Hi Ivan

I am happy to hear that you got it working well.

The best of luck with your project 🙂

Best regards
Torbjørn

RE: nrf52840 - Scan start delay

Ivan Herrera — Wed, 01 Jul 2020 12:41:26 GMT

[quote userid="2116" url="~/f/nordic-q-a/63150/nrf52840---scan-start-delay/257823"]If you stop advertising before you start scanning (and then re-start advertising afterwards) you should be able to start scanning immediately[/quote]

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.

[quote userid="2116" url="~/f/nordic-q-a/63150/nrf52840---scan-start-delay/257823"]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. [/quote]

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

RE: nrf52840 - Scan start delay

ovrebekk — Wed, 01 Jul 2020 12:13:51 GMT

Hi Ivan

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.

Best regards
Torbjørn

RE: nrf52840 - Scan start delay

Ivan Herrera — Tue, 30 Jun 2020 12:12:05 GMT

Hi! No active connections of any kind. Just advertising and scanning.

RE: nrf52840 - Scan start delay

ovrebekk — Tue, 30 Jun 2020 11:58:07 GMT

Hi Ivan

Are there any active central connections, or are you only doing advertising and scanning?

Best regards
Torbjørn

RE: nrf52840 - Scan start delay

Ivan Herrera — Tue, 30 Jun 2020 11:51:01 GMT

S140 v6.1.1

RE: nrf52840 - Scan start delay

ovrebekk — Tue, 30 Jun 2020 11:46:09 GMT

Which version? s140 v7.0.1?

RE: nrf52840 - Scan start delay

Ivan Herrera — Tue, 30 Jun 2020 11:44:51 GMT

Thanks! I'm using S140

RE: nrf52840 - Scan start delay

ovrebekk — Tue, 30 Jun 2020 11:35:46 GMT

Hi Ivan

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?

Best regards
Torbjørn