Searching \ for 'Manchester 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/index.htm?key=manchester+encoding
Search entire site for: 'Manchester encoding'.

Truncated match.
PICList Thread
'Manchester encoding'
1998\02\04@161047 by Ed Todd

picon face
Here's a method I use:
latch on edge of first bit in signal
count high data samples for one Manchester bit width (using a clock
prescalar and one clock tick helps if you control data rate)
count same for another tick
subtract first count from second count
CARRY now holds the bit value.

This compensates for small spikes, distortions and so on.

Ed Todd <spam_OUTedtoddTakeThisOuTspamsni.net>
http://www.sni.net/cedardell

1998\02\04@172344 by Morgan Olsson

picon face
I think I never heard of Manchester encoding.
Please someone explain in short what it is.
Thanks in advance
/Morgan
/  Morgan Olsson, MORGANS REGLERTEKNIK, SE-277 35 KIVIK, Sweden \
\  .....mrtKILLspamspam@spam@iname.com, ph: +46 (0)414 70741; fax +46 (0)414 70331    /

1998\02\04@180723 by Martin R. Green

flavicon
face
Manchester encoding, as it's name implies, was invented at the
University of Manchester, and has been around for many years.  It is a
type of serial protocol with the special benefit that it is self-
clocking, there is always at least one transition during a bit time,
and this precludes the need for crystal controlled clocks to extract
the information from the stream.  Being self-clocking, it is also
relatively immune to source timing variations, making it a popular
choice for tape data storage, since variations in tape playback speed
are easily accounted for.  Among other things, it is the base serial
protocol for Ethernet, as mentioned, it is widely used in tape backup,
and it is the usual method of transmitting IR data in consumer remote
controls.

There are two types of Manchester encoding in use, and the only real
difference between them is the exact position of the information
holding transitions in the data stream, otherwise, the theory behind
them is basically the same.

CIAO - Martin.

On Wed, 4 Feb 1998 23:19:05 +0100, Morgan Olsson <mrtspamKILLspamINAME.COM>
wrote:

>I think I never heard of Manchester encoding.
>Please someone explain in short what it is.
>Thanks in advance
>/Morgan
>/  Morgan Olsson, MORGANS REGLERTEKNIK, SE-277 35 KIVIK, Sweden \
>\  .....mrtKILLspamspam.....iname.com, ph: +46 (0)414 70741; fax +46 (0)414 70331    /


Martin R. Green
EraseMEelimarspam_OUTspamTakeThisOuTNOSPAMbigfoot.com

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

1998\02\04@205049 by Andy Kunz

flavicon
face
At 10:53 PM 2/4/98 GMT, you wrote:
>Manchester encoding, as it's name implies, was invented at the
>University of Manchester, and has been around for many years.  It is a

And I always thought it was a friend of Girl Friday's. <G> Man Chester.
Get it.

Never mind.


==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1998\02\05@000435 by Mike Keitz

picon face
On Wed, 4 Feb 1998 14:09:41 -0700 Ed Todd <edtoddspamspam_OUTSNI.NET> writes:
>Here's a method I use:
>latch on edge of first bit in signal
>count high data samples for one Manchester bit width (using a clock
>prescalar and one clock tick helps if you control data rate)
>count same for another tick
>subtract first count from second count
>CARRY now holds the bit value.

This method, as described, will not work if the bit rate is not exactly
as expected (it will get out of sync after a number of bits) or if the
"edge of first bit" used for synchronization is not valid.  The concept
of continuously majority detecting is a good one, though generally not
necessary.

About the simplest method, though not optimal, it works on reasonably
clean signals when the bit rate is approximately constant and known:

1) Sample the data input and store the result
2) Wait until data input is opposite the value accepted at (1)
3) Wait 3/4 bit time (1.5 "manchester bit widths") and repeat to (1)

It is necessary (as with any decoder) to receive at least one "long" bit
(a 10 or 01) to get in synchronization.  Depending on how the data is
encoded, the data accepted at step 1 may need to be inverted, or xor'd
with the previous bit.  During step 3, the CPU can do other tasks,
ignoring the data input.  If the routine is in sync with a
properly-encoded signal, the mandatory transitions occur during step 2
and the optional transitions during step 3.  So the time spent in step 2
is about 1/4 bit time.  A timeout of step 2 could be used to detect loss
of data carrier or intentional violations of the Manchester code used for
byte or frame sync.
>
>This compensates for small spikes, distortions and so on.

The routine above could be hardened against small noise impulses (which
are usually rejected by hardware anyway) by using a majority detect in
step 1 and a "debounce" (minimum time at constant value before change is
accepted) in step 2.  Small variations in the bit rate could be
compensated by looking at the average time spent in step 2 and adjusting
the time for step 3 accordingly.

Optimizations of the sort described above are usually not needed as the
Manchester data clocks itself.  If the data is subject to "dropouts" (for
example if it is recorded on bad tape or sent by radio), a different
decoding scheme altogether should be considered, one that uses a PLL
method to keep in bit sync during the dropout.  Something similar to Ed's
method, only more advanced than just latching on the edge of the first
bit. Then data will be recieved in sync as soon as it returns, and the
ECC routine will have as much as possible to work with to reconstruct the
dropped-out data.
>
>Ed Todd <@spam@edtoddKILLspamspamsni.net>
>http://www.sni.net/cedardell
>

_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]

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