# SatDump: decoding satellite downlink baseband into frames and products > SatDump is a generic signal processing application for satellite data, built on C++, libvolk and a plugin system, with pipelines named after missions. Its release tags have not moved in two years even though development has. **SatDump/SatDump** — A generic satellite data processing software. - Repository: https://github.com/SatDump/SatDump - Website: https://www.satdump.org - Stars: 2,306 · Forks: 298 - Language: C++ - License: GPL-3.0 - Published: 2026-10-07 · Updated: 2026-10-07 · Language: en - Canonical page: https://hysenlabs.com/projects/satdump-satdump ## Pipelines, not a single decoder SatDump calls itself a generic satellite data processing application, and the mechanism behind that word is the pipeline. A pipeline is a named chain of modules chosen to match a particular mission or signal, and the CLI takes a pipeline identifier as its first argument. ``` Usage : satdump pipeline [pipeline_id] [input_level] [input_file] [output_file_or_directory] [additional options as required] Sample command : satdump pipeline metop_ahrpt baseband /home/user/metop_baseband.cs16 metop_output_directory --samplerate 6e6 --baseband_format cs16 ``` The input level tells the pipeline what kind of input it has. The README lists baseband, frames and soft symbols, so a pipeline can start at the raw samples or further along the demodulation chain. Output formats include cf32, cs32, cs16 and cs8, which is the normal raw IQ representation set, plus w8 and w16 for demodulated output. That structure is why the software is described as generic rather than mission-specific. The mission knowledge lives in pipelines such as `metop_ahrpt` in the sample command, not in the core, and the full parameter list is documented at docs.satdump.org rather than in the README. Live capture and recording use the same pipeline concept behind a separate verb set, with `--source airspy`, `--gain`, `--bias`, `--dc_block`, `--iq_swap` and `--timeout` among the options. `satdump sdr_probe` lists the SDRs actually visible on the machine and their IDs, which is the first thing to run when a source is not detected. ## Two interfaces over the same engine The application ships a GUI and a CLI, and the README documents both. The GUI path for recorded data goes through File, then Processing, where you pick a pipeline, choose an input file, set the input level, confirm settings such as sample rate and press Start. For live work the GUI adds a recorder: add one, select an SDR device, choose a pipeline and start it. The source tree explains why that is two front ends over one core. `src-core/` holds the processing engine, `src-ui/` and `src-interface/` the graphical layers, `src-cli/` the command line entry point, and `src-testing/` the tests. There is also `plugins/` at the top level, which is the extension point that lets mission support live outside the core. SIMD is a first-class concern rather than an afterthought. The repository topics list volk and simd, there is a `volk_includes/` directory, and the README says explicitly that MinGW builds are not supported because VOLK will not work. So vectorised kernels are assumed on every supported platform, and the Windows build instructions insist on Visual Studio 2019 for x64 with the Visual C++ Runtime installed. There is also an `android/` directory and an appdata XML file for Flatpak, so a mobile and a Linux distribution path exist alongside the desktop builds. ## Docker as a two-stage build with host device mapping The `Dockerfile` is more informative than the README's Linux section because it shows exactly which build options exist. It builds from a `debian:trixie` base, installs dependencies listed in `packages.builder`, and configures CMake with four switches that reveal what the project considers optional: ```docker RUN cmake -B build \ -DCMAKE_BUILD_TYPE=Release \ -DBUILD_GUI=ON \ -DPLUGIN_SCRIPTING=ON \ -DBUILD_TOOLS=ON &&\ cmake --build build --target package ``` `PLUGIN_SCRIPTING=ON` is the flag to know about, since it implies plugins can be driven by script rather than only compiled in. `BUILD_TOOLS=ON` builds the auxiliary command line tools. The runtime stage creates a `satdump` user and, importantly, makes the UID and GID configurable so files written into a bind mount belong to you: ```yaml device_cgroup_rules: - 'c 189:* rwm' devices: - '/dev/bus/usb' ``` The companion `docker-compose.yml` grants that USB access and runs with `network_mode: host`, plus a commented-out block for binding `/tmp/.X11-unix` if you want the GUI over X11 or WSLg. `/tmp` is a tmpfs. That is a pragmatic arrangement for SDR work, where the device is a USB dongle and the network path should not be namespaced. ## The release tags stopped while the code did not The newest tagged release is 1.2.2, published on 2024-11-29, preceded by 1.2.1 on 2024-10-28 and a `nightly` tag from 2023-06-29. The last push to the repository is 2026-09-28. So the release list is roughly two years behind the working tree, which is the most important fact about this project for anyone deciding what version to install. The 1.2.2 release body does not even contain notes. It is a single line pointing at a post on the SatDump website's own repository, at SatDump.Org, dated 2024-11-28. Anyone wanting the changelog for that release has to leave GitHub for the project site. Search traffic reflects the gap. People typing SatDump 2.0 download is looking for a version that the tag list does not offer, and there is an android/ directory in the tree with no corresponding release entry to explain what state it is in. So the practical question, whether the current tree is better than 1.2.2 and whether it is stable enough to use, is not answered by the release feed. The repository is not archived and pushes are recent, so the code is moving; whether you want the moving version over the tagged one is a judgement the release notes do not help with. ## Install paths, and two of them point at an old name The README gives per-platform instructions, and they are detailed enough to build from source. On Linux it recommends building from source, with prebuilt binaries for x64 Ubuntu, and lists dependencies in commented groups so you can see what each one is for: FFTW, PNG, TIFF, jemalloc, curl and SQLite always; GLFW and D-Bus only for the GUI; PortAudio for audio output; zstd for ZIQ recording compression; HDF5 for official product support such as EUMETSAT; librtlsdr, libhackrf, libairspy for live processing; libad9361 and libiio for Pluto-class SDRs; libbladerf for BladeRF; OpenCL ICD for the GPU paths. That grouping is the documentation. The optional labels tell you which capability you are buying with each library, which matters because the full list is long. The macOS path needs Homebrew, then a clone, then `../macOS/build_deps.sh` before configuring CMake. Two details there are easy to miss. If `-DBUNDLING_MODE` was off, you must symlink `resources` and `satdump_cfg.json` into the build directory or the binary will not run, and if it was on, the bundled app ends up in `./MacApp`. One inconsistency to be aware of: the Windows and macOS instructions link the releases page at github.com/altillimity/SatDump while the clone command and the repository itself are SatDump/SatDump. Both probably worked at different times; use SatDump/SatDump for anything you run today. The GUI entry points are `satdump-ui.exe` or `satdump.exe` on Windows and `./satdump-ui` on macOS. ## What the README deliberately skips The README opens by saying it is a basic how-to that assumes you know what you are doing, and points to docs.satdump.org for details and advanced use cases. That is an honest framing for a signal processing application, where choosing a pipeline requires knowing what the signal is. What stays on the README is the operation: which menus to click, the three CLI verbs with their argument shapes, one worked sample command per verb, and where the pipeline and SDR option lists live. What moves to the documentation is everything about what a pipeline actually does, which is the part that decides whether you can decode your target. The repository itself carries a `Doxyfile.in` and a `docs/` directory, and the tree includes `cmake/`, `tools/`, `resources/` and a top-level `CMakeLists.txt`. There is a `satdump_cfg.json` at the root, the settings file the macOS instructions told you to symlink, and a `packages.builder` and `packages.runner` pair that keep the Docker dependency lists in the repository rather than in the Dockerfile itself. The licensing is GPL-3.0 with a LICENSE file present, which is unremarkable for this class of software and worth noting only because the plugins directory invites people to write their own modules. There is also a Matrix room and a Discord bridge, both linked at the top of the README, which is where mission-specific pipeline questions tend to get answered. ## Conclusion SatDump is the tool to reach for when you already have a baseband capture and need decoded frames or mission products, because pipelines are named per mission and the plugin format lets you add one without touching the core. It is the wrong tool if you want orbit prediction or a satellite tracker, since it is a decoder rather than a tracker, and building it on Linux means assembling a long dependency list including libvolk and FFTW. Take a prebuilt Windows or macOS binary where you can, because the newest tag is 1.2.2 from 2024 while the code has moved since, and expect to read docs.satdump.org for anything the README leaves out. ## FAQ ### Is SatDump free to use? Yes. GitHub reports GPL-3.0 for the repository and a LICENSE file is present in the tree, and the README offers prebuilt Windows and macOS downloads plus a Docker path, with Linux builds from source documented in detail. ### What is SatDump used for? It processes satellite signal data. You feed it a baseband capture or a live SDR stream, choose a pipeline named for a mission such as metop_ahrpt, and it demodulates and decodes through to frames and products. It is a decoder rather than a tracker, so it does not tell you where a satellite is. ### Which SDRs does SatDump support for live processing? The README shows `--source airspy` and `--source rtlsdr` in its examples, and the Linux dependency list names librtlsdr, libhackrf, libairspy and libairspyhf for live processing, plus libad9361 and libiio for ADALM-Pluto and Pluto-class devices and libbladerf for BladeRF. Running `satdump sdr_probe` lists what is actually detected on your machine. ### What is the latest version of SatDump? The newest tag is 1.2.2, published on 2024-11-29, before 1.2.1 and a nightly tag from 2023. The repository is not archived and its last push is 2026-09-28, so the code is well ahead of the tagged releases and the release list does not describe what is in the current tree. ## Sources - [License: GPL-3.0](https://github.com/SatDump/SatDump/blob/master/LICENSE) - [Project website](https://www.satdump.org) - [README](https://github.com/SatDump/SatDump/blob/master/README.md) - [Releases](https://github.com/SatDump/SatDump/releases) - [SatDump/SatDump on GitHub](https://github.com/SatDump/SatDump) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/satdump-satdump