Human Experiences, Proximity, Augmented Reality and the Internet of Things

Differentiating between range and precision is one of the challenges of understanding how to build effective use cases with iBeacon, Estimote beacons and other other types of Bluetooth LE devices.

I had an interesting back-and-forth with someone on Twitter last night asking about the range of beacons. The conversation reminded me of my own confusion related to beacons and Bluetooth LE and the mental leap I had to make in understanding range, signal strength, accuracy and precision.

My understanding was further confused by the fact that while Apple iOS doesn’t let you “view” the actual advertising packet data in a beacon that isn’t your own, Android DOES.

This fact is FURTHER confused by the fact that there can be (although usually there isn’t) a difference in whether a beacon transmits in public or requires pairing. I covered a lot of this in a previous post (where I recommend you also read the comments), but here’s how I understand things today:

Beacon Data

A beacon sends the following data:

ADV-PDU – or what we call UUID

Flags

TX Power Level

Local Name

Services

The UUID can be static or, if the beacon requires “pairing” it can be a randomly changing number. Almost all of the current beacons that you can get have a static UUID and are “public”. For Estimote, the UUID is B9407F30-F5F8-466E-AFF9-25556B57FE6D If you don’t know this number, there’s no way in iOS7 to “see” it because Apple closes off the packet for beacons you haven’t specified (Estimote does the specification for you in its API, but you might want to create a custom app that goes ‘straight’ to the beacon).

If a beacon requires pairing, it’s not that its data can’t be “seen” by an Android device, it’s that it would be hard to “fix” the beacon in a database because you’d have no unique identifier to build a profile around. Again, almost ALL beacons are currently using static IDs.

Estimote indicates that when they launch their cloud services you’ll be able to choose between static/random and set other factors in the beacon itself. Right now, however, Estimote does NOT have its cloud-based services launched and has not indicated a timing for when they will. (As a side note, they’re hinting that their cloud services will also include CMS and other features).

Range and Precision

There’s a difference between range and precision. I’m not sure why I found this confusing but it’s a fairly profound difference between beacons and, say, GPS.

Because we’re so used to the idea of GPS location-detection, I think it’s hard to break our mental models and understand what beacons actually DO.

Now, I’m a bit slower than most people when it comes to technology, but here’s my recommendation:

Do NOT think of beacons as location detectors. They are PROXIMITY detectors.

GPS had me thinking about location – “I’m at the corner of Main and First”. Sure, if you triangulate a bunch of beacons, you can get to location, but beacons are first and foremost about proximity.

Second:

The closer you are, the more accurate the detection of proximity becomes.

The main drivers of this precision (or accuracy) are radio interference and signal strength. Signal strength is dependable over time. Interference is NOT. Interference can change with time of day, the building you put them in, or the street corner you post them at.

So, while you can generally depend on signal strength to give you a general ability to identify that you’ve come in range of a beacon, the measurement of proximity will be variable.

Estimote Precision

Have you run a test with Estimote or other beacons? Maybe we can share some info on our tests?

Range varies, but is roughly 40m out of the box for an indoor setting.

We’ve run tests with Estimote and see a precision that ranges from 10% to 20% depending on how far you are from the beacon with this number fluctuating depending on whether I put it in a store with lots of metal shelves or a large mostly empty room.

If you’re practically touching your phone to the beacon (50 cm or less) the precision is +/- 5 cm or +/- 10%. When you get to 10+ meters, the precision decreases with up to 20% variance the further you get.

And these numbers aren’t ‘fixed’. Stand still with your phone and you’ll see rapid fluctuations.

Apple iOS ‘groups’ proximity into near/far and immediate. You’ll see rapid toggling between these zones even if you’re standing still, and then the API makes corrections and seems to average out the detection to allow your app to make intelligent decisions.

What Has Been Your Experience?

Can other people validate the above? We’d love to hear whether others are having similar results. Maybe us Canadians have more interference in the air! Let us know in the comments below or e-mail me and I’ll try to keep this data up-to-date.

I’ve no experience w/ estimote devices (’cause don’t have any) but i experienced distance & strength signal with Apple devices (Macbook pro, ipad mini). I even tried the cross compatibility w/ Android device (Nexus 5). The distance is almost the same, a 40m circle from the emitter maybe a little more, for those devices, except i noticed that the iPad mini is more powerful than the Macbook. The second difference is that i have a something different for the RSSI value between android & apple devices, like a 20 fixed value.

Ah good confirmation. We had the same thing with a Bluetooth LE dongle plugged into a Macbook. We used this little micro-adapter http://www.iogear.com/product/GBU521/ and set up a virtual machine using the instructions over at Radius. Had the same result as you….the precision was a lot more accurate than a stand-alone beacon and didn’t fluctuate as much as, say, the Estimote.

Its been two days since I’m working on Estimote Beacons. I’v gone through api and sample code that Estimote provided on site though with iOS7 devices none of the demo got the virtual beacon (yes, Estimote itunes app is what all i have for now as a beacon). After spending much of time on forum I got HiBeacons sample code and it get me out of empty beacon array condition.

I used same default UUID B9407F30-F5F8-466E-AFF9-25556B57FE6D for HiBeacons.

There may be something went wrong with Estimote Virtual Beacon Itunes app. When I user HiBeacons as an advertiser, sample code of Estimote worked well as a receiver.

Thanks Shrejash. Yeah we has problems with one of the estimote apps too but didn’t try their virtual beacon app – was proximity app I think that didn’t “do” anything. They
Might want to get their developers to do a more thorough review maybe and perhaps add more documentation – which I generally find vague on github (although the class references are ok)

My name is Jakub and I am the CEO and Co-Founder of Estimote. I will be more than happy to comment
on few issues mentioned above:

When it comes to the range our beacons are shipped with narrowed range a bit. It could be easily extended up to 70-100m using our Beacon API. The new version of app we are working on should also allow extending the range from the app.

The current version of the Virtual Beacon App in the App Store is old one and it does not support “iBeacon” since it was published before 10th of Sep.

The beacons we are shipping now do support iBeacon and the new app is currently pending approval in the App Store. It should be published this week and will allow both:
1) connect and run demo apps with physical beacons
2) create virtual iBeacon that is visible by API and other devices running demo apps

I’ve been using techBasic to work with six Estimotes for the last two days, getting RSSI sample data. I’ve been trying to get a feel for how their signal strength behaves compared to the TI SensorTag I’ve used previously. Their range is about 10-15% less than the Tag’s, from what I can tell. One of the six is a bit more flaky than the others with less signal strength, and it drops out more. The other five seem to behave similarly to each other.

I’ve noticed that the firmware on the Estimotes will drop a connection after a few seconds. This happens in BLExplorer and my own code. I assume this is to preserve battery life, as their normal operation is to run un-paired.

I’m using techBasic for my tests as it’s a full IDE on the iPad (I’m using the latest iPad Air) and no other computer is required to create and run programs—and it fully supports BLE communications. With it, I can scan for all BLE devices (by not providing a UUID to scan for) and use the static UUIDs returned to identify the individual transmitters. (I’ve written the first four characters of this on the bottom of each Estimote so I can tell which is which.)

I keep the last N (currently 50) RSSI samples and display the average as well as the standard deviation. My goal is to not only track proximity, but to see how much location data I can extract from an office with multiple beacons scattered about. Tests with the single TI SensorTag showed a roughly circular pattern with a sharper drop-off over the first couple meters with a far more gradual slope over the remaining signal range.

The Estimotes, so far, are giving me similar results, although with a shorter over-all range. There is, of course, a lot of noise in the signal. Without averaging over many samples, the noise will swamp out any useful range data. Note that while the RSSI is usually in the 0 to -127 range, I do get a positive 127 value from time to time. Be sure to filter this from your averages or it will skew the results. I’m guessing it indicates no RSSI data for that transaction.

But I’ve had the Estimotes for less than 48 hours, so more research is needed. 🙂

We have an indoor mobility solution, and thinking to try beacons for improving location, but after reading your comments, I do not know if it is a right solution. We want to position a person in a certain part of a building, and help them to move around, and as you know wi-fi is not a good solution neither. Then, I would like to ask you if you do not think that using beacons, we could improve positioning rather than with wi-fi. Thanks!

As you mentioned in the article, these are not at all location detectors. For example, you can have an actual distance of 2 meters from a sensor. While facing the sensor, you will notice your reading may fluctuate from 1-3 meters. Simply turning in place so that your back is now facing the sensor can change your readings to display 3-12 meters, which is a note of caution for anyone attempting to get a fine location from these (Hint: don`t do it!)

Hi Doug, i´ve made a lot of tests with estimotes in few days and i can finish my first prototype, so, i can see some keys issues, first and foremost, the range (didRangeBeacons) ios method needs of some calls in it to be found the correct distance between him and estimote beacon, your code needs deal with it, he can´t believe that first beacon found are in the correct distance nor that is the more closer beacon, so, you need of a few code lines to deal if it, like wait some seconds to show another beacon information when tha app are showing data to the user and i need divide my beacons in departments (range proximity immediate and near) and product types (only immediate distance) to app works fine.
(Sorry by my poor english, i learn it yet…)

My challenge now will make the estimotes and radBeacons works together…if you have some experience with it, share with us please or with you want i shared it with you, i think that a post (with your words and experience, off course) about it (ibeacons brands that works with ibeacon native libraries and ibeacon with owner libraries) working togheter) will be great!

Hello Jakub, we’re using your estimote beacons. While installing these in a large warehouse type store, I’ve set a broadcast range of 40m, 50m and 70m on the different estimote beacons. These have been placed at an approx height of 3m – 5m on walls. Also, the frequency set has been with the shortest intervals. However, with almost all of them (7 – 8), my app is unable to detect them beyond 2 – 5 meters away. Am I doing something wrong in the way I’ve set them up ?