Joe - For the record, here are the results of analyzing 1000 SimJT JT65A files with sync level set to 0 (a setting of -1 gave the same results) and with Rx frequency set equal to the simulated signal’s frequency:
kvasd (this result should be for the high-effort “on frequency” setting): 198/1000 (20%) sfrsd 5000 trials, p1 metric, erasure probabilities 0.5, 0.6, 0.6, 0.6, 0.8: 157/1000 (16%) sfrsd 10000 trials, p1 metric, erasure probabilities 0.5, 0.6, 0.6, 0.6, 0.8: 182/1000 (18%) sfrsd 20000 trials, p1 metric, erasure probabilities 0.5, 0.6, 0.6, 0.6, 0.8: 201/1000 (20%) - Overall yield roughly doubled when the sync threshold was lowered from the wideband setting to the on-frequency setting. - The results confirm that sfrsd is capable of achieving the same decode probability as kvasd on weak simulated signals. You have probably already noticed the fact that the sfrsd should be easy to parallelize. It should be possible to test a bunch of candidate vectors at once. Perhaps that is something worth investigating for sfrsd. In an earlier thread, Bill had suggested that using Qt’s threading facility is the way to go, in general, for WSJT-X — but it’s not clear to me if that applies for this stand-alone C program. Steve k9an > On Sep 19, 2015, at 5:03 PM, Steven Franke <s.j.fra...@icloud.com> wrote: > > I have just now realized that the sync threshold is higher for “off > frequency” signals. Since I had set Rx freq to 3000, the results reported > below were obtained using the higher wideband sync threshold. That probably > explains the lower than expected yield. I’m re-running with Rx frequency set > equal to the simulated signal’s frequency… > Steve k9an > >> On Sep 19, 2015, at 2:57 PM, Steven Franke <s.j.fra...@icloud.com> wrote: >> >> Thanks Joe! This has been a fun project, and I’m learning a lot from it. >> >> I used your SimJT program to generate 1000 JT65A files at -24 dB SNR. Here’s >> what I get: >> >> kvasd (with Rx frequency set to 3000, so this should be the low-effort >> setting): 106 decodes out of 1000 (10.6%) >> sfrsd 5000 trials: 94 decodes (9.4%) >> sfrsd with 10000 trials: 112 decodes (11.2%) >> >> I expected higher percentages overall at this SNR but, in any case, the >> results seem to confirm that sfrsd is a viable decoder. I noticed that only >> a fraction of the files result in a vector being submitted to the decoder - >> maybe around 50% - I didn’t count carefully. Maybe this is another reason to >> take a look at the upstream processing. I think that your earlier results >> showed something closer to 40% at this SNR. >> >> Also, I am surprised at how little guidance the soft information is >> providing with the settings that we are using. Almost none, as it turns out. >> Note that if I change just the two probabilities that I use to set the >> erasure frequency of the “best” and “worst” symbols, such that all of the >> probabilities are the same, then we wouldn’t even need to sort the data >> according to probability (for the stochastic patterns), i.e. we would be >> using no soft information whatsoever! The results would change - but we’d >> be in the same ballpark. This makes me feel like one or both of the >> following might be true: >> >> 1. it may be possible to achieve the same results with fewer trials if the >> soft-symbol information was utilized in a smarter way >> >> and/or >> >> 2. the quality of the presently used soft-symbol information is so bad that >> it’s not worth using. >> >> In 2, I do not mean to say that there is something wrong with the signal >> processing. Instead, I’m wondering if information only on 2 of 63 symbols is >> just too watered down to be useful. >> >> Steve k9an >> >> >>> On Sep 19, 2015, at 2:11 PM, Joe Taylor <j...@princeton.edu> wrote: >>> >>> Hi Steve, >>> >>> I've looked again at the innards of sfrsd. I'm *much* impressed by what >>> you have done. >>> >>> Soon, it may be time to look again at the upstream decisions made in the >>> JT65 decoding chain -- decisions that determine what symbol vectors are >>> passed on to the actual decoder. Among other things to consider: >>> various parameters affecting those decisions were optimized (a long time >>> ago) for the EME situation with very weak signals, little if any QRM, >>> and only one or two signals in the Rx passband at a time. For HF use we >>> might want to change some of these parameters. >>> >>> -- Joe, K1JT >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> wsjt-devel mailing list >>> wsjt-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> wsjt-devel mailing list >> wsjt-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
