BLE Advertising Power Management

RE: BLE Advertising Power Management

Einar Thorsrud — Thu, 12 Dec 2024 14:43:28 GMT

Then you would have to use the radio to scan and that is power consuming. And as you will have to scan for some time to be lucky and overlap with when other devices advertise this is typically more power consuming than advertising. (Power consumption is the reason most small power limited devices acts as peripherals and advertise, while larger less power constrained devices typically acts as centrals that scan etc).

RE: BLE Advertising Power Management

ksrinidhi — Wed, 11 Dec 2024 22:55:31 GMT

Could I, for example, read RSSI values from devices around me in firmware?

RE: BLE Advertising Power Management

Einar Thorsrud — Wed, 11 Dec 2024 11:49:15 GMT

What do you have in mind? The nRF can only wake up on something internal or physically connected to it. Internal would typically be the RTC, which is what wakes it up regularily for advertising or other regular or scheduled events. External could be a GPIO configured as interrupt source or similar.

RE: BLE Advertising Power Management

ksrinidhi — Tue, 10 Dec 2024 20:29:57 GMT

Beautiful!! I got the "stop checking every 20 ms" part but was there an alternate wake up option?

RE: BLE Advertising Power Management

hmolesworth — Sat, 07 Dec 2024 01:38:51 GMT

There are other issues with the fast-advertising, slow back-off advertisement period algorithm in common use; consider the case where the gateway remains on the periphery of the area where connection is reliable, perhaps because the gateway (maybe a phone) is in a patient's back pocket. Continuous disconnect-connects occur, and so the battery gets exhausted as the 20mSec advertising never stops between each disconnect-connect event.

Reminds me of a similar issue where sophisticated sensors along streets and roads were in low-power mode (so very long battery life) except when woken by an infra-red communication beam from a passing data collection unit. Batteries were expected to last for years, yet they all failed within a month or two. The cause? Sunlight modulated by soft winds agitating tree leaves. The fix? Stop checking incident beam signals every 20mSecs. The moral? Been there, done that.

RE: BLE Advertising Power Management

ksrinidhi — Sat, 07 Dec 2024 00:58:15 GMT

This is interesting perspective

Our analysis showed average current of ~300 uA when measured over a 30 second advertising interval. Even if the advertising period is 20ms per sec, it seems to add up quickly. But the idea of short but relatively frequent advertisement pings could work. Yes, I agree reconnection duration is not the issue here.

RE: BLE Advertising Power Management

hmolesworth — Sat, 07 Dec 2024 00:47:02 GMT

A separate view - we have an almost identical medical wearable device - is that no-one really cares about how long a reconnection will take place if the gateway moves away and sometime later moves back in range; 20mSec or several seconds, irrelevant. Hence just continually advertise (say) once per second; this is very power-efficient and worst case with congested advertising channels due to other devices a slightly longer period before reconnection.

This assumes both sufficient internal data storage for the connection gap with gateway and that the gateway is not supporting (say) real-time display of brain waves without which the patient might expire.

Bottom line is a once-per-second advertising scheme uses a tiny fraction of available battery power compared with CPU wakeups and analogue data acquisition and subsequent local data storage, the latter perhaps using high-current flash writes.

RE: BLE Advertising Power Management

ksrinidhi — Sat, 07 Dec 2024 00:26:45 GMT

Thanks Einar. The document seems to suggest that advertising to start from 20ms and increase upto ~1.3s in duration but with some very specific intermediate intervals. Would you know what is the motivation for those specific intervals?

RE: BLE Advertising Power Management

Einar Thorsrud — Fri, 06 Dec 2024 14:02:23 GMT

Hi,

The most power efficient way is advertising (the other would be scanning if the other device advertises, but this will be less power efficient.

The task is to find the best compromise between the time it takes for the central to connect when in range and power optimization. A typical way to solve this is to advertise with a short avdvertising interval right after disconnect, to make re-connection fast, and then move to slower (higher interva) advertising that on average increases the time to reconnect, but also reduces power consumption (you could also have several "steps" here). This is very application specific though, so you need to find a compromsie that work well for your specific product. (You can refer to Apple's Accessory Design Guidelines for Apple Devices for suggested intervals).