Old, but Still Useful: The Manchester Code

Manchester encoding was developed in the late 1940s at the Victoria University of Manchester in the United Kingdom and put into service in their Mark 1 computer for the first time. There it was used for storing data on the computer’s magnetic drums. Since then, this coding method has become very popular as the modulation technique for low-cost radio-frequency transmission of digital data. For example, it is employed for the two NASA space probes Voyager 1 and Voyager 2, launched in 1977. Here it is used for control signals consisting of 16-bit/s Manchester-encoded commands, which are biphase modulated to a square-wave sub-carrier with a frequency of 512Hz. Both probes are now active for 44 years and are currently flying in the interstellar medium.

Technically, the Manchester code is a self-clocking binary code, which encodes the clock signal and the data of a synchronous bitstream in a single signal. In contrast to other techniques, Manchester encoding uses transitions from a low to a high voltage level, or from a high to a low voltage level, to represent the bit value, instead of using voltage levels. In other words, the state of a bit is determined by the direction of the transition and not by the level.

Figure 1: Waveform for the Manchester code

This means that at least one transition exists for each and every symbol (bit). All transitions of interest occur in the middle of a bit and not at the beginning, so a positive half-bit and a negative half-bit period represent each symbol. This way, the length of each bit is set by default, making the Manchester code self-clocking, something which minimizes the error rate and optimizes the reliability. The receiver synchronizes on the edges of the coded signal. The disadvantage of this is that the bandwidth is halved while the clock remains the same, since two clock cycles are required per bit due to the transmission of two logic states.

Generated From Exclusive OR of Clock and Data

The Manchester code is created from a non-return-to-zero (NRZ) data stream by a binary XOR (exclusive OR) with a clock signal having twice the frequency of the bit stream. When XORed with the ‘0’ (low) level, a low-to-high transition occurs, representing a logic ‘0’. Is a data bit XORed with the ‘1’ (high) level, an inversion occurs and the signal makes a high-to-low transition, corresponding to a logic ‘1’.

As there are two possible clock phases, there are also two accepted standards for the Manchester encoding: In the original implementation named after G.E. Thomas, a falling edge represents a logic ‘1’ (high) and a rising edge a logic ‘0’ (low). The definition used for the lower-speed versions (10MBit/s) of the IEEE 802.3 Ethernet and the IEEE 802.4 token bus standards uses a rising edge to represent a logic ‘1’ (high) and a falling edge to represent a logic ‘0’ (low). Table 1 summarizes both versions.

The Manchester code has many names. Because of the biphase nature of the clock signal used to generate the code, it is sometimes also called biphase code (with the version according to G.E. Thomas named biphase-L), or phase encoding, or even diphase code. The name Manchester II generally refers to the coding after G.E. Thomas.

Table 1: Truth table for the Manchester code according to IEEE 802.3 (top) and G.E. Thomas (bottom)

Besides the encoded data, the transferred bitstream can include preambles, for example as synchronization pulses, or to signal the encoding scheme used. Lastly, there is also the so-called differential Manchester code (DMC), which is a combination of the Manchester code and a non-return-to-zero inverted (NRZI) code. This code uses transitions in the middle of the bit like the Manchester code, but the direction of the transition changes with every ‘1’ in the data stream. DMC can be created by using an XOR function of an NRZI-coded bitstream and the clock signal.

Manchester Code Has Advantages

One of the major benefits of the Manchester code is that it avoids some of the problems of the non-return-to-zero (NRZ) encoding. There, during each bit period, a logic ‘1’ is represented by a “high”-level, and a logic ‘0’ by a “low”-level. Several consecutive “low” or “high” levels can, for example, lead to a loss of synchronization between the transmitter and the receiver, as no clear bit clock exists anymore. Common workarounds for this would be to transmit a separate clock signal or to run an independent clock at the receiver.

Another issue of NRZ encoding is what the literature calls “DC Wander”. As transmission lines are commonly AC coupled, a long series of logic “ones” will lead to a DC-like behavior of the signal, which cannot be properly reproduced by the AC coupling, resulting in a degradation of the amplitude and eventually in bit errors at the receiver. The Manchester code avoids this issue by having at least one level transition for each bit, “recharging” the line each time.

Figure 2: Flowchart for the Manches-ter code-generation script

There are other advantages as well. As the clock is encoded into the data stream, no separate clock signal is required. This makes the Manchester code a good choice for applications where galvanic isolation between the transmitter and the receiver is necessary, as a single channel is sufficient for communication. This way, it is ideal for wireless transmissions using RF (radio frequency), RFID, or near-field communication (NFC). Also, while needing two clock cycles to transmit one bit, the bandwidth is relatively high compared to return-to-zero (RZ) and NRZ codes. This is because the timing is less constraint due to the level change in the middle of two half-bit cycles. And, the power requirements are quite low, as is the error probability.

Applications Throughout the Industries

One disadvantage of the Manchester code is that the data rate is only half that of a non-coded signal as soon as the possible bandwidth is limited, for example by the clock frequency of an embedded system. So, it can only be used in systems where the bandwidth is not an issue, such as a local area network (LAN) or optical fiber communication (OFC) networks. Another problem is that at higher data rates, some frequency related complications may be introduced, making the code unsuitable for high-speed communication.

Based on the many advantages, the Manchester code is used in several applications, like video, pulse-code modulation, and many communication standards. Besides being employed by the command interface of the Voyager space probes mentioned earlier, there are other fields as well: The RC-5 protocol developed by Philips uses it for infrared remote control signal transmission in consumer applications, as does the DALI (digital addressable lighting interface) standard, which applies it to bidirectional communication between lighting control products. In the automotive world, the Interface 5 (PSI 5) uses Manchester coding, for example for car airbag sensors. And the industrial space employs it in the Profibus PA standard to monitor measuring equipment in process automation systems.

How to Generate a Manchester Coded Signal

But how do you generate such a bitstream? For quick tests, Digilent's free WaveForms multi-instrument software is a good choice. It connects seamlessly to the Analog Discovery 2 and Analog Discovery Pro oscilloscopes from Digilent, which can also work as logic analyzers, pattern generators, or power supplies.

The software supports Windows, macOS, and Linux and users can choose from any one of twelve traditional instruments including an oscilloscope, waveform generator, power supply, voltmeter, data logger, logic analyzer, pattern generator, static I/O, spectrum, network, impedance, and protocol analyzer. This way, users can capture, record, analyze, document, and generate mixed-signals and mixed-domain signals. Additionally, the WaveForms application includes a script editor tool, which allows custom programming of the instruments in JavaScript, and which can also consume comma-separated values (.csv) files for customized patterns.

Here is an example: We want to create such a file with a Manchester-encoded bitstream using a Python script. The Pattern Generator instruments of WaveForms will then output the bitstream on the DIO0 digital I/O-pin of the Analog Discovery Pro, read it back to WaveForms and decode it using the Logic Analyzer instrument.

First, we write the script. In the next step, we read the input string and convert it to binary, invert the order of the octets if necessary, and double every bit. The next step is that we generate an array for the clock signal, and then create the Manchester code from the bitstream by XORing the two arrays. Then we write the resulting code to the .csv file. Figure 2 shows the flowchart for the script.

We will have to make a few settings in WaveForms before we can run the pattern generator:  to connect the Analog Discovery Pro, select DIO0, set the output to PushPull and the type to Custom. Then, after importing the .csv file, we can run the pattern generator in Auto mode.

Figure 3: Digilent's Analog Discovery Pro is useful in many cases

How to Decode a Manchester Coded Signal

To verify that the code is working, we add a Manchester channel to the Logic Analyzer instrument of WaveForms. The parameters of the encoding need to be set the same way as we did in the Python script, as should the frequency of the bitstream. We use the first bit as a trigger and subsequently the logic analyzer outputs the signal as a waveform and in ASCII format (Figure 4). Displaying the decoded signal in ASCII format makes it human-readable.

Figure 4: The decoded bitstream in the WaveForms software

While the Manchester code is already of quite some age, it is still used widely in the industry. The generation of a coded bitstream does no longer require the use of discrete logic parts for the XORing of the clock signal and the data, as in the past. It can now conveniently be done in software. Verification of such a system is easy if developers put tools like the WaveForms software and the Analog Discovery Pro oscilloscope / logic analyzer from Digilent to use.