[CQ-Contest] multi-contesting

Tue Mar 24 10:45:54 PDT 2009

RC> Comments inline, below...

----- Original Message ----- 
From: "Michael Coslo" <mjc5 at psu.edu>
To: "cq contest" <CQ-Contest at contesting.com>
Sent: Tuesday, March 24, 2009 9:13 AM
Subject: Re: [CQ-Contest] multi-contesting

On Mar 23, 2009, at 7:39 PM, Robert Chudek - K0RC wrote:

> WØQE did a thorough job of creating the 3,077 state/county codes.
> It's a
> shame the "Not invented here" syndrome has precluded his work to be
> leveraged as a QSO Party standard.

Make no mistake about it. If the PAQSO were to start today, I would
use the MARAC county standard acronyms.

RC> That's great! It tells me you believe there is an intrensic value in 
using a standard.

> Does anyone remember the "Pre-ADIF" days
> when logging authors rolled their own and there was no
> interoperability?
> That's pretty much where the QSO Parties stand today, 15 years
> behind the
> times.

Now that made me smile. I regularly get my chops busted for
introducing changes and adding modern modes too! 8^)

RC> I understand, change is difficult for some people, no matter what 
environment.

Might I respectfully suggest that you are looking at it from a fairly
narrow view?

RC> Well I do wear glasses. :-)

I have to look at it from many viewpoints. I can see that having
standardized counties will allow people to operate in several parties
at once. So with rewrite of software to include that list, and more
rewrite to differentiate parties, some folks who want to operate
multiple parties can get in the action under their own terms.

Now, what does that do for the rest of my people? It means they have
to get familiar with a new list of counties. Some will get angry and
drop out for a while or permanently. They are passionate. I LIKE that.
But I have to respect that also. I would have to explain my actions,
and come up with a way to convince them that in order to accommodate
some folks who want to operate in multiple parties, a whole lot of
things have to change. I'd have to go into the witness protection
program. Just kidding, but I wouldn't be the subject of happy talk,
for sure. But I do make changes at my own peril.

RC> Getting used to new county abbreviations is certainly a deterrent for 
some people. Let me suggest that you look at this from the other direction. 
Start by getting the contest software people to output the MARAC codes into 
the Cabrillo and ADIF files that are generated after the contest. I know in 
N1MM Logger, for example, will support "equivalent" codes when logging 
contacts. That is, WA, WSH, WASH, WSHGTN can be typed by the operator and 
the software converts this to the official codes listed in the QSO Party 
rules. So if the QSO Party managers request MARAC codes in the Cabrillo 
file, this can be automated in most software.

The casual op who wants to work a lot of parties at once probably
isn't going to be seriously competing for any particular categories in
our party. Maybe a county award if they are operating from a rare one.

So I look at the situation, and weighing the pros and cons, I can see
that in order to please a fairly narrow, small, and casual group of
Ops, I have to inconvenience every regular op, rewrite much of my own
database and log checking software, and make an extra effort for the
software writers as they rewrite their software to accommodate
multiple concurrent contests.

I don't know about the logging programs, but that makes a week, likely
more of work for me on my end with absolutely no improvement, it
breaks my older databases, so I'll have to carry two, both old and
new, and I'll catch a lot of grief I'll have to take from all the
people I inconvenienced.

Couple with the statements we get such as "not invented here" and
accusations of being "15 years behind the time". Can you blame us for
not being so excited about the idea?

>RC No I don't blame you. There's a lot of work involved in making the 
>transition. At some point though, the pain of doing it the "old way" will 
>overcome the effort needed to move to a universal standard. There is one 
>QSO Party that is in the process of making that transition this year. They 
>are accepting the old abbreviations but encouraging the use of new 
>abbreviations. Unfortunately they didn't choose the MARAC codes as their 
>new standard.

And yet, there is an answer to the problem of working multiple state
parties, as outlined below.

>
> With many QSO Parties overlapping on weekends, I think it's a big
> disincentive for operators. You need to go into your logging
> software and "custom roll" a new abbreviation list.

Most software writers put in support for specific QSO Parties.

> Most people won't take the time or don't have the skill. Using the
> MARAC standard would allow you to operate numerous QP's,
> submit your complete log to each one, and be done with it.

Which software will split up the logs into specific contests?

>RC I don't know the answer to this question. I know last year at least one 
>of the QSO Party sponsors said they would accept mixed logs and parse them 
>on their end. Maybe someone who dealt with that issue can comment about the 
>process they used?

Once again respectfully,  if it is too much trouble to download a
county list, or a person doesn't have the skills to produce one, are
they going to be operating in multiple state QSO Parties?

Taking a look at the programming situation, you don't need the MARAC
list to do that anyhow. You could rewrite the software to accommodate
the different QSO parties, using their own list of counties.
Presumably there would be a switch to move between parties, which
would take you to the respective parties window, at which time you're
there.

Now a solution:

Many QSO parties have software written for them, and it's usually
free. And I've found that particular software tends to produce the
best logs.

My personal experience with operating multiple QSO parties is that I
eventually tend to concentrate on the one that is busiest. Trying to
run a frequency is a little complicated, so S and P tends to work best.

If I were to do this again, I would use the individual parties
software, and tab between them, adding entries as needed. Most have a
list of respective counties for display, so there shouldn't be a mixup.

Now some might say that "I use XXXX software, I don't want to use
anything else". At this point I have to refer them back to my
statement about changing things at my own peril.

But by this time, I'm not interested in doing multi parties anyhow.
Just like in real life, I'll go to one and hang out there.

In the end, I always have to revert to the old saying "you can't keep
everyone happy". State Parties tend to be a bit less cutthroat. Don't
mistake that for a lack of competitiveness though.  Many times a
person on a run allows another to break in and work a rare one they
just worked. There's more than UR 599 GL - I've heard and had short
conversations. It's fun. It's a different atmosphere.

But it isn't for everyone.

-73 de Mike N3LI -

>RC I didn't really find your solution above, although I did see what I 
>would call "work-arounds."

>RC But you're right Mike... with all you have said it boils down to "What 
>is the objective?" I believe the objective is different depending whether 
>you are "in state", "out of state", "DX", "a county hunter", a "club 
>sponsoring the QSO Party", or a software developer.

>RC The objective I am looking at is from a programmers perspective. Like I 
>stated before, using a standard abbreviation list allows programmers to 
>concentrate on program features and bug fixes instead of monitoring the 40+ 
>QSO Parties each year to see if someone changed their rules or "official 
>county codes." To reflect on the ADIF standard again, the programmers can 
>turn to one document and implement a solution.

>RC Let's say you're a programmer and you are building the ultimate 
>cross-QSO Party software. You will need to visit 40+ websites in order to 
>obtain the "official lists". How much time will that waste? (BTW, I just 
>did that excercise so I can tell you the answer - about 1 week of almost 
>full-time effort.)

>RC In addition, a standard provides the opportunity (in the future) for 
>programmers to create a real "cross QSO Party" logger that doesn't need to 
>deal with these maintenance issues or have users jury-rigging them to work.

>RC As far as log checking, I am only aware of one package in this arena, 
>W3KM Log Checker. I have loaded and looked at this package but have not 
>processed any logs with it yet. I am not the MNQP log checker, although I 
>have been involed with some of the issues when processing the master log 
>for other purposes.

>RC Most people agree using standards is good. Where the resistance comes 
>from is the amount of work involved (if it isn't broken, it doesn't need to 
>be fixed) or basic change (we've always done it this way). So my suggestion 
>is to look at a method to make a smooth transition from the current 
>situation to a better situation. Yup, there's going to be complainers no 
>matter what you do. Making changes for progress in any area, you need to 
>rebuff the nay-sayers with "Lead, follow, or get out of the way."

>RC Okay, I'm putting the soapbox away now and returning you to your normal 
>contesting activities...

73 de Bob - KØRC in MN

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