On Oct 19, 2013, at 8:47 AM, Peter Laws wrote:
> I share your concern about turning all HF digital bands over to
> SailMail, but we need to be ready with counter-arguments as well.
Peter,
You and Ron are both right with you assessment that if we are lumped together
SailMail and other nefarious uses of the ham bands (such as encrypted data),
then we are open to rendering the bands unpleasant for us (and for that matter,
for them too).
You are further correct that the counter argument is that good coordination can
mitigate the problem. But we need not just symbol rate to segregate the
stations that can QRM one another, we also need a band plan to keep SailMail
from RTTY ragchews. So we are back to having to enforce band plans anyway.
Lets see if I can explain why classifying sub bands by symbol rate is a
horrible idea.... (sorry that this is going to get long).
The problem with using symbol rate is that a "symbol" can be anything. A
symbol is typically defined as any discrete change in the transmitter waveform.
http://en.wikipedia.org/wiki/Symbol_rate
In the case of something simple like RTTY, a symbol is simply one bit of data.
When you switch from Mark to Space, you transmit two different waveforms.
In the case of MFSK16, as an illustration, the modulation consists of one of 16
tones (compared to one out of 2 ones for RTTY). I.e., known in the literature
as 16-FSK. Each symbol now can encode 4 bits of data (2 to the power of 4 is
equal to 16). For the same symbol rate (or baud rate), the bit rate of MFSK16
is now 4 times faster.
Again, taking MFSK16 as the example, what has just happened? How did we get
this 4x bump in bit rate?
Well, by using more bandwidth of course. I now have 16 tones to transmit and I
need to space them out in frequency. The minimum bandwidth for an 16-FSK
signal is 16 times wider than the minimum bandwidth for a 2-FSK signal (I am
not saying MFSK16 is 16 times wider than RTTY -- it is not so because RTTY's
shift is much wider than it could be; but it RTTY is so to take advantage of
ATC circuits during selective fading).
So what is there to stop you or I from using 256 tones and use up 11 kHz, and
still be defined as a 45 baud signal -- nothing whatsoever. This will make
SailMail people really happy since their effective bit rate is now 360 bits per
second instead of 45 bits per second.
That of course will still not satisfy anyone using the ham bands for email (and
hiding behind the curtain of "but I can use it for emergencies").
And this where multi-carrier techniques such as OFDM comes in. Unlike m-FSK
which only has one tone on at any one time, you can transmit any number of
carriers, up to m. With 256 carriers, you can now have a bit rate of over 200
times that comes from a steam RTTY signal -- *at the same symbol rate*!
This is not the melodic Olivia signal we hear, but a wideband buzz that you
hear from the Pactor III stations. To a carrier base system, it is no
different from noise. And, I can design such systems that are 2 kHz wide and
still be classified as 45 baud (with DSP and good soundcards, you can do
anything).
OFDM is a IMD nightmare by the way. Unless you have very clean transmitters,
an OFDM signal will spread even wider. Very few hams have the knowledge to
build transmitters than is that clean -- you will need to use predistortion
with DUC type SDR transmitters.)
So, just be aware of what is being discussed... by classifying transmission by
symbol rate, we are no longer limiting the bandwidth of the transmissions. A
symbol rate of 45.45 sec^-1 can be 10 kHz wide if I want it to be, or it can be
100 kHz wide, if the rules permit it.
So, to make ham bands livable, we need to police (by rule, or by amateurs
policing it themselves) subbands that are related to occupied bandwidths of
signals anyway. No different from today.
So, is this Symbol Rate proposal a Trojan Horse for something more insidious?
I cannot decide that for you -- I can only explain, as I did above, the fact
that a symbol rate limit is not the same as a bandwidth limit.
73
Chen, W7AY
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|