Hi Steve Thanks - yes the trap of small sample size caught me :-(
I also fixed the other problems I reported earlier, and learned a lesson (do NOT use MS Powerpoint to edit and copy command lines from). This is why I could not get -G and -F to work. Also, it often throws up slanted inverted commas, which also don't work. Since moving to Notepad all is now fine. Charlie -----Original Message----- From: Steven Franke [mailto:[email protected]] Sent: 02 January 2018 14:50 To: WSJT software development Subject: Re: [wsjt-devel] Inconsistent JT65b reporting Hi Charlie, Bill, and all, > I also tried 40Hz spreading at -23 with 11025 with WSJT-X and found AP and > no DS did not decode anything, whereas it gets 2/10 with 12000 sample > rate. It does OK however with DS with these -23/40Hz 11025 signals. > Perhaps the resampling on very marginal signals like this is responsible? I think that you need to look at a larger sample to decide whether or not the decode probability is different between the two sample rates. I used the following to generate 100 JT65C files at SNR=-23 dB with 40 Hz Doppler spread, at sample rate 12000 /s: ./jt65sim -d 40.0 -m C -n 1 -F 1200.0 -t 2.5 -f 100 -s \\-23 -G 10 -M "K9AN G3WDG RRR" With AP decoding enabled, G3WDG in the Dx Call box, and Tx5 selected, I got 34/100 decodes. All decodes were AP decodes with aptype=3 or 4. Deep Search was not enabled. Then, I repeated the experiment with -S added to the command line so that the files were generated with 11025 /s rate. When WSJT-X detects a wav file with 11025/s rate, it calls Joe's wav12.f90 resampler to resample the data to 12000/s. In this case I got 38/100 decodes. It's worth noting that we expect the number of good decodes to have a binomial distribution. The standard deviation of the binomial distribution is sigma = sqrt( n*p*(1-p) ) where n is the sample size and p is the decode probability. My results with 100 simulated wav files suggest that the decode probability for the case that we are considering is somewhere in the neighborhood of 0.36. With a sample size of 100, and p=0.36, the standard deviation of the binomial distribution is sqrt(100*0.36(1-0.36))=4.8. Thus, the difference between my results with sample rate 12000 (34/100 decodes) and sample rate 11025 (38/100) is not statistically significant, i.e. the observed differences are of the same order as the differences that we'd expect if we just processed two different groups of files, with the same underlying decode probability for each group. In summary, there is no evidence (so far) that resampling in WSJT-X causes any degradation in decoding performance. It would take many more trials (>1000) to be able to detect any differences in WSJT-X's decode probability at the two sample rates. Of course, this experiment does *not* address what happens when the operating system does the resampling, as would be the case when processing audio data in real time. Steve k9an ---------------------------------------------------------------------------- -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
