Hi Steve and all,
Thanks for passing on your test results with JT65 signal subtraction.
Very interesting!
> There are a couple of things that need to be looked at in more
> detail — I had to add a mysterious 1s offset to the “dt” parameter,
> and I don’t understand why this was necessary.
In the WSJT slow modes PTT is nominally asserted at t=0 s and audio
starts at t=1 s in a UTC minute. SimJT generates wav files in which the
noise starts at t=0 and signal starts at t=1. I guess this is
essentially what you observed?
> Also, I’m not happy with the relatively large glitches that occur
> at each symbol transition. It may be that the time synchronization
> is in WSJT-X coarser than I am used to from the wspr subtraction
> exercise - or perhaps I don't have the dt offset set correctly.
I haven't yet looked at or tried your subtraction routine, so I can't
comment in detail. You're probably right that the time synchronization
is not quite good enough to assure clean subtraction of a decoded
signal, near the symbol boundaries. (BTW: this is one of the things
presently done somewhat differently in WSJT and WSJT-X.)
I agree that we'll probably get most of any available improvement in
decoding with a two-pass scheme, as we have done in WSPR.
You may have noticed I've been playing with another test program,
rsdtest0[.exe]. It starts out with the arrays mrsym, mrprob, and
mr2sym, as computed by demod64a.f90. It then does a quick attempt at
what one might call "experience-based decoding" before calling sfrsd2.
By this I mean a scheme in which a list of plausibly likely messages is
encoded using encode_rs_int() and tested for soft distance from the
observed mrsym, mrprob, mr2sym, information in the same way we do it in
sfrsd2. If any of these produces an acceptably small value for
nhard+nsoft, we're done -- with no need to do the potentially expensive
random-erasures loop in sfrsd2. In effect, we're testing some likely
codewords before going on to look for others that we couldn't guess.
A list of some of the most interesting plausible messages can be quickly
made from a table of previously decoded call+grid combinations, perhaps
limited to decodes on the currently active band or propagation mode
(such as EME or scatter). The messages might have the form
MyCall Call Grid
CQ Call Grid
...etc.
Here's a short summary of early results, using our group of 1000 SimJT
files with S/N = -24 dB:
neme nexplim decodes time
---------------------------
0 0 811 231 s
0 72 904 101
0 90 1000 1.6
1 90 1000 0.5
With neme=0 the program uses all 5651 callsigns found in a particular
CALL3.TXT file found on my development machine. With neme=1 it uses
only the 1769 calls marked as being active on EME.
Parameter nexplim is the specified limit below which a soft distance is
deemed acceptable, and setting nexplim=72 provides the same limit now
hard-coded in sfrsd2.c. In effect, we try to find the correct codeword
by guessing what it might be, and then testing the guess to see if it's
correct. If the transmitted message is one of those in the list of
guesses, we can get the same answer that we'd get by setting ntrials to
a very large number -- but we get it almost immediately. The speedup is
more than a factor of 100.
A similar approach has been used for years in WSJT. For the EME case,
where the number of active stations is no more than a few thousand, it
works extremely well.
-- Joe, K1JT
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
