Hi Steve, I was not aware of the additional command line flags until your email and a chat from Jim. It does increase CPU utilization enough that a Pi can no longer perform two wsprd decodes on each of the 11 bands, so I have divided the bands across 2 Pis. In addition, I have modified my script to completely isolate the decodes into separate directories. I am running with C 10000 rather than 5000. It seems to cost little in cpu cycles, but I will take your directions on the optimal values.
Running with those changes for the last two hours, I can see that KPH2 has logged 577 spots in the last hour, while KPH has logged only 494 spots. These results are so good that I am inclined to switch the calls so that KPH doesn't fall even further behind you and others in the top spotters list ;=) Thanks for all of your excellent work on WSJT-x and WSPR. This technology has revived my interest in ham radio after 40 years of dormancy. 73, Rob AI6VN On Sat, Oct 27, 2018 at 9:28 PM, Steven Franke via wsjt-devel < wsjt-devel@lists.sourceforge.net> 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 > > -- 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
