[Cwo] CWO support - software

[Alan Maenchen]

Thanks Matt!

First,  I'm getting bounce messages for no5w at consolidate.net
I think its a busted address.  Try no5w at consolidated.net<no5w at consolidate.net>

>From the CWO perspective,  I'm happy with simply identifying GOOD QSOs as a
minimum. What to do with bad QSOs is something we haven't discussed.  For
those not involved with CQP,  The CQP event follows the philosophy that it's
a fun event and that log checking bends over backwards to accept a QSO
rather than reject or penalize it. A "bad QSO" with a single copy error
(call or exchange" is dinged 1/2 the QSO points.  Two or more copy errors in
the same QSO and it's deleted.

CWO is a different animal. I'm open to ideas.
I'm still of the opinion that busting a call is no better or worse than
busting part of the exchange. Let me start this with my thought:  Any copy
error in a QSO results in the loss of the QSO (point and mult). Doesn't
matter if it's the call or part of the exchange, or wrong band...  I would
not (this time) penalize for wrong time.  We'll have enough trouble given
that there are three different events to judge and the only difference is
the time. I suspect that will be a real problem later.

CWO does not need to follow the CQP methods, although it would be convenient
if Matt can work CWO into Green with his re-write. However, it's only a
convenience .. not a requirement. Matt has a lot to do, and I'm sensitive to
that. That's why Chuck and Bill are on this list  (sorry Chuck for the bad
email address).  I'd like to hear from them.

73  Alan  AD6E

PS  so far KX7M has 1470 Qs and close to 600 mults in WPX  multi-single.  I
just got relived by W6NV. We seem to be holding out well despite the solar
storm. I'm going back in the morning. An old photo is on QRZ.com if you look
up the club call: N6DZ





On Sat, May 28, 2011 at 7:51 PM, Marshall "Matt" Thomas, WX5S <
mmthoma at attglobal.net> wrote:

> Hi Folks!
>
> I've been working on CQP software today and so this whole topic
> is on my mind....
>
> The level of judging that we do for CQP is way over the top!
> I'll explain a bit for you...
>
> CQP software is especially difficult to write because we have
> some unusual scoring rules - it is possible for a Q to get 1/2
> credit!  We look at callsign,number received, qth received and
> any one of those can be wrong and you still get the 1/2 QSO point
> credit. That means that if qth is wrong, we correct it (possibly gaining
> a mult) and you get 1/2 qso points for the Q. It is possible to
> bust the callsign. Weird cases can arise where both guys on either
> end of a Q bust the other guy's callsign and both wind up getting
> 1/2 credit for this wacko QSO. When we detect that you have logged
> a Q on the wrong band or mode, we will correct that at no penalty -
> this often results in the gain of a QSO because that Q might have been
> a "dupe" on the band that it was logged on and because it is now
> on a new band, it is a "new" complete credit QSO. Unlike
> most contests, we do not remove dupes before scoring. This adds
> a lot of complexity, but is an advantage to the Op. Each QSO is scored
> on its own merits. If there are 2 QSO's with one station on the same
> band mode,  both are scored. When the final rollup score for the log is
> done, we use the highest scoring of the two Q's - NOT arbitrarily pick
> the first one or the last one. Seemingly weird things can happen like
> the first of two Q's is counted for station A's score, while the second
> Q is counted for station B's score.
>
> The net effect of possible additional QSO's or multipliers showing up
> is that it is entirely possible for the final checked log to have a higher
> score than the initially submitted claimed score! Wow!
>
> CQP is extremely competitive. As generous as our rules sound, they
> are strictly enforced and applied evenly to all. Some first place finishes
> have been decided by one single QSO of 2,400. Or the case where
> if the op had made 2 of his phone Q's on CW, the 3 vs 2 point difference
> would have carried the day.
>
> A CQP like process is probably overkill for an "out of the blocks" process.
> I think the CWO scoring rules are more conventional and that decreases
> the complexity of the software.
>
> In CQP, with 300,000 Q's Green knows what to do with all but about 1,800
> of them. Green has a very high degree of certainty in what it does - it is
> not
> 100% but it is very close and knows when it does not have enough
> confidence and needs to ask a human.
>
> The humans get involved in wild stuff. Say station A claims a 20m Q with B,
> B claims a 15m Q with A. Are these really the same Q on either 15 or 20?
> Are the both Nils? Or is something even weirder going on? Cases like A
> thought he was Qing B, but really Q'd C although he logged B's callsign.
> The list of wild things we have come across is huge. Green has a nice
> set of graphical tools that help the humans figure things out and score the
> the QSO's manually. In this example, A would get credit for working C in
> CQP.
> In a more conventional set of scoring rules, the software could say, hey,
> I don't know what is wrong here, but something is wrong with the A QSO
> and it ain't going to get credit.
>
> In CQP we get a lot of hayseeds logging Q's on the wrong band or at
> the wrong time. Hopefully you will get a higher quality of logs in
> a CW only contest!
>
> I would suggest a "pretty good" process for the first go.  No program can
> ever be "perfect".  Green could make more decisions, but these would have
> more uncertainty. I would suggest CWO go the route of a little less sure,
> but requiring a lot fewer people the first time out.
>
> CWO does represent a mult challenge. The scores will be heavily affected
> by the number of mults. And the number of "valid" mults will be affected
> by callsign busts. The international nature of it also complicates things
> as the callsign database's that can be accessed aren't that good.
> I think that a lot of thinking should happen on how this part of the
> scoring
> is going to work.
>
> ==Green Roadmap==
> Here is what I am working on for CQP....
>
> First, implementation language is Perl 5.10 and the DB is SQLite.
> This is freeware and these are the right tools for this job.
> If I was trying to do this in Java, C# or whatever, it would a lot
> harder to do and take a lot more code.
>
> I do have a professional license for Active State PerlApp and I
> compile the code down to an .exe for distribution to end users
> for their Windows machines. That way end users do not have
> to have a Perl environment on their machine.
>
> 1. I am recoding the pre-processing scoring step. This is where
> Green does what it can before we send the logs to the human log
> checkers.
>
> 2. The GUI will be re-written and will then work with a local SQLite
> database (right now flat files are used). I tack on Green Info to the end
> of each Cabrillo QSO: line to keep track of the scoring, etc. This was
> great when we had 400 files, but with 1,000 this is getting slow and
> cumbersome. Besides having lost the code (storm took out
> all the 3 hard disks that had redundant copies, Yikes!),
> this is why step(1) needs to be re-done too! New version will be much
> faster...
>
> 3. All clients will be joined in a network to a central server. As you see
> in the A,B,C example above, often while working on log A, I find out
> something
> about log C. If you are responsible for log C, my wisdom from looking a log
> A will propagate auto-magically to you.
>
> A distributed client/server database application is not for the faint of
> heart!
> It will be way cool when I get it going. All of this will be done in Perl.
>
> *Need a server host*
> I am looking for a *nix machine to host my server on. The requirement
> is that I be able to use one of the 64K ports (HTTP uses port 80, MySQL
> uses port 3306. I need a port of my own.) Of course I write all the
> software
> I just need an SSH login and SFTP access and away I go.
>
> I have all sorts of utilities like things to search the QRZ database, etc.
> I have good approximate callsign matching algorithms that could be
> helpful to CWO.
>
> K6TD is working on Cabrillo file validation. You will need something
> similar
> for CWO. Plan for a HUGE amount of time being spent cleaning up formatting
> and other mistakes in Cabrillo logs before you can even begin to start
> log checking.
>
> Its not clear how much oxygen that CQP will suck out of the room.
> The CQP hunger for software is huge.
>
> /Matt WX5S
>
>
> On Thu, May 26, 2011 at 12:53 PM, Alan Maenchen <ad6e at arrl.net> wrote:
> > Both are now invited to join.  Welcome Bill and Chuck!
> >
> > This sounds great, and I look forward to working with both.
> > I don't know what Rob told you about our group.  CWO is "more serious"
> than
> > CWT in that we want it to be taken as a serious contest. That means we
> won't
> > just accept reported scores.
> >
> > What we need is help with log processing after the event.  N1DG is
> writing a
> > web application to allow folks to drop in their Cabrillo log and store it
> > somewhere. So far, so good, but there is a LOT of work that starts at
> that
> > point. I don't know if you've been involved with contest adjudication or
> > not. Basically, all logs need to be scrubbed and inhaled into some sort
> of
> > data base from which we can do QSO by QSO log cross checking for errors.
> > WX5S has a wonderful piece of software called Green that we use for CQP
> > logs. Unfortunately, due to a massive power blowout last year, he lost
> the
> > source code. He is now re-writing that code with significant upgrades for
> > use this year (hopefully). I asked Matt if he could include CWO in his
> > re-write so that it could be used for both CQP and CWO. He said that was
> > possible, but it adds work and he is unsure if he can do it in time for
> us
> > to use it this year. Worst case, CQP can use the executable we used last
> > year, but that leaves CWO out in the cold.
> >
> > Given the high profile of CWO in it's initial run this August, there is
> very
> > little time to get "something" running that is useful, even if not
> ideal.  I
> > would suggest communicating with Matt directly as I know enough software
> to
> > really ruin things if I get in the middle.
> >
> > This could go a number of ways, and I'll have to leave it up to you to
> > figure this out.
> >
> > The basic philosophy I'd like to follow is what I (and others) are used
> to
> > in judging CQP.  That is, computers are really nice and useful, but they
> > cannot be relied on to make judgements very well.  Thus, log checking
> > involves cross checking QSOs by computer with the computer identifying
> > suspect QSOs, and giving positive credit for perfect matches... which are
> > the vast majority of QSOs. Suspect QSOs are then fed to human judges to
> > decide if there is fault or not. The Green software does that and gives
> the
> > human judge tools needed to make that decision.
> >
> > I can send you Green and a bunch of logs that we checked last year with
> it.
> > Sometimes it's easier to show than to describe.  What Matt came up with
> is
> > really good. It isn't difficult to assemble a group of 10 humans to judge
> > the logs.  I've been doing that for almost 15 years now, and I'm
> comfortable
> > with it.
> >
> > Now, if you have a different idea or take on this, I'm open to
> suggestions.
> > My main concern right now is that we presently have nothing.  I expect
> 1,000
> > logs even in this initial year of CWO.
> >
> > Tks & 73,  Alan  AD6E
> >
> >
> >
> >
> > On Thu, May 26, 2011 at 10:02 AM, <k6rb at baymoon.com> wrote:
> >>
> >> Alan,
> >>
> >> Bill, N5RR, and Chuck, NO5W, are both very skilled software guys. Bill
> >> developed the CWops Award Manager (CAM) software, and Chuck developed
> >> CQ/X. I met both in Dayton, and both have agreed to help out, where they
> >> can, with the adjudication software effort. So, we should put both of
> them
> >> on cwo at kkn.net and let them network with Matt, WX5S, so that they have
> a
> >> sense of what we're trying to do. I promised Matt I would find him
> >> competent guys to help it...and these guys are aces.
> >>
> >> Rob K6RB
> >>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.kkn.net/pipermail/cwo/attachments/20110528/65b9d7c5/attachment.html