A Maker Review on Bluetooth Smart Beacons (or Apple iBeacons)
UPDATED!!! (as of 08-Feb-2014)
UPDATED AGAIN!!! (as of 19-Sep-2014)
UPDATED ALSO AGAIN!!! (as of 21-Jul-2015)
Lately, but not for very long (as of the writing of this article), there has been a bit of buzzy-buzzy around Apple's iBeacon technology. It's a mixture of software and hardware that allows iOS devices to receive one-way broadcasts from little Bluetooth "beacon" devices. It was touted to be the big "NFC killer" (NFC = Near Field Communications). I would add an asterisk to that statement: It's an NFC killer as far as retail and point-of-purchase, but probably not as far as supply chain (container tracking), security (door fobs, badges) and other non-retail uses. Edit: Apple does now include NFC on the iPhone 6 and 6+ and utilizes NFC in their Apple Pay system.
I didn't think much about the technology at first. "NFC killer" seemed like a pretty bold statement. How can you beat the simplicity of just touching your phone to a thingie at the point-of-purchase ("PoP")? It's basically "tap-to-buy." However, after some thought and discussions with business development peeps at the office, the possibilities beyond PoP started to become obvious. I started to realize just how flippin' cool this unassuming technology really was. Lemme 'splain...
What is (are) iBeacons?
iBeacons (the word or name) is a trademark of Apple (go figure, given the "i" in front of "Beacons"). As a side note, there's also a "LIVE" trademark registration for the same name owned by a company in Canada, but for a slightly different concept. I don't know if that trademark was been taken over by Apple or not, but as of September of 2014, Apple does indeed have a trademark on the name. I'm not a patent/trademark attorney. It's status is "live," so I assume it is all squared away, at this point.
We first learned of iBeacons at the 2013 Apple World Wide Developer Conference. It was a little label on a slide during the keynote presentation that wasn't really hyped at the time:
Developers who were under the usual Apple Developer NDA and who attended WWDC'13 got to see more about iBeacons technology in the CoreLocation session. The iOS CoreLocation framework makes it pretty easy to work with beacon devices and beacon regions, as I've found out experimenting with them. More on that later... iBeacons (the general term) is an overall technology that consists of Bluetooth Smart hardware and iOS software frameworks. In the press, as of late, the term is used as a generic word for the technology. I don't know that Android and other non-Apple manufacturers and marketing people will refer to them by that term, likely preferring to call the simply, "Bluetooth beacons." Who knows? It's still early in the wave of adoption.
In the context of software development, iBeacon classes in the CoreLocation framework allows iOS apps running on Bluetooth Smart Ready iOS devices (iPhone 4S, 5, 5S and 5C, iPad Mini, iPad 3rd/4th Gen) to receive notifications about proximity to a Bluetooth Smart device beacon that is configured to broadcast a special bundle of data (proximityUUID [a UUID], major and minor numbers [16-bit integer values]).
If we're talking about 3rd party beacons, like estimotes, those work with their own software development kits on iOS and Android (and probably others shortly). They may be adding some functionality or providing enhancements (or fixes) to the existing software to make the experience better.
AN iBeacon device is a Bluetooth Smart® device whose sole purpose in life is to sit somewhere and broadcast that little bundle of data I mentioned above (proximityUUID, major number, minor number) to any Bluetooth Smart Ready® devices in range. The range of these devices is upwards of 70 to 100 meters. The concept is very simple: A beacon broadcasts and does not listen. This is a one-way communication channel. It's up to the listening device to determine what to do with the broadcast data.
estimote beacon exploded (not with pyrotechnics but with 3D graphics, of course)
One cool feature in using low-energy Bluetooth devices is their ability to use very little power. Since the beacon broadcasts only tiny little packets of data and goes right back to sleep for several milliseconds up to a minute or more, they don't use much power at all. They are touted as being able to last for months or upwards of a couple of years on a single coin cell battery. In my experimentations with tod beacons (based on the Bluegiga BLE112-A module) which I flashed using firmware that was reverse engineered to work like an functional iBeacon found in the wild, I've seen the batteries drain rather quickly initially, but then stabilize a bit. I just received my developer pack of estimote beacons. I'll update this article when I have a better idea of the battery life on those products.
There is a subtle bit of terminology to clear up real quick: You will hear, "Bluetooth Smart" and "Bluetooth Smart Ready" when reading about devices relating to Bluetooth and beacons. You will also hear, "BLE," which is the acronym for, "Bluetooth Low-Energy." In fact, I think I see "BLE" more than anything else. According to the Bluetooth standards website, the proper tradename for BLE is Bluetooth Smart. A device that is "Bluetooth Smart Ready" is a device that can communicate with a "Bluetooth Smart" device. A Bluetooth Smart Ready device is the center of your Bluetooth world, as it can also communicate with legacy Bluetooth devices. "Bluetooth Smart" (sans "Ready") devices are devices that cannot communicate with legacy Bluetooth devices, but only Bluetooth Smart and Smart Ready devices. Them crazy engineers and marketers and their silly naming conventions...
Why iBeacons?
One reason for iBeacons is microlocation: It's the ability to figure out where something or someone is indoors with more accuracy than good old GPS. GPS doesn't work well inside buildings (or sometimes in urban in canyons or under ground). It's hard to get a solid GPS signal indoors to get a fix on a device's location. Yes, this can be enhanced with WiFi and cellular tower signal information, but it's still not that accurate or reliable for the indoors. For instance, it can't tell an app that I'm standing in front of a particular display or in a particular isle in a store using GPS. iBeacons is billed as being able to do just that: Accurate indoor location. I'll get to my empirical findings below.
Another reason for iBeacons is to be what NFC cannot be: iBeacons by nature are more versatile because they have better range. NFC is cool because you can touch your phone (or get pretty darn close to something) and make a connection to share data or make a purchase. But that same cool functionality is also its downfall. The range is very proximal, as in, it must be within inches if not mostly touching. Bluetooth beacons have a range of 70 to 100 meters. With some creative software engineering, you can do all that cool NFC stuff almost anywhere in a store and then some. This is why many are touting Bluetooth Smart beacons (iBeacons) as an "NFC killer." It's NFC Plus Smart Ultra (you heard it here first).
It won't kill off NFC technology completely, to be sure. There are MANY other uses for NFC beyond retail environments and such. Logistics, material handling, security are all perfect use cases for the near-field communications that NFC affords. That key fob you use to let yourself into your office is still a solid solution for security. Packages flying by an NFC scanner on a belt in a shipping warehouse... Good use of NCF. NFC tags are dirt, dirt cheap and easy to implement, even from an electronics standpoint (even hobbyists can get into quickly and easily).
Another positive for Bluetooth beacons: The hardware is in everything already because we have so many accessories that use it. NFC is an additional circuit manufacturers must add to their devices. That equates to added cost. It also means that their software must have additional code to support NFC. Bluetooth is in the core of most (if not all) smart devices. It's ready to leverage for uses other than audio (et al) accessories.
Major League Baseball did a big test run of beacons this year, already. Shopkick deployed beacons in some Macy's stores to try 'em out. GeLo deployed some in a museum in Grand Rapids, MI to test their product. I saw a retweet from Hyatt who is testing estimote beacons. More will pop up over the next few quarters, for sure.
Apple just announced that they went live with iBeacons in all of their US Apple Stores this month (December 2013). I've read an article or two about the experience. One author apparently didn't understand the technology very well. The other didn't add anything to the conversation that hadn't been written about a dozen times before. I visited three different Apple retail stores here in the Phoenix metropolitan area and didn't see anything in the Apple Store app that felt iBeacony (you heard that term here first, BTW). iBeacony: Something that is of iBeacons. I didn't purchase anything, but it looked like the app still relied on the barcode scan feature and not iBeacons. I walked everywhere in the store keeping my iPhone 5S in-hand and ready, app open. Nothing jumped out, no notifications. The only notifications I got were the GPS-based (geofencing) ones when I approached the area of the stores from the parking lots. So, it's still kinda on its way, I guess. Can't wait, either way. Fun stuff.
At meltmedia, I've got a number of types of beacons and bare Bluetooth modules on my bench and I've already written a framework of my own to work with Apple's CoreLocation more smoothly. The beacons here and they're going to be huge. If you're interested in the super-basics of the code, it's in the next section.
The "How" of iBeacons
First off, as for the hardware, I used the developer edition of the tōd beacons from todhq.com (see a close-up further down in this section). I couldn't get their default firmware working, so I used the recommended Texas Instruments CC Debugger tool to reflash the firmware with a generic iBeacons firmware I found online here: http://jenswilly.dk/2013/09/ibeacons-ready/. The tōd beacons are basically breakout boards for the Bluegiga BLE112-A Bluetooth modules, so flashing them with your own firmware is trivial. Instructions for that can be found at Bluegiga's website.
Once I got the three tōd beacons reworked with the new firmware, I wrote a quick sample for an imaginary museum. I placed each of the three beacons on artwork hanging on the walls around meltmedia.
I haven't worked with the estimote SDK, yet. I've only used their sample app. The findings are similar as far as the reliability of the signal readings and ranging. I'll take that SDK for a test drive shortly and post an update after. They're picture below:
UPDATE... At meltmedia, we've been working with beacons and building a generic, versatile and extensible beacon management system with matching apps for iOS and Android. We're implementing algorithms in-house for making the user experience (and the developer's, for that matter) more enjoyable.
In tinkering, we've come across the UpNext Beacon. It looks like they're still in prototyping stage, but what I've seen in their Twitter feed look promising. It appears they're building their own circuitry, not using a pre-built module (e.g. Bluegiga BLE-112A or the like). I can't see from photos what the main MCU is on the board, but it looks cool, nonetheless. When I get my hands on some, I'll post my findings here, of course.
The nice thing is that they're quite responsive on Github. One of our developers at meltmedia has already done a pull request to their code for iOS and they've rolled it in. I also like that they've not reinvented the wheel on Android and they've based their code on the Radius Networks BLE beacon stuff. As of January 20, 2014, looks like some people have gotten ahold of their beacons (based on tweet in their feed).
iBeacons Development, Code, Hacking... Whatever it takes.
iBeacons classes are available in the CoreLocation framework in iOS, but I don't believe it's available in desktop OS X devices running Mavericks (that I could find in a quick check, anyway). I haven't verified this fact myself, but this article from Blended Cocoa indicates it is iOS-only. The article does show how to use a Mavericks desktop device as a beacon if it has the latest Bluetooth 4.0 hardware inside.
I'm not going to dig super-deep into how to get a module up and running. estimote and tōd and a number of others make modules that are ready to go and most offer their own SDKs. As for the iOS part, below is the bare minimum.
The snippets above use the CoreLocation framework in iOS. If you're not familiar with the basics of iOS development, don't ask how to do it here. Go learn on the 8,403,447 blog, site, pages out there that tutor and train on that topic. The code above is partial and assumes you know how to do the other stuff required to make it work.
In the iBeaconSample.h file, I import the CoreLocation framework. The iBeaconSample adopts the CLLocationManagerDelegate so it can get notifications from the Location Manager. We'll be setting up a CLBeaconRegion, so there's a property for that as well as one for the locationManager.
In the implementation (iBeaconSample.m) file, the -initRegion method sets up the listening and whatnot. You need a proximityUUID to look for. Different beacon vendors use different UUIDs. Some may not even use the CoreLocation framework and opt to use direct Bluetooth access in iOS. I've only tinkered in depth with the tōd and bare Bluegiga BLE112-A modules myself and on those modules I put some firmware I found on the web that works as a nice, simple generic iBeacon.
The CLLocationManagerDelegate protocol lets your class pick up on some delegate calls for receiving notifications when beacons go in and out of range. Those are the following method calls:
-(void)locationManager:(CLLocationManager *)manager didEnterRegion:(CLRegion *)region
-(void)locationManager:(CLLocationManager *)manager didExitRegion:(CLRegion *)region
-(void)locationManager:(CLLocationManager *)manager didRangeBeacons:(NSArray *)beaconsFound inRegion:(CLBeaconRegion *)region
In the didRangeBeacons method snippet, I pasted a dump of the NSArray of CLBeacons you get when that method is invoked. In theory, the UUIDs of all of those beacons should match the one you asked for in your initWithProcimityUUID call above.
That's the bare frame of an iBeacon app. Again, not in depth, just a quick view of the core of it. You wrap that stuff in whatever kinda app you want. There are detailed samples out on the web, which is how I got everything working. If time permits, maybe I'll post an article with a more detailed code walk-though along with the how-to steps on flashing a Bluegiga BLE112-A module to your liking.
Tinker for Yourself, No Code!
We've (meltmedia) created a simple app for playing with beacons called, "Beacontrol" and it requires ZERO software development on your part. Simply download and install the app from the Apple App Store or the Google Play, let it find beacons around it, assign actions to events for those beacons and test away. It's a great way to find out the possibilities without the investment of time and resources in developing a custom app. It's FREE and you can use it to prove out your ideas to the powers that be.
Q: Any Items on the Bluetooth Beacon Bummer List?
A: Yes.
The microlocation isn't what it's sold to be, in my experimentation and as I read the literature. When I first heard about these things, I was thinking the frameworks were going to triangulate the location of devices on a sales floor, for instance, and allow the app to trace customers around the premises that way with high accuracy. Not so. In my experimentation, the signal is pretty weak and fluctuates quite a lot and is easily interfered with (human bodies absorb with signals quite well, for instance).
My findings were disappointing, initially. I had starting evangelizing about the technology and that made me feel it was my responsibility to try to smooth out the readings we were getting from the test beacons. For my in-house demos at meltmedia, I wrote my own version of Apple's CLBeacon class that helps clean up the wacky signaling we were seeing initially. Without the new beacon class and some error correction, the beacons appear and disappear and bounce all over the place. With the smoothing the beacons don't seem to be so jumpy and the technology seems close to how it's being sold in marketing material.
Another item on my Bluetooth Beacon Bummer List is the battery life. Given what I'm seeing, at the moment, I'm not completely convinced the batteries will survive a year or more. We will see. I could be wrong, as I am not a electrical engineer by any stretch. Just know that the rate of drain of the batteries I'm using with the Bluegiga BLE-112A modules (based on the Texas Instruments chipset) is faster than I thought it would be. Perhaps it's a function of normal coin cell battery usage. I don't know. I'll report back here on my battery life observations as time goes on.
List of Some Bluetooth Beacon Vendors
I've been trying to find all the hardware vendors I can for this technology. New ones have been popping up in my searches. This is the list I have as of today:
If you have any question, feel free to hit me on in the comments or via the Contact page.