Hero shot of SDR++ running my plugins

A Radio Contact Console

SDR++ has a better waterfall than my radio, and I can overlay helpful visuals on top of it like the bandplan or spots. So I want to synchronize my radio and SDR++. I can rely on SDR++ to provide information about band activity, while I make contacts on my radio. I can tune from my radio or from SDR++ and they both always stay in sync. I’m pulling in spots from pota.app or from DX Cluster (via hamqth). Using this setup, I can quickly navigate to frequencies of interest and make contacts on my radio.

SDR++ Plugins

To get this setup working, I had to make two plugin modules for SDR++:

  • RigSync synchronizes my rig and SDR++
  • Spots visualizes spots on the SDR++ waterfall

RigSync, synchronizes my rig and SDR++ using Hamlib rigctl. It works in both directions, so I can tune on either the radio or in SDR++ and the other one will be tuned to match automatically. This way I can find interesting signals in SDR++ and then receive or transmit using my radio. And if I wander down the band on my radio, SDR++ will automatically follow along.

SDR++ actually has a rigctl client plugin currently in development. I wanted to use that work, but it’s missing a lot of the functionality I’m looking for. And having spoken with the developer a bit, it’s not clear that my use case is exactly what they’re trying to support. So I ended up scrapping that plan and basically starting from scratch.

Spots displays spots on the waterfall, shows details on hover, and lets me tune directly to spot frequencies. I can see frequencies that are likely to have people looking for contacts. I can see when they were last spotted as well as their location.

The Spots plugin listens for external connections to pull in spots. I’m not sure if this is the best way do it. It does make the plugin a little harder to use. But I didn’t want to code up different spot sources in C++. This way I can quickly add another spot source with a little bash script. I did write a little tool in bash that polls Pota.app or HamQTH for spots and feeds them into the plugin.

Setup

I’m running Ubuntu Linux, so all of these steps are specific to linux. With a little persistence you should be able to get things working on Windows. Of course, there’s lots of ham radio software alternatives for Windows.

SDR++ gets its RF information from some radio source. In my case this is an SDRPlay RSP1B software defined radio. This radio has a proprietary computer interface that requires installing their library and service to interact with the radio on a computer.

I have an IC-7300 radio and have udev rules that give a friendly /dev name to the tty interface. I might write up that info in a future post.

  1. Start SDRPlay service if not already running 
    systemctl start sdrplay
  2. Turn rig on and plug into computer
  3. Start rigctld 
    rigctld -m373 -r /dev/ic7300
  4. Start SDR++, will start rigctl client and spot server
  5. Start spot daemon to feed spots into SDR++ (--source=hamqth or --source=pota) 
    ./spots.sh --source=hamqth

SDR++ should now show spots on the waterfall. You can start RigSync (“Start” button on the left panel somewhere) and any tuning you do in SDR++ will be reflected on your rig and vice versa.

Edit: After playing around with this setup, I noticed quite bad interference across the 10m band whenever I turned on the RigSync plugin. It turns out that I was getting some kind of RFI over the USB cable from my computer into my radio. Adding a ferrite bead on the USB cable (specifically the cable between a USB hub I use and the radio), the RFI almost complete disappears.

I actually tried two ferrite beads. The first was a cheap no-name bead from Amazon that had a small effect on the RFI. The second was a Palomar Engineering ferrite bead which worked much better. You get what you pay for I guess.

I thought that was surprising and I’m really glad it was easy to resolve with just a ferrite bead.