Background ranging problem with iBeacon: infrequent results

Hi there,

We’ve just noticed something extremely odd with background ranging of Estimote beacons using iOS.

A bit of background: we’re just using standard CoreLocation API here to do ranging using iBeacon, we’re not using Estimote’s API (though we are using Estimote beacons as iBeacons). We set up a tiny test app to just upload RSSI values to a local laptop in real time.

We’ve set the app to allow background mode (this is just a test app so we’ve not pushed it through the App store or anything).

In foreground, everything works great: we get accurate and frequent (every 1-2 seconds) RSSI values to the didRangeBeacons callback. When we move the phone we see the RSSI values update accordingly.

However in background we’re seeing a problem. What we’ve observed is that although iOS continues to report back ranges to the didRangeBeacons callback, pretty much at the same frequency, the actual values are stale (out of date). In fact, it seems like iOS is only really updating the true RSSI values every 30-60 seconds (depending on how long we’ve been in background mode). After that point, it seems to send the last value that it knew.

We can watch the RSSI values and see that it takes about 60 seconds for it to update to the new value (we’re testing this by moving the phone to extremely close to a different beacon each time).

I’m aware that iOS can choose to “suspend” the app if there is no new background information to send, but that isn’t what’s happening here.

My suspicion is that iOS is deciding to reduce the frequency of how often it actually ranges the beacons, and then is just “lying” in between.

Or maybe, it’s only ranging one or two of the beacons in turn or something.

Has anyone seen this issue before?

Quite likely iOS’s Bluetooth stack goes into some power saving mode when the app is in the background.

You could try enabling iOS Bluetooth debug profiling and look for clues in the log files:
https://download.developer.apple.com/iOS/iOS_Logs/Bluetooth_Logging_Instructions.pdf

Could also try opening a radar with Apple about it, though I highly anticipate they’ll just say this is the intended behavior (:

Thanks Piotr - that’s very helpful.

I’ll look into both of those suggestions.

So, does that mean that the Estimote Location API also suffers from this problem? Or maybe you’re using CoreBluetooth to do ranging instead?

Yes, we’re using mostly Core Bluetooth. Yes, it also slows down in the background (: [although I don’t recall it being as bad as 30-60 seconds]

OK that’s good to know. Thanks as always!

PS for others reading this thread, I did raise an issue with Apple and they replied with the following:

Our engineers have reviewed your request and have concluded that there is no supported way to achieve the desired functionality given the currently shipping system configurations.

So that’s a typical Apple “works as intended” response.

Ha ha, this is probably the most confusing way to reply I’ve ever seen :slight_smile:

Haha! I know :stuck_out_tongue: