Hi Joe
In case it helps in looking for the differences between WSJT and WSJT-X it
might be worth looking at what happens on JT65c. You might recall I found that
the reduction in performance on WSJT-X compared to WSJT10 for convolutional
decoding was only about 1 dB on JT65a about 6 dB on
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
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
Joe -
I hope that you have received the zip file containing the versions of the key
routines that produced the results that I reported yesterday. I sent it to your
Princeton email because the attached zip file caused the list to bounce the
message.
For the record, just now I found that
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
I have attached the sfrsd2.c that I used to produce the results reported below.
Steve k9an
sfrsd2.c
Description: Binary data
> On Oct 15, 2015, at 9:03 PM, Steven Franke wrote:
>
> Joe,
> Reporting on results of this evening’s tests on -24db gaussian noise
> no-fading
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
Correction:
> For these test files the "ntest" criterion is too stringent, so I
> removed the test commenting it out. Then all 994 candidates are
> submitted for decoding, and 662 produced valid decodes.
I should have written "662 produced valid decodes with ntrials=1".
-- Joe
Joe -
> Do you think we may need to use
> different erasure probabilities for HF and EME-like conditions?
Sorry, I didn’t answer this question. Working in between appts and meetings
here.
My aim is to come up with erasure probabilities that will work reasonably well
for both situations and,
Hi Steve,
My tests with the 1000 SimJT files were done using a narrow frequency
window, 1270 +/- 20 Hz. (The sync tone of the generated signal is at
1270.5 Hz.) The un-modified r5970 passed 992/1000 beyond the "thresh0"
filter; 990 of these produced just one synchronized candidate, and two
Hi Steve and all,
In coming days I hope to catch up with your work on sfrsd. I haven't
yet tested r5970 under crowded-band, HF-style conditions.
I did make a quick test on my group of single-signal 1000 files
generated by SimJT, with S/N=-24 dB. The program ran well and was fast,
but the
Hi Joe -
Welcome back!
Your results are consistent with mine. I got 488 decodes for the -24dB files
using the current r5970.
After mulling over the results for a few days, and after doing one more
experiment (results to follow), I’ve concluded that the new
candidate-identifying-scheme is
> On Oct 11, 2015, at 4:11 PM, Steven Franke wrote:
>
> Hi Joe and all,
>
> This message summarizes my recent work on jt65 decoding in 1.6.1.
>
> I’ve added 3 new entries to the table summarizing JT-65a decoding results on
> my batch of 333 20m .wav files.
>
>
Hi Joe and all,
This message summarizes my recent work on jt65 decoding in 1.6.1.
I’ve added 3 new entries to the table summarizing JT-65a decoding results on my
batch of 333 20m .wav files.
Program Good Bad SoftDecoder
14 matches
Mail list logo