Steve -- Some follow-up on the rare (but annoying) false WSPR decodes...
I decided to look especially at the 15 files in the wspr_data.tgz package that produced a false decode (one containing "/") in *any* of your test cases. The files are: 150426_0114.wav 150426_0148.wav 150426_0342.wav 150426_0512.wav 150426_0526.wav 150426_0530.wav 150426_0534.wav 150426_0540.wav 150426_0614.wav 150426_0616.wav 150426_0654.wav 150426_0704.wav 150426_0746.wav 150426_0856.wav 150426_1400.wav On these files I ran test cases like yours, plus two more, with the following results: Command T B G time ----------------------------------------------------------- 1. wsprd 125 2 123 25 s 2. wsprd_exp 126 13 113 29 3. wsprd_exp -J -C 5000 115 3 112 30 4. wsprd_exp -J -C 5000 -z 0.5 112 0 112 30 5. wsprd_exp -z 0.5 113 1 112 30 6. wsprd5000 120 0 120 23 7. wsprd -z 0.5 119 0 119 26 T = total decodes B = bad decodes G = good decodes Case #6 used a re-compiled wsprd with maxcycles=5000. On these files, at least, it seems that the best performer is the deafult wsprd, Case #1: 123 good decodes, 2 false decodes. With maxcycles=5000 (Case #6) it yields 120 good decodes and 0 false decodes. With bias=0.5 (Case #7) it gives 119 good decodes and 0 false decodes. Seems to me we should probably go back to bias=0.5, and possibly reduce maxcycles a bit. -- Joe ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel