Re: [digitalradio] Busy Detectors

2007-09-17 Thread Jose A. Amador

In an animals meeting someone stated that the culprit was a
"big mouth animal"

...and then the frog and the alligator began blaming each other...
.
.
.
.
John Becker, WØJAB wrote:

> Not sure what mode "the mode" is but should it not be for
> all modes? 
> 
> Case in point - the other evening I was in QSO with a ham in 
> Dallas Texas keyboard to keyboard Pactor 3 on 7077.4 LSB
> when N4CE started calling CQ on HELL (for half an hour) .
> He was so strong here in the mid west that we last the link.
> I feel sure that he had no clue whatsoever who or even that
> it was a KB to KB QSO. 

It is more common than you would expect. It also has happened here
quite often when someone on SSB making a national QSO below 7100 kHz 
gets QRM
from someone in FL or LA starts a QSO with New York or Chicago on top of 
you.

Unless you plug your keyer ad say QRL  D I R E C T L Y, he will ignore
"that latino QRM". And then, not all QSY, either. In many bands, the FCC 
allocations and our allocations are different.

Conversely, I have been doing BBS forward in the past and some people 
have come to talk on SSB "over that cricket". Turning the linear on and 
overpowering them has been the only solution not to lose the link.

Disconsideration is more extended than what is generally believed, 
people on one mode ignoring the others.

> My point being it's just not "only" Pactor stations. In fact
> last week I have see more ALE stations and JT65A than
> anything else blasting away on a freq already in use.

Undoubtedly.

> John, W0JAB

73,

Jose, CO2JA




__

Participe en Universidad 2008.
11 al 15 de febrero del 2008.
Palacio de las Convenciones, Ciudad de la Habana, Cuba
http://www.universidad2008.cu


RE: [digitalradio] Busy Detectors

2007-09-17 Thread John Becker, WØJAB
Not sure what mode "the mode" is but should it not be for
all modes? 

Case in point - the other evening I was in QSO with a ham in 
Dallas Texas keyboard to keyboard Pactor 3 on 7077.4 LSB
when N4CE started calling CQ on HELL (for half an hour) .
He was so strong here in the mid west that we last the link.
I feel sure that he had no clue whatsoever who or even that
it was a KB to KB QSO. 

My point being it's just not "only" Pactor stations. In fact
last week I have see more ALE stations and JT65A then
anything else blasting away on a freq already in use.

John, W0JAB

At 07:15 AM 9/17/2007, you wrote:
>Exactly the reason the mode should be taken to some other band(s).
>
>73
>
>Bill KA8VIT




RE: [digitalradio] Busy Detectors

2007-09-17 Thread Box SisteenHundred

Exactly the reason the mode should be taken to some other band(s).

73

Bill KA8VIT


> To: digitalradio@yahoogroups.com
> From: [EMAIL PROTECTED]
> Date: Mon, 17 Sep 2007 00:52:07 +
> Subject: [digitalradio] Busy Detectors
> 
> There are down sides to busy-detection: 
> 
> 1. There is no way to know the relative interference temperature
> threshold for distant co-channel users on HF. SNR at every station is
> different. A signal that seems in the background at one location, for
> one mode, may be interference to another mode working at a different
> SNR or a different mode at another station. 
> 
> 2. What to detect? How sensitive? It is possible to engineer a
> busy-detector that can be set for a very sensitive threshold, and
> detect almost any mode or almost any level. That same detector will
> also falsely show a busy channel most of the time on the HF ham bands.
> That renders the busy-detector useless for the busy-detector user who
> wants to have a QSO or send an important message. 
> 
> 3. When does the receiving station with busy-detection know whether
> the content of such an incoming message is an emergency? A
> too-sensitive busy detector might prevent such a message from being
> run in the first place, and the result would not be good. Thus,
> stations that are on the air specifically with a very likely possible
> purpose of running emergency traffic should probably not use a
> busy-detector. It is possible to envision a busy-detector that could
> be programmed to remotely disengage upon reception of a specific
> command... but such a system is not readily available at the present
> time, and the use of it would certainly unnecessarily complicate the
> sending of an emergency message at a critical time.
> 
> 4. It may be counter-productive for networks or users to announce what
> type of busy-detection they use or don't use, because this sort of
> information can be used nefariously  (has been and will be) by
> individuals on purpose to maliciously interfere or thwart normal
> operation. 
> 
> 5. We all know that there are many feuds and grudges out there on the
> air. It seems that certain hams who are most prone to carrying on
> feuds or grudge-matches may also be the same individuals who clamor
> most loudly for busy-detectors to be put in place by their "enemy" :)
> 
> 
> Bonnie KQ6XA
> 
> 
> 
> 
> 
> 
> 
> 
> Announce your digital presence via our Interactive Sked Page at
> http://www.obriensweb.com/drsked/drsked.php
>  
> Yahoo! Groups Links
> 
> 
> 

_
Gear up for Halo® 3 with free downloads and an exclusive offer. It’s our way of 
saying thanks for using Windows Live™.
http://gethalo3gear.com?ocid=SeptemberWLHalo3_WLHMTxt_2

Re: [digitalradio] Busy Detectors

2007-09-16 Thread John Becker, WØJAB
At 08:18 PM 9/16/2007, Andy, K3UK in part wrote:

>but Bonnie, a fundamental issue has been the frustration with 
>PACTOR just switching on mid-stream and interfering with a QSO. 

If I may jump in here.
Does this not go back to the so called  "hidden transmitter"  issue ??
This I think has bee beat to death by many times on this list.

Find a fix for that and you will die a very rich man.

But I really think a lot has to do with those that just *HATE* the 
wide modes (RTTY Amtor Pactor) .

John, W0JAB
















Re: [digitalradio] Busy Detectors

2007-09-16 Thread Andrew O'Brien
but Bonnie, a fundamental issue has been the frustration with PACTOR just
switching on mid-stream and interfering with a QSO.  Other than under
contesting conditions, it rarely happens with other modes.  Would not it be
fairly easy for programmers to build in a variable parameter that allows the
user to set a signal to noise ratio and a waterfall bandwidth.  If the
software detects a signal above the specified SNR within the specified
bandwidth, the software refused to xmit?  A "off" setting could be used
when emergencies exists.  For example MixW and PC-ALE both have a pseudo way
of measuring SNR.

Andy.

On 9/16/07, expeditionradio <[EMAIL PROTECTED]> wrote:
>
>   There are down sides to busy-detection:
>
> 1. There is no way to know the relative interference temperature
> threshold for distant co-channel users on HF. SNR at every station is
> different. A signal that seems in the background at one location, for
> one mode, may be interference to another mode working at a different
> SNR or a different mode at another station.
>
> 2. What to detect? How sensitive? It is possible to engineer a
> busy-detector that can be set for a very sensitive threshold, and
> detect almost any mode or almost any level. That same detector will
> also falsely show a busy channel most of the time on the HF ham bands.
> That renders the busy-detector useless for the busy-detector user who
> wants to have a QSO or send an important message.
>
> 3. When does the receiving station with busy-detection know whether
> the content of such an incoming message is an emergency? A
> too-sensitive busy detector might prevent such a message from being
> run in the first place, and the result would not be good. Thus,
> stations that are on the air specifically with a very likely possible
> purpose of running emergency traffic should probably not use a
> busy-detector. It is possible to envision a busy-detector that could
> be programmed to remotely disengage upon reception of a specific
> command... but such a system is not readily available at the present
> time, and the use of it would certainly unnecessarily complicate the
> sending of an emergency message at a critical time.
>
> 4. It may be counter-productive for networks or users to announce what
> type of busy-detection they use or don't use, because this sort of
> information can be used nefariously (has been and will be) by
> individuals on purpose to maliciously interfere or thwart normal
> operation.
>
> 5. We all know that there are many feuds and grudges out there on the
> air. It seems that certain hams who are most prone to carrying on
> feuds or grudge-matches may also be the same individuals who clamor
> most loudly for busy-detectors to be put in place by their "enemy" :)
>
> Bonnie KQ6XA
>
>  
>



-- 
Andy K3UK
www.obriensweb.com
(QSL via N2RJ)


[digitalradio] Busy Detectors

2007-09-16 Thread expeditionradio
There are down sides to busy-detection: 

1. There is no way to know the relative interference temperature
threshold for distant co-channel users on HF. SNR at every station is
different. A signal that seems in the background at one location, for
one mode, may be interference to another mode working at a different
SNR or a different mode at another station. 

2. What to detect? How sensitive? It is possible to engineer a
busy-detector that can be set for a very sensitive threshold, and
detect almost any mode or almost any level. That same detector will
also falsely show a busy channel most of the time on the HF ham bands.
That renders the busy-detector useless for the busy-detector user who
wants to have a QSO or send an important message. 

3. When does the receiving station with busy-detection know whether
the content of such an incoming message is an emergency? A
too-sensitive busy detector might prevent such a message from being
run in the first place, and the result would not be good. Thus,
stations that are on the air specifically with a very likely possible
purpose of running emergency traffic should probably not use a
busy-detector. It is possible to envision a busy-detector that could
be programmed to remotely disengage upon reception of a specific
command... but such a system is not readily available at the present
time, and the use of it would certainly unnecessarily complicate the
sending of an emergency message at a critical time.

4. It may be counter-productive for networks or users to announce what
type of busy-detection they use or don't use, because this sort of
information can be used nefariously  (has been and will be) by
individuals on purpose to maliciously interfere or thwart normal
operation. 

5. We all know that there are many feuds and grudges out there on the
air. It seems that certain hams who are most prone to carrying on
feuds or grudge-matches may also be the same individuals who clamor
most loudly for busy-detectors to be put in place by their "enemy" :)


Bonnie KQ6XA