Searching \ for '[PIC]:PICs and RF links' 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/microchip/ios.htm?key=rf
Search entire site for: 'PICs and RF links'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:PICs and RF links'
2002\09\29@083511 by Dimitris Papavasileiou

flavicon
face
Hi,
I want to put together a full-duplex RF link for low baud rate data
transmission between to devices.One channel will be used for remote control
and the other for telemetry.The traffic will consist of fixed-length data
packets.Error detection is needed(a CRC should do) but packets need not be
resent in case of an error.PICs seem to have everything I need to do
this(UARTs for the link,ADCs for the controller etc.) but I'm not sure about
how suitable they are for RF links.The requirements are:

1)a ~9600kbps(or less if necessary) full-duplex link
2)a ~300-500m range(more would be quite welcome)
3)reliability:the link should not be lost for more than a few ms while in
range(that is it should deal with resync in case of sync loss quickly)

The questions I have are:
1)Can the built-in UART deal with a reliable RF link (that is
provide a more or less constant flow of data in normal conditions)?I'm asking
mainly because I've read in an article somewhere on the PIClist faq that HW
UARTS aren't best suited for RF transmission).Also in case of a framing error
what is the best way to resync the channels.I assume that the method
described in article on synchronizing at the byte level will work with
PICs(will it? some assumptions were made on the UART behavior) but how does
the receiver let the transmitter know that sync was lost.Obviously we can't
depend on the second channel because (in a very bad day) they might loose sync
simultaneously.
2)What other things should I look out for?Like using Manchester code or not(I
assume this is necessary as some transmission might include long 1 or 0
strings which would result in clock drift),how the physical link should be
established(FM RF,RF modem chip),etc.
3)Out of curiosity.If all the above is possible and doesn't cost a fortune(it
shouldn't) why do all commercial remote controls(RC cars etc.) use one analog
channel per 'stick' instead of just reading a bunch of data with an MC and
send it as digital data packets(like I want to do).It would give you as many
channels as you can use with a 9600kbps link.

Thanks in advance,
Dimitris

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\09\29@125921 by Doug Butler

picon face
Look at Microchip's rfPIC series:
www.microchip.com/1000/pline/rfpic/index.htm
They are new and I have not used them but they sound like just what you
need.

Doug Butler
Sherpa Engineering


> {Original Message removed}

2002\09\29@232514 by Dale Botkin

flavicon
face
On Sun, 29 Sep 2002, Dimitris Papavasileiou wrote:

> 1)Can the built-in UART deal with a reliable RF link (that is

Not in my experience.

> 2)What other things should I look out for?Like using Manchester code or not(I
> assume this is necessary as some transmission might include long 1 or 0
> strings which would result in clock drift),how the physical link should be
> established(FM RF,RF modem chip),etc.

I had to go with Manchester on the project I'm currently working on.
This of course pretty much rules out using the hardware UART.

Transmitting is easy, receiving much much less so.  I finally implemented
an interrupt driven tx/rx service routine that does both quite well, but
unfortunately I can't share the code as it was done on someone else's
nickel.  I can, however, tell you that a Microchip app note on Manchester
data exchange came in VERY handy.  It's not a PIC app note, it's a Keeloq
app note.

> 3)Out of curiosity.If all the above is possible and doesn't cost a fortune(it
> shouldn't) why do all commercial remote controls(RC cars etc.) use one analog
> channel per 'stick' instead of just reading a bunch of data with an MC and
> send it as digital data packets(like I want to do).It would give you as many
> channels as you can use with a 9600kbps link.

Well, I believe it's probably partly that they use dirt cheap application
specific chips dedicated for that purpose.  They also don't *need* to send
anything complicated, just very simple position information for X number
of channels.  Just a guess, but when designing for low-buck mass
production, cool counts for zero and cheap counts for everything.

Dale

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


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