Apple iBeacon Bugs Complicate Bluetooth LE Experience

Before you attack your new Bluetooth LE beacon in frustration you can blame a possible bug in the Apple API for sudden state changes in finding and ranging beacons.

After banging our own heads, Dan Nolan from Proxima confirmed a problem we’d been seeing and which we initially blamed either on the beacons themselves or interference of some kind.

Namely:

  • Your app is likely to lose range of beacons for brief instances and will briefly report didExitRegion before quickly returning to being in range
  • Your app will sometimes make the wrong ‘guess’ as to which proximity region it’s in before eventually correcting itself. It will sometimes report Proximity == near when you’re “immediate” or “immediate” when you’re “near” and then flip itself back to the correct value.

The bug is hard to nail down because Apple hasn’t documented the logic behind how it’s API works and doesn’t tell us how, exactly, they calculate proximity (which is a kind of rolling average and calculation based on signal strength and the accuracy packet). There are two key steps that your app will take in “finding” beacons:

Ranging Beacons
Using didStartMonitoringForRegion your app will ‘look’ for beacons while open or in the background tray. Once it finds them, you can initiate an action with didEnterRegion.

This one is simple enough and while the response time varies depending on whether your app is in the background or foreground and, weirdly, how long your app has been open or whether you’ve recently ranged, it works well enough.

It’s how the app monitors leaving a region that makes things complicated. With didExitRegion the API is ‘smart’ enough to delay itself when you leave a region to make absolutely sure you’re gone. Usually, this delay seems to be 3-4 seconds, whereas it will detect a proximity change in 1 second or under.

Phone and beacon stay in a fixed position and then this happens...
Phone and beacon stay in a fixed position and then this happens…

However, the bug we’ve run into is that your app will sometimes say that you’ve left a region and then immediately correct itself. This might be due to signal interference. Using HiBeacon or other beacon monitoring apps, we’ll see brief “cutouts” in power displayed – but our suspicion is that there isn’t an actual cut-out, it’s the detection that’s the issue.

What’s strange about the bug is that under ‘normal’ conditions, the app won’t report didExitRegion until it’s confirmed that you’ve actually left. But in the issue of the bug, no confirmation happens – it just “exits” itself from the beacon region and then immediately flips back.

Beacon Proximity
As noted above, your app will sometimes make the wrong guess as to which region it’s in. Using CLProximity, the API seems to have been set up to correct itself as more data comes in. Your app may be right next to a beacon and it will ‘guess’ that it’s near, but then correct to immediate. But these corrections aren’t predictable. And when the app is guessing “immediate” but you’re actually “near”, you can have weird decisions to make about the user experience.

One time you put your app next to a beacon and it pushes a coupon, the next time it pushes an ad for shoes. Not at least being able to predict what factors will help the app get it ‘right’ is frustrating to say the least…and it’s either an out-and-out bug or a flaw in the logic behind the scenes.

What to Do?
The work-arounds to these issues all feel like hacks. Instead of the Apple API gracefully moving between finding and leaving regions and coming into proximity of beacons, you need to insert additional logic to avoid rapid ‘toggling’ and to ‘fix’ the last beacon reading in the case of a brief didExitRegion call. Dan and Apple itself have suggested that CLProximity won’t be the API you want to use if you’re really putting beacons through their paces: and you’ll need to calculate proximity based on RSSI and accuracy from the beacon advertising packet.

We’ve tested this on three different types of beacons, so it doesn’t seem to be related to the manufacturer of the beacons.

But have you seen similar results to those above? Are they “bugs” or just the reality of beacons which needs to be corrected for with code? Let us know in the comments below or drop me an e-mail.

Jump Onto Our Mailing List

Let’s chat on Twitter! We have some good conversations. Or join our weekly mailing list for ‘BEEKn unplugged’ – I rant a little each Friday and share stuff that doesn’t make it on the site.

Be the Beacon!

11 Responses to “Apple iBeacon Bugs Complicate Bluetooth LE Experience”

  1. Guenther Muranyi

    Region Monitoring
    https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/LocationAwarenessPG/RegionMonitoring/RegionMonitoring.html

    “region events may not happen immediately after a region boundary is crossed. To prevent spurious notifications, iOS does not deliver region notifications until certain threshold conditions are met. Specifically, the user’s location must cross the region boundary and move away from that boundary by a minimum distance and remain at that minimum distance for at least 20 seconds before the notifications are reported.”

    Reply
  2. Yes – that’s true Guenther – as I say, it’s not a mistake that it takes time to ‘exit’. It’s a good thing that there’s a delay.

    HOWEVER, there’s also a bug where you WILL exit, even though your phone is in exactly the same place and nothing has changed. Location services seems to turn off for a brief millisecond, enough to call a false region exit.

    You can see it in the error logs.

    Three observations:

    - It takes time for region boundary conditions to be met
    - The 20 second rule isn’t a true number – it can vary from 5 seconds to 30 in our tests
    - Your phone will sometimes turn location services off for no reason which will force an “exitregion” call and have your app start scanning for regions again.

    Reply
  3. Hayden Evans

    The problem I seem to be getting most of the time is a display of immediate proximity when I am clearly out of range of the iBeacon. I can be well over 40 or 50 feet away from the device and it will still display an “immediate” proximity. By walking close to the device it will eventually correct itself from immediate back to near and then immediate again (when it is actually within immediate proximity). So frustrating! Anyone else have this issue?

    Reply
  4. Yes, we get exactly the same behavior. Right now, we consider the Apple API to be ‘broken’ in this regard. As a result, we tend to be using signal strength to calculate proximity rather than ranging and then setting a timer or counter for number of times you poll within a range of signal strengths.

    We get the same behavior you do, and also get ranging turning off entirely for brief intervals (it basically loses the signal and then needs to start over…it last for less than half a second but enough to throw you off!)

    Reply
  5. Williams Martinez

    Observing the same behavior here while playing with Estimote beacons.
    How do you calculate “proximity” out of signal strength?

    Reply
  6. Observing the same behavior here while playing with Estimote beacons too.

    Reply
  7. Williams Martinez

    Sorry for my last post, I just pressed “Enter” before finish.
    The advertisement interval should be 100ms.

    Reply
  8. Hi,

    We are experiencing the same kind of “troubles” with our BLE iBeacon here. Air traces clearly shows that our chip is correclty transmitting advertising events with a period of 30ms and as we are even facing similar issues between 2 iOS devices, we consider this for now as an Apple “Work In Progress API” issue. From what I see in the API reference, the beacon region misses a reliable Timeout Interval property.

    Reply
  9. Paul Ashford

    Changing the time of the signal to 100ms gives a far more stable proximity change. Change the time to a large value such as 900ms and you will see the proximity go a little wild and it takes some time to stabilise, then set this to 100ms and you will see that a decision is made very quickly as to the proximity status.

    Reply

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>