SECC
[Top] [All Lists]

[SECC] Contest rules

Subject: [SECC] Contest rules
From: gary@noblepub.com (Gary Breed)
Date: Fri, 9 Mar 2001 16:12:25 -0500
John and all

I agree about the power multiplier in Stew Perry.  And yes, the QRP
contests DID have dominance by the 1-watters over the 5-watters until
they settled on a less problematic multiplier formula.

I'm not all that familiar with WAE, and I suspected there were some
contests that had single-op 10 or 15 minute rules. Recent growth in SO2R
has changed S/O contesting, so I was suggesting that, in the interest of
diversity, at least one contest could steer competition to a different
set of skills. Its not a big deal, just a constructive thought.

Actually, I would like to see either a new contest or one of the less
popular contests experiment with a truly creative set of rules and exchange
info. The Stew Perry and WPX experiments are a start and Sprint is certainly
"different," but there could be other fun ideas, new and old. I'll try to
remember all those party games and see if there is a ham radio equivalent.
(Twister, for example.)

Maybe we can try something totally wacko for the GaQP?

73, Gary
K9AY




> Gary:  I am generally opposed to band change limits for single ops.  There
> is a 15 minute limit in WAE (with an exception for a quick change for a
> new mult).  It means that, if you go to 80 meters and make one contact,
> you must stay there for 15 minutes, even if there is no more activity on
> the band.  The same is true for that last change to 40 meters after
> European sunrise.  The same is true for 10 meters during low parts of the
> cycle.  It discourages use of marginal bands and cuts down on the possible
> contacts and multipliers for everyone.  Other contests have the same (or a
> 10 minute rule) for single ops and I think it is a bad idea.
>
> One thing about the Stew Perry rules that is bad is the power multiplier.
> That also appears in several state QSO party rules.  I have no problem
> with different awards for three different power levels.  What I am talking
> about now is a multiplier that encourages stations to use less power in
> order to maximize score.  That means that fewer contacts will made and it
> will be harder and will take more time to make them.  So, one must run 5
> watts or maybe 100 watts to win the contest, but one will make fewer
> QSOs.  The more remote stations (VK, ZL, Europe, etc) will have fewer QSOs
> and fewer DX QSOs than if everyone could run the maximum power allowed by
> his country, his license class, and his equipment.  I almost always run
> high power (particularly on 160 meters) to increase my enjoyment of the
> contest and to increase the possibilty that I will make a QSO with someone
> who will actually appreciate it.  I just got a QSL from NV7U for a
> 160-meter QSO from Idaho where he was running 2 1/2 watts and he needs GA
> for WAS on 160.  That contact would not have been possible if I had been
> conforming to a point maximizing rule that required me to run 5 watts (or
> maybe even 100 watts).
>
> Those are my two prinicpal observations of contest rules that need
> re-thinking.  I think the purpose of each contest is to encourage the most
> possible contacts, the most possible countries, the most possible
> counties, etc. and these two rules detract from that.
>
> I am sure you recognize, but just to make myself clear to others, I am NOT
> opposed to QRP contests as such or to 100 watt limit contests such as NAQP
> either.  Those are fine.  But the playing feel is level and no one is
> required to artifically limit QSOs to maximize a score.  (I do recognize
> that some QRP contests do the same thing, but I haven't felt strongly
> about that.  Almost never does someone running 1 watt beat a station
> running 5 watts in a QRP contest, despite a power multiplier.)
>
> 73, John, K4BAI.
>



--
SECC on the Web:          http://secc.contesting.com/
Submissions:              secc@contesting.com
Administrative requests:  secc-REQUEST@contesting.com
Problems:                 owner-secc@contesting.com


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