BLE Advertising Power Management

[ksrinidhi]

Looking for suggestions for power management on a product

We have a wearable that needs to periodically sync data to the cloud through a gateway. Currently the wearable advertises periodically, connects with the gateway and all is good. Well, most of the time... However, it is possible that gateway is not in the range when the advertising happens. We can create some heuristics on next advertising window but we really need to manage power extremely carefully. There is an absolute requirement that data sync should happen with no user intervention expectations. 

Any suggestions on how the wearable can determine that the gateway is in the range before it starts to advertise?

[Einar Thorsrud]

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).

[ksrinidhi]

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? 

[hmolesworth]

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.

[ksrinidhi]

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.

[hmolesworth]

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.