Back to the future: Manchester encoding - Part 1 - Embedded.com

Back to the future: Manchester encoding – Part 1

When commercial options fail, try using Manchester encoding and other time-tested protocols in low-cost, low bit-rate serial communications.

When developing an embedded system that requires basic serial network communications, the list of design options are plentiful. But when all of the off-the-shelf alternatives fail to meet your requirements, it's worth remembering that traditional and well-tested protocols, such as Manchester encoding, offer some unique alternatives to the current commercial methods of wired and wireless control-data transmission.

The off-the-shelf choices are numerous. Many of today's microcontrollers offer such a wide variety of network peripherals that the possibility of not finding the right one for your application seems highly remote. Whether your system architecture requires a peer-to-peer or multi-drop topology, standards such as RS-232 and RS-485, to name a few, have loyally served the embedded development community for a long time. In addition, today's technology has expanded to include CAN bus and Ethernet as possible embedded network solutions.

For applications that are cost-sensitive, have a low data rate, and are physically constrained, some component manufacturers offer a variety of low-cost devices that interface to a simple network scheme. Dallas Semiconductor has taken it one step further and designed a family of components that communicates via a proprietary one-wire network. This novel design provides power and communications all on a single wire. These devices work well for low-cost designs where the power required from the single wire is not significant.

In wireless network applications, numerous solutions based on the use of the ZigBee protocol atop the IEEE 802.15.4 standard for physical layer and medium access control in low-rate wireless personal area networks are available off-the-shelf from companies as diverse as Amber, Freescale, Microchip, and Texas Instruments, among others. In addition, Microchip has an even lower bit-rate solution, combining its more sparse proprietary MiWi protocol atop the 802.15.4 physical layer. Freescale, in addition to its full ZigBee products, offers developers alternatives that use lower bit-rate protocols atop the 802.15.4 physical layer.

When off-the-shelf is not enough
But even with so many options, both wired and wireless, available off the shelf, there are a significant number of networked control designs where cost and physical size continue to place a heavy burden on our designs. In those cases, the usual list of suspects may not be viable after all.

Embedded developers are then challenged to dig deep and find solutions that satisfy their performance requirements, while maintaining a small physical size and a lower product cost, all without sacrificing data integrity.

For those systems requiring more power than is capable from one-wire solutions, standard off-the-shelf components may not be feasible. The solution may require a custom design that strives to balance functional requirements with a number of significant constraints.

When cost constraints are tight and performance requirements less stringent, it might be worth your while to use a “back to the future” strategy and consider the use of a well-known and well-tested serial communications protocols such as Non-Return to Zero (NRZ) or Manchester encoding as a possible solution to your embedded design.

Digital encoding for serial links
All digital serial communications share one thing in common; they all send a series of ones and zeros. From this point, the differentiating factor becomes the level of the signal, the organization of the data, how the data is encoded, and how the data is synchronized. In a design that is sensitive to component availability and overall cost, it's highly desirable that serial data is transferred with a minimum number of wires and is built from readily available components.

Non-Return to Zero (NRZ) : One of the simplest ways to transmit digital data is by having a separate clock and data line. In this approach, a clock signal of constant frequency is synchronized with its corresponding data. Depending upon the preference of the designer, the data is either latched on the rising or falling edge of the clock. Figure 1 illustrates a typical NRZ implementation.

View the full-size image

In this example the binary string “1010011” is being transmitted. Each bit is identified on the rising edge of the clock signal. As simple as this process is, you need to consider at least three fundamental drawbacks:

1. An additional line must support the clock signal. This is required to latch the data accurately. Depending upon the quality and length of the transmission line, additional circuitry may be required to provide the proper drive capability.

2. The second problem occurs if you decide to eliminate the clock signal. In this scenario the receiver will require an internal clock that is in near-perfect synchronization with the transmitter. Any phase shift between the transmitter and the receiver can cause bit errors to occur. This may seem a trivial matter. However, when the clock frequency becomes high enough, the sensitivity to phase differences between the transmitter and receiver becomes more significant.

3. A third limitation occurs when an NRZ transmission contains a long string of ones or zeros, as shown in Figure 2. This can make the synchronization between the transmitter and receiver even more sensitive to bit encoding errors. Since the line is in one state for a relatively long period of time, there are no transitions. Without transitions on the data line, it becomes impossible to see where a bit boundary is located. This can result in erroneous data encoding.

View the full-size image

The next section describes an encoding scheme that addresses these issues and provides a unique alternative to the traditional method of data transmission.

Manchester encoding
Manchester encoding offers distinct advantages over other digital encoding schemes. It has become a popular standard for low-cost radio frequency communication of digital data. Even Ethernet employs Manchester encoding that was used to deliver this article to your computer (if you're reading this online). So what exactly is Manchester encoding and how can it be used effectively in a low-cost embedded systems design?

Manchester encoding was first developed back in the late 1940s at the University of Manchester in Manchester, England. Given the time period and location, one with a proclivity for history might be inclined to believe its development was perhaps a by-product of research done by an obscure World WarII code-breaker at England's infamous Bletchley Park.

In reality, Manchester encoding was the result of research done at the University of Manchester into phase modulation techniques used for reading and writing digital data onto a magnetic storage device. Since that time, Manchester encoding has gained wide acceptance as the modulation scheme for low-cost radio-frequency transmission of digital data.

One of the most significant characteristics of Manchester encoding is its unique way of representing digital data. Rather than representing data based on a particular level, Manchester encoding uses transitions (see Figure 3) to identify a binary one or zero. In more traditional encoding schemes, a separate clock signal determines when to sample the data line. Manchester encoding uses one signal to identify the data.

Figure 3 shows two different options for encoding the data. There has been some debate over which scheme is more advantageous. The Ethernet and IEEE standards describe Option B as the method for encoding data, while the original Manchester-encoded specification described Option A. Confusion may occur when looking at the voltage signals on a Manchester-encoded line. Most line drivers will invert their signals, which have led some to believe that Option B is being implemented. In the end, when developing your own custom-designed embedded system, the choice as to which option is best may be purely academic. However, once a choice has been made, consistent implementation is a necessity.

View the full-size image

With this information, let's construct a Manchester-encoded bit stream using Option A. We will use the binary bit pattern shown in Figure 1. The first thing to do is establish what are called bit boundaries . These are the points in time where a level transition occurs. Bit boundaries are analogous to one clock period in an NRZ scheme. It's these bit boundaries that define the points where Manchester encoding of the individual bits will occur.

Figure 4 illustrates the bit stream constructed using Manchester encoding. Each point where you see an arrow is defined as the bit boundary. The arrow indicates the direction of the transition. So, using Option A from Figure 3, the first binary “1” bit is translated by a transition from a high to a low level. One clock period later, another transition occurs. This time a binary “0” bit has been encoded by a low- to high-level transition.

View the full-size image

Further down the bit stream, you will notice a transition that looks out of place. It occurs at a point halfway between two clock periods. This is called the setup point . The reason for the setup point is to ensure the signal is at the correct level prior to the next bit boundary.

Construction of Manchester-encoded data
Manchester encoding is very easy to construct. You simply combine the serial bits to be encoded with the clock running at the bit-boundary rate (see Figure 5). When you compare the Manchester-encoded output in Figure 5 with the bit stream in Figure 4, you'll see the same waveform.

View the full-size image

Decoding Manchester-encoded data
Decoding Manchester-encoded data is as easy as encoding it. You simply perform an exclusive-OR of the Manchester-encoded signal with a logical “1” at the bit-boundary sample points, as shown in Figure 6.

View the full-size image

If you prefer an analog solution for decoding, Figure 7 shows a simple circuit that can achieve the same results. The beauty of this circuit, sometimes called a data-slicer , is that it doesn't require a synchronizing clock. This eliminates the possibly of errors caused by clock jitters or mismatches between the transmitting and receiving clock signals. The only issue is the values selected for the resistor and capacitor. They must be selected so that the RC-time constant is longer than 1/2 the bit-boundary period. This will prevent detection during a setup period. While Figure 7 represents a conceptual view, in practice you would want to create some positive feedback around the amplifier. The positive feedback will provide hysteresis that will help filter out noise that could possibly be misinterpreted as a real Manchester-encoded transition.

View the full-size image

Once the hysteresis and the RC-time constant have been properly setup, the circuit will reliably decode Manchester-encoded signals. You will also notice that this circuit will work for both Option A and Option B.

Clock synchronization
Another intrinsic value to Manchester encoding is the fact that the synchronizing clock is embedded within the signal. This fact is exploited in Ethernet, which uses on-board circuitry to maintain clock synchronization. A Digital Phase Locked Loop (DPLL) circuit monitors the incoming Manchester-encoded signal and makes adjustments to its internal oscillator to keep it in constant synchronization with the transmitter's clock frequency.

The DPLL functions by sampling the incoming Manchester-encoded data with its own local clock. A simple shift register, driven by the local clock, accumulates all the shifted bits.

If the local oscillator is in synchronization with the transmitter's clock, there will be an equal number of binary 1's and 0's across the shift register. If an imbalance occurs between binary 1's and 0's, the local clock is adjusted based on the number of binary bits off center. This is why you will find a preamble at the beginning of each packet transmitted via Ethernet.

Each Ethernet packet starts with an 8-byte (64 bit) preamble, which is used by the DPLL to “lock” into the correct frequency. Since the preamble doesn't contain useful data, no data is lost. However, it does add more overhead to the data stream.

Differential Manchester encoding
A more esoteric version of Manchester encoding is a scheme calledDifferential Manchester encoding (DME). Think of it as Manchesterencoding on steroids. DME is a more efficient encoding scheme becauseit requires less bandwidth than standard Manchester encoding. Theoverhead of transmitting a data stream using DME is less because itdoesn't require a preamble, which is used by the DPLL to lock onto theclock frequency. Because of this, DME can be found in networks, such asfast Ethernet over copper twisted-pair wiring.

DME differs from standard Manchester encoding in one simple way:Manchester encoding represents binary data based on a positive ornegative edge transition at each bit boundary. DME represents data bythe presence or absence of a transition between two bit boundaries.Simply stated, if a transition occurs between a bit boundary, it'srepresented as a binary 0. An absence of a transition signifies abinary 1.

As a complement to this reintroduction to the basics of Manchesterencoding for low-bit serial network applications, a second article is available online atEmbedded.com. The article will leverage from the theorypresented here and offer a practical, real-world example thatillustrates the simplicity of implementing Manchester encoding into areal embedded design.

Robert Guastella is a senior controls engineer for TennantCompany in Minneapolis, Minnesota. He has over 22 years of experiencein hardware and software design on products ranging from industrialcontrols, to digital servo drives, to automotive electronics. Guastellaholds a BSEE from Lawrence Technological University, as well as an MBAfrom Oakland University, both located in Detroit, Michigan. He can bereached at .

Leave a Reply

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