Design Article
Back to the future: Manchester encoding - Part 1
Robert Guastella
2/4/2008 3:15 PM EST
When commercial options fail, try using Manchester encoding and other time-tested protocols in low-cost, low bit-rate serial communications.
When developing an embedded system that requires basic serial network communications, the list of design options are plentiful. But when all of the off-the-shelf alternatives fail to meet your requirements, it's worth remembering that traditional and well-tested protocols, such as Manchester encoding, offer some unique alternatives to the current commercial methods of wired and wireless control-data transmission.
The off-the-shelf choices are numerous. Many of today's microcontrollers offer such a wide variety of network peripherals that the possibility of not finding the right one for your application seems highly remote. Whether your system architecture requires a peer-to-peer or multi-drop topology, standards such as RS-232 and RS-485, to name a few, have loyally served the embedded development community for a long time. In addition, today's technology has expanded to include CAN bus and Ethernet as possible embedded network solutions.
For applications that are cost-sensitive, have a low data rate, and are physically constrained, some component manufacturers offer a variety of low-cost devices that interface to a simple network scheme. Dallas Semiconductor has taken it one step further and designed a family of components that communicates via a proprietary one-wire network. This novel design provides power and communications all on a single wire. These devices work well for low-cost designs where the power required from the single wire is not significant.
In wireless network applications, numerous solutions based on the use of the ZigBee protocol atop the IEEE 802.15.4 standard for physical layer and medium access control in low-rate wireless personal area networks are available off-the-shelf from companies as diverse as Amber, Freescale, Microchip, and Texas Instruments, among others. In addition, Microchip has an even lower bit-rate solution, combining its more sparse proprietary MiWi protocol atop the 802.15.4 physical layer. Freescale, in addition to its full ZigBee products, offers developers alternatives that use lower bit-rate protocols atop the 802.15.4 physical layer.
When off-the-shelf is not enough
But even with so many options, both wired and wireless, available off the shelf, there are a significant number of networked control designs where cost and physical size continue to place a heavy burden on our designs. In those cases, the usual list of suspects may not be viable after all.
Embedded developers are then challenged to dig deep and find solutions that satisfy their performance requirements, while maintaining a small physical size and a lower product cost, all without sacrificing data integrity.
For those systems requiring more power than is capable from one-wire solutions, standard off-the-shelf components may not be feasible. The solution may require a custom design that strives to balance functional requirements with a number of significant constraints.
When cost constraints are tight and performance requirements less stringent, it might be worth your while to use a "back to the future" strategy and consider the use of a well-known and well-tested serial communications protocols such as Non-Return to Zero (NRZ) or Manchester encoding as a possible solution to your embedded design.




dprogrammer
2/13/2008 6:43 AM EST
Thanks for this wonderful article. However, the title should read as "Part 1". Also it would be better if a link to Part 2 of the article is provided at the end.
Keep good articles like this coming out!
Sign in to Reply
EEH
3/26/2008 2:08 PM EDT
On page 4 of this article you discuss a circuit that from the way that the article is written, led me to believe that it would be able to produce the data bits directly and ignore manchester edges. I was unable to do this in the lab (thus far) using an AMI 51200 RF receiver ASIC. I tried a number of different RC combinations and various feedback / hysteresis R values. I even tried doing AC hysteresis instead of DC (using a cap instead of a res for feedback). I simulated in TINA-TI's freeware SPICE sim as well, with only marginal results.
However, then I found the Maxim-IC article:
http://www.maxim-ic.com/appnotes.cfm/an_pk/3435
which has the same diagram. It appears that the intention of this circuit is not to eliminate the manchester edges but merely to voltage-shift the levels properly for CMOS so you can read it with a uP. The input is low-passed to get you the DC value of the average signal coming in from the RF receiver circuitry, which is used as the comparator reference voltage. This is the standard use of the data slicer. I am not sure where it says in the Maxim article that you are actually removing Manchester edges.
Perhaps you could elaborate. I am probably doing a nonstandard thing since the AMI ASIC puts out a CMOS level manchester encoded signal (which I then have to read in via the MSP430's Timer capture control register bit by bit). Apparently future versions of the AMI chip will be putting out SPI which makes my life slightly easier. I am trying to see if I can skip the capture register by reading in via SPI as bytes and then converting the SPI byte data to actual data as opposed to manchester encoded in FW.
I naively (?) thought perhaps this circuit could eliminate the edges in hardware so I could read in the data directly via SPI. We have an application where space is extremely critical, however, and I am having a hard time getting permission to add even one little tiny IC.
Turns out then I discovered the ASIC puts out a 16 KHz clock signal (for 8 KHz manchester edges) so actually I can read it in directly via SPI anyways, with no hardware conversion.
Sign in to Reply
mixed-signal
4/4/2011 12:22 AM EDT
Figure 6 states something to the effect of 'XOR with a 1 at the bit boundary points.' How do you sample something at a boundary when the signal is changing? Signal samples should be taken during stable data regions. Usually this is done at in the 1st half of the symbol (bit) time, prior to the mid-symbol (bit) transition.
Also, where the "bit boundaries" are shown, where the XOR bubbles are placed, are actually the mid-symbol (mid-bit) transitions, not at the symbol boundaries.
It would be nice to see some clarification on this.
Sign in to Reply