CQ-Contest
[Top] [All Lists]

[CQ-Contest] hypothetical - NOPE: ITS A: Been There Done That

Subject: [CQ-Contest] hypothetical - NOPE: ITS A: Been There Done That
From: K4OJ@aol.com (K4OJ@aol.com)
Date: Sat Nov 8 18:29:21 1997
<< Suppose they are virtually the "only-game-in-town" for that mult.  Suppose
they are  iron-butts and chafe at the idea of doing "only" 24 of the 30
hours. >>


time to turn back the clocks to the days of one of the great legends: KH6IJ

Katashi Nose, KH6IJ would always operate more than his alloted time to be
able to provide the mult for those deserving.....

It has been a long time since he was an active contester, and he is a silent
jey - but I am sure many on this reflector will attest to countless contest
QSOs with him....he was really good!

k4oj

--
CQ-Contest on WWW:        http://www.contesting.com/_cq-contest/
Administrative requests:  cq-contest-REQUEST@contesting.com

>From Ward Silver <hwardsil@WOLFENET.com>  Sun Nov  9 00:46:57 1997
From: Ward Silver <hwardsil@WOLFENET.com> (Ward Silver)
Subject: [CQ-Contest] Sending Both Calls in SS
In-Reply-To: <34655096.77D6@mb.sympatico.ca>
Message-ID: <Pine.OSF.3.95.971108162529.23320C-100000@gonzo.wolfenet.com>


> According to the rules as published in Oct. 1997 QST (can there be a 
> better source?) the other station's callsign is not part of the required 
> exchange; I quoth: ``4) Exchange: A consecutive serial number, precedence 
> (<SNIP>), your call sign, check (<SNIP>) and your ARRL/RAC section.''
> 
> There is no mention of the other's callsign.
> 
> I believe that the example that follows is merely to display a typical 
> contact, which likely would (but not necessarily MUST) include the 
> calling station's call sign, especially given the circumstances 
> indicated. Here, WJ1U would have no other way to indicate to whom he was 
> responding other than preceding the exchange with his call sign. 
> 
> WJ1U pretty much knows his own call sign, and that W1AW is in contact 
> with him. It is optional, then, for W1AW to include WJ1U in the exchange.
> 
> Comments?
>
> from Kelly, VE4XT

Interesting to see the Sprint requirement of sending both calls in the
exchange diffusing into other contests.  It's not such a bad idea under
really crowded band conditions - say, 40-meters on Saturday night. 
However, it's mostly not needed and slows you down. 

Is there any ambiguity in the following?

1: CQ SS de N0AX                "I am available"

2: W1AW (and maybe others)      "I wish to be selected"

3: W1AW 123 Q N0AX 72 WWA       "I select you and send data"

4: R 567 B W1AW 19 CT           "I acknowledge and return data"

5: TU N0AX SS                   "Received and released, I am available"

To be sure, W1AW never sent my call at all.  It is implicit in the
combination of frequency and timing.  Yet, it works 99.99999% of the time.
Why?  Because of the "bus-master" status of the CQ-ing station.

Similarly to most master-slave protocols, the master is responsible for
the detection of "collisions".  If N0AX, the master in this situation,
sends message number 3, and a response from more than one slave is
received, there has been a collision and it is up to the master to
"arbitrate" the collision and re-establish "bus sync".  This is easily
handled.

There are problems when there is more than one master on the channel.  The
technical term for the resolution of master-master disputes is a "pissing
contest", but I digress.

The question boils down to, "Does the additional overhead of redundant bus
traffic (i.e., sending both calls in the second response) result in an
equivalent decrease in error rate?"  The answer is no, unless there is a
possibility of more than one master on the channel (i.e., two CQ-ers in
the same passband of the S&P-er).

So, unless required by the rules or warranted in the judgement of the
S&P-er, don't send the CQ-er's call back at him or her.

73, Ward N0AX



--
CQ-Contest on WWW:        http://www.contesting.com/_cq-contest/
Administrative requests:  cq-contest-REQUEST@contesting.com

<Prev in Thread] Current Thread [Next in Thread>