VHFcontesting
[Top] [All Lists]

[VHFcontesting] Explaining "the three simple rules" [was: Endorse Rover

To: vhfcontesting@contesting.com
Subject: [VHFcontesting] Explaining "the three simple rules" [was: Endorse Rover Rules Revisions EXCEPT the 30 Q Limit
From: Ev Tupis <w2ev@yahoo.com>
Reply-to: w2ev@yahoo.com
Date: Sun, 22 Feb 2009 13:12:38 -0800 (PST)
List-post: <vhfcontesting@contesting.com">mailto:vhfcontesting@contesting.com>
Hi Joe.
I agree that open discussion is a good thing for as long as focus remains on 
the issues-at-play.  Thanks for your well-presented point-of-view.

You brought up some great points.  I'll reply in-line below.  But first...

The purpose of "the three simple rules to normalize Rover scoring" is 
specifically to provide Rovers with the same incentives that all other 
participants have; and nothing more.  It's not a "silver bullet" to all of the 
ills of contesting.  That said...

> With all due respect, please consider the situation I face
> when I try to make FN01 available to "as many stations
> as possible:
<snip>
> So, which group of "as many stations as possible"
> should I deliberately prevent from getting the FN01 mult?
> 

The example that you cite simply restates the dilemma that non-rovers have 
dealt with since the beginning as they attempt to adopt practices to allow them 
to contact as many stations as possible - from the single location within a 
Grid-4 that they must operate from.  In this case, there is still a slight 
Rover-advantage in that they may choose their location (along with it's pro's 
and con's).

> Also, wouldn't your new Rule #3 end up totally banning
> operation while in motion? For me, that's prime 6-meter
> time if there's an opening. Again do we really want to
> outlaw working "as many stations as possible?"

This would encourage Rovers to adopt other practices to work as many stations 
as possible while not in-motion.  It is an issue of strategy, similar to what 
HF contesters have had to deal with.  "Is this a good time to take my required 
off-time or will I miss that rare zone/country/etc.?"  vs. "Is this a good time 
to cease Grid operation or will I miss too many 6 meter QSO's between now and 
when I can setup again?".  It adds an exciting dimension to rover operations.

> Wouldn't it make more sense -- if we were to permit
> activation of a given grid only once -- to permit operation
> anywhere in that one grid until another grid is activated?

A single grid touches 8 others (for a total of 9).  If I could move within a 
grid, I could "game" the system by travelling around a grid's perimeter, 
working "lunchbox" rovers.  The result is that there would be a reward for not 
really contacting lots of other stations.  Again...no other class of operation 
can do this.  Neither should Rovers be able to.

> Now, how does this stop grid circling? Your way: For 8
> 10-band "toolboxes," that would be 70 Qs, 196
> Q-points and 4 mults per grid per toolbox.

I'm not sure I understand the example that you cited, but let me say that, 
using "the three simple rules" method, we are left with the same problems that 
everyone else has.  This *includes* "captive rovers"...those who go out to 
support only a single other operation.  If that's what you're describing, then 
I agree.  However...this is no different than the issues that all other 
operation deals with (the purpose of "the three simple rules").

In recap..."the three simple rules" serve to normalize rover scoring to that of 
all other classes.  In doing so, they eliminate grid-circling and encourage 
rovers to build stations that are capable of real communication through 
enhancing equipment, operator skill and strategy.

Alas, the genie is "out of the bottle".  So much accommodation has been made 
because of it (THREE rover categories?!?!) that other things would need to be 
realigned, too.  The topic of another thread, for sure. :)

Ev, W2EV



      
_______________________________________________
VHFcontesting mailing list
VHFcontesting@contesting.com
http://lists.contesting.com/mailman/listinfo/vhfcontesting

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