Please Recommend Wireless Protocol and How-To/Tutorial

"Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> wrote in message
news:FP6dneUpIbsCVRbcRVn-vw@comcast.com...
> "torresD" <nospam@nospam.com> wrote in message
> news:2v0h6vF2fnk63U1@uni-berlin.de...
> > 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.
>
> 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
>
That is a whole study area in itself, and it gets quite complicated.
It is quite dependent upon the channel characteristics too.
The hot code now is a class called Turbo codes, invented by some frenchies.
Good luck with your project

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

> ... which will pretty much destroy the ability of protocols designed for 
> 'wired' systems (TCP/IP...

Actually, TCP/IP probably isn't a good example, as what is on the lower 
layers can be entirely different and encoded and error corrected however 
you like, as long as the other end brings it back to the same data.  Ok, 
that's probably a bit picky, but it is true. ;^)

Jeff.

"Jeffrey A. Wormsley" <jwormsley@nospam.debitek.com> wrote in message 
news:Xns9598974302841jwormsleyatdebitekdo@195.191.14.90...
> Actually, TCP/IP probably isn't a good example, as what is on the lower
> layers can be entirely different and encoded and error corrected however
> you like, as long as the other end brings it back to the same data.  Ok,
> that's probably a bit picky, but it is true. ;^)

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.

I mention this primarily because I've been told that approach has been tried 
and the progenators apparently surprised at the results... ;-)

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

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!

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

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

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

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.

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