Searching \ for 'Manchester Data Encoding' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/mems.htm?key=data
Search entire site for: 'Manchester Data Encoding'.

Truncated match.
PICList Thread
'Manchester Data Encoding'
1998\01\09@012440 by Eric W. Engler

flavicon
face
>Greetings:
>
>Does anyone have any info on manchester encoding and decoding.  I have Andy
>Warren's "psudo code" from his FFE site, and I found a link that appears
to be
>"dead" at: http://hobbes.king.ac.uk/matt/pic/manchest.html.
>
>I want to manchester encode a data stream using 16C84's for a radio link and
>any *more* help or pointers would be greatly appreciated.  I was obviously
>hoping someone has some code they could share <g>.
>

I don't have any PIC code for you, but you sure brought back some memories for
me!  That gray matter is very wierd stuff!

Manchester Coding
               There is a transition at the middle of each bit period
               The transition serves a clocking mechanism and also as data
               A low to high represents a 1
               A high to low transition represents a 0
               Widely used in LANs, and open-reel data tape drives

A simple diagram of how a byte is encoded:
 www.optimized.com/tech_cmp/manchest.html
see also:
 www.erg.abdn.ac.uk/users/gorry/eg3561/phy-pages/man.html
and this one:
 http://knuth.sirti.org/~clark/cs333/Exam1_s97_key.html  (and Exam2)

The last referance above is VERY good for people who want to know
more about physical data encoding!

The objective is to mark all changes in bit values, not the actual values
of the bits.  But, they put a spin on it to avoid a contant tone in the event
of a string of 1's or 0's.  This much is called NRZ, "non-return-to-zero"
coding.  To save on the number of cycles, they use a half-cycle of the
main tone as their standard period - this is where their brains came in!

The reason it's used is to allow you to transmit twice as much data as FSK
for a given bandwidth. If you use 1200 hz as your main frequency, you can
actually send data at 2400 baud. But, your bandwidth will exceed 1200 hz
in the real world (the math gets heavy).

It's became popular for use with data tape drives, since it is somewhat
tolerant
of WOW and flutter induced timing skews.  The first use that I saw of
Manchester
coding was in the "Don Tarbell" cassette interface for S-100 computers, circa
1979 or 1980.  Of course, it was used earlier in mainframe tape drives.

Both Ethernet and Token Ring networks also use Manchester - again, because of
concern about timing skews.  Another concern is that they don't have enough
time to decode more advanced encoded signals.  Manchester gives you twice
as much data as FSK, along with the same timing tolerance as FSK.

To get mode data into the same bandwidth, you can opt for GCR - Group
code recording.  Most disk drives use GCR, because disk drives don't have
the same WOW and Flutter problems as tapes.  Many hackers like myself who
wanted to read "protected" floppy disks on the Apple 2 had to learn about
GCR encoding.  They called it "nybble encoding", and the good copy programs
like LockSmith were called "nybble copy" programs.  The book "Beneath
Apple DOS" explained the coding in detail.

To really pack data, you can use quadrature encoding, as in 9600 baud
modems (I think 2400 baud modems use Manchester?).  A quarter of a sine wave
is used to hold 2 bits of data, I believe. Once you go above 9600,
the math gets way over my head!

For work over radio waves, the newest coding methods include "feed-forward"
error-correcting codes (similar to hamming codes).  These extra bits allow
for error-correction at the other end without the need to retransmit the
data.  You pay about 20% extra in overhead, but it can be worth it because
you save the "turn-around" latency that modern transceivers have.

On the HF bands, CLOVER is the best protocol going!  It's totally remarkable -
it can dig down below the noise level to read the data. I think they even
have a Clover+ out now.

On VHF and higher, you don't need sophisticated coding methods because there's
much less interferance.  Simple FSK is the easiest if you can tolerate low
speed, or if you have lots of bandwidth.

For highest speed and lowest bandwidth, use real modem chips, as is done
with ham radio "packet" protocols.  Modem chips are usually far better than
anything us hardware hackers can do, short of DSP (Clover uses advanced DSP
methods).  But, the newest modem chips all use DSP now, too!

Eric Engler, KC8YB

1998\01\09@032016 by Eric W. Engler

flavicon
face
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

1998\01\09@113206 by Mike Keitz

picon face
On Fri, 9 Jan 1998 01:15:30 -0700 "Eric W. Engler" <spam_OUTenglereTakeThisOuTspamSWCP.COM>
writes:
>
>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.

This is not Manchester data then.  In your earlier post, you said
correctly that "manchester data has a transition in the center of each
bit".  There is either 1/2 or one full bit time between transitions.
However, special sequences which violate the protocol (missing a required
transition) are often used for sync marker bits.  The decoder would need
extra logic to detect these.

It is easier for me to think of the guaranteed transition being at the
start of each bit, with an optional transition in the center if needed to
set up for the next bit.  The simplest possible decoder detects a
transition and waits 3/4 of a bit time, ignoring any other transition
during this time.  Once the decoder gets in sync by receiving a signal
with a full bit time between transitions (which occurs when the sequence
01 or 10 is transmitted), the transition detector will be certain to fire
only at the start of each bit.  The data line can then be sampled at a
known point in the bits and correct data decoded.  This decoder doesn't
work really well in the presence of noise.  For recording on disks or
tapes or sending over cable, noise is not usually a major problem.  The
entire block must be re-sent if noise destroys even one bit, so the
decoder's ability to re-sync in the middle of the block is not useful.

The FM (single-density disk) format is very similar, having one
transition per bit for one value of data and two transitions per bit for
the other value of data.  The same 3/4 bit time timer can be used, but it
is necessary to take 2 samples during each bit to determine if a
transition occurred in the center.  The advantage of this format is that
it is not sensitive to inverting the polarity of the signal during
recording or transmission.  Of course placing a NRZI encoder/decoder
around a Manchester system has the same effect.

It was realized that a lot of the transitions in FM are not necessary to
convey data, so MFM was developed.  If a 1 data bit was defined as having
2 transitions, the transition at the start of a 1 is deleted.  So a 0 has
a transition at the start, and a 1 has a transition in the middle.
Additionally, if a 0 follows a 1, it has no transition at all.  This
guarantees a full bit time minimum betweeen transitions, with a
possibility of 1, 1.5 or 2 bit times before the next transition.  The
minimum and maximum transition intervals are now twice as long, so the
same hardware can record data twice as fast.  Thus it is called "double
density".  "High density" disks use the same MFM format, but with better
heads and disk materials that can handle twice again the data rate.

Simple one-shot decoders do not work for MFM because there is not a
guaranteed transition at the start of each bit.  In fact, a long string
of ones looks exactly like a long string of zeros: a transition each bit
time.  But the phase of the transitions is different.  The decoder
typically uses a PLL operating at twice the bit rate, and logic to
remember the last bit state and the time since the last transition.

Observe that the MFM standard breaks the data to the disk into basic time
units of 1/2 the bit time.  Each basic time unit may contain a single
transition, however the basic time unit which follows one containing a
transition is guaranteed to not contain one.  Using shorter basic time
units, but longer guarantees of nonrepeated transitions allows more data
to be recorded on the disk, by more precisely controlling the phase of
the data signal.
This is the basis of RLL encoding.  It uses a basic time unit of 1/3 bit
time, with a guarantee of at least 2 but not more than 7 basic time units
with no transition after each transition.  Conforming to these rules, it
is possible to store 8 bits every 16 basic time units.  To record on the
same hardware that previously used MFM, every 3 basic time units is
equivalent to 1 MFM bit.  Thus the overall bit rate is 1.5 times that
possible from MFM.  This format is used on nearly all modern hard disks
as well as CD-ROMs  (On CD, 17 basic time units store 8 bits.  The extra
time is supposedly used to "reduce DC content").

1998\01\09@120757 by Martin R. Green

flavicon
face
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.

I remember some Manchester backup hardware for the ancient Sinclair
(or Timex) ZX-81 which used 3 or 4 simple logic IC's to recover the
data from a plain old audio cassette recorder (and 3 or for more to
encode the data in the first place).

Seems to me this should be easy to implement in a PIC.

CIAO - Martin.

On Fri, 9 Jan 1998 01:15:30 -0700, "Eric W. Engler" <.....englereKILLspamspam@spam@SWCP.COM>
wrote:

{Quote hidden}

Martin R. Green
elimarspamKILLspamNOSPAMbigfoot.com

To reply, remove the NOSPAM from the return address.
Stamp out SPAM everywhere!!!

1998\01\09@125709 by Pedro Drummond

flavicon
face
One doubt:

Still referring to my tones via phone lines problem, will I get any benefit
by using Manchester encoding in my transmission ?

I understand the advantages of a synchronous approach when you are recording
the data on a cassette, but how about phone line transmission ?


Pedro.


>I remember some Manchester backup hardware for the ancient Sinclair
>(or Timex) ZX-81 which used 3 or 4 simple logic IC's to recover the
>data from a plain old audio cassette recorder (and 3 or for more to
>encode the data in the first place).

1998\01\09@144215 by John Payson

picon face
> 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.

1998\01\09@160250 by Martin R. Green

flavicon
face
Ok, I think we are getting confused here.  Manchester encoding is not
based on pulse width, but on the direction of the level transition in
the middle of each bit.  There are synchronous schemes that do depend
on pulse width, and which are also fairly immune to speed mismatches
between encoder and decoder, but they are not Manchester.

I also remember another type of Manchester encoding (a quick search of
the web reveals this is called "differential Manchester") in which one
logic level is represented by a level change at the beginning of a bit
boundary followed by an opposite level change in either direction at
the middle of the bit, and the other logic level is coded a NO level
change at the beginning of the bit, but again, a change in either
direction in the middle of the bit.  Effectively, the only real
difference between regular and differential Manchester is the location
of the "intelligence" in the bit stream.  With one it is at the start
of the bit boundary, with the other it is in the middle.

CIAO - Martin.


On Fri, 9 Jan 1998 13:31:13 -0600, John Payson <.....supercatKILLspamspam.....MCS.NET>
wrote:

{Quote hidden}

Martin R. Green
EraseMEelimarspam_OUTspamTakeThisOuTNOSPAMbigfoot.com

To reply, remove the NOSPAM from the return address.
Stamp out SPAM everywhere!!!

1998\01\09@162518 by John Payson

picon face
> Ok, I think we are getting confused here.  Manchester encoding is not
> based on pulse width, but on the direction of the level transition in
> the middle of each bit.  There are synchronous schemes that do depend
> on pulse width, and which are also fairly immune to speed mismatches
> between encoder and decoder, but they are not Manchester.

Okay, I think we're dealing with essentially isomorphic codings here; the
two versions may be transposed by xor'ing each bit (on the "unencoded"
side) with the previous.  I've seen both forms referred to as "manchester"
coding.  Also, for the terminology, one scheme is described as always
having a transition at the START of each bit, and MAYBE one in the middle,
while the other MAYBE has one at the start and ALWAYS has one in the middle.
I personally find it easier to use the former interpretation since it uses
an actual event to locate the start of a bit (instead of having to wait
for the transition in the middle to determine when the start of the bit
actually occured).

If people use PLL's to sync on "the middle" of bits, all the more power
to them; even with Manchester coding as you describe it, though, I'd think
it easier and more reliable to read things as long and short pulses, and
then try to interpret the long/short pulse strings.

1998\01\09@165441 by Martin R. Green

flavicon
face
It occurs to me this would make a good "joint" programming  challenge
for the wizards on this list.  Code a Manchester decoder (preferably
without interrupts) in as few instructions as possible.  Ideally, the
clock speed of the bit stream should be irrelevant so another device
talking to the decoder would not have to worry about stringent timing
requirements.

This would be a usefull addition to most peoples "toolbox", a 1 pin
solution for sending data to a PIC, with the timing insensitivity of
I2C, but again, with only one pin.  Of course, it would not be a "BUS"
like I2C, just a one way serial link.  This would probably be very
useful in IR and RF link apps too.

Any takers?

Martin.

On Fri, 9 Jan 1998 15:13:26 -0600, John Payson <supercatspamspam_OUTMCS.NET>
wrote:
><SNIP>
>
>If people use PLL's to sync on "the middle" of bits, all the more power
>to them; even with Manchester coding as you describe it, though, I'd think
>it easier and more reliable to read things as long and short pulses, and
>then try to interpret the long/short pulse strings.


Martin R. Green
@spam@elimarKILLspamspamNOSPAMbigfoot.com

To reply, remove the NOSPAM from the return address.
Stamp out SPAM everywhere!!!

1998\01\10@014537 by Eric W. Engler

flavicon
face
>>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.
>
>This is not Manchester data then.  In your earlier post, you said
>correctly that "manchester data has a transition in the center of each
>bit".  There is either 1/2 or one full bit time between transitions.
>However, special sequences which violate the protocol (missing a required
>transition) are often used for sync marker bits.  The decoder would need
>extra logic to detect these.

You're correct. I got it confused with MFM.  I believe MFM is the one I
described regarding the 3 carrier freq's.  I remember playing around with
it, but the terminology is not fresh in my mind.

>This is the basis of RLL encoding.  It uses a basic time unit of 1/3 bit
>time, with a guarantee of at least 2 but not more than 7 basic time units
>with no transition after each transition.  Conforming to these rules, it
>is possible to store 8 bits every 16 basic time units.  To record on the
>same hardware that previously used MFM, every 3 basic time units is
>equivalent to 1 MFM bit.  Thus the overall bit rate is 1.5 times that
>possible from MFM.  This format is used on nearly all modern hard disks
>as well as CD-ROMs  (On CD, 17 basic time units store 8 bits.  The extra
>time is supposedly used to "reduce DC content").

Indeed, RLL is one type of Group Code Recording.  The lookup tables ensure
that you will never have too many 0's or 1's in a row.  I'll try to come
up with a better explanation of GCR.

As others have noted, Manchester itself is not so hard to decode.
You are guaranteed one transition for each bit of data.  That must be
why it's used on TV remotes - not necessarily because it's efficient, but
just because it's easy to work with.

Eric Engler

1998\01\10@042021 by Eric W. Engler

flavicon
face
At 05:55 PM 1/9/98 GMT, you wrote:
>One doubt:
>
>Still referring to my tones via phone lines problem, will I get any benefit
>by using Manchester encoding in my transmission ?
>
>I understand the advantages of a synchronous approach when you are recording
>the data on a cassette, but how about phone line transmission ?
>

Phone lines are a little different in their frequency spectrum.  They
don't do good with 300 hz tones, so MFM is not a reasonable method.

However, Manchester is still fine, but not optimum.  It would give you
two tones an octave apart.

The biggest concern with phone lines is "Group delay distortion".  This
is basically a inconsistant phase shift throuhout the frequency range.
To minimize this type of distortion, your tones should be closer together.
For example, if you're using 1200 hz with Manchester, the low tone is 600 hz.
Both tones are well within the passband, but the delay of 600 hz will
likely be different than the delay of 1200 hz.

For ease of use and good performance, it's best to use real modem
chips.  Some of them are even good enough to automatically compensate
for group delay distortion.

Only the absolute lowest cost designs should use Manchester, or FSK,
over a phone line. It will work, but it's easier and fairly cheap to use
real modem chips. One popular one was from TI - I think it was only a 1200
baud chip, but it was easy to interface to and cheap.  I've heard that it
may not be available any more - I can't remember the part number.

Does anyone know of some inexpensive modem chips?  Please give us
some part numbers.

Eric Engler

1998\01\10@042034 by Eric W. Engler

flavicon
face
See this site for a good explanation of Manchester and
Differential Manchester coding.

ppdbooks.pok.ibm.com/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/EZ306400/REVIS
IONS

Diff. Manchester has 2 big advantages:
 - less clock jitter
 - not polarity sensitive

I'm still hunting for a source of good info on MFM and GCR.

Eric Engler

1998\01\10@045205 by Eric W. Engler

flavicon
face
I looked up some sources for GCR encoding, since that method is
one of the most efficient (short of DSP methods).

Apparently the "GCR" term (Group Code Recording) is not widely
used, since it got associated with tape drives.

"4b/5b" encoding is the most common form of GCR for network
applications.  FDDI (the fibre optic network protocol) uses it
with NRZI.  I think Fast Ethernet also uses it, but it combines
several other protocols together.

Some confusing terms:
source encoding - the way you translate your data before sending it.
                 This is "4b/5b" for FDDI.

channel encoding - the way the logic values are actually sent on the
                  wires.  This is NRZI for FDDI.

This web site has the table that you need for "4b/5b".  You just
break your data into nybbles, and lookup a 5 bit value to send in
place of each nybble.

http://www-dept.cs.ucl.ac.uk/staff/S.Bhatti/D51-notes/node51.html

Eric Engler

1998\01\10@105902 by Tom Handley

picon face
  Martin, I also recall that Manchester's popularity was the self
clocking and another advantage was there was always a bit level change
which we took advantage of in the early 80's with an IR system. With
NRZ we could'nt drive the IR LEDs as hard. I was trying to find the
encoder/decoder chips we used. I think it was from Harris but I have
their recent data book set and I could'nt find it. I think it was
HD3<something>. I thought that I still had a pair but I still have old
surface mount 54 series TTL from the 60's and 1702's... This has'nt
made it to my current inventory data base ;-)

  With Manchester code, the 1's change at the leading half of the
time slot and the 0's change in the trailing half of the time slot.
Another related scheme is Bi-Phase (the chips we used did both). In
this case, 1's are at the middle of the time slot and 0's occupy the
full time slot. Basically, the 1's occur at the clock rate and the 0's
occur at 1/2 the clock rate.

  - Tom

At 04:55 PM 1/9/98 GMT, you wrote:
{Quote hidden}

1998\01\14@062510 by paulb

flavicon
face
Many years ago (20?), I was musing on circuits to implement Manchester
coding.

 As I understood it, there was a "Type I" and a "type II" Manchester
coding, type I being regular clock transitions with data transitions
(present or not present) between.  At 1200 bps, this was the Kansas City
Standard for tape storage and other things.  The alternate description
of it was that one state was coded as a half cycle of 600Hz square wave
while the other state was a full cycle of 1200Hz.

 If it could fit a tape recorder, it should have passed down a
telephone line too!  The type II encoding I understood to be a
transition at clock time for one state, no transition for the other
state, alternatively called NRZ or NRZI depending on which state is
regarded as which.  This requires bit-stuffing and flags or an
asynchronous protocol (with guaranteed periodic stop bits corresponding
to transitions) to maintain clock synchronisation and is used in HDLC
protocol.

 With filtering, this is used as the basis for the 4800 baud HAPN
protocol on Amateur Packet Radio, but it very touchy to tune.  It
appears that we will be reverting to 1200 baud (Bell 212) FSK on our
packet network in this area for the near future!

 Cheers,
       Paul B.

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...