This is not wishful thinking, Jose. An effective multimode busy
frequency detector was deployed in the SCAMP project more than a year
ago. Despite being a first iteration, its busy frequency detector
exceeded all expectations. SCAMP was a soundcard-based
implementation.
When attacking such a problem, one must keep in mind that perfect is
the enemy of good. A busy frequency detector that reliably detects
PSK31, CW, RTTY, and Pactor but is blind to Olivia and Domino would
be far better than no busy frequency detector. Such a detector would
be expected to evolve and improve over time -- taking advantage of
operational experience and increases in available CPU cycles. And
yes, busy frequency detectors would have to cover new modes as they
are developed -- as do the applications that decode and encode them.
73,
Dave, AA6YQ
--- In [email protected], "Jose A. Amador" <[EMAIL PROTECTED]>
wrote:
>
>
> David Michael Gaytko // WD4KPD wrote:
>
> > Your point was "QRM is inevitable -- live with it".
> >
> > My point is "QRM from unattended stations is preventable; stop
making
> > excuses and fix it".
> >
> > david/wd4kpd
>
> The point is: How?
>
> The workings of HF links have been explained here, and the
assymetric
> cases (to identify them somehow)
> you hear me but I don't hear you DO HAPPEN, by an uncoutable
number of
> reasons (QRO vs QRP, propagation assymetries, etc)
>
> So far, the software multimode squelch is still wishful thinking,
as far
> as I know.
>
> How many modes are you going to identify?
>
> It is the same case as an antivirus, it fails when a new virus
appears...
>
> A extreme case is that it might identify thunder as an oldtimer
> operating in spark...
>
> Jose, CO2JA
>
