please dont rip this site

Manchester Encoding of Serial Data

Data and clock in one data stream. dict.org definition

A method of transmitting bits which enables the receiver to easily synchronise with the sender.

A simple way of signalling bits might be to transmit a high voltage for some period for a 1-bit and a low voltage for a 0 bit:

           Bits Sent:            1     1     0     0
       
           Signal:    High    ___________
          	      Low                |___________
       
           Time: ->              .     .     .     .     .
       
However, when several identical bits are sent in succession, this provides no information to the receiver about when each bit starts and stops.

Manchester encoding splits each bit period into two, and ensures that there is always a transition between the signal levels in the middle of each bit. This allows the receiver to synchronise with the sender.

In normal Manchester encoding, a 1-bit is transmitted with a high voltage in the first period, and a low voltage in the second, and vice verse for the 0 bit:

           Bits Sent:             1     1     0     0
       
           Signal:    High    __    __       __    __
          	      Low       |__|  |_____|  |__|
       
           Time: ->            .  '  .  '  .  '  .  '  .
       
In Differential Manchester encoding, a 1-bit is indicated by making the first half of the signal equal to the last half of the previous bit's signal and a 0-bit is indicated by making the first half of the signal opposite to the last half of the previous bit's signal. That is, a zero bit is indicated by a transition at the beginning of the bit. Like normal Manchester encoding, there is always a transition in the middle of the transmission of the bit.
                 Differential Manchester Encoding
       
           Bits Sent:            1     1    0     0
       
           Signal:    High  ____       __    __    __
          	      Low       |_____|  |__|  |__|
       
           Time: ->            .  '  .  '  .  '  .  '  .
       
With each bit period half as long, twice as much bandwidth is required when using either of the Manchester encoding schemes.

Dan Michaels says:

...Manchester (or is it Manchester II?) encoding is what Ethernet uses for its on-wire symbology. If you look at the Power Spectral Density of Manchester NRZ, you'll note that it doesn't have any DC component. This is critical for proper operation at the receiver when that receiver is, effectively, AC coupled to your data output. RF Monolithics has an excellent How-To on it at:

http://www.rfm.com/corp/appdata/AN43.pdf

titled "Unique Considerations for Data Radio UARTS". Although their examples are, naturally, aimed at supporting their own equipment, the well written concepts apply nearly universally to OOK RF.

Nikolai Golovchenko says:

When you read Manchester encoded data, use major sampling, that is, three samples per half of bit time:
 ------
      |        - encoded data
      ------
 xyz   xyz    - samples

Then add all samples s=x+y+z. The sum's bit 1 (s1) is the major sample. Major sampling helps avoid an occasional error:

 x   y  z  s s1
 -- -- -- -- ----
 0   0  0  0    0
 0   0  1  1    0
 0   1  0  1    0
 0   1  1  2    1
 1   0  0  1    0
 1   0  1  2    1
 1   1  0  2    1
 1   1  1  3    1

Besides, you can derive timing from these three samples. If last sample (z) is different from previous two (x and y), then the signal edge is somewhere between y and z, which means that there should be less time before the next major sampling. Similarly, if x is different from y and z, then the sampling should be delayed a bit. Hope it helps.

To which Scott Dattalo added:

A good suggestion I might add. However, be careful - even single bit errors with this approach may produce errors in the bit stream: e.g. 111000111000 produces 1,0,1,0; however 111000011000 introduces an ambiguity depending on which bit you begin sampling. You get these streams: 1,0,1,0 ; 1,0,1,0 ; 1,0,0,0,0 depending on whether the sampling begins at the 0'th, 1'st or the 2'nd(actually the sample before the 0'th). I say be careful, because a very simple phase lock loop can re-synchronize your sampling. For example, if you run through this majority filter for every sampled bit then you can discount invalid manchester streams (a manchester stream always has an edge in every bit). If there is a single bit error then the two streams remaining after discounting the invalid one will match.

BTW, if you've got the bandwidth, you might want to sample as fast as possible, but at a constant rate. Phase accumulators may then be used to convert to whatever sampling rate you want (almost).

You're oversampling the incoming stream by some 'large' factor. For example:

       +---------------------+
       |                     |
-------+                     +----------------------
0000000111111111111111111111110000000000000000000000

So instead of one bit representing this pulse there are 20 or so. In the normal, non-oversampling case, you'll somehow determine the edges (e.g. monitoring a start bit) and ideally sample the middle of the pulses. To make this work with the oversampling algorithm you'll need a phase accumulator that's capable of determining when edges have occurred and when it's time to sample. Fortunately for Manchester data streams, the edges occur frequently. In fact, there are two edges for every data bit and the edges are confined to occur at i*bit_time/2 intervals. Note this doesn't say they HAVE to occur at these intervals (if it did, then we'd just have a square wave). Also, for Manchester data we need to produce two samples for every bit. The algorithm shown below doesn't assume that the data stream is a Manchester encoded one. Consequently it could theoretically work for any data stream. However, because it is PLL of sorts, it would require that the data stream be continuous and synchronous.

Algorithm in psuedo-C

  int phase_accumulator;  //
  int delta_phase;        // initialized elsewhere - or
                          // perhaps the pll can dynamically init.

  boolean expected_edge;  // True when we expect the data to change
  do forever {

    expected_edge = ~MSB(phase_accumulator);

    phase_accumulator += delta_phase;

    expected_edge &= MSB(phase_accumulator);

    // if the expected edge bit is set, then
    // this when we expect the data to change
    // (if it is going to change, that is).

    if(phase_accumulator rolled over )
     {
       // We're in the middle of a bit
       latest_sample = current_sample()
     }


    if ((the latest_sample is different
      than the previous sample) AND
      (the expected_edge is false)
     {
       // we found an edge on the incoming data
       // at an inappropriate time. Some we need
       // to re-adjust the phase delta.

       if (the msb of the accumulator is set)
        {
         // The phase accumulator was expecting
         // this edge to come later. This means
         // the phase accumulator is running too
         // fast.
         decrease_delta_phase();
        }
       else
        {
         // The phase accumulator has expecting
         // this edge to come sooner. This means
         // the phase accumulator is running too
         // slow.
         increase_delta_phase();
        }
     }

   }

Here's an example that explains the algorithm:

     X      X      X      X      X      X
        +------+      +-------------+
        |      |      |             |
    ----+      +------+             +----
A   000011111110000000111111111111110000000
B   010000001000000100000010000001000000100
C   100011110001111000111100011110001111000
D   100100110010011001001100100110010011000
ee  000010000001000000100000010000001000000

The square wave is the incoming data stream we wish to sample. The X's above the square wave represent the positions we'd ideally want to sample. These correspond to the middle of the data bits. Row A is the bit stream we get when we over sample. This example shows that we're oversampling by a factor of 8 or so. My intuition tells me that that is about the minimum over sample rate for this algorithm to work properly.

The next three rows, B,C, and D, are the upper bits of the phase accumulator. Row B is the phase accumulator roll over. In other words, every time the phase accumulator rolls over B will be set. This also marks the point at which we wish to sample. I guess you could technically argue that row B is not part of the accumulator since it's not permanently stored. (Somewhat like the Carry bit is not part of an addition that causes an overflow - you could argue either way). It would be easy enough to keep 'roll over' information part of the accumulator. All you'd have to do is decrease the phase delta by 2, but keep in mind this reduces the dynamic range. In my experience, it's been easier to use the rollover. However, if you were wanting to re-transmit a phase-locked wave then it probably be useful to keep the rollover with the phase accumulator.

The next two rows, C and D, are the two MSBs of the phase accumulator. The real phase accumulator will of course have 8,16, or more bits. These two rows illustrate the counting behavior of the accumulator. If you were to draw the square wave associate with each of these rows, you'd find that the frequency doubles for each bit as you go from the MSB to the LSB (up to a point). For example, if you look at row C you'll notice that there's a square that has the same frequency of sampling. On every falling edge, the incoming data stream is sampled. Row D has twice the frequency as row C. However, you'll also notice that row D has a lot of 'jitter' too. If row 'E' would've been drawn, then we'd see even more jitter and notice that some cycles were skipped altogether. This is a manifestation of the phase delta being larger than the half period of these higher frequencies. To contrast, you could call a simple counter a phase accumulator that has a phase delta of 1. If you were to look at the frequencies associated with each bit of a counter you'd see that they're halved as you proceed from the LSB to the MSB.

The last row, ee, is the expected edge and is coincident with the MSB of the phase accumulator going high. This is when the phase accumulator is expecting the data to change states. This is not to say that the data has to change states. It only means that this is where we expect the data to change states. If the incoming data changes states at some place other than when ee is true, then the phase accumulator is not phase locked. Consequently, we need to adjust the phase delta. For example, if the incoming data changed states just before we were expecting it to, then the phase accumulator is running too slow. This means that the phase delta needs to be increased.

The most difficult portion of this algorithm (which I've conveniently left out) is how to adjust the phase delta if we're not phase locked. This digital pll has some of the same behavior problems of its analog cousin. For example, if we adjust the phase delta by very small amounts then we run the risk of taking a long time (to phase lock. This is analogous to having insufficient gain the feed back loop. If the phase delta is changed by large amounts, then we have the opposite problem. It could be difficult to ascertain what an optimum 'gain' should be. There are many factors that affect the design. I'll just list a few: noisy data, insufficient over sampling, insufficient dynamic range in the phase accumulator. Another factor is that the algorithm presented above only adjusts the phase delta when the incoming data changes states. You could also enhance it to continuously adjust the phase delta by comparing the time between expected edges and actual edges. In analog pll parlance, the above algorithm has a differentiator in the feedback loop but no integrator. (The phase accumulator itself is like an integrator, but the way we adjust the phase delta is only by differentiating).

_

PIC Manchester codeing routines

Interested:

Comments:

See also:


file: /Techref/io/manchester.htm, 13KB, , updated: 2011/12/1 13:08, local time: 2014/7/22 08:15,
TOP NEW HELP FIND: 
54.211.50.5:LOG IN

 ©2014 These pages are served without commercial sponsorship. (No popup ads, etc...).Bandwidth abuse increases hosting cost forcing sponsorship or shutdown. This server aggressively defends against automated copying for any reason including offline viewing, duplication, etc... Please respect this requirement and DO NOT RIP THIS SITE. Questions?
Please DO link to this page! Digg it! / MAKE! / 

<A HREF="http://www.piclist.com/Techref/io/manchester.htm"> Manchester encoding</A>

After you find an appropriate page, you are invited to your to this massmind site! (posts will be visible only to you before review) Just type in the box and press the Post button. (HTML welcomed, but not the <A tag: Instead, use the link box to link to another page. A tutorial is available Members can login to post directly, become page editors, and be credited for their posts.


Link? Put it here: 
if you want a response, please enter your email address: 
Attn spammers: All posts are reviewed before being made visible to anyone other than the poster.
Did you find what you needed?

  PICList 2014 contributors:
o List host: MIT, Site host massmind.org, Top posters @20140722 RussellMc, Richard R. Pope, IVP, alan.b.pearce, John Gardner, Isaac Marino Bavaresco, Bob Blick, James Cameron, Josh Koffman, cdb,
* Page Editors: James Newton, David Cary, and YOU!
* Roman Black of Black Robotics donates from sales of Linistep stepper controller kits.
* Ashley Roll of Digital Nemesis donates from sales of RCL-1 RS232 to TTL converters.
* Monthly Subscribers: Gregg Rew. on-going support is MOST appreciated!
* Contributors: Richard Seriani, Sr.
 

Welcome to www.piclist.com!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  .