Reino Talarmo kirjoitti 26.5.2020 klo 12.33:
In Saku's example false decodes are due to noise. Decoder can detect even an empty band synchronization patters with a probability that is not very low and continues decoding and error correction. You could continue error correction actions 'forever', but at some point you 'give up' and assume you got a message. At that point it may or may not be a real one. In the message there are also error detection bits and those are used to filter out most of the fake/false messages. It is always a compromise how many bit are used for error detection and how many for information.
With those samples result is always same what ever selection decode has (Fast, Normal, Deep) or is AP enabled or not. So they happen to be "cleanly rubbish".
Of course, after getting decode result the line could go through process where at least locator, maybe also callsign prefix, is checked against standards what they could be in real life. But on the other hand it is good to give some work also for operator's brains.
I am not very concerned about false decodes. There has always been those and usually they are easy to find as result is total nonsense.
Interesting part here is that there are no AP decoding marks at the end of line and that now with version 2.2.0 those kind of false decodes have now started to appear. Previously they have almost 99% been AP-marked ones that one can expect to be nonsense.
I think we just have to accept that nothing is perfect. Even with this great software that has opened totally new level to get qsos in poor conditions and/or equipments.
-- Saku OH1KH _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
