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

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 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.

"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?

Thanks.

Hi Usenet,

This is a popular search. Lots of people buy tiny RF modules and then go
looking for a protocol, myself included.

I looked at a lot of stuff and concluded that I was better off, and
certainly from an educational standpoint, writing my own.

I have 3/4 baked 8051 pseudocode for a HDLC with digital PLL, that  various
protocols can be layered over. Contact me privately if your interested in it
'as is', or if you think you might like to do some work on it with me.

Regards,
Murray R. Van Luyn.

<usenet@pobox.com> wrote in message
news:8ded0ef5.0411022017.542f84a7@posting.google.com...
> 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.
>
> 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. I was wondering if
> you might be able to make a recommendation.
>
> Additionally, if you would please recommend any existing protocols
> that would be sufficient for my application, this would be very
> helpful because: a) I can use the existing protocol as a reference
> when developing my own and b) If it turns out to be too difficult to
> develop my own, I can switch my goal to implementing the existing
> protocol.
>
> I would be very grateful for any assistance that you might be able to
> provide.  Thanks so much for your help.

Sounds like there may soon be a vacancy in that chair.....

<usenet@pobox.com> wrote in message
news:8ded0ef5.0411041517.67b5c463@posting.google.com...
> .....in that I've ventured
> outside of the realm of my Professor's expertise

It is simple.

Write down what is required; how you expect each side to behave in
response to each part of your protocol, and the program design is then
obvious.

For example, you mention packetisation. How do you propose to
encode your information such that the real data that you send is never
confuse with the start and stop of packets?

<usenet@pobox.com> wrote in message
news:8ded0ef5.0411022017.542f84a7@posting.google.com...
> 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.
.

"Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> wrote in
news:n5GdnTZ4pJxgexbcRVn-rw@comcast.com: 

> Right, the point I was after is that even though TCP/IP has plenty of
> its own error correction built-in, it assumes the lower level has a
> 'reasonable' bit error rate (perhaps 10^4-10^-6) and using it
> _without_ further encoding (i.e., with simple CW/AM/FM) over the
> typical radio link will kill it. 

Ok, almost totally off topic, but did you see the EDN article about 
10GbaseT, 10GBPS over copper?  What these guys are doing for error 
detection/correction must be orders of magnitude over orders of magnitude 
beyond what I am capable of.  To bring it slightly back on topic, I doubt 
many of those techniques apply to wireless, unless you are looking at 
spread spectrum.  Certainly beyond the OP's request, though.

Jeff.

Joel Kolstad wrote:
> "torresD" <nospam@nospam.com> wrote in message
>
>> You have to have the specs of the TXRX boards and the IO.  You can
>> use x modem or y modem or z modem or several gernic file transfer
>> protocols, kermit, just to get going. why write all that code, and
>> figure out the timing. and fine tune it later
> 
> 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.

Actually X and Y modem are likely to be very hard to get up on such
a system.  Timing is quite critical, and turning around to listen
for an ack/nack is critical.  This is one of the reasons Zmodem was
born.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

On Fri, 5 Nov 2004 10:38:46 -0800, "Joel Kolstad"
<JKolstad71HatesSpam@Yahoo.Com> wrote:

>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.

For real world applications, you also need to consider the multipath
problem and avoidance using e.g. by frequency diversity (e.g.
frequency hopping) or space diversity (multiple antennas or movement).

With a fixed narrow band channel in the UHF and a stationary system,
you will sooner or later be in a spot, with a 20-40 dB signal level
drop, while the signal would be perfectly acceptable with the antenna
at a location 20-40 cm away or at a frequency 100 kHz away.
 
Paul