Pactor is not the problem. Unattended stations without busy detectors
are the problem -- whether they're operating in Pactor, PSK, RTTY, or
CW.
73,
Dave, AA6YQ
--- In digitalradio@yahoogroups.com, "Andrew O'Brien"
<[EMAIL PROTECTED]> wrote:
>
> but Bonnie, a fundamental issue has been the frustration with
PACTOR just
> switching on mid-stream and interfering with a QSO. Other than
under
> contesting conditions, it rarely happens with other modes. Would
not it be
> fairly easy for programmers to build in a variable parameter that
allows the
> user to set a signal to noise ratio and a waterfall bandwidth. If
the
> software detects a signal above the specified SNR within the
specified
> bandwidth, the software refused to xmit? A "off" setting could be
used
> when emergencies exists. For example MixW and PC-ALE both have a
pseudo way
> of measuring SNR.
>
> Andy.
>
> On 9/16/07, expeditionradio <[EMAIL PROTECTED]> wrote:
> >
> > There are down sides to busy-detection:
> >
> > 1. There is no way to know the relative interference temperature
> > threshold for distant co-channel users on HF. SNR at every
station is
> > different. A signal that seems in the background at one location,
for
> > one mode, may be interference to another mode working at a
different
> > SNR or a different mode at another station.
> >
> > 2. What to detect? How sensitive? It is possible to engineer a
> > busy-detector that can be set for a very sensitive threshold, and
> > detect almost any mode or almost any level. That same detector
will
> > also falsely show a busy channel most of the time on the HF ham
bands.
> > That renders the busy-detector useless for the busy-detector user
who
> > wants to have a QSO or send an important message.
> >
> > 3. When does the receiving station with busy-detection know
whether
> > the content of such an incoming message is an emergency? A
> > too-sensitive busy detector might prevent such a message from
being
> > run in the first place, and the result would not be good. Thus,
> > stations that are on the air specifically with a very likely
possible
> > purpose of running emergency traffic should probably not use a
> > busy-detector. It is possible to envision a busy-detector that
could
> > be programmed to remotely disengage upon reception of a specific
> > command... but such a system is not readily available at the
present
> > time, and the use of it would certainly unnecessarily complicate
the
> > sending of an emergency message at a critical time.
> >
> > 4. It may be counter-productive for networks or users to announce
what
> > type of busy-detection they use or don't use, because this sort of
> > information can be used nefariously (has been and will be) by
> > individuals on purpose to maliciously interfere or thwart normal
> > operation.
> >
> > 5. We all know that there are many feuds and grudges out there on
the
> > air. It seems that certain hams who are most prone to carrying on
> > feuds or grudge-matches may also be the same individuals who
clamor
> > most loudly for busy-detectors to be put in place by
their "enemy" :)
> >
> > Bonnie KQ6XA
> >
> >
> >
>
>
>
> --
> Andy K3UK
> www.obriensweb.com
> (QSL via N2RJ)
>
