Manchester encoding

As I understand, in Manchester coding known bits are sent before start a transferring.

But I didn't understand why - One of the main benefits of Manchester, is the fact that sync between the two side is easier. So why I need to send bits before the transfer?

• @mazurnification: I delete the linking. It is Manchester protocol – Adan Sh Apr 24 '12 at 9:30
• I would say that "Manchester protocol" is bad alias for the same thing as "Manchester code". Wikipedia redirects you from the protocol to the code. – Telaclavo Apr 24 '12 at 9:39
• Adan Sh: revered to put the link back; what @Telaclvo said is correct. – Brian Carlton Apr 24 '12 at 18:33

There are two main reasons for using a preamble to start a packet of manchester encoded data:

1. Let the data slicer settle. Manchester is often used over radio links and physical links where there is no direct connection and the difference between a high and low level not explicitly known up front. This usually means a anlog signal is presented to a data slicer, which detects and passes on the sequence of digital highs and lows.

One property of manchester encoding which makes it useful for such links is that it averages to 1/2 high and 1/2 low over short intervals. Each bit has the same average level of 1/2. This makes data slicing relatively easy because it can be a simple comparator against the 1/2 level. However, that means you have to know what the 1/2 level is. Old receivers would do this in hardware by low pass filtering the manchester stream. Such filters deliberately don't react much over a single bit time, so take a few bits to settle. The preamble contains throw away bits that the receiver is not intended to properly detect while its data slicer is finding the 1/2 level.

2. Indicate start of packet. Since most manchester receivers essentially have automatic gain control via the 1/2 level used for data slicing as described above, the receiver will interpret background noise as a series of high and low levels just like the real signal. There is generally no such thing as no signal to the digital stream interpretation part of the receiver, only that the stream makes sense when there is real signal.

Manchester contains some redundant information so that some sequences of levels can be detected as invalid directly without higher level interpretation. For example, there needs to be a transistion in the center of every bit. Three half-bits of the same level is illegal, so is two-one-two, for example.

While resetting to start of packet whenever a violation like above is detected helps, there is still enough chance of random junk making it further into a packet that this needs to be dealt with in most cases. You don't want the higher levels deep in the packet decoding logic from noise when a real packet comes along that then just looks like more data for the bogus packet. Eventually the bogus packet will presumably fail the packet checksum test, but you still loose the real packet.

A good strategy is then to make the preamble a unique sequence that is not valid in the rest of the the packet. When this sequence is detected, the higher level packet interpretation logic is reset to start of packet regardless of what it thought it was doing at the time.

I usually do this by using a stuff bit scheme. If the real data contains 7 0s in a row, for example, then the transmitter must add a 1 stuff bit after the 0s. The receiver knows this and strips out the 1 bit following 7 consecutive 0 bits. This means that there are never 8 consecutive 0 bits, which would be a bit stuffing violation. If a bit stuffing violation is detected, then the packet interpretation logic can be safely reset to start of packet since it definitely wasn't in a valid packet at the time. The preamble deliberately contains such a stuff bit violation to force the interpretation logic to be reset to start of packet.

This stuff bit scheme and resetting to start of packet is not standard manchester, but something I like to use to make manchester more reliable over links like radio.

There is more to manchester encoding when you really think about the details. You can do a much faster responding data slicer in a digital processor, for example, in which cases you can use other means than bit stuffing to reliably detect start of packet, but that is a whole topic onto itself.

• Two alternatives to bit-stuffing which are used in certain scenarios: (1) include a parity bit every few bits. This approach is used on magnetic-stripe cards, there the maximum number of consecutive zeroes in a 5-bit data stream is 8 (10000 00001); (2) use BCD data. This approach is used with SMPTE time code data, though BCD nybbles alternate with non-BCD, so the maximum number of consecutive "1"'s is 8 (0111 1111 1001 if it's big-endian). I'm curious whether "1101100100" would be a good preamble pattern, since it would be unique even without bit-stuffing. – supercat Apr 24 '12 at 16:01
• @supercat: Yes, there are lots of schemes. For example, a preamble of long-short-long-short, etc, works without bit stuffing since it is a violation of manchester on its own. It's doesn't average to 1/2, but that's fine if your data slicer does something other than compare against the recent average. It would work fine with my digital data slicing implementations, for example, since those use non-linear filters to derive the slicing level. – Olin Lathrop Apr 24 '12 at 16:53
• I think it's important for a preamble to include a high and low of the same length; otherwise if the transmission channel is at all "analog", the long times may read shorter than they really are and the short times longer. It's possible to decode balanced Manchester data by only measuring rising-edge to rising-edge times and falling-edge to falling-edge times, without having to measure rising-edge to falling-edge or vice versa, but a preamble of 100 or 110 would just read as a uniform sequence of rising edges and a uniform sequence of falling edges. – supercat Apr 24 '12 at 17:41
• @supercat: What you are really saying is that typical analog data slicers require the data stream to have a average value of 1/2. That is true, but as I said, there are other types that don't have this requirement. I haven't done a analog data slicer in years. All my digital ones would be fine with something like a long-short-long-short sequence. They also settle faster, usualy in a little over one bit time. – Olin Lathrop Apr 24 '12 at 21:36
• A lot depends on the medium through which the data is passing. If the behavior on rising and falling edges can be assumed symmetrical, or if the data rate is known, then high-low-low might be a perfectly fine preamble. If such assumptions do not hold, high-low-low might look like a sequence of longs or shorts where the low pulse is "stretched" relative to the high pulse. – supercat Apr 24 '12 at 22:36

One of the main benefits of Manchester, is the fact that sync between the two side is easier.

The type of sync that Manchester encoding makes easier is the synchronization at the bit level, not at the word or packet level. In fact, it doesn't help at all with the latter one. And that is why you still may need to transfer some known bits, before your data bits.

It does help with the former one (the bit-level sync), because it eases clock recovery.

So why I need to send bits before the transfer?

• Thank for you answer. So as I understood from you, I need to send bits before a word or packet to mark that I start transfer word/packet (in other word, two sides are decided about agreed sign, which symbol the start of packet/word). This is done in the netword acsses layer? – Adan Sh Apr 24 '12 at 9:28
• @AdanSh Yes, you need to send bits because of that, and I would say that it is done in the Data link layer. See this en.wikipedia.org/wiki/Frame_(networking) – Telaclavo Apr 24 '12 at 9:36

Manchester is a coding method, not a protocol, which describes a lot more about the communication. Ethernet is a protocol, which uses Manchester coding.

Manchester coding works at bit level, it only sees one single bit, it doesn't care about preceding or successive bits. It doesn't care whether it's the first or the fifth bit, and as such it can't dictate to send extra bits before the start of a transfer.

What you probably mean is that the protocol will start the transfer of a packet/word with a known sequence (also Manchester coded, so this becomes the first bit).

Consider the following sequence of four negative going pulses:

$\mbox{1 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1}$

There's no way to know whether this is 0x0000 or 0x1111, and Manchester doesn't care. You'll have to define extra bits to your data to be able to decode it. For instance if your protocol says every message starts with a 1-bit preamble it has to be 0x1111. Preambles of several bits make synchronization easier, but also decrease the channel's efficiency.
BTW, such sequences, only 1s or 0s, are the only ones which can't be decoded. Any sequence which has at least 1 1 and 1 0 can be decoded. Bit stuffing can help avoiding all 1s or all 0s patterns.
Even then a preamble remains useful because the decoder will be able to output bits as they're received. Without a preamble data like 0x0000001 can only be decoded when the 1 bit is received.

Nevertheless, the preamble is not a Manchester coding requirement!

Manchester coding results in a biphase signal: either half a bit time low, followed by half a bit time high (that's for instance for a logical 1), or half a bit time high followed by half a bit time low (logical 0). It doesn't require any extra bits.

It is possible that the next higher protocol level requires a preamble before the actual payload is transferred, but that's not defined by Manchester. Manchester only deals with the coding of individual bits, it doesn't know concepts like messages or packets.

• Are you sure? I read the next sentence in a book that deal with this issue:"bits that are known by two sides, are send before an information's transfer is started". I translate it to english, but I hope you understand the meaning. – Adan Sh Apr 24 '12 at 8:51
• @AdanSh: positive! Manchester only concerns the coding I described. Extra bits must be part of a higher level protocol. By the way, how are these extra bits encoded? – Federico Russo Apr 24 '12 at 8:56
• The book doesn't mention how, It just state this information. – Adan Sh Apr 24 '12 at 9:03

The usual reason is to give the receiver clock time to synchronise/lock before actual data arrives. Typically a run of consecutive ones or zeros is used.

With MIL-STD 1553 (an avionics bus protocol) a logic one (or zero) lasting 1.5 bit periods is sent followed by a logic zero (or one) lasting 1.5 bits. This is actually a violation of the Manchester code but is easily detectable by the receiver.

In low frequency RFID tags using the EM 4100 protocol, a data frame starts with a header of 9 Manchester ones. Synchronisation is not the issue here since the receiver already has a clock (because it is radiating it to the transmitting tag). However, the data can become inverted so the receiver needs to determine polarity. Since 9 consecutive bits of the same polarity can never occur in the actual data (due to parity bits), the header can be unambiguously detected as a run of ones.

Name at least 3 methods of Manchester Code or Bi-Phase, a) Mark, Space, Transition

Name at least 3 sync levels in communication;

a) bit sync, b) word sync (~byte) c) frame sync

What is optimal for frame sync?

Cross-Correlation code where code words have high uniqueness when in sync vs out of sync. i.e. Pattern detection scheme that is also least likely to be data too.

This is essential when converting serial bits to parallel words and frame sync. This is what I knew 35 yrs ago when I first implemented a SCADA system in mid-70's. It may have changed now. Clock sync can be as simple as an XOR with a 1 shot delay on transitions to create a non-retriggerable clock, or better a PLL with transitions sampling an ultra stable VCXO using a Sawtooth clock signal and data edges to sample the phase error Voltage.. Of course your Bandpass filter and medium will introduce jitter, so you must learn to use Raised Cosine Filters where bit shift is zero. The bit error rate or BER is a function of the asymmetry of your clock slicer, jitter & phase error in your clock and jitter in your data. BER is directlly predictable from SNR and Phase margin tests help isolate the cause of your BER issues by using reduced and shifted timing windows to force your clock off center and see if data is still valid.

This is the secret method to analyzing any marginal communication system. I applied to my SCADA comm, Telemtry to aerospace, HDD data recovery and Telecom T1 days.

( if you want details on sawtooth VCO with Sample & Hold phase error from data transitions.. just ask :p) more than 30 yrs ago I designed but I think I can still do it.

Of course that was a synchronous comm channel.. You can use it for ASYNC comm too. and perhaps is what you intended with the preamble bits. . I used +/- peak and hold detectors for the slicer tracking filter.

If none of these answers work for you, maybe try another question....

• Huh? Little of this seemingly aimless babble makes much sense. – Olin Lathrop Apr 26 '12 at 12:40
• Seems like you know nothing about Manchester code. I have designed many successfully since 1976. Biphase requires a preample to enable phase of clock sync. Since there are at 3 phase protocols, Mark, Space and Inverse defined by IEEE, you cannot guess this is known. Then clock extraction is easy. It always occurs to me that those who know nothing cannot make sense of reason and logic and make such comments as your.. Pls retract. BTW since this is used for asynch. mode. pre-amble is essential to maintain synch operation after words. such as frame synch, byte sync etc used in T1 repeaters & Biø – Sunnyskyguy EE75 Jul 20 '12 at 15:39
• whenever you establish synchronous or asynchronous communication with a single channel ( clock embedded in encoded data ) then data recovery requires a established pre-amble.. Manchester code or BIPHASE or modems all need a pre-amble, but unlike UARTS which is center sampled Nx clocks on leading edge of start bit. – Sunnyskyguy EE75 Jul 20 '12 at 15:44