Hi Steve,
Thanks for being skeptical about implications of my conclusion that
candidate selection is OK in r5970, at least for the simulated -24 dB
"gnnf" files.
I think your results make a strong case that while the correct
candidates for decoding were identified in nearly all cases, the
time-and-frequency synchronization necessary to produce the data in
array s3 was not as good as that used to produce the test file
s3_1000.bin. That task had been done from within WSJT, in which the
code related to JT65 has been carefully tuned for EME-like conditions.
I will spend some time looking at differences in the way WSJT and WSJT-X
are currently doing the time-and-frequency synchronization.
-- Joe, K1JT
On 10/15/2015 10:03 PM, Steven Franke wrote:
> Joe,
> Reporting on results of this evening’s tests on -24db gaussian noise
> no-fading (gnnf) data. As always in these tests, the number of test files is
> 1000.
>
> I started with sfrsd2 from the current r5970 and opened up the acceptance
> criterion to nhard+nsoft<81. The purpose of doing this is to find out how
> many potentially good decodes are in the set of candidates that are presented
> to the decoder.
>
> I ran this sfrsd2 in rsdtest using matched sf metrics and sf gnnf erasure
> probabilities. I used your s3_1000.bin file.
>
> ntrials ngood
> 0 5
> 1 26
> 10 206
> 100 511
> 1000 736
> 10000 854 + 3bad
>
> I’d call this very good performance.
>
> Next, I dropped the sfrsd2.c that was used with rsdtest back into the current
> wsjt-x, which I set up to use 10000 trials. I zero’d the ntest threshold.
> Using the sf metrics and using my batch of -24db files, I get only 735
> decodes - about the same as I was getting with ntrials=1000 in rsdtest.
>
> So this seems to support my notion that something may not be completely right
> with the syncing or final peakup of dt and f0, or some other thing upstream
> from demod64a in this latest version. Maybe the next step should be for me to
> drop the same sfrsd2.c into whatever version you used to generate the
> s3_1000.bin file. Do you remember what version that was?
>
> Steve k9an
>
>> On Oct 15, 2015, at 6:32 PM, Steven Franke<[email protected]> wrote:
>>
>> Joe,
>>
>>> I conclude that for these files the candidate selection is OK
>>> (preferably with a somewhat higher threshold for ntest), but sfrsd is
>>> not decoding as many as it "should". I suspect that for marginal
>>> signals either different metrics or different values in the probability
>>> matrix will yield better results.
>>
>> Hmm.
>>
>> I was totally focused on hf performance and the differences between the
>> number of BM only decodes between the old and new sync schemes. I see now
>> that I have broken something for the -24dB gaussian-noise no-fading case…
>> I’ll investigate.
>>
>> Steve k9an
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> wsjt-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
