Hi guys,
I am trying to measure the exact distance that the beacon can range up to. The reason I want to test the beacon distance is because I am planning to minimize the number of beacons for triangulation. I know there’s a method called computeAccuracy in AndroidSDK and it’s used to compute the distance from the beacon to the phone. I found that a method called EILPositionAccuracy is available in IOS Indoor SDK. It seems that method can’t compute distance, but determine the level of accuracy. Is this the method I am supposed to use and do something with it to get the distance like get the RSSI value and convert it to distance?
Any helps will be appreciated!!
If you want to measure how far away a beacon can still be detected, it’d probably be easier to use some ready-made BLE-scanner apps available in the App Store, and see how far away you still detect your beacons. (you can google “itunes bluetooth scanner” or “itunes ble scanner”)
Note however that trilateration (a) generally doesn’t give very good results with BLE signals, and (b) gives much worse results further away from the beacon, even if the signal is still detectable. Our own Indoor Location SDK generally requires the beacons to be spread ~ 10 meters apart for best results. (We don’t use trilateration.)
I see. I am trying to implement a device location system on a floor (using triangulation or maybe a different method), perhaps not as accurate as the Estimote Indoor location SDK. The Estimote Indoor location requires 6 beacons per 100 sqr meter which is not very feasible for our use case, cost-wise. For this reason, I am trying to get as much information (distance, signal strength, latency etc at any point in time…) between devices and the beacon(s) in order to come up with a workable alternative. So far, from the proximity demo, I’ve been able to use the proximityObserver (iOS) to estimate distances by zones. Any additional help is much appreciated.
Thanks!
Hah, yeah, we understand that well here at Estimote, that’s why we’re driving two products: Proximity, which is easier to deploy and cheaper, and Indoor Location, which is more powerful but ultimately more expensive, both in terms of # of beacons, and time to deploy.
Is Proximity not a good option for you? We once had a simple deployment in our HQ, where we’ve just put a beacon in each conf room, kitchen, lobby, open spaces, etc., and built a simple “office” app where you could see in which “zone” people currently are.
Proximity zone can gives us estimated distance of the beacons which is a good start. But we want to have more control of the beacons.
Below method is from Android SDK. Are there any functions that can return distances based on beacon’s RSSI and measured transmitPower in IOS SDK?
public static double computeAccuracy(Beacon beacon)
Returns distance in meters based on beacon’s RSSI and measured transmitPower. Returns -1 when cannot compute accuracy.
No, there’s no such method in iOS Proximity SDK. You can however use Apple’s Core Location framework. The “ranging” method in Core Location does provide the “accuracy” value, which is the estimation of the distance much like computeAccuracy.
(BTW, since you’re currently using our Estimote Android SDK, please keep in mind that proximity features/APIs in that SDK are deprecated in favor of the Proximity Android SDK. Basically, they won’t be developed or improved further.)
A little more context about why we’ve decided to move away from providing distance estimation APIs in our new Proximity SDK, and why it’s likely not coming back.
We found that developers generally use distance estimations for two things:
- triggering an action at a certain distance to a beacon
- trilateration/multilateration to determine the indoor position
We’ve been building software and SDKs for beacons for a few years now, and we know first-hand that these two uses are actually quite difficult to solve with distance estimations alone. So rather than provide distance estimations and see majority of developers fail* to implement a good experience based on that, we’re now providing two higher-level, dedicated SDKs for these two uses: Proximity and Indoor Location.
* this BTW has nothing to do with how competent these developers are—we’ve worked with some really smart, world-class mobile teams that still struggled, they simply don’t have the time and resources to dedicate to all the research, data science, and experiments we’ve made over the years
It’s definitely been tempting to add some sort of “advanced”/“low-level” API which would bring the distance estimations back, but we’re resisting this very strongly, because we believe it builds the wrong mental model of how the sensor technology works, provides out-sized expectations, and is generally more harmful than helpful.