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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
