Top Five Considerations for Designing a BLE Beacon Quickly, Securely, and Effectively

May 10, 2016 // By EDN Europe
Joe Tillison - Senior Manager, Field Marketing, Silicon Labs
Many OEMs who have never used wireless technology before are now adopting Bluetooth and adding beacons to their products. This can be simple, but it’s more likely a little bit of a challenge.

The beacon designer needs to consider:

  1. hardware;
  2. software;
  3. battery life;
  4. security and privacy; (next post)
  5. the vendor.

 1. Hardware Building Blocks

A self-contained beacon product can be implemented with a wireless System-on-Chip (SoC) or a module, along with a battery and a mechanical enclosure. But it will likely include other components such as pushbuttons, LEDs, piezo buzzers, sensors, and reed switches.

A pre-certified module with all these features provides the fastest time to market, while a discrete SoC design might provide size or cost savings over the long run.

The whitepaper Six Hidden Costs in a 99 Cent SoC provides a good discussion of the financial and developmental trade-offs for using a module or SoC.

Typical pre-certified Bluetooth low energy beaconing module and Bluetooth SoC reference design

2. Software

It’s fundamentally important to choose a widely deployed and field-proven Bluetooth stack. Most often, this market success is more important than any promises of new cutting edge features. Market success indicates good customer support and a stable stack, both of which help get to market quickly.

For beacons in particular, it’s very important that the protocol efficiently manages sleep modes. A beacon typically broadcasts it advertising packets for about 1% of its life. The vast majority of the remaining 99% are spent in deep sleep mode. Having a proven, energy efficient stack is obviously very important for both states.

Beacon Application Code

Writing the beacon code can also be very simple if the developer uses a proven Bluetooth programming tool. Silicon Labs’ BGScript is a very mature software abstraction tool. It is a simple, high-level, BASIC-like programming language that allows developers to quickly develop their Bluetooth applications.

This BGScript example code for the BGM111 shows a functional iBeacon implementation. It takes just 38 lines, most of it comments. While this is a very simple example, its power and simplicity are obvious.

BGScript iBeacon example code for the BGM111 Bluetooth low energy module

3. Battery Life

As with any product, a beacon’s battery capacity versus power consumption determine its operating life.

The beacon’s transmit power and beaconing interval play an important role here. But there are trade-offs to be made.

- Long transmit range takes more battery life (high transmit power), but provides more coverage area.

- Short transmit range limits coverage, but may be suitable for close-proximity applications.

- Short beaconing intervals allow for better location approximation through more data points.

- Long beaconing intervals conserve battery life, but may be missed by scanners entirely.

A beacon’s average battery life is determined by transmit power and its transmit / sleep duty cycle

Current profile in a typical Bluetooth low energy advertising event (ADV PDU)

Whitepaper on Developing with Bluetooth BLE Beacons

Our experts have put some very relevant information in a whitepaper on developing with Bluetooth beacons, which can be downloaded here. The goal is to help you get to market quickly with the right, stable solution.

It covers a lot of territory:

- We examine beacon applications to help you brainstorm some of your own.

- We provide a short history of Bluetooth and its derivatives, including Bluetooth