I forgot to mention an important part of Manchester coding in
my last message.

The encoding of the data is very simple, but the decoding is not
as easy.  The problem arises because you are NOT guaranteed a
signal transition at the main clock frequency (FSK does guarantee
this transition, and so it is easier to code).

The rest of this discussion is about decoding Manchester data.

Sometimes it takes a half of one clock to get a transition, and
other times it takes 1, or even 1 and a half clocks before you get a
signal transition.  This makes it difficult to recover the clock
that you need to decode the data.

There are 4 ways to get the real clock back:

  1) Analog Phase-Locked Loop (PLL)
  2) Digital PLL
  3) one-shot multivibrator-based circuit (Don Tarbell)
  4) a digital algorithm to simulate the one-shot circuit

Number 1 above is very good, and provides for quicker re-sync
after you lose a bit.  This is easier to understand if you look
at a Manchester signal on a spectrum analyzer - you will see 3
discrete "carrier" frequencies.  If your main frequency (which is
half the data rate) is 1200 hz, then the other 2 freq's are 600hz
and 400hz.  Your PLL can simply lock onto the 1200 hz signal.
Take the output of that and feed it into a zero-crossing detector,
and then your get your data clock: 2400 hz.

Number 2 above is just a digital algorithm that does the same
thing as the Analog PLL circuit. This method is used by Ethernet
chips.  People who can code a PIC to do this definitely have
my respect!

Number 3 above is what made such a big splash with the Tarbell
Cassette interface - Don made a very simple "one-shot" circuit
hooked up to a couple Flip Flops to detect the location where
the missing clock pulses would be.  It was so awesome that Byte
magazine published the circuit and an explanation.  James
Electronics (now Jameco) had a big run on the Signetics 8T20 chip
(which mysteriously went up in price around that time), which was
the one-shot with built-in flip-flops.  Every electronics
hacker wanted to build one of those circuits!

Number 4 is a no-brainer now that every circuit has some kind
of micro-controller built-in.  You just set up a rather complex
set of nested timing loops.  The hardest part is to re-sync after
losing one or more bits.  With a special digital bit pattern, that
I can't remember right now :-( , it is possible to guarantee
re-sync within a certain number of clocks.

The part of this decoding circuit that you need to do in external
components is the front-end amp/limiter and zero-crossing
detector (ZCD).  This ZCD is NOT the same as the one mentioned
in Number 1.  This Zero-Crossing Detector puts out a short digital
pulse on every transition of the input signal through
the 0v level (assuming plus and minus swings).  That digital
pulse is the only input to the PIC.  Along with that pulse,
you will use the internal PIC timer heavily.

End of discussion on Manchester coding.

------

Other clarifications:

Group Code Recording (GCR) can be used 2 ways: to improve timing
margins OR to improve throughput within a given bandwidth.

One method of GCR (published in one of the IEEE journals circa
1980-1981) gives you a change in the frequency spectrum of the
encoded signal, such that it improves your timing margins over
Manchester. Instead of 1200, 600, and 400 hz, it gives you 1200,
600, and 300 hz. That is a whole octave between "carrier"
frequencies - a much improved story for timing margins.  This
type of GCR has the same approximate throughput as the Manchester
code, but is more reliable if your transport medium may introduce
slight timing variations (like WOW and flutter of a tape drive).

Most GCR methods are used to improve data throughput, since timing
margins are not such a big deal with hard disk drives and Microwave
radio links.

I won't give an example of GCR encoding because it is a difficult
subject to explain.  I'll just say that it's based on keeping the
ability to recover the clock, while also reducing the number of
signal transitions.  Manchester guarantees a signal transition at
least once every 1.5 periods of your main frequency. GCR normally
expands that time lag between transitions - often to 2 or 3 periods.
Extended periods mean you can raise the data rate while keeping the
same general bandwidth.

The data itself can not be directly coded - instead you need a
lookup table and a translation of "m encoded bits" for "n data bits",
where m is always greater than n.  This extra baggage comes in bec.
of the need to keep the clock syncronized - but the data throughput
goes up anyway.

Of course, GCR is much harder to encode and decode than Manchester,
and should not be used in typical "casual" circuits because of
it's complexity.  Also, recovering from errors (dropped bits) is
almost impossible.  On a hard disk, you'll likely lose the entire
track's worth of data if you lose just one bit on the track.

----

I think the "feed-forward" error codes I referred to are actually
called "FEC" - Forward Error Correction codes.  There are several
types of these used now, but the idea is the same: make you carry
extra bytes with each data packet that can be used (if needed) to
automatically correct errors at the distant end.  Think of them as
being an extension of the "parity" concept.


Eric Engler, KC8YB