Raspberry Pi, SDRPlay RSP1a and WSJT-X

After a lot of testing of the new Raspberry Pi 4B, especially its power use (very little changed from the 3B+ for my applications), this is now my standard field radio computer.

That means I have a 3B+ spare, which I decided to use for experimental purposes - such as trying to get a SDR receiver going. This is so that I don't have to carry a heavy 12V battery and a full rig when all I want to do is receive from the beach.

Like many, I had expected to have a fight with the Raspberry Pi's audio, to get it from the SDR software into WSJT-X for signal decoding.  But it turns out that all this is taken care of by the nice people at SDRPlay, who have an image disk ready for us to download and insert into the Pi's socket.

It was evening before I got everything shorted out...

After downloading the image, this was flashed across to a new micro SD card, and after a bit of editing the config file (see here) to get the correct settings for use with my 7" screen, we were off!

I managed to get Cubic SDR to open up alongside WSJT-X.  But it took me a while to figure out why there were no decodes at all.

Firstly, I had to correct something that seems only to happen with the SDRPlay image - poor timekeeping of the Pi, probably because it hasn't got NTP time installed by default.  As it was, the Pi was out by 3-4 seconds, way too much for good decode rates.  A much earlier download of the NOOBS package for my portable operations resulted in excellent timekeeping - all very odd!

This correction is easy to do, and needs only a couple of commands, which are listed here, but reproduced for my own records below:

sudo apt install NTP

Next, force time updates:

sudo apt install ntpdate

Checking it all works, type the following to return the time offset.  You may need to reboot to see it all take effect first:

sudo ntpdate -q 0.us.pool.ntp.org

 

Then I discovered that I can listen to the audio feed, even though it's being routed to software, simply by connecting a pair of headphones to the jack on the Pi.  This makes things a lot easier, as you can hear what's going on.  I don't think you can do this with a Windows computer.

What was going on was very stuttery sound indeed.  Cubic SDR lets you choose a low RF sampling rate of 250kHz, and an audio sampling rate of 22.05kHz - much lower than the typical default settings. This combination provides nice clear and stable audio for HF reception on the Pi 3B+

Unfortunately, the alternative, and much nicer, faster software - GQRX - has a fixed audio sampling frequency of 48kHz, which is too high for the Pi 3B+ to cope with.  It can probably be changed with a bit of file editing, if you have the patience that I don't!

 

A very short test at 14MHz WSPR, showing timekeeping and sample rates all now working nicely.

After all this, WSJT-X settled down nicely into plenty of decodes with good timekeeping going on in the background.  Cubic SDR takes a bit of getting used to in terms of its irritating frequency changing windows, but it's simple enough, once you get used to it.

The Pi CPU does get quite warm running all this code, peaking at about 50 degrees Celsius.  It ideally needs a cooling fan or passive heatsink, although I had neither for this test, which lasted for about three hours.  I expect the system can run on a 20Ah USB battery for five hours or so.

It's quite amazing that such a small computer can run all this software without a glitch.  The 4B, with 4GB RAM, should find the whole experience much easier going, but that will have to wait another day.