Operation
In this chapter, you will get some information and examples on operation and modify/extend a station with satnogs-client-rs.
Basics
satnogs-client-rs is controlled via systemd-units. To start/stop it, you can use the systemctl command:
Per default, satnogs-client-rs is enabled and will startup with your system booting up.
You can view the status of your station with the status command:
This status will show only the last couple of lines in your stations log. To
see a full log (and follow it while), you can use the journalctl command.
Advanced
This section shows some advanced workflows on your station.
Securing Station by Deactivating Web Configuration
Once you’ve done with the initial configuration, you may switch off the web based configuration tool by deactivating the systemd unit:
You may want to do this, to avoid your station being reconfigured accidentally or to avoid attack surface in your local network. You should definitely perform this step, before exposing your station to the internet (which I only partially can recommend, depends on the scenario).
Pre-/Post Scripts
Pre- and Post-Scripts are a vital part of your station operation. They give you the chance to heavily modify the observation process without the need to touch the clients code. Pre-scripts are run before an observation and post-scripts after an observations. At the time of writing (July 2026), pre-scripts start running directly at the point of time the observation should start. Effectively, they postpone the observation until they are finished. In consequence, pre-scripts should do minimal tasks only, so that they finish fast.
Note
Post-scripts are run asynchronously after the observation. They can perform longer tasks. Please note, that upload of artifacts will only happen, once all scripts finished.
Writing Scripts
Scripts reside either in Scripts are run in lexicographical order of their filename. E.g., /usr/bin/satnogs-pre or /usr/bin/satnogs-post, depending on when they shall run. Once called, the scripts current working directory (cwd) is set to the directory with the observation data. Hence, your script can assume to access the files directly, without any directory structure needed.
Tip
10-first.sh will run before 20-second.py. That way, you can precisely control the order of running your scripts.
This is a listing of an observation data directory, located at /var/tmp/satnogs-client-rs/39614:
From the job.json, your scripts can grab any information they might need. It is the exact same json structure as delivered by the satnogs network to the client.
Examples for reading this json-File in Shell and Python are delivered in the standard installation of satnogs-client-rs. You can find them in the predefined directory at /usr/bin/satnogs-[pre|post] or in the source code.
The demo_* files in the listing above are generated by the demonstration scripts.
Post-Processing: Waterfall
The waterfall script is taken from the original satnogs client. It post-processes the waterfall data generated by the satnogs-flowgraphs and renders them into a .png picture.
Example: Package IQ-Data to SigMF
This section is under construction. I plan to adjust the sigmf-packer, that I published already at codeberg and in the librespace community for satnogs-client-rs.
Example: Upload IQ-Data to a Nextcloud-Share
Under construction. Same as above. Packaging and uploading should be separate scripts, though.