Topics

WSPRD executable will decode from the audio file reliably - so why won't JT9?


Clint Turner
 

As part of the WSPRDaemon project where a script is used to record audio from multiple receivers, fed to the "wsprd" executable and then thrown at wsprnet.org, I've been trying to use this same audio file for the decoding of FSW4W packets which seem to be supplanting WSPR on the 2200 and 630 meter bands, so it would be nice to add FST4W-120 decoding to the processing.

The problem is this:

The 120 second off-air audio file produced by the WSPRDaemon script on the Linux machine is happily decoded by wsprd, but the same file - known to contain valid FST4W packets - will almost always yield nothing when fed to the jt9 executable - either on Linux or Windows.  I say "almost" since I occasionally do get an FST4W decode - I'm guessing, maybe, less than 1% of the time:  When this decode occurs, it shows a "believable" S/N ratio - and both weak and strong signals have occasionally popped up.

Interestingly, if I use WSJT-X (on Windows) in FST4W to generate a 2 minute .WAV file, both the Windows and Linux instance of will happily decode the FST4W transmissions that it contains.

I've bared the command-line FST4W invocation to minimum:  jt9 --fst4w -p 120 <.wav_filename>

I have checked:
  • Sample rate:  The "working" and "non-working" audio files are of the same sample size, rate and format.
  • The original .WAV file (from the Linux WSPRDaemon) script has its audio at about -30dBFS which was subsequently boosted to -10dBFS:  Still, no decode.
  • The timing:  The transmissions received all begin at the same time offset from the beginning of the file, which would seem to imply that DT was not an issue.
Do the JT9 (in FST4W-120 mode) and WSPRD executables expect different things from their .WAV files?

Any suggestions?

Thanks,

Clint, KA7OEI


Bill Somerville
 

On 17/10/2020 04:27, Clint Turner wrote:
As part of the WSPRDaemon project where a script is used to record audio from multiple receivers, fed to the "wsprd" executable and then thrown at wsprnet.org, I've been trying to use this same audio file for the decoding of FSW4W packets which seem to be supplanting WSPR on the 2200 and 630 meter bands, so it would be nice to add FST4W-120 decoding to the processing.

The problem is this:

The 120 second off-air audio file produced by the WSPRDaemon script on the Linux machine is happily decoded by wsprd, but the same file - known to contain valid FST4W packets - will almost always yield nothing when fed to the jt9 executable - either on Linux or Windows.  I say "almost" since I occasionally do get an FST4W decode - I'm guessing, maybe, less than 1% of the time:  When this decode occurs, it shows a "believable" S/N ratio - and both weak and strong signals have occasionally popped up.

Interestingly, if I use WSJT-X (on Windows) in FST4W to generate a 2 minute .WAV file, both the Windows and Linux instance of will happily decode the FST4W transmissions that it contains.

I've bared the command-line FST4W invocation to minimum:  jt9 --fst4w -p 120 <.wav_filename>

I have checked:
  • Sample rate:  The "working" and "non-working" audio files are of the same sample size, rate and format.
  • The original .WAV file (from the Linux WSPRDaemon) script has its audio at about -30dBFS which was subsequently boosted to -10dBFS:  Still, no decode.
  • The timing:  The transmissions received all begin at the same time offset from the beginning of the file, which would seem to imply that DT was not an issue.
Do the JT9 (in FST4W-120 mode) and WSPRD executables expect different things from their .WAV files?

Any suggestions?

Thanks,

Clint, KA7OEI

Hi Clint,

currently the command line decoding of FST4W signals using jt9 is somewhat limited in control options. It will decode signals around the f0 passed (-f), with a frequency tolerance of ±20 Hz, and a decoding effort related to the depth argument between 1 and 3 (-d). So you will have to decide what centre frequency to decode around and then use something like:

jt9 -W -p 120 -d 3 -f 1620 <audio-file>

Which will make best effort to decode FST4W-120 signals between 1600 Hz and 1640 Hz inclusive, this assumes that FST4W signals will be transmitted just above the traditional WSPR segment and you have your USB dial frequency 1500 Hz below that frequency. The actual frequency of FST4W signals relative to WSPR signals may vary depending on the band selected.

It should be noted that the FST4W waveforms are very narrow bandwidth, particularly the longer T/R periods, so we expect FST4W transmitters on LF and MF to utilize a very narrow sub-band. The decoder is tuned to operate best when presented with signals within such a narrow sub-band.

73
Bill
G4WJS.


Joe
 

To explain why your effort to decode FST4W signals from the command-line has failed, we would need to have (1) a copy of an example .wav file and (2) some indication of the signal(s) that you think should have decoded, perhaps obtained by opening and processing the file from within WSJT-X.

  -- Joe, K1JT


Clint Turner
 

Hi Joe,

I have exemplar .wav files containing both WSPR and FST4W-120 signals, and that which is expected to be decoded:  I'd be happy to drop them off in a location of your convenience.

Thanks,
Clint, KA7OEI