There has been a crazy amount of media coverage this week after the release of the iBeacons API for iOS 7…including much confusion about what iBeacons is and isn’t, from retail stores using beacons to Major League Baseball offering “experiences” around the stadium in their “At the Ballpark” app. Read on to see why Apple is not the first to crack the code for “indoor beaconing,” and why iBeacons are not as accurate as the press leads you to believe.
First, what’s true: We’re at the cusp of wireless change. Especially us at NewAer, as we’ve been pushing this change of the term ‘proximity,’ vs. ‘location,’ for many years. This shift in definition has finally been embraced by the media via big-name technology providers. Apple is driving a new protocol based upon our old friend Bluetooth, called ‘4.0’ and Smart or BTLE (meaning Low Energy), or iBeacons as they like to brand it. Don’t worry about all of these terms – they’re interchangeable.
iBeacons is what we at NewAer have been building for years: a proximity platform on standardized protocols using low-cost commodity chips that anyone can build and place within products or accessories.
There are a few reasons BTLE is exciting for us. The first is that the beacons or ‘stickers,’ which are basic ‘dumb things’ that will emit the beacon signals and work for a year or longer on simple lithium “coin cell” battery power. The other exciting thing about a BTLE signal is that it does not need to be authenticated for your application to read it. This means no more cumbersome pairing – and because they can be identified more easily indoors than GPS signals, to infer a person or a location to trigger something within an app. We call these triggers actions.
Many reporters have described iBeacons as an indoor GPS solution, which it clearly isn’t if you read the API. Instead of thinking of iBeacons as a localization system, think of it as a proximity system, and design your applications appropriately to create an event or trigger when you enter or leave the range of one.
NewAer began leveraging radio waves like WiFi, older Bluetooth 2.0 and cellular towers when all of those required pairing, keys and authentication – we removed those ‘pairing’ necessities before BTLE enabled this functionality. We then added NFC and BTLE support once it arrived. In fact, we had BTLE iBeacon-like support running on iOS 6, when we released our Kiosk advertising app. (See it here in our VentureBeat Minority Report story.)
We’re glad that Apple has recognized the value of proximity. As the leading provider of proximity software in the world, we welcome developers to start thinking about adding proximity to their applications. While iBeacons is exciting, we have been building code around the possibility of proximity for much longer and believe that it should be available on every platform, not just for the iPhone 4S, 5 and 5s and iPad 3, 4 and Mini on iOS 7.
Second, accuracy: Fundamentally, iBeacons gives you access to the proximity of devices. While the API does offer an “accuracy” of a beacon, as measured in meters, this is a very noisy reading of distance and Apple’s docs specifically say that this should not be used “to identify a precise location for the beacon. Accuracy values may fluctuate due to RF interference.” While RF interference could be from other devices, it is more likely to occur because of some simple physical properties of the objects that are likely to be in vicinity of the iBeacon device.
A quick lesson in physics helps demonstrate why this measure shouldn’t be used for exact locations. Humans are essentially large, skin-containing bags of water. Unfortunately for iBeacons, and any other system which relies on radio waves, water is excellent at blocking RF, and it is particularly good at blocking RF at the frequencies around 2.4GHz that iBeacon operates at. Add to that the fact that humans have legs, and are thus mobile, and determining anything from signal strengths starts to get very challenging.
Imagine you are in a room with a BTLE beacon, looking at an application that presents you with a map of your location in the room. If a person walks between you and the beacon, the perceived RF will change significantly, but the distance between you and the beacon is the same. Should your position on the map be moved? iBeacons would lead you to believe that you have, but this is not true. Apple refers to this as “RF Interference,” and this simple physics problem makes any solution that relies on iBeacons as a localization system suspect at best, and misleading at worst.
Now let’s assume that you want to press ahead and use iBeacons for localization anyway. Well then, a single distance measure from a single iBeacon gives you a sphere of a certain radius from the iBeacon on which you reside. On a 2D overhead map this would be a circle. But your app wants a dot on the map. So you deploy another iBeacon in the same area, and now your app can see two spheres which hopefully overlap. But the intersection of two spheres is a planar circle. So you add a third beacon and that gets you a circle which intersects with the plane resulting in a line. Just like with GPS, you need to see four beacons simultaneously in order to determine your exact location. This means a much more costly deployment, all based on the assumption that you can trust the “accuracy” measurement iBeacons is supplying, which Apple specifically tells you not to do. This is why NewAer concentrates on “actions” vs. mapping.
Furthermore, mapping indoors is less necessary thanks to signage… another reason why we avoid that approach. We can find the exit and restrooms just fine with the analog methods.
What iBeacons wants you to use instead of this inaccurate measurement is proximity, which they call CLProximity in the iBeacons API. This is exactly what NewAer has been offering for some time now on iOS and Android, and in our recently released SDKs for Windows and OSX. What’s more, on Android, Windows, and OSX we offer iBeacon like proximity to WiFi access points as well. This means your application can offer iBeacon-like functionality on these platforms WITHOUT the need to deploy a large number of hardware beacons. The beacons already exist all around you in the form of beaconing WiFi access nodes. In addition, on Android, our platform supports NFC and cell towers, allowing you even more options for beacon-like technologies to use to add proximity to your APIs, without the need for costly iBeacon deployments.
So there you have it, a marketing and deep technical dive into the technology that Apple just released, that we’ve been building for every platform for the past handful of years. Welcome to our future! We’re excited to be leading a part of it.
We are excited that Apple has realized the value of apps with access to wireless radio data, and encourage developers to take a look at our platform, which offers iBeacon-like functionality on iOS, Android, OSX and Windows, as iBeacon is limited to iOS 7 devices only. Proximity makes applications smarter, and we cannot wait to enjoy more proximity-enabled applications in the market. We can envision reward applications, movie theaters launching their relevant ticketing and trailer apps when you get near a theater with friends and even deal apps sending us nearby special offers that we actually want.
So what do you think that you can build on an open all-platform SDK? It’s a diverse world out there and proximity beacons can run on every device with NewAer. Download the SDK and learn more about it at www.newaer.com/developers
Dave, Nick and the NewAer Tech team.
But we don’t plug thumb drives into our mobile phones, and today we endure this same format elitism on these handsets. Consider some of the most commonly-used file sharing services today and their limitations;
Recent Comments