[CQ-Contest] Error free RBN

Fri Jul 19 08:49:30 EDT 2013

There is no effort underway that would reject any valid calls AFAIK.

This is a total non-issue.

The focus is on removing easily identifiable BUSTED calls that are repeatedly spotted.

For example, HA3OS being spotted as T30S.  N2NT being spotted as TN2T. Et al.

W5OV

-----Original Message-----
From: CQ-Contest [mailto:cq-contest-bounces at contesting.com] On Behalf Of Mark Bailey
Sent: Thursday, July 18, 2013 7:57 PM
To: w2up at comcast.net; cq-contest at contesting.com
Subject: Re: [CQ-Contest] Error free RBN

Hi Barry:

I do my own filtering.  I want to minimize rejection of valid calls.

73,

Mark

Sent from my Verizon Wireless 4G LTE Smartphone

-------- Original message --------
From: Barry <w2up at comcast.net> 
Date: 7/18/2013  5:45 PM  (GMT-05:00) 
To: cq-contest at contesting.com 
Subject: Re: [CQ-Contest] Error free RBN 

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
_______________________________________________
CQ-Contest mailing list
CQ-Contest at contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest