>>>>AA6YQ comments below --- In digitalradio@yahoogroups.com, "Robert Thompson" <[EMAIL PROTECTED]> wrote:
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. >>>Agreed 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. >>>Yes, that makes perfect sense. The client station's software could make this all transparent to the end user. 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. >>>As you say above, it will take some time to tune this properly. The tuning might actually be an adaptive procedure implemented by the software based on conditions. > 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. >>>Yes, that would work well. >>>We seem to be on the same wavelength here... 73, Dave, AA6QY