[RTTY] ARRL Symbol rate proposal

Sat Oct 19 15:52:40 EDT 2013

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 at 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 at contesting.com
> http://lists.contesting.com/mailman/listinfo/rtty
>
_______________________________________________
RTTY mailing list
RTTY at 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