Hi,
Just a reminder, why there are so many false band spots. From the current
candidate release notes rc1:
Correct a flaw that could send incorrect frequencies to ALL.TXT
and PSK Reporter after a band change
That happens each time you change the band during monitoring. The previous band
Hi Phillip,
It would be nice if the problem could be reduced at the source of the spot
then there is less complexity needed upstream. My thought is the
PSKreporter option in WSJT-X can only be enabled if CAT is defined, this
might filter some of the chaff from the wheat when it comes to spots
pskreporter has an algorithm to identify and filter out most of those bad
spots. However, this can only happen once confirming/disconfirming spot
reports arrive from other monitoring stations. Thus HamSpots will be passed
these bad spots before pskreporter can figure out that they are bad.
Philip
On 16/08/2022 9:52 am, Laurie, VK3AMA via wsjt-devel wrote:
HamSpots has a couple of thousand callsigns that have their spots
permanently blocked because of repeated occurrences of wrong-band
spotting by the callsign
I neglected to add, that the majority of those habitual wrong-band
On 16/08/2022 9:32 am, Peter Sumner via wsjt-devel wrote:
Why? oh too often many of us have seen 'false spots' from a busy band
appearing on what is a very quiet band via PSKreporter because an OP
somewhere has changed bands on the rig but not on WSJT-X
HamSpots has a couple of thousand
Hello.
I would like to see the PSKreporter functionality in WSJT-X be restricted
to situations where the CAT control of the rig is active.
Why? oh too often many of us have seen 'false spots' from a busy band
appearing on what is a very quiet band via PSKreporter because an OP
somewhere has
