[RTTY] ARRL Symbol rate proposal

[Kok Chen]

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