The ARRL's proposal, if adopted, will allow the broad deployment of
semi-automatic operation without any requirement that semi-automatic
stations implement "listen before transmit". This is clearly a fatal
flaw. We must ensure that the FCC understands this flaw, and rejects
the ARRL proposal.
I acknowledge your points regarding the efficient use of spectrum,
but it would be far more difficult to build an open-and-shut case
against the ARRL proposal on these grounds. Thus I will continue to
focus my energy on highlighting the obvious and widely-acknowledged
problem.
Besides preventing the enactment of a very bad plan, defeating the
ARRL proposal will have another benefit: it will make clear to ARRL
leadership that successful development of a new allocation scheme
requires broad engagement with American amateurs, a previously
unthinkable process now made feasible by the internet and modern
collaboration tools. That will be the time to take up the difficult
issue of spectrum officiency.
73,
Dave, AA6YQ
--- In digitalradio@yahoogroups.com, Tim Gorman <[EMAIL PROTECTED]>
wrote:
>
> On Tuesday 24 January 2006 21:46, Dave Bernstein wrote:
> > I disagree, Tim. In your scenario, Busy Channel Detection works
> > perfectly: it prevents the automatic station in St. Louis from
> > QRM'ing the west coast QSOs.
> >
> > Busy Channel Detection is not a solution to
the "oversubscription"
> > problem, which will occur whether or not Busy Channel Detection
is
> > in place.
> >
> > 73,
> >
> > Dave, AA6YQ
> >
>
> Busy detection will work to keep the automatic station from
becoming a
> nuisance by actually blocking other QSO's due to interference.
>
> It doesn't add anything to the system for traffic load carrying
capacity. In
> fact, it can make things much, much worse. This contributes
negatively to the
> spectrum efficiency metric of "time denied to other users" by
greatly
> extending the amount of time that specific piece of spectrum is
tied up
> trying to carry the traffic load.
>
> It isn't an oversubscription problem, it is a system design
problem.
>
> If the system is loaded with calls that are staggered, for
instance, the busy
> detection scheme can actually prevent the system from answering
the first
> caller because it will hear the second one on the frequency. If a
third
> station then begins calling, or a fourth ad infinitum, you can
block the
> channel up to where nothing gets accomplished until the calling
stations all
> go away because of propagation or the control operators decide to
hang it up.
>
> If you prevent this from happening by killing the busy detection
once a
> session is started then you open the system back up to being a bad
neighbor
> because a session could be started while the hub couldn't hear the
second
> side of an ongoing QSO on the same frequency.
>
> If the system were to be designed based on well-known traffic
design rules,
> ways to either block calls or queue calls would be implemented.
This provides
> a way to smooth the offered load and greatly enhance the traffic
capacity of
> the channel.
>
> In fact, if you do a simple Erlang C analysis on the Winlink
system using a
> 30minute queue time, five 500hz channels on HF would have handled
all the
> Winlink traffic for the month of April, 2005. That's one 500hz
channel each
> on 80m, 40m, and 30m plus two 500hz channels on 20m.
>
> *THAT'S* what the FCC would say is a novel technical and
operational approach
> to mitigating interference on the amateur bands as well as
maximizing
> spectrum efficiency!
>
> Any new modes being developed for use with such traffic carrying
systems had
> better be looking into traffic control mechanisms as well as
channel busy
> detection. Otherwise you might just find the problems caused by
these systems
> become worse instead of better.
>
> tim ab0wr
>
Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org
Other areas of interest:
The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion)
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/digitalradio/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
