I’ve successfully deployed my SpotViz app on WildFly running locally and tested running a visualization playback of FT8 signals received during a whole day, from 9am to 10pm. It’s interesting to see the propagation move from my location on the US West coast out to the East coast, and then gradually move West during the day, following the sun, until the propagation dies out on 20m completely around 10pm.
Here’s a screen capture of the playback:
Next up, I’ll be setting this up hosted on a VPS somewhere, and start working on some of the bugs in the UI.
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… 🙂
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:
