Satnogs client v.3 released!

v.3 of the satnogs client is here and there are some big changes at hand:

  • Change in the executable name from satnogs-poller to satnogs-client (you will need to update this within supervisord configs or any other scripts you have)
  • Moving from rtl_fm to gr-satnogs, gnuradio based software receivers. This will allow us a greater range of SDR support and functionality beyond rtl_fm. However, this is also a new dependency and you will need to build and install
    • With this we have support for multiple receiver/demodulator scripts to better match different modes. v0.3 will allow for different scripts for CW and FM observations as well, more will come in future releases.
    • Also added is the generation of a waterfall image which is uploaded to network.
    • Currently supported SDR devices in this release are rtlsdr (default), airspy, hackrf, usrpb200.
  • redis is now required for message queuing in the backend and will need to be installed in older clients
  • A new web interface is now included to monitor status of the ground station or operate manual observations in a stand-alone mode. This interface is running on port 5000 and accessible via a web browser.
  • Various bugfixes

This represents 143 changes and almost 13 months of work. We have been very successful with this new client and the gr-satnogs scripts lately (check out the results at ).

Please visit for client documentation. While an upgrade from v0.2.5 is possible, we recommend a clean install using Fedora 25 for the Raspberry Pi platform.

Next up for the development team is fully automating the decoding of telemetry data that is captured. The move to gnuradio allows more opportunities to make this happen. We have some users who are manually decoding the observations, the data for which are making it to Visualizations will be added shortly as well. If you have experience in python or gnuradio and would like to help, let us know!


This is a huge milestone for satnogs! Congratulations to everyone involved in the release, and special thanks to @cshields, @fredy, @Acinonyx, @surligas, @Sleepwalker, ctriant for all the hard work to get us here!


and thanks to @johngian @jinxcat who helped with commits too!

Also a big thanks to @surligas, @PE0SAT and @csete who have helped us on the gr-satnogs side of this development, which makes up a huge piece of the functionality of this release!


Unfortunate the link to the documentation does not work in modern browsers:

The problem is that your main site is configured to force https through a HSTS header (which is a good thing). It is configured in such a way that it also includes sub-domains. The corresponding header looks like this:

Strict-Transport-Security: max-age=15552000; includeSubDomains

Thus it also affects which will automatically be upgraded to https by the browser. However the site does not server a valid certificate for and thus the browser shows an error message. Additionally because of the HSTS header there is no way for the user to continue and override the certificate error‌.

Steps to reproduce in a clean browser profile (tested in Firefox and Chromium):

  1. Visit
  2. Try to visit

You should either remove the “includeSubDomains” from the HSTS header, however due to caching in the clients this may take a very long time, or as a better solution configure a valid certificate for

Actually it’s an issue with the readthedocs service.
Alternatively you can visit the following link if this is not fixed.

@cshields feel free to edit your post and add this as an alternative link for anyone having trouble.

Thank you for the information elkos.

As an additional note the documentation can also be accessed encrypted on the link you posted:

Thanks for reporting this @Maxi. Indeed the includeSubDomains on our HSTS setup caused some problems. Everything should be working fine now. We created a new valid certificate and we now proxy ReadTheDocs through our nginx.

Hi comzeradd, thanks for the update. I can confirm it’s working fine now.