I only need a rough guide on this really at this point, though specific calculations would obviously be welcome too!
I'm looking at using Radius Network's Android iBeacon Library in an app which will listen for iBeacon advertisements.
I'm new to this but from what I understand it's the scanning for BT devices which is the most battery intensive part of the BLE system so it's not advised to have this running constantly, however I would like to be able to 'catch' devices when they are in a certain area, i.e. a person walking through a lobby.
The Android Beacon Lib's documentation states that the Battery Manager's default setting scans for 30 seconds every 5 minutes (actively scanning for 10% of the time) and this reduces the battery drain on a Nexus 5 from roughly 90mA to 37mA.
My question is... would scanning for 3 seconds every 30 seconds (also 10% of the time) acieve the same battery savings? Or is there an overhead involved in starting the scanning process which would mean the savings would be less? and if so by how much?
You would have to measure to be sure, but I would suspect you would get similar power savings from the cycle you describe (it may be slightly less savings because of startup overhead as you suggest.)
The disadvantage of this approach is that you may miss detections in a 3 second interval, especially in areas with lots of beacons, distant beacons, or with beacons transmitting infrequently. You have to decide if it is worth the tradeoff.
To test power savings, do the following:
On a test device, uninstall as many apps as possible to limit background activity that might use power in unpredicatble ways.
Install an app that implements background scanning on the cycle you describe and start it on your device.
Charge the battery to 100℅
Turn off WiFi and mobile data to prevent system downloads from using power in unpredictable ways.
Note the time, turn off the screen, and let the device rest, checking it every hour or so for battery level.
When the battery reaches 5%, note the time.
Repeat the above test with the app doing a constant scan in the background.
The end result of the above procedure will give you the time it took to drain the battery in both cases. From this you can calculate the percentage difference in power savings.
Please let us know what you find!
Related
I wish to use for my app ActivityRecognitionClient, and I wish it will run always in the background. But how much battery actually it consume and what is the best interval for battery optimization?
In the reference it only says
"Larger values will result in fewer activity detections while improving battery life. Smaller values will result in more frequent activity detections but will consume more power since the device must be woken up more frequently"
Can you tell me in real life how much it will consume per refresh rate?
It is nearly impossible to correctly answer this question because the answer is a resounding "it depends."
The amount of battery power that a particular action will consume on a phone is difficult to determine because there are a ton of different factors that play into it.
First, Android attempts to batch many types of requests such as this together, so if 10 different apps wants to detect updates ever 5 minutes, it will only do it once every 5 minutes instead of 10 times every 5 minutes. Which app and which action is responsible for that?
Second, activity detection relies on whatever sensors (and models of sensors) are available on the device. Different devices have different GPS chips, accelerometer chips, etc. Some devices may not have all of those types of sensors as well. These all change the amount of energy activity recognition will consume.
These are just a few of the reasons it is difficult to determine how much energy an update will consume.
The answer for "how often should I request updates" is "as infrequently as your app can tolerate." Think about your use case and the general statement that more frequent updates will consume more power, and make the appropriate decision from there.
I'm playing around with the AltBeacon and these parameters. My goal is to have the fastest (as fast as possible) callback didRangeBeaconsInRegion().
I understand that ranging uses running average to calculate the distance and make the callback. I'm not interested in the distance, but the rssi. With that said, if the rssi is varied by 1 that's ok.
In my current code, I currently use:
RangedBeacon.setSampleExpirationMilliseconds(1000);
try
{
mBeaconManager.setForegroundScanPeriod(700l);
mBeaconManager.setForegroundBetweenScanPeriod(0l);
mBeaconManager.updateScanPeriods();
}
catch(RemoteException ex)
{
...
}
My app is in foreground all the time. Running on Nexus 5X.
I notice that the smaller the value for setSampleExpirationMilliseconds(), the more frequent I get the didRangeBeaconsInRegion() callback, which is good. The setForegroundBetweenScanPeriod is set to 0 which means the service always scans all the time.
In my venue, I have about 30 beacons deployed. With the above code setup, I get callbacks every second, each time a different set of beacons.
The problem is even when I stand right next to a beacon, that beacon is not heard every 1 or less second. When I get the callback, it's usually for other far away beacons. There are times that it takes a good 30 seconds for me to hear that particular beacon to which I'm standing next again.
I know that the beacon we setup chirps every 20ms, so during that 700 ms, I should see them.
I notice that if I raise the setForegroundScanPeriod to 5000 (I hope the scan period to be longer so I can get the nearby beacons), I get less callbacks. The delay between callbacks is about 10 seconds. So I think a smaller value means faster callback.
My questions:
Why don't I get all the beacons in the callback (they all chirp at 20ms)? How is the callback called? When it has enough info, or it has some kind of interval? What controls it?
Is there any relationship between setSampleExpirationMilliseconds, setForegroundScanPeriod, and setForegroundScanPeriod? How to make them work well together?
My app requires that I should hear a nearby beacon (3ft or less) within less than a second, how to best setup the parameters to achieve this?
Thanks for reading such a long question. Appreciate any insights.
#davidgyoung maybe you could shed some light?
The Android Beacon Library isn't designed to give you a callback for every beacon packet detected, but rather to give you regular callbacks at some configured interval to let you know beacons are still around. By default, this interval is 1100 ms in the foreground, which is configured by
setForegroundScanPeriod(1100l);
setForegroundBetweenScanPeriod(0l);
As soon as the scan period ends, a list of beacon detected in the scan period are returned in a list via the didRangeBeaconsInRegion callback.
You can get faster callbacks by setting a shorter scan period. To get callbacks every 500ms, setForegroundScanPeriod(500l); The disadvantage of this is that this stops and restarts BLE scans at the end of each scan period. (Stopping and restarting is necessary for some Android phone models that can only detect one packet per unique bluetooth MAC address in a single scan cycle.) But whenever you stop and restart scanning, you will miss any packets that are being transmitted at that exact time -- it's akin to shutting off the bluetooth radio in the middle of the packet. This leads to a higher percentage of missed packet detections the shorter the scan period.
This may be OK for your use case, provided that the beacon is transmitting every 20ms -- with a 500ms scan interval, you have plenty of samples to ensure a detection.
The setSampleExpirationMilliseconds parameter is largely unrelated to what you are trying to do. It is used for distance estimates when using the default RunningAverageRssiFilter. This setting decides how long to average RSSI measurements for distance estimating purposes. By default, it retains 20 seconds worth of RSSI samples, which affects the results of getDistance() method on Beacon.
We are using AltBeacon for detecting regions in the background. For an important use case of the project we absolutely need to have a lot of very small regions (basically one beacon with minimum transmitting power is the whole region) and very close to each other.
With this beacon setup, we get notified at each region event, but the enter region events are triggered earlier than we would like them to do, usually happening when we walk in a 10m radius of the beacon (representing the region). Our goal is to at least cut this distance in half.
I understand that this use case is not an ideal one for region monitoring, but it is essential that it works this way.
Is it possible to set a minimum distance for getting notified on enter region events?
A possible solution we are starting to test is to always do ranging (even on the background), overriding the default foreground scan periods to something resembling background monitoring. Our worries are that the distances might not be reliable (due to the scans not happening all the time and the minimum beacon power settings) and that the battery consumption might be higher than an equally frequent monitoring. Any thoughts on this approach?
You can use
onReadRemoteRssi . This measures the signal strength in dB and you can approximate the distance by it. Keep in mind that it is not accurate and you have to test it. I've tried something like this but there were some peak values like a noise and you should filter them. Here is one example
The Ranging and Monitoring APIs are abstract concepts applied to detecting beacon packets. As you have found for your use case, neither concept fits perfectly.
What you want is two things at the same time:
Logic triggered on a short distance from a specific beacon (like Ranging)
Battery friendly detections (like Monitoring)
Unfortunately, to estimate distance, you must do constant Bluetooth scans as is typically done for ranging in the foreground. These constant scans do use more battery.
Depending on your use case it may be possible to do constant ranging in the background but only or a limited time. This should give you acceptable distance estimates for that period. You could decide when to start this (e.g. first beacon detection) and continue only as long as beacons are detected or for a maximum time interval, say 10 minutes. If you can limit the time, the battery usage may be acceptable.
my client wants an application which essentially uses all these all the time i.e. in a background service:
- network/wifi
- location service
- BLE scanning
Which means this has a big effect on the battery life. According to my measures it can lower your battery more than 10% per hour this way.
What would be the best way to lower energy consumption, and which one of the three services would consume the most power? The location service only gets updated if the user location changes significantly (can happen while travelling), and there is constant client-server communication going on in the background.
And the whole idea is that BLE is constantly scanning. What would be the best way to handle this situation?
Why would you need to be constantly scanning? A better solution would be to scan for short time intervals (for example 2 seconds) every 5, 10, 20 or more seconds. You get the idea.
I highly doubt that the available devices would change faster than this and if they do, you most likely won't be able to connect to them.
Brief process of how AltBeacon works in the app:
Detect iBeacon of specified ids (UUID, major/minor id)
Run a thread when "didEnterRegion" called (and keep running until the
beacon is out of range)
When "didExitRegion" called, wait 30 seconds before stop the thread
(this is to assure that the beacon is definitely out of the range)
Continue to run the thread when "didEnterRegion" called again during
the 30 seconds delay and stop the thread, otherwise.
And I found some reliability problems:
"didExitRegion" is frequently called even when a iBeacon is right besides the app.
Once "didExitRegion" is called, it takes several seconds, even more than a minute sometimes, to re-scan the iBeacon even with having a
very short scanning period setting.
My objective is to run a thread until a beacon is definitely out of a range -- in other words, I would like to secure the high reliability of the app with iBeacon integration.
Any suggestions? Am I missing something?
Any insight from you will be greatly appreciated!
Regards,
The problems described typically happen with a beacon that is not advertising frequently enough. A standard iBeacon transmits every 100 ms (10 Hz). Many beacon manufacturers try to extend battery life by slowing down advertisements to be much less than this standard.
The Android Beacon Library is designed to work properly with beacons advertising every 1000 ms (1 Hz). It has a scan cycle of 1.1 seconds, giving it a high probability of detecting a beacon transmitting every one second or more.
But some manufacturers claim long battery life by reducing the transmission rate to once every 5 seconds or less. This will cause the exact symptoms described, because the library will intermittently fail to detect the beacon, causing spurious exit and enter events.
To solve this, consult the documentation for your beacon and configure it to transmit at least once per second or faster.