iBeacon detection in background sometimes fails

Hello,


we are developing an app that should respond to an iBeacon also in background. We have developed a small device carried on a sporting tool (sorry, can't be more specific due to NDA) that can be activated by pushing a button.

Once the user pushes the button the device turns on (gives current) to a small BLE iBeacon that will emit 10 iBeacon signals, broadcasting for 2 millisecs, 10 times (so the overall elapsed time for each pressure is 10 seconds).

The device, since it's on a sporting tool used by the user, is never more than 2 meters from the iOS device.


Of course this is not the usual iBeacon use case, but it's similar: when the user pushes the button, the device emits iBeacon packets, and the iOS device magically finds itself INSIDE the iBeacon range. AFter the device stops transmitting, after a while, the iOS device detects the exiting from the range. This is our expected behaviour.


By using other commercial BLE apps we can detect it correctly (for example the app by Nordic, nRF connect. Or others.


So far, by using CoreLocation and RegionMonitoring with the correct iBeacon UUID, our app is able to detect the transmission of iBeacon packets (by pushing the device button):

  • always, while in foreground
  • most of the times, but not always, when app is in background
  • sometimes after iOS reboot or app kill
  • after rebooting the iOS device, it helps to actually open your iPhone and do something for a while (i.e. look at a Whatsapp msg) before detecting the beacon


Any idea? We are working to increase the period of time when the iBeacon packet is sent, i.e. up to 30 seconds.

It seems to me that the background scanning of regions is given low priority sometimes, and we broadcast our signal for a too short period of time?

Could it be the problem?


Thanks

Z

For successful detection of an iBeacon under a varying set of conditions, including varying states of your app, you must follow the iBeacon spec and advertise the specified packet format at the specified advertising rate. You can find the iBeacon spec at https://developer.apple.com/ibeacon


The advertising rate is pretty much non-negotiable, and any change from the specification will dramatically decrease your chances for discovery.


Once you are advertising at the correct rate (hint: it is not one advertisement per second like your description indicates), the longer you advertise for, the higher the probability of detection will be. How long you need to keep advertising, whether 30 seconds or longer will depend on your required chance of discovery. The probability curve for discovery is asymptotic.


Additional problems you might be encountering are jitter in advertising rates, or antenna power inconsistencies every time your power up the device. You should follow the recommended test steps in the iBeacon specification to make sure advertising is constant and as recommended.

Hello Gualtier,

thanks for answering me back.

Following your link I've downloaded the tech specs and will share with the HW engineering guy.


Moreover thanks for sharing the tidbit that discover probability is "asymptotic".


But I have another quetion:

after rebooting my iPhone (it's a 7) Ive experienced several times this behavior:

  1. if I activate the device after the reboot, no iBeacon is detected
  2. if I unlock the iPhone for the first time (with Pin as required), and try activating the device, no iBeacon is detected
  3. if after 2) I actually use an app for 2 seconds (my test was with Whatsapp) and then lock the iPhone, and activate the device, it is almost always detected.


Is this an expected behavior? Or this is just a consequence of other issues (adv rate, power, duration of overall transmission, etc?)


Thanks

Z


BTW the tech bit is under "Downlad Artwork and Specification", a bit misleading maybe, but that's where to find tech specs.

Hi Zontar,


Yes, the behavior you are seeing is expected. What changes is the bluetooth scan rate depending on device state, running apps, etc.


As the scan rate slows down, the probability of discovery drops. Of course the slow down is not random but uses very specific scan rates and the specific advertising rates we publish for iBeacons and other BLE devices are counterparts to the scan rates and are meant to maximize the probability of discovery.


That's why it is very important to not only use the exact rates we publish, but also to make sure there is no change (other than the Bluetooth spec variance) over time due to external circumstances (for example temperature, or battery conditions).

Hey Gualtier,


Thanks for your response! I'm really glad I stumbled upon this. I'm using some Estimotes and having them broadcast as iBeacons. I've set the advertising rate to 100ms, as specified in the iBeacon spec, and that did decrease my number of false events, but if I'm still getting them periodically. If I'm in the same area as a beacon for 30 minutes or an hour I still get a faulty event saying I've left the region when I haven't. It looks like there are times that it takes 40s or even longer for the beacon to enter again after it exits. Do you think this is an issue with the Estimote hardware or is the iBeacon software in the iPhone not ready to be in the same area as a beacon for more than an hour?


Thanks,

Davis

The problem you are seeing is more likely due to signal degradation, due to interference or other factors.

Placement of iBeacons is critical, and human bodies are surprisingly good RF blockers. You may want to try relocating the beacons to a location where the signal propagation will not be interfered by humans, microwaves, etc.

Gualtier,


We are seeing similar behaviour in our iBeacon application, but we have noticed the following:


iBeacon interval set to 100mS


If we turn the iBeacons on / off, iOS will fire the DidEnter and DidExit as expected with high reliability, and this works with our app in the kill state, background, and foreground. However, if we walk towards / away from the iBeacons, we observe that occasionally DidExit and DidEnter do not fire at all. We have even confirmed this by using DidDetermineState and we get the wrong state returned from iOS. The phone can be sitting right beside an iBeacon transmitting at 100mS intervals and the phone doesn't know it is there. We can also use DidDetermineState when there are no iBeacons around and it will return that the iBeacon is still in range when it is long gone.


Sometimes (but not always) waking up the phone will cause it to immediately fire the DidEnter (if the beacon is present) or DidExit (if the beacon is gone).


We seem to get 100% success when we turn the iBeacons on / off. We get about 90-95% success when walking towards / away from the iBeacons. We have tested this behaviour with multiple iBeacons and multiple iPhones and it is repeatable.


If you could provide any guidance it would be most appreciated. This issue is causing extremely poor customer experiences, and it only exists on iPhones. Our system runs perfectly on another platform.

Chiming in to say we are experiencing this too. My users typically interact with up to 10 beacons per hour to satisfy work requirements. They are all broadcasting at 100ms. Also worth mentioning that our app is pinging the phone for a GPS location every 5 minutes or so and it has been working normally. When a user first shows up the beacon aspect of the app usually works no problem. However when they set off on their 2nd walk through the only thing that makes the app work normally again is deleting an redownloading the app. We are using the region method on IOS12+, model of iPhones vary but have recreated the issue on iPhone 8, iPhone X, and iPhone XR.

We see the same behaviour! We have to tell our users to delete our app and download it again. Then everything starts working properly - until it happens again. Sometimes a phone restart fixes it as well.


Incredibly annoying. I find it interesting that Android never seems to have any issue detecting iBeacons, but iPhones do (in the background and kill states). With Android we can even reduce the advertising rate of the iBeacon and it still works fine. With iPhones we set them to 100mS and still have significant problems.

iBeacon detection in background sometimes fails
 
 
Q