+++More AA6YQ comments below
--- In digitalradio@yahoogroups.com, "Robert Thompson"
<[EMAIL PROTECTED]> wrote:
>
> On 9/17/07, Dave Bernstein <[EMAIL PROTECTED]> wrote:
>>> Two years ago, SCAMP demonstrated a multi-mode busy detector for
HF that proved highly effective, despite the fact that it was a
quickand dirty first attempt.
>snip<
Has this been widely tested by third parties on a large number of
differing HF channel conditions?
+++There was a beta test in which many operators participated;
everyone, including SCAMP's developer, was surprised by its
effectiveness and relative freedom from false positives. I don't
think the test ran long enough to claim that a large number of
differing HF channel conditions were encountered. This was a quick-
and-dirty attempt that could undoubtedly be improved with focused
effort.
The hard part isn't the *busy* channel detection, it's the *clear*
channel detection. As long as *clear* channel detection (Clear to
Send) generates so many missed transmission opportunities, people
will disable it. After all, it's the one change that will
dramatically improve their message delivery throughput, so barring a
gun to the head, why would they *not* disable it?
+++For the same reason that most of us don't run with 10 KW output
power or 10 kHz of bandwidth on HF -- because it would be a violation
of both amateur radio regulations and operating practice. We should
not allow our equipment to transmit over top an existing QSO if its
possible to prevent it.
>>> We do not need a busy detector that is guaranteed to detect all
possible modulations under all circumstances.
>snip<
Actually your statistics are misleading. The detector isn't rolling
the dice once for the QSO, it's rolling the dice once, coming
up "Busy", holding off n seconds, rolling the dice again, coming
up "Busy", etc... four of five (forty or fifty, whatever) events
later, it comes up (falsely) "Clear" and *then* steps on the QSO.
Think "Russian Roulette", not "Busy signal"... =) Especially since,
if the unattended station is doing a stream protocl, it's not going
to stop transmitting for some time.
+++There are two important characteristics of a busy frequency
detector: its success rate (the fraction of truly busy frequency
conditions that are correctly identified) and its false positive rate
(the fraction of truly not-busy frequency conditions that are
incorrectly identified). I suggested that a busy frequency detector
with an 80% success rate would reduce QRM to ongoing QSOs by a factor
of 5; you say this statistic is misleading, but offer no explanation;
please elaborate.
+++There is clearly a tradeoff between a busy frequency detector's
success rate and its false positive rate. That's one reason I'm
assuming an 80% success rate -- to permit a reasonably low false
positive rate.
In practice, 80% is often achievable, and works well enough in the
packetized world. Worst that happens if a conversation gets stepped
on is that the other party either detects the collision and retries or
times out and retries. There are tricks with sliding ack windows and
multi-ack responses to even avoid the sudden drop in throughput, but
this doesn't work well on stream-oriented (especially not
ear-in-the-loop) communication.
+++Agreed.
73,
Dave, AA6YQ
