CQ-Contest
[Top] [All Lists]

Re: [CQ-Contest] The Fat Lady Sings at 2359Z

To: cq-contest@contesting.com
Subject: Re: [CQ-Contest] The Fat Lady Sings at 2359Z
From: "Jeffrey Embry" <jeffrey.embry@gmail.com>
Reply-to: jeffrey.embry@gmail.com
Date: Thu, 21 Jun 2007 12:17:06 -0400
List-post: <mailto:cq-contest@contesting.com>
I guess it all comes down to the operators 'intent' when any
modifications happen.

Is it done to provide the 'most correct log possible' to the contest
sponsor, or is it done to 'manufacture points/mults'?

73...hope work a bunch in Field Day and IARU.

-- 
Jeff Embry, K3OQ
FM19je
ARCI #11643, FPQRP #-696,
QRP-L # 67, NAQCC #25, ARS #1733
AMSAT LM-2263

No trees were harmed in the sending of this message, however a large
number of electrons were terribly inconvenienced.


On 6/21/07, Steve Harrison <k0xp@dandy.net> wrote:
> At 04:52 AM 6/21/2007 -0700, Ev Tupis wrote:
> >The casual contester (my definition) will find "yeah, but..." loopholes.
> >The contesting purist (my definition) will "put the pencil down" because
> >"the test is over."  It is up to the individual participant to decide
> >which definition applies to them, since there is no distinction in the
> >results.  This is simply a matter of honor (like keeping the score in a
> >casual round of golf).
>
> Most contest rules, when speaking about submitting your log, also say
> things such as "Make certain the correct category is marked....." or "Make
> certain all dates and times shown are in GMT.....".
>
> I don't think any serious contester really believes that correcting
> callsigns or received reports after a contest is really ethical; I never
> have. And rubber-clocking is another serious no-no. The columns containing
> that data are usually considered "untouchable", in my experience.
>
> But the complexity of some computer loggers has made it mandatory to
> carefully examine your Cabrillo log after the fact to make certain that it
> is in the format required by the contest sponsor.
>
> For example, the most recent incident involved logs that recorded 1296 QSOs
> as band "1.2", which used to be accepted by the ARRL robot. However, the
> ARRL apparently changed their robot to require such QSOs to be recorded as
> "1.2G" and would not accept "1.2" as the band. Some people edited that band
> info in their Cabrillo log and some downloaded a new update of the logger
> that would make the correction.
>
> There are many other such examples.
>
> Then there are the rarer times where logger programs have features such as
> Super Check Partial and even fill in a QTH. There, one must make certain
> that what is received from the other station agrees with what the logger
> "wants" to insert into the log fields. And once in a while, due to
> inexperience or even a logger bug, the IMPROPER QTH may be dumped into the
> log DESPITE the operator attempting to enter the correct data. While the
> operator should be "savvy" enough as to be able to see when this is
> happening, we don't always have the ability or knowledge to correct the
> incorrect logger data right at that moment. So what should we do? Top
> contesters say "Make a note and correct it later,".
>
> I strongly suspect that's partially why we find all those wishy-washy
> statements that Ev mentioned finding: "Should....", "many do.......", etc.
>
> Personally, if I believe my logger program has made a mistake, I believe I
> should be allowed to correct that mistake before submitting my log.
>
> One could argue that "You should have checked out your logger program
> BEFORE the contest to make certain it works properly,".
>
> But that's not always possible, especially in these days of oddball
> callsigns and up-to-the-minute updates of bugs found in loggers. Even the
> Country file is sometimes updated just a few hours or minutes before a
> contest begins.
>
> Furthermore, oddball callsigns are sometimes not obvious just which country
> is using them; take, for example, YU/YT/YZ which, until very recently,
> could be either Montenegro or Yugoslavia. Then there was the recent
> addition of 5P for Denmark. This is where the Country file is sometimes
> updated just a few hours before a contest.
>
> And if you're doing paper logging?? Normally, the contest sponsors'
> "suggested format" paper logsheets also include a column in which to mark
> QSOs that are multipliers. Obviously, if you work an oddball callsign
> during the contest, you may not know whether it's a multiplier at the time
> and will have to wait until AFTER the contest to do the research. The mere
> existance of those multiplier columns in those paper "suggested format"
> logsheets strongly indicates that the contest sponsor, indeed, DOES expect
> one to perform at least a limited amount of "editing" after the fact.
>
> But if *I* made a mistake in recording data received from the other
> station, that's a different situation: *I'm* in the wrong, and it was *my*
> responsibility to have heard, and entered, the correct data at the time.
>
> I think the bottom line is the data that should not be changed or
> corrected, after the fact, involves what is received from the other
> station; i.e., exchange information. As you pointed out: "Once you step
> over the line into making changes to what you think you "should" have
> logged, that's going too far." This statement isn't entirely clear since
> while filling out the row on the logsheet, you would normally also enter
> the band, date, time, exchange sent, etc. Where it says "... "should have
> logged,", I'm certain what is meant is recording the exchange information
> that you received.
>
> In other words, NO: I don't believe the "Put the pencil down" idea covers
> all the bases; and furthermore, I also do not believe that idea is intended
> by the contest sponsors.
>
> Steve, K0XP
> _______________________________________________
> CQ-Contest mailing list
> CQ-Contest@contesting.com
> http://lists.contesting.com/mailman/listinfo/cq-contest
>
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest

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