Hi Steve,
wouldn't it be a good idea to include those hints as "known issues" in
the the release notes for the current version, because several users
have reported those false decodesrecently. I've had a couple of those,
too. I remember that in several sections of the user guide it is
recommended to set the decode depth to "deep"for other modes, but
without the given background info people don't see a reason why not to
use deep in FT8, too.
Just a thought.
Vy 73 de Joe, DL6ZBN
Am 24.01.2019 um 14:23 schrieb Steven Franke via wsjt-devel:
Hi Paul,
Recently, we’ve introduced a couple of techniques that have significantly
improved the sensitivity of WSPR-2. Increased sensitivity comes with higher
probability of false decodes. The next release of WSJT-X will fix a bug that
should eliminate some of those false decodes - but it will not address either
of the issues that you have observed. You might consider running with decode
depth set to “Normal” rather than “Deep”. This will give you the same
performance that was available under the “Deep” setting in earlier versions of
WSJT-X. You will lose a couple of dB in decoding sensitivity, but you will also
see fewer false decodes.
73 Steve, k9an
On Jan 24, 2019, at 4:03 AM, N1BUG <[email protected]> wrote:
I want to report two new behaviors with WSPR in 2.0.0 that were not
occurring with prior versions.
1. Occasionally a known / real call sign will decode with an
incorrect grid. Usually the grid is thousands of miles from where it
should be, sometimes in the arctic or the middle of an ocean. A look
around WSPRnet confirms this is not limited to me.
2. I have always had the occasional spurious decode while
transmitting, due to all the noise of receiver overload I presume. I
use separate receiver and transmitter (LF and MF). Usually it is
14MDA LR90. Prior to 2.0.0 it would happen a couple times a day or
so. What is new in 2.0.0 is that once this decode comes up once, it
keeps coming up every few minutes if not every transmission. If I
delete hashtable.txt or remove the 14MDA entry from that file, it
will then be several hours before I get another of those decodes.
Note: I am not yet certain whether not having hashtable.txt prevents
the first odd behavior. I am now running a script which deletes that
file after every decode period in an attempt to find out, but it
will take some time to be sure. Fortunately WSJT-X does not seem to
mind finding itself deprived of hashtable.txt and just silently
re-creates it.
73,
Paul N1BUG
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
