Either way, it was clear that it was bad policy and the Commission
was not going to adopt it after it languished without action for
an extended period of time.
73,
... Joe, W4TV
On 10/19/2013 3:52 PM, Dave AA6YQ wrote:
The FCC did not reject the ARRL's "Regulation by Bandwidth" proposal; the ARRL
retracted its proposal before any decision was
rendered.
73,
Dave, AA6YQ
-----Original Message-----
From: RTTY [mailto:rtty-bounces@contesting.com] On Behalf Of Joe Subich, W4TV
Sent: Saturday, October 19, 2013 3:07 PM
To: Kok Chen; RTTY Reflector
Cc: Peter Laws; Ron Kolarik
Subject: Re: [RTTY] ARRL Symbol rate proposal
> 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.
Although this thread is titled "ARRL Symbol rate proposal" the actual
ARRL proposal is to eliminate symbol rate limits in favor of a 2.8 KHz
"occupied bandwidth" standard. In other words, this is just another
attempt to accomplish through the back door what they failed to
accomplish a few years a go in their "regulation by bandwidth" proposal.
Perhaps one of the key response points is that the Commission already
*rejected* 2.8 KHz wide digital modes when they (wisely) rejected the
regulation by bandwidth proposal. In other words, there is absolutely
*no justification* for any digital data mode to occupy more than 500 Hz
or for digital voice to occupy more that about 1500 Hz. Both are well
within the current state of the art and there is no need for higher
data transmission rates *in the amateur service* on MF and HF bands.
73,
... Joe, W4TV
On 10/19/2013 12:52 PM, Kok Chen wrote:
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
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1432 / Virus Database: 3222/6264 - Release Date: 10/19/13
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|