Bill, You are completely preaching to the informed here with knowledge of what, how, why and even some of the maths involved ☺ But thanks again.
The issue is that the software picks one of these out and then you respond, then abort or manually over-ride to the Tx6. There is a clear pattern that both myself and others in backchannel comms are observing with the /R suffix and how that seems to be almost universally thrown up in the process. I cannot explain that as this “consistency” makes no sense ! Hey if we don’t report the good, the bad and the unpredictable back how can we get better software? [ Back to working on some of the Mac-compile issues. For the record on that I am observing unpredictable behaviours through an old Mac with Ubuntu 20.04 LTE on it as well ! ] 73 (and I note subsequent comms but are unseen !). Steve I VK3VM / VK3SIR From: Bill Somerville <[email protected]> Sent: Monday, 25 May 2020 10:09 PM To: [email protected] Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode Steve, please don't equate AP assisted decodes with low levels (I prefer the term weak signals). AP decoding techniques, like the other FEC mechanisms, allow missing information to be recovered. Weak signals are not the only cause of missing information, truncated or otherwise interrupted signals are just as likely to require FEC, and AP if enabled, to successfully decode them. As I said, it is virtually impossible to eliminate this sort of false decode without compromising the purpose of AP decoding, unless information not received on air is used to make the decisions. That's the operator's job and not something that we feel WSJT-X should be attempting. Yes, examples of false decodes, along with supporting .WAV files, and settings necessary to reproduce them, are welcome but unless there is common cause that can be detected by the application, like unrealistically low SNR values combined with marginal sync detection and maximum FEC required, there's little that can be done. 73 Bill G4WJS. On 25/05/2020 12:54, Stephen VK3SIR wrote: Bill, Fully aware of that :-) Yet you have asked for reports when these occur. I am in a far-away land to many where low-level, low confidence signals are the norm and not the exception. Around 40% of the 40 contacts made today with the new version have been > -18dB. Without the reduced confidence in-use I'd be in constant RR/73 loops ! In in the last few minutes I have another .... again with a /R ! You want this one was well? 114715 -18 0.3 825 ~ VK3VM PA6UES/R R BM44 ? a2 I'll send that one as well as its now 2 in 60-odd minutes of operation. 73 Steve I VK3VM / VK3SIR -----Original Message----- From: Bill Somerville <[email protected]><mailto:[email protected]> Sent: Monday, 25 May 2020 9:43 PM To: [email protected]<mailto:[email protected]> Subject: 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
