Beacons are pretty cool little devices. All they do is send out a tiny piece of information repeatedly. When they get close to the beacon, any device that’s listening for that information can be triggered to do something. Communication is only one way, from the beacon to any devices in the area. The range is typically somewhere in the neighborhood of 30-100 feet so the location is fairly precise.

Here’s a potential beacon application and let’s assume that Starbucks has installed beacons in all of their stores.

(This is somewhat simplified but this is the basics in a nutshell.)

• A beacon in your local Starbucks sits there sending out a very small but unique chunk of information called a UUID.
• Someone with the Starbucks app installed walks in the store. (The app is waiting to hear from any of those Starbucks beacons.)
• Once the app recognizes the UUID it checks it against the listing of beacons it knows about and figures out which store you’re in. It can then be helpful and do something like this:
  • Offer you the option to order “the usual”
  • Show you a daily special
  • Let you know the approximate wait-time.

With enough information about your previous orders and a little logic, it could change the order it suggests for you to save you some time.

• Every time you stop at this Starbucks around 7:30 AM you order a venti black coffee.
• When the Pumpkin Spice Lattes come out in the fall, you always switch to those.
• When you swing by Starbucks in the afternoon maybe you’re on the way to drop the kids at practice so you get 3 drinks and some yogurt.
• Any time you come in after 5PM, you order decaf.

If done right, it’s a little creepy but also helpful.

Right now the most common beacon standard has been iBeacon from Apple. Unfortunately iBeacons don’t work with Android. That has really slowed any widespread adoption. (Android runs on 1/2 of the smartphones in the US and 80% worldwide). If you’re a retailer, you probably wouldn’t be interested in implementing anything that excludes at least 50% of your customers.

Google’s Eddystone is open source and cross platform so it removes that limitation. It also provides some other benefits over iBeacons. iBeacons can only broadcast their UUID and nothing else. In order for that to be useful, the receiving device has to be listening or paying attention for that UUID. With iBeacons you have to have the vendor’s app installed if you want to receive their benefits.

Eddystone removes this limitation since it can send more types of information (called frames). One of the most helpful frame types is the URL. Without having a specific app installed, you could still be prompted with special offers or location based information.

• At a vending machine, you could be prompted with a special offer or a coupon.
• At a bus stop, you could be directed to the Google Maps application and see the bus schedule as well as the current bus positions.
• When walking in to a classroom to teach, the system could offer to display instructions for the room operation.

Eddystone can also transmit telemetry data. Since beacons are often battery powered, they need to be changed periodically. It seems likely that the beacons at Starbucks could transmit their battery state to people with the Starbucks app installed on their phones. That information could then be forwarded to the IT group so they can proactively monitor the health and replace them prior to failure.

There are obviously a lot of issues to work out, like how to stop every restaurant, store, and vending machine from spamming my phone. It will be interesting to see how Apple and Google come up with ways to balance user frustration and privacy with the benefits that beacons might provide.

Source: Meet Google’s “Eddystone”—a flexible, open source iBeacon fighter | Ars Technica