2
votes

I am working on a project where a stationary iPad will act as a BLE peripheral and an iPhone will act as a BLE central. As the iPhone enters within a few meters of the iPad, the iPhone will do something. The iPhone needs to be able to run in the background or locked.

I've been working with the CoreLocation library to create an iBeacon. Using ranging methods, CoreLocation allows me to find the accuracy and proximity of the beacon. However, from what I've found, CoreLocation does not allow for background ranging. I've also found that monitoring for a beacon region can trigger enter/exit events which allows me to launch the app temporarily (~5 seconds) to then range for accuracy and proximity. However, this solution would not work as the iPad's beaconing range is very large, and the central device would trigger the enter/exit events long before the device reaches my target range (a few meters of the peripheral).

Thus, I've been looking into the CoreBluetooth library as an alternative to CoreLocation/iBeacons. I am aware that using CoreBluetooth, I would have to manually calculate the distance based on the RSSI.

My first question is, Are my assumptions correct? Would CoreBluetooth be a good alternative to use for this project?

My second question is, Can the iPhone (central) determine the distance between itself and the iPad (peripheral) while locked or running in the background?

Thanks in advance!

1
@ElTomato I'm not asking for any code. I'm simply trying to determine if this is the right solution to pursue. I wouldn't want to waste any time implementing CoreBluetooth if I would end up with the same problem as I have with CoreLocation.Mitch Wolfe
In order to determine range you need several RSSI samples; given that your phone (central) app may be in the background, this will be a challenge as you cannot receive multiple advertisements in the background. You could connect to the iPad peripheral and then use your limited background execution time to request RSSI values, but you only have up to 180 seconds to do this.Paulw11
@Paulw11the iPad will be in one location permanently. Could I just collect RSSI samples beforehand and use those to calculate distance? I don't want the iPhone to be constrained by time as the user might not enter my target proximity within that 180 seconds.Mitch Wolfe
Kind of. Yes, you need to correlate RSSI values to distances during an initial calibration operation, but you also need a stream of RSSI values as the phone approaches the iPad in order to determine when the person is "close" to the iPad; otherwise you will just get an initial RSSI when the phone first "sees" the iPad, which would be from 30m away or so.Paulw11

1 Answers

3
votes

CoreBluteooth is generally a poor substitute for CoreLocation for detecting beacons for a number of reasons:

  1. You cannot detect iBeacon transmissions at all with Core Bluetooth. Apple explicitly blocks you from doing this, blanking out advertising data in the CoreBluetooth APIs if the advertising data matches iBeacon.

  2. The ability to detect other beacon formats with CoreBluetooth in the background is poor. Manufacturer advertisements (like AltBeacon) are blocked almost entirely in the background (you can detect only one packet!). Service advertisements (like Eddystone) are detectable in the background, but callbacks are very slow relative to what you get with CoreLocation.

  3. Lots of other CoreLocation features are missing like app auto-launch on beacon detection, and hardware filters to get fast background detections when your app is suspended.

You actually can range beacons in the background using CoreLocation a few different ways:

  1. For 10 seconds after each region entry/exit transition as you have seen.
  2. For up to 180 seconds after each region entry/exit transition if you request extra background running time.
  3. Indefinitely if you set your Info.plist to have a location background mode, and register for periodic location updates (e.g. log/lon location updates)

Options 2 and 3 above are available with CoreLocation but not CoreBluetooth. To get into the AppStore with option 3, you must convince Apple reviewers that your app is providing a legitimate background location tracking function.

Finally, you can do your own distance calculation based on the CLBeacon#rssi property. It is best to average it over 20-30 seconds to reduce noise, and you'll somehow need your own reference value for what the expected RSSI is at 1 meter, as the one embedded in the beacon frame is not readable by third party software. But you may not need to do this. If you are simply targeting iPads with your app, you can simply adjust the calibration constant inside the beacon with the expected 1 meter distance RSSI for your iPad, and you should get more accurate distance measurements.

There are some cases where you still want to use CoreBluetooth despite the drawbacks above. For that reason, I built this repo.

It is also possible to use advanced techniques like forcing screen on events to read RSSI from "Overflow Area" advertisements using CoreBluetooth.