[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]


Commercially, no one usually would consider putting up a satellite circuit 
without FEC. Trading bandwidth for power on ham satellites is a sound idea, 
in my opinion. The requirement then falls back to us to come up with a 
clever way to decode the recovered data stream. In commercial satellite 
modems, this is usually done with some dedicated hardware, usually using 
some programmable logic arrays. The process by itself could most likely be 
handled by the average desktop already in the shack except for all the 
other process's already being run there. Not an entirely un-manageable 
problem, but could be a factor.  Multi-tone, and higher order modulation in 
general, is becoming easier to generate and decode now that commercial 
products are becoming available. The OFDM modulation scheme being used in 
Europe for HDTV and here in the U.S. for broadband wireless are good 
examples of where we might be able to adapt some good technology.

I agree completely that any ham protocol needs to be point to multi-point. 
One of the things that I am guilty of is getting my ISO layers melted at 
the edges at times. Many of the satellite protocols currently used, like 
PACSAT, are layer 3 functions and still use part of AX.25 as the layer 2 
data link function. The modulation method, usually FSK, is part of the 
layer 1 physical interface. When we start thinking of protocol development, 
I think we need to look at the entire suite so that if we want to be able 
to bridge standard protocols onto the satellite network, we can do it with 
minimum effort. So far we have talked about layers 1 and 3 but not paid too 
much attention to layer 2. In my opinion, this area could use some work as 
well.  Our current method of access, Aloha with CSMA/CA is truly 
multi-point, but is terrible inefficient. Yes, it is true that this is how 
most LANs currently operate, but they are very inefficient as well. Put 200 
people on a 10 MBpS LAN and watch the traffic jam, caused mostly by data 
collisions. The PACSAT protocol does a good job of handling this in Layer 3 
( or maybe it's actually layer 4), but PACSAT isn't a good "conversational" 
protocol. The current AX.25 layer 2 schemes have at best a 10% thru-put 
efficiency.  In order to automatically control the "digital pileup" I think 
we need a more structured access mechanism. I believe the adoption of 
either CDMA or TDM/TDMA could be made to work for us.

In a CDMA (a.k.a. spread spectrum) environment, connections could be 
"channelized" by spreading code. By using a pool of known, orthogonal 
spreading codes one could scan all the virtual "channels" to find an 
interesting digital QSO. In a similar manner, digital QSO's in a TDM system 
would occur in known timeslots. Access in either system would be controlled 
by a separate reservation/request channel. This would be the only place the 
aloha or maybe slotted aloha scheme would be used. While any of these 
schemes are not as fast as a speeding P.T.T. button, they are all used t  
oday with great success. Look at trunked radio systems and satellite VSAT. 
All make better use of bandwidth than we do now.

I have really enjoyed this thread, it's always fun when you have the 
opportunity to create something new from the ground up, even if it's only 
on paper.


Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org