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.
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.
first of all i would like to say that beacons seems to be something great and usable, i am very enthusiastic still i saw it for the first time.
Now, i would like to try them and to make an Android app, but i'm confused about some things that i didn't found it clearly on internet:
Are beacons available already?
How much does a beacon cost?
Does it need to be charged ?
How much time can a beacon work without charging?
Do i need to setup every device for interaction with it?
Can i implement beacon in Unity App ?
Is there any tutorials about using it?
I know, post is a little big, but i would be very glad if i will found here answers. Have a nice day! ;)
Are beacons available already?
yes, check out the internet.. radius networks, kontakt.io, estimote etc., you could also hit Alibaba, or buy a raspberry pi and a bluetooth dongle
How much does a beacon cost?
cheap. Small beacons could be as little $1 each, but these have drawbacks like non-replaceable batteries and short range, Bluetooth 5 beacon could be more expensive, but these can cover a 1km radius (personally I think that's pointless). Typically expect around $30 for a "good" or top-tier beacon company's primary beacon choice. If you buy bulk you get cheaper, but you might want to experiment with a few different kinds before you do that. Our company bought like 300 at one stage and we might need to replace them with a different manufacturer now
Does it need to be charged ?
some have replaceable batteries, some are only available to be plugged in, some are just disposable - you need to track that yourself
How much time can a beacon work without charging?
it can't - you may be thinking of NFC here - a Bluetooth radio/antenna requires more power than you might think (but probably less than both of us think to be honest), however it needs a dedicated power source both to transmit and receive data
Do i need to setup every device for interaction with it?
no, you make an app that listens for it. Well.. there are actually lot of options, however, not with straightforward detection/processing. Eddystone promotes a notion of "the Physical Web", which is like using URLs sent by Eddystone beacons to show you the right content, or iPhones actually have more built in support for some (mainly) retail use cases. Android is great because you can do so much in the background, and foreground services give you a lot more say about how and when you are stopped. You should also be aware that 4/5/6/7 all have different caveats around scanning/receiving, but most of the differences will/should be absorbed by any SDK you might use
Can i implement beacon in Unity App ?
certainly, just find a use case (AR/VR and a drone with a beacon for a Dragon? :O)
Is there any tutorials about using it?
so many, google about, but I would recommend starting with Radius Network's Android Beacon Library.(This uses Altbeacon, but is VERY easily changed to work with iBeacon and even Eddystone, also it's free and these guys know their stuff). Also, there are many beacon apps you should download as the consistency is not guaranteed across devices, and a few apps have a few different features that you might want for debugging. Try Locate Beacon (by Radius) NRF Toolbox and basically any other BLE app with a decent score - it can be really good to cross reference the hits when funny stuff starts happening.
A lot of people talk about Beacons and managing them as if it's more complex than it is, you have an object that just screams an ID every X milliseconds, you hear that, you do something with it, once, every X seconds, or whatever you want
I would say you should get very familiar with the difference between BLE/ Bluetooth Smart and regular Bluetooth that interacts via a GATT server. With beacons you're essentially just listening to a peripheral device that advertises in a set format. As the developer, it is up to you to take this and make it meaningful for your user
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.
I am currently developping an Android application that can monitor the signal strength of an iBeacon with the library Android iBeacon Library (http://developer.radiusnetworks.com/ibeacon/android/).
But because we want to use iBeacons with very slow frequency to save battery, I need to be able to increase the frequency for a few minutes to have frequent detections during the signal strength monitoring. The problem is that the library I am using does not seem to provide this functionnality. I searched the web for other libraries that would offer this feature, but I can't find any.
Do you know a library that would let one change the beaconing frequency of an iBeacon? If not, how should I proceed to code it?
My revised understanding of your question is this: You want an Android library that communicates with an iBeacon to dynamically change its advertising rate.
Unfortunately, I think the Android side is the easy part. The hard part is that no iBeacon manufacturers I know of have an open API that allows you to dynamically change the advertising rate. (Although some do let you use an app to configure this rate over a secondary Bluetooth connection. Radius Networks' small USB-powered iBeacons work this way.) Because each vendor's service works differently, you'd have to reverse-engineer how each of their configuration BLE services works.
If you really want to do this, here is how I would approach it:
Build your own custom iBeacon that has a secondary Bluetooth LE service that allows you to connect to the beacon and change its advertising rate. A great way to prototype this would be with an iOS device acting as an iBeacon or with one of my company's iBeacon Development Kits. For an iOS-based beacon, you can write the secondary service in Objective C. For the IDK beacon, you can write the software in any language supported by Linux.
Write custom Android code that connects to the bluetooth service and sets the advertising rate as needed. You could use this alongside the Android iBeacon Library. And as an open-source project, you could always offer to merge your code into it once you have it working. (I'm the guy to talk to!)
Once you have this working, talk to an iBeacon vendor to make custom firmware for a battery-powered beacon that does the exact same thing. Hardware suppliers will tell you how to make custom firmware. This typically requires a proprietary workbench tool and is done in C or in a proprietary scripting language.
Yes! The Android iBeacon Library from Radius Networks Supports this. Below is sample code that changes both the foreground and background scan period to be every 5 minutes. What this means is that the library will spend five minutes doing scanning, and let you know what iBeacons it sees during that time. (The foreground default is 1.1 seconds.)
You can change this frequency as you wish based on some algorithm in your app.
iBeaconManager = IBeaconManager.getInstanceForApplication(this.getApplicationContext());
...
#Override
public void onIBeaconServiceConnect() {
try {
long five_minutes_in_millis = 5*60*1000l;
iBeaconManager.setForegroundScanPeriod(five_minutes_in_millis);
iBeaconManager.setBackgroundScanPeriod(five_minutes_in_millis);
} catch (RemoteException e) {
e.printStackTrace();
}
}
Full disclosure: I am an employee of Radius Networks and the primary author of this library.
I'm looking for a list of all the components and their power drainage on an up-to-date smart phone.
Accelerometer, gyroscope, magnetometer, etc.
Display
WiFi
Bluetooth
GPS
CPU
Camera
Microphone
etc.
Preferably in mA so it can be easily compared to the battery's capacity (usually specified in mAh).
The Sensor's power is actually available via the SDK and can also easily figured out for most devices on AndroidFragmentation. However what I'm looking for is comparable data for the other hardware components to consider their efficency.
Bonus: Will a request for less frequent updates of a Sensor decrease energy consumption of the Sensor, as it returns only one value for getPower()?
There are a couple of detailed studies that I am able to find on this.
A study from the USENIX meeting in 2010 which studies various components of a smartphone (except the camera)
Another study from the Hotmobile mobile computing workshop 2013 that has more information on cameras and displays.
Reference 1 especially seems a great starting point.
I'm looking for a list of all the components and their power drainage on an up-to-date smart phone.
That is impossible to answer.
First, different devices will use different varieties of these components, with different power characteristics.
Second, many, if not most, of those components will have no published power statistics, or the specific components themselves may not be knowable without a complete teardown of a device.
Will a request for less frequent updates of a Sensor decrease energy consumption of the Sensor, as it returns only one value for getPower()?
That will depend on the sensor. Some sensors are effectively always "on" (e.g., ambient light sensor), courtesy of the OS, in which case the only incremental power drain for your use of that sensor will be in passing that sensor data to your process. Other sensors might not be regularly used by the OS, meaning that your request for events from that sensor might turn it "on", resulting in power drain from the sensor itself in addition to supplying you with that data.
It would be truly wonderful if all Android devices were instrumented in the way the Qualcomm MDP is, so that we could get fine-grained power detail for our apps and their usage of various components.
There was a Google I/O session on this very subject a few years ago; you can see the video here and slides pdf here.
I know it's against the rules to plug your own startup, but what you're asking sounds exactly like what we're working on.
There's an Android performance monitoring tool called "Little Eye Labs". It shows real-time power consumption of an App as it runs on a phone. It currently only supports CPU, Display, GPS, Wifi and 3G, but you'll be able to get the instantaneous power consumed (in mW) by these components.
/end of plug
Note that there's no real way to get this information directly from a device, so the best you can do is model the phone, gather device resource consumption, and model power usage.
Display is the most power consuming part of the smartphones; accounting for up to 60% of total battery life (Can draw power up to 2W). There is a book called Green IT and its Applications; you can read it online in Google books.
On any modern Android, go to Settings > Battery (sometimes Settings > About > Battery). You should see a graph of power drain over time, as well as how much was used by what component.
Although consumption varies a lot based on usage patterns, in my experience the top consumers are display, radio, and CPU. I have not seen sensors rank high in energy use on any of my devices, in the absence of bugs. The link provided by Yusuf X places game sensors above CPU.
For more information about optimizing battery use on Android, see Reducing the battery impact of apps that downloads content over a smartphone radio and Optimizing Battery Life.
There is an app called PowerTutor that it does some battery consumption measurements for every phone component and for every process. The code is open so you can pick up some ideas from there. Note that this app was optimized for Google's phone, especially for the Nexus One.