Hi Steve, Thanks for your response from which I infer that I can't decode FST4W type 3 spots with jt9 by invoking it anew for each new wav file.
I see that WSJT-x on my Mac runs a persistent instance of jt9 that listens for wav files on a shared memory segment which allows jt9 to build and retain a hash table. Is there a utility or diagnostic program in the WSJT-x package used to test the shared memory input to jt9? Lacking that, is there any description of how to use that shared memory interface so I could create a utility program to read wav files and feed them to jt9? Thanks, Rob On Mon, Jun 13, 2022 at 5:19 AM Steven Franke via wsjt-devel < wsjt-devel@lists.sourceforge.net> wrote: > Rob, > > The fst4w_calls.txt file is not used to resolve the hash in type 3 FST4W > messages. It is used to validate decodes obtained when jt9 is called with > the “-d 3” option, which enables a decoding pass that treats the FST4W > message’s CRC bits as if they were parity bits rather than message bits. > This trick decreases the size of the space that we have to search for > codewords by many orders-of-magnitude in trade for giving up the ability to > discriminate against false decodes that is normally provided by the CRC. > The fst4w_calls.txt file provides a memory of calls that have previously > been decoded using the standard CRC-protected decoding method. This memory > is used to reject false decodes whenever we use the CRCless decoding > approach. > > Note that the fst4w_calls.txt file is written to disk only when jt9 is > called with the “-d 3” option. > > The hash table that is used for resolving callsigns in the “type 3” > messages is maintained internally in jt9 and is not written to disk. > > Steve k9an > > On Jun 12, 2022, at 8:41 PM, Rob Robinett via wsjt-devel < > wsjt-devel@lists.sourceforge.net> wrote: > > Hi, > > In version 3.0 of my wsprdaemon software for Linux systems ( > http://wsprdaemon.org/) I am decoding FST4W by running 'jt9 --fst4w ...' > jt9 outputs spot lines for type 1 spots, but for a type 3 spot which > follows it in the next WSPR cycle jt9 always outputs the callsign '<...>' > I can see that the file 'fst4w_calls.txt' is created when WSJT-x decodes > those same spots, and I suspect that file is used to look up the hashed > calls in a type 3 packet, but that file is never created when I run jt9 > standalone on Linux. > The format of fst4w_calls.txt is simple and my code could create it for > jt9, but inspecting "fst4_decode.f90" with my limited familiarity with > Fortan suggests that jt9 will maintain that file in the same way "wprd" > does its hash table file. > > So how can I get jt9 to resolve the hashed calls in type 3 FWT4W spots? > > I now have 30 receive sites worldwide listening for FST4W spots 24/7/365, > and solving this hashed calls problem will complete their ability to report > all FST4W transmissions. > > Thanks, > > Rob > > > -- > Rob Robinett > AI6VN > r...@robinett.us > mobile: +1 650 218 8896 > _______________________________________________ > 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 > -- Rob Robinett AI6VN r...@robinett.us mobile: +1 650 218 8896
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
