Searching \ for 'Manchester Code' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=manchester+code
Search entire site for: 'Manchester Code'.

Truncated match.
PICList Thread
'manchester code'
1998\09\11@100229 by Aaron Hickman

flavicon
face
To all,

       Can anyone point me to a link that includes some code on any uP
explaining how to use Manchester or biphase encoding?

Aaron Hickman

1998\09\11@101253 by John A. Craft

flavicon
face
>        Can anyone point me to a link that includes some code on any uP
>explaining how to use Manchester or biphase encoding?
>

After going through this with Andy, here is his link.

Good look.

http://pw2.netcom.com/~fastfwd/answers.html#OTHER00015

John C.

1998\09\11@102045 by Philippe

flavicon
face
At 09:56 11/09/98 -0400, you wrote:
>To all,
>
>        Can anyone point me to a link that includes some code on any uP
>explaining how to use Manchester or biphase encoding?
>
>Aaron Hickman

Go at TEMIC Semiconductor and look at Idendification devices,
the circuit is called U2270B, look at AN019.PDF, there is nice
description of  Manchester and biphase coding inside the data-sheet.
If you did not succeed to get it, ask me for, I can send it to you (340K).

Regards,
       Philippe.

 +----------------------------------------------------+
 | Virtual Micro Design                               |
 |                                                    |
 | UMPS: Universal Simulator/assembler/debugger       |
 |                                                    |
 | E-Mail: spam_OUTp.techerTakeThisOuTspamvmdesign.com                      |
 | URL:    http://www.vmdesign.com                    |
 +----------------------------------------------------+


'Manchester code'
1998\11\30@004246 by Gianni
flavicon
face
Hi!
For my PIC16F84 based datalogger,I need to send some bytes with a pair of
commonly available low power RF Tx/Rx modules.
Usually these modules uses MM53200 or MC14026/27 IC to encode/decode data.
The receiver uses an A.C.coupled output amplifier/comparator ; so it isn't
possible use standard NRZ(like RS232) coding to send more bytes.
To save time,components,headache,I looking for some routines that emulates
MC14026/27 , or better , that send/receive a byte with Manchester code.
Any help would be greatly appreciated !

       Best regards
         Gianni


'Manchester Code'
1999\02\25@094242 by Howard Simpson
flavicon
face
Could someone direct me to where I would find a description of
Manchester code, and the use of same, please.
Ta!
Howard

1999\02\25@111112 by John A. Craft

flavicon
face
I always go back to Andy Warren's web page, here is the link.

http://pweb.netcom.com/~fastfwd/answers.html#OTHER00015

John C.

At 12:30 AM 2/26/99 +1100, you wrote:
>Could someone direct me to where I would find a description of
>Manchester code, and the use of same, please.
>Ta!
>Howard
>
>

1999\02\25@114424 by Wagner Lipnharski

picon face
Howard Simpson wrote:
>
> Could someone direct me to where I would find a description of
> Manchester code, and the use of same, please.
> Ta!
> Howard

Hi Howard,

Manchester encoding is a method of transmitting bits which enables
the receiver to easily synchronize with the sender.

A simple way of signaling bits might be to transmit a high level
for some period for a 1-bit and a low level for a 0 bit:

Bits Sent:             1     1     0     0

Signal:      High    ___________
             Low                |___________

Time: ->            .     .     .     .     .


However, when several identical bits are sent in succession, this
provides no information to the receiver about when each bit starts
and stops.

Manchester encoding splits each bit period into two, and ensures that
there is always a transition between the signal levels in the middle
of each bit. This allows the receiver to synchronize with the sender.

In normal Manchester encoding, a 1-bit is transmitted with a high
voltage in the first period, and a low voltage in the second, and
vice verse for the 0 bit:

Bits Sent:             1     1     0     0

Signal:      High    __    __       __    __
             Low       |__|  |_____|  |__|

Time: ->            .  '  .  '  .  '  .  '  .


In Differential Manchester encoding, a 1-bit is indicated by making
the first half of the signal equal to the last half of the previous
bit's signal and a 0-bit is indicated by making the first half of the
signal opposite to the last half of the previous bit's signal. That
is, a zero bit is indicated by a transition at the beginning of the
bit.

Like normal Manchester encoding, there is always a transition in the
middle of the transmission of the bit.

      Differential Manchester Encoding

Bits Sent:            1     1    0     0

Signal:      High  ____       __    __    __
             Low       |_____|  |__|  |__|

Time: ->            .  '  .  '  .  '  .  '  .


So, if you are receiving normal Manchester encoding, your circuit
will take a look in the burst of ones in the preamble of the block
received, it means your pll chip will lock frequency in the high to
low transition and generates a quadruple frequency to extract the
first pulse after the sync as a line sample.  Some circuits just use
a certain time delay to do that.

If receiving this signal:

                __     ___         _______
signal             |___|   |_______|       |___

clock extracted  __|_______|_______|_______|___

quadruple        __0_1_2_3_0_1_2_3_0_1_2_3_0_1_2

first pulse     _____|_______|_______|_______|__  <-- sample clock

level decoded        1       1       0       1


Some other circuits just open a window for sampling the arriving
signal between the 3 and 1 timing (exactly at the 0), so if the
incoming signal is down going, it is a "1", if it's up going it's a
"0".


For the Differential Manchester encoding, your circuit will take a
look in the burst of zeros in the preamble of the block received, it
means your pll chip will lock frequency in the high to low transition
and generates a quadruple frequency to generate the pulses necessary
to gate the incoming signal at exactly timing #2, between 1 and 3.

If receiving this Differential Manchester signal:

                __     ___         _______     ___         ___
signal             |___|   |_______|       |___|   |_______|   |___

clock extracted  __|_______|_______|_______|_______|_______|_______|

quadruple        __0_1_2_3_0_1_2_3_0_1_2_3_0_1_2_3_0_1_2_3_0_1_2_3_0
                     ___     ___     ___     ___     ___     ___
Sample gate    ______|   |___|   |___|   |___|   |___|   |___|   |__

level decoded          0       1       1       0       1       0

A change direction (differential pulse) at the gate time (time #2)
means a zero bit, a non pulse means a "1".


Resuming:

The normal Manchester is just a simple down level for "0" bit and up
for "1", but there is a sync embedded, while the differential gives a
360 degrees pulse for zeros and 180 for ones.

In any case it will carries a clock pulse for every bit.

manchester encoding is just a physical level modulation, this is a
serial synchronous, and there is the level modulation rules...
For example, your floppy disk read/write digital circuits works in
manchester physical coding.

IBM uses manchester coding on their 3278/9 terminals connected to
the controller 3274/3174 via coaxial cable.


--------------------------------------------------------
Wagner Lipnharski - UST Research Inc. - Orlando, Florida
Forum and microcontroller web site:   http:/http://www.ustr.net
Microcontrollers Survey:  http://www.ustr.net/tellme.htm

1999\02\25@122759 by John Payson

flavicon
face
|manchester encoding is just a physical level modulation, this is a
|serial synchronous, and there is the level modulation rules...
|For example, your floppy disk read/write digital circuits works in
|manchester physical coding.

I was under the impression, though, that double-density floppies used
a slightly different form of encoding which could sometimes go three
clocks without a state change, but would never have a state change on
more than three consecutive clocks [IIRC, the sequence 1010 would be
rewritten as 1000].  This allowed for the otherwise-illegal sequence
10101010... to be used as a synchronization/start of sector mark.

1999\02\26@084357 by Howard Simpson

flavicon
face
Thank you all for info. I shall investigate further.
Howard.


'Manchester Code'
1999\03\02@073841 by Howard Simpson
flavicon
face
Re the replies to my enquiry about Manchester Code.  Thank you, it's
been very clear and informative, and I see how it works.  AND it looks
like (after more experimentation) that I'm going to have to attack it,
as I have to send code over a radio link, and the radio link prefers
close to fixed length hi's and lo's.  Not only that, the instructions
say Manchester is preferable!  (A rarity - I've read the instructions!)
So!  Is Manchester practical to generate and resolve with 16F84's?
Mention was made of PLL's etc, which I'd rather not get involved in.
Speed is 2400 baud (4800 if I can get it) If so, I'd be appreciatiove of
a pointer to some sample program code.

1999\03\02@075923 by Marc

flavicon
face
> Re the replies to my enquiry about Manchester Code.  Thank you, it's
> been very clear and informative, and I see how it works.  AND it looks
> like (after more experimentation) that I'm going to have to attack it,
> as I have to send code over a radio link, and the radio link prefers
> close to fixed length hi's and lo's.  Not only that, the instructions
> say Manchester is preferable!  (A rarity - I've read the instructions!)

I haven't followed the thread, but I assume you consider Manchester
because of it not having much DC component, and the self-clocking
data?

If so, you might be better off with convolutional coding. That can
provide you with selfclocking data and little DC component (though
not zero), too. But additional to that it gains you forward error
correction of burst errors.

Convolution coding is quite simple and documented on the web (try
altavista). Just remember to send the parity bits inverted for
self-clocking data. I have done implementations that work on streams,
so the RAM requirements are very low and don't limit the block size.

Actually I think it's as simple to implement as Manchester, but
more desirable for radio links.

1999\03\02@174510 by Peter Homann

picon face
Hi  Marc,

Do you have an example of convolutional coding that you could forward to me.
I have not heard of it and are interested as I am about to attempt a data
radio link.

Thanks

Peter
---
Peter Homann    Email:  .....peterhKILLspamspam@spam@adacel.com.au
Adacel Technologies Ltd _/_/_/ _/_/_/ _/ Phone:   +61 3 9596 2991
250 Bay St, Brighton   _/  _/   _/   _/  Fax:     +61 3 9596 2960
Victoria  3186        _/_/_/   _/   _/   Home:    +61 3 9555 5603
AUSTRALIA            _/  _/   _/   _/_/_/Mobile:      0414-494578
------------------------------------------------------------------------


{Original Message removed}

1999\03\04@104900 by Marc

flavicon
face
> Do you have an example of convolutional coding that you could forward to me.
> I have not heard of it and are interested as I am about to attempt a data
> radio link.

Unfortunately, since I process my email on a Win machine, I have no reliable
archive of incoming/outgoing email anymore. I had written examples more than
once, and, I'm convinced, also to the PICLIST.

You should query Altavista for an error correction page, probably you can
find it with +"forward error correction" +convolutional +cyclic +codes robert
It is offered by a Robert something (I think).

Another info about those codes can be found somewhere on motorolas web server,
in context of their trunking radios.


The approach of convolutional codes is simple: Before each data bit, you
send a parity bit. The parity bit is build from _two_ databits (for example
using XOR). There three bit locations involved:

- the parity bit time slot
- the 1st data bit
- the 2nd data bit

Those are spaced evenly apart, for example 3 parity/data pairs each

In the receiver, you extract the data bits only and calculate new parity bits.
Then you compare those to the received parity bits. Differences indicate
transmission errors.

To find out whether the error hit a parity bit (in this case you ignore the
error) or a data bit (in this case you have to correct it), you use the fact
that the parity was influenced by _two_ databits - so for every databit
there exists a second parity information!

Just calculate the other data/data/parity in which the questionable data bit
took part, and see if it results in false parity, too.

If it does, the data bit is wrong (flip it to correct). If it does not,
the parity is wrong.


Your code is resistant to burst errors that are shorter than your spacing
window. If the 2nd calculation input is broken due to _another_ error (or a
too long burst), the corrected output is still erranous. Use a CRC to
validate the final output.


Maybe I have some early test code in C somewhere still, which is not efficient
at all but shows how errors are detected and corrected. If you have problems
locating the mentioned web pages, you can return with private email and I'll
try to find it.


Offer: If your project is commercial, I can develop that for you on the PIC.
Or if you're willing to go AVR, I have everything done already and can adapt
it for your application more cheap. I used an AVR S1200 on 434MHz FSK 1280bps.

1999\03\04@151453 by Gerhard Fiedler

picon face
At 14:04 03/04/99 +0100, Marc wrote:
>Unfortunately, since I process my email on a Win machine, I have no reliable
>archive of incoming/outgoing email anymore.

don't blame the operating system for an unsufficient application. email is
not part of windows, and my email application (running on windows) sure
provides me with a "reliable archive of incoming/outgoing email". just go
and buy a decent app :)

ge

1999\03\04@163650 by Andy Kunz

flavicon
face
>Unfortunately, since I process my email on a Win machine, I have no reliable
>archive of incoming/outgoing email anymore. I had written examples more than
>once, and, I'm convinced, also to the PICLIST.

Use Eudora (best) or one of the MS bundled products that they consider part
of the OS <G>.

Andy

  \-----------------/
   \     /---\     /
    \    |   |    /          Andy Kunz
     \   /---\   /           Montana Design
/---------+   +---------\     http://www.montanadesign.com
| /  |----|___|----|  \ |
\/___|      *      |___\/     Go fast, turn right,
                              and keep the wet side down!

1999\03\05@102047 by Marc

flavicon
face
> >Unfortunately, since I process my email on a Win machine, I have no reliable
> >archive of incoming/outgoing email anymore.
>
> don't blame the operating system for an unsufficient application. email is
> not part of windows, and my email application (running on windows) sure
> provides me with a "reliable archive of incoming/outgoing email". just go
> and buy a decent app :)

:-) That begins with a decent OS. On my previous machine (an Amiga) it was
dead easy to replace RMAIL by a script that appends the email to an archive
and then feed it into the original RMAIL command. DCRON then called another
script each 2nd week to compress those to a backup drive.

This not possible on my current machine, both because Windows is
more "user friendly", denying me =easy= access to the low level of
processing (costing much more time to achieve the desired functionality,
ie write a whole own Win32 mail reader program), and because it is so
quirky that there is no continous basis for automatic processes to
count on. For some programs I have to boot DOS6.2, for others I
even keep Win3.11 on the machine. A program can never count on the
machine to be able to run it at a certain time of the day.

I could go ahead and use different machines for those purposes, but I
want to =save= time, not =spend= it. I kept my previous computer until
I had to move, and most of it would have required major adjustments
(=spend time).

The lack of quick and proper access to data lets me no read usenet
anymore, not archive mails, not keep phonenumbers in the computer,
and use lots of paper instead of files.

Going Wintel was a major step back. But I had no choice, all the
EDA software requires that platform. Including Microchip, to get
back on topic (a little bit at least) :-)

1999\03\05@170925 by Gerhard Fiedler

picon face
At 12:42 03/05/99 +0100, Marc wrote:
>> >Unfortunately, since I process my email on a Win machine, I have no
reliable
>> >archive of incoming/outgoing email anymore.
>>
>> don't blame the operating system for an unsufficient application. email is
>> not part of windows, and my email application (running on windows) sure
>> provides me with a "reliable archive of incoming/outgoing email". just go
>> and buy a decent app :)
>
>ie write a whole own Win32 mail reader program)

i seem not to understand. have you ever looked at, say, eudora light
(freeware)? why would you want to write your own, if stuff like that is
around? and that's not the only one, you have choices. if you know how it
works you can do everything i understand you want to do and more.

ge

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