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@comcast.net>
Date: 7/18/2013 5:45 PM (GMT-05:00)
To: cq-contest@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@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@contesting.com>
> To: w5ov@w5ov.com
> Cc: "Jack Haverty." <k3fiv@arrl.net>, cq-contest@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@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
>
_______________________________________________
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
|