Just a few thoughts: * A busy detector is not a panacea for all qrm, especially as you look at the lower bands. I can easily lay out a scenario for 80 meters or daytime on 40m where the PMBO should transmit when the freq is busy. This scenario happens less as you expand the skip zones on the higher bands. But it needs to be included.
* The possibility of "killing" a system like winlink needs to be assessed also. This could be done by folks qrming it with periodic transmissions. * One of the big problems with pactor is its proclivity to expand its bandwidth regardless of who is operating close to the frequency. You can hear a 5 minute session at 500 Hz in p2, figure you can start up a psk31 qso as far away as 500 Hz, and ZAP, the pactor session moves to p3 and wipes you out. To prevent this, any new protocol needs to have a process built in that it will never expand once a session is set up. Going more narrow is no problem, but once done, you can't go back to a wider bandwidth. Pactor was designed to work in a commercial channelized system not a shared frequency system. It was set up so that once you claimed a channel, what you do with it is up to you. This just doesn't work in a shared freq environment like amateur radio. * While busy detection may help, it won't be a total solution. The FCC had a big process a couple of years ago on Cognitive Radio utilizing Software Defined Radios. The best minds in the business couldn't come up with an adequate solution that could be applied in just a transmitter that would prevent interference. The 'hidden' transmitter problem would still occur. * A new protocol really needs to utilize some kind of "control link" and/or stacking of client requests so that a single frequency can handle multiple requests on a queued basis. This will prevent the need for horizontal frequency spreading of servers (PMBO's) and achieve mazimum spectrum efficiency. * The protocol needs to be general in scope, like AX25, and not tied to just one operating system. Someone mentioned in another message here that it should work on Windows. The protocol should NOT be tied to anything Windows specific. It should be implementable on windows, linux. mac, etc. or even in a TNC like box. The software that uses it can then be written on whatever system the programmer so chooses. Thanks for the bandwidth. I had some other thoughts too, but these are the most important. Jim WA0LYK --- In digitalradio@yahoogroups.com, list email filter <[EMAIL PROTECTED]> wrote: > > Folks, > > I really don't know if I am failing to understand the problem, or > underestimating the complexity of the solution, but I'd like to propose > at least a dialog here of what it would take to implement a busy > frequency detector. I'm not at all interested in discussing systems > that may or may not use such a detector, or the politics / etc. > involved. I am interested in at least defining the process of how a > busy frequency detector should work, and defining some base requirements > for how well it would need to work to be considered 'adequate' for use > in amateur radio. > > My idea is to first define what the system should do, then define how > well it would have to work to be considered successful or useful, and > finally to consider the technical details required to implement such a > system. > > To that end, the following to which I am inviting comments from this > group, is my first pass at defining what a busy frequency detector > should do (please hold comments on how well it would have to work, and > how to implement it for follow-up threads, for now lets focus on getting > the process definition refined): > ""snip"" > > So what do you folks think, is this a reasonable process for an rf based > client / server busy frequency detection system? > > 73, > > Erik > N7HMS > > PS. Everyone knows a software project will never be successful without a > catchy acronym or code name... if this ever becomes a real software > product / project, lets NOT use the acronym BFD! >
