Fastest rate at which to rapidly switch advertising data

[calebt]

Hello,

We have an application based on ble_app_blinky that is actively scanning for advertised packets but does not attempt to connect. We have a second application based on usbd_ble_uart that will broadcast (BLE advertising) small packets of data that are received over USB.

To change our advertised packets, we use sd_ble_gap_adv_set_configure().  We follow this with a call to nrf_delay_ms(500) to ensure the broadcaster has advertised for at least half a second before changing the packet data again.  Unfortunately, this is too slow for us to use realistically, so we want to speed up the rate at which we call sd_ble_gap_adv_set_configure().  However, dropping nrf_delay_ms to 250ms is too fast and the Blinky-based application will miss packets despite setting the scan interval and scan window to 20ms.

Is there a way to improve this? Again, we want a way to rapidly change advertised packets and for the receiver not to miss any of them.  This is sort of a beacon-type application.

Thank you!

Note: we are developing using nRF5 SDK 15.0.0 on the nRF52840 with SoftDevice 140. Segger ES is the dev environment.

[Fred]

I'm wondering if I understand your requirement correctly because if you don't want to miss any advertising packets, you need to advertise longer; since the scanner is scanning on all 3 channels, there is always a probabilty that it will not detect an advertising packet during this advertising event. This probability depends on the ratio between the scan idle time and the scan interval (see figure below). The probability of the scanner not detecting a peripheral becomes very low after a number of advertising intervals (the ratio to the power of the number of advertising intervals), but will never be 0.

I guess you have a reason for not simply connecting to the peripheral? Depending on advertising packets for reliable data is not a good approach in my experience. I have a neighbor who has over a 100 BLE beacons (we're not friends ;-) and connecting to a peripheral takes at least a couple of tries, i.e. my application most of the time fails to detect the peripheral during a number of advertising events.

[calebt]

Thank you for the useful figure, Fred!  Just a couple follow-ups:

Looking at the "Advertising interval" figure, it seems that the device will advertise on the 3 channels one after the other, then stop advertising. It will then wait for the interval to be over before advertising again, correct?  Or is the device advertising on the 3 channels repeatedly until the interval is over?

Also, is it possible to both advertise and scan exclusively on one channel to raise the probability of catching the packet?

We really wanted this design to be more beacon-esque because we wanted a couple hundred devices in the vicinity to receive the same packets at around the same time.

[Fred]

Yes that’s correct. Also it is possible to configure channel masks for both advertise and scan on a single channel (there are several questions on this forum discussing this). As of Bluetooth 5 one can also advertise on all other data channels. However, advertising on a single channel makes the application more vulnerable for interference of course. But it depends on the environmental setting of your application whether this is a problem of course.

[calebt]

Great, thanks!

By "yes, that's correct", you mean that the device will advertise on the 3 channels one after the other, then stop advertising. It will then wait for the interval to be over before advertising again, correct?

One last question: do you know how long the device will advertise on a single channel before moving on to the next one?  We would want to shrink the advertising interval down as much as possible--if we only advertise on a single channel, we'd basically want to set the interval to exactly the length of time needed for the device to advertise once on the channel.

[Fred]

The device will transmit on an advertising channels, then listen shortly for a response and then continue to the next advertising channel. After all 3 channels, the device stops (i.e. radio switches off) and waits for the advertising interval to end after which the process repeats.

A nice way of getting insight into timing of this process is looking at Nordic's "Online Power Profiler". That gives you all the information about timing (which also depends on the contents of the advertising packet) and the associated power consumption.