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.
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'm new with the beacon technology and I have some doubts. What is the difference between ibeacon and eddystone format? I want develop an indoor navigation app with beacons in Android. I read some articles that ibeacon protocol is better for indoor navigation. It is true? Why?
When used on Android there is no advantage for indoor navigation apps for either format. Both use Bluetooth LE advertisements with a different byte and identifier sequence.
The iBeacon format has advantages on iOS in that you can detect the packets quickly in the background, where as with Eddystone you cannot. But this difference only applies to iOS. If you are working only with Android, there is no such disadvantage.
for more understanding refer this two links just to interact with android and ios device .both can transmit and receive information like Range proximity etc.
iOS
https://github.com/AltBeacon/ios-beacon-tools
Android
https://github.com/AltBeacon/android-beacon-library
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).
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 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.