Joe, Here’s a link to the file that I referenced in my description of the nuisance vectors:
https://dl.dropboxusercontent.com/u/33211132/150822_1444.wav Note that this is not an isolated occurrence. Virtually every file that contains one or more decodable signals will also present a large number of nuisance vectors. On average, the ratio of nuisance/decodable vectors is more than 10:1. This is why I am focused on this - because if we can eliminate these vectors we stand to reduce, by a large factor, the time spent in the kvasd/sfrsd decoders. Another thing that occurred to me after I wrote to you last night — depending on the order in which the signal processing steps are done, maybe coherent signal subtraction could be used to reduce the amplitude of the false syncs. Steve > On Sep 15, 2015, at 7:33 AM, Joe Taylor <j...@princeton.edu> wrote: > > 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 ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
