You would think the process would be quicker since everything is
computerized now. Before email came along (from what I remember) the CW
results would be in the Apr. issue of QST and SSB in May. Maybe that
10% of people who send paper logs are slowing down the process ??
Maybe they ought to just classify those paper logs a "check logs". I
doubt it would cause much of a fuss because I bet most of those logs
are probably from casual participants anyway...
73's Jeff KU8E
--- Tree <tree@kkn.net> wrote:
>
> Bill, WB0O asks:
>
> > The question is: why does it take until June to get
> > the results? The entire contest season will be over,
> > and it may (or may not) be summer here, and my mind
> > will be a million miles from contests.
>
> I think it is easy to understand why this takes as long as it does.
> First,
> it takes about 2 months to get all of the logs, and fix some of the
> problem
> logs up (those that are missing information or logged the contest in
> local
> time or sent in the previous year's log). Then, the log crunching
> has to
> occur, and in the past few years, there has been work put into
> improving
> the capabilities of that process at the same time. Once the numbers
> are
> generated, then the writeup needs to be written and folded into the
> schedule
> of the two people in the contest department at the ARRL. Then,
> finally, it
> goes off to the printers and gets mailed out using the slow mail.
>
> And that doens't mention the paper logs that have to be dealt with
> manually
> (still about 10 percent).
>
> Many things are changing that can reduce this time and already this
> has
> happened. The robots are helping clean up problem logs in real time.
> Publication of the results on the web eliminates the printing and
> mailing delay. The log checking process is near "perfection" and
> requires
> less development in parallel. It might be very possible to have
> "final"
> results for all stations within two months of the contest.
>
> The ARRL has come up with a new schedule for results, and things are
> moving
> up about 6 weeks for this year I understand.
>
> WB0O goes on to wonder about uniques:
>
> > The question of what to do with uniques. This is
> > probably meat for a years worth of discussion. IMHO,
> > it seems that there should be NO uniques among the
> > top 100 or so scorers in the CWSS contest.
>
> This really isn't an issue in my opinion. First off, uniques are
> only
> a problem if a log has a lot of them. All logs are going to have a
> few,
> but when a log shows up with 10X the average (that aren't matched to
> busted calls), then this raises suspicions.
>
> For sure, any uniques a top scoring station has will be looked at.
> There
> have been some cases where it was obvious that "friends" got carried
> away
> using multiple callsigns. These QSOs were not removed, but in most
> cases,
> these friends were encouraged to stick with one callsign, and to work
> some
> other stations in the contest.
>
> But - just to be clear - no uniques are removed without being judged
> to
> be a busted callsign.
>
> K4SB chimes in:
>
> > I've gotten dinged for these "uniques" for the last 2 years. And
> > afraid I sent a nasty
> > email the last time. If it happens again, I'm going to send ARRL
> the
> > QSL card!
>
> I am not sure this happened in the SS? It takes a lot of unprobable
> events to occur for any unique to be "dinged". Please provide
> specific
> data if this is the case - as I would be intersted in knowing more
> about
> it. Uniques are not removed from any log without being identified as
> a busted callsign. This applies to all contests I am aware of
> (except
> the Internet Sprints and Keyman Club of Japan contests which require
> both logs to show the QSO to be counted).
>
> If you are concerned about uniques being listed, then please
> understand
> this is a tool to detect people that have way too many uniques, a
> sign
> of manufactured QSOs. It also flags possible bad QSOs that can later
> be
> judged to be busted either by the software or a human.
>
> Finally, WB0O asks for my opinion (a dangerous thing):
>
> > The results would be posted in a week. Tree, your comments?
>
> I would not want to make the call on who makes the top ten in a tight
> race
> without having all of the information available. Part of the log
> checking
> process involves cross checking the QSOs with the logs we have. This
> will
> detect not-in-log situations, as well as incorrect serial numbers.
>
> If we did this before all of the logs were in, the stations with
> higher
> error rates will look better than they should. For each NIL not
> detected,
> there is a 2 QSO impact. Thus, an inaccurate log will be more
> competitive
> without all of the logs being used in the process.
>
> Therefore, I would suggest that if you wanted even faster results
> than
> supported by the log submission deadline, you work to move up the log
> submission deadline for all logs.
>
> Finally, AA4GA asks an interesting question:
>
> > How would deleting uniques make the reporting process faster?
>
> It makes it a LOT easier - because uniques are much easier to detect
> than
> busted calls. You have no judgement involved at all. A unique is
> simply
> a callsign that nobody else worked. It takes a lot more work and
> time to
> match these up to busted calls. In a contest like the SS, that is
> pretty
> easy because of the "quality" of the exchage (lots of good
> information that
> can be used to help you match up the call). For other contests, like
> the
> ARRL DX and CQ WW, where the exchange is pretty useless, it is a lot
> harder.
> These contests would be about 100X times easier to check if uniques
> were
> just not counted.
>
> Please understand I am not proposing this... I am just answering the
>
> question Lee asked.
>
> Tree N6TR
> n6tr@arrl.org
> _______________________________________________
> CQ-Contest mailing list
> CQ-Contest@contesting.com
> http://lists.contesting.com/mailman/listinfo/cq-contest
__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
|