Re: TI-H: RF TI link


[Prev][Next][Index][Thread]

Re: TI-H: RF TI link



At 09:51 PM 10/4/97 -0700, you wrote: 
>>>>
Ok, so you want me to make a contribution to the  TI-calc mailing list...
fair enough.  My opinion on the wireless  link:  it would be much more
productive if we studied cordless phones,  since they obviously rx and tx
at the same time, full-duplex.  Not any of  this walkie-talkie bull or
playing TI sounds over the radio.  I simply  don't have the time to design
a wireless link, or even look that far into data  sheets and figure out
what chips to use, or perhaps I would.  But, you have  my contribution.
-Robert Baumann Webmaster, Sagebrush Online
http://www.asun.unr.edu/Sagebrush/  

:x--------------------  SNIP  -------------------x:

I would like to agree with you, but I think size and cost are going to be
too great.

Full Duplex transmission requires one of two options. Either there must be
two separate paths (such as in a standard telephone which uses what is
commonly refered to as E&M (Ear and Mouth) signalling, you have the
(normally) red and green wires for 2 wire phone systems (four wire uses the
red/green, black/yellow (commonly refered to as christmas trees and
bumblebees) unless of course your in the military like me and we do it
alphabetically black/green, red/yellow)), OR you must use two separate
frequencies. One for the M intelligence, and one for the E intelligence.
These are the 10 channels allocated by the FCC for cordless telephone
systems (Not including the 900Mhz versions):

CH   BASE FREQ. HANDSET FREQ.
1 --   46.610     49.670
2 --   46.630     49.845
3 --   46.670     49.860
4 --   46.710     49.770
5 --   46.730     49.875
6 --   46.770     49.830
7 --   46.830     49.890
8 --   46.870     49.930
9 --   46.930     49.990
10--   46.970     49.970

Let's take channel one for an example. The base unit (the one connected to
the wall) is transmitting to the handset phone (we'll call this uplink for
now), this frequency contains both sides of the conversation and is routed
to the E lead (remember E is Ear). The reason it has both sides of the
conversation, is that your M (M for mouth) downlinked transmission is
placed on the E lead (This is so you can hear yourself when you talk. It's
annoying as hell when you can't hear yourself trust me!). Also the keypad
(In-band signaling) is placed on the E lead, so you can hear yourself dial.
If I remember correctly, this is called sidetone or something like that.

Christ, a little more deeply than I had intended to get into it, sorry.
Anyways. Although it is feasible to have full-duplex, it probably won't be
anywhere near size/cost effective. You would have to have in each calc
separate TX and RX freqs. This in and of itself is no problem, but now what
happens if you have two ppl playing a game, and another set of ppl want to
transfer a file. Now you have to have FOUR separate frequencies, or you'll
garble each other out. You can see where I'm going with this if you have
quite a few ppl in class with a RF TX/RX linking. Now you can have variable
tuning like on a FM and AM radio, but this takes up some more space, would
require a calibration sequence before beginning any transfers of data, you
would require a pretty good variable resistor, either continously tuning,
or something like the channel selector on the cordless phones, but this
would require a frequency network for the switch (a network of RC/LC
oscillators, or a reference oscillator and a frequency divider. Don't get
me wrong. I would love a full-duplex system, but I think cost and size
would kill it. If anyone has information to the contrary, please share it. 

I just thought of a possible fix to the multiple frequency problem. One
freq (half duplex), or two freqs (full duplex), each calc sends an overhead
byte on each transmission. This byte contains, say the calc group it's
currently in (i.e. a four player game going on, this is set up in the
software configuration as calc group 1. Now another four player group wants
to play a different game. They ask the first group what they're calc group
designator is, and then set theirs to something different). The overhead
byte would also include the calc designator number (In calc group 1, there
are four calcs. numbered 0,1,2,3 respectively, in calc group (let's say 2),
there are also four calcs 0,1,2,3.)) Each calc would have to be configured
prior to each session (unless say there is always the same four calcs in
one group of friends, then they could save the config.) When I say four
calcs, I'm using this number arbitrarily, there could be as few as two, to
as many as who knows. ALRIGHT, time to shut up... I'm a little long winded
(see my sig). :)

If I'm wrong somewhere in my above message:

enLIGHTen me, just without the flames please.



Leif

- ldgregory@biogate.com
    Dedicated to providing you with more
    information than you needed to know. -