Hi Steve and all,
I've added more lines to the table summarizing my tests of decoding
weak, isolated JT65A signals. As before, the final number on each line
is the number of valid decodes from a thousand files at
S/N=-24 dB.
1. WSJT-X (BM only) 2
2. WSJT (BM only) 5
3. WSJT-X + kvasd 189
4. WSJT-X + kvasd (thresh0=1, ntest>0) 207
5. WSJT-X + sfrsd (Linux) 302
6. WSJT-X + sfrsd (Win32) 309
7. WSJT-X + sfrsd (Linux, thresh0=1) 348
8. WSJT-X + sfrsd (Win32, thresh0=1) 350
9. WSJT + kvasd (Linux) 809
10.WSJT + kvasd (Win32) 809
11.WSJT + sfrsd (10000) 464
12.WSJT + sfrsd (SFM no ntest 10000) 519
13.WSJT + sfrsd (SFM no ntest 20000) 543
14.WSJT + sfrsd (SFM no ntest 1000) 342
15.WSJT + sfrsd (SFM no ntest 100000) 706
16.WSJT + sfrsd (SFM no ntest 1000000) 786 (took 11 hours!)
17.WSJT + kvasd (SFM no ntest) 897
Test 11 simply replaced kvasd with sfrsd, with no other changes. Tests
12-16 used Steve's metrics for the symbol probabilities in demod64a.f90
and commented out the following lines in extract.F90:
! if(ntest.lt.50 .or. nlow.gt.20) then
! ncount=-999 !Flag bad data
! go to 900
! endif
The number of random erasure vectors is specified for each of these
runs. Test 17 is a final run using kvasd.
With "reasonable" numbers of random erasure trials, sfrsd seems to be
something like 0.5 dB shy of the sensitivity of kvasd. Steve, I know
you have already done some parameter-tuning for sfrsd, but possibly
there's still room for improvement? How did you choose the values 0.5
0.6 0.6 0.6 0.8 and the step locations 32 128 196 256, lines 197-207 in
sfrsd.c ? Have you thought about other possible ways to speed up the
search by eliminating some candidate erasure vectors?
-- Joe, K1JT
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
