Beacons, how do they work?

At the heart of all Estimote APIs lie Estimote Beacons. Whether it’s:

  • Proximity API using beacon signals to trigger enter and exit events,
  • Indoor Location API using signals from multiple beacons to compute an (x,y) position,
  • or Display API using the Mirror beacon to interact with the big screen,

it helps to understand how exactly beacons work. Hence, we present to you this very short* compendium on Estimote Beacons!

* compared, for example, to a 3,000 pages long Bluetooth spec, :wink:

Info: For a more metaphorical and high-level overview, see also this FAQ on our Help Center.

What’s ahead (aka Table of Contents)

Chapter 1: Estimote Beacons are…

Tiny, specialized computers

Think about your smartphone, laptop, or desktop: they’re all computers with processors, flash drives, RAM, wireless connectivity… Each beacon also has:

  • a low-power ARM® CPU
    • e.g., 32-bit, 64 MHz CPU in Proximity beacons, or a quad-core, 64-bit, 1.2 GHz CPU in Mirror
  • flash memory to store apps and data
    • e.g., 512 kB in Proximity beacons, 8 GB in Mirror
  • RAM memory for the apps to use while running
    • e.g, 64 kB in Proximity beacons, 1 GB in Mirror
  • a Bluetooth antenna and chip to communicate with other devices, and between the beacons themselves

Battery-powered

One big theme which differentiates Estimote Beacons from other computers is energy usage. Unlike:

  • desktops, which are constantly plugged to power,
  • or laptops and smartphones, which you recharge daily,

… Estimote Beacons are generally optimized to run on battery power for months or years. Mirror video-beacon is the notable exception here, since it can draw the power from the TV/screen it’s connected to.

Running Estimote firmware

These tiny beacon-computers are mostly running apps and services written by Estimote, usually referred to as firmware or “Estimote OS”.

Most of the time that’s all you need, because you won’t be actually writing apps for beacons themselves. You’ll be writing iOS, Android, Linux, or other apps that use beacons.

Depending on the beacon and its specialization, there might be some programmable aspects to it, for example:

  • beacons with Generic Advertisers can be set to broadcast custom Bluetooth packets
  • beacons with GPIO can have their Generic Advertisers controlled from an external device in real-time via UART
  • Mirror beacons run HTML5 and JavaScript apps to render content on the big screen

Interacting with other devices via Bluetooth

Unlike regular computers, which you interact with via keyboard, mouse, or touch-screen, Estimote Beacons are primarily interacted with via Bluetooth Low Energy (Bluetooth “LE”, or “BLE” in short).

Most of the time, you won’t be doing this yourself, directly. An Estimote SDK will do all the Bluetooth-handling for you, leaving you to work with a higher-level API and your business logic.

Estimote SDKs are available for iOS, Android, and Android Things. If you’re using some other platform, you can still use Estimote Beacons, but you’ll need to handle the Bluetooth connectivity yourself, or use a 3rd-party library. Naturally, your platform also needs to support Bluetooth Low Energy.

Chapter 2: How Estimote Beacons use Bluetooth

Since Bluetooth is the primary way to interact with Estimote Beacons, we dedicate an entire chapter to explore this in more detail.

Undirected, non-connectable advertising

Estimote Beacons don’t use Bluetooth in the “classic” sense of pairing or connecting to them, like you pair and connect to a Bluetooth mouse or headset. Instead, they do something described in the Bluetooth spec as “undirected advertising”. This means that the beacon broadcasts its data “into the air”, and that there’s no specific recipient for these broadcasts. Any BLE device (smartphones for example) in range can scan for these advertisements and pick them up. No pairing or establishing a connection is required.

Also, there’s no limit to how many scanners can pick beacon advertisements up. (Think: if there’s a person shouting on the street, the entire crowd around them can hear it.)

Tip: You can secure the beacon advertising with technologies like Estimote Secure Monitoring, or Eddystone-EID. Any BLE device in range will still be able to pick up the broadcast, but only authorized apps and devices will be able to “decipher” it.

Info: Exceptions, exceptions! In some cases, beacons do establish connections with other devices.

For example, to configure a beacon, the smartphone will actually connect to it, and the two will exchange some data (authorization challenges, new settings, confirmations, etc.) in both directions.

Display API also connects to Mirror beacons, and then it’s the smartphone that sends the data to the Mirror, to be shown on the screen.

Can beacons scan for other BLE devices? Do they?

The BLE hardware in Estimote Beacons is capable of pretty much everything defined by the BLE spec. For example, Location Beacons can scan for Estimote Stickers nearby, for asset tracking purposes. Mirror beacons can scan for any other Estimote Beacons nearby, and adjust the display—for example, if a person with a beacon-ified badge comes in range.

However, BLE scanning consumes much more power than BLE advertising. With advertising, the beacon turns its radio on for just a brief moment (~ 3 ms), broadcasts the data, and goes back to sleep. Scanning requires the radio to be on for longer periods of time (for example, 3 seconds), consuming appropriately more energy. (in this example, 1 scan = 1000x advertisements)

Because of that, battery-powered beacons generally don’t use their scanning powers very often or at all.

Keep in mind: Beacons generally don’t use BLE scanning for any kinds of analytics. Usually, it’s the smartphone app who reports that it was in range of a beacon for N amount of time, and not the beacon reporting about the smartphone.

Other than for battery-saving reasons, this is because (a) smartphones may or may not advertise themselves to the beacon, and (b) smartphones generally randomize their Bluetooth addresses to protect the privacy of their users.

Beacons don’t broadcast rich content

A common misconception is that beacons use Bluetooth advertising to broadcast text, images, videos, and others kinds of rich media content. That’s … not the case.

The amount of data that can fit into the broadcast is quite limited: in Bluetooth 4.x, it’s 20* bytes … which would only be enough for a 20-character tweet. In Bluetooth 5, that’s extended up to 243* bytes—better for text, still not enough for richer content. (* numbers after excluding all the headers & commonly used metadata)

Because of that, the most scalable, flexible, and common approach is for beacons to only broadcast some kind of identifier (think, “beacon #1”, “beacon #2”), and to store any extra data in the cloud. For example:

beacon_identifier: 1
  name: Lobby Beacon
  location: 35 E 19th St, New York
  attachments:
    title: Welcome to the lobby!
    text: We've already notified the receptionist about your arrival,
          but feel free to say hi, or ask any questions.
          While you wait for your appointment, help yourself to some of
          our delicious coffee and fresh fruit!
    image: /images/lobby.png

For Estimote Beacons, that extra data can be stored and queried in Estimote Cloud, mostly with the Devices and Attachments APIs.

Some other data commonly broadcast by beacons are:

  • short URLs
  • data from the beacon’s sensors (beacon’s motion, ambient temperature, light, etc.)

BLE signal range & distance estimations

BLE signal is a 2.4 GHz radio wave that the beacon transmits with a certain “strength”, often called Broadcasting or Transmit (Tx) Power. The strength of that radio radio wave decreases as it travels further and further away from the beacon.

The BLE receiver “catches” that radio wave with its own antenna, and tries to convert it back into usable, digitial data. As the signal gets weaker, the probability of being able to do that successfuly decreases. At some point, when the “error rate” or “packet loss” reach certain levels, we’re talking about the “max range” of the signal.

Info: An interesting tidbit: you can increase the max range by boosting the signal strength (Estimote’s long-range beacons include an amplifier to do just that), but also by dealing with the error rates directly. In fact, Bluetooth 5’s “4x range” is exactly that: a new packet structure with error correction capabilities.

The strength of the received signal is known as RSSI. Since the signal strength decreases with distance, if we know both the RSSI and the “original” strength at a point very close to the beacon, we can approximate how much distance the signal has traveled. Such approximation is more accurate closer to the beacon: ± a few meters, and gets less and less acurrate very quickly as the distance increases.

Both the max range and the distance estimations are further affected by:

  • the receiver. Each has its own sensitivity, antenna placement and polarization; the material that the receiver’s case is made of can also impact the signal, etc.

  • the environment. BLE radio waves can bounce off walls and objects, or get some of its strength absorbed on the way to the receiver. Water, metal, and glass in particular are known “troublemakers”—and do note that 80% of the human body consists of water.

We often use numbers to give you an idea whether your should expect something closer to 10 m range or 200 m range, or APIs for you to express whether you want to trigger events closer to 1 m or 10 m. Just be aware that these numbers are only a rough approximation.

Beacons generally don’t use GATT or Bluetooth profiles

If you’re a little bit more familiar with Bluetooth, you may ask what Bluetooth profiles or GATT services Estimote Beacons support, and where you can find the appropriate specifications.

Generally speaking, apps don’t interact with Estimote Beacons via profiles or GATT services. Beacons are primarily designed around advertising, and are mostly meant to be scanned for. Estimote Beacons don’t implement any Bluetooth profiles.

Advertising specifications are available on:

Estimote Beacons do implement some GATT services, primarily for configuration and fleet management. These are proprietary Estimote services, and we don’t currently share their specs.

Chapter 3: How smartphones process beacon signals

If a tree falls in a forest and no one is around to hear it, does it make a sound?

By now we know that beacons are mini-computers, programmed to mostly advertise small amounts of data over BLE. By itself, this isn’t very useful … until there’s some other BLE device that scans and retrieves this data, and actually acts on it. In this chapter, let’s talk about how that works.

We’ll focus mostly on smartphones, since they’re the most commonly used beacon-signal receivers. However, some concepts discussed here might also apply to other kinds of BLE-capable devices.

Do I have to build an app?

If you want to read your email, take a photo, or play a game on your smartphone, you open a respective app. That app is programmed to use system services such as Internet connection, camera, motion controls, etc. to do its thing.

Using beacons is no different: there needs to be some app that’s programmed to use Bluetooth, and to take actions—be it navigating you around an airport, finding a colleague in your office, or rewarding your continous visits to your favorite coffee shop.

And just like you don’t generally build your own email app to read email, you can also try to find and use a ready-made app or system for home automation, indoor maps and navigation, asset tracking, loyalty rewards for presence in specific places, etc. At Estimote, we believe that the future will be full of ready-made software that you can simply “install” in your physical space: your home, your office, your warehouse.

Today however, while the ecosystem of beacon-powered solutions is still developing, you will very likely need to build your own app or system. And if you want to do just that, you’re most definitely in the right place: this is developer.estimote.com after all (-:

Tip: A notable mention goes to Nearby Notifications, a mechanism built into Android Google Play Services. If you register your beacon with Google, or set it to broadcast a URL directly, Android will surface a link to that web site in its “Nearby” section. Well-performing links are even promoted to low-priority notifications. (Do note however, Google representatives mentioned on multiple occasions that ads and coupons don’t generally perform well with Nearby Notifications.)

Can web apps use beacons?

Modern web browsers can use the GPS in smartphones to detect location, or access the smartphone’s camera to capture pictures and video… Can they access the smartphone’s BLE to scan for beacons?

Indeed, there’s work in progress on a Web Bluetooth Scanning API, that is, a standardized API to do BLE scanning in web browsers: https://webbluetoothcg.github.io/web-bluetooth/scanning.html

At this time however, no web browser implements it yet:
https://github.com/WebBluetoothCG/web-bluetooth/blob/master/implementation-status.md#scanning-api

There’s also a Web Bluetooth GATT API, but as we mentioned above, beacons generally don’t use GATT.

Detecting beacons in the background

On iOS and Android, when the user leaves the app or locks the phone, the OS will usually suspend the app after a very short while. The app will stop executing any and all code when that happens, including the beacon-triggered callbacks.

However, iOS and Android 8.0 allow your app to request the OS to continue the BLE scanning, and to wake the app when a matching BLE advertisement is found. This will even automatically re-launch the app if it got killed by the user or due to memory pressure. On iOS, this mechanism is the bluetooth-central Background Mode. On Android, it’s a PendingIntent BLE scan.

Keep in mind: On iOS, Background Mode usage means extra scrutiny for your app when submitting it to the App Store. Be prepared to explain how your app’s background features benefit the user. To prevent a back-and-forth with the reviewers, it’s best to do this pro-actively in the submission notes.

For Android < 8.0, such mechanism didn’t exist, so the app needs to find a way to actually continously run in the background. This is usually achieved with a Background Service, and sometimes also by utilizing Job Scheduler and Broadcast Receivers—for example, to restart scanning after smartphone is rebooted.

Important: Starting with Android 8.0, Background Services and Job Schedulers are limited to at most 15 minutes of background execution time. The PendingIntent BLE API makes up for it big time—it’s almost always (if not plain “always”) a better solution.

Tip: Another good pattern for all versions of Android is to use a Foreground Service. Foreground Services are guaranteed not to get terminated, although they must show a notification to inform the user that the app is running. This however is a fantastic, user-friendly solution for all kinds of “session” activities.

For example, an event app could allow the user to share their indoor position with friends. It would start Indoor Location updates inside a Foreground Service, with a notification akin to “you’re currently sharing your location with 3 friends; tap here to stop”.

How responsive is BLE scanning? Does it drain smartphone’s battery?

Estimote Beacons by default advertise every 200 ms = 5 times a second. However, smartphones don’t always continously scan for BLE. For example, Android in “balanced” scanning mode has a 1024 ms scanning window every 4096 ms, so there’s about 3 seconds of downtime between scans. (In the “low latency” scanning mode, it’s a 4096 ms window every 4096 ms, so that’s actually a continous scan.)

Then, there’s also the matter of scan results propagating from the BLE chip, to the BLE driver, to the BLE OS-level services, and finally to the app itself. Because of that, it’s not that easy to estimate the exact latency, and it may also vary between different smartphones, and even OS versions.

When the app is in the foreground, the OS and/or Estimote SDKs will generally try to use more aggressive scanning settings, to provide the user with the best, most responsive experience. The battery drain it still relatively small, compared for example to what the display or the LTE radio draw.

In the background and outside range of beacons, as mentioned in the previous section, your app generally won’t be running and executing code—saving a ton of power. The OS itself will keep scanning for beacons on behalf of the app, but modern smartphones are capable of doing that in a very energy-efficient way. They will delegate most of the work to the BLE chip itself, allowing the CPU to go to sleep. The latency might increase slightly though, as the OS and/or Estimote SDKs will generally try to use lower-power scan settings.

Info: Older and lower-end smartphones might not be capable of such “BLE delegation”. As a result, background scanning might either use much more energy, or only happen periodically. (e.g., iPhone 4S runs iBeacon scanning only every 15 minutes when the app is not in use)

Luckily, this is quickly becoming a thing of the past. In the iOS world, this capability was introduced way back in 2012, in iPhone 5. In the Android world, example “first of their kind” devices include Nexus 6, Samsung Galaxy S5, and Moto G 3, from 2014 and 2015.

In the background and in range of beacons, the BLE chip will wake the CPU, and the OS will wake your app, so energy usage will rise. For short sessions, this is nothing to worry about. If you expect the users of your app to spend a lot of time around beacons, it’s worth being a little more mindful about that. While there’s no way around keeping the CPU active (if you don’t want to suspend the app), you can for example keep your network usage in the background down, allowing at least the cellular/WiFi radio to sleep.

Privacy opt-in

Beacon and BLE-scanning APIs usually give the app some idea of the user’s location. Since most of us consider our location data sensitive information, both iOS and Android require the user to explicitly allow that.

This means both that Location services must be enabled system-wide, and that the app specifically must ask for permission to use location data, and the user must agree. On iOS, the user can also decide whether the app can access the location only when in use, or also in the background.

This makes designing good value-proposition for your beacon-powered features, as well as good onboarding and messaging around all these permissions, critical to the success of your app.