Hi Joe, RR on all. > I still need to trace (and correct?) the reason that the identical > sfrsd2 gives somewhat fewer decodes when called from within WSJT-X than > when called from WSJT. Evidently some step in the path to evaluating > array s3() is now sub-optimal in WSJT-X -- at least for idealized, > threshold-SNR data.
Yes - but I can’t help adding that even if we don’t consider WSJT performance, the current WSJT-X version does 6% or so worse than older WSJT-X versions (e.g. released version 1.5) on my hf files - even with soft-decoding taken out of the picture (BM only). Released version 1.5 produces 2551 BM-only decodes (I replaced kvasd with a dummy bash-script that returns 0), whereas the current version with ntrials=0 produces only 2387. > One more idea: I think we should try a scheme similar to what we've done > in the WSPR decoder. After a successful decode of whatever signals are > found in the analyzed passband, subtract those signals from the raw data > and then make a second decoding pass. On a crowded HF sub-band, and > also in an EME pileup situation, I suspect that additional decodes will > be possible. Yes - and in addition to producing a few more decodes, I suppose that if we were to subtract the largest signals first, immediately after they are decoded, that this might reduce the number of spurious syncs (reduce the false alarm probability). What I have in mind is to try using a high sync threshold on the first pass (to completely avoid spurious syncs) — then reduce the sync threshold after the big signals have been subtracted out. Steve k9an ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
