>-----Original Message-----
>From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] 
>Sent: 28 April 2005 16:35
>To: Microcontroller discussion list - Public.
>Subject: Re: [EE] RF encoding
>
>
>Mike,
>
>There are additional benefits you gain with Manchester 
>encoding other than a negligible DC offset. One is 
>self-timing. If there is any variation in your transmitters' 
>clocks your receiver can easily compensate for it. Second, 
>since there are essentially 'rules' that describe how the 
>Manchester data stream is to be coded, the receiver can verify 
>that none of the rules are broken. And a rule can be broken by 
>noise corrupting the data. (If you view the Manchester 
>encoding as a sequence of narrow/wide and high/low pulses 
>there are combinations that are invalid.) Thus, you get some 
>error checking by virtue of the fact that the stream is 
>Manchester encoded.
>
>To address your concern that it appears Manchester encoding 
>sends the data twice, I'd just suggest trying to imagine any 
>other encoding that can send clocked data. One example is a 
>pulse width scheme. If you divide the bit slice in half, then 
>a '0' can be sent with a pulse that is narrower than half a 
>bit slice and a '1' is wider. You'll need some margin, so you 
>may choose 1/3 width for 0's and 2/3 width for 1's. But, 
>you'll notice that there are two edges transmitted for *every* 
>bit. On average, Manchester encoding has fewer than two edges.
>
>As far as CRC versus Hamming, I'd say the choice depends on 
>the number of bits in your data. If there are only a few 
>bytes, then I'd use a hamming code.


Scott,

Thanks for the comments.  I appreciate the benefits of manchester for
clock extraction, however I think I forgot to mention a fairly important
point!  I was intending to use the PIC's USART for sending and receiving
data, and sending a string of balanced, but illegal manchester codes as
a preamble to stabilise the data slicer in the receiver, and using the
code sequence shown on Piclist.com (originaly by Bob Ammerman I think??)
to ensure the USART is byte aligned.

Under these circumstances, the edges aren't used for clock recovery
apart from the start bit at the beginning of an asynch byte.  Looking at
(e.g.) an (8,4) hamming code, an 8 bit code can represent 16 discrete
values (same as manchester) but with the advantage of being able to
correct 2 bit errors.  The downside is that 2 of the 16 resulting codes
are totally unbalanced (i.e. 0x00 and 0xFF).  I could just ignore those
codes, using the other 14 and only geting ~3.8 bits encoded per octet,
and this would actualy be ok as 4 encoded bytes would hold a ~15bit
value which is plenty for my application.  However, if there is a
reasonably simple scheme that would allow the full range of codes to be
used it would be usefull.

Regards

Mike



=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist