Please Recommend Wireless Protocol and How-To/Tutorial

<usenet@pobox.com> wrote in message
news:8ded0ef5.0411061307.7c3c46b4@posting.google.com...
> "Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> wrote in message news:> I
agree that a good way to start is with, e.g., XModem, since the original
> > poster apparently has a 'virtual RS-232' connection between the
transmitter
> > and receiver going already.  In fact, getting XModem or similar working
> > should be sufficient for his project.
> >
> > However, for 'real world' applications, you need to encapsulate the data
in
> > a much more robust encoding scheme -- at least if you need to go
'reasonable
> > distances' with 'reasonable powers.'  Wireless systems typically have
bit
> > error rates on the order of 10^-2 (1 in 100 bits bad), which will pretty
> > much destroy the ability of protocols designed for 'wired' systems
(TCP/IP,
> > X/Y/ZModem, etc.) to function over any reasonable distance.
Implementing
> > sophisticated encoding with error correction would be a good follow-up
> > project for the OP.
> >
> > ---Joel Kolstad
>
> Hi all,
>
> Thanks again for all of your assistance.  Can I characterize my
> connection as a "virtual RS-232 connection"?  I do have a pair or
> transceivers with serial data in/data out.  I haven't gotten too much
> information from the vendor that sold them to me, but from what he has
> said, I will need to produce a transmitted waveform with apx. 50% duty
> cycle, for which he recommends I use Manchester Encoding.  He also has
> explained that I need to transmit a preamble (he said a square wave
> for about 5 ms would do) in order to allow the receiver time to
> stabilize before receiving data.  Without the preamble, he says I'll
> lose the first several characters that I transmit.  He also said that
> I'd have to choose a pattern that I won't find in my data stream to
> use as my start code.
>
> I also agree with Joel (above) that I "should" have to worry about
> errors as a result of this being a wireless communication.  (Whether I
> will actually experience a reasonable amount of errors if I put the
> transceivers right next to each other remains to be seen, but I'd like
> to include error detection and possibly correction as a part of my
> project nonetheless.)
>
> So, given all of this, I'm thinking that any protocol I use as a
> reference needs to be designed for wireless communications so as to
> show me how all of these needs are addressed.  Perhaps I might be able
> to use protocols like XMODEM to observe how some common things are
> done (i.e. packetization).
>
> BTW, does anyone know how to figure out how large to make your packets
> when designing a protocol?  I imagine that if you make a packet too
> large, you defeat the purpose of breaking up your data and increase
> the chance that your packet will contain a corrupted piece.  On the
> other hand, if you make your packet too short, you lose efficiency
> because your packet header overhead will dominate the size of your
> actual data payload.  Given that, how do you pick a size in between?
> One way to do it would be experimental--just try some sizes and see
> what works.  Any other ideas?

The zmodem protocol used back in the latter days of phone bbs's used a
variable packet size. If you were getting lots of errors, it would drop
packet size down till some packets got thru without an error, if later it
detected that all packets were getting thru without errors, it would up the
packet size to increase thruput. If it got down to minimum packet size and
still had at least one error per packet it would abort the transfer. If you
include some form of error correction along with the packets then you lose
another 30% or so of thruput, but you can survive simple bit errors, and it
takes a multiple bit error to be unrecoverable. And when I speak of errors I
refer to unrecoverable errors, that the error correction couldn't fix.

Error detection is mandatory for any sort of packetized communication.

You might also check out the code used by modems around the time of v22.bis
(2400 cps modems) and later. Most of them offered error detection/correction
and data compression which meant the data was packetized.

On 2 Nov 2004 20:17:35 -0800, usenet@pobox.com (usenet@pobox.com)
wrote:

>I am a student in an embedded systems design class.  I am planning a
>project where I'll get two 8051-microcontroller-based development
>boards with 433 MHz FM transceivers to talk to each other.  Each
>development board will be connected via RS-232 to a computer running
>terminal software.  My initial goal is to be able to send some
>keystrokes back and forth between the two systems.
>
>

Hi, I have had some of my students do such things in the past, I
lecture at the University of Ulster (and am a radio amateur)

A fully fledged protocol that is robust has a lot in it

If all you want to do is pass keystrokes, or some application that
just demonstrates the technology then it is not too difficult.

My students just used three remote stations and demonstrated switching
a relay on and off, sending back their status when asked and sending
back temperatures when asked, all very low volume stuff.

The students spent their time getting the modules going, aerial (i.e
antenna (sic) ) working and handling a crude master slave protocol.

The only "gotcha" ( unexpected feature 8-) ) was that if receivers and
transmittes are close to each other then switching the transmitter on
saturates the receiver and the particular modules we used it took over
half a second before the receiver could receive anything after the
transmitter was switched off.

(the standard fix for this would be to design a little pin diode
switch that shorts out the receiver input so it doesn't see a massive
signal from the transmitter. Or to use distance to separate tx and rx
aerials, there are other fixes...)

The expedient solution was to add a one second delay!

We just used RS232 and the RTS control line to enable the transmitter
(AFAIR). Each transmission was a single line of simple text readable
ASCII, with a end of line sequence of <]><CKSM>CKSM><CR> and a start
of line sequence of <n><[> where n is 1,2,3 or the letter 'M' for
slaves 1,2 or 3 or the master. I used the bracket symbols so that if
you clip a second PC onto the system you can use hyperterminal to
monitor traffic, ( also I implemented the first version of this
protocol on 8-bit apple microcomputers ][ )

Hope that helps, I may have a machine readbale version of the
student's report, but the info above should get you started. I would
only email the report to your prof in any case, 

Don't forget to tell the group how you get on!

Regards and good luck
Ian McCrum, MI5AFL, lecturer in Digital systems
Unversity of Ulster.
__

usenet@pobox.com wrote:

> The real challenge of the project is in developing my own wireless
> protocol to handle packetization, start and stop codes, error
> detection and correction, line coding, and perhaps collision handling.

>  I am looking for a good tutorial on how to go about such a task--i.e.
> what options are available and guidelines for implementing them. 
> Something on the web or a book would both be good. 

It gets into more of the low level detail than you might, perhaps, be 
interested in for this project, but I'd recommend Bernard Sklar's book, 
_Digital Communications: Fundamentals and Applications_ for a very good 
book on the basics of that topic.  Second, if you do elect to design 
your own protocol, I'd recommend modelling it before you deploy it.  You 
can find errors quickly and easily in a model that you might only rarely 
encounter in real operation.  To find out more about that, I'd recommend 
Spin, which you can read about at http://spinroot.com/spin/whatispin.html

Good luck!

Ed