>>>>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
