According to the documentation of Android Beacon Library,
Fast background detections on Android 5.0+
On Android 5.0, new scanning APIs allow for more efficient background scanning that saves provide similar power savings to the technique described above, but with much faster beacon detection times. Instead of it taking up to five minutes to detect a beacon (with the defaults described above), it detections of new beacons generally take place within a few seconds.
But looking at Android's official documentation, the major new thing that I can find is this BlueToothLeScanner which is introduced in API 21.
This documentation of this new class does not mention anything about using less energy.
Assuming Android Beacon Library is also using these frameworks, why will it save more energy?
i.e. Does the handling of this library have any difference from calling startScan() in my own app, without using this library?
Android 5 introduced new scanning APIs supporting scan filters, which look for a byte pattern in a BLE advertisement packet. These filters are designed for Bluetooth chips that implement these filters in hardware. This means the Bluetooth chips will offload all of the processing until there is a match, and only then send the packet to the operating system. This is much more efficient from a battery perspective. My own tests on a Nexus 5 when scan filters were introduced showed that filters used <10% the battery of an unfiltered scan. Newer generation chips on newer phones have gotten even more efficient.
In the API prior to Lollipop, there was no scan window / interval setting. The parameters used were hardcoded to 5000/5000 which means the radio is on all the time listening for incoming advertisements.
With the new API you can set the scan window / interval to "balanced" which will use the parameters 500/5000 or similar. That requires 10% energy compared to when the radio is active 100%!
The new API also have methods so that packet filtering can be done in the Bluetooth chip rather than the main CPU. This could reduce the power a bit but I think this will only be significant in noisy areas (many advertisers).
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.
I know every device transmits bluetooth at a different frequency. Any way to change the frequency. I want to change the frequency of BLE specifiaclly.
Given that the radio technology used in Bluetooth Low Energy is known as frequency hopping the answer is NO not as a developer as that belongs to the BLE driver level.
Realize that the range frequencies used to communicate between devices are collectively grouped into channels and that Bluetooth can switch between channels at 1600 hops per second so the notion of a third-party app being able to modify a lower level protocol seems undesirable as simply a security and separation of concerns matter.
Update
is it possible to change it at a device level. when i add a Bluetooth component(peripheral) to the device
Without more detail as to what and how you want to change the radio, I can't say. However:
What if I'm building the device from scratch
You'll need to learn how to read a datasheet which is provided by the chip/peripheral manufacturer. The datasheet will provide detailed physical connection information and details about the wire/software protocols necessary for operation. The datasheet for a chipset is roughly the API to the hardware, generally obtainable by using your favorite search tool, so if you do have a specific modification in mind, the datasheet should inform what is possible or not.
At this point you are at a level below the types of programming questions that StackOverflow normally operates at and should look to: https://arduino.stackexchange.com/ or https://raspberrypi.stackexchange.com/ or https://electronics.stackexchange.com/
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.
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.
when beacon is more useful in ble application in android?
What are the benefits to use beacon ,is i know we can customize background scan rate. but using normal ble also we can change background scan rate by using SCAN_MODE_LOW_POWER and other flags. both will decrease the scan period.
can anyone explain these
Beacons as a specialized version of a Bluetooth LE device. They are designed as transmit-only devices that simply send out a unique identifier at regular intervals, typically at 1-10 Hz. Beacons send out these identifiers using Bluetooth LE Advertisements, a feature which is a relatively small subset of the Bluetooth 4.0 specification.
Beacon-specific Android libraries like the Android Beacon Library are designed to focus on the use case of detecting Bluetooth LE beacons as opposed to doing more general purpose Bluetooth LE operations. A beacon library adds logic on top of built-in Android BLE Scanning including:
Parsing of beacon identifiers from raw BLE advertisements, based on different beacon formats (Eddystone, AltBeacon, iBeacon, etc.)
Event-driven APIs to tell you when a specific beacon identifier pattern is first seen and then stops being seen.
Regular callbacks (e.g. once per second) telling you a list of which beacons are visible.
Distance estimates to beacons.
Automatic switching of scan intervals as the app switches from the foreground to the background.
Automatic wakeup of the app when beacons are detected.
While it is possible to do all of the above with the lower-level Bluetooth LE APIs in Android, you have to write a lot of code to build these features yourself. Using a beacon library allows you to focus on your App's business logic and leave the complexities of dealing with the beacon parsing and detection functions to somebody else.
Full disclosure: I am the lead developer on the Android Beacon Library open source project.