Hi Steve, Thanks for the reply. Can you be any more specific about what setting decode to "Normal" does, please? I couldn't find it documented anywhere but probably I am just being inept.
I am aware of two recent changes to the WSPR decoder. One came in 1.9, where I believe inherent phase stability at LF and MF was used to good advantage. I did extensive side by side testing of that with the previous version and found this an excellent change. I would not want to lose that one. The other change I am aware of came in 2.0 where hashtable.txt is used to assist very weak signal decoding for known call signs. This change I would very much like to "lose" permanently. I find the apparent cost of this increased sensitivity too high for my liking. I am intelligent enough to recognize false decodes and ignore them. Unfortunately they get into WSPRnet data and clutter things up, for which I know of no solution. 73, Paul N1BUG On 1/24/19 8:23 AM, Steven Franke via wsjt-devel wrote: > 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
