Hi Barry,
i tend to agree with Mark about the choice not to enable the CT1BOH
algorithm, for two reasons:
- A "little pistol" station (like I am), when propagation isn't wide
open (e.g. on 10 and 15m operating low power with a multi-band vertical
antenna), when CQ'ing is being spotted by just one or two skimmers. With
CT1BOH filter enabled, that station wouldn't be spotted at all.
That's not good, both for me and for the big guns who, especially at the
end of the contest, are scraping the barrel, looking for a QSO more.
(Note that I also happen to operate from a "big gun" station, and at
some point we decide not to use the "Unique >1" feature of the ARC
described before by Pete N4ZR for the same reason).
- When calling CQ, even out of the contest, I like to know where my
signal is heard, and, with the filter "on" that won't happen, or would
happen partially.
IMHO the Jose's Algorithm is nice, just let each station decide whether
(and when) use it or not.
73 Paolo IK3QAR
From: Barry Date: 18/07/2013 23:45:
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
|