Fastest rate at which to rapidly switch advertising data

RE: Fastest rate at which to rapidly switch advertising data

Fred — Thu, 11 Apr 2019 05:07:24 GMT

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.

RE: Fastest rate at which to rapidly switch advertising data

calebt — Wed, 10 Apr 2019 20:26:19 GMT

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.

RE: Fastest rate at which to rapidly switch advertising data

Fred — Wed, 10 Apr 2019 20:17:32 GMT

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.

RE: Fastest rate at which to rapidly switch advertising data

calebt — Wed, 10 Apr 2019 19:41:40 GMT

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.

RE: Fastest rate at which to rapidly switch advertising data

Fred — Wed, 10 Apr 2019 18:05:10 GMT

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.