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
