This document is a non-technical survey of communication standards that have, or may have, some usefulness for embedded applications. It contains a brief description of each standard, but focuses on the comparative advantages and especially the disadvantages of each.
The Electronic Industries Association formerly released all of its specifications as RS (Recommended Standard) plus a number. More recently, the EIA changed its name to the Electronic Industries Alliance, joined forces with several other single industry standards organizations, and changed its standards designations to EIA- plus a number.
The original RS 232 specification described how to connect a mechanical Teletype machine to a dumb modem. For all other applications, the engineer was left to his own imagination. Engineers responded with great imagination, and eventually entire books were written on connecting machine A to machine B.
For many years, EIA 232 was available on every desktop computer, but this is no longer true. Apple Macs don’t have any EIA 232 ports. Home and home office machines from Dell and HP don’t include serial ports, although their larger (“professional”) machines still do. These ports are being replaced by USB, but EIA232 is still the fastest path to a solution for point-to-point short-range communication, if only because every embedded programmer already has a filing cabinet drawer stuffed with routines written years ago.
EIA 232 is specified for data rates to 20K bps at distances up to 50 feet, or 2500 pF. What the heck is that equal to? For telephone grade wire, which is 24 gauge solid unshielded twisted pair (UTP) with PVC insulation, it works out to about 100 feet. For Cat 5 UTP, which is only about 15 pF per foot, it is about 160 feet. These distances are for the maximum bit rate. Texas Instruments ran some tests years ago that showed that at 9600 bps EIA 232 would work perfectly well with 500 feet of cable.
The required hardware can be cheap, if the board already has +12V and –12V digital power available. Otherwise, the required DC-DC converter requires several capacitors, and the cost and board space can become a consideration.
The primary drawbacks to EIA 232 are that it connects only two points, the data rate is not up to modern requirements, there is no standard communication format, and there is very little noise immunity.
EIA 561 is the same as EIA 232, except that it uses modular (telephone) connectors.
EIA 422 was originally designed as an RS 232 “extension cord”. It uses differential signaling, so it isn’t plug and play but it can handle data rates to 100Kbps and 4000 feet of cable. EIA 422 also specifies a party line mode with one transmitter and up to 10 receivers. There are some very non-standard dual half duplex concoctions that allow bi-directional communication after a fashion, but EIA 422 is not true multi-point. These set-ups offer no advantage over EIA 485.
EIA 485 was the first high speed, long distance fully bi-directional communication specification. It is still the only EIA hard wired (that is, non-RF) communication standard that allows multiple transmitters and receivers in a bus configuration. A configuration can get by with a single two wire twisted pair if half duplex is sufficient, while two, two-wire twisted pairs will provide full duplex.
Half duplex is very easy to hook up, although, since the standard connector is a DB9, there are still several opportunities to get it wrong. Since EIA 485 is differential, it is very reliable, especially in noisy environments. The required hardware is low cost, about mid-way between EIA232 and CAN bus.
The specification allows for up to 32 “unit loads”. But not all transceivers are unit loads. The more recent designs are ¼ or even 1/8 unit load and so a network can have up to 128 or 256 devices respectively.
The specification allows data rates up to 10 Mbps and cable length to 4000 feet. “Short” cables don’t require termination, but termination is required for longer cables. A short cable is defined as one where the rise time of the signal is at least four times the propagation delay through the entire cable. There are two ways to terminate the cable correctly. One is to put a 120-ohm resistor across the inputs to the units at both ends of the cable. The other way uses that resistor, plus “fail safe” resistors to power and ground, also at both ends. The fail-safe resistors force the inputs to a known state even when the cable fails or falls off. However, the termination and fail-safe resistors greatly increase the power required. One way to reduce the power is to use zener diodes instead of resistors for the termination. They are much more expensive, but draw no power at all unless there is an over- or under-voltage condition.
One of the drawbacks to EIA 485 is the output structure is optimized for high-speed. A side effect of this is that both transistors are on simultaneously during every output transition. This “feature” enables high-speed operation, but draws enormous amounts of power; in fact, for CMOS transceivers about 99% of the total power drawn during normal operation is used during this transition. It also injects noise into the output signal, which can be very hard to get rid of. There are several ways to help cut the fat out of this power budget. One is to send fewer, longer messages. This reduces the number of overhead bits sent, which in some formats is considerable. Another tactic is to disable the transceiver in idle mode. This works best when used with transceivers that wake up and connect automatically when a message is detected. Active termination? REVISIT THIS LATER.
High data rates, low power, low noise differential signaling
800 Mbps at up to 30 feet or so
Many uses in PC backplanes, 3G base stations and video
CAN was originally developed as the Car Area Network by Bosch for automotive engine controller applications. As such, it is extremely reliable in noisy environments, very low cost, widely available, and has lots of development support. Renamed the Controller Area Network, it has found wide acceptance in many stationary applications including vending machines. Consistent with its automotive heritage and widespread use in vehicles, CAN is the lowest cost communication protocol. It is an excellent choice for large networks of hard-wired controllers that need to exchange medium quantities of data at medium rates
CAN is fully differential and has built-in CRC and automatic message resend if necessary. The CAN controller handles all error detection and message retransmission; the designer does not have to even think about them. However, this does mean that message timing can be described as elastic at best. Messages will eventually get through, but priority must be planned carefully in advance. All messages are broadcast to all nodes. Every message is accepted either by every node or by no nodes. In the latter case, it will be retransmitted automatically. Although a node receives every message, it only acts on some as described below.
CAN was specifically designed for reliable communication in difficult circumstances. All random errors of up to 5 bits per message are detected. All burst errors of up to 15 bits are detected. All errors of any odd number of bits are detected. The odds of an undetected corrupted message are less than 4.7X10-11. Detected corrupted messages are automatically resent
A message can be acted upon by one, several or all other nodes. Nodes don’t have addresses, so a node can be added or subtracted at any time. Nodes act upon messages based on message acceptance filters. This means that one message can be accepted and acted upon by multiple nodes and that any one node can accept and act upon multiple message identifiers.
Message identifiers are always either 11 bits (“Standard format”) or 29 bits (“Extended format”).
Messages may have zero to 64 bits of data. Zero length messages can use the identifier to send simple commands such as a command to turn a particular control on or off.
Every node can transmit data whenever the bus is idle. Arbitration is handled bit by bit. Every node that is transmitting is also monitoring the bus. When the level on the bus doesn’t match the level that the node is transmitting, then that node has lost arbitration and immediately stops transmitting. It will automatically retry when the bus goes idle.
USB was designed to simplify the connections between a host PC and up to 127 associated peripherals. In particular, it was intended to open up the PC to peripherals that didn’t exist at the time that the USB bus was created. It is designed to be low cost and very easy for the average end user to connect and use. Unfortunately, none of the readers of this document are likely to qualify as average end users, and USB has significant drawbacks for engineers and programmers.
There are three transmission standards under the USB label.
The first is Low Speed. It is designed for human interface devices (HID) with short, infrequent messages. Example devices are keyboards, mice, and monitor configuration applications. Data rates are limited to 10 to 100 Kbps and messages are limited to 8 bytes or fewer. The specification states that devices in this class are limited to one 8-byte message every 10 ms, although Win98 doesn’t enforce this limit.
The second is Full Speed or Medium Speed. It is designed to take over audio and telephone applications and can run at 500 Kbps to 10 Mbps Maximum data payload is 8, 16 32 or 64 bytes per message. Full Speed guarantees message latency and bandwidth.
The last is High Speed, which is designed for video and disk applications. It can run at 25 to 500 Mbps. It also guarantees latency and high bandwidth.
USB uses differential signaling and connectors that at first glance resemble each other, but there are really two different connectors. All “downstream” connectors are alike. All “upstream” connectors are alike, but are different from, and not interchangeable with downstream connectors. Downstream connectors are the squarish ones, while upstream connectors are flat rectangles. The connectors can also distribute power to downstream devices. Power is limited to 5V (at the source) and at least 500 mA but no more than 5A. Devices taking power from the bus can’t count on any more than 4.4V.
The host is always totally in charge of the communication link. When a device is connected, the host tells it to reset, and then the host assigns a unique address to the new device and configures it.
Error handling consists of CRCs and up to three retries before the host controller informs the client of a problem. Other error recovery is up to the client program, but USB is not intended for noisy applications. In particular, the CRC used is the IBM EBCDIC generator polynomial, (x16 + X15 + X2 +1) which will detect all single and double bit errors. It is not intended to be as bulletproof as the patterns used by CAN.
The primary disadvantage of USB is that there is no such thing as a generic interface, and no equivalent to a terminal emulator. Every application needs a custom PC program. Also, for low speed interfaces (the only practical kind for microcontrollers like the 68HC908 and others of that class) the message structure is limited to 8 bytes at ten millisecond intervals.
The primary advantage of USB is that it is now found on every new PC, both desktop and laptop.
Bluetooth is primarily intended for short-range cable replacement applications. Products available now include wireless mice, keyboards, headphones, wireless hands free cell phones and RS232 cable replacement. Bluetooth features cheap hardware, at least in comparison to other RF solutions, but certification costs offset this in low volumes. Bluetooth must co-exist with many competing transmitters in the same band including microwave ovens, portable phones, garage door openers and many other radio services including Wi-Fi and ZigBee.
A Bluetooth connection is designed for either point to point with exactly two ends (called unicasting), or a point to multipoint configuration (multicasting). This second mode has one master and up to seven slaves arranged in what the standard calls a piconet. For both types of links, the master always initiates every message exchange. The slaves never communicate with any other slave, and never initiate communication with the master. A device may be part of more than one piconet at the same time, and may be a slave in one and a master in another. One device may never be the master in more than one piconet at a time. This is because the piconet is synchronized to the master’s clock.
All Bluetooth links must one of the predefined protocols. There are more than two-dozen, covering every application from headphones to FAX, but only a few are of any interest for embedded applications. These are the Serial Port Profile (SPP) at the “higher” level, and some lower level protocols including RFCOMM, Link Access Protocol (LAP), Link Manager Protocol, (LMP), and the Logical Link Control and Adaptation Protocol (L2CAP). The Serial Port Profile is specifically intended to replace RS232 cables, and so many Bluetooth features are optional. This includes authentication, encryption, authorization, and bonding. RFCOMM is used as the transport protocol for the Serial Port Profile.
There are a very few commercially available, off the shelf, fully certified products to connect two BT equipped products together in SPP. This is the simplest, cheapest (in low volume) and fastest to implement solution, and should be used whenever possible. Up to eight devices can be connected together by using the RFCOMM and lower protocols directly. This method is significantly more complex, even for exactly two devices.
Bluetooth is advertised as being capable of 700 kbps and up to 300 meters. Naturally, this doesn’t mean at the same time; tests show that at 9600 baud, the range is a bit less than 10 meters. The Serial Port Profile ensures data rates up to 128 K bps. Support for higher rates is optional. Bluetooth also inherently adds a time delay to all data, although for a message stream this delay is more or less constant. This delay is not defined in the specification. Tests on one system showed that message exchanges that took 60 ms on a wired connection took from 120 ms to over 200 ms on Bluetooth. This can be much longer (several to many seconds) in a noisy environment, or at large distances (> 20 feet or so) between receiver and transmitter.
Bluetooth is not particularly low power, and the highest power mode is when a device is searching for another device. An attempt has been made to reduce power by defining a variety of times when the device is not available, presumably for transmit power off rest modes. These modes are park, hold, and sniff. Park and hold use less power than sniff, but neither mode allows data to be transferred. Sniff mode does allow at least some data exchange.
A significant difference between Bluetooth and a wired cable is the reliability of the received data. Bluetooth uses several types of error correction at each level including Forward Error Correction (FEC), Header Error Correction (HEC), CRC, and multiple rebroadcasts. Despite that, the specification doesn’t offer any hard numbers about error rates that can be expected. In fact, the specification makes it clear that in a poor RF environment, Bluetooth should be considered inherently unreliable. Anecdotal reports are that the user won’t see bad data, but for virtually all of the intended applications (headphones, etc), the odd dropped bit won’t be noticed. If data integrity is paramount, the application needs to be able to guarantee the data itself, without relying on Bluetooth.
The biggest disadvantage to Bluetooth is its complexity. The objective is to replace any data cable, from mice to streaming video. Consequently, the basic specification is 1200 pages, which does not include any of the transmission protocols. A result of this, and the second biggest disadvantage is the expensive and time-consuming certification process. $10,000 seems to be pretty typical, and several times that is common. A product must be certified to display the Bluetooth logo.
ZigBee (based on 802.15.4)
IEEE 802.15.4 is an as yet unreleased document that describes the two lower layers of a communication standard. As usual, these are the physical layer and the media access control layer. The ZigBee Alliance is building the upper layers from the network layer to the application layer
ZigBee is being designed specifically for low power, very low data rate wireless embedded control and monitoring applications. Hardware costs are supposed to be very low, on a par with CAN and RS232. But since there isn’t any hardware yet, this remains to be seen.
Estimates are that ZigBee software requirements vary from 2% to 10% of a Bluetooth link.
ZigBee is extremely low power, much lower than Bluetooth. It is intended for very long battery life with non-replaceable batteries. One suggested application is reading household utility meters while driving by. The long battery life is achieved partly by leaving the radio in sleep mode for more than 99% of the time.
Messages can be up to 104 data bytes. Message overhead consists of a 4-byte preamble, one byte start of frame delimiter, and one byte frame length byte all sent before the data. A 2 byte CRC follows the data.
Transmission speed is up to 250 Kbps at up to 30 meters at a base frequency in the 2.4 GHz band. As might be imagined, antenna design is critical. ZigBee networks are supposed to be able to form autonomously, whatever that means, and contain up to 65,534 devices, compared to eight for Bluetooth.
Channel access is Carrier Sense Multiple Access with Collision Avoidance (CSMA-CA). The networks can be star, mesh or cluster-tree topologies. Star is best for lowest power, mesh is better for scalability, and cluster-tree is a combination of both.
The primary drawback to ZigBee is that it doesn’t really exist yet. There are some products, but the certification process has not been completed and isn’t expected to be until late 2005. Only two certification houses have been selected (TUV in Europe and National Testing Services (NTS) in the USA.) Although ZigBee is being developed under IEEE auspices, the ZigBee Alliance is really a private concern. Membership in ZigBee Alliance costs $10K per year for the entry level, and almost nothing is possible without membership. You can’t even download the specification or browse the FAQs. Protocols are closely held and proprietary and are about two years behind schedule. Philips and Motorola were both early supporters but recently have cut back. This may not mean much, Motorola has a history of supporting concepts and then cutting back just as it takes off. Even so, it remains to be seen whether ZigBee will be a success.
Ultra Wide Band (UWB) (IEEE 802.15.3a)
Only legal in the USA, UWB is strictly experimental for now. The FCC is allowing only five applications for the near future. They are:
- Home and office applications known as Wi-Media that can only be used indoors.
- Automotive collision detection systems. (Dibs on calling it Wi-Boom)
- Automotive suspension systems that respond to road conditions.
- Short-range ground penetrating radar for locating underground pipes etc.
- Through the wall imaging for law enforcement and search and rescue applications.
UWB is designed to send data in very short pulses over a very wide bandwidth. Proponents claim that the pulses are so short that they will not interfere with competing radio broadcasts.
UWB is expected to achieve 110 Mbps at up to 10 meters or 480 Mbps at up to one meter.
Ethernet for Embedded Applications
Although Ethernet seems to have been around since mastodons roamed the earth, it has only recently been feasible to use it for embedded applications. This is primarily because low cost micros have only recently acquired the horsepower to handle Ethernet requirements.
Specification of the Bluetooth System: Core Specification v.1.2. Downloaded from www.bluetooth.org, which is separate from www.bluetooth.com.
Survey of Selected 802.xx Wireless Standards by David Benson and Michael Gold. White paper on the web site of SRI Consulting Business Intelligence at: www.sric-bi.com
Universal Serial Bus Specification Revision 1.1
ZigBee: Wireless Control that Simply Works by William C. Craig. Downloaded from www.zigbee.com. This is a popular title, as it references two other documents with virtually identical titles.
Toucan Technology 2444 Lexington Dr. Ventura, California 93003 on the beach between Los Angeles and Santa Barbara.