+++ AA6YQ comments below
-----Original Message-----
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Alan Barrow
Sent: Tuesday, November 24, 2009 10:30 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Digital busy detect
Dave AA6YQ wrote:
>
> Its only unworkable because the implementation of the busy frequency
> detector in question is obviously quite poor.
Significantly more to it than that... unless *all* stations honor &
abide by common rules/tech, it simply won't work. This is true of just
about any network, not just radio. (remember the FRACK wars back in
packet days?)
+++The rules to be honored by all stations are:
1. if you're not yet in QSO, don't transmit on a frequency that is already
in use (meaning that signals have been detected during the past 5 minutes)
2. if you're in QSO and signal other than that of your QSO partner appears
(the busy frequency detector indicates the presence of signal, but you
aren't decoding your QSO partner), wait for that signal to disappear, send
"QRL QRL" in CW, and resume your QSO
+++There is nothing complicated about this. Automation is only required in
unattended automatic stations.
> No, an automatic station already in QSO need only respond with "QRL"
> in CW, which will be understood by the majority of attended stations.
With full respect: "Yeah, right" :-) You want me to hold off my
transmissions automatically, but trust other ops (in other modes) to do
the same. Voluntarily. Cross-mode. Right.
+++Amateur radio operators have been trusting each other to mutually obey
these rules since the service began. On what possible basis can you claim
exemption?
Kindof like asking all cellphone users to install a device that allows
anyone to disable their ringtone. Just what do you think the compliance
on that would be?
+++No, its not remotely like asking cellphone users to install such a
device; there is no parallel whatsoever.
I agree CW QRL is probably the most universal approach, but you'd have
to match the exact beat frequency of the cw sig for them to hear it. And
be able to decode CW on the fly (CWget in all busy detectors) to honor
it from others.
+++Only attended stations need detect the QRL; if automatic stations never
transmit on a frequency that is in use, then they will rarely QRM an ongoing
QSO, and so have no need of automatic QRL detection.
>
> This is rarely problem with attended stations; you might not hear one
> side of an in-progress QSO, but you will hear the other side, and be
> able to respond appropriately when the side you hear asks you to QSY.
> Only automated stations without busy frequency detectors suffer the
> vulnerability you describe here.
Only true if you listen for 1-2X the average transmission length or do a
"?" query. Voice ops do that, because it's not cross mode, and
transmission times are shorter.
Digi modes do not do that by practice (even RTTY), the transmission
times are longer, and the price of an interuptted transmission higher.
(resend)
+++When not in QSO, automatic stations can easily monitor the frequency to
determine whether a QSO is in progress, even if they are only hearing one of
the stations involved; this is easily implemented. If an automatic station
receives a connection request and its busy frequency detector has seen no
activity for the past 5 minutes, it can respond to the request without
compunction. If its busy frequency detector has been intermittently
reporting signals over the past 5 minutes, it should not respond.
And it's not rarely a problem in attended modes, I see it daily on PSK.
+++I didn't say it rarely occurs, I said its rarely a problem -- because
attended stations can communicate with each other and resolve the conflict,
thereby preserving the QSO in progress. Unattended automatic stations are
incapable of doing this.
>
> Effective multi-mode busy frequency detection has been demonstrably
> feasible for years. Had a concerted effort been made to equip all
> automatic stations with competent busy frequency detectors, the rate
> of "QSO breakage" caused by such stations would have plummeted, the
> anger caused by this QSO breakage would have dissapated, and we'd be
> efficiently sharing spectrum in the pursuit of our diverse
> objectives. Instead, we've been treated to years of blatantly lame
> excuses as to why busy frequency detection either can't be designed,
> can't be implemented, can't be deployed, won't work, causes warts,
> causes cancer, causes global warming, or will cause the universe to
> expand forever. Few are fooled by this.
OK, here's the challenge: Demonstrate it's feasibility if it's JSMOP.
Implement one that balances the right of the sending station not to be
QRM'd VS the expectation not to QRM. Publish an API & a spec (turnaround
times, etc). IE: Not a passive (hold off) detector
Make it open source so that all coders can leverage & refine it. Windows
assumption is OK, but we could probably find a lock/semaphore system
that is multiplatform. But a windows DLL & API would satisfy 90% of the
commonly used digi programs.
Will have to codify a standard that would allow any program to grab
soundcard resources (to monitor as well as send the qrl) along with any
cat/ptt required. Or maybe you let the digi program figure out how to
send CW QRL, that would be close enough.
Do so and I bet we could get the major coders (Certainly DXlab's coder)
to roll it in.
I'll commit to influencing the major ALE coders to try to integrate.
(Steve/Charles/Patrick)
We could get Simon on board. Rick is already mostly there. I won't
commit for CJX/winlink, as he's been burned by BD more than once.
RTTY will be more difficult, but will come with time. Lot's of legacy
users of mmtty!
Can't just be a passive (hold off) detector, needs to signal QRL and
honor QRL signals from others. Independent of your filter & that of the
other station. (IE: interfering CW op using 500hz filter, you'll have to
match his freq pretty darn close)
Meanwhile, I'll be in the 7102 bedlam with the rest of the users.
>>>Rick KN6KB is already on the second iteration of his busy frequency
detector; there is no need to re-invent this wheel. No changes are required
to MMTTY, WinWarbler, DM-780, MixW, Digipan, FLdigi, or MultiPSK, as these
are exclusively used in attended operation. Only applications that manage
unattended automatic stations require modification -- specifically, the
implementation of the two rules described above.
>>>There are steps we could take to accelerate the dissipation of anger over
past practices once most automatic stations are implementing the above
rules; this would minimize intentional QRM aimed at triggering busy
frequency detectors. I would be happy to drive this effort.
73,
Dave, AA6YQ
