On Fri, 12 Sep 2003 21:33:45 -0400, you wrote:

>Mike Harrison:
>
>I think there may be some confusion arisin here - I was under the =
impression
>that the issue was
>generating RF -suitable data patterns from TX uart.
>I don't think anyone was proposing trying to receive it via a uart - if =
so,
>it's really not a good
>idea.
>What you typically see is noise, then the preamble, which stabilises the
>gain and the data slicer,
>then you need some synchronisation pattern or gap to define the byte
>framing.
>A bit-bashed receiver (or interrupt driven, or using input capture =
hardware)
>which can deal with all
>the rubbish correctly is not hard to implement and will be much more
>reliable than trying to bend a
>UART into doing something it's not deaigned for.
>
>Bob Ammerman:
>
>Ah.... but that is the neat trick here. You can use the way the UART =
handles
>framing errors to get you properly into byte sync. See
>http://www.piclist.com/techref/microchip/ammermansync.htm for the =
details.

Very clever solution , but quite a few downsides :=20
Very wasteful of airtime (4 bytes to sync instead of 2 bits) - a =
significant issue wheer you have
several transmitters sending short packets,  and the sync patterns are =
not DC free.=20
Using a UART for receive also requires that the TX and RX have reasonable=
 clock frequeny accuracy
(at least a cearmic resonator), and it will have poorer margin for the =
varying pulse widths that are
typical typically occur under poor link quality conditions.=20
A true manchester encode/decode system is very simple to code, and =
overcomes all these restrictions.
I recently did this on an AVR - 20 instructions for byte-transmit, and =
about 40 for receive.=20
Of course this is a little more CPU intensive, although doing it under =
interrupts would not be much
harder and would allow other stuff to be happenning simultaneously with =
receive.=20

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu