> Excuse me?  I thought one major reason that Manchester encoding was
> (is?) popular is that it is self clocking, that is, it is easy to
> decode since the clock and the data are "combined".  Manchester is RZ
> (return to zero) encoding, unlike the familiar serial protocol, which
> is NRZ (non-return to zero), which means that decoding manchester
> needs none of the "framing" overhead of the serial protocol, such as
> start and stop bits.  Neither does it require particularly accurate
> decoder timing, it can tolerate fairly gross timing discrepancies from
> "nominal", which would render RS232 useless since an FF byte or a 00
> byte has no transitions at all, and rely on matched XTAL timing to
> determine the bit boundaries.

Manchester coding uses two lengths of pulse: long and short.  Within valid
data, short pulses always occur in pairs.  Consequently, it is fairly easy
to design a manchester decoder which can adapt relatively quickly to changes
in data rate, and the "paired short pulse" requirement adds a little bit of
error detection.  Linear time code readers for videotape can often read data
written at 2400bps nominal when the tape is moved anywhere from 1/10 to 10x
normal speed (they can also go both forward and backward--kinda neat!)

In some other long/short coding schemes, the lengths of long/short pulses
differ in a non-2:1 ratio.  I2of5 barcodes code each decimal digit as
either 2 wide and 3 narrow bars, or 2 wide and 3 narrow spaces; the wide
parts are 2.5x as wide as the narrow.    Schemes like Manchester coding
are easier to encode in hardware than those which use variable or fractional
width pulses, but decoding of corruptible signals may be more reliable
with variable-width techniques.