Request for more documentation on scan behavior about android-ibeacon-service

[davidgyoung]

The way the Android bluetooth scanning works, you only get one callback for each unique device that Android sees while the scan is running. If you run a scan for 30 seconds, you will only get one signal strength measurement over that period, and you won't have any way to know if the device disappeared. The only way I can find to get periodic updates about a device is to stop scanning and restart.

The reason I chose 1100 ms as the scan interval is to emulate the iOS callback frequency as much as possible. In iOS, you get an update about an iBeacon every 1000 ms. But stopping scanning and restarting exactly every 1000 ms is problematic, because some devices advertise at a frequency of 1000ms. If these intervals are synchronized, it is possible that you could miss every advertisement from a device because you are stopping scanning in the middle of every single one of its transmissions. Thus, I made it start and stop at a slightly different frequency.

[OneWorld123]

I agree with you. What are the reasons for taking this 5 minute break
between each scan? Do you also emulate some interval from iOS or did you
come up with that time period after some testing? Do you have experience
about the impact on battery live?
Am 05.12.2013 17:52 schrieb "David G. Young" [email protected]:

The way the Android bluetooth scanning works, you only get one callback
for each unique device that Android sees while the scan is running. If you
run a scan for 30 seconds, you will only get one signal strength
measurement over that period, and you won't have any way to know if the
device disappeared. The only way I can find to get periodic updates about a
device is to stop scanning and restart.

The reason I chose 1100 ms as the scan interval is to emulate the iOS
callback frequency as much as possible. In iOS, you get an update about an
iBeacon every 1000 ms. But stopping scanning and restarting exactly every
1000 ms is problematic, because some devices advertise at a frequency of
1000ms. If these intervals are synchronized, it is possible that you could
miss every advertisement from a device because you are stopping scanning in
the middle of every single one of its transmissions. Thus, I made it start
and stop at a slightly different frequency.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-29914845
.

[davidgyoung]

Yes, this emulates what iOS does with an eye toward saving battery usage. From my experience with iOS, I know that when no application is actively ranging beacons in the foreground, the max time it takes to detect an entry/exit from a region slows down to between 4 minutes and 15 minutes. The 5 minute break is basically a shot at a reasonable approach on Android.

I have not done any testing on how this affects battery life, but I would love to have that info. If you would be interested in doing some measurements, please let me know!

[davidgyoung]

Some updates on battery life.

As of 0.7, the default background scan interval (which is customizable) is to do one 10 second scan every 5 minutes. In the foreground, a scan is always active.

Here are the rough numbers measured on a Nexus 4:

Using the service in the foreground uses 90.5 mA
Using the service in background mode uses 37.4mA (59% savings)

Details are here.

[OneWorld123]

Thanks for your testing. I have to apologize for not responding lately.
Could you please share some details about your test? How long did your test take until you measured the 90.5 mA and 37.4 mA consumption? Like a fixed amount of time or from 100% to 0% of the Nexus 4's battery?

[davidgyoung]

Yes, the rudimentary tests were similar to what you describe. Here's a link to what we did: https://github.com/RadiusNetworks/android-ibeacon-service/wiki/Battery-Usage