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.
-
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.
-
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.
-
Most plugins for doppler shift control with SDR# rely on Windows-only methodologies such as DDE.
-
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
-
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: rtl-server.py [options]
rtl-server.py 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
functionality.
Options:
--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 = 127.0.0.1
-p PAUSETIME, --pause=PAUSETIME
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 =
127.0.0.1
-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.