The market for low power, portable wireless devices is exploding, and the Bluetooth low energy 4.0 specification is a key part of developing such systems. This article looks at how modules from manufacturers such as Laird Wireless, connectBlue and Bluegiga that support the 4.0 specification can be used to develop wearable and low-power medical equipment with development environments such as the one provided by CSR.
With the increasing focus on wearable computing, the low-energy connectivity of Bluetooth LE 4.0 is enabling a wide range of devices, from portable fitness systems to smart basketballs.
Everyday items such as watches, bracelets, gloves and even toothbrushes are being updated with Bluetooth wireless technology, allowing them to capture data and send it back to an application on a smartphone or tablet. Sports and fitness trackers made up 96 percent of wearable devices shipped in 2013 and ABI Research projects 32 million such devices with Bluetooth Smart will ship in 2014.
Powering a device from a small or rechargeable battery is key for the wearable and sports market, and the ability to run an embedded link for several years from one battery is driving the adoption of Bluetooth Smart; this requires some key considerations in the design, both from the hardware and software perspective.
The key to Bluetooth Smart is its ability to work with an application on an existing smartphone or tablet. However, while Bluetooth LE uses the same 2.4 GHz ISM band frequencies as the previous Classic Bluetooth, 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 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. Initially, ‘Bluetooth Smart Ready’ indicated a dual-mode device, typically a laptop or smartphone, whose hardware is compatible with both Classic and LE Bluetooth peripherals, while the ‘Bluetooth Smart’ label indicates an LE-only device.
Bluetooth Smart gains its 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 100 ms. The maximum transmit power is also reduced to 10 mW, reducing the range to under 50 meters, which is more than sufficient for the short range wearable and home applications. This also makes it easier to implement a BLE4.0 system, as there is less need to worry about the total link budget.
Much of this complexity can be hidden by a module maker such as Laird Wireless. The Laird Wireless BL600
module combines a transceiver from Nordic Semiconductor with an antenna and interfaces, all in a compact footprint of 19 mm x 12.5 mm. 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 1: The BL600 Bluetooth Smart module from Laird Wireless allows connectivity to be easily added to existing designs.
Acquiring the data from these connections is handled by a series of profiles that include Blood Pressure, Heart Rate, Health Thermometer, Proximity and Find Me. These profiles, called Generic Attribute Profiles (GATT), provide a client-server application programming interface (API) within the operating system, along with services and descriptors.
A service is a collection of related characteristics that operate together to perform a particular function. The Health Thermometer service includes characteristics for a temperature measurement value and a time interval between measurements. A descriptor provides more information about a characteristic, such as an indication of its units (e.g. Celsius), and the maximum and minimum values that the sensor can measure.
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-bit 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.
Commands are also provided to transfer data about the characteristics from the server to 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. 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 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.
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 BLE to transfer it to any Bluetooth v4.0 device – smartphone, tablet, gateway, or computer.
In addition to carrying FCC modular, IC, CE and MIC approvals, the modules can be fully qualified as Bluetooth End Products. This enables designers to integrate the modules in their existing devices without the need for further Bluetooth Qualification, dramatically speeding up developments.
Other module makers such as Bluegiga and connectBlue are using BLE silicon from Texas Instruments
for modules that support v4.0. The Bluegiga BLE112
module can be powered directly from a standard 3 V coin cell battery or two AAA batteries to fit into the smallest designs from key fobs to iPhone accessories. In the lowest-power sleep mode, it consumes only 500 nA and will wake up in few hundred microseconds to extend the battery life. The connectBlue module integrates a temperature sensor and accelerometer and can run for up to 10 years from a single coin cell battery.
module is qualified as Controller Subsystem and supports Bluetooth low energy profiles, services and attributes developed by the customer. The module is based on the TI CC2540
system-on-chip that runs both application and Bluetooth low energy protocol stack. This includes object code with the latest BLE protocol stack supporting multiple connections, sample projects and applications covering an extensive set of profiles with source code.
The connectBlue OLP425 sample code package includes sample projects for accessing the LEDs, temperature sensor and accelerometers with the embedded software developed using IAR’s Embedded Workbench for the 8051 core in the chip.
The design of the CC2540 is split into three main categories: CPU-related modules; modules related to power, test, and clock distribution; and radio-related modules (Figure 2).
Figure 2: Block diagram of TI’s CC2540 Bluetooth Smart 4.0 transceiver.
CPU and memory
From the developer’s perspective, the heart of the SoC is the single-cycle 8051-compatible CPU core. It has three different memory access busses (SFR, DATA, and CODE/XDATA), a debug interface, and an 18-input extended interrupt unit.
The memory arbiter is at the heart of the system, as it connects the CPU and DMA controller with the physical memories and all peripherals through the SFR bus. It has four memory-access points, each of which can map to one of three physical memories: an SRAM, Flash memory, and XREG/SFR registers, and is responsible for performing arbitration and sequencing between simultaneous memory accesses to the same physical memory.
The SFR bus is drawn conceptually in Figure 2 as a common bus that connects all hardware peripherals to the memory arbiter. The SFR bus in the block diagram also provides access to the radio registers in the radio register bank, even though these are indeed mapped into XDATA memory space. The 8 KByte SRAM maps to the DATA memory space and to parts of the XDATA memory spaces. This is an ultra-low-power SRAM that retains its contents even when the digital part is powered off (i.e. in power modes 2 and 3). The 128/256 KByte Flash block provides in-circuit programmable non-volatile program memory for the device, and maps into the CODE and XDATA memory spaces.
Writing to the Flash block is performed through a Flash controller that allows page-wise erasure and 4-bytewise programming, and a versatile five-channel DMA controller is available in the system. This accesses memory using the XDATA memory space, and therefore has access to all physical memories. Each channel (trigger, priority, transfer mode, addressing mode, source and destination pointers, and transfer count) is configured with DMA descriptors that can be located anywhere in memory. Many of the hardware peripherals (AES core, Flash controller, USARTs, timers, ADC interface, and more) can be used with the DMA controller for efficient operation by performing data transfers between a single SFR or XREG address and Flash/SRAM.
Each CC2540 contains a unique 48-bit IEEE address that can be used as the public device address for a Bluetooth device. Designers are free to use this address, or provide their own, as described in the Bluetooth specification.
The interrupt controller services a total of eighteen interrupt sources, divided into six interrupt groups, each of which is associated with one of four interrupt priorities. I/O and sleep timer interrupt requests are serviced even if the device is in a sleep mode (power modes 1 and 2) by bringing the CC2540 back to the active mode.
The debug interface implements a proprietary two-wire serial interface that is used for in-circuit debugging. Through this debug interface, it is possible to erase or program the entire Flash memory, control which oscillators are enabled, stop and start execution of the user program, execute instructions on the 8051 core, set code breakpoints, and single-step through instructions in the code. Using these techniques, it is possible to perform in-circuit debugging and external Flash programming elegantly.
The I/O controller is responsible for all general-purpose I/O pins. The CPU can configure whether peripheral modules control certain pins or whether they are under software control, and if so, whether each pin is configured as an input or output and if a pull-up or pull-down resistor in the pad is connected. Each peripheral that connects to the I/O pins can choose between two different I/O pin locations to ensure flexibility in various applications.
The sleep timer is an ultra-low-power timer that can either use an external 32.768 kHz crystal oscillator or an internal 32.753 kHz RC oscillator. The sleep timer runs continuously in all operating modes except power mode 3. Typical applications of this timer are as a real-time counter or as a wake-up timer to get out of power modes 1 or 2.
A built-in watchdog timer allows the CC2540 to reset itself if the firmware hangs. When enabled by software, the watchdog timer must be cleared periodically; otherwise, it resets the device when it times out.
Timer 1 is a 16-bit timer with timer/counter/PWM functionality. It has a programmable prescaler, a 16-bit period value, and five individually programmable counter/capture channels, each with a 16-bit compare value. Each of the counter/capture channels can be used as a PWM output or to capture the timing of edges on input signals. It can also be configured in IR generation mode, where it counts timer 3 periods and the output is ANDed with the output of timer 3 to generate modulated consumer IR signals with minimal CPU interaction.
Timer 2 is a 40-bit timer used by the Bluetooth low energy stack. It has a 16-bit counter with a configurable timer period and a 24-bit overflow counter that can be used to keep track of the number of periods that have transpired. A 40-bit capture register is also used to record the exact time at which a start-of-frame delimiter is received/transmitted or the exact time at which transmission ends. There are two 16-bit timer-compare registers and two 24-bit overflow-compare registers that can be used to give exact timing for start of RX or TX to the radio or general interrupts.
Timer 3 and timer 4 are 8-bit timers with timer/counter/PWM functionality. They have a programmable prescaler, an 8-bit period value, and one programmable counter channel with an 8-bit compare value. Each of the counter channels can be used as PWM output.
USART 0 and USART 1 are each configurable as either an SPI master/slave or a UART. They provide double buffering on both RX and TX and hardware flow control and are thus well suited to high-throughput full-duplex applications. Each USART has its own high-precision baud-rate generator, therefore leaving the ordinary timers free for other uses. When configured as SPI slaves, the USARTs sample the input signal using SCK directly instead of using some oversampling scheme, and are thus well suited for high data rates.
For more secure applications, the AES encryption/decryption core allows the user to encrypt and decrypt data using the AES algorithm with 128-bit keys. The AES core also supports ECB, CBC, CFB, OFB, CTR, and CBC-MAC, as well as hardware support for CCM.
The ADC supports 7 to 12 bits of resolution with a corresponding range of bandwidths from 30 kHz to 4 kHz, respectively. DC and audio conversions with up to eight input channels (I/O controller pins) are possible. The inputs can be selected as single-ended or differential. The reference voltage can be internal, AVDD
, or a single-ended or differential external signal. The ADC also has a temperature-sensor input channel. The ADC can automate the process of periodic sampling or conversion over a sequence of channels.
The operational amplifier is intended to provide front-end buffering and gain for the ADC. Both inputs, as well as the output, are available on pins, so the feedback network is fully customizable. A chopper-stabilized mode is available for applications that need good accuracy with high gain.
The ultra-low-power analog comparator enables applications to wake up from PM2 or PM3 based on an analog signal. Both inputs are brought out to pins; the reference voltage must be provided externally. The comparator output is connected to the I/O controller interrupt detector and can be treated by the MCU as a regular I/O pin interrupt.
Another Bluetooth transceiver and SoC chip maker, CSR, also provides a complete set of tools for software development, board design and production test around its uEnergy chip. This chip sits on a reference module with 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 run standalone from an on-board coin cell to allow power measurements to be made.
Figure 3: The CSR Bluetooth Smart development system.
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.
The BLE112 from Bluegiga can be used directly with a coin cell battery. Due to 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 ohms 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.
Another option is to use a DC/DC converter to reduce the current consumption during TX/RX and data processing stages. There are several ultra-low-power DC/DC converters, and with by-pass mode, will reduce the current consumption during transmission nominally by approximately 20% when using a 3 V coin cell battery. A ferrite bead is recommended to be used to filter any excessive noise in the power supply lines to guarantee the radio performance.
A whole new generation of portable, wearable, and connected home equipment is set to take advantage of Bluetooth Smart technology. With the 4.0 version of Bluetooth Low Energy, existing designs can be easily upgraded to connect to smartphones and tablets for a wide range of new applications. Pre-qualified modules and development kits to support highly-integrated silicon devices help developers add this capability quickly and easily.