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\30@070934 by Dimitris Papavasileiou

flavicon
face
Thanks for the replies.I looked into these rfPICs,they look pretty cool but
there might be some problems with being able to get my hands on one and being
able to build a programmer since they're new.So if I have to use normal PICs
I'll have to use Manchester code, huh?What I was more interested in though was
how you synchronize transmission and how you detect sync loss(which should happen
easily with RF links since noise can change your synchronization(that is start/stop)
bits/bytes/whatever) quickly and restore it.I assume you don't use start stop bits per
byte any more but rather per frame/packet.But what's a good way to go in order to be
able to sync and resync quickly?

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\09\30@085443 by Russell McMahon

face
flavicon
face
> But what's a good way to go in order to be
> able to sync and resync quickly?

If you want optimum synchronisation (and a scheme that will stun your
friends if they haven't met it) look at "T Codes" invented by Mark Titchener
of Auckland University.

T codes essentially implement a recursive binary tree where each new node
added replicates the preceding tree to date. Using them is easier than
understanding them (fortunately).

Despite their apparently scary nature T Codes are essentially simple to
implement and allow mind boggling resynchronisation capabilities (to my mind
anyway).

Here's a page with some material thereon including a PhD thesis. There will
be simpler material around I'm sure. I have a friend who did his PhD on T
codes who I am sure could point you to some simpler material if you can't
Google up anything.

       http://www.tcs.auckland.ac.nz/~ulrich/publications.html

Here's a not totally simple intro

       http://www.tcs.auckland.ac.nz/~ulrich/depletion.ps

or a slightly mangled text version of the same thing.


http://www.google.co.nz/search?q=cache:aKbRonKMMPYC:http://www.tcs.auckland.ac.nz/~
ulrich/depletion.ps+%22introduction+to+t+codes%22&hl=en&ie=UTF-8

Here's an abstract that demonstrates that T codes may well be what you want
BUT they ant money for the full article.

           http://www.jucs.org/jucs_2_11/data_compression_and_serial



       Russell McMahon

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\09\30@093006 by Dale Botkin

flavicon
face
On Mon, 30 Sep 2002, Dimitris Papavasileiou wrote:

> But what's a good way to go in order to be
> able to sync and resync quickly?

Each packet includes a sync header.  In my case, I send a few zero bits to
stabilize things, then the sync sequence.  The sync is four bit cell
periods of low signal, which is a code violation and easy to detect.  It
also establishes exactly what 4x bit cell time is so the receiver can
start timing.

Dale

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\09\30@095110 by Dennis Crawley

flavicon
face
> On Mon, 30 Sep 2002, Dimitris Papavasileiou wrote:
>
> > But what's a good way to go in order to be
> > able to sync and resync quickly?
>
> Each packet includes a sync header.  In my case, I send a few zero bits to
> stabilize things, then the sync sequence.  The sync is four bit cell
> periods of low signal, which is a code violation and easy to detect.  It
> also establishes exactly what 4x bit cell time is so the receiver can
> start timing.
>
> Dale

Does anybody have worked around S.N.A.P.?
I think it is well documented and very simple to implement.
And thanks to Scott-Tony-Ashley the CRC16 it works very fast! (19200bps)
I didn't hear anyone who has implemented SNAP via RF.

Dennis.



Ahora podis usar Yahoo! Messenger desde tu celular. Aprendi csmo hacerlo en Yahoo! Msvil: http://ar.mobile.yahoo.com/sms.html

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\09\30@104851 by Dale Botkin

flavicon
face
On Mon, 30 Sep 2002, Dennis Crawley wrote:

> Does anybody have worked around S.N.A.P.?
> I think it is well documented and very simple to implement.
> And thanks to Scott-Tony-Ashley the CRC16 it works very fast! (19200bps)
> I didn't hear anyone who has implemented SNAP via RF.

If your'e talking about the same S.N.A.P I found at http://www.hth.com/snap, it
looks to me like a lot of overhead, especially for a point to point link
with a well defined data set.  It's a really unfortunate choice of names,
since SNAP has been used before -- SNAP is an extension to 802.2 used in
Ethernet systems, and of course there are legions of other people who've
used SNAP as the name of some protocol or other.

It might make a decent protocol at Layer 3 if you need all the features
(though IP would probably do as well and doesn't require a 'vendor code').
I think the main problems you'll see will be at L2, though.  With a good
L2 protocol you can just send your data and not worry about all the
addressing and other stuff if it's not needed, just toss a checksum or CRC
on the end for error detection.

It's been my experience so far that for reliable RF communications you
really need self clocking, bit-synchronous link layer encoding.  I've had
no luck just using async serial data fed to the transmitter; any noise
will keep the receiver in a nearly constant FE or overrun error state.
To be fair, I have only used a couple of types of RF hardware.  Maybe
other Tx/Rx hardware than what I've used is better for this, such as those
that implement a suitable synchronous L2 protocol internally.  In my case
I only got solid, reliable communications using a Manchester encoding and
a state machine receiver written to be very tolerant of noise and errors.
Once I did that everything fell into place and it works like it's supposed
to.

Dale

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\09\30@113813 by Dimitris Papavasileiou

flavicon
face
Ok, so what I need to do is:
1)implement the UART in SW myself instead of using a chip with built-in HW
UART
2)use Manchester code for the transmission and reception of the data
3)hack my data into n-bit packets(was going to do that anyway),no need for
frames since I only want to send one type of packet.
4)Send some kind of sync header like 00110011 or even 00110101 which will
allow me to detect packet start and sync at bit-level

That's more or less what I had come up with before looking into PIC UARTS
(w/o the Manchester code) where the hacking of data into frames(besides
my packets) complicated things with resync at the frame level(especially
since frames were delimited by single bits).
With a fixed packet length this should work ok.In sync-state you'll have the
PIC hunt for 00110101 and then enter packetread-state.At this point n bits
are read(well 2*n because of the Manchester),the packet is delivered for
processing and sync-state is entered.If an encoding violation is detected
during packetread-state read data is discarded and sync-state is entered.
This way the transmitter can just transmit packets whenever he wants to and
the receiver will sync and get them missing one or two packets at most.Does
that sound ok or am I missing something?
If that works(and if it doesn't something similar will anyway) it should be
a nice alternative to rfPICs if I can't use them for some reason.I'll have a
look at those t-codes as well.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\09\30@140930 by Dale Botkin

flavicon
face
On Mon, 30 Sep 2002, Dimitris Papavasileiou wrote:

> With a fixed packet length this should work ok.In sync-state you'll have the
> PIC hunt for 00110101 and then enter packetread-state.At this point n bits
> are read(well 2*n because of the Manchester),the packet is delivered for
> processing and sync-state is entered.

It's a little deeper, actually.  Think in terms of "bit cells" ot "bit
times", each of which has two parts.  The two parts -- call them half-bits
-- are always opposite.  You have a 0->1 or 1->0 transition in the middle
of each and every bit cell.  This is true for all data, preamble,
postamble, whatever.  The *only* time you send both half-bits without
changing state is during sync.  In my system, I send a few 1 bits followed
by 4 consecutive LOW half-bits, so it looks like this:

_-_-_-____-_
1 1 1sync 0

So while the receiver looks for a packet, it's really looking for a SYNC.
Once it sees that, it looks for a 0 bit to make sure it was a real SYNC
and not just a period of low signal.  The length of the SYNC must be
within a small fraction of the time it expects, and the total time is
divided by 4 to get the half-bit time.  That time is used to determine how
long to wait before reading the next bit.

I could go on and on, but a very helpful explanation and example has
already been written by our friends at Microchip.  It's done in assembly,
but I had no trouble working from this to write my own in C.
http://www.microchip.com/1010/suppdoc/appnote/all/tb045/index.htm

> If an encoding violation is detected
> during packetread-state read data is discarded and sync-state is entered.

Yep. Exactly.  For debugging when I wrote mine, I used four LEDs that I
set on and off to identify what state the routine was in.  Was very
interesting and very helpful to see where it was getting hung up.

> This way the transmitter can just transmit packets whenever he wants to and
> the receiver will sync and get them missing one or two packets at most.Does
> that sound ok or am I missing something?

You got it.

Dale

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\09\30@195143 by Dimitris Papavasileiou

flavicon
face
thanks for the appnote link.It looks like there's everything I need to know
there,at least for the receiver.But I guess I can implement the transmitter
on my PC and send data through the rs232 which should make things easier.If
you have any docs on a transmitter design let me know.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


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