My goal is to provide a new means of communication to merchants. These merchants will seize their ads on a platform and the beacons will take care of "spreading" them.
The mobile application will therefore scan the beacons on the background (the most frequent case) and retrieve merchants' ads based on the ids of the discovered beacons. So I need a very regular scan so that no ads are missed.
I have already done a big part of the development however I do not know how to configure the periods of scans.
What optimal configuration would you advise me for this case ?
Currently the application to this configuration in background: setBackgroundScanPeriod(2000L); setBackgroundBetweenScanPeriod(0L);
The foreground setting is the default setting. So I scan for two seconds and then start again immediately.
Thank you in advance and sorry for my english.
The default settings of the AndroidBeaconLibrary are already optimized for fast background detections on Android 5+ devices when using the BackgroundPowerSaver.
When no beacons have yet been detected, the library will do a constant low-power scan for beacons when in the background. This yields detections within 5 seconds on tested Nexus or Pixel devices.
This relies on hardware filters which do not work on Android 4.3 and 4.4 devices and will not work if beacons are already in the vicinity. For these cases, background scanning falls back to cycles of 10 seconds scanning every 3000 seconds.
While you are welcome to increase the on/off cycle rate from 10/3000 to something more frequent, the 2000/0 ratio you suggest will drain the battery on users devices noticably, so I recommend against it.
The defaults are designed to give optimal performance for most use cases.
It entirely depends on the capability of the device and importantly how much battery do you not mind draining. The faster the polling the more draining of the device battery. You also have to keep in mind that the iBeacons also have a interval of sending scans which also drains battery.
For example I have set some iBeacons to a frequency of 900ms and they still are at 100% battery after 1 week. So it seems like you can max out the iBeacons, but as the android application goes you have to see how the battery drainage goes with higher polling rates.
Related
Do the "setForegroundScanPeriod" and "setForegroundBetweenScanPeriod" in the AltBeacon library match to the Scan Window and Scan Interval of the BLE standard? Also, does this refer to a scan event for each of the 3 advertising channels or will a scan of the 3 channels occur in a scan window?
I have a beacon advertising on a single channel (CH39) every 400ms and want to set my scan window and scan interval appropriately to ensure a maximum packet reception rate with those two options that Android let you control.
I am also open to try other suggestions for that matter.
Thanks,
The setForegroundScanPeriod and setForegroundBetweenScanPeriod settings of the Android Beacon Library are a high-level concept designed to control:
battery usage
The BLE scan will be stopped during the foregroundBetweenScanPeriod, allowing you to duty cycle the scanning to save battery. This is typically set to 0 for the foreground and a much higher value (say 5-15 minutes) for the equivalent background setting. The Background setting applies when the app is not in the foreground or the screen is off, and the Foreground setting applies when the app is visible on an illuminated screen.
beacon search intervals
By default, the foregroundScanInterval is set to 1100ms. This means that the library will look for beacons for 1100ms, keep track of the distinct list of all it detects in that period, then report them to the application using the library at the end of that interval (e.g. every 1100ms). This is similar to what iOS does with its CoreLocation API at a rate of 1000ms. The reason it defaults to 1100 instead of 1000 is because many early Android devices with BLE support could not detect more than one distinct advertisement per scan, so scanning had to be stopped every cycle and restarted to detect one again. The default cycle was set to be slightly more than 1000ms to avoid being closely synchronized with beacons advertising at a 1Hz rate.
The library's settings are not the same thing as the ScanWindow and ScanInterval of the BLE Standard. The library's settings are a much higher level concept.
The BLE standard concepts of ScanInterval and ScanWindow, as you state, control how quickly a device doing a BLE scan rotates between listening on each of the distinct BLE advertising channels. Unfortunately, Android APIs give you no direct control over these intervals -- they are baked into the firmware by the Android manufacturer. Further, Android gives you no APIs to determine what these are set to, or even which advertising channel the receiver was set to when an advertising packet was detected (something that has unfortunate impacts on RSSI measurements, see below.) The limited scan settings provided by Android are visible here. The SCAN_MODE_LOW_POWER vs. SCAN_MODE_LOW_LATENCY may affect these intervals (they do in the open source Android code), but again, Android manufacturers may adjust this at will. The Android Beacon Library generally uses SCAN_MODE_LOW_LATENCY except in specific background mode states.
In general, these BLE-Standard settings baked into the Android firmware will be different compared to the library's settings mentioned above. (The BLE spec says the ScanInterval can range from 2.5 ms to 10,240 ms) The periods, however, vary quite a bit between different Android models. You can see the open source Android definitions in this answer, which set the ScanInterval to 5000ms for SCAN_MODE_LOW_LATENCY, but keep in mind that each manufacturer may adjust the constants to their own liking.
Because the RSSI of an advertisement detection varies a small but significant amount between each advertising channel, you can usually derive the hard-coded ScanInterval of an Android device by plotting the RSSI of advertisements detected on an Android device from an advertiser that uses all advertising channels. Plotting this on a graph of RSSI vs. time will show a stair step pattern, where the width of each step is equal to the ScanInterval. On Samsung devices, the ScanInterval is close to the max allowed by the spec at about 10 seconds. My anecdotal testing suggests the baked-in setting from devices by other manufacturers are typically shorter.
The inability to control the channel hopping rate on Android means that 2/3 of your advertisements will not be detected, and on Samsung devices, you will typically go 20 seconds without any detections.
We want to incorporate beacon technology in our apps to create user engagement with screen-off events.
In the present use case, we assume that the end-user will be in constant movement.
So far, we have tested two different approaches.
Kontakt SDK/Android Beacon Library in order to be constantly scanning for beacons. Using the UUID (assuming we are using Eddystone), we can associate it with a cached message that we have retrieved for our back-end. However this ends up eating a lot of battery.
Nearby Messages/Nearby Awareness this had potential, since it has a beacon dashboard to easily configure the attachments on each beacon and it has the "same" implementation on both iOS and Android. However, after reading the documentation and after numerous tests, we could not retrieve beacon attachments if we had the screen off. The only possible way was for the user to be still in front of the beacon for 3 minutes (depending on the smart-phone and energy settings) and it goes against our premise that the user is in constant movement, so the scan might be triggered when the user is not near the beacon.
Also: using Nearby Messages on iOS we had the desired behaviour: the app would discover the beacons when using the Nearby Messages if both the app and the API was configured for background usage.
Thus, we ask:
Is there a way to use Nearby API with screen-off events? Like constantly scheduling a scan?
What other alternatives do we have, that can be used cross-platform between iOS and Android? (so that we can try to assure a similar behaviour between platforms)
EDIT:
Upon further reading, we came to the conclusion that BLE beacon scanning causes minimal impact on the battery when used correctly (emphasis on the correctly, we will have to change the heuristics on our side), see : this.
The question then remains: why can't we have background scans in the nearby api without Nearby Messages own notifications, so that we can assert that the user passed near a beacon? What intrigued us is that this works just fine on iOS...
The Nearby API scans on a schedule of its choosing, including screen on events. You do not have the flexibility of customizing Nearby scanning rules for your app, as it is designed to be a service that runs for all apps on the phone. When using Nearby, you must accept this limitation.
The Android Beacon Library is open source and allows flexible configurations of when you scan. If you find your configuration uses too much battery for your use case you can adjust this. The default settings have been designed for a good tradeoff between power usage and quick detection, so these are recommended. If you find the default settings don't work for you there are many different ways you can set it up. The simplest way is by adjusting its scanPeriod and betweenScanPeriod for the background. But there are many other ways to customize its scanning behavior.
You should note, however, that a "constantly scheduling a scan" (as mentioned in your question) will use up a lot of power if in low latency mode. The Android Beacon library default is to do a constant scan in low power mode, when the app is in the background and no beacons are around. On most devices, this yields detections within 5 seconds and reasonable power usage similar to cell standby.
It's hard to offer more suggestions without knowing the configuration you used with the Android Beacon Library, the test conditions in place, and how much power consumption was witnessed. If you can provide this information, I might be able to help more.
Full disclosure: I am the lead developer on the Android Beacon Library open source project.
I was trying to test battery consumption caused by Android and IOS beacon detector application for different beacon protocols and advertisement rates. My question is that will the advertisement rate of beacons in anyway affect the battery consumption of detector applications? These applications scan for a fixed amount of time and after a fixed interval, will different advertisement rates have any effect?
Thanks
Yes, in most cases an app that detects more beacons will use somewhat more battery than one that detects fewer beacons. While this is true on both iOS and Android and for Eddystone/AltBeacon/iBeacon, the details vary for each combinations.
Two reasons for detecting more beacons using more battery on the receiver side:
It takes more CPU power to decode each beacon packet from an array of bytes into useful fields and then trigger the app to do something useful with it. The more packets that need to be decoded, the more CPU (and battery power) that is used.
If an app is woken up in the background when it detects beacons, more frequent wake ups will cause the app to run in the background more often, again burning more CPU and battery.
On both iOS 7+ with iBeacon and Android 5+ (with the Android Beacon Library), bluetooth hardware filters are used to mitigate the effects of (1) when no beacon apps are actively ranging, but instead just monitoring for detections in the background. This is not true with Eddystone or AltBeacon formats on iOS, because they generally cannot use the hardware filters effectively. These formats may use a bit more battery power in the background on iOS when simply looking for detections in the background.
The good news is that the only time this extra battery usage really comes into play is when you are constantly ranging (scanning) many beacons for long periods of time, and most of this extra battery usage is for just doing the scanning at all. If your app is constantly scanning for many minutes or hours at a time you will see a significant battery hit. And if it does so with 100 beacons around instead of one, you will see an even bigger battery hit still.
I noticed that the signal strength of Bluetooth Low Energy received on Androids is varying in cycles.
The graph below represents the RSSI values of one BLE beacon over two minutes. The receiving Android and the beacon were both static with a distance of 1 meter. I made sure that there is as low interference as possible. The Android was a Nexus 5, but I had the same phenomenon with other Android devices, all running on API 21. I could not test it on iOS yet.
RSSI Graph
You can see that there are 3 major levels for the RSSI repeating every 15 seconds, like low -> middle -> high -> low -> middle -> high etc.
My guess is that the reason lies on the android side, not sure whether it is because of hardware or software reasons.
Why is the RSSI cyclic over time? Can someone explain?
After reading a lot into the topic now, I might have come to an answer.
Bluetooth Low Energy beacons use three different channels for advertising, which is their adaption of frequency hopping to avoid interference with other 2.4GHz signals. This happens much slower than for normal Bluetooth (1600/s) - according to my measurements around every 5 seconds.
More here:
http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/
The received signal strength depends obviously on the frequency, so if the frequency changes to another channel, the RSSI is different. How to deal with that is now a different question.
UPDATE:
After following up on this issue, I have to update my remarks:
It is very likely that the three levels with each one around 5s are not directly due to the beacons slow frequency hopping, but to the android devices scanning seperately on the channels and switching to the next after such a time interval.
A way to overcome this behavior is starting and stopping the scan process in a loop, so that a scan lasts clearly less than 5s. When starting the scan, the device seems to begin scanning always on the same channel and the scan is restarted before it can switch to a different channel. With the restarts, the pattern is not detectable anymore - to the disadvantage that the channel is "fixed" and may suffer interference on this frequency.
Thanks to Airsource Ltd for bringing me back to this question.
As per Android AOSP - Definition of scan interval and scan window in android source code the scan interval in any scanning mode is 5000ms.
I would assume that your graph was generated via an application that used continuous scanning - i.e. scan window of 5000ms, which is basically continuous.
The scanner will rotate between channels 37,38,39 after every scan interval, which accounts for the differences you observe. Channels 37,38,39 are not contiguous in the BLE spectrum - 37 is at 2402Mz whereas 39 is at 2480Mz. The difference in wave length means that the multi path (interference from reflections) fade will be different for each channel http://www.cl.cam.ac.uk/~rmf25/papers/BLE.pdf - you say that the devices were static, so provided that nothing else was moving, the interference will also be static.
On iOS, the scan interval (foreground) is reportedly 40ms which means that you should not experience this precise effect.
The Google Fit app, when installed, measures the duration you are walking or running, and also the number of steps all the time. However, strangely, using it does not seem to drain the battery. Other apps like Moves which seems to record number of steps pretty accurately declares that it uses a lot of power because of it constantly monitoring the GPS and the accelerometer.
I imagine several possibilities:
Wakes up the phone every minute or so, then analyses the sensors for a few seconds and then sleeps again. However it seems that the records are pretty accurate to the minute, so the waking up must be frequent.
Actually turns on the accelerometer all the time, and analyzes it only after the accelerometer measurement data buffer is full. However I think the accelerometer has a small buffer to store the latest measurements.
Use GPS to estimate the number of steps instead of actually counting it. However this should not be the case, since it works even indoors.
The app still feels magical. Counting steps the whole time without perceptible battery drain.
Thanks for asking this question!
Battery is one of our top most concerns and we work hard to optimize Google Fit's battery usage and provide a magical experience.
Google Fit uses a mix of sensors(Accelerometer, Step counter, Significant Motion counter), Machine Learning and heuristics to get the data right. Our algorithm is pretty similar to your 1st option plus a little bit of magic.
We periodically poll accelerometer and use Machine Learning and heuristics to correctly identify the activity and duration.
For devices with hardware step counters, we use these step counters to monitor step counts. For older devices, we use the activity detected to predict the right number of steps.
Our algorithms merge these activities, steps and sometimes location to correlate and further increase accuracy.
We do not poll GPS to estimate steps or detect activities.
-- Engineer on Google Fit Team.
On some very recent phones like the Nexus 5 (released in late 2013 with Android 4.4 KitKat), there is a dedicated low-power CPU core that can serve as a pedometer. Since this core consumes very little power and can compute steps by itself without the need for the entire CPU or the GPS, overall battery use is reduced greatly. On the recent iPhones, there is a similar microcontroller called the M7 coprocessor in the iPhone 5s and the M8 in the iPhone 6.
More information here:
https://developer.android.com/about/versions/kitkat.html
http://nexus5.wonderhowto.com/how-to/your-nexus-5-has-real-pedometer-built-in-heres-you-use-0151267/
http://www.androidbeat.com/2014/01/pedometer-nexus5-hardware-count-steps-walked/
having a 3 year old HTC OneX I can say that THERE IS NO DEDICATED HARDWARE, Google Fit just uses standard sensors in a very clever way. I come from Runtastic Pedometer: there is a clear battery consume when in use, it would be impossible to keep it on all the time as it needs the full accelerometer power. On the other side, if you stand still and shake the phone Runtastic will count the shakes, while Google Fit apparently does nothing... Still it works perfectly when you actually walk or run. Magic.
Google fit try to learn use pedo step pattern and try to create its own personal walking patterns and its clusters. This eliminates the need of having huge mathematics calculations on receiving sensor data every time. This makes Google fit more power efficient compared other software pedo apps. Having said that, there is compromise on accuracy factors here. Between power-accuracy trade off, google seems to be more aligned towards power factor here.
At this moment the most power efficient detection happens Samsung flagship & its other high end models. Thanks to Samsung's dedicated hardware chip! No matter how power efficient your software pedo algorithm be but its hard to beat dedicated hardware unit advantage. I also heard about Google's bringing dedicated hardware unit for Ped upcoming nexus devices.
It would seem like the solution would be device dependent, with devices where a co-motion processor or "wimpier" core is available for low power operations, that it would default to this once the buffer is full or similar condition. With devices where a low-power core is not available, it seems like waking the device could trigger a JIT operation that would/should finish by the time the app is called.
While the Nexus 5 does have a dedicated "low-power" pedometer built in. It isn't as "low power" as you might think.
My Nexus 5 battery life was decreased by about 25% when I had Google Fit Activity Detection switched on.
Also, the pedometer doesn't show up in the battery usage stats. Presumably, because it is a hardware thing.
I don't know for the other phones out there, but Google Fit was really draining my battery life on my Nexus 5. Disabling it definitely improved my battery life.