Newsgroups: rec.models.rc
Subject: Re: Radio dreams
From: kaiser@elec.canterbury.ac.nz (Chris Kaiser)
Date: 10 Sep 92 10:36:52 +1200
Distribution: world
Organization: Electrical Engineering, University of Canterbury, New Zealand

In article <ERICJ.92Sep9124702@calcutta.cfsat.Honeywell.COM>, ericj@hwcae.Honeywell.COM (Eric Jacobsen) writes:
> In article <1992Sep9.150729.4381@informix.com> robertw@informix.com (Robert Weinberg) writes:
> 
>    OK, set loose your electronic imagination.
> 
>    SUPPOSE all transmitters used the SAME frequency, sending out packets of digitally  
>    encoded signals. The receiver would look for a packet addressed to it with a  
>    digital code, and only pay attention to that packet.
> 
>    Everyone would have to time-share the same airwaves, so the packets would have to  
>    be brief, and there would have to be assurances that if there were, say, 25 planes  
>    up, nobody got bumped.

Something that Eric didn't say in his followup is that by compressing the information
into a short time pulse (packet), you are increasing the frequency spread. The frequency
range (bandwidth) necessary to send a certain amount of information at a certain
quality (SNR) is essentially independent (to within a resonable factor) of the method
used to send the information - the reasons for using one method over another are
generally dependant on other factors.

> ... some stuff deleted ...
> 
> This sort of thing does work, but adds a lot of complexity (interpret $$$$)
> to the systems, both in the airplane and in the xmitter. The other problem
> is that the channel access management (how to decide when you can transmit)
> is not trivial and signal traffic collisions do occur. How to do the access
> management is a current topic for networks, cellular systems, etc. Many
> of the current methods involve waiting some random length of time and trying
> again if a collision occurs. If another collision occurs, you wait again, etc.
> 
> The problem comes along when you need your model to respond *really quickly*
> and can't tolerate the access delays. (stuff deleted)

This is essentially the method that ethernet uses. For low traffic volumes (i.e.
few users in the RC scenario) it works well, however for large amounts of traffic
its performance drops off fast, and delays become rather long. Another problem is
that it is statistical packet system, which means that information is transmitted
in discrete packets, and each packet can take a different amount of time before its
succesfully received. This isn't a problem for most data communication applications,
however RC stuff can be quite sensitive to time delays :-)

> Another method, though is to use a spread spectrum technique where you don't
> really care (as much, anyway) about how much radios are interfering with
> each other. This also complicates ($$$$ again) the transmitter and receiver.

Add to that that eash flier would have to have their own unique code, and there are
only a finite number of codes. Therefore you'd still have to have a control pegboard,
although it'd be a code control board rather than a frequency control board. Also, its
much easier (more idiot-proof?) to change a crystal than a spreading code.

These three techniques (frequency division multiplexing, time division mux'ing, and code
division mux'ing) are the major methods of allocating an available frequency spectrum
between multiple users. Each has advantages and disadvantages for different applications.
For RC applications, frequency division mux'ing (our current system) is currently the
best system in terms of cost, time delay, ease of use, control of clashs, etc.

Chris Kaiser

Postgrad, Elec. Eng. Dept.
University of Canterbury
Christchurch, NEW ZEALAND