On 9/18/07, Dave Bernstein <[EMAIL PROTECTED]> wrote: > >>>AA6YQ comments below > 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. > > >>>That would be true if the trials were independent, but they are > not. For example, If the busy detector detects modulation on three > successive samples, then it can conclude that a QSO is in progress, > and set a substantially higher threshold for inactivity before > assuming the frequency is clear. One would not implement a busy > detector as a simple binary device that returns busy or not busy; its > a context-driven state machine.
Yes, a bounded-backoff mechanism would almost certainly be necessary. I would probably also choose to implement a detector that required the channel to appear "clear" for several sequential tests before initiating communication if this station had not been using this channel in the past few minutes. The problem is that too long of a "listen" window, or too long of a QSO-tail overshoot can *seriously* impact a station that has a large stack of traffic to pass, especially if each message is separated by a gap to allow other automated users to communicate with the same station. Of course, such a situation would result in high enough channel usage that it would be unlikely any human would honestly believe the frequency was free. Thus, I guess it's a non-issue. > > 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. > > >>>This would be a suboptimal design. Once a QSO is known to be in > progress on the frequency, the busy detector should not return "not > busy" based on a single modulation-free sample. At the first > modulation-free sample during a "QSO in progress" condition, the busy > detector might begin sampling every 15 seconds and only change state > to "not busy" after seeing, say, 3 minutes without any modulation on > the frequency. See the above response. I suspect that it would take much trial and error to actually pick numbers that work well, but I agree that such numbers could be picked. Actually, this is the case where IMO the automated station(s) should switch to another of the monitored frequencies. If you study the problemspace ALE is actually designed to solve, many ways of improving automated station operation in presence of busy-channel conditions make themselves obvious. No need to actually use ALE itself . That's a debate for another time, and other than compatibility with hardware ALE, I'm not convinced there is a reason to pick the ALE modulation and state machine. However, whether you use ALE waveforms or not, letting the "server" station scan multiple contact frequencies, and the "client" station try to initiate on a frequency that is idle (retrying on different frequencies in the list until successful) is just an obvious solution. > >>>Waiting 3 minutes for a QSO to clear doesn't seem like undue > suffering for a message-passing system --- except during emergency > conditions, during which the busy detector would be disabled. Unless the automated station actually "owns" the frequency (at least in emergency times), it would probably be a wise idea to merely reduce the listen window and shorten the maximum backoff time. The busy detector, if it works, is important to efficient shared-channel use between message-passing nodes, and there is also the issue that the "stepped upon" QSO might itself be life-and-safety traffic. > > > 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". > > >>>A "universal QRL" signal would allow busy detectors to be less > conservative -- if an automated station's transmitter was given a > premature go-ahead, one of the participants in the QRM'd QSO could > send QRL (just as happens today between attended stations), which the > automated station would instantly respect. An alternate way of doing this: When initiating traffic on a channel that the busy detector said was free, make the automated (or human/automated) station merely initiate its traffic with a "this channel in use?" canned emission in some standard modulation (synthetic/recorded SSB, 5 or 10 wpm morse etc) and wait some short period listening for *ANY* detectable signal. The "we're here, go away" signal should be at least 10 seconds long, so the detector can avoid noise-triggering. Assuming no signal detected, the automated (or human/automated) station initiates its traffic and the frequency is now in use. Advantage: Whistling into a SSB mic, keying a CW transmitter, transmitting anything on most other common protocols would be enough to busy-flag the transmission. No need for the humans to do anything "special". No complaints about not wanting to have to reconfigure to send CW, etc. Just make sure you immediately transmit whatever mode you're currently set up to transmit. Random offtopic comment: There's no reason why the ALE sounding and linking state-machine couldn't be implemented using pretty much any modulation, assuming you rescaled the appropriate timeouts and such... -- Regards, Robert Thompson
