Hi Bob - sometimes I wish that e-mail had a better "tone of voice"
indicator than those darned smileys. Iam not offended at all. I just
wanted to point out that in the interim, there are tools out there that
can help a lot. I routinely run a filter that applies the unique test
and also limnits spots to RBN nodes in my area. with that combination,
I see almost no busts.
Full credit for this great leap forward belongs to CT1BOH - his
algorithms seem to be working very well in our testing so far.
73, Pete N4ZR
Check out the Reverse Beacon Network at
http://reversebeacon.net,
blog at reversebeacon.blogspot.com.
For spots, please go to your favorite
ARC V6 or VE7CC DX cluster node.
On 7/18/2013 7:47 AM, Bob Naumann wrote:
Pete,
I have to presume that you didn't read my previous note.
I'm fully in support of the RBN error checking initiative underway by VE7CC
et al. Great work!
My slight exaggeration of the underlying problem was to make the point that
the problem indeed needs to be and can easily be solved.
There seems to be somewhat of a gap in understanding of what the problem is
by some apparently casual users, and what its impact is to those who are at
minimum semi-serious about operating and seeking to take advantage of the
RBN.
All of my commentary is in support of the error checking initiative. A+++!
I'm very encouraged and pleased by the early projections and look forward to
a much less stressful time of operating due to a greatly reduced # of busted
calls.
73,
W5OV
-----Original Message-----
From: CQ-Contest [mailto:cq-contest-bounces@contesting.com] On Behalf Of
Pete Smith N4ZR
Sent: Wednesday, July 17, 2013 8:38 PM
To: cq-contest@contesting.com
Subject: Re: [CQ-Contest] Error free RBN
Not quite fair, Bob - consider that the RBN is over 100 individual
nodes, many of which are copying the same station. It may be entirely
blameless, or it may be running the end and beginning of the call
together (see LW3LPL) or committing other sending errors. In my
experience, using a simple Unique >1 filter as ARC6 and VE7CC do removes
roughly 95 percent of the busted spots. We will do better than that,
but in the meantime...
73, Pete N4ZR
Check out the Reverse Beacon Network at
http://reversebeacon.net,
blog at reversebeacon.blogspot.com.
For spots, please go to your favorite
ARC V6 or VE7CC DX cluster node.
On 7/17/2013 4: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
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
|