Category: Amateur Radio

Posted on

Running WSJT-X on a Raspberry Pi using an SDRPlay RSP2

Using the preconfigured/installed Raspberry Pi .img from SDRPlay (here), it’s pretty easy to get WSJT-X up and running once you work out some stuttering audio issues with GQRX or CubicSDR (both installed on the image). I’m using a Raspberry Pi 3 for this experiment, maybe a new RPi 4 would have better results.

First download and install the .deb for the Raspberry Pi from the WSJT-X page here.

Start up either GQRX or CubicSDR and tuning to the standard FT8 frequency for the band you’re listening to, eg. 14.074MHz for 20m.

Here’s GQRX listening on 14.074MHz:

it was good to see that there must already be preconfigured virtual source/sink configured for alsa/pulse audio, so just selecting the available pulse audio as the input in WSJT starts to get you signals on your waterfall. I was fully expecting to have to configure my own source/sink virtual audio cables to pipe the audio from one app into the other, but this seems to be ready to go straight out of the box with the supplied .img:

At this point though I was stuck for a while trying to work out why I was not getting successful decodes, notice all the signals in the waterfall above, but the decodes window on the left is empty. I checked the audio sample rate in GQRX was 48khz, and I checked ntpd was running so my clock time was in sync.

I went round in circles trying to debug this for a while until I listened to the audio being received and realized the audio from GQRX was stuttering, it was only out putting about 1/2 sec audio in every sec. Decreasing the SDRPlay RSP2 sample rate in CubicSDR all the way down to the minimum 250kHz solved the stuttering (slightly higher sample rates worked too, but I didn’t need more than this for listening on a single frequency, and this same approach worked in GQRX too), and now with constant audio with no dropouts, I was getting good decodes in WSJT-X:

Logging my spots out to pskreporter, 40m at 11pm this evening was not great, but had a few spots on the West coast and also out to Cuba:

This is great that you can get an SDRPlay RSP2 running as a receiver on a Raspberry Pi and also run WSJT at the same time. I have a few ideas for how I can use this as a low power setup running 24×7… more details to come as my project takes shape… 🙂

Posted on

WSJT-X reports time difference > 2 seconds on Windows 10

All of the JT modes (JT65, JT9), and now the new mode FT8 are sensitive to correct system time within a couple of seconds. This is because the transmit/receive cycle starts and stops at a predetermined time, and the software of each transmitting station and each remote receiving station need to be in sync in order for each transmission to get successfully decoded.

FT8 seems to be forgiving within about 1.5 seconds of difference, but above this it flags the delta between stations in the DT column:

On a new laptop with Windows 10, even though the date and time is set to set automatically using a remote time server on the internet, almost every FT8 transmission received was consistenly > 1.5 seconds in difference.

To fix this I downloaded and installed Dimension 4 and set it to start automatically. Sync’d the time and now we’re all set – you can see the received calls below in the DT column are all now within a couple of 0.1s after the sync:

Posted on

Configuring WSJT-X to log to N3FJP for ARRL Field Day (part 1)

My amateur radio club (RCARCS) uses N3FJP logger for Field Day (we run N3FJP on one laptop and the log from each station over WiFi). This year I want to have a go at setting up a digital mode station to log automatically to N3FJP from WSJT-X to run some FT8, and also from fldigi to work PSK and RTTY. First up, let’s look at getting WSJT-X working.

WSJT-X doesn’t log directly to N3FJP (it does to N1NM though), but it does indirectly through the intermediate helper app JT-Alert. The setup we’re going to do then is:

WSJT-X -> JT-Alert -> N3FJP Field Day logger.

Starting with N3FJP, the first step is to enable the Server API from Settings / Application Programming Interface:

The next step after installing JT-Alert is to select ACLog (N3FJP’s main logging app) in the settings. The options give you a setting to connect to a locally running ACLog, and while this works for a local N3FJP’s ACLog app, it doesn’t for N3FJP’s Field Day logger. This part is not obvious, but to configure JT-Alert to log to the Field Day logger even if on the same PC you configure the remote connection settings and then also point it to the .mdb log file of the locally running N3FJP:

Here you also select the log type is ‘Field Day’. This approach for the config is in the Help docs for JT-Alert here:

Next, configuring network options in WSJT to allow JT-Alert to connect. Without making any other changes, if you start JT-Alert and then start WSJT you’ll see these two dialogs which tell you what settings you need to change in WSJT:

In WSJT settings on the reporting tab, select all 3 checkboxes in the UDP section, and replace the default 127.0.0.1 with your current IP address, e.g.

To use FT8 for Field Day, WSJT has a setting to customize the exchange to include the required class and ARRL section:

To test out the config so far, start the apps in this order: N3FJP, JT-Alert, WSJT. To test logging a QSO, enter a test call in the DX Call field and press the Log QSO button:

… note here when running Field Day mode you should enter the correct exchange sent and exchange received so the QSO is logged correctly in N3FJP.

The log is automatically sent across to N3FJP via JT-Alert:

I noticed if you don’t manually enter the exchange sent and received then it will populate just the callsign field with the sent and received still blank. If you complete both as you log from WSJT then the log entry is saved into N3FJP automatically.

Note: in JTAlert v2.13.6 I noticed the above steps work fine on Windows 10 if you are logged in as an Admin user. If you log in as a regular user, JTAlert will not copy logs across to N3FJP, unless you start JTAlert with ‘Run as Administrator’. Also, it will pop up the warning message saying that it failed to check if the log was successfully written, even though it is written to N3FJP successfully. There is a timing setting in the JTAlert Performance settings to increase the length of time before the N3FJP is checked for a successful log, but it doesn’t appear to make any difference for this issue.

Next up, I’ll look at getting fldigi setup to also log direct to N3FJP.

Proudly powered by WordPress