Hi Rob, WSJT-X v2.2.1 uses the following command line options for the Deep decoding setting: " -C 500 -o 4 -d “. The “-d” option may be too intensive for low-powered machinese.
You’ll notice that the number of Fano iterations is limited to only 500. Testing here indicated that this virtually eliminated false decodes from the Fano decoder which, in turn, results in a much cleaner hashtable.txt file. Almost all of the very small number of good decodes that are obtained with your more aggressive setting "-C 5000" that are not obtained with “-C 500” end up being picked up by the OSD algorithm anyway. In addition to a cleaner hashtable.txt, v2.2 includes the decoded grid square in the hashtable. This is used to validate decodes produced by the OSD algorithm. This largely eliminates the false decodes with valid callsigns and incorrect grids that were occasionally produced by v2.1.2. 73 Steve k9an > On Jun 11, 2020, at 3:49 PM, Rob Robinett <r...@robinett.us> wrote: > > With the release of the enhanced wsprd decoder, I have published version 2.9g > of my 'wsprdaemon' system (http://wsprdaemon.org/) and upgraded some of the > 25+ WD sites to run it. > > In addition to running wsprd 2.2.1, wsprdaemon can run both that new wsprd > and old wsprd 2.1.x and compare the number of spots extracted by them from > the same 2 minute wav file. > Unfortunately, the Raspberry Pi4 at worldwide top spotter OE9GHV doesn't have > quite enough CPU power to execute both wsprds (i.e. complete execution of 48 > wsprds in one 2 minute wspr cycle) on all of the 24 antenna+band receive > channels at that site. > > However at US top spotter KD2OM the i86 CPU running WD has no problem > performing the 66 decodes required to document the decode performance on the > 33 antenna+channels at that site > You can see in the following table of spots decoded in the last 16 hours at > KD2OM, that the 20M DI (dipole) antenna channel decoded almost 6% more spots > using the new wsprd, while on other bands the difference is in the range of > 2.5-4.5%. > > So my question is: would a change to the flags passed to the new wsprd > further enhance decode performance, even if it costs more CPU time? > I am currently passing the same flags and values to 2.2.1 as I do to 2.1.1, > e.g. /usr/bin/wsprd -c -C 5000 -o 4 -f 14.0956 200611_2036.wav > During the transition from 2.0.x to 2.1.x Steve suggested adding '-o 4'. > Would the performance of the 2.2.1 wsprd benefit from a similar change? > > Thanks, > > Rob > > > plex@Plexserver:~$ show-spots > BAND ANT NEW_WSPRD OLD_WSPR > 10 BE 9 new 9 old 0.00% > 10 DI 21 new 20 old 5.00% > 10 VE 4 new 4 old 0.00% > 12 BE 1 new 1 old 0.00% > 12 DI 5 new 5 old 0.00% > 15 BE 91 new 91 old 0.00% > 15 DI 124 new 122 old 1.64% > 15 VE 95 new 95 old 0.00% > 17 BE 95 new 95 old 0.00% > 17 DI 416 new 413 old 0.73% > 17 VE 120 new 119 old 0.84% > 20 BE 1992 new 1953 old 2.00% > 20 DI 4304 new 4073 old 5.67% > 20 VE 2351 new 2297 old 2.35% > 30 BE 1563 new 1514 old 3.24% > 30 DI 2968 new 2874 old 3.27% > 30 VE 1853 new 1812 old 2.26% > 40 BE 3126 new 3048 old 2.56% > 40 DI 3625 new 3555 old 1.97% > 40 VE 2758 new 2700 old 2.15% > 60 BE 6 new 5 old 20.00% > 60 DI 0 new 0 old -nan% > 60eu BE 8 new 7 old 14.29% > 60eu DI 2 new 2 old 0.00% > 80 BE 296 new 283 old 4.59% > 80 DI 523 new 505 old 3.56% > 80eu BE 85 new 83 old 2.41% > 80eu DI 104 new 104 old 0.00% > 160 BE 211 new 192 old 9.90% > 160 DI 242 new 240 old 0.83% > 630 BE 108 new 101 old 6.93% > 630 DI 25 new 25 old 0.00% > 2200 BE 17 new 14 old 21.43% > plex@Plexserver:~$ > > -- > 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
