RTTY
[Top] [All Lists]

Re: [RTTY] ARRL Bandwidth Proposal - FCC Invites Comments

To: <rtty@contesting.com>
Subject: Re: [RTTY] ARRL Bandwidth Proposal - FCC Invites Comments
From: "George Henry" <ka3hsw@earthlink.net>
Date: Sat, 14 Jan 2006 11:54:15 -0600
List-post: <mailto:rtty@contesting.com>
----- Original Message ----- 
From: "Joe Subich" <W4TV@subich.com>
To: "'George Henry'" <ka3hsw@earthlink.net>; <rtty@contesting.com>
Sent: Saturday, January 14, 2006 12:24 AM
Subject: RE: [RTTY] ARRL Bandwidth Proposal - FCC Invites Comments



> #1 is currently permitted under 97.221 which regularly causes
> significant interference to QSOs in progress, particularly in
> areas currently used for PSK.  Expanding those permissions to
> wideband digital modes will only make matters significantly
> worse.
>

Okay, to play devil's advocate:  just WHAT would you have the software 
listen for, to determine that a frequency is in use?  I'm no software 
engineer either, but it doesn't take one to figure out that you're looking 
at crippling the functionality of the program with too simple an algorithm, 
and making it terribly bloated (& expensive), and possibly still crippling 
its functionality, if you cover ALL the possible bases.

The only reasonable solution that I can see is to relegate semi-automatic 
operation to a small set of discrete frequencies, like the beacon system, 
and we all steer clear of them.  There needs to be at least this one 
exception to regulation-by-bandwidth.  That will go in my comments to the 
FCC.


> #2 only requires published protocols and codes it does not
> require that functional software be freely available in order
> to permit any amateur who wishes to do so to monitor
> communications in order to resolve the source of interference
> or engage in self(-peer)-policing activities.
>
> An Amateur should not be required to be a software engineer
> and own a shelf full of compilers, debuggers and other development
> resources.
>

Nor should any software developer be required to give away the fruits of 
their labor for free:  that would have a very chilling effect on software 
development.  The FCC will  never agree to that, nor should they - that's 
entirely outside their authority.  (Unless, of course, the Commission is 
going to write the decoding software & give it away...  yeah, right!)

> There have been two bedrock principles of Amateur Radio service
> for more than 80 years ... first, make sure that a frequency is
> not in use before transmitting and
>

Listen-before-you-transmit will never be perfect:  there will ALWAYS be 
cases where a 3rd party cannot hear the others on frequency.  It happens 
under LOCAL control, every day in every mode, even on FM repeaters, thanks 
to odd splits and PL!  (You should hear it on SSTV and the satellites!)  The 
only way around it with semi-automatic operation is as I pointed out above: 
semi-automatic stations should be restricted to operation on discrete 
frequencies so that users of other modes can avoid them.  So let's all 
propose that in our comments.

> second no transmission is
> encrypted or obscured in any way.

Sorry, that one's not gonna fly:   97.113(a)(4) prohibits transmissions 
"...in codes or ciphers INTENDED TO OBSCURE the meaning thereof..." 
(emphasis mine).  That's quite different than how you are attempting to 
apply it.  Lack of software to decode a transmission on your end doesn't 
equal intent to obscure on the sender's part........  In reality, the only 
people who could legitimately claim to NEED the decoding software would be a 
repeater operator whose machine is being used to relay digital 
transmissions, and the FCC itself.


73 de KA3HSW

_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty

<Prev in Thread] Current Thread [Next in Thread>