A Little More on Beacons- Promise and Frustrations

Last week, Beacon Fever bit me, as I described here. Since then, I’ve made little progress in actually doing anything of real-world value with the three Qualcomm Gimbal beacons that I have on hand. But that doesn’t mean I haven’t gained a bit of an education in the few hours I’ve noodled around with them as I’ve consorted with The Google on where to go next. Allow me to share just a little more on Beacons, then I’ll likely put the topic away for a while.

What I’ve Learned:

  • There is a good variety of beacon hardware out there. Here’s another list
  • If you don’t want to $pend, Android and iDevices can be configured to act as beacons for testing
  • There are lots of mobile beacon management and scanning apps out there- some from the beacon manufacturers and some from 3rd party developers
  • The entire proximity paradigm with beacons is built on leveraging “degrees of nearby-ness” like near, far, immediate vicinity, out of range
  • Beacons can be USB powered, or battery powered. If using battery, there will be administrative burden of battery upkeep in large deployments over time
  • Beacons don’t just magically come to life, you have to activate them and do a basic config
  • Every beacon maker seems to have their own management console
  • You can see where heavy beacon use would very much be “another thing to manage”, despite having really cool real-world use cases
  • A “UUID” gets assigned to all beacons in an organization that will be part of the same “system”
  • Each beacon can make use of a Major and Minor field to further segment/identify them
  • Without an application to use with them, beacons aren’t real exciting
  • To leverage beacons, SOMEBODY has to do some coding, and there are a number of frameworks to do that in
  • For people like me, who are definitely not endowed with coding skills, some companies are trying to make “getting started” a little easier
  • There are a lot of beacon videos on YouTube, and blogs from others’ efforts to be had online
  • It doesn’t look like all vendors beacons are welcome in each other’s development environments
  • Connected users “opt in” by enabling Bluetooth on their smartphones, tablets, etc.

That’s the short of it for me, so far, on actual knowledge gained. I also tried to do more with my Gimbal beacons, but found some frustrations- like simply setting the UUID, Major and Minor fields. It looks like other vendors make this a lot more intuitive, but perhaps my lack of experience is the problem here. On my Gimbal developer account, I understand each individual word but get foggy when you put it all together in phrases and sentences. There is a Gimbal iOS management app, but none for Android that I have found yet.

I did discover a couple of promising leads for myself in learning more, as a mental-midget when it comes to programming. Estimote makes a popular kit that comes with three beacons, and from what I can tell their app-building tools seem to have folks like me in mind. But… each kit is $99, and indoor location requires two kits (for some unspecified reason). I’m not ready to drop $200 on beacons yet, but maybe at some point.  And… Meridian (An Aruba HP company) also seems to understand that some of us need all the help we can get. They put a very friendly face on getting started, and I hope to learn more about this product set/application framework in the months to come.

So… that’s all on beacons from me for now. If anyone reading gets further with these fascinating little transmitters, please share what you learn.

5 thoughts on “A Little More on Beacons- Promise and Frustrations

  1. Wojtek Borowicz

    Hi Lee,

    This is Wojtek Borowicz, I’m a Community Evangelist at Estimote. Thanks for sharing your thoughts on beacons. Just wanted to clarify why our Indoor Location SDK requires two devkits. The mapping and location algorithms require at least one beacon per wall. And since you don’t really stumble upon many triangular rooms, you need at least four beacons 🙂 Since one devkit contains three beacons, you need two devkits to set up Indoor Location.

    You might wonder why, in that case, we have 3-piece devkits. The answer is simple: we introduced Indoor Location SDK more than a year after Estimote Beacons were available. It’s a separate product from our original SDK, so if you’re looking for proximity-based features, you’ll be fine with a single kit.

    Cheers.

    Reply
  2. wirednot Post author

    Thanks for the reply Wojtek. Though I still don’t understand why you don’t simply introduce a devkit with four beacons under a new new product offering!

    Reply
    1. Wojtek Borowicz

      I’m not saying we won’t =) But shipping beacons is way more complicated than simply stuffing them in a box. Changing it would require things to happen from packaging to backend, so it just takes time.

      Cheers.

      Reply
  3. Pingback: Quien es Mas Macho? A Beacon Battery Brouhaha! | wirednot

Tell me what YOU think.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s