[CQ-Contest] Error free RBN

[Pete Smith N4ZR]

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 at contesting.com] On Behalf Of
> Pete Smith N4ZR
> Sent: Wednesday, July 17, 2013 8:38 PM
> To: cq-contest at 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 at 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 at 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 at contesting.com
>> http://lists.contesting.com/mailman/listinfo/cq-contest
>>
> _______________________________________________
> CQ-Contest mailing list
> CQ-Contest at contesting.com
> http://lists.contesting.com/mailman/listinfo/cq-contest
>
>