The Future of Beacon Technology | Guest Post

Guest Post by Jakub Krzych, CEO and Co-Founder of Estimote

Jakub Krzych is CEO and Co-Founder of Estimote, Inc.

In this (epic) guest post, he provides his thoughts and insights into the future of Web and mobile apps, the introduction of Google Eddystone and beacon support, and his vision for what it takes to bring digital context to the real world.

Mobile & web apps and the future of beacon technologies

It’s been almost two years since Apple launched iBeacon, its own beacon format, and kicked off the contextual computing revolution. For the first time in computer history, a massively distributed and popular consumer device such as an iPhone was able to sense micro-location information broadcast by tiny, battery-powered radio devices.

The most important innovation was removing all of the friction in user interactions. Before iBeacon, it was possible to use QR codes and pass contextual information to the phone, but it was inconvenient: pulling out the phone, opening a QR code scanning app, focusing the camera on the code, etc. With beacon technologies, users just need to enter a beaconified location and a pre-programmed action will automatically appear on the screen—frictionless.

Apple made this technology elegant, privacy-oriented and straightforward. They anticipated billions of devices advertising their presence, thus they designed the iBeacon format to consist of 20 bytes containing a static identifier (UUID + Major + Minor)—enough to number all the objects on earth.

When a phone discovers the beacon and picks up the identifier, it triggers an app and the action assigned with that beacon. That is the most beautiful part of this elegant design: an app searching for a specific beacon is required. That means this technology is opt-in only. Apple knew that powerful and frictionless experiences might also put users at risk of being spammed or tracked without their knowledge. That’s why users have to explicitly opt in by simply downloading their favorite store or brand app. By doing that, they allow app creators to push notifications to their phone or to use location services.

When a user feels that the app shouldn’t use her location or that there’s not much value behind the app, she removes it. That is actually why many app developers concentrate on delivering amazing value to users.

If a user boards a train, arrives at the destination, and gets a notification with the ticket automatically charged to her credit card, that would be a magical experience. Or if she arrives at the airport and the app says exactly where to go and she is checked in by walking to the gate, that would be an amazing frictionless passenger experience.

However, it’s one thing to broadcast a static identifier and trigger hard-coded actions and another to engage with users through dynamic app content.

When a user walks into a furniture showroom and approaches the sofa she likes the most, she can see the picture, description, or price on her smartphone. But this data might change over time. In order to maintain it, developers might either hard-code all the new data into the app and push the new version to the App Store, or the app might simply fetch the data from the server by passing beacon identifiers to CMS solutions, where marketers could keep the content up-to-date.

Eddystone by Google and the mobile web

But what if we want to interact with many brands and many airports or retail stores? Do we need to download all these apps? Not really.

Google recently released a different beacon format called “Eddystone.” Unlike iBeacon, it doesn’t broadcast only an identifier, but also a pre-programmed website URL. So instead of having many different apps fetching contextual data, we might have just one, and it can simply be the web browser.

A similar shift happened in the early ‘90s. There were many standalone apps exchanging data with servers using different data formats. There was, for example, the FTP protocol and the FTP client app, IRC and its client, Usenet, Gopher, Mail, etc. Over time, most of these services moved to the web and were consumed by the internet browser, which could run on any computer, any processor architecture, and any screen.

It was faster and cheaper for developers to design, build, distribute, and update web apps. Broadband and modern browsers made it impossible for users to distinguish the so-called Web 2.0 apps such as Gmail, Google Maps, and Google Docs from their standalone competitors like Outlook or Excel.

That trend is not visible in the mobile world yet. Most of the popular services such as Snapchat, Facebook, or games still run as standalone native apps. It’s because of performance: native apps can run much faster, they optimize battery consumption, and they have access to low-level peripherals such as built-in sensors, cameras, memory, etc.

Over time, the defragmentation of mobile devices, platforms, and screen sizes might again result in a shift towards web apps, especially if browsers become faster and gain more access to low-level peripherals. Google, for example, recently released a Chrome browser for iOS that can natively scan for URLs broadcast by beacons. This might become the promise of a single app talking to many beacons.

Web app or native mobile

One app installed on the phone and responding to all beacons might be an elegant solution to the app distribution problem.

Nevertheless, the most progressive brands and retailers, with their innovative mobile teams, will keep investing in their own loyalty or in-store-experience apps. They know that the only way to have  full control over the data, branding, and end-to-end user experience is via standalone apps installed on consumer devices.

They also know that the only way to convince users to download these native apps is to provide them with amazing value. Beacons help with that, by removing the friction and making apps smarter.

UI and UX designers can leverage beacons to understand the microlocation or context of their users. Also, by using additional data from sensors, such as motion or temperature, user interfaces can be simplified or sometimes completely reduced.

Beaconified apps help their users focus on the main goals behind the apps and can impact important metrics such as engagement, usage, or retention.

Scaling beacon deployments

The typical app beaconification process starts with experimentation and prototyping. A proof-of-concept app is created with just a few beacon dev kits. Pitched internally, it can often attract attention from product people and decision-makers. Once an app is budgeted and the mobile team allocated, the proper app development process starts. After few weeks or months of app development, beacons are deployed to the production environment.

For airports, shopping malls, or huge retailers beaconifying enormous spaces and thousands of locations, deployment might be a logistics nightmare. They will most likely optimize for the simplicity of the installation and maintenance as well as the cost of that operation. It’s easy to calculate that a workday of deployment crew to complete the installation, configuration, and testing, multiplied by thousands of stores, can result in multimillion-dollar bill.

That is the main reason it’s unlikely that large beacon deployments will install beacons that require power cords, manual configuration, and floor-plan assignments. Even tiny details such as the lack of a built-in adhesive layer can impact the efficiency of the deployment.

On batteries and hardware upgrades

For the same reasons, it is unlikely that retailers will replace batteries in their beacons. The cost of that operation would be higher than installing new ones.

Once installed, beacons should last long enough that they can be replaced with the new generation: technology cycles in that industry move fast. Last year, Bluetooth SIG released two updates of their BLE standard and one of them requires completely new hardware for both the beacon and the mobile phone. So three-year-old beacons will be obsolete anyway.

However, software or hardware upgrades shouldn’t affect applications running on top of this infrastructure. The most progressive beacon companies will not only optimize the cost of deployment but also the simplicity of the migration.

For all of these reasons, it’s clear that retailers won’t install multiple beacons broadcasting exclusive data formats for different mobile platforms or apps. We shouldn’t expect that there will be beacons only for Microsoft, Google, or Facebook. It just won’t happen.

There’s nothing preventing beacons from broadcasting as many packets as we want. They’re just tiny computers, after all.. These packets can also consist of whatever data we want. That’s why any customer who purchased Estimote Beacons in the past can simply update them over the air and turn on an Eddystone packet or switch to iBeacon at any time. No new hardware is required. At Estimote, we are committed to supporting whatever the popular future beacon format is.

We expect rapid development of beacon technologies, new formats, sensor integrations, and security updates. That is why we advise our customers to choose a beacon partner wisely and to make sure purchased beacons can be frequently and effortlessly updated with new firmware.

Remote fleet management

An elegant and easy fleet management technique including firmware updates isn’t a huge challenge. Each and every beacon is a tiny computer and can connect to phones or other beacons. It can also exchange configuration data, including firmware.

That is why at Estimote we do not have additional devices or hubs to configure or upgrade our beacons. All the beacons can be upgraded over the air, and we use technology already built-in to the phones. When users visit different locations and their apps interact with beacons, they can simply connect and update beacon configuration or firmware in the background: it’s just a few kilobytes, so there is no impact on usage. And it’s 100% secure and respects the user’s privacy—no personal data are collected or transferred.

Because of the operation cost argument mentioned before, there’s no point in installing additional hardware to remotely manage beacons. Whenever beacons are installed, users with compatible apps should be in the proximity. After all, if there are no users around, why are beacons there?

On security and risks

Part of the fleet management routine should also be security updates. Many retailers or airports investing in beacon infrastructures are very sensitive to any potential vulnerabilities of beacon networks.

We can easily imagine airport passengers receiving notifications about cheaper flights to the same destination from a competitor airline exactly when they check in at the gate. Or, consumers visiting retail stores might receive coupons from E-commerce apps detecting their location in specific departments, causing a showrooming effect.

All of this could happen if competing apps sense the presence of beacons and remember their static identifiers. Since beacons are tiny computers, they can dynamically compute these identifiers so that only authenticated apps could decode them. This is exactly how we implemented Secure UUID mode. Our customers who want to protect their networks can simply turn on Secure UUID, and competing apps won’t be able to easily resolve the location.

Of course, every computer technology is hackable. But even if that happened, the risk is still very low, because there’s an additional layer of security: the Apple App Store approval process. Apple would never agree to publish in the App Store software malware that would basically have access to information it shouldn’t. These days, App Stores are the main distribution channels for apps, so respected app creators won’t risk dealing with Apple on that front.

Infrastructure sharing and innovation acceleration

Once the network of beacons is built and secured, there might also be opportunities to share it with other app creators. That is why we built a feature we call “beacon infrastructure sharing” on top of our cloud and beacons. Our customers can allow any app to take an advantage of the infrastructure and the context established in the venue.

We see retailers enabling different brands to use beacon infrastructure so their apps might trigger notifications when customers visit a partner retail environment. The same with airports, which might share different terminals or gates with different airline or duty-free apps.

We should expect that in the future, locations that are attractive and offer value to visiting consumers will sell access to their beacon infrastructures, via exactly the same model we’ve seen on the web with popular websites and ads. If someone creates a website with high traffic, they can make part of that website available for banners, cookies, or widgets as long as those components don’t confuse users. Otherwise, that website would lose them quickly.

With the security component and infrastructure sharing, any beacon network owner can invite third-party apps and offer campaigns for a specific period of time. For exactly the same reason that the visual language of layouts and banners have been used on the web by agencies and web owners, there must be similar visual language to manage campaigns and interactions in physical venues. That language has been already created: it’s called “floor plans and maps” and has been used by retailers, airports, museums, and their suppliers for years.

Indoor location with beacons

Being able to quickly deploy hundreds of beacons and see them immediately on a floor plan has been always a long-term goal for Estimote. Every day we get closer to that vision because of our heavy investment in beacon-based indoor location.

We’ve built an amazing data science team that has created robust indoor location algorithms and SDKs that anyone can build into their apps to achieve an accuracy of locating people and their phones inside a building to within just a few meters.

In order to make this extremely simple, we invented an auto-mapping tool. Even if the deployment crew doesn’t have a floor plan, they can map the space automatically using our Indoor Location App from the App Store. They just need to walk around the room once. The mapped space and beacon locations are automatically saved in the cloud, where they can be edited, managed, or shared with third-party apps.

There is also an analytics component venue owners can use to better understand the behavior of their users in their locations. The RESTful API makes it extremely simple for integrations or deeper insights.

The privacy issue here is solved by the same opt-in mechanism explained before. If users are offered strong value such as wayfinding, asset tracking, etc., they will download an app with a built-in Indoor Location SDK and explicitly agree to be located.

Knowing the exact location of people and being able to resolve their context is one thing, but having more insight into their interaction with the objects around them is another. Both of these components can help to design amazing context-aware mobile apps and experiences. That is why at Estimote we have also invested heavily in sensors built into beacons and invented “nearables.”

Using tiny beacons in the form factor of stickers, users can turn ordinary things into smart, connected objects. These objects can broadcast into the air not only their presence, but additional metadata such as temperature, motion, orientation, and state duration. This is all possible because of our very own connectionless Nearable Packet, which we introduced last year long before Google started to work on Eddystone.

Apps for the physical world

If you combine all of this—beacon infrastructure sharing, easy-to-use, and precise indoor location, plus nearables—you will very quickly understand where this is going. Finally, all these components make it possible to build real apps on top of physical locations that are full of objects. It’s a tremendous shift from apps designed for phones to apps designed for airports, retails stores, or museums.

For example, Estimote apps designed for one museum can be “run” on top of any museum that is “compatible.” A scavenger app built for one retail store can be scaled to thousands of stores. That is the long-term vision behind beacon technologies: to make it extremely simple to develop, configure, deploy, and distribute apps for physical locations.

At Estimote, we have been executing that vision since the day we launched this project. We interact with many pioneers in the community, and we are very proud of their help in making this technology better every day.

We are extremely excited that all the major players, including Apple and Google, are fully on board with beacons, and we look forward to seeing what comes next and how contextual technologies will evolve. The most exciting part is the fact this is still at an early stage, with many innovations and pioneer inventions ahead.

Share Your Thoughts

Join our e-mail list for more on iBeacons and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

Come on – let’s give a shout-out to Jakub. Epic post – and lots to think about. What do you think he gets right (or wrong) about the future of mobile and web apps in the era of Eddystone and iBeacon?

Tutorial: Using Beacon and iBeacon Technologies on Your iPhone / iPad with PubNub | Guest Post

iBeacon has been quite a buzzword since the release of iOS 7 when Apple enabled all their iPhones since the 4S with this new BLE technology.

The iBeacon is simply a protocol that takes advantage of the new Bluetooth Low Energy technologies. It has been easy for companies, aside from Apple, to emulate similar protocols such as estimote or AltBeacon. As a result, we thought iBeacon and PubNub could fit together in some pretty cool ways.

In this article, we will explain how the iBeacon protocol works by taking a closer look at how the emitted data is actually structured. We will move onto how to use the iOS sdk to detect and emit beacons. Finally we will try to see if we can use other protocols on iOS devices.


iBeacon Detecto
iBeacon Emitter


What an iBeacon’s Advertisement Looks Like

According to the Bluetooth v4 specification, a beacon advertises a data package called the Scan Response Data.

This Data can be up to 31 bytes. If we create a smaller scan response, the remaining bytes will be filled with as many 0s.

The scan response is divided into what are called AD structures. They are sequences of bytes of various size, with a predefined structure that goes as follows:

  • The first byte represents the number of bytes left to the end of the AD structure. This allows a receiver of this structure to know when it ends and when a new AD structure starts.
  • The second byte is the ID of an AD structure type.
  • The rest of the bytes are data that is structured in a predefined way depending on what AD type was defined by the previous byte.

That’s all there is to it. Just a succession of AD structures.

Most beacon protocols have only 2 AD structures, which are as follows.

The first one has 3 bytes:

  • The first byte will be: 0x02 because we only count the following bytes.
  • The second byte is: 0x01 which indicates we have a “Flag” AD type.
  • The last byte represents theses flags. These flags express whether the emitting device is, in “Limited Discoverable Mode”, “General Discoverable Mode”, etc… The byte is computed the following way:

The 5 flags are represented by the first 5 bits of a byte. The value of these bits defines whether the flag is ON or OFF. The binary number is then written as a hexadecimal value which will be advertised. An example may clear things up:

bit 0 OFF LE Limited Discoverable Mode
bit 1 ON LE General Discoverable Mode
bit 2 OFF BR/EDR Supported
bit 3 ON Simultaneous LE and BR/EDR to same Device Capable (controller)
bit 4 ON Simultaneous LE and BR/EDR to same Device Capable (host)

The resulting binary value hence becomes: b00011010 Converted into a hex, we get: 0x1A

That’s all there is to the first AD structure! Let’s look into the second one, which contains most of the information we need!




The second structure can be of a different size according to the protocol. Let’s look at the detected scan response emitted by an iPhone.

  • First byte is 0x1A (26 in hexadecimal).
  • The next byte is always 0xFF which means we have a “Manufacturer Specific” type of AD structure.
  • As a result, the 2 following bytes represent the company identifier as defined on For an iOS device, the manufacturer is “Apple Inc.” whose company ID is 76. In hexadecimal value, this is equal 0x004C. The ID, written as little endian, takes up 2 bytes. Here it will be 0x04C 0x00 in this order.
  • The rest is Manufacturer specific data.

For the iBeacon protocol, the 2 first bytes of the manufacturer specific data are always 0x02 0x15. The next 16 bytes are a UUID representing the advertiser’s organizational unit and the 4 following bytes are going to be the major and the minor. They are 2 bytes long numbers.

There is a final byte at the end of the data structure called the TX Power, which represents the device’s signal reference intensity a meter away from it. This value is held into a single byte which is the two’s complement of the signal’s intensity in dB.

Computing the distance to a Beacon

When a scan response is detected by a device, it also determines the intensity of the received signal. Hence the iBeacon protocol uses the reference value held in the TX Power byte and compares it to the intensity of the signal effectively received. This allows iBeacons to compute an estimation of the distance to the emitting beacon. This is a great quality of iBeacons, but note that the intensity of the signal depends vastly on existing obstacles or simply on the geometry of the room. As a result Apple does not recommend to use iBeacons to determine precise locations.

The algorithm used to compute the distance is not open-source, although others have tried to emulate matching ones.

How to Use Apple’s SDK for iBeacon

Emitting or detecting iBeacon data is organized around iBeacon regions.



These regions are instantiated with optional initial values such as the UUID, major or minor. In the case of detecting an iBeacon, this region object defines what type of beacon scan response should be detected. For example, if you provide a UUID, only the beacons with matching UUIDs will be detected, regardless of the major and minor. If you also provide these values, you’ll detect only beacons matching all three of these values.

When emitting an iBeacon signal, the region object based on the values of the UUID, major and minor generates the data structure to be advertised.

As you may have guessed, this makes the iOS SDK very simple to use! For more detailed examples, check out our beacon emitter and beacon detector tutorials.

However, it also makes things much more difficult when you are trying to use a protocol different from iBeacon! Let’s look into that immediately.

Using Apple’s SDK for AltBeacon or Estimote

We have seen how complicated the scan response can be, and how Apple simplified the SDK so that we just need to enter the UUID, major and minor to set it up. However, with other beacon protocols, the scan response has a different structure which Apple makes hard for us to tweak.

Detecting other beacons

When detecting iBeacons, the locationManager:didRangeBeacons:InRegion: method is called on the event of a detected signal. However, this is very specific to iBeacons. When detecting another BLE signal, you must not use a CLLocationManager instance, but a CBPeripheralManager which detects ANY BLE advertisement EXCEPT iBeacons, which will be blocked.

The callback that will be triggered upon detection is centralManager:didDiscoverPeripheral:advertisementData:RSSI: . The advertisement data that is returned is a dictionary holding 2 objects; one for each data structure of the scan response. Here is a sample response from an AltBeacon.

kCBAdvDataIsConnectable = 0;
kCBAdvDataManufacturerData = <1801beac 0cf052c2 97ca407c 84f8b62a ac4e9020 00090006 c5>;

The top element represents the first, three bytes long, “Flag” data structure. The second one represents the manufacturer specific data following the bytes describing the size and type of the data structure.

This is good news for us, and means we can detect any beacon information!

Emitting another beacon

We have found things are much trickier when it comes to advertising custom beacon scan responses. We can try to build an NSDictionnary similar to the one detected and try to advertise it using the startAdvertising method.

However the advertisement data keys available for detection are limited to only CBAdvertisementDataLocalNameKey and CBAdvertisementDataServiceUUIDsKey when it comes to advertising the data. It is Apple’s way of preventing us from building manufacturer specific data outside of the iBeacon protocol.

So there you have it! We went through apple’s iBeacon protocol, looked at how we could detect other beacons and apple’s restrictions to advertising data. We have some working examples and tutorials to build an iBeacon app on Swift – check out our beacon emitter and beacon detector tutorials, which allow you to get the best out of iBeacons by establishing a two-way communication which beacons aren’t usually capable of. The reason why we think it’s great is that we use PubNub to enhance beacons’ capabilities while still keeping their low energy consumption asset! Sweet, right?


Guest Authors 

Norvan Sahiner and Sunny Gleason wrote this tutorial series on behalf of PubNub, a platform that allows you to build and scale realtime apps for connected devices.

iBeacon Buffet: The Next Generation of Beacons Is Better (And Harder) Than the Last

Beacons just keep getting better. And the choices more difficult.

With manufacturers creating a new generation of the little devices it isn’t just battery life or reliable firmware you need to think about – but also choices about security, vendor lock-in, or concurrent technologies.

Even the definitions have shifted – you see a lot less talk about iBeacon and more references to BLE. Apple took the lion share of attention with its iBeacon specification, but as Android and other devices starting coming on board the larger industry started to understand that there wasn’t anything particularly special about an iBeacon – it was more of a branding move by Cupertino.

Apple made beacons simple. But as retailers, brands and venues have started understanding what a beacon really is,  the decision of “which beacon” has become far more complicated.

Beacons As Profound Change – And Challenge

How do you explain to a brand or retailer, for example, that even though BLE is a universal standard you still need to add a few digits to your advertising packet for a Samsung beacons, remove a few digits and change your broadcast interval for it to be an iBeacon?

It’s simple enough to say that “beacons work with all devices”, which is true – but can you avoid delivering beacons which end up being locked out by Samsung (for example) when they launch Proximity?

Regardless of the cross-platform challenges, we also saw a pronounced shift in the latter part of 2014 from “beacons as buzz” to “beacons as infrastructure” – and companies started grappling with the larger challenges of deploying, maintaining and building user experiences around beacons at a much larger scale than a few pilot stores or a museum exhibit or two.

These larger deployments and multi-year road maps are mostly happening under the radar. The conversations we have with customers, for example, have shifted from educational and pilot-focused to much larger multi-year projects with greater clarity around KPIs and a deeper awareness that beacons represent one prong in a larger strategic struggle.

We’ve said that beacons are “the gateway drug to the Internet of Things”.  Brands and venues have started grappling with the fact that while beacons make proximity possible, they also pose a larger question of how you create user experiences when everything can be digitized.

Beacons can help tell you that you’re in front of the cookie aisle. But once you’ve figured THAT out, you need to ask how the consumer got in front of the cookie aisle in the first place, where they’ll go next, and how looking at a bag of cookies changes when you can also deliver media, digital coupons, or an ability to purchase right at the shelf.

Beacons create a simple-to-understand interaction. But their implications for an always-on, digital-everywhere, contextually-relevant consumer experience drives to the heart of how we define a physical space in the first place.

5 Questions To Ask About Beacons

The number of beacon options is also expanding. And the manufacturers are moving “up the stack” – adding more and more services on top of their beacons while at the same time shifting from relatively ‘dumb’ beacons.

If you’re shifting from pilot deployments to beacons-as-infrastructure, new questions come into play:

  • How can you remotely monitor and manage a beacon, does it require a WiFi connection to do so, or does it embed management as a payload in the user’s app?
  • What specifications does the beacon broadcast for, and will it be able to simultaneously support (for example) iBeacon and Android specifications?
  • How can you create an authentication layer, do you need one, and what will the larger implications be as beacons shift into being a key part of the payments ecosystem?
  • Are the beacons secure? Do they need to be? What does security mean? What’s the difference between hijacking and spoofing?
  • What’s the vendor road map for Bluetooth 4.2?

And, in the “your guess is as good as mine” category:

  • Are the beacons future-proof against changes or innovations by Apple, Samsung, Google and other vendors?
  • Are you willing to make a bet on the Physical Web?
  • How quickly should we migrate to dual-mode BLE/NFC beacons?
  • Do your beacons work with location mapping technologies, do they need to, and can your beacon be made “self-aware”?

A Buffet of Beacons

This week felt like Christmas, and the post office must think we have a very large family. But it was boxes of beacons arriving at the front door.

Some of the latest beacons, platforms and announcements give us a hint of what’s in store for 2015:

Radius Networks RadBeacon X

Best known, perhaps, for their USB beacons and some of the best code examples and insights on the planet, Radius Networks got batteries for Christmas. Their RadBeacon X2 and X4 tout a rugged indoor/outdoor design and take a subtle dig at other beacons which often lock out your ability to control the UUID numbers:

You pick the identifiers for your project. Don’t get stuck with UUIDs from your beacon vendor that might overlap with other deployments.

But just as important is its dual-mode, with Radius saying that “RadBeacon is an all-weather, long-life Bluetooth Smart™ proximity multi-beacon using iBeacon™ and AltBeacon™ technology that provides seamless proximity services for both iOS and Android mobile devices. ”

Kontakt Gets Cloud

Kontakt meanwhile has been trying to slip its Cloud Beacon in for the holidays – but is facing a 6-8 week delay in shipment and is currently promising a mid-January delivery. A little late for Christmas maybe, and the delay is a misstep by the company which has been working hard to overhaul the service layer for its beacons.

The launch comes on the heels of Estimote launching its own cloud and fleet management services. While on first glance, the approaches might seem the same, there are big differences in approach.

Both launches point to subtle differences in the way companies are handling security, UUID rotation and over-the-air firmware updates.

Gimbal Series 21

Gimbal, the Qualcomm spin-off, continues its aggressive push to be the “big infrastructure” provider of beacons with the launch of its Series 21.

The company, which has taken indirect flak by outlets like Buzzfeed is highlighting its consumer-friendly privacy policies:

Gimbal has earned TRUSTe’s certification for consumer-controlled privacy, is a member of the Future of Privacy Forum and delivers industry-leading security via its secure software and transmissions.

Advertising and Connected Spaces

OK, they’re not actually beacons. But one is a home town favourite of ours – and an indication of how there will continue to be products and services that build out on top of all the beacons and services, whether Urban Airship or

Juice Mobile launched a sister company, Freckle IOT to make a play to be the platform for beacons (and other sensors), with a focus on outdoor media:

“Freckle permits brands to establish and maintain personalized consumer relationships, while allowing advertisers to deliver messages that are measurable,” says Sweeney, CEO of Freckle.  “Bringing the brand activation outside of the store to the interested and connected consumer reframes the conversation. Our solution is immensely scalable, both geographically and in its capacity to connect with future devices. Freckle connects all the dots.”

It’s an indicator that the view of beacons as ad networks will only grow.

At the other end of the spectrum are the highly personalized connected spaces offered by Get Robin. They’re promising automation and analytics for the world of work – and, if you haven’t taken it for a test drive, please do. Their experience is beautifully designed and the company is a demonstration that in addition to huge networks of beacons as ad networks, they’ll also drive much more intimate engagements.

A Busy Year Ahead

These are, of course, just a few of the announcements of the past few weeks. If you’re scanning the main stream media or tech press, beacons are a sort of gentle buzz.

But under the surface, there’s something more profound happening: companies have seen beacons as a deep innovation which they need to understand. But now that we’re past the initial learning curve with beacons, turning them into an operational strategy is giving us everything from ad networks to major transformations.

2015 won’t be the year of the beacon. It will be the year where beacons are the cost of entry to an era of digital which will transform industries in the same way Napster transformed music – the year when beacons are a synonym for the creative power of the Internet of Things to transform the way consumers experience a new landscape of digital embedded in the very physical world in which we live.

Share Your Thoughts

Join our e-mail list for more on iBeacons and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

Thoughts? Comments? Drop them below.

Apple Launches an iBeacon [and they call it a watch]

The speculation was correct. Apple launched its own iBeacon.

But it didn’t come in the form you might have been expecting. Instead, you’ll strap it to your wrist and in so doing, the power of beacons to help make sense of the world around us will have a very personal, tactile and physical connection – right down to our pulse, the steps we take, and the friends we send our heart beats to.

Setting aside the lust-worthy bands or Swiss-level precision of the bevel (check out the “Watch Guy” to learn why), the Apple Watch is clearly more than a beacon. It’s a fusion of industrial design, software and sensors. But for those of us working in the world of beacons it’s a reminder that the power of proximity won’t rest in a one-to-one relationship between dumb and smart devices, but between many smart devices connecting to many other smart devices.

Dumb Beacons, Big Challenges

The challenge for the ‘becosystem’ will be breaking the lock on the mental model which was facilitated by the first wave of proximity beacons.

Companies like Estimote established the standard: they promised that simple, elegantly designed ‘motes’ could be popped onto the wall of your local store and deliver coupons or other messages.

And the uptake of beacons, whether in museums, Tulip gardens or your local coffee shop, was powered in large part by its seeming simplicity. The code you need on an Apple or Android device is relatively simple: a few lines in your software and your app can listen for beacons and, once detected, do “stuff”.

The initial challenge was to figure out what that stuff should be.

This turned out to be harder than most folks imagined: because suddenly, you had to shift from designing for mobile devices to designing for something far more messy and imperfect.

Namely, the physical world.

Push the wrong message at the wrong time and you’re suddenly sending a “Nice to See You” message in the toilets rather than the front door of your restaurant.

Reality is fuzzy, filled with interference, there’s little clarity between the shoe department and accessories even though the ‘zones’ might seem like they’re clearly marked.

Reality wasn’t designed to be digital and yet the promise of digitizing the grocery store was compelling enough to at least try.

What we discovered, however, was that even though beacons are relatively dumb, you need to be reasonably smart about how you deploy, manage and create experiences around them.

Beyond the Dumb Beacon

We’ve called beacons the gateway drug to the Internet of Everything.

On their own, they pose intense design challenges – challenges which, it turns out, can’t always be tackled with the elegance they deserve. And we admit that we went through months of trial and error and testing to even approach getting those challenges right. (Thankfully it’s pretty much all we do, so we had the luxury of focus).

Until now, the use of beacons has mostly focused on treating them solely as ‘dumb’ devices.

Powered by Bluetooth Low Energy (or Bluetooth Smart), beacons are, after all, not much more than radio transmitters that broadcast small packets of data which are picked up by nearby phones or other devices.

But the power of beacons is both a product of the paradigm they represent, and the exponential value they provide when coupled with other technologies.

Bluetooth Smart (BLE) uses a service-based architecture upon which profiles are built. Even excluding technologies such as passive WiFi monitoring, BLE itself has over a dozen ‘profiles’, from proximity (which powers beacons) to heart beat monitoring, time monitoring and “find me”/link loss services.

Add in chips to detect humidity, a gyroscope and an accelerometer and suddenly a simple beacon becomes a tiny powerhouse of data.

The Tempo

The Tempo is still one of our favorite devices. In spite all the beacons we’ve seen and tested, these little ‘stones’ still have the best app-side user interface, the best design, and give Apple a run for its money in terms of form and function.

And they’ve recently added iBeacon support. Richard Hancock, CEO of Blue Maestro,  tells me that “Through the app, users can turn on iBeacon mode and it will act as both an environment monitor and an iBeacon at the same time by intertwining broadcasts.”

“Tempo is particularly suited to use cases where iBeacon functionality and environmental monitoring is important, such as in museums, historic tourist attractions, transportation networks and stadiums.” He explains that “as iBeacon functionality is expanded by Apple (and Android), we will have the potential to do neat things with Tempo, such as automatically determine whether the environmental data has been harvested and, if not, trigger the download from the device, without having to involve a user.”

The device isn’t just beautiful to hold. The app isn’t just a rock solid interface which, you know, actually works. (I can’t tell you how many times we scream in frustration at the beacon companies whose apps time out when trying to pair so that you can recalibrate the settings).

Instead, Blue Maestro reminds us that “beacons” are already more than just proximity – they’re turning into incredibly powerful, multi-sensing machines.

The Smarter Cloud

Coupled with smarter devices is the smarter cloud.

Kontakt, for example, has launched its Cloud Beacon. Its power doesn’t rest, however, in the fact that it’s WiFi enabled. Its power rests in the simplicity with which it lets you manage fleets of beacons and harvest anonymized data.

Kontakt, whose sole focus is beacons, brings its not insubstantial expertise to the task of extending a simple beacon into a full network that combines WiFi with cloud-based control.

But from another angle, companies like, propose extending existing ‘smart infrastructure’ in order to extend it to beacons:

Why The Apple Watch Reminds Us of the REAL Future

But these developments pale in comparison to the real power of beacons.

We’ve long proposed that beacons represent the first in a paradigm-change for computing:

  • Proximity is different from location. Whether through beacons, Google’s Project Tango, or increasingly refined ambient signal detection, we’ve entered an era in which we can know what we’re close to, whether a stationary shelf or a moving vehicle.
  • Because our devices can now ‘see’ what they’re close to, the physical world itself is becoming a digital interface. This blurring of the digital with the physical means that there will soon be no offline.

And if our phones can ‘see’, and if our devices are also beacons (which is the case with Android-L capable phones and Apple devices) then it means we can also see….each other. And our devices can start to talk. And if our devices can start to talk, they can also start to do so without us even necessarily participating in the exhange.

Google Now gets us where we need to go. Our Apple Watch will gently tap us on the wrist if we’re driving in the right direction.

These ambient cues may still connect us to our devices and make us aware that they’re working on our behalf, but over time they’ll be more ambient and calm than pushy and forthright.

Lights in the Muji Change Room – One Day, They Won’t Need You To Touch

Objects will glow. Digital signage will subtly change. The change room in your local store will switch its lighting to show how your outfit looks in the actual light that you typically find yourself in.

And your watch.

Your watch is the new skeumorphic. Mostly familiar, mostly simple looking, it even tells the time and has a crown.

But as a beacon, it takes sensors, broadcasting and connection to a new level.

Your pulse is a text message. A gentle tap on your wrist is an interaction with another beacon.

Your watch won’t just be a connection to dumb devices planted in the world around you. For better or worse, your watch turns your physical body into a digital interface.

Mesh networks, continuity between devices, objects talking to each other, and our very pulse are creating a new canvas upon which digital interactions will be deployed.

We’ve said that with beacons, we’re inviting engagement with the physical world through the most personal object most of us own (our phone).

But Apple Watch and other wearables are extending this metaphor into even more personal spaces, into even more personal realms of data and connection, and are part of a network of nodes which is larger than we can conceivably imagine.

So, What’s Your Channel?

We spend a lot of time thinking about beacons. Trying to figure out how to deploy 10s and 100s of thousands of beacons keeps us awake at night worrying about signal interference and sun spots. (OK, well, we DO have our moments of random terror I suppose).

But what’s more challenging, and we think more interesting, is what it means for the user to be walking through an array of beacons that cover entire towns.

A visit to the grocery store can be a utility or it can be a cultural exploration. A wander down Main Street can be a chance to browse and window shop or it can be a chance to connect to community. A digital billboard can be an ad, or it can be the start of a story, an aspiration or an adventure.

The Internet gave us access to a universe of stories. Social media connected those tales to others. Beacons connected them to the physical world. And wearables bring them back to the domain with which we still have our most visceral and emotional connections: the physical world, our selves.

Apple and Samsung and Nike have invited themselves onto the most personal real estate there is. But it’s the connection of these devices to the world around us that creates the truly profound change – and gives both the ability for data to be harvested and experiences to be driven, pushed and personalized; and for us to understand these connections as a new art form, a new network of pulsing, ambient and personal power.

The motto of this site is Be The Beacon.

Now, more than ever, we are.

Toronto Dsrupted – Join Me!

I’ll be presenting this week at the Dsrupted Conference in Toronto. If you’re interested in beacons, digital signage and the next generation of ‘screens’ and devices you should join us.

Share Your Thoughts

Join our e-mail list for more on iBeacons. Join the conversation on Twitter, or connect with me on LinkedIn.

Thoughts on wearables? Comments on Apple Watch? Drop them in the comments below.

And a side note: if you’ve commented before your contribution should immediately appear. But I’ve turned moderation back on because the darn Akismet spam filter just doesn’t seem up to the task. So, apologies in advance if it takes me a bit of time to approve your comment.

iBeacon Feels the Squeeze: Adapt (or Die?)

iOS8 is a monumental move towards devices that are more connected, more aware, and increasingly powered by iBeacon and Bluetooth LE technology. And yet in spite Apple shifting the emphasis from the screen to the world around the screen, iBeacon device makers are about to feel the squeeze.

Google is expected to follow suit with announcements (such as a contextual awareness via its Nearby feature) at their I/O conference at the end of the month.

These combined moves will result in an equally massive shift amongst beacon device makers. We expect to see rapid consolidation, some of the beacon “makers” fading from the scene, and others changing their business models.

As an industry, proximity devices and software tools will explode. And yet the first generation of early innovators will face an intense pressure to grab market share, improve their products, and respond to an increasingly demanding marketplace.

4 Ways Apple Changed the Game

iBeacon wasn’t on center stage at WDWC. (Mind you, neither was maps due to rumored internal divisions and problems with execution).  And yet the philosophy that underpins beacons was very much in evidence. As we said yesterday:

If beacons allowed our phones and tablets to see the world around them in a new and profound way, Apple has just launched a new philosophy and approach for the purpose of computing: to connect it to the physical world

The physical world, until now mostly ‘dumb’ and disconnected from our devices is, for better or worse, waking up, and our devices are responding. There is no offline. And last week, Apple demonstrated that nearly everything it’s doing to enhance its platform is directed at that fact.

But once we got off the main stage, it became clear that Apple had a few tricks up its sleeve that would have a very tangible impact on iBeacon. Here are four key take-aways that will impact iBeacon experiences:

Game Changer 1. Indoor Mapping

If you own a store, museum or other location you can now ‘register’ for indoor mapping. Let Apple know whether your location has WiFi, iBeacon and other technologies; load up a map of your store; and you can then embed wayfinding and other features into your app.

This is a significant change, and comes in direct competition with similar efforts by Google to do indoor mapping and to “own” location registration. But it also slices off a significant iBeacon use case: indoor wayfinding (something which iBeacon was never designed to do, and required extensive “hacking” to try to get it to work well).

If a store was looking to use beacons to help consumers find their way from the front door to the shoe aisle, this new feature eliminates the need for beacons in the first place.

You can think of it as ‘narrowing the range’ of a beacon – instead of using beacons, you can use the equivalent of indoor geofences.

Take-Away: Over the past year we’ve had hundreds of questions and seen dozens of companies building ‘wayfinding’ around beacons. Those use cases have (mostly) disappeared.

Game Changer 2: App Promotion

Location registration comes with a major upside: if you register your app and venue with Apple, they’ll promote your app on the lock screen of a user’s device. Arrive at the museum, and your user will see a little icon on their lock screen telling them that there’s an app specific to that location.

Take-Away: An iBeacon experience only works if your user has an app. Apple just made a game-changing move to make it easier to promote your app at your location.

Game Changer 3: Notifications and Widgets

Apple finally caught up with Android, creating a better “home screen” experience for notifications and ‘granular’ interactions with apps. As Wired reports:

Interactive notifications will spur all sorts of new behaviors. (And yes, Android already has interactive notifications, but the ones in iOS 8 look to go beyond what KitKat can do.) Some of these will be simple, like the ability to reply to an email or text message. But they’re powerful in that you can do this without quitting whatever you’re already doing. And this interactivity is not just limited to system apps. Third-party developers can take advantage of this new capability as well, so you could comment on something on Facebook, respond to a tweet, or even check in on Foursquare. But others are going to be radical, stuff we haven’t imagined yet. Once developers begin to really harness what interactive notifications can do in iOS 8—and they will—it’s going to cause one of the most radical changes since third-party apps. With the advent of iOS 8, notifications are the new interface frontier.

This will spur all kinds of new user behaviors triggered by beacons, and will shift some of the interactions from the app itself to side widgets and the ‘notification layer’.

Take-Away: You need an app to react to a beacon. But the focus has been on in-app interactions. Notifications creates a new “layer” for how users will be able to interact with beacons.

Game Changer 4: Privacy and User Choice

Apple has, again, “turned the dials” on user choice and privacy. While iOS7 gave us the ability to respond to beacons even if your app was closed, iOS8 returns some of the choice to consumers, allowing them to ‘toggle’ whether they want an app to be location-aware and at what times.

A new feature called “visit monitoring” puts more power back in a user’s hands, as 9 to 5 Mac reports:

Apple is adding a new authorization request type in addition to the one it currently does for apps that ask for permission to access a user’s location. The new type of authorization is called “When In Use” and allows developers to ask for permission to only use location data when an app is in use. Previously Apple had a single authorization type referred to now as “Always”. What this means for users is a new blue status bar for apps that opt to request “When In Use” permission to let them know the app is currently getting continuous location data in the background.

Apple has also closed the door on anonymous device tracking (a move that puts a question mark on the business models of companies like Turnstyle) by anonymizing the device ID that your iPhone transmits – similar to ‘masking’ the UUD that an iBeacon device transmits.

3 Challenges for iBeacon Manufacturers

In addition to the above, which are on their own game changers in how a proximity experience is designed, the introduction of HealthKit, Home and Swift will each have deep implications for iBeacon device-makers and their related software services.

These combine to create a tsunami of challenges for iBeacon and Bluetooth LE device makers.

Challenge 1: Demand Up, Prices Down

Apple’s changes are the tip of the iceberg. More rapid adoption of Android Kit Kat is bringing a massive new user base to proximity experiences. The changes by Apple will help overcome lingering doubts about app downloads, wayfinding, user experiences, user choice (and fear of spam), privacy and engagement.

More devices powered by BLE in the home will drive a larger demand for devices, which will have a collateral effect on the iBeacon markets in retail and other venues.

Demand will go up, but per unit costs will plummet. And yet continued problems with the BLE supply chain (especially out of China) will challenge device makers to deliver rapidly at a lower price point.

Challenge 2: Swift and Android Are Not An Option

Check most of the iBeacon device sites out there, and most of them announce that Android is “coming soon”. But just as they get poised to launch Android support, device makers will also scramble to support “native” Swift (meaning in more than just an “import Objective-C into your Swift project kind of way).

With Google announcing its next suite of tools, this will leave device-makers scrambling on two fronts, and casting a glance over at Windows and Samsung’s shift to Tizen.

Challenge 3: Wearables and the Home

And the game is about to change again. Apple’s iWatch is projected to outsell the iPad. And it’s anyone’s guess whether its launch will be coupled with changes to the iBeacon protocols. It will certainly drive new notification interactions and we can expect to see iBeacon experiences shift from your phone to your wrist.

Combined with home automation, we’ll also start to see cross-over products: beacon-powered devices for your living room that wouldn’t look out of place in a coffee shop.

What’s Next? 3 Predictions

While challenging, these are exciting times. 10,000 developer kits by Estimote looks like pocket change compared to what’s ahead. And yet the changes we’re seeing this month will lead to some pretty tough decisions by makers of iBeacon and Bluetooth LE proximity devices.

How will they respond? Expect to see at least three strategies.

Prediction 1: Move Into the Home

We’ll see beacon makers shift from retail into the larger, more competitive, and potentially more rewarding market: the home. Beacon makers will decide that the retail market has become too demanding and price-sensitive and will retool their business models to package beacons up with simple use cases for home automation and proximity detection.

Prediction 2: Shift From Beacon to Proximity/Location

Sorry, but beacons alone don’t cut it. With indoor mapping, integration into local WiFi detection, and changes to notifications and consumer privacy agencies will expect a lot more from their beacons than just fleet management. Cloud-based services will need to support indoor mapping, push notification support and management of collateral technologies.

Prediction 3: Down To the Metal

Instead of competing on “cloud”, device makers will dive deeper into the metal and their beacons will become more powerful. Beacons will combine with ARM processors, local hubs, distributed computing and mesh networks, while leaving ‘services development’ to others. These moves will be pursued aggressively by companies like BlueGiga, Nordic and Texas Instruments and will power second and third generations of beacons that make today’s devices look like toys.

Challenging? Yes. Transformative? Definitely

The world has changed forever and will be a different place in the years to come. Connected homes, quantified selves, mesh networks and nano satellites – things that seemed like dreams or scenes from a movie will be visible and real in the years ahead.

And in a few short months, the “becosystem” will also be radically changed. Stressful, nail-biting, life-altering? Yes.

But hey – we all knew what we were signing up for – a chance to change the world and participate in the creative destruction that comes with turning the physical world into the new digital interface.

Share Your Thoughts

Join our weekly e-mail list for more on iBeacons. Join the conversation on Twitter, or connect with me on LinkedIn.

Has the game changed for iBeacon? Do things like indoor mapping make iBeacon more or less relevant? Are the makers of iBeacon and BLE devices looking at opportunity, or challenges in the months ahead?

WWDC: Bringing Home the iBeacon

It’s hard to resist the parlor game of guessing what Apple will launch at its World Wide Developers Conference – but with the Wall Street Journal reporting that iBeacon will get time on stage during the keynote, I’ll add a few more last minute predictions to the list I posted this weekend.

With Apple expected to make announcements related to a connected home, I proposed that Bluetooth LE is the ‘secret star’ of WWDC. Whether it’s explicitly called out or not, BLE powers much of the communication architecture of Apple’s potential connected devices.

From smart thermostats to a Healthbook app, BLE is the lightweight ‘broadcast’ technology that lets one device know that another device is near, what it is, and what kind of data it’s transmitting.

But perhaps Apple will be more explicit about iBeacon itself. To that end, a few more predictions to add to my previous post.

Estimote: Coming Soon to an Apple Store Near You

Rumors are that Estimote has a follow-up device in the works. Its original iBeacon device was always positioned as a developer kit, and the company has been noticeably silent with new releases, cloud tools and follow-on product.

But Estimote is nothing if not a Y Combinator playbook. And like any company driven by the release cycle/investment stage approach of Silicon Valley, it knows how to time its press.

If I was following the same playbook, the step to take that would make the most sense? Hold your release until WWDC and then launch out of the gate on the back of the Apple press.

So while we might not see Estimote on the main stage (although we might!), my prediction is two-fold:

  • Estimote will launch a new beacon or hardware product on the heels of WWDC
  • Apple will announce (either on the main stage or in the companion briefing materials) that it will be selling iBeacon devices in its stores, with Estimote being the poster child for the initiative.

The announcement that Apple is making iBeacon devices available through its stores won’t be positioned as a retail play – instead, it will be launched as a way to make iBeacon accessible to everyone – from schools to small businesses to the local yoga studio.

If this is true, then in addition to Estimote we’ll see other products ‘ready for shelf’ with more targeted audiences – highly secure beacons for healthcare settings and carry-along beacons (like Tile or Chipolo) for your key chain.

Maps: Making Triangulation  and Wayfinding Easier

I alluded to this in my last post but want to call it out more explicitly.

Apple is expected to make major improvements to its maps…and with those improvements, expect the company to explicitly draw a connection to iBeacon. The details will be rolled out during the workshops and sessions that are held in the days following the keynote, but I fully expect developers to have a new set of programming tools and classes that will extend the functionality of beacons beyond simple range detection into triangulation, indoor mapping and wayfinding.

Broadcast Always On

It won’t mean a lot to most people and therefore won’t likely be a keynote topic, but one of the limits of iBeacon is that although your phone or iPad can be a beacon, keeping it running is a challenge.

While your phone can detect beacons even if your phone is off, turning your phone INTO a beacon has limitations. Say, for example, that you want to turn your iPad into a beacon. You need to worry about power, app state and avoiding conflicts between beacon transmission and detection.

Dig into the workshops following the keynote, and I expect to see improvements to how Apple treats turning your iDevice into a beacon.

Share Your Thoughts

Join our weekly e-mail list for more on iBeacons. Join the conversation on Twitter, or connect with me on LinkedIn.

Any last minute predictions for WWDC? Do you think Estimote will come out with a new product this week? And would beacons in Apple stores make sense? Or would they confuse consumers who expect them to, you know, DO something (not understanding that they need an app!)

iBeacon Sees the Light: Powering a New Generation of Bluetooth LE

iBeacon Light Harvesting

Next Generation of Devices Use Energy Harvesting

Balancing the user experience with maintaining battery power on an iBeacon or Bluetooth LE device is a key development challenge.

Set your advertising or signal power too high and your battery will run out in weeks. Set it too low and your battery could last years – but there could be a significant delay in your users getting beacon “messages” – receiving a welcome alert when they’re in the restroom instead of at the front door of your restaurant.

But a new generation of Bluetooth LE beacons use energy harvesting and remind us that while iBeacon technology may be relatively simple, we’re still at the earliest days of the technology. Yesterday’s world-class beacon may soon seem like a relic of a different time compared to their new, um, higher powered cousins.

The iBeacon Conundrum: Brand or Specification?

Estimote this week published an excellent post outlining how to conserve battery on their devices.

But the post isn’t just a primer for Estimote. It’s for anyone who wants a quick cheat sheet on how long a beacon will last at different signal and power strengths. It serves as an excellent response to concerns that the Apple specification for iBeacon might put a lot of pressure on battery life. With Apple requiring a 100ms advertising interval, many battery-powered beacons would only last a few months.

Of course, this leads to an interesting question: who cares? And I tend to side in the camp that says that while Apple may have a specification, that doesn’t mean you need to use it.

In fact, the value of the iBeacon name attached to a beacon seems, for now at least, to be negligible. It’s great marketing. But your beacon will work just as well whether it has the iBeacon trademark affixed or not.

In theory, a beacon could be two things at once: an iBeacon (meeting their specifications for broadcasting) or just a good old Bluetooth LE beacon when broadcasting at a different interval or power strength than the Apple specification.

Most retailers or venues won’t even know the difference.

The iBeacon name, therefore, can simply mean this: we love Apple, we love using their trademark, but use our beacon however you please. 

Battery and Signals

The Estimote post reminds us of the challenge device makers face in jumping ahead of the curve, or waiting for the technology to settle down:

We became the first company to ship beacons in July of last year, because we wanted the developers in our community to get to play with our Dev Kits as early as possible – introducing them to the possibilities of next generation context-aware applications.

At that time, Apple was still finalizing the iBeacon specification. We didn’t wait for them to finish, deciding instead to ship the beacons with our default settings because we knew it would be easy to update configurations live. We are tremendously happy to have built a huge community of developers who have helped us to test and validate both the beacons themselves and a slew of beacon applications.

After a quick overview of the physics of signals, Estimote offers a handy guide to battery life….one which would roughly apply to most of the popular coin-battery operated beacons:

Battery Life Comparisons | via Estimote

A New Generation of Beacons

A new generation of devices, kits and chips is hoping to make these tradeoffs a thing of the past. Using light harvesting, they offer a way to power beacons without any batteries at all.

Light-Harvesting Beacon: Netclearance m1Beacon

Netclearance Systems

Netclearance Systems is staking a claim to be first out of the gate. Their m1BeaconLite uses the latest in energy-harvesting and storage technology that converts ambient light into a power source capable of handling a typical BLE application.

“Energy harvesting delivers a scalable and environmental-friendly approach to indoor beacon deployments while reducing the total cost of beacon ownership,” said Jack Donner, Chief Technology Officer. “Most indoor venues such as airports, stadiums, retail stores, hotels, shopping centers have an abundance of high intensity ambient light. The tremendous operational and energy-harvesting efficiency of the m1BeaconLite…enables our customers to realize the benefits of beacons without having to manage battery-life or wired installations.”

Texas Instruments

Meanwhile, Texas Instruments has been making waves of its own.  While TI chips power a range of existing beacons, the company has become a competitor to other beacon makers.

By releasing its SensorTag beacon, they may well have recognized that they had a chance to grab some of the margins that other device makers were grabbing by releasing its own product.

But TI isn’t being left behind on the energy front. They offer their own reference design for using light harvesting to drive device development:

This subsystem reference design is highly differentiated over existing solutions as it incorporates no batteries, thus eliminating the hassle of battery replacement, battery charging, and saving costs associated with battery maintenance.  This solution also ensures that there are no constraints around installation as long as there is typical indoor lighting available.  There is also no ON/OFF switch; the entire load connection and disconnection is handled by the power management IC therefore ensuring that the solution is self managing.

Based on this, we should start to see existing device makers incorporate this approach into new lines of iBeacon devices.

(But please…would someone at Texas Instruments recognize how bloody awful your website is? It’s almost impossible to find information!)

Will Estimote Launch a New Beacon?

We’re told that Estimote is planning to release a new line of beacons. Perhaps their next generation device will use energy harvesting. Maybe it will use a new form factor that makes it easier to change the battery!

Regardless, we expect to see them and others launch new beacons, new devices, and set new standards for quality. Some won’t even use batteries at all.

Soon, we’ll be able to worry more about the user experience and less about how to configure our beacons so they don’t go dead a month or two after being deployed above the front door of your store.

Share Your Thoughts

Join our weekly e-mail list for more on iBeacons. Join the conversation on Twitter, or connect with me on LinkedIn.

Are there other light harvesting beacon solutions that we’ve missed? Is this a trend or a dead end? If nothing else, does it suggest that the current generation of devices will look like prototypes in the years ahead?