2
\$\begingroup\$

Is it ok to increase the time between BLE advertisements to longer than 10.24 seconds? I know 10.24 s is the longest time I can set for the advertisements to automatically repeat, but I can also manually turn advertising on and off.

If I set a timer for 1 minute to enable advertising, send out the advertisement packet, and then disable advertising for another minute, is this violating any BLE rules? Our system is constantly scanning for our beacons so we won't miss any advertisements, I'm just trying to save some power by not having to transmit so often.

\$\endgroup\$
1
  • \$\begingroup\$ any rules would most likely be concerned with flooding the airwaves, not transmitting infrequently \$\endgroup\$
    – jsotola
    Oct 21, 2020 at 23:05

2 Answers 2

2
\$\begingroup\$

The "BLE rules" you refer to would be the "Core Specifications" of the Bluetooth Special Interest Group (Bluetooth SIG). As far as I know, they do not place a limit on how infrequently a device can advertise.

But you may run into problems connecting, if using a smartphone as your central device. Although you might guess otherwise, scanning uses almost as much instantaneous current as transmitting, and since it runs much longer than transmitting, it is a greater consumer of battery energy. As a result, the smartphone OS generally only scans for a limited period after each request. You can, of course, bypass this by repeatedly requesting a scan, but the battery life will suffer.

Focusing back on your peripheral, you should calculate a power budget to determine how much battery energy is consumed by the periodic advertising versus the baseline current draw during sleep. Even though advertising draws several mA, it only lasts a few mSec. Once the advertising interval is longer than a few seconds, you will find the sleep current, even at a few microAmperes, takes a bigger part of the energy budget than advertising.

Also, instead of advertising and scanning, consider maintaining an actual connection, with a long connection interval, and a high value for "slave latency" (number of connection intervals the peripheral is allowed not to respond, without breaking the connection). This tends to optimize battery life for both the peripheral and the central device.

\$\endgroup\$
1
  • \$\begingroup\$ Thanks! Our current system doesn't need to connect at all, it's more of a central observer scanning for a bunch of beacons to make sure they are all still present and not tampered with (based on flags in the advertising data). I guess the only confusing thing is why the sleep current matters, because the device is always going to be either sleeping or advertising, so why not minimize the transmissions and maximize sleep time? \$\endgroup\$
    – esimunds
    Oct 23, 2020 at 16:48
0
\$\begingroup\$

Is it ok to increase the time between BLE advertisements to longer than 10.24 seconds?

That would reduce the likelihood of being detected by something that intermittently scans, for example because it is itself battery powered.

Our system is constantly scanning for our beacons so we won't miss any advertisements

If you don't need to be compatible with other people that might work. Is it really even important that you be implementing BLE and not some other 2.4 GHz GFSK scheme that happens to look uncannily similar?

One thing to keep in mind however is that BLE advertising is split over three channels. You may want to think about how that interacts with your sparser than usual rate; not saying it will be an issue, just that it might merit investigation and thought.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.