Getting started with Bluetooth Low Energy on iOS

Published in

codeburst

10 min readMar 15, 2017

Introduction:

One of the main features of the Bluetooth 4 specification is Bluetooth Low Energy (BLE). Also called Bluetooth smart, this technology allows peripherals to communicate by consuming much less energy than regular Bluetooth. Another major advantage is that the user does not need to manually pair with the device using the system settings. This article serves as a quick introduction to BLE and shows how to make an iOS that connects to a BLE peripheral.

Definitions:

Bluetooth Low Energy is also abbreviated to BLE. For clarification, the Bluetooth 4 specification defines a set of technologies which include Classic Bluetooth, Bluetooth high speed and Bluetooth low energy protocols. So be careful to check the compatibility of the peripheral with BLE.

We can recognize a BLE peripheral if it contains in its specifications the terms “Bluetooth smart” “Bluetooth Low Energy” or “BLE”.

Now that we have some BLE peripherals, we will see in the next section how they communicate.

BLE communication; the central and the peripheral:

In the BLE world there are two type of devices: peripheral and central.

A peripheral is a device that exposes services and data for reading or writing.

The central is a device that connects to peripherals in order to read or write data exposed by the peripherals. The central is the device that initiates the connection to the peripheral.

In a client / server model the central can be seen as the client and the peripheral can be seen as the server.

Some devices can act a as central peripheral at the same time. iOS and Mac devices are such an example.

Peripheral / central example:

Smart-bands such the MI-Band is a peripheral.
The iPhone that connects to a smart band acts as a central.

Source: https://learn.adafruit.com/introduction-to-bluetooth-low-energy/gatt

In the next section, we will introduce the possible communication modes in BLE.

BLE communication modes

The are two communication modes in BLE:

Advertising mode: the peripheral sends information to be available to all the centrals around. This mode allows a peripheral to be known by centrals, thus the term “advertising”. In this mode, simple information can be exchanged using GAP broadcasting. In the perspective of a peripheral, this is a one-to-many mode.
Connected mode: allows a central to exchange complex data with a peripheral. The GATT protocol describes how the conversation is made in this mode. In the perspective of a peripheral, the connected mode is a one-to-one mode.

Here are some additional rules:

A central cannot connect to another central and a peripheral cannot connect to another peripheral.
A peripheral can be connected to only one central device at a time

In the following section, we delve into more details about the communication in connected mode.

BLE communication in connected mode; services and characteristics:

The GATT protocol defines how a central can communicate with a connected peripheral. First of all the data structure is defined like this:

The peripheral exposes fields that the central car read, write or be notified of. Each of these fields is called a characteristic. A characteristic is also accompanied by a descriptor which explains it.
Characteristics are grouped into a service.
We can also group services into a profile.

Let’s take an example: a heart rate monitor is BLE peripheral that has a rate profile which in turn has 2 services: a Heart rate service and a Device information service. The heart services define a read characteristic that provides the measured heart rate. It also defines a write characteristic for the body sensor location. The device information services contains characteristics about the model, the firmware version, etc. of the device.

Each characteristic and service is defined by a unique identifier called UUID. There are predefined UUIDs for many services and characteristics. You can find a list here: https://www.bluetooth.com/specifications/gatt/services and https://www.bluetooth.com/specifications/gatt/characteristics. Of course, you can define your own UUID for your services and characteristics. You are also not obliged to recuse predefined UUIDs. Official BLE UUIDs are on 16 bits and custom one take 128bits. They are generally represented in hexadecimal form. For example the UUID of the heart rate service is 0x180D.

The next section describes typical BLE use cases.

Typical BLE use case

This section describes some typical BLE use cases. There are other use cases possible but we will describe the most common ones.

BLE Scan app: this use case describes situation where you want to discover and test any BLE peripheral in the surroundings.

Peripheral devices advertises services
Central devices scan for any advertising peripherals and displays it to the user
The user to select a peripheral from the list of available one
The central connects to the selected peripheral and displays its available services to the user
The user choses a service
The central asks the peripheral for the characteristics of the selected services and displays them to the user
The user choses a characteristic and perform some actions depending on the operations allowed: read and/or write and/or be notified of.

Examples of iOS app that suit this use case are: BlueCap and LightBlue.

Another typical use case if the following:

The iOS app scans for peripherals which advertise specific services.
The iOS app connects to a specific peripheral. For example: a smart band.
The app then collects information using specific characteristics and predetermined services. For example: the number of footsteps.
The app disconnects from the peripheral and reconnects to it directly the next time

This type of use case is more straightforward and does require user intervention only for the first connection. Apps that handle specific BLE hardware follow this type of use case. For example, we have the MI Band official app. The application that we are going to develop at the end of this article will follow this use case.

In the next section, we will check if our Apple hardware supports BLE.

BLE and Apple

Apple supported BLE in its software and hardware early. Here is a little recap

The iOS5 SDK introduced Core Bluetooth framework that allows interact with BLE devices either as a central or a peripheral.
All iOS devices since the iPhone 4S support BLE.
The iOS simulator support BLE if your Mac supports it. The first Macs that support BLE are:
Mid-2011 MacBook air
Mid-2011 mac mini
Mid-2012 retina and non retina MacBook pro
Late 2012 iMacs

Knowing this, if you currently own a Mac and an iPhone or iPad, chances are very high that you can get started right now to code some BLE apps.

Developing BLE apps on iOS

When you develop an app that interacts with other hardware using BLE, you need to first ask these three questions:

Am I going to interact with a peripheral or central device ?
What is the profile, i.e. services and characteristics of the peripheral
Which framework or library am I going to use

Firstly, the answer of the first question allows to decide which type of BLE device the app going to implement. If device we are interacting with is a central, then the app will act as a peripheral. On the other hand, if the device that we want to communicate with is a peripheral, than our app will be a central device.

Secondly, clearly defining in advance the services and characteristics allows the app to seamlessly and correctly communicate with the BLE device. Without this, it will be like a blind communication.

Lastly, choosing the framework that suits you the most is very important when developing BLE apps. The first most important reason for me is because we need to perform many asynchronous tasks before exchanging the first bytes. The second one is that the commination may fail for many reasons. So choosing a framework that eases these tasks is very relevant.

In my experience, I had to choose between two frameworks:

Core Bluetooth which is the BLE framework developed by apple and included in the iOS SDK since iOS5. This framework relies heavily on delegates and is very well documented. However, the example code is still in Objective-C. This framework feels also old.
BlueCap: which is a swift wrapper around Core Bluetooth. It supports iOS 9.0+ and requires Xcode 8.2? It relies on futures instead of delegates. If you are new to futures like me, it will take you some time to get used to but it is worth it. It feels more natural for me than delegates.

Since the project I was working on supports iOS 10 and is written in Swift 3. I did not hesitate to choose Blue Cap :). In the next section, we will create a simple central app that communicates with a peripheral simulated on a Mac using Bleno.

Sample Central iOS App

First of all, we are going to simulate a peripheral device using the Mac. You can use you own peripheral if you want though

Simulate a peripheral with the Mac

It is possible to simulate a BLE peripheral using a Mac with different techniques. The first that comes to mind is to make Core Bluetooth Mac app that uses the peripheral role. There is also a node.js module called bleno (https://github.com/sandeepmistry/bleno) that allows to quickly implement a BLE peripheral. We are going to use bleno in this article. Here is a way to get rapidly started:

Install Xcode
Install node.js
Open a terminal and install the bleno module: npm install bleno
Download the bleno github repository : https://github.com/sandeepmistry/bleno
Open e terminal and go to the examples/echo folder
Run node main.js. If you encounter errors saying “missing module”, you need to install it using npm install “module” and try again

When you the last command, you should see the following output.

You have just turned you Mac into a BLE peripheral that advertises the “echo” service with UUID EC00. You can check this in the main.js file:

One we connect to the Mac, a characteristic with UUID “ec0e” will be available with the read, write and notify properties. This is defined in the characteristics.js file, which defines also how the read, write and notify properties are handled.

Now that we have a fully functional peripheral. Let’s develop a small iOS app that interacts with this peripheral.

The iOS central app

The central app will be straightforward. It searches for devices advertising the ‘echo’ services, and then connects to first device that it finds. Next, the app will allow us to read and write the ‘ec0e’ characteristic. Here the steps required to initialize the project:

Create a new single view app

Configure your project to use swift

After the project creation is completed, we will add the BlueCap iOS framework https://github.com/troystribling/BlueCap. There different to add the framework, I let choose the one that suits you best :). Do not forget to add the BlueCapKit as an embedded library !.

We will also add the CoreBluetooth Framework the project since BlueCap is wrapper for CoreBluetooth.

Next add the central capability in the project properties. To do this, enable background modes and check “Uses Bluetooth LE accessory”.

Our storyboard contains one ViewController that shows a loading indicator while scanning for the characteristic that we want to use. Once we discover the characteristic, the ViewController shows a view that allows to read and write the characteristic.

Our main view controller performs the following tasks:

Initializes a CentralManager which is a class that allows to scan for peripherals

Scans for the peripherals that advertise the service “ec00”

One we find the first peripheral that advertises such a service; we connect to it

Then, we discover the service “ec00”. This step may seem a repetition to step 2, but it is very important because it instantiates a Service object which will help us get the desired characteristic.

After discovering the service, we use the service instance to discover the characteristic “ec0e” and register for notifications

It is also possible to use a single chain to perform all the previous steps.

After getting a reference to the Characteristic object, we can also read and write data.

Conclusion

This article is a brief introduction to Bluetooth Low Energy. It is a Bluetooth standard that allows to communicate with reduced energy and without the need to pair in the system settings. We illustrated a Bluetooth central implementation on iOS that connects on a peripheral simulated on a Mac.

We can do more things using BLE. For example, we can write our own app for a smart band. We can also, for example, equip an Arduino with a BLE chip and do funny stuff with it.

The source code is available here: https://github.com/yostane/iOS-BlueCap-Example

Happy coding :).