As engineers design more and more products with embedded computer systems that require connections of one sort or another, we've got to pay attention to the ease with which these connections can be made. Short-range wireless protocols offer an attractive alternative to wired connections.

Of course, numerous types of localized wireless communications are possible. But as far as I can tell, only three wireless "media" are in common use today: infrared light, radio frequency radiation, and soundwaves. Examples of products that use each of these media are TV remote controls, cordless phones, and "The Clapper," respectively. In this column I'll introduce to you two wireless communications standards, one infrared and the other RF--called IrDA and Bluetooth, respectively--that will help you make the most of these media. Unfortunately, no sound-based equivalents are available.


To date, infrared has been the hands-down winner in the move toward localized wireless communications. One standard, called IrDA-Data, has already found a place in some 50 million laptops, printers, handheld PCs, PDAs, and other devices. It helps, of course, that infrared transmissions are inherently localized and that governments do not regulate the infrared portion of the light spectrum. It helps, too, that the components of an infrared transceiver have been perfected and their costs reduced through their successful use in so many remote control applications. But what if you want to send generic data-rather than one of a small number of commands-or communicate bidirectionally? That's where IrDA-Data comes in.

The Infrared Data Association is a consortium with over 150 member companies. Founded in 1993, nonprofit IrDA was established to promote standards for point-to-point infrared communications. Fearing the chaos that would erupt if each of the manufacturers of laptops, PDAs, and peripherals went off on their own to develop a proprietary infrared technology, some 50 companies came together in June 1993 to agree that infrared data communication standards were necessary. And within one year, they produced a specification.

This first IrDA standard paved the way for asynchronous data communications at rates up to 115.2Kbps and synchronous communications at 1.152Mbps. (A synchronous 4Mbps option was added to the standard about a year and a half later.) This standard is now formally known as IrDA-Data, to distinguish it from other standards bearing the IrDA moniker, including IrDA-Control. The latter is a specification for communication between cordless input devices (keyboards, mice, and so on) and the computers they control. Although IrDA-Control is perhaps another interesting avenue for later discussion, I'll avoid it and talk only about IrDA-Data this month.

Figure 1 shows a typical application of the IrDA-Data protocol. In this example, the infrared transmitter in a nomadic embedded system is aimed in the direction of a nearby printer and a document is transferred to it. If all goes well, a hard copy of the document will result-without connecting any wires or configuring either device. I've actually done this in my home office, with a laptop, handheld PC, and laser printer from three different manufacturers. It's a beautiful system to use, but how does it work? And how much does it "cost" to implement?


Figure 1. A typical application of IrDA-Data

Like any communications standard, IrDA-Data works on the layering principle. A series of hardware and software components are layered one on top of the other (the hardware is always at the bottom) to form a protocol stack. Equivalent layers exist on each device and the two application programs that want to communicate do so by making calls into their local stack.

The IrDA-Data protocol stack contains the usual suspects: a physical layer that defines data rates, the encoding of individual bits, and the way that bits are combined into frames; a data link layer that provides addressing, error detection, and retransmission capabilities to ensure the reliable delivery of all packets; and a link management layer that enables multiple simultaneous conversations between the two connected systems. These layers are roughly equivalent in function to the Ethernet, IP, and TCP layers of a typical TCP/IP implementation. (Though that is not to suggest that IrDA-Data and TCP/IP are directly compatible.)

Above the link management layer the software is more varied. Each type of IrDA-compatible system provides its own unique set of services. For example, a printer may offer only a printing service, whereas a cellular phone may offer voice services, Internet-connection services, and address book services. Each of these services may require additional protocol layers above the link management layer. And, of course, every device needs a way to advertise the services it offers so that other systems may take advantage of them.

In order to advertise their services, each IrDA-compatible device must incorporate a "yellow pages" protocol called the Information Access Protocol. When two devices approach each other and are ready to do business, they use this service to exchange information about their capabilities. The client in the transaction asks the server if it offers the desired service. For example, if you aim your PDA at another IrDA-compatible system and say "print this note," the PDA will query the remote device's yellow pages to find out if a printing service is available there. If so, the document will be transmitted to the printing service at the indicated service address (analogous to a TCP port). If not, you'll get an error message on your PDA indicating that that type of service is not available.

This brings up an important point about infrared communications: you never have to wonder which device you are actually talking to. The infrared signal is emitted in a narrow cone of light and with very little signal strength. You've generally got to be within one meter of the other device and have your infrared transceiver pointed in its approximate direction. So there's not much fear of interference from other IrDA devices (except from fluorescent lights and other background producers of infrared radiation) or eavesdropping.

The IrDA-Data protocol reflects the good and bad features of the environments in which it is typically used. For example, because no opportunity for eavesdropping exists, built-in encryption isn't available; because you can see the device at which you're aiming, you don't need to select the device with which you want to communicate from a pull-down list; device and service addresses are short; collisions between multiple senders are rare; but temporary interruptions of the signal (you set your coffee cup down between the devices, for example) are commonplace. IrDA-Data is designed to thrive in this type of environment. And it does.

Current applications of IrDA-Data include printing documents, connecting to a network, exchanging business cards, and synchronizing the address books on two distinct devices (a PDA and a cell phone, for example). What all of these applications have in common is that the user is actively engaged. It's the user who points one device at another and begins the transfer of information. That is very different from the Bluetooth communications model.


Bluetooth is a short-range wireless communications standard that utilizes radio-frequency transmissions in the 2.4GHz Industrial-Scientific-Medical (ISM) band. Although the ISM band is potentially subject to regulation (like all RF bands), most of the world's governments allow use of this particular band for localized applications and do not require individual licenses. Devices like garage door openers, baby monitors, and high-end cordless phones already inhabit the ISM band, though, so it's a potentially noisy part of the spectrum. However, the Bluetooth standard has been designed to work smoothly in this noisy, unregulated environment.

The Bluetooth Special Interest Group is the current standards body. Like the Infrared Data Association, it's a consortium of companies that prefer standards to chaos. However, the use of Bluetooth currently involves licensing certain key patents. Though these licenses are free, you must agree to some terms. In other words, the Bluetooth standard is less open than IrDA.

Though it may seem silly to even discuss a new approach to wireless communications when there is already an installed base of 50 million IrDA-compatible devices, a complementary relationship exists between RF and infrared technologies. For example, infrared communications work best in line-of-sight, point-and-shoot style applications like the exchange of business cards. You may not want to send your business card to every possible receiver in your vicinity. But the RF-style multipoint communications are more appropriate in other types of applications.

In addition to multipoint, major differences between the IrDA and Bluetooth technologies include: IrDA is directional and line-of-sight, while Bluetooth is omni-directional and able to connect through solid, non-metal objects (including walls); Bluetooth also has a much longer range than IrDA, up to 100m, depending on signal strength. Bluetooth also offers built-in support for voice channels. But one of the biggest differences is how the user controls the connections.

Bluetooth-enabled devices discover each other automatically, forming ad-hoc "piconets" of up to eight devices each. An example of this is shown in Figure 2. Once established, the devices on these piconets sit, ready to cooperate, until one or more of the devices moves out of range. They may even do certain things automatically, if you have configured them to do so. For example, when your PDA and cell phone discover each other they might automatically synchronize the contents of their address books. That way, you would always have the most up-to-date phone numbers in both places. Similarly, a laptop could instantly connect to the Internet as soon as it comes within range of an access port with which it is configured to work.

Bluetooth Piconets

Figure 2. A pair of adjacent Bluetooth piconets

Because Bluetooth-enabled devices can potentially communicate with so many devices at once and don't know who might be listening (and with what intent), data security is an important consideration. So authentication, encryption, and frequency hopping are all used to make eavesdropping and unauthorized use of x extremely difficult. Frequency hopping has the added benefit of increasing a Bluetooth network's robustness in the face of interference from other ISM band users.

Of course, like IrDA-Data, the Bluetooth standard specifies a protocol stack and divides the various communication responsibilities into physical, data link, and other layers. In order to include either type of connectivity in your embedded system, you'll need the requisite hardware, a protocol stack, and application programs that take advantage of it. Because IrDA-Data is an older standard, many vendors of these components are already available and the cost of including IrDA hardware and software is relatively low (approximately $2 per system). However, Bluetooth is just out of the standardization process and prices are significantly higher. You'll have to decide on a case-by-case basis which, if either, of these protocols would work best in your product. In some systems, it may even be desirable to include both. Table 1 provides a feature-by-feature comparison of the two technologies.

Physical Media
RF (2.4 GHz)
Communications Range
Up to at least 1m
10cm to 100m
Connection Type, Direction
Point-to-Point, Narrow Angle (30 degrees)
Multipoint, Omni-directional
Maximum Data Rate
4Mbps (16Mbps on the way)
1Mbps (aggregate)
Physical limitations offer some built-in protection
Authentication, encryption, spread spectrum
Approximate Cost
under $2
under $5

Table 1. IrDA vs. Bluetooth feature comparison

Further Reading

A lot has happened with these protocols--particularly Bluetooth--since this article was originally written. To learn about the latest developments, follow these links:

  • Wikipedia's entry for IrDA
  • Wikipedia's entry for Bluetooth
  • Open source lwBT Bluetooth stack

This article began as a column in the October 1999 issue of Embedded Systems Programming.