This message answers some questions I had about the ALL_WSPR.TXT file. Since I started using the WSPR mode of WSJTX the number of fields in a ALL_WSPR.TXT line has been increasing. Is there a plain text explanation (one that doesn't involve reading through the source code) of all the items ?
Regards David Owen GM1OXB On Sun, Oct 28, 2018 at 4:59 PM Steven Franke via wsjt-devel <wsjt-devel@lists.sourceforge.net> wrote: > > Jim, > The number in question is the total Fano path metric for the returned > codeword. When the last number is 1, that means that the Fano algorithm > failed. In such cases, the path metric is just set to its maximum possible > value, 810. > Steve k9an > > On Oct 28, 2018, at 11:31 AM, Jim Lill <j...@jimlill.com> wrote: > > Steve, > > What does the number before the 0 or 1 in ALL_WSPR.TXT represent? I see it as > 810 when there's a 1 (new algo) decode > > > -Jim wa2zkd > > > On 10/28/2018 12:28 AM, Steven Franke via wsjt-devel wrote: > > Hi Rob - > > Are you using the same command-line arguments that WSJT-X uses when it calls > the decoder? The “Deep” decode setting in WSJT-X v2.0.0-rc3 uses “-C 5000 -o > 4”. > > Also, it is essential that the decoder in v2.0.0 have access to a > well-populated hashtable.txt. Briefly, the enhanced sensitivity is obtained > by invoking a new (to wsprd) decoding algorithm if the Fano algorithm fails. > The new algorithm always returns a codeword, but only a fraction of these are > “good”. Many of the returned codewords are incorrect and would produce false > decodes. Ideally, one would use a CRC to reject the incorrect codewords (as > in FT8), but the WSPR message doesn’t include a CRC. Instead, we only accept > codewords that unpack to callsigns that we’ve seen before, i.e. callsigns > that are in the hashtable. If there’s no hashtable, then we will never accept > any of the codewords from the new algorithm. This means that the v2.0.0 > decoder becomes more sensitive than 1.9.1 to a particular callsign only after > that callsign has been decoded at least once by the Fano algorithm. > > Finally, decodes produced by the new decoding algorithm will have a “1” as > the last number on the line that is printed in ALL_WSPR.TXT. Fano algorithm > decodes will show a “0”. > > I’ve been very pleased with the results here. There have been many nights > when all of my MF decodes of VK4YB were produced by the new algorithm. > > I hope that this information is helpful, > > 73 Steve k9an > > On Oct 27, 2018, at 10:27 PM, Rob Robinett <r...@robinett.us> wrote: > > Hi Steve, > > Jim's question was stimulated by tests I have been running at KPH to compare > the decode performance of the wsprd in 1.9.1 against the wsprd in 2.0rc3 > > My test setup is located at KPH where I have one KiwiSDR fed by a 3-30 Mhz > TCI-530 and a second KiwiSDR fed from a Marconi T. I don't use the excellent > wspr decode extension included in the Kiwi, but instead run a bash script on > a Raspberry Pi 3B which records a 2 minute wav file for each band from 2200M > through 10 M. Each 2 minutes wave file is then fed first to wsprd 2.0 and > logged as KPH2 and then the sme wav file is fed to wsprd 1.9.1 and logged as > KPH. After 24 hours I can find no difference between the KPH spots and KPH2 > spots. > > The wsprd binaries were obtained by downloading and installing packages from > the WSJT-x site and the binaries definitely are different sizes: > > pi@KPH-Pi2:/tmp/kiwi-captures $ lrt /usr/bin/wsprd* > -rwxr-xr-x 1 root root 46376 May 30 17:32 /usr/bin/wsprd > -rwxr-xr-x 1 pi pi 79972 Oct 16 21:32 /usr/bin/wsprd.v2 > pi@KPH-Pi2:/tmp/kiwi-captures $ > > I can see from 'top' that my script is first executing wsprd.v2 and then > wsprd, so I am confident in my test methodology. > Perhaps I am misusing wsprd. Before processing each wav file I truncate the > ALL_WSPR.TXT file but leave the other files used by wsprd alone. Could the > two wsprd versions depend up the history in ALL_WSPR.TXT or be sharing > information in wspr_wisdom.dat or the other support files which influence the > results? > > Thanks, > > Rob > AI6VN > > > > > > On Fri, Oct 26, 2018 at 3:37 PM, Steven Franke via wsjt-devel > <wsjt-devel@lists.sourceforge.net> wrote: >> >> > On Oct 26, 2018, at 2:21 PM, Jim Lill <j...@jimlill.com> wrote: >> > >> > What is the method to verify my system is indeed enjoying the 1 dB SNR >> > improvement that 2.0 gives? >> > >> > Thanks >> > >> > Jim >> > >> > WA2ZKD >> >> Hi Jim, >> >> You might try turning on “Save All” and running for, say, 24 hours or even a >> couple of days. Then you can decode the saved batch of wav files using older >> versions of WSJT-X and with new versions, and compare the yield. >> >> Suppose that you want to compare the WSPR decoder in WSJT-X v 1.9.1 to >> WSJT-X v 2.0.0-rc3. >> >> 1. Run with Save All to save a large batch of wav files. >> >> 2. Delete ALL_WSPR.TXT. Start WSJT-X v 1.9.1 and use "File/Open" to select >> the first (earliest) wav file in the batch that you saved. This will cause >> WSJT-X to process that file. Next, select "File/Decode remaining files in >> directory" to process the rest of the files. When you have finished >> processing all of the files, ALL_WSPR.TXT will contain all of the decodes. >> Rename ALL_WSPR.TXT to something different, such as ALL_WSPR_1.9.1.TXT, so >> that it will not be overwritten or appended to by subsequent runs. >> >> 5. Make sure that you have moved ALL_WSPR.TXT to a new filename. Start >> WSJT-X v 2.0.0-rc3. Process all files. Rename your ALL_WSPR.TXT, e.g. to >> ALL_WSPR_2.0.0.TXT. >> >> 6. Use your favorite tools to compare the decodes in ALL_WSPR_1.9.1.TXT and >> ALL_WSPR_2.0.0.TXT. >> >> Here are some results that I obtained back in September: >> >> Bands monitored: 160/80/40/30/20/17/15/10 (these were monitored >> simultaneously, using my SDR setup) >> Start: 2018.09.13 0128 >> Stop: 2019.09.18 2046 >> >> Total 1.9.1 decodes: 45344 >> Total 2.0.0 decodes: 52126 >> >> (Number of 2.0.0 decodes) / (Number of 1.9.1 decodes) = 1.15 >> >> Thus, 2.0.0 increased the yield by 15%. >> >> Note that WSJT-X v1.9.1 contains enhancements that improve sensitivity over >> that of v1.8 and prior versions for highly coherent signals, as obtained on >> LF/MF and sometimes, on 160m. Thus, I would expect a somewhat larger yield >> difference if v2.0.0 was compared to v1.8. FWIW, the improvements in 2.0.0 >> are expected to increase sensitivity for all signals, regardless of how >> coherent they are. >> >> YMMV! >> >> Steve k9an >> >> >> >> _______________________________________________ >> wsjt-devel mailing list >> wsjt-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > > > -- > Rob Robinett > AI6VN > r...@robinett.us > mobile: +1 650 218 8896 > > > > > > > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
