Give away medical masks when you place an order. learn more
Mention Bluetooth and the first thing that a non-engineer thinks of are the wireless earphones that seem to sprout from nearly every smartphone user’s ears. An embedded designer, on the other hand, sees a low-cost, interoperable, battery-friendly technology that can enable their products to exchange data files and multimedia streams with a growing number of consumer and industrial devices (Figure 1). In this article, we will explore some of the design issues involved with successfully integrating the technology as well as at the architectures and feature sets of a new generation of Bluetooth devices that are specifically designed for embedded applications.
Figure 1: Bluetooth, and its cousin Bluetooth low-power, provide an efficient, near-universal conduit for data between embedded applications such as glucometers (top), blood pressure meters, or other health care equipment (bottom) and a standard smartphone or tablet computer.
The original Bluetooth specification¹ and all of its variants operate in the in the globally unlicensed Industrial, Scientific, and Medical (ISM) 2.4 GHz short-range band using frequency-hopping spread-spectrum transmission. Nearly all devices on the market today support the Bluetooth v1.2 specification and its 720 kbit/s data rate. Even many low-cost products also support the V2.0/V2.1 +EDR specifications, which feature improved security, simpler pairing between devices, and modes which enable reduced power consumption. The recently-introduced Bluetooth low energy specification² features dramatically-reduced power consumption at the cost of reduced data rates and shorter effective range.
To simplify application development and interoperability, Bluetooth employs so-called “profiles” which define the functionality and behavior of the master and slave nodes for specific use cases. In addition to the profiles used by cellular accessories (headset, hands-free, and Advanced Audio Distribution, or A2DP), there are many profiles that support critical embedded capabilities. For example, the Human Interface Device (HID) profile provides support for devices such as mice, joysticks, keyboards, as well simple buttons and indicators, and the Basic Printing Profile (BPP) allows devices to send text, e-mails, vCards, or other items to printers. Other profiles perform application-specific tasks such as the Health Device Profile (HDP) or Video Distribution Profile (VDP). Still other profiles, such as the Serial Port Profile (SPP) which emulates a serial RS-232 wired data connection, perform general-purpose functions that can serve as a general-purpose M2M interface for an embedded system. A standardized “profile” is not required for creating a Bluetooth low energy product, allowing a manufacturer to write their own “custom profile” to support the needs of their application.
Chip, module, or dongle?
The program and data memory required to support Bluetooth depends on the specific MCU, radio, and profiles used in a particular application. However, as a typical example, a MCU Bluetooth stack from Texas Instruments will consume around 100 KB of an MCU’s code space, with the remainder free to be used by the application. TI’s CC2564 Bluetooth/Bluetooth low energy radio solution includes pre-integrated Bluetooth and Bluetooth low energy software stacks for several popular TI MCUs such as MSP430 and Stellaris®. Likewise, TI says that for most Bluetooth low energy applications, the protocol stack will also consume approximately 100 Kbytes of code space. If your team has sufficient RF expertise and the software skills to integrate the controller’s application code with the code required to support the protocol stack, investing 12 to 18 months of development time will be handsomely repaid by a more efficient design and lower production costs.
For products with anticipated production volumes of less than 250,000 pieces, it is often better to simplify and shorten the design cycle with a Bluetooth module that integrates a radio, its associated antenna and RF elements, and an MCU that support the Bluetooth protocol stack and manages the radio. Several companies offer a complete Bluetooth module in the form of a multichip SoC that is ideal for space-constrained or medium- to high-volume applications. Typically housed in BGA packages, modules such as Texas Instruments’ CC2540 and CC2541 series typically exchange data with their host MCUs through a UART serial interface. Some modules also provide an ASCII command mode, which enables the host to use a simple instruction set to configure and control the module.
The CC2541 is a true single-chip Bluetooth low energy solution that includes the radio, an 8051 MCU to run the Bluetooth low energy stack and application, and integrated flash. No external MCU or external memory IC is required for most applications.
Modules in the form of small board-mountable packages are an excellent compromise between ease of integration and cost (Figure 2). Compact modules are available from many manufacturers, including BlueRadios, Microchip (Microchip modules), and RFM (RFM modules). Plug-and-go devices are available as USB dongles and serial port adapters from vendors such as CSR and Microchip Technologies. They make it fast and easy to add Bluetooth capabilities to an older product by masquerading as commonly-used I/O devices and using the host system’s existing software drivers them to exchange data and control messages. One of the most popular applications for Bluetooth serial port adapters and USB dongles are so-called “cable replacement” products that provide the wireless equivalent of an RS-232, USB, or other common wired interface.³
Figure 2: Bluetooth modules such as Microchip Technology’s RN-41 and RN-42 can offer fast time to market and cost-effective wireless connectivity for products with low- to mid-volume production runs. Some of the embedded applications where Bluetooth modules are commonly used include barcode scanners, measurement/monitoring systems, industrial sensing and control, medical devices and asset tracking. (Courtesy of Microchip Technologies)
Most manufacturers provide reference designs and easily-customizable application software for their Bluetooth components, which eliminate many of usual the design-level hardware/software problems. In general, most Bluetooth profiles pairing should work seamlessly if the device and stack were tested for interoperability. All data communications in Bluetooth low energy are handled by the GATT (Generic Attribute Profile) protocol, which contains a set of standard procedures for sending and receiving data. Operating systems such as iOS, MacOS, and Windows 8 use an API that directly corresponds to the GATT procedures specified in the Bluetooth v4.0 core specification. This allows for strong interoperability between different Bluetooth low energy devices.
Naturally, some issues still remain to snag the unwary designer. While a manufacturer’s reference software will be extensively tested with all of its own products, extra care should be taken to insure the smooth paring and interoperability of various pairing modes with as many other device types currently on the market as is practical. Developers must also be careful to insure that any auto-launch applications work properly in heterogeneous hardware environments. This is also true for interoperability across multiple smartphones and computers, and, in particular, across multiple versions of operating systems such as iOS and Android.
Additional considerations are required for designs using Bluetooth low energy technology. Achieving the desired balance between minimizing a system’s energy consumption and maintaining an acceptable response latency requires that designer have a firm grasp of the concept of connection interval and slave latency. For Bluetooth and dual-mode operations, the designer needs to consider how often their application will be connected (connected all the time or on/off), and adjust the transmitter’s output power a minimum level that meets the application’s requirements.