Dave AA6YQ wrote: > > > +++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 OK so far
> > +++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? > Here's where it falls apart..... many, many digi ops neither copy CW even to understand QRL, or would not hear it. And another large percentage would not honor a QRL request, they don't in other situations for sure. > 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'd be OK if all mfg's had such a device. But to selectively enforce it is unworkable. IE: Multipsk, others should have similar detect & honor a QRL request. Recioprocity is part of being a good neighbor. > > > +++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 does not deal with hidden terminal, nor does it address the cases where attended mode ops interfere with non-attended > . > > +++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. Unworkable on most auto sub-bands, there is just that much traffic. If you held off 5 minutes for many parts of the day you'd never, ever be able transmit. Again, unequal standard, do CW/RTTY ops wait 5 minutes? They sure don't when interfering with 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. > While voice ops do tend to honor this if "enforced", there are many, many cases where they do not. Net's being one, and ops with unequal power being another. The world is not as clean as you allude. Regarding your monitoring test with Pactor- clear "selection bias" (Google it).... you could not hear the cases of interference that you claim do not exist. > > >>>Rick KN6KB is already on the second iteration of his busy frequency > detector; there is no need to re-invent this wheel. May be a wonderful thing, but does not address the need to be able to be leveraged by other programs. You propose a technical solution is not that hard. I asked for one, committed test & deploy it. That would be a big win. Simple DLL, common standard. All major digi programs to implement & honor it. Not just modes which you do not care for. Since we all hope winmor will be a leveragable DLL, it would be great if it's busy detector was also leveragable by other modes. > 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. I respectfully disagree, as users of these programs interfere (perhaps unintentionally) with each other and auto stations all the time. If it's such an easy problem to solve, we should apply equal standard. Likewise, some of these programs are capable of auto-respond, or are heading in that direction. (RSID selcall work, etc) > > >>>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. As mentioned previously: Propose a standard, build/test a reference implementation, release some code, work with the various coders to integrate. Though I normally don't agree with guillotine moderation, in this case I think we've reached impasse. Have fun, Alan km4ba
