>>>AA6YQ comments below
-----Original Message-----
From: digitalradio@yahoogroups.com
[mailto:digitalra...@yahoogroups.com]on Behalf Of Alan Barrow
Sent: Tuesday, November 24, 2009 9:57 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Digital busy detect- it's not a technology
issue
Andy obrien wrote:
>
>
> FYI, the author of Winmor advised me that 3rd party busy detect IS part of
Winmor.
so what does it do when it's already involved in a qso, waiting to ack or
transmit, and someone starts transmitting? That's the core issue, not
detecting that a frequency is in use.
Not many options, it can:
A) backoff, and effectively abandon the frequency to the new station, even
though they are the one who QRM'd
>>>There is no reason to do this, presuming that the frequency was clear
before your QSO began
B) Try to signal the interfering station in the mode
(cw/rtty/clover/ax.25/psk/etc) that the station is using.... hmm, but that
assumes the station is listening, so you have to wait for that station to
stop, and try to get a break in. Meanwhile, your sending station you were
originally in qso with has timed out!
>>>Wait until the "offending" signal dissappears, send "QRL QRL" in CW, and
either initiate reconnection or await connection as dictated by the
protocol.
C) Go ahead and transmit anyway, since it was in qso already. Which will
still generate complaints, as most of the perceived qrm is really hidden
terminal issues and unintentional
>>>No, most of the perceived QRM is not the result of attended stations
breaking in on an on-going QSO in which one of the stations is automatic.
Several years ago, I monitored WinLink PMBOs with my SCS PTC-IIe. In every
case where QRM occured, it was the result of a PMBO responding to a
connection request on a frequency that was already in use.
For any of the busy detection schemes to work, all stations have to be using
it, and it would need to a universal "freq is in use" signal honored by all.
>>>No, only unattended automatic stations need include a busy frequency
detector. As suggested earlier, "QRL" is a universal "freq in use" signal
that will be honored by most attended stations. As long as an unattended
automatic station never initiates transmission on a frequency that is in
use, then it will rarely QRM an on-going QSO, and thus need not have the
means to detect a QRL sent by an attended station. The only collision
scenario that is not covered is "change in propagation", where two QSOs that
were initially sharing a frequency without interfering with each other begin
hearing each other because propagation has changed; if one of these QSOs
involves an unattended automatic station, it will by the above rules either
complete its QSO (if the QRM doesn't prevent it), or break off (if the QRM
impedes communication).
The only other alternative is for all stations/modes:
- Listen for 2X the average transmission length for the slowest mode
possibly in use on the frequency to eliminate the chance of hidden terminal.
- For most frequencies/modes, that would be CW or RTTY, so you are looking
at a listen period of a minute or more.
>>>When not in QSO, an automatic station monitors its frequency
continuously, so it very well knows whether or not another QSO is in
progress on that frequency, even if it can only copy one side of that QSO.
- Have some algorithm that factors in if you are in QSO vs just starting
a QSO
>>>Obviously.
My view: This is not a technology issue, it's an operator expectation issue.
we could have the miracle BD (busy detection) widget. But until ops in all
modes started respecting & listening for other modes, it won't work.
>>>The scheme described above is straightforward to implement and will
prevent QRM most of the time. As I pointed out to Rick KN6KB while
attempting to persuade him to implement a busy frequency detector in Scamp,
a scheme that's only 80% effective would reduce the incidence of QSOs broken
by automatic stations by a factor of 5.
Ex: The rtty guy in the middle of a qso has a cw op break in. He can't
answer in rtty, and his radio is in fsk or ssb mode. IE: He can't just send
CW to tell the interloper the freq is in use.
>>>Certainly he can; I have done so. This is easier in FSK where the
transceiver is displaying the mark frequency; digital mode apps could easily
be extended to automate this operation.
Same for RTTY/CW in psk. (even worse, due to the long psk transmissions).
Shift to ALE/Pactor, and it's even less likely that the op is setup for the
mode.
>>>Saving your PSK frequency, changing mode to CW, sending "QRL", and
returning to PSK is just not that difficult. It certainly beats losing your
PSK QSO.
So all that said, what are the odds that the homebrew cw op is going to have
have the miracle BD? The RTTY op?
>>>There is no reason for an attended station to have a busy frequency
detector; the operator's ears are generally sufficient. Only unattended
automatic stations require a busy frequency detector.
Ah, so we have the miracle BD send CW (universal) when someone starts
qrm'ing a transmission in progress. You just blew any chance of receiving
the data being sent by the station you are in qso with.
>>>Google "Automatic Repeat Request".
And what is that signal? And will majority of ops respect that? when less &
less hams even know CW?
>>>Learning a single CW Q-signal is hardly an impediment.
Remember, you are asking the newer modes to implement this, how will the
legacy modes do it?
>>>There are no legacy automatic modes.
Do you really expect winlink et al to implement a scheme that would allow
anyone to pre-empt (hold-off) their traffic, while not doing the same in
return?
>>>Isn't this presumption the basis on which we've shared spectrum since the
amateur radio service was born?
Again, when someone can show me a scheme that queries the freq prior to
usage on psk, I'll be convinced. Anything else is still subject to hidden
terminal interference, and will still generate complaints. IE: Solve the
problem for a legacy mode, and then we'll talk.
>>>Attended PSK stations should verify that the frequency is not in use
before transmitting; this is accomplised by monitoring the tuning display
for awhile before transmitting. No automation is required; the operator is
responsible for this action. Automatic PSK stations are no different than
automatic Pactor-3 or ALE stations -- they should include an effective busy
frequency detector.
I'd love to do peer review for such a scheme. We'll get the ARRL to send it
out as "best practices". Right. Don't mean to be negative, but it's far
more complex than JSMOP. (Just A Small Matter Of Programming)
>>>Its not complicated at all, though you're trying very hard to make it
seem complicated:
1. if not in QSO, don't transmit on a frequency that's already in use
2. if in QSO and a signal other than that of your QSO partner is detected,
wait for the intruding signal to end, and send "QRL QRL" in CW.
Meanwhile, I'll operate ALE & occasionally P3 in the auto sub-bands. And
bite my tongue when I am qrm'd by RTTY, CW, and other PSK ops in the PSK
sub-band.
>>>There is no excuse for your signals being intentionally QRM'd, but as
I've said before, the multi-year failure of WinLink and other unattended
automatic stations to curb their breakage of on-going QSOs has generated a
lot of anger; this won't end until the lame excuses are replaced by
competent busy frequency detectors.
73,
Dave, AA6YQ
------------------------------------
Suggested frequencies for calling CQ with experimental digital modes =
3584,10147, 14074 USB on your dial plus 1000Hz on waterfall.
Announce your digital presence via our Interactive Sked Pages at
http://www.obriensweb.com/sked
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/digitalradio/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/digitalradio/join
(Yahoo! ID required)
<*> To change settings via email:
digitalradio-dig...@yahoogroups.com
digitalradio-fullfeatu...@yahoogroups.com
<*> To unsubscribe from this group, send an email to:
digitalradio-unsubscr...@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
