Thanks Joe - Your results in cases 1,3,4,5,7 agree with mine, to within a few decodes either way. All of my runs were on OS X with sfrsd compiled using gcc - but perhaps this produces a different set of random erasure vectors than either linux or windows. Just now, I’ve also confirmed your result from case 9 as well, running WSJT10 in a virtual Ubuntu 14.04 machine running under VMware on OS X. I got 813 total decodes (BM+KVASD). Wow. I was feeling pretty good about sfrsd until I saw that result.
I will poke around at this and see what I can figure out. Thanks for taking time out to confirm my results! - it gives me a lot more confidence about what I’m doing over here. Steve k9an > On Sep 23, 2015, at 3:13 PM, Joe Taylor <j...@princeton.edu> wrote: > > Hi Steve and all, > > Here's an update on my tests of decoding weak JT65A signals. I used > 1000 files generated by SimJT, each containing one JT65A signal at > S/N = -24 dB. I am using current code revisions of WSJT-X v1.6.1 (with > minor edits noted below) and WSJT v10.0. > > For each line in the following table the final number is the number of > valid decodes. None of the tests yielded any false decodes. > > 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 > > Test 4 set thresh0=1.0 rather than 1.5 in jt65a.f90. Tests 5 and 6 used > Steve's small changes to demod64a.f90 and extract.F90. Tests 7 and 8 > used these and also set thresh0=1.0. Tests 9 and 10 used the default > WSJT v10.0. I believe the small differences in tests 5-6 and 7-8 are > the result of using different random number generators in Linux and > Windows. (The resulting random numbers generate the stochastic erasure > patterns used in Steve's algorithm.) > > Unless I've made a mistake somewhere, these results show clearly that > for marginal, isolated signals, none of the decoding schemes currently > being tested in WSJT-X reach the sensitivity provided by WSJT 10.0. > > To me the decoding superiority of WSJT is surprisingly large, even > though it probably amounts to slightly less than 1 dB. (See, for > example, the steep curves for "percent copy vs. S/N" in Figure 4 of > http://physics.princeton.edu/pulsar/K1JT/JT65.pdf or Figure 2 of > http://physics.princeton.edu/pulsar/K1JT/K1JT_eme2006.pdf .) > > It seems we would be well advised to look in detail at the (probably > rather minor) code-tuning differences in the late stages of processing > JT65 signals in WSJT and WSJT-X. An important question will be whether > we can simultaneously obtain near-optimum weak-signal sensitivity along > with acceptable decoding speed and all-around performance in a band > filled with many signals. > > It should also be instructive to try sfrsd as the final JT65 decoding > step in WSJT 10.0. > > -- Joe, K1JT > > ------------------------------------------------------------------------------ > Monitor Your Dynamic Infrastructure at Any Scale With Datadog! > Get real-time metrics from all of your servers, apps and tools > in one place. > SourceForge users - Click here to start your Free Trial of Datadog now! > http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
