I recently found this App Note from Nordic Semi about using a UART for transmitting over RF. It looked useful to me, perhaps it can help you. http://www.nordicsemi.no/files/Product/applications/nAN400-07rev1_2.pdf Glenn On 4/29/05, Michael Rigby-Jones wrote: > > > >-----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 > -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist