Communications

Building-in Bluetooth

13th January 2014
Nat Bowers
0

There are three key design considerations when adopting Bluetooth: which version of Bluetooth to use, which profile or profiles to select and how to choose the right module for your application. David Potts, Technical Marketing Manager, Semiconductors, Anglia, explores further in this article from ES Design magazine.

Bluetooth is still one of the best wireless cable replacement technologies out there. Its popularity means that it is very widely supported, and there are many low cost modules that make system integration very straightforward. Using one of these modules, though, can be like dining in a foreign restaurant. The hard work of cooking is done for you, but you do need to understand the menu properly before you order.

The latest Bluetooth Core Specification version adopted by the Bluetooth SIG is v4.0 (called Bluetooth Smart). It includes Classic Bluetooth, Bluetooth high speed and Bluetooth low energy protocols. Bluetooth high speed is based on Wi-Fi, and Classic Bluetooth consists of legacy Bluetooth protocols.

Figure 1: Bluetooth as a ‘wireless cable’ 

Figure 1: Bluetooth as a ‘wireless cable’

There is a lot of buzz about Bluetooth Low Energy around at the moment. Bluetooth Low Energy (BLE) is a new radio standard but is very different to classic Bluetooth; it still uses the same 2.4GHz band as other standards but with a totally new protocol stack. It uses only 20% of the power consumption of Bluetooth classic with low sleep and receiver currents of only a few mA. It offers a fast reconnect speed and is aimed at low data rate applications (optimally <40Kbit/s) over ranges up to 50m. BLE has a lot of potential but since today there is limited profile support, not all smartphones or tablets support it and the availability of BLE Modules is limited, unlike classic Bluetooth. As all versions of the Bluetooth standards are designed for downward compatibility, however, the latest standard covers all older versions.

Profiling

Profiles define which application protocol runs above the lower RFCOM transport level (see Figure 3) and both host (e.g. Smartphone) and client (e.g. Sensor/Accessory) must support the chosen profile. Not all profiles are equally important. The majority of Bluetooth implementations only use a few of the profiles. The most common are: SPP (Serial Port Protocol), HID (Human Interface Device) and A2DP (Advanced Audio Distribution Profile).

The Bluetooth SPP emulates a COM Port over Bluetooth for cable Replacement Applications, the Bluetooth driver on the host computer creates a virtual COM port, after a successful pairing where the COM port is open the Bluetooth connection to the slave is then opened.

The Bluetooth HID profile is typically used for keyboard and mouse applications; the host computer loads the HID driver when pairing is successful. The HID profile is a standard interface across platforms and is a single direction connection, if bidirectional communication is required the SPP should be used.

The Bluetooth A2DP allows for wireless distribution of stereo audio This profile defines how audio can be streamed from one device to another over a Bluetooth connection. For example, music can be streamed from a mobile phone, to a wireless headset or a hearing aid. The Audio/Video Remote Control (AVRCP) profile is often used in conjunction with A2DP as it allows for basic play/pause, next/previous type control. A2DP is designed to transfer a uni-directional 2-channel stereo audio stream to a headset or car radio.

Module architectures

There is a wide selection of Bluetooth Modules available and they don’t all offer the same functionality. Some modules are also known as a HCI (Host Controller Interface), where the Bluetooth Stack and profiles need to be implemented in software on a separate host microcontroller. HCI is a standardised communication between the host stack (e.g. a PC/mobile phone OS or embedded microcontroller) and the controller (the Bluetooth IC or Module). There are several HCI transport layer standards, each using a different hardware interface to transfer the same command, event and data packets. The most commonly used are USB (in PCs) and UART (embedded applications).

Class Consumption (mW) Output (dBm) Range (m)
Class 1 100 20 ~100
Class 2 2.5 4 ~30
Class 3 1 0 ~10

 

Table 1: The power classes of Bluetooth modules

In Bluetooth devices with simple functionality the host stack and controller can be implemented on the same microprocessor. In this case the HCI is optional, although often implemented as an internal software interface. If you use a Bluetooth host stack it will allow you to add additional profiles in the future and the module is likely to be lower cost. However the downside is that it will inevitably lead to a longer time to market and increased development costs. There is also the additional cost to license the stack, most are licensed per unit. If you use a module with the stack on-board it will be simple to integrate and you can focus on what is important to you — your application — and not worry about the Bluetooth profiles.

For most designers, who want to get to market quickly and don’t really want to get involved with the detail of Bluetooth, modules such as the Microchip range with profiles and stack built in are ideal. These can be used alongside any suitable microcontroller and sometimes as a stand-alone device without a micro.

Table one show the different power classes of Bluetooth module available, showing there is a relationship between power consumption and transmission range.

Figure 2: Bluetooth Human Interface Device based solution 

Figure 2: Bluetooth Human Interface Device based solution

The effective range varies due to propagation conditions, material coverage, antenna configurations and battery conditions. Most Bluetooth applications are used in indoor conditions, where attenuation through walls, and signal fading due to signal reflections will cause the range to be far lower than the specified line-of-sight ranges of the Bluetooth products. Choice of class demands careful consideration of how the system will be used. In an industrial automation application for example, if the module is just there to load configuration data into the product, a Class 3 module with a range of 10m is probably fine, but if the module needs to send data across a factory floor, a Class 1 module is probably required.

Related to this question is the choice of antenna. The main options are a module with an integrated antenna or a separate antenna. The first is simpler to integrate and more compact, and the second offers more flexibility, longer range in some circumstances and a smaller form factor for the module itself. Again, for designers wanting to get to market quickly with the minimum of fuss an integrated antenna is best, unless there is a compelling reason to separate the antenna out.

Figure 3: Different Bluetooth module architectures 

Figure 3: Different Bluetooth module architectures

Interfacing and pairing

Having selected the architecture and the class of module that an application needs, two key questions remain: how easy is it to interface to the module and how well is the issue of pairing handled.

Having drawn up a shortlist, purchasing the low cost development kits offered by most manufacturers and trying to get them up and running is a great move. Well-designed Bluetooth modules such as the Microchip range are extremely easy to use, with UART and USB hardware interfaces and will be up and running in an hour or two. The underlying Bluetooth protocol is unseen by the user. Data written to the UART is sent out over the Bluetooth link and data received over the Bluetooth link is read from a UART. There is also a command mode which is entered through an escape sequence and is used to configure parameters such as baud rate, device name and pin code; once set the settings can be stored in Flash.

Figure 4: The Microchip range of Bluetooth modules 

Figure 4: The Microchip range of Bluetooth modules

Anyone who has used a Bluetooth product will be familiar with the issue of pairing. This can be awkward and fiddly for the user, especially for systems without a screen. It is worth exploring how modules handle the discovery, authentication and pairing process especially if the system is to be managed from Apple phones or tablets, since these have a unique discovery/pairing sequence. Ideally, auto-discovery and pairing would require no software configuration.

To be marketed as a Bluetooth device, a product must be qualified to standards defined by the SIG. A network of patents is required to implement the technology, which is licensed only for that qualifying device. A product will also need RF certification in each country in which it is to be sold. Basing a design on a properly qualified module developed by a SIG member means the approvals and licenses come as part of the package. It is well worth checking that any module chosen has the appropriate certification for each country in which the product will be marketed. The time and effort involved in getting a product certified in a market from scratch shouldn’t be underestimated.

Figure 5: The ideal architecture for a Bluetooth system 

Figure 5: The ideal architecture for a Bluetooth system

A final point to be aware of is that any company taking a product to market must be a member of the Bluetooth SIG (no cost) to use the Bluetooth logo on a product, packaging or marketing materials.

A Bluetooth interface implemented with a well-designed module is no harder to create than a cable connection and can provide the user with a lot of extra flexibility and additional features.

Product Spotlight

Upcoming Events

View all events
Newsletter
Latest global electronics news
© Copyright 2024 Electronic Specifier