[CQ-Contest] Error free RBN

[Mark]

No processing would of course be needed for 6m or where there is a lack of multiple skimmers, 
like perhaps with rtty  skimmers which are also handled,by the RBN.  

Of course it would be easy to exclude thes from the algorithm.

Mark. N2QT

On Jul 18, 2013, at 5:45 PM, Barry <w2up at comcast.net> wrote:

> Why would you want a raw feed?  What kind of additional info do bad calls give you?
> Barry W2UP
> 
> On 7/18/2013 07:25, kd4d at comcast.net wrote:
>> Hi Pete:
>> 
>> We DEFINITELY want the ability to get an unprocessed stream (raw feed).  This looks like a very valuable option for RBN users.
>> 
>> Thanks and 73,
>> 
>> Mark, KD4D
>> 
>> ----- Original Message -----
>> From: "Pete Smith N4ZR" <n4zr at contesting.com>
>> To: w5ov at w5ov.com
>> Cc: "Jack Haverty." <k3fiv at arrl.net>, cq-contest at contesting.com
>> Sent: Wednesday, July 17, 2013 6:00:18 PM
>> Subject: Re: [CQ-Contest] Error free RBN
>> 
>> The real question is, *where* in the system - at the individual
>> Aggregators (1 per Skimmer), at the RBN database server, at the RBN
>> telnet server(s), or at the user's local Telnet server?  I tend to agree
>> that we need a centralized solution, preferably one that makes both the
>> unprocessed stream and a processed stream available for users who may
>> want one or the other.
>> 
>> But before we can do any of this, we want to test CT1BOH's algorithms,
>> both for accuracy (no fair rejecting real, good spots) and for speed.
>> Any solution must be capable of at least 40 spots/second *average*,
>> preferably more. We've only been looking at this for 48 hours, and
>> everyone on the RBN team except me still has a real job, so it won't
>> happen overnight, but we *are* serious about it.
>> 
>> 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
>> _______________________________________________
>> 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