Short-Distance Roaming

Is it really so terribly constraining to plug the cable from a headset into your mobile phone to enjoy hands-free operation? The ability to separate the phone and headset by 5 ft at most, given a very tall individual with long arms and a briefcase, seems a weak justification for a complex RF link between the two devices. Nevertheless, this apparently trite application was among the first presented for Bluetooth technology.

More recently, serious discussions of Bluetooth’s powerful networking capabilities have added to its credibility. Of the many scenarios presented, a common theme involves a manager of one company visiting another company. Bluetooth’s small size and low cost suit it to portable applications, and there are several ways it can be used during the visit.

Bluetooth’s automatic networking capabilities would allow the manager’s PC or PDA to join others nearby in forming an ad hoc network—a piconet—when he walked into the meeting room. Short bursts of information, such as company addresses and phone numbers, could be exchanged without significantly reducing the device’s battery operating time. Internet access is more than 10× faster than a 56k modem with Bluetooth and may be adequate for most users. Figure 1 shows the decoded information corresponding to two packets.

On the other hand, if the hypothetical manager wanted to download significant amounts of data from the Internet during his visit, he would rather do so via IEEE 802.11b, not Bluetooth. Bluetooth is not intended to replace a high-speed Ethernet LAN. Its 721-kb/s maximum data rate is a long way from the 802.11b WLAN Ethernet-like technology that provides up to 11 Mb/s.

Lower bandwidth communications, such as a voice conversation, could be carried via Bluetooth. Within a 10-m radius PAN, you could, for example, download a document to a Bluetooth-enabled printer. The benefits of this technology certainly include elimination of local low-bandwidth wiring, but the capability to form ad hoc networks is at least equally important.

Under the Hood(s)

So, how does it work, and what parameters are critical to its correct operation? At the highest level, Bluetooth devices are classified according to usage model. Three examples given by the Bluetooth SIG are an Internet bridge, the ultimate headset, and automatic synchronization.

As an Internet bridge, a Bluetooth-enabled mobile phone, PDA, or PC would have constant access to the Internet. The ultimate headset refers to one that communicates via your mobile phone as long as it is within 10 m, for example, in your briefcase or on a desk. Automatic synchronization describes the process of downloading calendar and address information from your office PC to a portable PDA when you bring the two devices close to each other.

There will be many more usage models developed as Bluetooth technology proliferates. In contrast to these broad categories, profiles describe the operation of a device in more detail, stating how the Bluetooth protocol stack should be used in specific situations. For example, a computer mouse doesn’t need to communicate with a headset. Different profiles describe the subsets of the overall standard appropriate for each device.¹

At the other end of the specification hierarchy, Bluetooth can be described as an FHSS system. As in a straightforward RF link, the information modulates the carrier; in this case, GFSK is used. Bluetooth complicates matters by pseudorandomly hopping among up to 79 channels spaced 1 MHz apart. The maximum hop rate is 1,600/s.

Figure 2 shows successive frequency hops in view b. Views a, c, and d examine different aspects of the lowest, circled hop.

In contrast, 802.11b is a DSSS system intended for longer range, higher data-rate applications. It could replace the wired LAN in your office, for example, allowing greater freedom to rearrange work areas.

A pseudorandom code spreads each data bit across a 22-MHz channel by subdividing it into a number of chips. An interferer at a particular frequency, if not too powerful, will only marginally reduce the correlation of the received signal. So, if a Bluetooth transmission fell on a frequency within an 802.11b band and packet retransmission were required, it probably would be successful because Bluetooth would have hopped to another frequency.

From the Bluetooth point of view, a DSSS system looks like background noise. As long as the 802.11b signal power isn’t too high, Bluetooth won’t be affected. Of course, at some point, packets will have to be retransmitted, and throughput will degrade.

A bigger problem for both systems is the unpredictable emissions from many other types of unlicensed devices sharing the 2.4 to 2.4835-GHz ISM band. For example, a microwave oven operates in this band, and its leakage can easily swamp both 802.11b and Bluetooth signals. 802.11b is vulnerable because a microwave oven emits energy over a 20- to 30-MHz band. Bluetooth may continue to operate at reduced efficiency by limiting its hop frequencies to avoid the oven’s interference.

The extent to which either technology is degraded by the other or a separate interferer is related to parameters such as receiver sensitivity, signal strength, frequency, modulation scheme, and the quantity of other devices attempting to share the same bandwidth.

Making Sure It Works

Bluetooth really is a complex standard, involving not just the lower level layers, but also the higher level protocols necessary to support piconet formation and termination, for example. For this reason, vendors stress the importance of thorough preproduction testing to ensure that the current Bluetooth specification has been met.

Comparing how users will experience Bluetooth and Ethernet, Paul Andersen, a marketing manager at Tektronix, commented, “The big difference is the extensive conformance testing required for Bluetooth. This testing will greatly minimize the protocol problems experienced in the field with qualified devices. Testing at this level is not true for Ethernet because anyone can develop hardware and software and call it Ethernet-compatible.”

At the time this article was prepared, 203 qualified products were listed on the Bluetooth Qualification Program website, qualweb.opengroup.org/Template.cfm?
LinkQualified=QualifiedProductsz. Because of the qualification process, Mr. Andersen said he expected problems in the field to be of a more serious and complex nature. He thought that network analyzers for network performance and load testing could be useful for field-application troubleshooting.

“Actual Bluetooth protocol analyzers will be used mainly in the development, design, debug, and prequalification testing of a product,” Mr. Andersen continued. “During the development stage, analysis of protocol errors is critical to allow the software designer to determine where a problem in the code may be. Testing and debugging includes the protocol stack itself to ensure compliant operation along with the integration of the stack, the hardware, and the product’s application software.”

To speed up qualification, Ericsson and other companies sell pretested Bluetooth modules and associated software. For example, you can buy a complete protocol stack designed to run on popular target microprocessors. In this way, you can concentrate on the characteristics of your specific application rather than attempt to reinvent proven technology.

Because the Bluetooth environment is a dynamic one, the capture of many thousands or millions of data bits may be required to catch a particular error. For this reason, Bluetooth protocol analyzers don’t attempt to identify problems in real time, but instead many capture network activity to the hard disk of a host PC. You can set up a filter to selectively accept only data satisfying certain criteria, but analysis still is a post-acquisition activity.

During analysis, packets are broken into the different levels of the protocol stack for detailed examination. It may be useful to export data to an external application such as Excel. In a stable piconet, being able to analyze data statistically could uncover bottlenecks or provide insight to load factors. However, if the piconet membership is changing, loading and performance can vary dramatically.

Additional protocol-analyzer capabilities include operation in a passive sniffer mode as well as emulation of an actual Bluetooth piconet member. Some analyzers can assume the master role and issue commands. It also may be possible to inject errors to test error-detection and recovery mechanisms.

You shouldn’t assume that any type of protocol analyzer will solve all your Bluetooth problems. Just as oscilloscopes, logic analyzers, RF test sets, and communications analyzers are useful for other kinds of wireless development, they have a role to play in Bluetooth design as well.

These instruments help you verify that the physical layer is working correctly: the correct bits are being sent and decoded, and data integrity is being maintained across the RF interface. If the system still doesn’t work as intended, a protocol analyzer can show you where the data is being misinterpreted, resulting in system errors. The chart accompanying this article compares the capabilities of five popular, SIG-approved, Bluetooth protocol analyzers.

“Developers are becoming more interested in easy-to-use, comprehensive equipment that provides an integrated solution as opposed to individual instruments,” according to Paul Kaspian, product marketing manager at CATC. “This approach saves developers valuable time, allowing them to concentrate on their particular development problem rather than assembling the pieces necessary to build a test setup.”

In addition, Mr. Kaspian emphasized the importance of emulating as well as analyzing Bluetooth devices. With both capabilities, an engineer can create complex test scenarios that run automatically. Results can be color-coded to provide a way to quickly identify different types of data packets, as shown in Figure 1.

Looking beyond Bluetooth, Mr. Kaspian said that developers often work with a variety of protocols. Most protocol analyzers are dedicated to one type of protocol and cannot deal with a different one such as Bluetooth. Taking a modular approach to analyzer products will allow engineers to plug in a particular emulation/analysis combination as required.

In addition to the differing capabilities shown in the comparison chart, there also is a fundamental distinction between analyzers that use the RF interface and those that capture serial data on the link between the host processor and the Bluetooth controller. Frontline Test Equipment’s SerialBlue™ PC-based analyzer is an example of the latter type. It captures serial data at rates up to 921.6 kb/s and fully decodes data frames at the bit level.

Operating at this point in a Bluetooth-enabled product, the SerialBlue analyzer cannot provide information about piconet activity, for example. Conversely, an analyzer using the RF interface may not present information about detailed bit-level data traffic on the host-Bluetooth link. The two types of products serve different needs during the development cycle.

References

1. Bluetooth Beginner’s Guide, Ericsson, www.ericsson.com/bluetooth/
   bluetoothf/beginnersg/.
2. The comparison chart was adapted from the Bluetooth Protocol Analyzer Comparison Table at www.palowireless.com.

Additional Reading

Kawada, H., “Bluetooth Modules: Application-Specific Components Speed Product Integration,” Microwave Product Digest, April 2001, pp. 50-62.

Glossary

Return to EE Home Page

Published by EE-Evaluation Engineering
All contents © 2001 Nelson Publishing Inc.
No reprint, distribution, or reuse in any medium is permitted
without the express written consent of the publisher.

August 2001