>>>AA6YQ comments below
--- In digitalradio@yahoogroups.com, "jgorman01" <[EMAIL PROTECTED]> wrote:
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.
>>>Please describe the scenario that would justify transmitting on a
busy frequency during non-emergency conditions
* The possibility of "killing" a system like winlink needs to be
assessed also. This could be done by folks qrming it with periodic
transmissions.
>>>Busy detection should be disabled during emergency conditions. If
someone builds an automatic station capable of QRMing WinLink 24x7,
it will be easy to track down.
* 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.
>>>Agreed, though expansion would be okay if one first verified that
the expanded frequency range was not busy. Instead of simply
expanding, the station must first acquire the expanded bandwidth (by
verifying it to be clear).
* 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.
>>>Perfect is the enemy of good, etc. SCAMP has already demonstrated
that a first iteration implemented two years ago would have a huge
positive impact if deployed today.
* 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.
>>>In the current situation, "divide and conquer" is a better
strategy than "boil the ocean". Lets make a big dent in the QRM
problem first; we can then use that momentum to address other
opportunities, like improved 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.
>>>I agree with these points, but lets not overreach. Step by step...
73,
Dave, AA6YQ
