Short-Range Wireless Design - Embedded.com

Short-Range Wireless Design

Error handling and bandwidth sharing are two major issues for engineers working on wireless projects. Here's a guide to designing short-range wireless devices that covers these and other concerns.

Wireless systems are popping up everywhere. From mobile phones and wireless PDAs to keyless entry systems, such devices are becoming part of our daily lives. In ten years, radio chips may be as commonplace in everyday gadgets as microcontrollers are today, making the chances high that you'll design one of these systems in the future.

Like microcontrollers, radio chips come in all different sizes and flavors. Wireless LAN (802.11) and Bluetooth chipsets, like 64- or 32-bit microcontrollers, are super fast and powerful. They're also more power-hungry and expensive than their smaller cousins. In this article, I'll concentrate on the “smaller cousin” wireless devices called short-range radio devices (SRDs) and the concepts used to design them.

SRDs are implemented in a small physical area, have lower data rates and lower current consumption than their bigger cousins, and are relatively simple, just as 8-bit and 16-bit microcontrollers are. In fact, 8- and 16-bit microcontrollers are the microcontrollers of choice in most of these devices. Practical examples of SRDs include keyless entry systems for cars, simple home automation devices, and wireless game controllers.

The biggest difference between 802.11/Bluetooth and SRD systems is that the high-end systems are implemented with advanced and complicated protocol stacks. These software stacks are often bought from a third-party vendor or encapsulated into the hardware. When designing an SRD, the embedded developer usually writes a small custom protocol and accesses the hardware directly. Fortunately, protocol stacks for SRDs are usually simple, but there are some pitfalls for the unwary.

Share and share alike

A radio frequency (RF) link differs from a wired connection in a couple of crucial ways:

  • Radio is a shared medium. You'll have company, both well mannered and otherwise.
  • Bit error rates are several magnitudes higher than in a typical wired system. Since modems and CD players need error-handling capabilities, you can be sure that your RF link does, too.

Because of these differences, the raw reliability of the RF link is lower than for a wired link. However, in almost all applications the end-user needs to have a reliable link. It is the responsibility of the software engineer to design a protocol that converts the raw error rate into a lower, reliable rate acceptable to the application.

You have to be prepared to share the airwaves with other systems as well as other units in your own system. Here are several approaches to doing this.

Time slicing

A technique called Time Division Multiple Access (TDMA) enables a piece of spectrum to be used “simultaneously” by having different devices use it at different time instants. This is typically done by allocating specific time slots to the various transmitters. Figure 1 shows how the available bandwidth might be shared between two devices over time.


Figure 1: TDMA access method


Figure 2: FDMA access method

An alternative to the basic time slicing scheme is found in Carrier Sense Multiple Access (CSMA) techniques. Instead of assigning fixed time slots, the basic principle of CSMA is the same as conversation between polite people: wait until your company has stopped talking before attempting to chime in. A well-mannered CSMA device implements some form of listen-before-transmit functionality, so that it waits if another device is currently using the channel. Of course, collisions may still occur if two or more transmitters seize the open channel simultaneously. (Wired systems often use CSMA, too, by the way; Ethernet, for example, implements a scheme known as CSMA/CD, which has built-in collision detection.)

Frequency slicing

The equivalent to TDMA in the frequency domain is called Frequency Division Multiple Access (FDMA). The FDMA method is implemented by dividing the available frequency bandwidth into subchannels with narrower bandwidths, as shown in Figure 2. That way each subchannel can be used independently of the others and can be assigned to an individual transmitter. Of course, these subchannels have to be spaced a certain distance apart from each other to prevent interference.

The biggest problem with FDMA is that narrower channels limit the rate at which data can be transferred. (Some subchannels may not be in use, but that fact alone doesn't make reclaiming the unused bandwidth any easier.) Narrow channels also require better filtering in the radio, which increases system cost. Also, there is still a potential for interference between channels, because strong out-of-band signals can interfere with the weak signal you are trying to receive. An adaptive approach is a good idea, with the system able to change its assigned frequency if it encounters interference.

Spread spectrum

Frequency hopping techniques, wherein the transmitter jumps from subchannel to subchannel at a rapid pace, were first used by the U.S. military. The military started using such techniques because they are difficult to intentionally jam and, unless you know the frequency hopping sequence, practically impossible to listen in on. As it turns out, spread spectrum techniques are useful for civilian applications as well. Spread spectrum techniques have two main advantages. First, they are more resistant to interference than conventional systems. Second, they can be used to provide multiple access functionality.

There are two kinds of spread spectrum: frequency hopping (FHSS) and direct sequence (DSSS). Both support multiple accesses in their own way. With FHSS, each transmitter can use a different hop sequence and thus coexist with all other transmitters sharing the same bandwidth. (See Figure 3.) A benefit of FHSS is that the order of frequencies can be made adaptive, so that frequencies found to have high interference levels are avoided.


Figure 3: FHSS access method

DSSS systems are based on spreading the signal energy by XORing the data signal with a spreading code. A system can use several different spreading codes to support multiple access, which is known as Code Division Multiple Access (CDMA). For a direct sequence multiple-access scheme to work properly, the power levels have to be relatively uniform across all transmitters, otherwise weak signals will be blocked by the strong signals. Figure 4 shows how this works. Two DSSS signals are transmitted in the same frequency band, with signal processing used at the receiver to extract the data from the transmitter with a known spreading code.


Figure 4: CDMA access method

The best wireless technique for your application depends on several factors. Of course, TDMA and FDMA are simpler to implement than spread spectrum, so you'll want to use one of those if you can get away with it.

TDMA is a natural choice if your devices won't need to transmit too often, since fewer transmissions mean fewer collisions. Also, radio regulations have mandated its use in certain bands by limiting the duty cycle you're allowed to transmit.

On the other hand, if you need a continuous communication channel for each transmitter, FDMA will likely work best.

Spread spectrum techniques are useful when lots of devices must communicate in an ad hoc fashion or when interference levels are high. DSSS must be implemented in hardware to be effective, while FHSS can be implemented in software, depending on the hop rate you need to use. (If direct sequence is used, it is usually transparent to the software developer.) Note that spread spectrum techniques rely on adequate bandwidth being available, so are not suitable for use in all radio bands.

It is worthwhile to do your best to be a good neighbor-adding listen-before-transmit functionality is not that hard to do or too much work, and you'll avoid clobbering other RF systems operating in the same frequency range. Additionally, your users will be saved a lot of trouble when operating your product together with other RF equipment.

The rules

Radio regulations govern the use of RF bandwidth-you can't just use any frequency you choose. The general rule is that you need to have a license to operate a radio transmitter. However, the authorities have designated some frequency bands as license-free, subject to various requirements. These are known generally as industrial, scientific, medical (ISM) bands.

Radio regulations differ from country to country. In the U.S., the FCC (www.fcc.gov) regulates radio use. There are several frequency bands available for general use: 27MHz, 260MHz to 470MHz, 902MHz to 928MHz, and the 2.4GHz band are the most commonly used. The 260MHz to 470MHz band has restrictions on what types of data can be transmitted; the other bands do not have such restrictions.

In Europe, most countries have signed agreements to harmonize their regulations. The European Telecommunications Standards Institute (www.etsi.org) provides information about the radio standards, and the European Conference of Postal and Telecommunications Administrations (CEPT) provides recommendations for frequency usage (www.ero.dk). Some differences still exist between countries, however. The following frequency bands are available: 27MHz, 433MHz, 868MHz, and 2.4GHz. The 433MHz and 868MHz bands are split into sub-bands with different RF power and duty-cycle restrictions.

Korea and Japan have somewhat similar legislation. Their regulations place more demands on the radio protocol. In most of the available bandwidth, the use of listen-before-transmit functionality is mandatory. Maximum transmission times and minimum silence times are also specified. The bands available are around 400MHz, 1.1GHz, and at 2.4GHz.

For the rest of the world, there are no hard and fast rules. The local governing body should always be contacted before development starts in order to have a clear handle on the local rules. FCC maintains a list of governing bodies at www.fcc.gov/mb/audio/bickel/world-govt-telecom.html.

Transceiver ICs are available from many different manufacturers for each of the different frequency bands. Most chips support only one band, but there are also products that support all frequencies between, say, 300MHz and 1GHz in one chip.

Regulations mainly affect the hardware developer. However, duty cycle and usage restrictions must be borne in mind by the software developer as well.

The choice of frequency band depends on several factors. Usage restrictions limit what bands can be used for a given application. The maximum communication range also depends on the frequency. Generally speaking, the range decreases with increasing frequency. Higher frequencies also generally support higher data rates than lower frequencies (because the available bandwidth is wider). Of course, the availability of transceivers with characteristics suitable for the application is also a concern.

Layers and all that

When discussing communication protocols, people usually talk about protocol layers. These layers together make up a protocol stack. How many layers are used and what they are termed depends on whom you talk to. I'll use the Open System Interconnection (OSI) model terminology here. As the topmost layers are more or less independent of the transmission media, we'll look only at the bottommost layers and how they are implemented in a wireless system.

Physical layer
The lowest level in a protocol stack is called the physical layer. This layer handles the physical access to the transmission media. In the case of SRDs, the physical layer has to handle communication with the RF transceiver. Digital interfaces vary quite a lot from one chip to another, but we can make some generalizations. There are three categories of chips available: transmitters, receivers, and transceivers (which are both transmitters and receivers). For the purpose of the following discussion, I'll just call all of them transceivers.

All transceivers have a data interface, usually serial. Simpler devices do not provide a clock, so the microcontroller has to take care of the timing. More advanced devices provide clock regeneration, so that the data interface looks like any other synchronous serial interface to the microcontroller. The data format also varies; some transceivers require data to be Manchester encoded (a self-clocking code that has a constant DC-level and always has at least one transition per bit), while others accept data in standard non-return-to-zero (NRZ) format.

When receiving data, the RF data is demodulated and presented to the microcontroller. Some transceivers provide only the raw data from the demodulator. For reliable operation, this data should be oversampled, as spikes and noise can exist within a bit. Because it also detects the transitions in the signal, oversampling provides bit-level synchronization. Other transceivers oversample in hardware, presenting a signal that does not have transitions in the middle of a bit.

If high bit-rates are used, one of the biggest challenges in writing the software is to ensure that the microcontroller can keep up with the incoming data. Most transceivers that support high bit rates can be connected to a standard synchronous serial interface; this saves the microcontroller from having to handle each bit separately.

Multichannel transceivers are generally programmable, with the frequency and other parameters selectable via a serial interface. Simpler devices provide a parallel interface with pins to select between receive and transmit and to put the device into power-down mode.

Additional features vary greatly from chip to chip. A useful function for receivers is a received signal strength indicator (RSSI), which can be used to implement listen-before-transmit functionality and determine RF link quality.

Data link layer
The data link layer is above the physical layer in the protocol stack. It takes care of error handling and link control. An RF link is usually half-duplex. By switching quickly between receive and transmit, we can simulate a full-duplex link. Error handling is covered in more detail later in this article.

Network layer
One of the most important factors in protocol design is the topology of the system. The protocol implementation of a point-to-point link will differ greatly versus applications in which a network of devices must communicate.

The number of units involved has important implications for the protocol used. Is there a central master, or is the networking peer-to-peer? Such issues are handled by the network layer of the protocol stack. Multiple access strategies also come into play at this layer.

Fortunately, most of these challenges are the same as in wired links. For example, Ethernet networks also employ a shared medium. Useful network layer protocols and techniques are described in general network literature.

One issue that doesn't usually come into play for wired networks (except in long-haul fibre-optic connections) is the use of repeaters. Repeaters are useful in ensuring that RF devices can communicate with each other in a wireless network. Often, the devices themselves can serve as repeaters. Adding repeater functionality is a good way to ensure reliability in complex indoor environments, where RF coverage can be hampered by multipath interference.

Coping with errors

As mentioned earlier, bit error rates are typically much higher for an RF link than a wired link. The protocol must be able to cope with this. Error detection and correction must be employed to achieve an acceptable error rate.

Most importantly, the software must reject false or garbled data. When there is no data to receive, a radio receiver will output noise. The task of separating valid data from noise is usually handled in software. In RF terms, this is known as a squelch function.

Data packets begin with a sequence of alternating ones and zeros, known as a preamble. The preamble is required in order to synchronize the radio receiver with the incoming data. Receiving a preamble is the first indication that someone is trying to communicate with your device.

In order to detect the end of the preamble and the start of the data, a synchronization word is used. This word consists of a fixed bit pattern that contrasts with the preamble. It is also used to filter out false data packets. If the synchronization word is not received correctly, the software goes back to searching for a valid preamble.

After the synchronization word has been received, a typical packet will contain header information such as source address, destination address, data length, and so on. The data payload of the packet follows that.

Many applications cannot tolerate the raw bit error rates of an RF link. The first step in decreasing the number of errors is to employ error detection. There are many ways of doing this, perhaps the most common of which is to add a checksum to the data in the form of a cyclic redundancy check (CRC). A CRC provides a much better error detection capability than more primitive methods such as parity checks. Depending on the application, detected errors may be handled by just ignoring the erroneous data or by requesting retransmission.

When using an RF link, you must also be aware of the possibilities for losing packets. Interference can garble packets. A simple mechanism for handling this is to use a packet counter. The packet contains a counter field that is incremented for each message sent. The receiver can then detect when a packet has been missed, and take appropriate action.

A more advanced option in error handling is to employ forward error correction (FEC). This entails adding redundant data to the packet. Based on this, the receiver can extract error-free data, even if bit errors have occurred in the packet. Of course, there are limits to how many bit errors can be tolerated. Bit errors will often occur in bursts, so that several consecutive bits are garbled. Error correction therefore entails interleaving the data after coding so that burst errors will be spread out. This technique is especially effective when used with FHSS. With sufficient data interleaving and error correction, the receiver can receive data even though some frequencies are jammed by interference. A sophisticated system might even avoid the jammed frequencies, by means of adaptive frequency hopping.


Figure 5: Bit error rate for a noncoherent FSK demodulator

Figure 5 shows how bit error rate varies as a function of the signal-to-noise ratio for a noncoherent FSK demodulator. The signal-to-noise ratio is determined by the sensitivity of the receiver and the received signal strength. It shows how you can expect bit error rate to change as the signal strength varies. For instance, the difference between 10-2 and 10-3 corresponds to around 2dB. In practical terms, this means that you will gain around 30% better range if error correction improves your error rate from 10-2 to 10-3 (assuming an error rate of 10-3 is what you need for your application).

Range

The practical range of an RF link is one of its most important parameters. While the hardware determines most of the parameters that govern range, the software is also important. I've personally improved the range of a wireless system by a factor of four simply by rewriting the software to filter the incoming data and improve timing accuracy. Incoming data should be oversampled and filtered if this is not done in hardware. Good error handling will also improve the practical range of the system.

The bit error rate is a function of the strength of the signal received by the radio receiver. The signal strength is in part determined by the distance between the receiver and the transmitter. RF designers use what they call a link budget to calculate the losses involved and how much signal strength will be left at the receiver. RF systems have high losses compared to other transmission media. The total loss between the transmitter and the receiver will typically be from 60dB to 120dB for a short-range link.

Interference will usually decrease the range of a link; only very strong interference will cause an RF link to fail completely. It is a good idea to do some field testing of your wireless product as soon as possible, and to do tests in different environments to see your link respond to practical interference levels.

Protocol cookbook

Here's a short list of steps to follow when doing RF protocol design. This is by no means exhaustive, but it should get you thinking about the most important issues you'll face. If you run through this list before starting with your implementation, you may save yourself a lot of work.

  • Decide on a multiple-access method. Even if you only need a point-to-point link, you should still have a strategy for sharing bandwidth with other systems.
  • Find out what error detection and correction methods you need to use. You should find out what error-rate performance you need, and plan to implement error-handling measures to reach this goal.
  • Do detailed protocol design. This entails deciding what header fields you need, how you want to structure the data, and so on. Often, it's useful to copy an existing protocol. If you are making a wireless version of an existing wired product, you'll probably want to make the protocol as similar to the original protocol as possible. Several flexible, general-purpose protocols exist; S.N.A.P. is one good example.

Winding down

Working with wireless systems is a bit different from working with wired systems, but wireless software design is not black magic. Do not expect the raw RF link to be reliable enough for every application. The protocol needs to implement measures to bring error rates down to an acceptable level. Many people new to RF have unrealistic expectations for raw RF error performance. Remember that even wired communication systems usually need error control and handling.

With good software and hardware in place, the system will be reliable and the user will be happy. Much of the work in writing software for an embedded system using an RF link is directed at ensuring that the system is reliable. Even if the system works in the lab, it may fail in the field (where it is exposed to other RF devices using the same spectrum). The best way to avoid such problems is to have mechanisms in place for tolerating and handling interference, and to do field testing in realistic environments. As always, try to anticipate possible errors, and code defensively. Good luck!

Karl Torvmark is a field applications engineer at Chipcon. He earned his MS in electrical engineering from the Norwegian University of Science and Technology in Trondheim, Norway. He can be reached at .

References

Mittag, Larry. “Magic in the Air,” Embedded Systems Programming, September 2001, p. 49.
Stallings, William. Data and Computer Communications, 5th edition. Upper Saddle River, NJ: Prentice-Hall, 1997.
Long, Nick. “Spread Spectrum Briefing,” parts 1-3, LPRA News, nos. 36-38 (2002).
Scalable Node Address Protocol, www.hth.com/snap/

Return to the September 2002 Table of Contents

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.