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?) > > > 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. 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? 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. > > 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) And it's not rarely a problem in attended modes, I see it daily on PSK. > > 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. Have fun, Alan km4ba
