>-----Original Message-----
>From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] 
>Sent: 29 April 2005 15:17
>To: Microcontroller discussion list - Public.
>Subject: Re: [EE] RF encoding
>
>
>Michael Rigby-Jones wrote:
>> 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.
>
>Not quite the same.  The UART sends an additional start bit 
>and stop bit, so you are sending 4 bits of data for each 10 
>slice times.  With manchester you get 4 bits per 8 slice times.
>
>> 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.
>
>How about using the synchronous serial port to send the 
>manchester data. This gets you 1 free bit for every 4 compared 
>to using the UART.  Then use those extra bits separately for a 
>CRC checksum or error correcting codes.  I doubt you'd need an 
>extra 25% more bits to reasonable protection, so this probably 
>takes less bit slice times and has better DC average over 
>shorter intervals, and is reasonably tolerant of clock 
>inaccuracies.  There is a reason manchester is used a lot in 
>low cost RF data transmission.

Olin,

The reason I was considering the USART was for ease of reception rather
than transmission.  The (increasingly vain) hope was that by
synchronising the USART with a preamble etc. that the rest of the data
would slot into place without too many problems, and I wouldn't need the
overhead of a timer interrupt at a multiple of the bit rate etc.  I'm
beginning to think that the USART might not be a great idea though.

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