ft8 – Page 2 – Kev's Development Toolbox

September 7, 2019September 8, 2019

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… 🙂

June 28, 2019June 28, 2019

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:

July 5, 2018July 5, 2018

Slides from RCARCS 7/3/18 meeting: Intro to FT8 Digital Mode

I presented an overview of the incredibly popular FT8 digital mode at the River City ARCS club meeting on 7/3/18.

Here’s a copy of my slides:

Instead of disassembling my HF station and taking it into the meeting, I tried something different and demo’d using the mode (to receive) using WebSDR, and to transmit using a remote station provided by www.remotehamradio.com . We operated the W1/Chaplain, CT station on the East coast, and worked 3 stations in Europe – HA1RB, DL2LDE and DG6YID during the meeting. From this East coast station the 40m section where FT8 is operated on 7.074Mhz was completely packed from edge to edge on the waterfall!