[WT-support] CQWW CW issue

[Bob Wilson, N6TV]

This is a new phenomenon, with dozens of Skimmers all over the world, all
interconnected by the Internet, together spotting spotting hundreds of
callsigns every second.  It is quite possible for two stations to be on
exactly the same frequency at exactly the same time, and not hear each other
at all.

Maybe the Win-Test band map needs a way to display up to three or four *
dissimilar* callsigns all at once, all on the same frequency.  Then it's up
to the *operator* to click on the callsign he is actually hearing.
Ctrl-Spacebar (grab spot according to VFO A freq) could be pressed multiple
times to run through the list.

Perhaps what is also needed in Win-Test' is a "voting" system for cluster
spots.  If two skimmers (or humans) spot EI6IZ, and another spots I6IZ, all
within the same 5-minute period within the same spot window, I6IZ should not
replace EI6IZ in the band map, even if it was spotted last.  The three
callsigns with the most spots in the last 5 minute period should "win".  Of
course if you sign your call enough times in the pileup, your call could end
up in the band map, right next to the DX callsign, causing more confusion if
you happen to be rare DX.

One would think that a manually entered operator correction (via right-click
/ Modify, or Ctrl-Enter) should have higher priority, but when should it go
away?  A new valid call could show up on that frequency, well before the
timeout period.  There needs to be some type of "similarity check" I guess.

Bad Skimmer or Cluster spots could also be automatically filtered if
Win-Test's used its built-in callsign pattern check, MASTER.SCP database,
and known calls already in the log, to determine whether or not to put a
spot into the bandmap and announce windows.  Maybe it's better to leave it
to experienced operators to recognize these errors, rather than the
computer, but it is a distraction.

Of course there's not much that Win-Test can do with skimmers like WA7LNW-#
that reported every station heard, instead of only those that were CQing.
Maybe Win-Test should automatically ignore a set of Skimmer spots if is
reported many different callsigns all on nearly the same frequency, all
within the same 5 minute period.

73,
Bob, N6TV

On Tue, Nov 30, 2010 at 2:55 PM, Matt IZ3EYZ <iz3eyz at virgilio.it> wrote:

> Unfortunately (as I expected) the 0hz thing doesn't solve at all the
> problem
> which comes up using RBN.
> I installed and used 4.7 dev during last cqww cw and due to the fact
> several
> skimmers actually spot S&Ping stns it means MANY mult spots are soon
> overwritten in a matter of few seconds. :-((
> Each op here devoleped his own strategy:
> a)writing down calls and qrgs on paper
> b)putting them into bandmap (but they are still overwritten)
> c)storing qrg's into rtx memories
> d)making sh/dx xyz to recall a certain call
>
> All of above is far from ideal.
>
> I just hope developers someday will understand the real need of introducing
> a new feature or eventually remove the overwriting (and keep it just for
> the
> same call spots )thing as ES5TV suggested.
> Looking at MS, M2, MM, SOA scores it can be seen how an automatic spotting
> system like RBN brought mult numbers to another level. Actually I feel
> those
> 800 dxcc scores could be improved even more!
>
> 73
>
> eyz
>
>
> ----- Original Message -----
> From: "Peter" <pc2a at pi4cc.nl>
> To: <support at win-test.com>
> Sent: Monday, November 29, 2010 4:08 PM
> Subject: Re: [WT-support] CQWW CW issue
>
>
> > Mikael Larsmark schreef:
> >> Hello
> >>
> >>
> >>
> >> I hope that some day you will understand how much the need to be able to
> >> shut down the spot bandwidth. Maybe its because you lads don't work much
> >> CW Contests (?) but this is a MAJOR issue.
> >
> > This is fix in the latest  dev version (4.7)
> > Worked great here with the spot wide set to 0 (zero) hz
> >
> > Ppeter
> > PC2A
> > www.pi4cc.nl
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.win-test.com/pipermail/support/attachments/20101130/209aacc8/attachment.htm>