Gpredict to SDR# Interface Using Hamlib & NetRemote

Hi Folks:

I’ve signed up here to share some work that I’ve been doing which allows Gpredict to control a running instance of SDR# during a satellite pass. There were a number of things that prompted me to set off down this particular path. The TL;DR version is that I like Gpredict more than any of the other tracking software out there and I was getting frustrated that there was no easy way to make SDR# communicate with it.

As a new user, I’ve not been able to figure out if the accepted protocol here is to simply include an attachment to a post or to provide a link from where the script can be downloaded, happy to do either if someone can advise.

  1. I have a massive problem with software and/or protocols which are not platform-agnostic - I am a Linux engineer by profession, but I also occasionally find myself having to work on Windows, both from a Workstation and Server perspective.

  2. The Windows build of Gpredict is several releases behind the Linux version, for example the most recent build that I’ve been able to find does not include the AOS/LOS signalling which is included in the master branch from GitHub. I don’t have either the tools or the skills to compile a newer Windows version.

  3. Most plugins for doppler shift control with SDR# rely on Windows-only methodologies such as DDE.

  4. The SDR# plugins that do use TCP are not compatible with the Hamlib protocol, for example the NetRemote plugin uses its own set of commands that are not Hamlib compatible

  5. This was my first attempt at writing anything in Python that uses the sockets library - a learning experience is always good!

The result is a Python script that accepts Hamlib-style connections from Gpredict and translates the commands received into something that the NetRemote plugin can understand. In order to be platform-agnostic, my script supports two ways of making this happen.

Anyone using the Windows build of Gpredict needs to configure both a ‘radio’ and a ‘rotator’ interface. The rotator interface is used to generate a rudimentary AOS/LOS signalling method based on the elevation of the satellite being tracked. By default, the script considers AOS to be the point at which the satellite exceeds 2 degrees elevation. Conversely, LOS is defined as the point at which the satellite drops below 2 degrees.

For the sensible people using the Linux version of Gpredict taken from GitHub, only the ‘radio’ interface needs to be configured. AOS/LOS signals are received from Gpredict by my script and acted on.

Upon receiving an AOS signal by whatever method, my script configures SDR# to use narrow band FM, sets the bandwidth to 40 kHz, switches off FM stereo mode, and does the software equivalent of clicking the ‘play’ button. Assuming you already have something like WXtoIMG running and waiting to go, you can just sit back and watch while gPredict and SDR# pull in the signal from the satellite and generate an image file for you. At the end of the pass, the script will stop SDR# and if left alone, will wait 30 seconds before quitting, to ensure that the whole pass is captured.

The script is purely CLI at this stage. My next ambition will be to make a GUI version of it using either wxPython or Tk. I’m making it available (assuming anybody is interested, of course!) under a GPLv3 licence. The ‘help’ text from it reads like this:

Usage: [options] facilitates communication between a running instance of gPredict
and a running instance of SDR# with the NetRemote plugin installed. It allows
gPredict to control SDR# to account for doppler shift during a satellite pass.
If the version of gPredict being used does not support AOS/LOS signalling via
the radio interface, the rotator control feature can be used to provide this

  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -e MINEL, --elevation=MINEL
                        Minimum elevation value which indicates AOS, default =
                        2 degrees
  -f, --file            Log output to rtl-server.log as well as the screen
  -l LISTEN, --listen=LISTEN
                        IPv4 address to listen on for incoming connections
                        from gPredict, default =
                        Time after LOS to wait before quitting the program,
                        default = 30 seconds
  -q, --quit            Quit the program automatically shortly after LOS,
                        default is to keep running
  -t TALK, --talk=TALK  IPv4 address to talk to SDR# NetRemote, default =
  -v, --verbose         be more verbose when processing
  -x, --debug           Emit debug messages for troubleshooting

Before running this program, SDR# should already be running with the NetRemote
plugin installed and set to accept connections on TCP port 3382. Best results
will be obtained by starting this program a short time before the expected AOS
from the satellite.

Hi Phil,

Thanks for the info and nice work. You could host your script on one of the free code hosting sites like github.

The latest development code in the gpredict repository does actually add AOS/LOS signalling. I use this in gqrx to start and stop recording. Unfortunately there is nobody at the moment to create windows builds, so windows support remains doubtful for now.

By the way, I think Ian MM6DOS has written an SDR# plugin that can understand the hamlib commands sent by gpredict. I don’t know whether it has been published, but you could ask on their mailing list.


Hey Alex @csete

I’ve seen you mention the lack of Windows support over here and on Twitter. Have you thought about using AppVeyor? Once setup it will create Windows binaries for you in the form of zip files.

It’s Travis for Windows essentially. I’ve never set it up personally but know they are using it at Qucs for example.

Thanks for the tip. I can’t say I have thought about it – in general I think very rarely about windows related matters :wink:

Jokes aside, I just have no interest or incentive in spending time on windows support. It has to be somebody to whom it makes sense. It is also important to understand that it is not just a question of building a binary package. It is a question of building a binary package, maintaining it and supporting it.