Hi Steve,
Some interesting results concerning JT65 symbol vectors. Your
suggestion (that these these may be false syncs obtained when stepping
in frequency across a fairly strong JT65 signal) sounds plausible. It
may be significant that the JT65 decoder was designed (and fine-tuned)
for EME, where no signal is "fairly strong" on a scale relevant for HF.
Your plan for a "dupe" filter sounds perfectly reasonable; it might
also be sensible to look at the code that allows a candidate signal to
get "down the line" far enough to produce these near dupes, without
being rejected on some other grounds.
One thing to keep in mind: JT65 is surprisingly good at decoding two or
more signals even when their tone ranges overlap somewhat in frequency.
So after a good decode we don't want to (say) kill all other
apparently valid sync conditions within a few Hz. But certainly it
seems that your "dupe test" should be OK.
Can you send me the wav file that produced those results? I'll be happy
to have a close look.
-- Joe
On 9/14/2015 8:44 PM, Steven Franke wrote:
> Joe,
> Here’s some more information about the un-decodable receive vectors that I
> have been complaining about. In extract.F90, I printed out the values of
> nhist and ipk along with mrsym(1:63) for vectors that passed by the birdie
> check. Here are the results for a file that contained only 1 decodable vector:
>
> nhist 5 ipk 37
> 1444 -12 0.1 1268 # JA6XBH PA0FVH R-18
> nhist 4 ipk 42
> nhist 4 ipk 42
> nhist 4 ipk 42
> nhist 4 ipk 42
> nhist 5 ipk 17
> nhist 5 ipk 17
> nhist 5 ipk 17
> nhist 5 ipk 17
> nhist 5 ipk 17
> nhist 5 ipk 17
> nhist 5 ipk 17
> nhist 5 ipk 17
> nhist 5 ipk 17
> nhist 5 ipk 17
>
> The first vector decoded as shown. The next 14 did not. Of the 14 that didn’t
> decode, the first 4 had nearly identical mrsym vectors and then so do the
> last 10. But none of these look at all like a birdie. I include the first two
> un-decodable vectors below:
>
> 10 30 49 24 41 54 4
> 42 41 22 26 10 36
> 25 58 5 40 9 58 2
> 8 9 4 20 4 23
> 23 19 15 46 5 16 32
> 1 51 33 57 31 19
> 60 60 62 41 41 34 53
> 29 48 34 33 25 46
> 14 27 26 9 31 50 39
> 27 22 15 5
>
> 10 30 49 23 41 54 4
> 42 41 22 26 10 36
> 25 58 5 40 9 58 2
> 8 9 4 20 4 23
> 23 19 15 46 5 16 32
> 1 51 33 57 31 19
> 60 60 62 41 41 34 53
> 29 48 34 33 25 46
> 14 27 26 9 31 50 39
> 27 22 15 5
>
> These are shown before the calls to graycode and de-interleaving. The next
> two vectors (not shown) are very simliar - they differ in only a few symbols,
> and when they differ the symbols differ by only 1, i.e. they are neighboring
> symbols.
>
> I wonder if these are produced by false syncs as you step (in frequency)
> across a fairly strong JT65 signal. That would explain why these nuisance
> vectors are almost, but not quite, the same. Maybe it also explains why they
> are seen after the one vector that did decode.
>
> Would it be reasonable to implement a “dupe” filter for candidate mrsym
> vectors, such that when the i’th vector differs from the (i-1)’th vector in
> less than N symbols (N<12), we don’t bother calling the decoder?
>
> 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
