On 9/17/07, Dave Bernstein <[EMAIL PROTECTED]> wrote: > +++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. >
I would *love* to see either code or a large-scale test, including prearranged intentional usage on a busy channel. If both false positive rate and false negative rate are good enough, this could easily be the way forward for many different projects. > 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. This is only true if both parties respect the other party's rights and trust the other party to reciprocate. In general, non-automated users resent the automated stations and often regrettably attempt to interfere. Given this fact, the automated station operators are often unwilling to enable features that can be used by others to destroy the automatic stations' functionality. Note that I am not saying this *should* happen, but that given human nature, it *does*. > >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. The problem is that a one-shot accuracy of 80% is trivially achievable, but real use isn't one-shot. My probability-math reference is at home out of reach at the moment, so I can't just quote you the formula to determine the actual probability of failure given repeated one-shot attempts. The bottom line, however, isn't good. An example follows: There is an ongoing SSB QSO on a given frequency. The automated station begins listening for a couple of seconds, and (correctly) detects activity on the frequency. It initiates a hold-off for N seconds. N seconds pass. It listens again, and (correctly) detects activity, initiating another hold-off. This sequence repeats for a few times until statistics catch up with us and it (erroneously) detects a clear channel and begins transmitting. Thus, assuming an 80% success rate and a hold-off algorithm that is reasonably balanced for both avoiding interference *and* efficiently using a shared channel (5 seconds < N < 60 seconds), over the course of a ten minute QSO, the chance that the automatic station will interfere approaches unity. If you pick too big of an N, the automatic station wastes lots of time waiting on the channel to clear. If you pick too small of an N, your busy detector's error rate increases the chance of a failure. In either case, one party suffers unduly. This is ignoring that in the above SSB case, even a continuous detector is going to misdetect periods of silence or other reduced modulation as "channel now empty". > > +++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. > > I'm only arguing that the one-shot success rate needs to be much greater than 80% to result in ruining only one out of 5 QSOs on frequency. On the wider discussion of automated stations and non-automated stations sharing spectrum, I suspect that the way forward will actually involve changes on both sides. An example: If the initiating member of the automatic conversation would, after the busy detector says the frequency is clear, use some standard modulation to ask "Is this frequency clear", listen for say 30 seconds, and if the busy frequency detector trips during this time, move onto an alternate frequency. Note that the automatic station only needs to do this when it hasn't been using the frequency for long enough that the frequency looks clear to some other party. Also note that the automatic station does not need to be able to decode any answer, it just needs to watch for a transmission. Combine this with listen-scanning on several alternate frequencies and both automated and non-automated stations could share the spectrum. Of course, the human QSO partners would need to tolerate occasional automated channel query messages, but it at least gives them a way to tell the automated stations to move frequency.
