The acid test for a busy detector is not an assessment by its
developer or deployer, but rather the assessment by those who share
frequencies with it.
The point is that anyone who develops an automatic protocol for use
on the amateur bands is irresponsible if they fail to provide an
effective busy frequency detector.
73,
Dave, AA6YQ
--- In [email protected], "expeditionradio"
<[EMAIL PROTECTED]> wrote:
>
> Automatic channel busy detection has been standard in ALE
transceivers
> for many years. These are transceivers that have ALE embedded in the
> microprocessor inside the radio, and they don't need an external
> computer.
>
> As an example, my Icom IC-F7000 HF ALE transceiver has a very good
> busy detector in it.
>
> PCALE software also has a good busy detector. Sometimes it is a
little
> too good, because it sometimes prevents transmissions in conditions
> that the operator considers to be a relatively clear channel.
> Lightning static often causes "false busy" errors.
>
> ALE busy detection in ALE transceivers has various trade names, such
> as "Voice Detector" or "Polite Mode" or "Channel Busy". The "Voice
> Detectors" also detect constant carriers, on-off carriers, or FSK
> carriers. ALE transceivers are designed to work best with the common
> methods of HF communication found on normal HF comms over the past
20
> years, such as FSK, Carriers, CW, and Voice. They work very well for
> enabling a compatible system on the same channel as SSB voice
> transmissions, or in combination with transceivers that have
syllabic
> voice squelch or ALE selective calling enabled speakers.
>
> Accurate detection of a busy channel becomes more difficult with
more
> recent types of signals such as constant OFDM and various other
> noise-like signals, or constant pseudo random signals that are wider
> than the standard SSB channel.
>
> Also, the time interval for busy detection can be a big factor on
> whether it is possible to use it or not. If the busy checking wait
> time is too long, then the ability to scan and enable fast linking
or
> ARQ communications can be reduced to the point of total
uselessness.
>
> In a perfect world, a busy detector system would be selected for
> specific types of channel traffic, and the different flavors of busy
> detector could be used with different kinds of signals that would be
> most likely found. If the traffic includes all types of signals in
the
> world, the balance between the ability to distinguish between valid
> and non-valid clear channels may result in an impractical solution
> that voids the purpose of busy detection entirely, or presents a
weak
> decision point.
>
> From my experience over the past several years using various busy
> detectors for ALE in the HF ham bands, I find that the vagaries of
> common busy channel detection as found in the ALE systems seem to be
> perfectly acceptable for use in the auto sub-bands where time-
sharing
> and ARQ predominates, especially to enable the use of short auto ID
> transmissions (soundings). It is also quite acceptable for auto
> responses to operator-initiated selective calling in other parts of
> the HF bands. In all of these cases, the transmission duration is
less
> than 30 seconds out of every hour, so even if there is an error in
> positive busy detection, due to hidden transmitter effect, the
> duration of the error is mitigated by the fact that the interruption
> in ongoing communications is a very very short period of time in the
> larger scheme of things.
>
> Bonnie KQ6XA
>
