PSoC4 Manchester Encoder and Decoder Sample Project

[Vison_Zhang]

Manchester Encoded Data

There are two Manchester encoding standard, depending on the data available in the first and second halves of bit time. Manchester encoded signal as per G.E. Thomas, a ‘0’ is transmitted by low-to-high transition and a ‘1’ is expressed by high-to-low transition. This is represented in Figure 1: Manchester Ecoded Data (As per G.E. Thomas). Manchester encoded signal as per IEEE 802.3 is the opposite of G.E. Thomas, where a ‘0’ is transmitted by high-to-low transition. In this document, G.E. Thomas standard has been used (Figure 2: An example of Manchester encoding (Source: https://en.wikipedia.org/wiki/Manchester_code).

Figure 1: Manchester Ecoded Data (As per G.E. Thomas)

Figure 2: An example of Manchester encoding (Source: https://en.wikipedia.org/wiki/Manchester_code)

Manchester Encoder Implementation

  For Manchester Encoder, user needs to synchronize the clock edges and data input edges. SPI master provides the slave synchronization clock input to the device. Once you perform XOR of MOSI and SCLK outputs from SPI master, you can easily implement a Manchester Encoder as per G.E. Thomas standard.

Manchester Decoder Implementation

If a delay of three-fourths bit time is triggered by the incoming mid-bit transition, the value captured at the end of the delay tells the next bit value (Figure 5: Manchester Decoder Outputs). 

Figure 5: Manchester Decoder Outputs (Source AN2358)

By using PWM and SmartIO we can easily captures input encoded data after ¾ bit time from the mid-bit transition and realize Manchester Decode.

Attached projects:

Encoder_PSoC4200M_AddSync_1K/ Encoder_PSoC4200M_AddSync_1K can generate 1K/4M data rate output. You can adjust the actual data rate of SPIM component for customize data rate.

SmartIO_Based_ManchesterDecoder_1K/ SmartIO_Based_ ManchesterDecoder_4M, can decode 1K/4M data rate Manchester data stream. You can adjust the NCO_Clk frequency and Compare value of NCO(PWM) component for customize data rate.

[Len_CONSULTRON]

XiaoweiZ,

Thank you for your contributions.  I've had to create Manchester encoding before and used a different technique.  Yours look very promising.

One note of caution though.  You have the two D FF outputs going through a XOR gate which outputs through a pin named "Encoded_out".

At a minimum the output "Encoded_out" should be a sync'd output.  This is to minimize a potential glitch due to the possibility of a "race condition" between the 'q' outputs of the D FFs.  A 'glitch' in most Manchester systems is usually not a problem since most systems will ignore a glitch if it occurs too soon after the first edge.  My suggestion is to minimize a false trigger in case the Manchester decoder at the other end is too time sensitive.  Besides it is a very 'cheap' (no additional resources needed) suggestion.

I'll check out your Manchester decoder scheme.  I've had to create a Manchester decoder before.  IT IS NOT EASY!   There are many issues to conquer to recover the encoded bits properly.

Issue 1:  Which edge to start the 3/4 sample?

Each data 'bit' is encoded into 2 'chips' The 2 chips are always the opposite of each other (that's what makes Manchester considered 'self-clocking').  In the Manchester type you are using,  the data is in the second of the two chips.  In order to sample at 3/4 of the Manchester bit width (1 and 1/2 chips), you need to know when the first chip starts otherwise you will be out-of-phase with the data.

Due to Manchester chips, you get either 1 or 2 bit transitions in 1 bit width.  In the case where the bit pattern is 110011 your chip pattern is 010110100101.  You'll notice that there are two 1s together and two 0s together.  In these cases there is only one edge transition across 2 chips.

In most system implementations I've seen to 'guarantee' a Manchester clock phase sync, the first Manchester data is at least 1 byte of 0s.  This is to prime the pump of the clock phase sync with two edge transitions per Manchester bit (2 chips).  This establishes the 'chip' clock.

Issue 2: Is the incoming message intended for this Receiver?

Many times the system Manchester protocol also uses a Manchester code violation before starting the data.   The code violation will purposely prevent one or more edge transitions required by bit encoding.  With a standard Manchester encode, you will always have either edge before and/or after and in the middle of the bit.  With a code violation you will have either 3 or more 0 chips or 3 or more 1 chips in a row.

The code violation is to try to make sure that the violation pattern matches the system between the Sender and the Receiver.  This is a method to try to make sure that if the Manchester encoded data being received is from the intended Sender.   I work in automotive where certain systems use Manchester as a encode/decode mechanism for wireless comm.  The goal for the Receiver is to determine if there is a high probability that the incoming message is intended for the Receiver.  If not, the Receiver with restart the Manchester decoding state machine and wait for a correct message.

Issue 3: Chip Clock Resyncing

Manchester is a self-clocking serial protocol.  This means the design could create there own version of a Digital PLL to recover the chip clock.  The DPLL could readjust on the fly the chip clock to allow for some Sender (and transmission medium) variance.  This would allow for long Manchester encoded messages to received with lower chances of the chip clock losing sync as the message progresses.  A DPLL is possible but not trival.

Most commonly, the Sender and Receiver chip clock rates are specified.  If both sides have clock generation circuits that can create the chip clocks with low variance to the agreed frequency, then a medium sized message can be received faithfully.  However, any discrepancies between the Sender's chip clock and the Receiver's chip clock will eventually accumulate a clock phase error as the message gets longer.

To avoid this most designs will add a simpler version of the above mentioned DPLL.  This is commonly implemented by over-sampling the chip clock frequency (usually 8x or higher) and detecting if the received chip edges are in-phase to the Receiver's chip clock or out-of-phase. If out-of-phase, by a certain amount, the Receiver's chip clock logic adjusts its sample point (the 3/4 method for example) or resyncs the counter to the 'new' chip edge and then the 3/4 sample point is better centered in the data.

Sorry for getting long-winded.  I used this discussion topic to help others with what I've learned over the years of design.  XiaoweiZ I wish you and other well in this endeavor.

Len