[CQ-Contest] Why not BAN packet entirely in contests?

David Robbins k1ttt at berkshire.net
Sun Jul 22 19:35:56 EDT 2001


Marty Tippin wrote:
> 
> What good reason is there to allow the use of packet cluster during contests?
> 
<lengthy arguments against spotting clipped>
>

because packet spotting was designed specifically for and by contesters to
improve on the limitations of voice spotting over vhf repeaters.  as long as
outside assistance of any kind is allowed at multi op stations there will be
spotting, be it by voice or digital methods.

if it weren't for contests probably many of the nodes in use now would shutdown,
mine included.  i don't really care if dxers like it being available during the
week, i keep it up the rest of the time so that it is ready for the weekend
contests.  in the beginning with rf linked clusters the only reason many of them
stayed on during the week was to keep the frequencies occupied so they would be
available on the weekends, some of the early sysops didn't see any reason to
keep them running all the time.


-- 
David Robbins K1TTT
e-mail: mailto://k1ttt@berkshire.net
web: http://www.k1ttt.net
AR-Cluster node: 145.69MHz or telnet://k1ttt.net


--
CQ-Contest on WWW: http://lists.contesting.com/_cq-contest/
Administrative requests: cq-contest-REQUEST at contesting.com


>From Leigh S. Jones" <kr6x at kr6x.com  Sun Jul 22 19:43:25 2001
From: Leigh S. Jones" <kr6x at kr6x.com (Leigh S. Jones)
Date: Sun, 22 Jul 2001 11:43:25 -0700
Subject: [CQ-Contest] Why not BAN packet entirely in contests?
References: <4.2.0.58.20010722115343.00a7db78 at pop-server.kc.rr.com>
Message-ID: <2c6001c112de$31b32bf0$ede3c23f at kr6x.org>


This would have a negative impact on contest activity, something
sponsors would prefer avoiding.  Spotting networks have the effect of
advertising the contests to those who might not have their
transceivers turned on, or perhaps are set to the wrong mode for the
contest.  The assisted category is an honorable and enjoyable category
that many prefer because it gives them the opportunity to maximize
their score -- perhaps to assiste their club score.

----- Original Message -----
From: "Marty Tippin" <martyt at pobox.com>
To: <cq-contest at contesting.com>
Sent: Sunday, July 22, 2001 10:14 AM
Subject: [CQ-Contest] Why not BAN packet entirely in contests?


>
> If this has been argued before, I've not seen it. Apologies in
advance if
> this stirs up a hornet's nest...
>
>
> What good reason is there to allow the use of packet cluster during
contests?
>
>
> I would propose banning the use of packet cluster in any way (either
> receiving or sending spots) during contests. Especially if
*spotting*
> stations on the cluster was banned, it would basically eliminate the
use of
> packet cluster during contests (no point in connecting if nobody is
> spotting...)
>
> Please note -- I'm not at all opposed to the use of packet cluster
outside
> of contests - it's a great way to find out where the DX is and/or
who's on
> the band, where propagation might be best, etc. etc. - I keep DXMon
running
> 24 hours on my shack PC and watch all the spots that come in from
DXSummit.
>
>
> I can esily come up with a lot more reasons *not* to allow it than
to allow it:
>
> * Ops might actually have to turn the dial, listen, and use a bit of
skill
> to find stations to work (a novel idea, I know..) This is not a
"level the
> playing field" argument and I don't want to start that. But just
think how
> much more true skill is required to tune the band, listening for
weak ones
> buried in the noise than it is to simply click on an incoming spot
and have
> the rig QSY for you automatically.
>
> * I've worked multi-single efforts where I believe the packet
cluster
> actually worked to the *detriment* of our score -- ops on the mult
station
> were so consumed with working every new spot that came in that they
never
> used a disciplined approach of scanning the band from one end to the
other
> to find new stations (including the many that weren't being
spotted). I'm
> certain a lot of mults were missed because of randomly hopping
around the band.
>
> * The opportunity to cheat is obvious, and apparently a lot more
widespread
> than I would have guessed. Eliminate the source of this opportunity
and you
> eliminate at least some of the cheating. We'll deal with the 3KW
stations
> and the low-power stations running 1KW or more later.
>
> * For those connected to internet packet clusters (as I believe the
vast
> majority of users now are), a great percentage of the spots that
come in
> are worthless and only waste your time when you check. I don't care
if JA
> is working ZS on 10m, because I probably can't hear them. But the
spots
> (after importing into the logging program) generally don't show the
source,
> only the station that was spotted.
>
> * For DX stations, the packet cluster is often more harmful than
helpful to
> the run rate. I've seen many big DX stations comment that it's
obvious when
> they were spotted as the pileup gets suddenly huge. Imagine what
happens to
> the semi-casual DX with an "average" station who gets spotted and is
> suddenly overwhelmed with the pileup. I'll bet many of them just
pull the
> plug and go do something else.
>
>
> The only argument I can think of in favor of allowing packet is that
it
> *might* attract more casual and/or inexperienced ops who aren't
serious
> about the contest and only want to work a few new ones here and
there. But
> keep in mind that these ops in general have less capable stations
and are
> only going to be able to work the loudest DX they hear, which is
obviously
> easy to find by spinning the dial.
>
>
> If anyone can come up with more valid reasons for allowing packet
cluster
> in a contest, I'm all ears!
>
> 73,
>
> -Marty NW0L
>   martyt at pobox.com
>
>
> --
> CQ-Contest on WWW: http://lists.contesting.com/_cq-contest/
> Administrative requests: cq-contest-REQUEST at contesting.com
>


--
CQ-Contest on WWW: http://lists.contesting.com/_cq-contest/
Administrative requests: cq-contest-REQUEST at contesting.com




More information about the CQ-Contest mailing list