need some power planning guidance

[rexxdad]

we have a device whos active time will be 5 minutes once a month 

we have done some preliminary work on saving power. 

the device scans for the app, before advertising. 

the app advertises its presence, then scans for the devices in a room, after waiting for some amount of time

when the app is done, it goes away, and the device stops advertising, until the next time the app shows up 

now, we want the 'delay' from app on to devices detected to be 'low', responsive, guess 15 seconds too long, 5 seconds about right.. 
as is typical, the device might have stopped active scanning just before the app appears., so the delay should not be more than 5 seconds.
the app currently scans for 15 seconds, and stops early if it hears no new devices. over a 2 second cycle

but wake up from sleep takes longer to get scanning up and running again ..

but 99.9999 % of the time there is nothing to scan. 

want to run off battery, full power demand is between 150-200ma. for 50% of the 5 minute period. 

scan power demand is 80ma. 

but I cant get wakeup from positive scan (wake on lan type approach), only have BLE available 

any thoughts welcomed..  we will be using the 52833 and 52840 devices. 

[tesc]

Hi,

the device scans for the app, before advertising.

Considering that RX is more expensive power wise than TX, it would in most (if not all) cases be better for the device to advertise directly than to do a scan first.

For your approach to save power, the energy spent during one round of scanning must be less than the energy spent during one round of advertising. Of course, connectable advertising does have a scan window as well, but the time spent in either TX or RX for an advertiser is significantly less than that of a scanner.

In fact, BLE is designed for the Peripheral to spend as little energy as possible (also in the advertising phase), and for the Central to have more energy at its disposal. Reversing roles, therefore, is expected to increase power consumption on the Peripheral, not to reduce it.

now, we want the 'delay' from app on to devices detected to be 'low', responsive, guess 15 seconds too long, 5 seconds about right.. 
as is typical, the device might have stopped active scanning just before the app appears., so the delay should not be more than 5 seconds.

In order for a scanner (central) to connect to an advertiser (peripheral), the typical way is for the central to scan for BLE advertisements until it finds an advertisements from the peripheral it wants to connect to. Then it starts scanning again, but this time with the intent of connecting to the particular peripheral (using the BLE address). Therefore, in order for a connection to succeed, the central must successfully receive at least two advertisements. (One for finding the device, then another one for initiating the connection on.)

The question then becomes, what advertising parameters, and what scan parameters, typically provide connection within 5 seconds?

I would say as high a scan duty cycle as possible, on the central, preferably 100 %. This is not particularly realistic on a smartphone, where you typically have Wi-Fi competing for the same spectrum, but it does provide a best case figure.

For the peripheral, there must be at least 2 advertising events during the 5 second window. This is also a best case figure.

Since there will be packet collisions, and since the central is likely at less than 100 % duty cycle, I would say there must be at least 3-5 advertising events every sliding 5 second window, for establishing a connection within 5 seconds. If you can relax the requirement to 10 seconds, then it would be 3-5 advertising events within a 10 second sliding window. In general, 3-5 advertising events within the interval. Those could be either in a short burst (minimal advertising interval for the full set of 3-5 advertising events, and then a longer pause) or they could be evenly spread apart (e.g. constant 1 second advertising interval, for the 5 second connection time scenario.) These are theoretical numbers, and you should select your final numbers after thorough testing.

want to run off battery, full power demand is between 150-200ma. for 50% of the 5 minute period. 

For estimates of the resulting power consumption for the BLE activity of the peripheral, when advertising and when in connection, you can use the Online Power Profiler for Bluetooth LE. The relevant roles for calculation are "Advertising (TX/RX)" and "Connection (peripheral)". Please note there are several parameters for the calculator, both for advertising and connection, including payload sizes.

Regards,
Terje

[rexxdad]

thanks.. will have to review our design and see if intermittent advertising is better than  limited scan and advertise only when usable.

[rexxdad]

oh, this front phase is NOT connect, just discover.. but the devices are waiting for an app to appear (advertise).
until then they are not advertising,  as such they do not exist , and cannot be found

there is no reason to have devices detectable until the appropriate app is present. 
the room could have 30 or more of our devices present.  no reason to create all that electronic noise.

[tesc]

Hi,

Right. When you put it that way. Please note however, that this approach will result in higher power consumption for those devices, since 1) scanning windows need to be longer than advertising events, and 2) RX uses more power than TX.

Might there be a different approach, for activating the devices, such as e.g. button press, motion sensor, etc.? Would any such method be suitable for your use case? If so, then the device could for instance advertise, quite frequently, for a period of time after activation, before it goes silent (no TX and no RX) until the next activation.

Regards,
Terje

[rexxdad]

no. my users are blind.. so can't find the devices. they may not reachable either, mounted in all kinds of places, and many have no line of sight for a motion sensor.. we don't control the space the devices are in. and there could be up to 32 of them...