Estimote beacons not working on Iphone as expected - ios

Question

OUR GOAL WITH ESTIMOTE BEACONS : We are planning to setup Estimote beacons in golf course. our scenario is whenever player reaches the hole and what is the pace of play, It should be detected by the beacon & respond to the server through our IPhone application.
In this case user doesn't need to open the app, because mobile is in his pocket & he is playing.
WHAT WE HAVE DONE SO FAR:
Ranging only works when the app is in only active state. (GOAL NOT ACHIEVED).
To achieve this goal we are using Monitoring, but the problem is monitoring delegate (didDetermineState state: for region:) some times called some times not (called: instantly, someDelay & never). In other words beacons don't always detect by iOS by monitoring. (GOAL NOT ACHIEVED).
If we are testing on two or more iPhones 6s with same iOS versions 10, each phone have different results some detects & others not. For testing we used flip to sleep & setup beacons in different locations to be enter/exit events fired & lowest advertising interval.
Implemented edystone on estimote beacons, they are not working when application is in background. (GOAL NOT ACHIEVED).
We tried following solutions found on internet or forums of estimote beacons.
Its Nov 2013 article Ibeacon monitoring but in Dec 2016 it seems no difference.
We also tried for background ranging through CoreLocationManager.startUpdatingLocation:
Here and Here
We tried to speak Estimote but they answer was ambigious, "We're painfully aware that iBeacon monitoring can be a bit finicky at times. We hate it as much as developers trying to build beacon-powered apps do, but when it comes to iBeacon, we're quite helpless, because Apple has the API on lockdown—there's no way to detect iBeacon packets on iOS other than through the built-in API, which exhibits these problems."
It seems like some how it is possible.
This is how i am registering array of beacons currently we have 3 to 6 beacons.
func loadBeacons() { // Load beacons
self.beacons = getAllbeacons()
self.beaconManager = ESTBeaconManager()
self.beaconManager.delegate = self
self.beaconManager.requestAlwaysAuthorization()
if self.beaconManager.isAuthorizedForMonitoring() == true {
self.rangingBeaconsSetup()
} else {
self.beaconManager.requestAlwaysAuthorization()
}
}
func rangingBeaconsSetup() { // SET UP Ranging beacons
for beacon in self.beacons {
if let beaconRegion = self.beaconRegionFromItem(beacon) {
beaconRegion.notifyEntryStateOnDisplay = true
self.beaconManager.startMonitoring(for: beaconRegion)
self.beaconManager.startRangingBeacons(in: beaconRegion)
}
}
}
func beaconRegionFrom(_ beacon: Beacon) -> CLBeaconRegion? { // GET VALID REGION
let val = 1 << 16
if let uuid = NSUUID(uuidString: beacon.uuid), beacon.major < val && beacon.minor < val {
return CLBeaconRegion(proximityUUID: uuid as UUID, major: CLBeaconMajorValue(beacon.major), minor: CLBeaconMinorValue(beacon.minor), identifier: beacon.deviceName)
}
return nil
}
func beaconManager(_ manager: Any, didDetermineState state: CLRegionState, for region: CLBeaconRegion) { // Monitoring delegate.
if state == .inside {
let notification = UILocalNotification()
notification.alertBody = "By tapping you will be able to check-in"
notification.alertAction = "OK"
notification.fireDate = Date()
application.scheduleLocalNotification(notification)
}
}
These are following responses we receive when we have same IOS devices (OS 10) both have inconsistant behaviour.
RELATED QUESTIONS :
Is our expectation for beacon accuracy is quite high?
If a beacon is broadcasting the data to all the phones then every device must behave same because we have same IOS version, same Iphone and same code.
How can we get consistant results
Our experience is, Detection varies "from few seconds to 15 minutes and some time it does not detect at all"
What can we do to get consistant and reliable results?

Answer 1

From your problem description, the core problem you have is inconsistent behavior in background monitoring callbacks.
In theory, you should be able to to get a monitoring callback that wakes up your app in the background and lets it range in the background for 10 seconds (extendable to 3 minutes if you use this technique) each time a beacon is first detected in a monitored region or each time all beacons stop being detected in a monitored region. This will fire a didEnterRegion or didExitRegion callback.
As you have seen, sometimes these callbacks do not come when expected. There are two primary reasons for this:
You don't get a entry or exit callback because the region state has not changed. This often happens when iOS believes it was always inside a CLBeacon region, whereas an app tester briefly removed the iOS device from the vicinity of the beacon (either by moving the phone or turning the beacon off) and then returning it to the region. The failure to get an exit/entry sequence in this case is often caused by not giving iOS enough time to detect it has exited the region. In the background, this can take up to 15 minutes. Most of the time this is purely a testing problem and not a problem your actual users will face -- testers are under time pressure to get their tests done, so they often just don't wait long enough in thse test cases. Adding logging, notifications or other insight for when region exits occur can help your testers make sure they wait long enough.
You don't get an entry callback quickly because all hardware acceleration slots are filled. In order to detect becacons and send didEnterRegion callbacks within a second or two, iOS relies on Bluetooth hardware filters to wake up the OS when a beacon of interest is detected. The problem is that these hardware filters are a scarce resource, and if they are exhausted by other apps that were installed on the phone first, then your app won't get access to them, meaning that detection times will fall back to software scans that can take up to 15 minutes. There is no way to know wheter your app has been granted access to these hardware filters, and even uninstalling and re-installing an app on your phone can change whether this is true, leading to inconsistent resuls. The number of available filters is undocumented, but some evidence suggests the number is 30, meaning only the first 30 CLBeaconRegions monitored on a phone get priority access.
In order to solve problem #2 in your tests, uninstall any other apps that you think may be monitoring for beacons, then reinstall your app. You should then get more consistent results.
Of course, you can't make real users uninstall other beacon apps, so they may still face these problems. But the good news is that most average users won't have a lot of beacon apps on their phones, so this is far less likely to happen to real users than it is to deveolopers or testers who often have lots of beacon apps on their phones.