Hi Uwe,
RRR, understood. I just wanted to show that as a general concept hiding
decodes may not be a good strategy unless there was some underlying
information to base that on. For example we could choose to hide low
confidence decodes altogether but that would be a regression in
functionality IMHO because they can often be the difference between
completing a QSO and not. Who are we to say that a decode discovered
with AP and low confidence is not genuine and possible critical to a
user in a QSO who was expecting such a decode, or perhaps even a wanted
DXCC that is worth joining the contest just to get a QSO in the log.
73
Bill
G4WJS.
On 25/05/2020 14:14, DG2YCB, Uwe wrote:
Hi Bill,
Agreed. Just one clarification: I didn’t want to let all /R decoded be
discarded unless in a special operation activity mode, ONLY THE AP
DECODES OF /R CALLSIGNS, so that true /R callsigns are still displayed
when in normal FT8 mode. The idea is to filter out some more false
decodes in a clever way.
73 de Uwe, DG2YCB
*Von:*Bill Somerville [mailto:[email protected]]
*Gesendet:* Montag, 25. Mai 2020 14:23
*An:* [email protected]
*Betreff:* Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode
Hi Uwe,
that is a possible option but we must be careful. For example a user
being deprived of sight of messages that happened to contain '/R'
suffixes may misunderstand that they should be enabling the relevant
contest mode. Also the same argument would apply to '/P' suffixes,
would you be happy to have all messages from '/P' stations hidden? As
I said to Steve, we must be careful not to program in use of
information not received on air, after all we are dealing with radio
communications - not sanitizing decoded messages based on outside
information. IMHO it is better for the operator to understand some of
the underlying technology and to apply informed decision making to
comprehend what is displayed. After all the consequences of trying to
communicate with an invalid station whose callsign was printed in a
false decode is not serious, maybe some embarrassment and a little
wasted time.
73
Bill
G4WJS.
On 25/05/2020 13:10, DG2YCB, Uwe wrote:
Bill,
Just an idea: Wouldn't it make sense to discard all the /R ?a2 decodes
unless a special operation mode is set?. My observation also with the prior
WSJT-X versions was, that if there are false decodes, most often they are /R
decodes. Couldn't that significantly reduce rate of false decodes without
reducing the sensitivity? And when only the AP decodes were discarded, a
true /R call would still be decoded. Couldn't that be a solution?
73 de Uwe, DG2YCB
____________________________________
German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail:[email protected] <mailto:[email protected]>
Info:www.qrz.com/db/DG2YCB <http://www.qrz.com/db/DG2YCB>
-----Ursprüngliche Nachricht-----
Von: Bill Somerville [mailto:[email protected]]
Gesendet: Montag, 25. Mai 2020 13:43
An:[email protected]
<mailto:[email protected]>
Betreff: Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode
On 25/05/2020 12:04, Stephen VK3SIR wrote:
Folks,
I just picked up a false decode that can be replicated when
played back
through WSJT-X 2.2.0 rc2:
104945 -23 -0.5 1623 ~ VK3VM FH9ZZV/R ND49 ? a2
Research suggests this is not a genuine call and is definitely
a false
decode (i.e. ND49 = middle of Southern Ocean). I have noted that many false
decodes in the previous version are reported with /R !
As one cannot send attachments via email I'll reforward this
email plus
the .wav file directly to Bill and Joe for further analysis.
73
Steve I
VK3VM / VK3SIR
Steve,
AP decodes flagged as low confidence ('?' marker) should always be
considered dubious, and unless there is other evidence that the decode
is genuine it should be ignored. Without using knowledge not obtained on
air it is virtually impossible for the decoder to eliminate such false
decodes without damaging the capabilities of the AP decoding mechanism.
AP decodes of the 'a2' category are only detected shortly after a CQ
call IIRC.
The FT8, FT4, and MSK144 decoders give virtually every possible message
equal weight. The message types that allow a '/P' or '/R' (grid rover
station) prefix to a standard callsign have a 50% probability per
possible callsign that random data will unpack as one of those prefixes,
so they will be far more common in false decodes than in genuine
messages where the expected likelihood is far lower.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
