[Skimmertalk] [RBN-OPS] Spot fidelity
Pete Smith N4ZR
n4zr at contesting.com
Tue Jan 17 05:32:20 PST 2012
Interesting report, Paul. A few semi-thought-out reactions...
I'm not sure what to make of different Eu stations busting the same call
at exactly the same time in the same way - perhaps QRN or something
propagated by radio has interfered, because the CW Skimmer decoder is
operating on a very short time interval before it moves on to the next
stream. I had wondered myself about whether a low SNR might be
implicated, but the evidence so far is inconclusive. Two stations
operating the same validation level, and both hearing the same bust,
could very well both decide to send the same busted spot to the RBN at
the same time.
From the RBN's perspective, it would make little difference if all EU
Skimmers were running Aggressive validation, because with so many
contributors in that area we are virtually certain of getting the spot
from several. The only real downside is that posting at all will occur
a little further along in the station's efforts to attract callers,
something that may not make much difference, since the RBN is typically
minutes, not seconds, ahead of traditional spots. However, I well
understand that people like to get as many spots as possible, hence the
appeal of running Normal rather than Aggressive.
For RBN users, the problem is a little different. Some big multi-ops
have reported that on the second afternoon of a major contest they were
seeing as many as 80 percent bad spots. At first, I thought, "How can
this be?", because the error rate of all Skimmers, in the aggregate, is
under 1.5 percent. Then it dawned on me - if RW9AS is calling CQ, and
being spotted, and then a single Skimmer busts his call as (for example)
RW9ASE, both spots will appear on the RBN, with seemingly equal
validity, and if the multi-op has already worked RW9AS, its operator
will see only the bad spot as potentially workable. Not good, clearly.
For the moment, the best solution to this for users may be to connect to
the RBN's ARCluster server and apply the Uniques>x filter. What that
does is to look at spots coming in and only pass them to the user if
more than x Skimmers world-wide report the same call at the same time
and frequency. Combined with a spotterstate= filter, to try to make
sure that you'll be able to hear what is being spotted, this should do a
pretty good job of filtering out even double busts.
Meanwhile, we are also working on algorithms that might be used to try
to catch this situation at the server as each new spot comes in, by
comparing it to spots received on about the same frequency and figuring
out who the outliers (probably busted) are. This is not an easy chore,
because the server saw *average* rates of 20 spots per second during
CQWW 2011, but we're hopeful. If anyone with programming skills that
might be relevant is interested in becoming involved, by all means
please let me know.
As a final aside, let me pass on my congratulations to the Skimmer ops
worldwide - virtually all of you are reporting frequencies within +/-
0.1 KHz of each other and of our standard frequency references. That is
a great help in our effort to put out the best quality spots possible.
73, Pete N4ZR
The World Contest Station Database, updated daily at www.conteststations.com
The Reverse Beacon Network at http://reversebeacon.net, blog at reversebeacon.blogspot.com,
spots at telnet.reversebeacon.net, port 7000 and
arcluster.reversebeacon.net, port 7000
On 1/17/2012 6:26 AM, Paul_group wrote:
> before I start, apologies but this is very long winded.
>
> I recently had a fairly nasty e-mail exchange with a F6*** stn who
> demanded that I immediately close down my skimmer as I was deliberately
> misleading stations and that 75% of my spots were busted. It turned out
> that he was particularly miffed as I'd spotted (U)T5G on 15m - as
> diplomatic relations have now permanently broken down with the pleasant
> gentleman from France I thought I'd better investigate anyway.
>
> G4HSO seems to run a very similar setup to mine and within reason our
> spots and SNR agree almost perfectly. I've put an example below. Where
> a busted call happens. Sometimes I bust the call, sometimes 'HSO skimmer
> busts the call but always we both either drop or insert a rogue
> character on the front of the call.
>
> I though I'd found an example where only I had bust a call at a good SNR
> but now I'm not sure. The example below with W9AS or RW9AS: we both
> decoded W9AS but shortly afterwards on the same frequency I spot RW9AS.
> A quick QRZ shows W9AS is a valid call where RW9AS isn't there.
>
> The thing is at the same time as me an almost equal split of skimmers
> around the world seemed to spot RW9 or W9 on the same QRG. Maybe I
> suspect this is down to an equal split of aggressive / normal
> validation? In addition, "R W9AS" is similar to "RW9AS". Maybe not to
> get too hung up on this particular example as its not a unique
> occurrence. The (U)T5G is another, I also saw (R)W1** spotted as W1** on
> top band recently. Again a mixture of skimmers spotting the two calls.
>
> I ran some tests using different validation and whilst aggressive does
> seem to be the way forward virtually none of the spots are then of any
> use to users as they are *always* post a none aggressive skimmer and it
> really does miss a lot of genuine good high SNR spots with well sent CW.
>
> Whilst this is a bit of speculation as to whether this links to call
> validation but with a dense population of skimmers in Eu I suggest
> running aggressive validation is actually a waste of electricity unless
> everyone does it.
>
> Going back to the initial complaint of 75% of spots being busted, if
> users suppress duplicate spots (why wouldn't they) and your running
> aggressive validation the users are only going to see your busted calls
> or the very occasional genuine new one.. is this a losing battle ;-)
>
>
>
> The second issue is spotting the same station on for example 3505.1Khz
> and 7010.2Khz - initially I had thought that the stn genuinely could
> have a readable 2n'd harmonic but the SNR in all cases I've found is
> identical. Maybe there was something in the QS1R hardware or active
> antenna none linearity but I cannot reproduce it on the bench or with
> locally generated test calls, I see other skimmers throughout the world
> doing this from time to time.
>
>
> In summary it would be nice to understand the best skimmer settings and
> if there are real decode quality issues to address how do we track them?
>
> As before, again I'm sorry this is long winded and I know its been
> discussed before ..... but after the nasty exchange experienced here
> maybe its worth revisiting?
>
> RW9AS example quoted above:
>
> DX de GW8IZR-#:14012.8 EW8MK 19 dB 25 WPM CQ
> DX de G4HSO-#: 14012.8 EW8MK 20 dB 24 WPM CQ
> DX de GW8IZR-#: 7001.7 SM5COP 31 dB 25 WPM CQ
> DX de G4HSO-#: 7001.7 SM5COP 30 dB 24 WPM CQ
> DX de GW8IZR-#:14019.5 HA6OD 09 dB 23 WPM CQ
> DX de GW8IZR-# 18077.1 RX3AP 20 dB 24 WPM CQ
> DX de GW8IZR-#:14025.3 OH2KI 35 dB 26 WPM CQ
> DX de G4HSO-#: 14025.3 OH2KI 36 dB 26 WPM CQ
> DX de GW8IZR-#:10117.0 DK8OV 23 dB 27 WPM CQ
> DX de G4HSO-#: 10117.0 DK8OV 18 dB 27 WPM CQ
> DX de GW8IZR-#:21017.0 UR5LGJ 11 dB 32 WPM CQ
> DX de GW8IZR-#:10103.0 DK4AN 37 dB 24 WPM CQ
> DX de G4HSO-#: 14021.0 TA1FA 15 dB 21 WPM CQ
> *
> DX de G4HSO-#: 14014.0 W9AS 23 dB 25 WPM CQ
> DX de GW8IZR-#:14014.0 W9AS 17 dB 25 WPM CQ
> *
> DX de GW8IZR-#:14003.0 DJ2BC 32 dB 25 WPM CQ
> DX de G4HSO-#: 14003.0 DJ2BC 15 dB 25 WPM CQ
> DX de G4HSO-#: 7016.0 F6FLF 12 dB 26 WPM CQ
> DX de GW8IZR-#:14028.7 DL9LM 37 dB 29 WPM CQ
> *
> DX de GW8IZR-#:14014.0 RW9AS 18 dB 25 WPM CQ
> *
> DX de GW8IZR-#:14046.8 OK2PRQ 10 dB 24 WPM CQ
> DX de G4HSO-#: 7010.0 F9EW 26 dB 17 WPM CQ
> DX de GW8IZR-#: 7010.1 F9EW 28 dB 20 WPM CQ
> DX de GW8IZR-#:18069.0 UR3UI 11 dB 26 WPM CQ
> DX de G4HSO-#: 18069.0 UR3UI 16 dB 26 WPM CQ
> DX de GW8IZR-#:21026.0 R3QA 13 dB 32 WPM CQ
> DX de G4HSO-#: 21026.0 R3QA 25 dB 33 WPM CQ
>
> And from RBN a SH/DX RW9AS
>
> 14006.8 RW9AS 17-Jan-2012 1101Z 18 dB 23 WPM CQ
> <TF3Y>
> 14006.7 RW9AS 17-Jan-2012 1100Z 21 dB 23 WPM CQ
> <SK3W>
> 14006.8 RW9AS 17-Jan-2012 1100Z 15 dB 23 WPM CQ
> <IK3STG>
> 14006.8 RW9AS 17-Jan-2012 1058Z 13 dB 23 WPM CQ
> <HA6PX>
> 14006.8 RW9AS 17-Jan-2012 1058Z 12 dB 23 WPM CQ
> <DK9IP>
> 14006.8 RW9AS 17-Jan-2012 1058Z 20 dB 24 WPM CQ
> <G4HSO>
> 14006.7 RW9AS 17-Jan-2012 1058Z 26 dB 24 WPM CQ
> <DL8LAS>
> 14006.8 RW9AS 17-Jan-2012 1058Z 21 dB 23 WPM CQ
> <PA1T>
> 14006.8 RW9AS 17-Jan-2012 1058Z 23 dB 24 WPM CQ
> <GW8IZR>
> 14006.8 RW9AS 17-Jan-2012 1058Z 32 dB 24 WPM CQ
> <RZ3DVP>
>
> followed by sh/dx W9AS
>
> 14006.8 W9AS 17-Jan-2012 1057Z 24 dB 23 WPM CQ
> <OL5Q>
> 14006.9 W9AS 17-Jan-2012 1051Z 08 dB 23 WPM CQ
> <RU9CZD>
> 14014.0 W9AS 17-Jan-2012 1013Z 13 dB 24 WPM CQ
> <IK3STG>
> 14014.0 W9AS 17-Jan-2012 1013Z 38 dB 24 WPM CQ
> <OH6BG>
> 14014.0 W9AS 17-Jan-2012 1013Z 16 dB 24 WPM CQ
> <SK3W>
> 14014.1 W9AS 17-Jan-2012 1012Z 27 dB 23 WPM CQ
> <US0KW>
> 14014.0 W9AS 17-Jan-2012 1012Z 24 dB 24 WPM CQ
> <DL8LAS>
> 14014.0 W9AS 17-Jan-2012 1012Z 23 dB 24 WPM CQ
> <OL5Q>
> 14014.0 W9AS 17-Jan-2012 1011Z 14 dB 23 WPM CQ
> <HA6PX>
> 14014.0 W9AS 17-Jan-2012 1002Z 17 dB 25 WPM CQ
> <GW8IZR>
>
>
>
>
More information about the Skimmertalk
mailing list