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.
Related
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).
If an environment has many BLE devices (200 to 500) advertising within range of a mobile device that is scanning for BLE devices, will the mobile device be able to see all of the advertising BLE devices? Does anyone know of actual testing that has been done on this scenario and can provide results of the testing?
There is no simple answer I am afraid. Assuming all advertizing devices are within a range (i.e. good RSSI), there are many factors affecting reception including: duty cycle of the scanner and broadcast interval of the beacons; you could also choose to use certain channels for groups of advertizers etc. Say the scanner is running flat out (100% duty cycle) and you start from sporadic broadcasts on all channels, gradually increasing the rate at which adverts are broadcast. At some point, you will hit a sweet spot -- increasing advert rate beyond will result in more collisions and poorer detection performance. (It's like being in a room full of people, all talking over each other, all repeating the same utterance over and over again.) The question is not so much "how many advertizers?" one can have but rather "how reliably can the advertizers be heard within a certain timeframe?" e.g. under which conditions can one detect an advertizer with 95% probability within 5 seconds.
If you can deploy multiple scanners (especially if they are spatially separated), then you will gain by collating their output. Based on one particular experiment I carried out using two scanners: 4% adverts were received only by scanner #1, 2% only by scanner #2, and 4% were not received at all. So #1 scanner alone received 94%, #2 alone 92%, but together they received 96% of the adverts.
Here is some related work I found Bluetooth beacon density maximum.
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 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.