I’ve been working on a iOS app (quite simple) that monitors and range beacons. Ranging seems to be working ok, but I’m having some issues with the background beacon monitoring:
My app currently is monitoring one specific beacon (Strong broadcasting power (4 dBm) & 1300ms interval). It simply sends a notification when didEnterRegion is fired, and another notification when didExitRegion is fired.
The problem is that I’ve been having unreliable results with the background monitoring, where I could be from 20 cm to 2 mts away from the beacon when suddenly didExitRegion gets fired, and of course, after that didEnterRegion is fired because I’m still inside the region (sometimes instantly, sometimes it takes some seconds) showing several entrance and exit notifications.
I’ve tried with a different beacon (just in case), but I’m getting the same results. Sometimes everything works fine, but some days I would get this crazy behavior.
Any ideas? Or something I should check? I know about the iOS 30 seconds waiting to avoid didExitRegion false positives, but it seems that is not working completely, or at least not always.
Yes, I’ve seen that as well, and we got other similar reports too. The problem lies somewhere at the Core Location level, but we’ve had no luck getting to the bottom of it so far. I’m gathering some data to submit a bug report to Apple, maybe you could help me?
Could you try setting the adv interval to 100 ms (Apple’s official requirement for “pure/strict” iBeacon)? Could you try enabling the Basic Power Mode and disabling the Smart Power Mode? Does this happen with all of your beacons, or just some specific ones? If there are two iOS devices in range of the beacon, does the problem happen at the same time for both?
Good to know that I’m not alone with this problem. To answer some of your questions, this happened with 2 different beacons (both Estimote) and I didn’t try it with more than one device simultaneously, but I’ll try that today.
I’ll change the beacon settings to the ones you mention and let you know how it goes.
While I try this, don’t hesitate to ask anything else if it helps you gather data to send to Apple.
Cheers.
Well, I’ve been using the beacons with Smart Power Mode disabled and a 100ms interval and so far the results are much better. I don’t suffer the false positives anymore. The only problem with this approach is, of course, the beacon’s battery life (only 3-4 months).
I will slowly increase the advertising interval to see if this behavior continues in order to try to extend the beacon’s battery life. Hopefully something around 400-500ms should be enough to get almost 2 years out of the beacon.
We have been testing and so far we are happy with 500ms interval. It doesn’t fail as it used to, maybe once every now and then, nothing terrible. With that interval you get a decent battery life, I would recommend you to do some tests too, but that seems to be our magic number.
Hey we are facing this same issue! Thank you so much for your trial and error testing, we will change the settings to advertise every 500 ms and broadcast at 4dBm. How long on average do your beacons’ batteries last with these settings?
Thank you so much, I’m not too familiar with NSOperationQueue or NSBlockOperation but I’m going to read into those classes and then add in your solution.
Thanks. So I tried it on 500 ms with 4 dBm all the way down to 100 ms advertising interval at 4 dBm and I’m still getting false positives I’m not sure what to do other than turning to continuous ranging in the background because our app cannot afford false positives as we are tracking people’s time.
Yes, indeed the false positives continue, although I’ve experienced not as many as before. I think you’ll need to mix this approach with a logic filter or ranging in the background.
Try the filter first, where by some logic (a time flag or something), you check if the user to re-enter the region immediately after exiting. So, in that case you can ignore the exit/entrance event.
I didn’t try @chaychoong solution. With Android, a time flag to check if a user re-enters immediately worked fine. With iOS it’s a little more complicated because of the background availability that only gives you around 10 seconds.
You should try looking for users re-entering the region up to 10 seconds after exit, and ignore the event if necessary or just go ranging in the background (I haven’t try this one).
Upon being woken up, the app has around 10 seconds to process the data. Ideally, it should process the data as fast as possible and allow itself to be suspended again. However, if more time is needed, the app can use the beginBackgroundTaskWithExpirationHandler: method to request additional time; it should do so only when absolutely necessary, though.
Nice to hear this! But i’m having this problem in android app, haven’t found any related information on android forum but it’s the same problem reported here, any news about this?
I’m not sure what to do other than turning to continuous ranging in the background because our app cannot afford false positives as we are tracking people’s time.