As the co-author, let me add a few additional comments to Phil's. I think part of the confusion concerns the definition of the words (which some now seem to equate with four-letter words originating in Chaucerian tomes) "spread spectrum" and "coding".
Phil and I took a look at the fact that a "legal" EME QSO (and the results are applicable to other weak-signal paths also) requires only a few (like < 100) bits of information to be exchanged; this included calls, signal reports, grid-squares and acknowledgements.
To that ~100 bits of information we added a large number bits for error correction. This involved the use of convolutional coding, where any one piece of transmitted data contains information from many of the "raw" data bits. The ~100 data bits are represented by the much larger number of coded bits, but you can take a "hit" and lose many of the coded bits without destroying the "raw" data. A simple example of coding occurs with your computer's hard disk. The data written on the disk may have 1:10e5 to 1:10e6 errors as the magnetic pattern is read, but you see a "delivered product" error rate more like 1:10e15!
We then tried to "match" the coded bit string to the physics of the EME path, realizing that much of the signal's coherence is lost in "multipath" scattering off the rough moon (the coherence loss and fading properties are different at 2M than they are at 3 cm. Our paper tended to focus on the characteristics in the 2M/70cm range). We found that if we "spread" the signal in frequency, performance would be better. But we adopted the additional "mere mortal radios" criteria and looked at "spreading" the signal over the ~2 kHz passband of an SSB radio. Various factors drove us towards a "keep the key down 100%" FSK scenario, where each transmitted "cell" would occupy one of several different frequency channels in a 2 kHz wide spectrum. The 2 kHz wide signal would be processed with DSP techniques with a SoundBlaster board in a Pentium-class PC. The PC would also do all the processing of the noisy convolutionally coded signal, so that at the end of a transmission (like maybe one minute), the entire QSO message would appear.
The other "key" to our scheme involves the fact that it is now possible for every amateur in the world to have timing clocks that are synchronized to a few hundred nsec using GPS. For those not familiar with what we've been doing on this front, browse my ftp site at ftp://aleph.gsfc.nasa.gov/GPS/totally.accurate.clock/ ; I am now working with TAPR to make a TAPRized kit version of my TAC available to the community. Expect an announcement Real! Soon! Now! and stay tuned to the TAPR web site at http://www.tapr.org
The tradeoffs that need to be made (and Phil and I don't have perfect agreement on which will be best!) involve: - the number of error correction bits to be added to the "raw" data - the number of FSK frequency "channels" - the length of time spent transmitting one coded "cell" - which combination of these parameters will be optimum on a band-by-band basis
Clearly there will be a lot of experimentation. The different parameters are all in the "it's only software" category. Our initial estimates are that ~20 dB improvement can be achieved easily; this brings 2-way EME into the realm of the OSCAR users.
On the "dirty word" "spread spectrum" issue -- the first thing to be realized is that the words "spread spectrum" do not a priori convey ANYTHING about the bandwidth to be used. We need to adopt the unemotional view that spreading the signal to match the relevant characteristics of the propagation medium is good, sound practice! What Phil and I discussed at CSVHFS was a spread spectrum scheme. It just happened to be only ~2 kHz wide.
Phil's discussion continues:
> The specific purpose of the CSVHFS paper was to outline an approach to
> a short-term demonstration of DSP-aided QRP EME that could work even
> with an existing narrowband transceiver, i.e., nothing wider than SSB.
> We did not imply, nor did we intend to imply, that it was the best
> possible signal design for the EME channel. The use of a narrowband
> transceiver severely constrained the coding and modulation methods
> that could be used; the whole EME problem would be *far* easier to
> solve were we able to use more than 2.7 KHz of bandwidth.
> In fact, Bob completely ignores the later part of the presentation
> where I show that the link budget for a pair of "regular" EME stations
> could support a ~300 bps user data rate, vs ~1bps for the Oscar-class
> station pair. However, simply scaling up the proposed 1bps modulation
> scheme (which alone would take ~64 KHz of spectrum) would probably not
> work because of the EME channel delay spread limits. Even more
> bandwidth (either to increase M in the modulation, or to perform true
> PN spreading) would be required to mitigate the intersymbol
> interference that the delay spread would otherwise cause.
73 de Tom, W3IWI ------ Submissions: firstname.lastname@example.org Subscription/removal requests: email@example.com Human list administrator: firstname.lastname@example.org