Hi Steve,
Sorry to say, my progress has been slow today. I wanted to start by
reproducing your good-looking results using rsdtest. So far I have not
really managed to do so; I can get as many good decodes as you reported,
but not (yet?) with the sfrsd2.c attached to your email.
Could you please give me details on exactly how you built rsdtest? In
what directory, in our SVN tree? With what Makefile?
-- Joe
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<s.j.fra...@icloud.com> 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
> 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
