Figure 1: WSJTx in action, showing two CW signals
The Soft66 Lite hardware worked well with Linrad, for copying CW signals, or SSB signals on a variety of ham bands. While that was fun, I decided to take it a bit further, and use the Soft66 Lite SDR hardware, the Quisk SDR software, and the WSJTx digital mode software to copy JT-9 and JT-65 style digital communications.
So:
Soft66 Hardware –> Quisk –> WSJTx –> Decoded JT-9 communications QSOs!
Theoretically, Quisk supports sound hardware interfaces directly, and also through Alsa and/or through Portaudio and/or through Pulseaudio interfaces. After playing with Quisk + Pulseaudio for awhile without success, I set the configuration file to use the hardware thusly:
.quisk_conf.py – added two lines (the only two lines in the file):
name_of_sound_capt = "hw:1" # (my Cirrus adapter card) name_of_sound_play = "hw:0" # (my onboard Nvidia adapter)
Note the Soft66 hardware output is connected to the Cirrus card’s line input.
Running Quisk, I could listen to CW and SSB signals readily by plugging a set of headphones into the NVidia onboard adapter’s line-out connector. The next step was to route the audio output from the onboard Nvidia adapter to the WSJTx software, in order to decode the JT-9 and JT-65 signals. This is where things were made a lot easier by the use of the latest version of WSJTx. Earlier versions may not have used Alsa + Pulseaudio, or only used it to some extent. By using the latest version of WSJTx (1.6) I was able to make use of its strong Alsa/Pulseaudio capabilities. While the older versions of WSJTx would (probably) have left me fussing with asound and jackd configurations, version 1.6 of WSJTx automatically detected the onboard NVidia adapter as the place where the audio could be found. All I had to do was to select the defaults, which were:
WSJT Audio Settings: Input --> alsa_input.pci-0000_00_05.0.analog-stereo Output --> auto-null
Note: “alsa_input.pci-0000_00_05.0.analog-stereo” is my onboard Nvidia adapter (input).
Output isn’t needed in this case (hence the auto-null target), because nothing is to be transmitted (Rx only), and to listen to JT-9 signals I have only to plug headphones into the NVidia onboard audio card’s line-out connector.
While the selection of audio inside of WSJTx was nearly automatic, I still had to set the level of audio from/to various things to prevent overdriving and clipping. To that end, I installed pavucontrol, to control those levels via a Pulseaudio GUI control application:
sudo apt-get install pavucontrol (Done on Devuan Linux. Yes, "Devuan," - it's not mispelled!)
Then, in the configuration tab of pavucontrol:
- Crystal 4281 set to "Analog-Stereo-Input" - Builtin (Nvidia) set to "Analog-Stereo-Duplex"
Then, in the input devices tab of pavucontrol:
Crystal 4281 - - line-in - - gain = 100% Builtin (NVidia) - - line-in gain = 47%
In the recording tab of pavucontrol:
- Qtpulseaudio (from Built-in Analog Stereo) - gain = 31%
The “Qtpulseaudio” name that appears in the pavucontrol tab belies some of the improvements made to WSJTx. Anything over about 35% saturates the output, in my case. At this point I could see some JT-9 and JT-65 signals in the “wide graph” display window of WSJTx. I set the Bins/Pixel setting in that window, to “5.” The Bins/Pixel=5 setting widened the Hertz scale (at the top of the window) to have the more broad range of [0 – 4500] Hz. Directly below the Bins/Pixel control, there is a JT65/JT9 control which sets the blue bar in the window. Everything to the left of the blue bar is decoded first with JT65, and everything to the right is decoded with JT-9. I set this control to 2500 Hz.
In the main screen, just below the monitor button, is a control for default transmit codec. I set it to JT9, so that when the mode (from the mode menu) is set to JT9+JT65, it will try to decode JT9 first. I think (but am not sure) this behavior is valid even when there is no transmitter configuration (as in my case with the use of WSJTx as a RX-only setup). I set the decode menu option to fast. The reason I set it to fast (rather than normal) is because I thought it would let me operate without having the KVASD binary installed on my system. Thus far, that does not seem to be the case, but I’m still testing.
Several JT signals were processed by the software, but in all cases the decoding stopped short, logging a message that indicated the KVASD binary was missing. I had attempted to avoid the use of KVASD use altogether via the “fast” decode selection. However; I observed the error message even when the fast decode mode had been selected. I’ve not yet determined how to proceed from this point. Stay tuned…
I have no affiliation with any of these sources, packages and components. All are open source projects, and can be found at the following URLs …
The WSJTx software is not my own. It’s produced and maintained by K1JT (and others) at:
http://physics.princeton.edu/pulsar/k1jt/
Linrad can be fund at:
http://sm5bsz.com/linuxdsp/linrad.htm
FLDigi can be found at:
Quisk can be found at:
http://james.ahlstrom.name/quisk
WSJTx can be found at:
http://physics.princeton.edu/pulsar/k1jt
Soft66 hardware can be found at:
Note: the soft66 Lite hardware is a product that is sold on a Japanese website (http://zao.jp/radio) – and is not affiliated with this site or author in any way.
WB8LZR 