Chapter 1. Introduction
In Chapter 2, we’ll install the tools we need to write code and deploy services. But before we do that, we need to talk about Bluetooth LE, and make sure your machine can talk to it, too.
This chapter talks about some of the jargon you’ll need to understand to work with Bluetooth LE. The following chapter walks you through installing all of the software and configuring the hardware you’ll need for the projects in this book. After working through these two chapters, you should probably proceed with Chapter 3, which is a solid introduction to working with Bluetooth and the Arduino. However, after that you should be able to pick and choose among the rest of the projects in the book.
Talking About Bluetooth LE
Bluetooth LE divides the world into peripheral and central devices. Peripheral devices are things like sensors; they’re typically small, low-powered, and resource-constrained. Central devices are things like mobile phones and laptops, although these can usually also operate in peripheral mode.
Peripherals can operate in two modes: either by broadcasting or being directly connected to a central device. The broadcast mechanism is one of the big differences between Bluetooth LE and classic Bluetooth; it allows data to be sent out by the peripheral to any device in range.
Note
The real-world range of a Bluetooth LE device depends on the transmitting power of the radio. Since higher transmitting power means more battery is required, Bluetooth LE is, unsurprisingly, a short-range standard. While it’s perfectly possible to have a real-world range of greater than 30m (about 100ft), a more typical operating range is between 2 and 5m (around 5 to 15ft).
This means that a Bluetooth LE peripheral device doesn’t necessarily need to be “paired” with a central device in order to transfer data. In Bluetooth LE, we speak of it as “connected” rather than paired as we did with Bluetooth 2.1. In broadcast mode, the peripheral will periodically send out advertising packets, available to any device that’s looking for them, for devices acting as “observers.”
The standard advertising packet describes the broadcasting device and its capabilities but is also capable of including custom information—sensor data, for instance—that you want to broadcast.
Broadcasting data from your peripheral is a good choice if you’re building something like a weather station where the data isn’t sensitive. However, there is no provision for security when broadcasting, so for personal data, the central device should connect to the peripheral, not the other way around.
Connections are exclusive. This means that a peripheral cannot be connected to more than one central device at a time. When a central device connects to a peripheral, the peripheral will stop advertising itself, and other devices will not be able to see it or connect to it until the first connection is terminated. However, whereas a peripheral can only be connected to one central device, a central device can be connected to more than peripheral at the same time.
Note
The Bluetooth 4.1 specification removed the restriction that peripheral devices can only be connected to a single central device. Going forward, a peripheral can be connected to multiple central devices simultaneously. However, there are still many devices and chipsets that remain limited in this fashion.
If you need to exchange data between the peripheral and the central device, then you need to establish a connection between the two devices.
Protocols and Profiles
On top of the protocols that make up the Bluetooth LE standard, the specification defines what are called profiles. These are either the basic modes of operation needed by all Bluetooth LE devices, like the Generic Access Profile and Generic Attribute Profile, or profiles covering specific use cases such as the Heart Rate Profile.
The GAP
The Generic Access Profile (GAP) defines roles for devices, including the peripheral and central roles we mentioned in the last section, alongside advertising and discovery.
There are two ways to advertise data using GAP: advertising data and scan response packets. While both packets use the same payload format, and consist of up to 31 bytes of data, only the advertising data packet is mandatory. It is sent out at a preset advertising interval—the longer the interval, the less power used—on receipt listening devices can request the scan response packet with additional data if it exists.
Using custom advertisement data in the broadcast packets is how both the iBeacon and Eddystone standards are implemented; see Chapter 10 for more information.
Once a connection with the peripheral has been made, you will use GATT services and characteristics to communicate with the peripheral device, and advertising will stop until the connection is terminated.
The GATT
The Generic Attribute Profile (GATT) defines how Bluetooth LE transfers data back and forth between peripheral and central devices. It defines profiles, which are collections of services. Each service has characteristics, which contain data.
Roles change when moving from GAP to GATT. GATT defines two roles: client and server.
It may seem backwards, but peripheral devices are known as GATT servers and the more powerful central devices are GATT clients. Think of it this way: the server has data and the client wants data. All connections between the devices are initiated by the client.
After connecting, the client can get a list of services offered by the server. Before connecting, the central device had a potentially incomplete list of services from the advertising data.
Services and Characteristics
Services are used to break up the data into logically associated chunks, and consist of a collection of characteristics. Characteristics are the containers that hold the data associated with a service. Both services and characteristics are identified by a unique identifier, known as an UUID; see “UUIDs”.
Characteristics contain at least two attributes: a characteristic declaration, which contains metadata about the data, and the characteristic value, which contains the data itself. The characteristic can also contain additional descriptors to expand on the meta data. Together, the declaration, value, and any optional descriptors form a bundle than make up a characteristic.
Characteristics can be defined as read or write. Characteristics are read by the client using a read request, with the returned value of the request being the characteristic value. Characteristic values can be written using a write request. The server returns a confirmation after the value is written. There is an additional write property called the write command. When a characteristic value is written with a write command, the server does not send any response back to the client. The write command is sometimes called write without response.
Two additional properties are notify and indicate. Both of these are server-initiated communication. A client subscribes to be notified when a characteristic’s value changes. When a change occurs, the server notifies the client by sending the new value. An indication is similar to a notification, except that the client must acknowledge the receipt of the indication.
Characteristics can have multiple properties. For example, one characteristic could allow read, write, and notify.
UUIDs
Bluetooth uses Universally Unique Identifiers (UUIDs) for many things, including services and characteristics. Bluetooth services that have been approved by the Bluetooth Special Interest Group are assigned 16-bit UUIDs. All other services and characteristics must use 128-bit UUIDs, which can be generated with tools such as uuidgen, as shown here:
$ uuidgen
437121E5-A6F0-43F9-8F8F-4AB73D6CC3EBIn this book, we use 16-bit UUIDs. Technically we’re breaking the rules, but for us it’s a lot easier to type DCF8 than 391CDCF8-4BD4-4507-BE23-B57DFD1F870B. See Table 1-1 for a list of officially approved 16-bit UUID ranges.
| UUID | Description |
|---|---|
00xx |
Namespace Descriptors |
18xx |
Services |
27xx |
Units |
28xx |
Declarations |
29xx |
Descriptors |
2Axx |
Characteristics |
For the LED examples, we reuse SmartBotics’ service for their RoboSmart lightbulb. For the button examples, we reused Texas Instruments’ Simple Key Service from their Sensor Tag. For the thermometer examples, we create some 16-bit UUIDs.
It’s fine to reuse UUIDs if existing services and characteristics meet your needs. If you’re making your own services, use 128-bit UUIDs. See the Bluetooth Developer Site for more information.
An Example Service
Pulling this together, let’s look at a typical example service for a lightbulb, as shown in Table 1-2 and illustrated in Figure 1-1.
This is part of the service definition advertised by a RoboSmart Light Bulb. As you can see, despite not being an officially approved service definition, like many other manufacturers, RoboSmart uses 16-bit UUIDs.
| Characteristic | UUID | Property | Value | Comments |
|---|---|---|---|---|
Light switch |
FF11 |
Read, Write |
1 |
1 on, 0 off |
Dimmer setting |
FF12 |
Read, Write |
0×7F |
0×00 to 0×FF |
Power consumption |
FF16 |
Read |
340 |
Watt Hours |
This is part of the service definition advertised by a RoboSmart Light Bulb (see Figure 1-1).
Figure 1-1. Exploring the Lightbulb service
Making Sure Your Machine Has Bluetooth LE
Support for Bluetooth LE is available on most major OS platforms. However, if your laptop or desktop hardware doesn’t support Bluetooth LE, there is a large number of Bluetooth LE USB dongles available. Many are based around the same Broadcom BCM20702A0 chipset; for this book, we used the IOGEAR GBU521 Bluetooth 4.0 USB Micro Adaptor, which can be picked up for about $10 to $15 on Amazon and other online retailers. USB adapters with the CSR8510 chipset also work well.
OS X
All Apple laptop and desktop machines built after 2011 have Bluetooth LE hardware built-in, though if you’re using a Mac built before that and running Mountain Lion or later, you’re probably still okay. You can pick up a Bluetooth LE USB adaptor and it should work out of the box.
If you’re running a pre-Mountain-Lion distribution of OS X, it’s still possible to get most Broadcom-based Bluetooth LE adaptors to work, but it’s probably going to be a lot harder. For Lion, you’ll have to go into the /System/Library/Extensions/ folder and make changes inside the IOBluetoothFamily.kext, adding the current Product ID and Vendor ID values of your USB dongle before reloading the kernel extension. For those running Pre-Lion distributions of OS X, things are even more difficult.
Apple iOS
Support for Bluetooth LE on the iPhone and iPad has existed since iOS 5, although we’d recommend iOS 7 as the minimum version because it introduced iBeacon support to the operating system. Hardware support for Bluetooth LE was introduced with the iPhone 4s, iPad (third generation), and the iPod touch (fifth generation). All current Apple iOS devices support the standard.
Linux
Linux uses the BlueZ service to talk to Bluetooth devices, and Bluetooth LE has been supported since version 4.93.
Linux users should take a look at the instructions in “Setting Up Raspberry Pi” where we talk about installing the BlueZ service to work with the Bluetooth 4.0 USB adaptors.
Android
Support for Bluetooth LE in the core Android OS was introduced in Android 4.3, although version 4.4 introduced numerous bug fixes and is probably the minimum recommeded version. Before this, though some manufacturers shipped hardware that was Bluetooth-LE-compatible, there was no software support, which caused many manufacturers to introduce their own libraries to support it—which were unfortunately all incompatible.
Microsoft Windows
Microsoft Windows 8 and above has built-in support for Bluetooth LE. Unfortunately, Windows XP, Vista, and Windows 7 only support Bluetooth 2.1, and while it’s theoretically possible to get these earlier versions to talk to Bluetooth LE devices—at least for Windows 7, it’s an extremely challenging problem that’s well beyond the scope of this book. If you’re working with Bluetooth LE under Windows, you should at least be running Windows 8.
What Haven’t We Told You About Bluetooth LE?
Lots. The Bluetooth LE specification is a sprawling mess of interlocking documents that runs to thousands of pages; the core standards document is over 2,700 pages on its own. What we’ve given you here is the barest outline, a sketch, of how the standard works.
However, it’s enough that you should now be able to go and confidently build projects using Bluetooth LE to actually do things in the real world. You can pick up the architecture and theory behind the protocols as you go along. But you have enough to get started.