Manchester encoding

Question

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?

Answer 1

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.

Answer 2

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?

So that they will help you to sync at the word/packet level. Manchester encoding doesn't help you at that level.

Answer 3

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!

Answer 4

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.

Answer 5

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.

Answer 6

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....