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 >>> <mailto: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 >>> <mailto:wsjt-devel@lists.sourceforge.net>> wrote: >>> > On Oct 26, 2018, at 2:21 PM, Jim Lill <j...@jimlill.com >>> > <mailto: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 <mailto:wsjt-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >>> <https://lists.sourceforge.net/lists/listinfo/wsjt-devel> >>> >>> >>> >>> -- >>> Rob Robinett >>> AI6VN >>> r...@robinett.us <mailto:r...@robinett.us> >>> mobile: +1 650 218 8896 >> >> >> >> >> >> _______________________________________________ >> wsjt-devel mailing list >> wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> <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
