Why do we need to use Manchester encoding for Ethernet transmissions?

Question

When you want to transfer data from one computer to another, your data (in binary form) will first go to the NIC (Network Interface Card) where the data will be encoded (with timer clock tick for example) and sent over the network under an electronic signal.

An example of Manchester Encoding:

101110011001   // data
101010101010   // timer tick on network
000100110011   // result using XOR

Why doesn't the NIC directly transfer the binary data but must encode it first?

Answer 1

Because using manchester encoding has a nice advantage, self-clocking (lower error rate and a more reliable transmission).

This is because rather at looking at the +5 volt to 0 volt to encode a bit, it will depend on the direction of a transmission how a bit is encoded.

^{Image source}

Normally you would first need to synchronize a clock before being able to transmit. Because of this encoding Manchester Encoding doesn't need this.

Answer 2

There are at least three (there may be more) reasons for using an encoding (such as the Manchester encoding you mention) when transmitting digital information:

• The data and clock are combined into one signal. If the clock was not sent with the data, then the receiver would not know when to sample the signal to extract the digital values. Even if the transmitter and receiver are somehow perfectly synchronized, the infinitesimal delay of the transmission medium would have to be accounted for. The other alternative is to accompany the data line with a clock line, but that doubles the number of wires. It's cheaper & more reliable to double (or halve, depending on perspective) the cable & transceiver bandwidth requirements (or capabilities) than use more wire & bulkier connectors.
• A long string of nulls (zeroes) will no longer look like a dead or disconnected line. A long sting of ones no longer look like a stuck level.
• The encoded signal has a more balanced energy profile, i.e. the voltage averaged over time should tend toward zero. The logic signal on the circuit board uses 0 volts for logic zero and a positive voltage (5 volts for old TTL, 3.3 volts or less for modern logic) for logic one. Only data logic of all zeros would have a null energy profile; any other data pattern would always have a greater than zero average voltage level and a characteristic magnetic field. But since encodings such as Manchester use both positive and negative voltage levels, the magnetic fields created by the transmitted signal are much smaller as they will tend to cancel each other. This allows wires to be bundled closer together in cables yet create less interference with each other. (Even slow transmission schemes like RS/EIA-232 use both positive and negative voltage levels to balance the energy profile. Probably board-to-board connections less than 0.5 meter and within an enclosure would use only positive voltages.)

Answer 3

To completely know the reason why Manchester Encoding is used, one must be aware of the following:

1. Clock signals
2. Synchronous signals
3. Encoding

After that, the reason is: "what is needed is a way for receivers to unambiguously determine the start, end or middle of the each bit without reference to an external clock

And finally, to do this, Manchester encoding is one of the approaches.

Answer 4

Basically Manchester code is used in preference over many other types, because it is self synchronising.

Synchronisation can be lost with other types when there are a string of zero's or one's where data is not changing. Manchester code does not have this problem due to the fact there will always be a change in signal level, whenever data is present.

The only problem with Manchester code is that you need double the frequency of your data rate, as 8 bits is made into 16 bits of data. So if you require a data rate of 5K you would need a baud rate of 10K.

Addendum I hope the link is allowed but just in case it is not, go to the Maxim site and search Manchester Data Encoding for Radio Communications. http://www.maximintegrated.com/en/app-notes/index.mvp/id/3435 This should help anyone to understand the merits of this encoding.