Note:
The following post is specific to WSJT-X v2.3.0-rc1. It may not apply to subsequent versions.
* * *
As a heavy user of K1JT's WSPR and operating on the 2200 and 630 meter bands, I have noted with interest the introduction of the "FST4W" mode in the recent (v2.3.0-rc1) wsjt-x release. Operating using the same detection bandwidth as WSPR (when FST4W is operated in the 120 second mode) it offers a theoretical 1.4dB improvement in detection sensitivity.
Being involved with wsprdaemon (link to that project here ) - an open-source project that automates and optimizes reception of WSPR signals on all bands, particularly if multiple receivers/antennas are used - we have been watching this development with interest, particularly since FST4W has the likelihood of supplanting conventional WSPR operation, especially on the lowest amateur bands (2200, 630 and possibly 160 meters) where a minimum of Doppler shift is likely.
Internally, WSJT-X uses the subordinate wsprd program as the decoding (and encoding) engine. As a stand-alone program, the wsprd executable code may be invoked with a command line to decode signals contained within a .wav file that was captured during the standard two minute interval - aligned with the even UTC minutes - and produce a text file containing the decoded signals.
Why use the executable rather than the entire wsjt-x suite? The fact is that the use of the wsjt-x suite does not lend itself to script-driven, bare-minimum, lightweight implementations where further processing of the decoded data (to remove duplicate decodes from multiple receivers, antennas and to use this same data for further analysis of signal/noise) is desired.
The "jt9" executable:
After a bit of digging about, it was "discovered" that FST4W - being an offshoot of the JT9 protocol - was handled not by the wsprd executable, but the jt9 executable. Simply executing this program with no arguments will yield a list of command-line arguments which, on the face of it, made it appear that updating the wsprdaemon would be a relatively simple matter.
Except that it didn't work.
Initial testing with strong, off-air FST4W signals that was known to be decodable (because farther-flung stations were able to decode the very same transmissions) yielded no results when the .wav file was applied to the jt9 program - but automatic execution over many hours yielded the occasional decode. Confused by this, I sought help on the WSJT-X groups.io forum. Fortunately, Joe Taylor and several of the developers offered a clue: The "-f" parameter of the jt9 executable, described minimally as "Receive Frequency Offset".
Apparently, the default center frequency of the jt9 executable - at least when in FST4W mode (and maybe others) is 1500 Hz - a fact implied when one gets the display of command-line arguments. What is not so clear - and only alluded to in the available documentation - is that the apparent bandwidth of the decoding - at least in the 120 second mode - is on the order of 40 Hz (+/- 20 Hz).
At a quick glance through the source code (file "jt9.f90"), this bandwidth setting appears to be hard-coded into a shared variable (apparently accessible by other programs in the WSJT-X suite) called "ntol"(likely a number referring to the "frequency tolerance" setting in the GUI) that is not available via the jt9 command line - at least, not without modification of the source code. (The possibility of directly accessing these shared variables exists - but this is platform-specific, a bit messy and somewhat dangerous!)
Unfortunately, this fixed +/-20Hz bandwidth does not appear to be compatible with the way that the FST4W mode has (already!) found use on 2200 and 630 meters where it is used along-side the WSPR mode in the 200 Hz subbands.
A hell of a kludge:
This fact implies that in order to use something other than the GUI version of the wsjt-x software, a work-around must be invoked. The following is a bare-minimum example of how one might do this via the command line:
jt9 -W -p 120 -f 1420 <wav file to be processed>
jt9 -W -p 120 -f 1460 <wav file to be processed>
jt9 -W -p 120 -f 1500 <wav file to be processed>
jt9 -W -p 120 -f 1540 <wav file to be processed>
jt9 -W -p 120 -f 1580 <wav file to be processed>
(One might include the -H, -L and -d parameters in actual practice.)
In other words, in order to cover the entire 200 Hz WSPR subband, the JT9 executable (v2.3.0-rc1) must be executed - processing the same .wav file - at least five times: The results of the decoding will, in each case, be found in the file "decoded.txt". If one wishes to implement an equivalent of the -w parameter of the wsprd executable (e.g. +/- 150 Hz "wideband" mode), you will need even more invocations than above.
The result from the above mess will be five different decoding results, each of which must be saved (e.g. renamed) between subsequent executions to prevent overwriting by the previous instance. After this, the five results must be concatenated to yield a single file - but there is a catch: It is likely - particularly if the signal is strong - that the same signal will be decoded more than once. Apparently, the "+/- 20Hz" limit isn't the result of a "brick-wall" filter: Signals beyond this frequency range may be decoded, but the reported S/N values will likely be reduced as distance of the received signal from the specified center frequency increases. In short, this means that the results of the concatenated version of the "decoded" file(s) must be sorted and all but the single, strongest decode for each station must be discarded.
If one wishes to integrate the FST4W decodes into the existing WSPR captures for processing, yet another step must be undertaken: "Fixing" the formatting. Not surprisingly, the output in the "decoded.txt" is not formatted the same as the results of the decoding from the wsprd executable meaning that one will need to do a few things, after the fact, to "fix" them - particularly if you wish to forward them to wsprnet.org, including:
- Supply the date. The "decoded.txt" includes the time - but not the date. Because date of the .wav file may not be the same as the system date (e.g. later processing of the .wav files - or the interval being processed occurred just before the new day) - one must use the actual date of the recording. The obvious place to obtain this is from the name of the .wav file being processed.
- Frequency offset. The information that one might send to wsprnet.org must include the carrier frequency of the received signal, but the output in the "decoded" file has only the audio frequency: One must obtain the LO frequency of the receiver being used from "somewhere" and calculate this on the fly.
- Supply missing information. The "decoded.txt" does not have all of the same information fields that one might supply when uploading spots, so this information must be added as necessary.
- Arrange the fields in the proper order. Once the needed information is applied, one will probably want to use "awk" or similar to produce the same order as the wsprd data - assuming this wasn't already done in the process.
* * *
There you have it: The germ of what would be needed if one wishes to supplement the existing WSPR decodes with the newer FST4W mode using just the bare executables.
* * *
P.S.: While it would be pretty trivial tweak the code to allow modification of the ntol variable via command line, this would complicate the ongoing maintenance of the wsprdaemon code. We can only hope that the current authors see fit to include a means by which the entire wspr subband can be monitored with a single invocation of the jt9 executable.
This page stolen from ka7oei.blogspot.com
[End]