CQ-Contest
[Top] [All Lists]

Re: [CQ-Contest] Error free RBN

To: w5ov@w5ov.com
Subject: Re: [CQ-Contest] Error free RBN
From: "Jack Haverty." <k3fiv@arrl.net>
Date: Wed, 17 Jul 2013 14:51:15 -0700
List-post: <cq-contest@contesting.com">mailto:cq-contest@contesting.com>
Bob,

I totally agree that getting the RBN to send a perfect stream of data is
the right solution.  That may however be a very hard problem to solve,
filtering out all "bad" spots while not filtering out any "good" ones.

My only point was that, while waiting, the problem operators have of seeing
too many bad spots could be alleviated by other means.

In addition, things like a "don't show me this call any more" in a logger
program might be useful in other ways.

For example, it would enable me to "shut off" the constant stream of spots
for one or more active DXpeditions that sometimes clutter up the screen
while I'm in some contest.  It's of course especially annoying when I can't
even break through their pileup with my little pistol signal to work them,
which would then shut off the spots on my screen.  I'd find it useful to be
able to say "I know this high-value multiplier is there, but I can't work
him, so stop telling me about it."

Some club might even decide to build a little software that takes in the
RBN-enhanced spotting stream, and allows one of their team to sit in front
of a screen and manually select which spots go on to the active operator(s)
at their  computers and radio(s).  For example, maybe they'd filter out
spots right now for stations that they know will be a lot easier to pick up
later in the day when propagation is different at their location.  That
little tool might give that team some slight competitive advantage and help
them follow their contest strategy.

73,
/Jack de K3FIV

On Wed, Jul 17, 2013 at 1:47 PM, <w5ov@w5ov.com> wrote:

> Jack,
>
> That would be OK if the busted spots would stop coming in.  Think of the
> wasted bandwidth around the globe that results from this problem.  Adding
> to the processing burden of my local logging program is not the answer
> when it can be done in the RBN system itself and totally eliminate the
> problem.
>
> You have to remember a couple of things:
>
> 1) is that these are busted callsigns.  They are copied wrong by the
> skimmer systems.  Just because they happen to be wrong, does not mean that
> they might not also be a real callsign so a "blacklist" will not work.
>
> 2) is that the RBN is not like the human packet network where you could
> send a "TALK" message to someone sending out busted spots and tell them to
> stop.  The RBN cannot be told to stop making mistakes - and it
> continuously repeats the same errors over and over and over and over and
> over and over and over and over and over and over and over and over and
> over and over and over and over and over and over and over and over.
>
> Get the point?
>
> Error correction in the RBN is the correct solution.
>
> 73,
>
> Bob W5OV
>
> > Me too - another casual contester.
> >
> > A simple enhancement of the logging program(s) you use might help a lot
> > with those serious operators' problem.  Suppose you could have a command
> > to
> > tell your logger "treat this call as if I worked it", so it would never
> > appear again as a spot on your screen.
> >
> > In N1MM, for example, there is a "remove selected spot" menu item now to
> > get rid of a spot on the bandmap.  A similar item "Remove selected spot
> > and
> > never consider that callsign again" would stop the "over and over and
> over
> > again" problem.
> >
> > The loggers could even have a file, similar to the ones we use today as a
> > "whitelist" of known contest calls, but containing a "blacklist" of known
> > bad calls.  The loggers would simply read such a file and then ignore any
> > spots for those calls.
> >
> > It's good to always improve the accuracy of the data feed, but there are
> > other techniques that might be very helpful too...
> >
> > 73,
> > /Jack de K3FIV
> >
> >
> >
> > On Wed, Jul 17, 2013 at 5:10 AM, Bob Naumann <W5OV@w5ov.com> wrote:
> >
> >>
> >> For the more "casual" contest operator (of which I'm one - most of the
> >> time), and for the day-to-day DXer, the errors admittedly don't present
> >> much
> >> of a problem.
> >>
> >> The problem comes in a major DX contest, when you're a serious operator,
> >> and
> >> during the last 24 to 36 hours of the contest you've already worked most
> >> everything that is unique (multiplier-wise) on the band(s).  As a
> >> result,
> >> your logging program is no longer alerting you to the stuff you've
> >> already
> >> worked (the real callsigns).  Guess what you do see?  A preponderance of
> >> RBN
> >> errors! It has been at a level that is simply unacceptable. Most of
> >> these
> >> are not "off by one" errors either.  The real problem is that they never
> >> stop. The same errors are propagated over and over and over and over
> >> again.
> >> It becomes quite unsettling after a while. "When will this stop?"
> >>
> >
>
>
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest

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