How to Build Low-Power Wireless Links for the Internet of Things Using Bluetooth 4.1

The latest versions of Bluetooth are creating a stir, not just for the latest wearable and fitness devices, but also for connecting together equipment and sensors in the Internet of Things (IoT).

Bluetooth 4.0 took a dramatic step forward to boost the power efficiency and ease of use of direct Bluetooth links, and 4.1 is adding to that with more networking capabilities. This is opening up the potential to connect many devices together using a standard smartphone.

The ability to run an embedded link for several years from one battery has driven the adoption of Bluetooth Smart 4.0 since 2010 and the networking element makes it even more appealing for IoT developers since the approval of 4.1 in December 2013. However, this requires some key considerations in the design, both from the hardware and the software perspective. The SIG recommends that manufacturers begin to implement Bluetooth 4.1 in their devices immediately to take advantage of the new features. This gives system developers reassurance to use the existing 4.0 modules from suppliers such as Laird Wireless, BlueGiga Technologies, Panasonic and ConnectBlue, and upgrade to 4.1 when the firmware is stable, providing the best of both worlds.

For the first time since the adoption of Bluetooth 2.0 + EDR, there are no mandatory features that must be claimed to use the Bluetooth 4.1 specification. However, manufacturers are required to implement all errata applied to Bluetooth 4.1 in order to comply with the specification. Devices implementing only the low-energy feature (branded Bluetooth Smart) will be backward compatible with Bluetooth 4.0 devices that also implement the low-energy feature.

Bluetooth Low Energy - version 4.0, now called Bluetooth Smart - uses the same 2.4 GHz ISM band frequencies as the previous ‘Classic Bluetooth’, but it uses a simpler Gaussian frequency shift protocol to reduce the power consumption. It also uses smaller, 2 MHz channels and direct-sequence spread spectrum (DSSS) modulation.

This combination of different channels and different modulation means that the LE and Classic specifications are not directly compatible. However, this is not a problem for the developer as all chips and modules that are certified as Bluetooth compatible can run in either mode - Classic for the older devices or as Bluetooth Smart with the DSSS version.

Versions 4.0 and 4.1 gain their low-power advantages by using forty of the 2 MHz channels, giving a link bit rate of 1 Mbit/s and an application throughput of 270 kbit/s. While this is lower than for Bluetooth Classic, the bit rate for applications is offset by reducing the latency to 6 ms from the 100 ms, which is more important for the networking and IoT implementation as it gives a quicker response to requests for data or sending control signals.

The maximum transmit power is also reduced to 10 mW, reducing the range to under 50 meters, which means it can be used for many IoT applications. Version 4.1 allows devices to support multiple roles simultaneously so that a Bluetooth Smart Ready product can act as a hub and a peripheral at the same time. The coexistence with other wireless technologies, notably Wi-Fi on the same 2.4 GHz band, has been improved and dedicated channels have been added, and it is these that specifically allow the IoT applications.

This comes from a Logical Link Control and Adaptation Architecture (L2CAP) that supports the higher-level protocol multiplexing, packet segmentation and reassembly and quality of service information that is needed for the IoT, using 64 Kbyte packets. The architecture is based around channels where each endpoint has a channel identifier (CID). The CID assignment is relative to a particular device and a device can assign CIDs independently from other devices, making it easy to add devices to a network. This allows multiple devices to be added in daisy chains, making the setup simpler.

Figure 1: The L2CAP channel architecture for Bluetooth Smart 4.1 enables a network of devices to be controlled, opening up the Internet of Things.

There is also more support for the user. With 4.1, connections are re-established automatically, so when a user enters a room, the connection is re-made. In addition, 4.1 supports bulk transfers of data, setting up a link and downloading a larger file rather than having to maintain a constant connection.

One of the areas that will be expanded with 4.1 is the Generic Attribute Profiles (GATT). These provide a client-server application programming interface (API) within the operating system, along with services, characteristics and descriptors.

These GATTs are used for handling the data for current applications such as Blood Pressure, Heart Rate, Health Thermometer, Proximity, and Find Me. New profiles for IoT applications will bring together data in different ways.

The attributes of services, characteristics and descriptors are collectively identified by universal identifiers (UUIDs). The Bluetooth SIG reserved a range of UUIDs (of the form xxxxxxxx-0000-1000-8000-00805F9B34FB) for standard attributes and these are represented as 16- or 32-bit short-form values in the protocol, rather than 128 bits, to keep the code size and complexity down.

The GATT protocol provides a number of commands for the client to discover information about the server. These include the discovery of UUIDs for all primary services, finding a service with a given UUID and then the secondary services, as well as finding all the characteristics for a given service. All of these will be part of the profiles for IoT applications.

Through GATT, commands are provided to transfer data about the characteristics from the server to the client (called a read) and from the client to the server (a write). A value may be read either by specifying the characteristic's UUID or by a handle value, which comes from the information discovery commands. Write operations always identify the characteristic by handle, but have a choice of whether or not a response from the server is required.

GATT also offers notifications and indications that are a key part of IoT links. The client may request a notification for a particular characteristic from the server, which can then send the value to the client whenever it becomes available. For instance, a temperature sensor server on a piece of equipment may notify its client every time it takes a measurement. This avoids the need for the client to poll the server, reducing the need for a regular radio link. An indication is similar to a notification, except that it requires a response from the client, as confirmation that it has received the message.

Chip and module makers are adding layers on top of the GATT to allow system developers to develop their own software using these profiles. This allows the software to be compatible with all the existing chips and modules that use 4.0 and 4.1 as they upgrade their systems.

This complexity is currently hidden by module makers such as Laird Wireless, who is using version 4.0 in modules such as the BT800, and the firmware is being developed to support 4.1 on these modules. The BT800 uses a transceiver from CSR with an antenna and interfaces, all in a compact footprint of 8.5 mm x 13 mm with an 8 dBm power output. The modules incorporate all the hardware and firmware required to support development of BLE applications, including UART, SPI, I²C, ADC, and GPIO interfaces for connecting peripherals and sensors. Connecting via these interfaces is relatively straightforward with single-, dual- or multi-wire links.

Figure 2: The BT800 Bluetooth Smart dual-mode module from Laird Wireless allows version 4.1 connectivity to be easily added to existing designs and upgraded to 4.1.

Laird adds an event-driven programming language that enables standalone operation of the module whereby sensors can be attached via any of the interfaces without the need for an external processor. A simple smartBASIC application encapsulates the complete end-to-end process of reading, writing, and processing of sensor data and then using Bluetooth Smart to transfer it to any Bluetooth 4.1 device.

Meanwhile CSR is also taking a different approach to providing networking for the IoT that can also be used by module makers. While 4.1 can provide eight to ten separate links from a smartphone to other peripherals, creating a personal area network or a daisy chain of links, CSR has developed firmware that sits on top of the 4.0 stack to control up to 65,000 devices in a mesh network.

This potentially disruptive technology places the smartphone at the center of the IoT. CSR Mesh allows for an almost unlimited number of Bluetooth Smart-enabled devices to be simply networked together and controlled directly from a single smartphone, tablet or PC for the first time.

The solution, which is optimized for smart home and IoT applications, combines a configuration and control protocol with CSR’s proven Bluetooth Smart devices, including CSR101x and CSR8811. It will allow consumers to control any Bluetooth Smart-enabled device in the home from wherever they are, including lighting, heating, appliances and security systems. Crucially for the consumer experience, solutions based on the protocol do not require the complex setup, pairing, or use of an access device such as a router.

Unlike other home automation connectivity solutions, CSR Mesh ensures direct control from mobile devices anywhere in the home because it does not have a limited range or require a hub. Developers do not have to use proprietary solutions or add anything else to create products that work easily without complex configuration.

The CSR Mesh protocol uses a mode within Bluetooth Smart to send messages to other Bluetooth Smart devices in the network. Messages can be sent to individual devices or groups of devices. It is also possible for devices to belong to more than one group. Control is enabled via standard Bluetooth Smart-enabled appliances such as light switches or via the majority of smartphones or tablets available today.

To ensure developers can get products to market quickly, CSR will be releasing a development kit to customers. The kit will offer Android and iOS application source code as well as access to binary CSR Mesh libraries.

The software does not use 4.1 features but extends 4.0 to cover a mesh topology. It is a flood mesh rather than a routed mesh so all the devices can participate as members and forward messages onto other nodes. This means it is very simple for a consumer setup as the protocol automatically handles the forwarding of messages. The originator of the message can be anywhere within the mesh and it is relayed to nodes that are out of range; to handle saturation and contention the protocol includes the features time of life and number of hops.

While version 4.1 allows master and slave modes simultaneously, the user still has to manually manage these connections, which will work with controlling smaller or core networks of devices. In this technique those limitations are not there - the connection management is deliberately much lighter.

The standard has addressing, grouping, and association and security built into the packet structure. This is similar to IPv4 but then there is a separate address field for the mesh network itself. This makes it much lighter weight than IPv4 for simple sensor information and command and control. At the moment, the capability is unique to CSR and we are working with lead customers and partners to standardize the capability, either through open source or through the Bluetooth SIG.

CSR has demonstrated the mesh running directly with a smartphone with a group of engineers laying out fifty LED light bulbs and walking in with an Android phone. With no formal configuration, they can control the network of lights.

CSR also provides a complete set of tools for software development, board design, and production test around its chips. This combines a USB programming interface and interfaces for breaking out I/O to application-specific sensors and actuators. The fully-licensed CSR xIDE software development environment includes example applications for popular Bluetooth Smart profiles and host applications for both iOS and Android smartphones to simplify the project. The Target board is normally powered from the host USB connection but can also be run standalone from an on-board coin cell to allow power measurements to be made.

Figure 3: The CSR Bluetooth Smart development system allows developers to add their own capabilities on top of the Bluetooth GATT layer.

Integrating the modules into designs is relatively straightforward, although there are several key choices to make when using batteries to provide the power for these devices. This will help the roll out of IoT applications using version 4.1, as the modules can be easily added to existing designs.

The BLE112 module from BlueGiga uses a Bluetooth 4.0 transceiver from Texas Instruments and can be used directly with a coin cell battery. Due to the relatively high internal resistance of a coin cell battery, it is recommended to place a 100 μF capacitor in parallel with the battery. The internal resistance of a coin cell battery is initially in the range of 10 Ω, but the resistance increases rapidly as the capacity is used.

The higher the value of the capacitor, the higher the effective capacity of the battery and the longer the lifetime for the application. The minimum value for the capacitor depends on the end application and the maximum transmit power used. The leakage current of a 100 μF capacitor is in the range of 0.5 μA to 3 μA, and generally, ceramic capacitors have lower leakage current than tantalum or aluminum electrolytic capacitors.

Figure 4: The BLE112 Bluetooth Smart module from BlueGiga. Using a capacitor across the battery can extend the battery life.

Using a DC/DC converter to reduce the current consumption during a transmit or receive operation and data processing is another option. An ultra-low-power DC/DC converter with by-pass modes will reduce the current consumption during transmission by around 20% and extend the battery life of the 3 V coin cell battery.


The addition of Bluetooth Smart 4.1 may seem like a small step for the evolution of the standard, but it has potential to drive some significant changes. Device, module, and system developers are looking at both 4.0 and 4.1 to deliver more sophisticated low-power networking capabilities to a wide range of low-cost devices, all controlled via the ubiquitous smartphone. Having a ready-made terminal available to connect to a network of devices is a tremendous advantage, and whether this is connected via the 4.1 channels or a network layer on top of 4.0, the Bluetooth Smart technology is set to be a significant technology for the Internet of Things.