CQ-Contest
[Top] [All Lists]

Re: [CQ-Contest] NILs hurt

To: <john@kk9a.com>, <CQ-Contest@contesting.com>
Subject: Re: [CQ-Contest] NILs hurt
From: "Christian Schneider" <prickler.schneider@t-online.de>
Date: Wed, 4 Sep 2013 08:53:18 +0200
List-post: <cq-contest@contesting.com">mailto:cq-contest@contesting.com>
KK9A wrote:
I think it is a very poor practice to receive a report, send your report and
then removed the station from your log unless you have a good reason to
believe that the station did not log you.  There should be something in the
rules prohibiting this practice.  ...  Listen to the operator's operating
style before calling.
-------------------------
When doing fast S&P I will definitely not waste time and wait a few qsos to
check his operating style. And I will not keep a begun qso in my log if I do
not get a proper cfm. What is not uncommon for running stations is to
somewhat terminate an uncomplete qso after one or two requests for a fill
with "CQ de XYZ" - leaving it open whether I´m in his log or not. I once
checked such contacts afterwards to learn that about half of such cases were
not logged by the running station. Leaving the decision about the validity
of the qso to the caller is IMHO very poor practice, too.

Either they have no paddle to send "sri ltr" or "sri nil" or have no
function key programmed with this message - I do not believe that they are
to shy to acknowledge that they could not copy my signal in the time they
want to spend for me. Starting to talk about "punishing" could equally mean
to punish running stations that do not make clear whether the caller is in
the log or not. IMHO both too difficult to prove to put another burden on
logcheckers. How many stations are really out that need the time saving of
omitting "tu" or "sri ltr"? (additinoal qrming requests or NILS possibly
eating up the "saved" time). 
73, Chris (DL8MBS) 

_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest

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