This document is still a work
in process. Please contact us if you have any comments, questions, or
complaints.
Revision NC March 2, 2005
This document is an
introduction to the use of Bluetooth for embedded control applications. Although there are many resources that
discuss Bluetooth for wireless headphones, keyboards, mice, and similar uses,
this document is confined to the advantages and potential pitfalls of using
Bluetooth for embedded control.
In general, Bluetooth can be very useful for certain embedded
applications, but applications that require either very high data reliability
or guaranteed data availability will have to be designed very carefully since
these are both weaknesses in Bluetooth.
Bluetooth is a radio
communication system that is intended to replace any cable in any short-range
communication link. It easily meets
this goal in non-demanding applications such as connecting a keyboard to a PC or
headphones to a cell phone, but will have great difficulty replacing an EIA-485
link with more than eight nodes.
Several dozen potential applications have been identified by the
Bluetooth SIG, and are supported with specific protocols. One of the intended applications is the replacement
of legacy EIA-232 links. Bluetooth
works well for EIA-232 applications that don’t push the envelope of the EIA-232
specification.
Bluetooth uses the ISM band
starting at 2.4GHz. Bluetooth divides
this band into 79 sub-bands and hops among them as described below.
Bluetooth devices connect to
each other in a network called a piconet.
A piconet may consist of from two to eight devices. In a piconet, one device is always the
master, and the remaining devices are all always slaves. Master-slave roles are never exchanged
because the message and channel timing are derived from the clock and Bluetooth
address of the master. A device may
participate in more than one piconet at a time, and may be a master in one
piconet and a slave in another piconet at the same time. A device may not be the master in more than
one piconet at the same time.
Since Bluetooth shares its
bandwidth with many competing services, a piconet attempts to reduce
interference by hopping from one frequency to another at frequent
intervals. Since there may be more than
one Bluetooth piconet in an area at the same time, the hop pattern that a
piconet uses is partially determined by the unique BT address of the master
device. The Bluetooth devices themselves negotiate this frequency hopping; the
user or designer does not have any role.
Unicast links are
bi-directional transmissions that exist between exactly two devices
irrespective of how many devices are in the piconet. Messages may be sent in either direction. A connection process must be executed before
any messages can be sent.
Broadcast links are one-way
links that contain a master and any number of receivers, including zero. No connection process is ever used. All messages go from the master out to
whatever devices can receive them.
There is no mechanism to resend in case of errors, so the usual solution
is to send every message several times and hope for the best. Better performance can be achieved by using
message based error recovery methods such as convolution.
Bluetooth does not support
multi-casting. (Define multi-casting REVISIT THIS LATER) A piconet with more
than two devices communicates by having the master exchange data with one slave
at a time.
Data coming into a Bluetooth link passes through several layers, all of which add a time delay to the message traffic. For an EIA-232 link, this time is measurable, and may be significant. For one particular application, a message exchange that requires about 60 ms over a wire line takes at least 120 ms at close range. At greater distances, where the link is weakening anyway, the delay can be seconds. In fact, it is possible to place two devices at a distance such that the link will be maintained but no data can be exchanged. This is more noticeable for longer messages than for shorter ones.
The Bluetooth standard says
that the data rate is 1 Mega “symbols” per second. After subtracting overhead, this leaves about 721K symbols per
second. For Bluetooth 1.1 and regular
Bluetooth 1.2, a symbol is one bit, but for Bluetooth 1.2 EDR (Enhanced Data
Rate) a symbol contains 3 bits for a data rate of 2.1 Mbps.
Data rates up to 128Kbps are
ensured by the Bluetooth specification, while support for higher data rates is
optional. For EIA-232 replacement, the
limiting factor is generally the EIA-232 level converters. In this case, the maximum useful bit rate is
10K – 20K Bytes/sec.
The difference between
128Kbps and 721Kbps or 2.1Mbps is not discussed in the Bluetooth specification.
Data is sent in packets that
may vary from 17 to 339 data bytes. The
size of each packet is determined on the fly by the transmitting and receiving
devices, the user and programmer have no influence over the size.
Apparently, at one time the
data rate was going to be adjustable for longer range. There are older documents that show
tremendous ranges at very low data rates.
Whatever the situation was, the date rate is now fixed as described
above and the range is limited to around 10 meters. The range is somewhat shortened by stucco walls, and shortened a
lot by block walls. Metal objects, like
vehicles, don’t seem to affect the range at all.
The Bluetooth specification
does take some measures to ensure the reliability of the data. However, keep in mind that for the vast
majority of Bluetooth applications, the odd dropped bit doesn’t really matter
and in most cases won’t even be noticed.
Even for keyboards, the user can easily back up and fix the error. For
several applications, like headphones and cell phones, the data ages very
quickly and becomes useless. For other
applications, the data must get through intact. This is controlled by a quality of service setting in one of the
data transport layers. The setting may
adjusted to indicate that the data has a limited lifetime after which it
becomes invalid, or that the data should be delivered within a given time
period, or that the data is reliable and should be delivered without error,
regardless of how long it takes.
Bluetooth uses forward error
correction (FEC), header error check (HEC), and cyclic redundancy checking
(CRC) to detect most errors. If errors
are detected, the higher quality of service settings will resend the data. However, Bluetooth uses the CCITT generator
polynomial for CRC. This polynomial has
a higher rate of undetected errors than, for example, the generator polynomial
used by CAN. Unlike CAN, Bluetooth is
not intended for applications with severe noise.
Broadcast mode, where one
master is sending the same message to several or many slaves, sends error check
data, but never resends data in response to an error. Although the data is usually sent several times, it is
nevertheless described in the specification as inherently unreliable.
If very high reliability is
required, then the application must take additional measures on its own. Convolution can be used for a new
application, but of course, it can’t be readily retrofitted to a legacy
application.
Unlike reliability, the
Bluetooth specification takes great pains to provide very good security. Security measures are provided at both the
application layer and the link layer.
All of the security processes are optional, and can be ignored where
less security is required.
Even though eavesdropping on
a Bluetooth link is not particularly likely, it is theoretically possible, and
some applications will need to take additional measures. For the most part, this is left up to the
individual application to establish.
Before discussing security, some definitions are in order.
Authentication is a procedure
for verifying the identity of a remote device.
The two devices share a secret key and use a challenge-response scheme
to check each other’s keys. In this
scheme, the verifier sends a random number to the claimant, which processes the
number with the key and returns it to the verifier. The master is not required to be the master, and in some
applications, both devices may challenge the other using a different random
number generated with the same key.
After a failed attempt, a waiting interval is imposed before the
verifier will start a new authentication on the same claimant. This interval increases for every failure to
reduce the usefulness of simply trying a large number of keys. Bluetooth can generate and store the keys
required. Although the specification
devotes considerable space to a very thorough discussion of authentication, it
does not ever explain where authentication takes place: in the application, or
in one of the transport layers. The
generation and management of keys is so complex that leaving it to each
application would seem to be counterproductive, but there is no indication that
anything else is in effect.
Bonding is the procedure for
performing the first authentication, where a common link key is created and
stored for future use.
Pairing starts with a mutual
authentication, regardless of the security level, and then requires a user
created PIN from both devices. After a
successful pairing, the remote device is considered to be a trusted device.
Authorization is a procedure
where a device grants a specific level of access to a specific remote
device. It assumes that the remote
devices identity has already been verified through authentication. Bluetooth does not handle authorization; it
is left to the application.
Bluetooth supports security
mode 1, also known as “non-security” mode, and security mode 2, also known as
“service-level enforced” security. It
does not handle security mode 3 “link-level enforced” security.
Bluetooth uses encryption
derived from the Massey and Rueppel summation stream cipher method. This method has been widely researched and
its strengths and limitations are well documented. Bluetooth uses a high resynchronization frequency to disrupt the
more common methods of attack. The
encryption key is changed for every data packet.
Low power consumption is not
one of Bluetooth’s strongest points.
The current drain is highest while waiting for a connection and is about
30 times higher than idle mode. If the
application doesn’t need the quickest response to a page or inquiry, then the
scan duty cycle can be reduced to as low as 0.5% at the expense of response
time.
Masters and slaves exchange
packets during timeslots. Each timeslot
is 625 microseconds. The master sends
data during a master timeslot, and the slave must accept or reject the data
during the next timeslot. Thus, a
master always knows when a packet will be sent and when the acknowledgement
will arrive. This means that the master
can reduce power without losing data or time.
The slave does not know when data will arrive and must assume that data
will arrive on every master time slot.
It must leave its receiver powered up for most of the master slot
duration. The result is higher power
consumption for the receiver than for the transmitter. In fact, when no data is being transmitted,
the receiver will draw around five times as much current as the transmitter.
The Bluetooth SIG dealt with
this by creating low power modes called sniff, park, hold and deep sleep. In sniff mode, the slave spends less time
listening for master transmissions. This requires the master to only send in a
specified ratio of the total time slots, but communication does continue. In park and hold modes, the slave stays
synchronized to the channel, but it does not participate in message
exchanges. This reduces the slave power
consumption to about that of the master, but that is still nearly 2 mA.
Bluetooth is very complex. The current revision of the specification is
1200 pages, which does not include over two-dozen protocols for specific
services.
A few companies have produced
Bluetooth modules that are intended to be drop-in replacements for RS232
links. They are successful in less
demanding applications, which covers more than 99% of all RS232 applications,
but links that require high data reliability or guaranteed data availability
will have to be tested very carefully.
These modules are available for under $70 in small quantities. At this time, they can be built in-house for
considerably less, but this product is perfect for manufacture in Asia at
dirt-cheap prices. When the market gets
large enough to attract Chinese manufacturing, it won’t be worthwhile to build
your own. CSR in particular has tried
to jump-start this process by producing a complete RS232 replacement design
guide, including schematics, parts list and a list of the required
certification tests.
At this time, there are no
commercially available drop-in replacements for communication formats other
than RS232. Bluetooth could be
considered for low speed, low message rate RS485 networks with eight or fewer
nodes at comparatively short distances.
Embedded Bluetooth is
probably most common in USB HID products such as keyboards and mice. Bluetooth cannot support the data rates or
guaranteed latency requirements for either Full Speed or High Speed USB and so
is not a candidate for replacing these links.
At this time, there are three
Bluetooth IC providers: CSR, Broadcom, and National Semiconductor.
CSR claims to have 2/3 of the
market including Apple Computer, AIRCable, Brainboxes, Dell, Sony, IBM, and TDK
among many others. As explained above,
CSR has gone to great lengths to make first time Bluetooth designs successful.
Broadcom has devices
specifically aimed at particular markets, such as cell phones and
keyboards. The keyboard device includes
key interface hardware, and key scanning logic in addition to the Bluetooth
parts. Broadcom’s web site doesn’t
appear to offer any design aids of any sort for any of its products.
National Semiconductor has a
page on its web site devoted to Bluetooth in general, and a Bluetooth IC in
particular. However, none of its
distributors has any information on it, and inquiries to NSC went unanswered.
Of the more than 60 protocols
that have been published so far, only a few are of any interest for embedded
applications. They are listed
here. Even so, most can be ignored for
most applications. Only RFCOMM and
perhaps SPP require any attention from the application.
L2CAP Logical Link Control
and Adaptation Protocol
LAP Lower Address Part
LCP Link Control Protocol
LMP Link Manager Protocol
OBEX Object Exchange Protocol
RFCOMM serial cable emulation
protocol
SPP Serial Port Profile
Broadcom web site,
www.broadcom.com
CSR web site, www.csr.com
National Semiconductor web
site, www.nsc.com
BlueCore Bluetooth
Qualification Summary, CSR April 2002
RS232 Cable Replacement
Example Design for BlueCore2-External May 2003 CSR
Specification of the
Bluetooth System version 1.2 November 2003
TDK blu2i Module User Guide