Bluetooth Low Energy (BLE) is a low power wireless communication technology that can be used over a short distance to enable smart devices to communicate. Some of the devices you interact with every day such as your smart phone, smart watch, fitness tracker, wireless headphones and computer are using BLE to create a seamless experience between your devices.

BLE is a relatively new Bluetooth standard defined by the Bluetooth Special Interest Group (SIG) with a focus on low energy. It has enabled device manufacturers to add a low power communications interface on existing solutions. It has also been used to create new low power devices such as beacons that can be powered by a small coin cell battery for months or even years.

BLE has a wide range of possibilities and is implemented in a broad set of fields such as health, fitness, security, home automation, home entertainment, smart industry and IoT (Internet of Things). It’s also close at hand in the smartphones and laptops that we use every day.

Apple was an early adopter of BLE in smartphones with release of the iPhone 4s in 2011. Today, the majority of Android and iOS devices on the market incorporate BLE for communication and interaction with other devices. The ubiquity of smart phones has enabled the rapid adoption of BLE and provides device manufacturers with access to a world wide BLE user base.

What’s with the name ‘Bluetooth’? It harkens back to the Viking heritage of the pioneering technologists of Bluetooth. If you’re looking for a little tech history that ties into Nordic history and King Harald Bluetooth, have a read here.

Device Roles: Central and Peripheral

In order to understand how BLE works, we need to define some of the terms and concepts at play. A BLE device is acting in either a central or peripheral role and is sometimes also referred to as a client or server.

·         Central (Client)

• A device that initiates commands and requests, and accepts responses.
• Examples: computer, smartphone

·         Peripheral (Server)

• A device that receives commands and requests, and returns responses
• Examples: a temperature sensor, heart rate monitor

The peripheral role is what we often think of with regards to BLE devices – things like headphones, fitness trackers, heart rate monitors, etc. A device that advertises its availability for connection and provides an interface for communication is acting as a peripheral.

Alternatively, a device that discovers, connects to and interacts with peripherals is acting in a central role – computers or smartphones for example. A central often scans for nearby peripherals and shows a list of devices found. If peripherals are connectable, the central can connect with a specified peripheral and begin exchanging information.

How does BLE communication work?

BLE uses a hierarchical data structure to define the information exchange structure. A BLE device acting as a peripheral will advertise services and characteristics that can be used for communication with the device. These attributes are defined using a GATT (Generic Attributes) profile. Characteristics expose values as small packets of information that can change over time. Characteristics are grouped together with similar types into services.

Characteristics can be defined to contain read or write type values. Peripherals providing read type characteristics are generally publishing information for the central to consume. Peripherals providing write type characteristics are generally providing an interface to receive data from a central – for example a configuration value that changes something on the peripheral.

As an example, assume we have a peripheral that implements BLE to provide a temperature reading from a sensor. This peripheral would have a read type temperature characteristic with the current temperature value set on the characteristic. As temperature readings change, the peripheral will update the characteristic value. A connected central device like a computer or smartphone would then subscribe to changes on that peripheral characteristic to provide real time updates of temperature readings over BLE from the peripheral.

The characteristics and services defined for a GATT profile each have a UUID unique identifier. There are some standard types of characteristics that the Bluetooth SIG defines as reserved, but BLE peripherals are expected to uniquely identify their characteristics.

A common interaction pattern from a central device is as follows:

• Scan for peripherals advertising defined BLE service types by UUID
• Connect to a selected peripheral
• Discover services on the connected peripheral
• Discover characteristics on the services of interest on the peripheral
• Read or write values to the characteristics of interest
• Disconnect when connection no longer needed

BLE data is sent and received in small packets of data. In BLE 4.0 and 4.1, a maximum data size of 27 bytes is defined. The data packet also contains a 4 byte header for a total size of 31 bytes. It’s important to consider how to structure data for transmission over BLE given the constraints on packet size. Developing for BLE involves converting values into binary data representations that can be serialized and deserialized consistently on both ends.

Mobile Device APIs

Apple and Google both provide great BLE APIs as part of their respective mobile development software development kits (SDKs). Apple’s CoreBluetooth API is used throughout many of their device operating systems including iOS, watchOS, macOS, and tvOS. There are some different capabilities on each of the device types, but it’s great to be able to leverage the same BLE implementation across so many different devices. Google’s Android 4.3 and above supports BLE as a central device. Current versions of Android and the Android SDK support a common BLE implementation that has standardized much of the development on Android. Previous generations relied heavily on device manufactures for individual implementations of BLE. Thank goodness we can leave that in the past.

BLE development on mobile requires BLE capable devices to debug and test the interactions with peripherals. The native platform SDKs provide the tools to build custom apps that implement BLE.

What about the hardware?

Our focus here is on the software side of the solution, but what about the hardware? Several chip manufacturers provide system-on-a-chip implementations for Bluetooth Low Energy. Nordic Semiconductor and Silicon Labs both provide full BLE development solutions that include development kits, SDKs and prototyping boards that can be used to begin the implementation and integration of BLE.

If you’re looking for a quick way to dive into prototyping with BLE without developing your own hardware, Nordic Semiconductor has a product called Thingy 52 that is a compact BLE device that has an array of sensor types like temperature, humidity, orientation and more that is ready to go out of the box.

Another great option for BLE development that often goes overlooked is the iOS devices you may already own. iOS devices can act as both a central or a peripheral. The common role for a smartphone device is a central, but the CoreBluetooth library on iOS allows a device to act as a peripheral and publish your own advertisement, services and characteristics.