SatDump Web Edition: Run SDR satellite data processing in your browser.
Real-time FM radio decoding
The real-time spectrum of FM broadcasting, achieved through demodulation using the WFM mode and playback via WebAudio.
SatDump Web Edition is an experimental browser port of SatDump. It converts the original desktop-running C/C++ SDR and satellite data processing programs into WebAssembly using Emscripten, allowing the core signal processing workflows to run directly in the browser without relying on any backend services.
The webpage directly controls the RTL-SDR using WebUSB, without requiring any plugins, background processes, or local forwarding agents. Once the IQ data transmitted via USB enters the browser, a multi-threaded DSP pipeline implemented in WebAssembly handles spectrum display, demodulation, recording, and satellite data processing – all computations are performed on your own machine, and no raw data is uploaded to any server.
Currently, I have tested RTL-SDR Blog V4, which supports real-time decoding of AM, NFM, WFM, USB, LSB, and CW. The project is still in the experimental phase, so please feel free to try it out with various RTL-SDRs, different browsers, and receiving scenarios.
Why was this transplant performed?
Last year, I moved the SSDV decoder to a web-based interface and spent some time debugging it. The results were much better than I expected. The performance of WebAssembly is now sufficient to handle many signal processing tasks that were originally only used in desktop applications. With the addition of WebGL, Web Workers, and SharedArrayBuffer, it's also possible to create a complete real-time processing pipeline.
Since the SSDV decoder can run in a browser, could we then take it one step further and also incorporate SatDump?
Starting last year, I have been periodically updating the development progress in the "SSDV Digital Slow Scan TV" group.
SatDump is a comprehensive package: it includes a complete DSP framework, a graphical user interface, FFT and filter functions, numerous satellite protocol and instrument processing plugins, image processing, projection capabilities, a file system, network functionality, as well as various SDR and audio device backends. The native version also relies on a large number of libraries such as VOLK, FFTW, libpng, SQLite, curl, NNG, and libtiff.
The interface portion uses Dear ImGui, so the first step is to connect it to a rendering backend based on WebGL 2.
Once the interface appears, the real challenges begin: how to migrate the entire C/C++ project and all its dependencies to WebAssembly?
- VOLK is tightly coupled with the CPU instruction set.
- FFTW requires an alternative implementation when used in a WebAssembly (Wasm) environment.
- The native thread needs to be mapped to a Web Worker;
- libUSB cannot be used directly in a web browser.
- The USB control and bulk transfer for librtlsdr should be connected to WebUSB.
- The desktop file system needs to be replaced with a virtual file system;
- The native audio output should be changed to Web Audio;
- Native sockets, dynamic plugins, and certain system APIs simply do not exist in browsers.
After a rough estimate of the workload, I realized that there were too many dependencies to refactor, and it was simply not feasible, so I decided to postpone it.😆
A turning point; a chance encounter
Later, Kimi released the K3 model, and I immediately integrated it into my workflow. I found that its agent capabilities were indeed very effective – even more user-friendly than models like Claude Opus 4.8 and GPT 5.5, and with excellent value for money. So… why not try it?
Therefore, I decided to pick up the project again. During the porting process, I used Kimi K3 to handle a significant amount of repetitive tasks related to dependency adaptation and build modifications. My main responsibilities included breaking down the tasks, defining the browser-side architecture, adjusting compilation constraints, and checking, testing, and correcting the generated changes.
After completing the first round of dependency replacement, the full SatDump interface was finally successfully launched in a browser for the first time.
Further, a number of stack overflow and I/O deadlock issues were fixed. The core functionality is now generally working as expected, but it still represents an experimental port. Performance and compatibility are significantly affected by the browser, operating system, GPU drivers, and USB controllers.
Some screenshots and instructions
The server is responsible for providing web pages, WebAssembly programs, and static resource files; all signal processing is performed locally.
Browser RequirementsWebGL2, WebAssembly, WebAssembly_SIMD128, WebUSB, AudioContext.
Minimum version: Chrome ≥ 91 or Edge ≥ 91. Firefox and Safari (macOS/iOS) cannot be used because they do not support WebUSB. The page will perform self-checks before loading; it is recommended to install the latest 64-bit version of Chrome or Edge for actual use.
The screenshots in this article are taken from Chrome version 134.0.6998.166 and Edge version 134.0.3124.51.
Connecting to RTL-SDR
If you are a Windows user and have previously used an RTL-SDR dongle and installed the WinUSB driver, you can directly connect to the RTL-SDR Blog V4 by opening the "Recorders" page without any additional configuration.
ImGui interface rendering
The ImGui interface and graphical components are all rendered using WebGL 2.
Image processing and projection
The image processing, display, and projection functions of the original SatDump can also be run in a browser.
Filesystem virtualization
The native version of SatDump heavily relies on the file system, and web pages cannot arbitrarily read and write to local disks like desktop applications. The web version uses Emscripten FS to allow programs to maintain a similar way of accessing files as a regular file system internally, while also using IDBFS to store the necessary data in the browser's IndexedDB. I have also added a simple file manager to easily browse, import, export, and manage the content of the virtual file system.
Settings page
In addition to the original configuration options for Satdump, you can also modify the DPI scaling factor used for page rendering (this requires refreshing the page).
About this page
In the past, browsers were primarily platforms for displaying interfaces and content. However, with the development of technologies such as WebAssembly, WebGL, WebUSB, WebAudio, and multi-threading, they can now handle relatively complete local computing tasks. A sizable C/C++ SDR and satellite data processing program can actually run directly in modern browsers without relying on a local backend. Next time you go stargazing, just bring a device that can open a browser.😎
Online Experience:https://satdump.quarix.me/
闽ICP备2021006864号-7
闽公网安备35020602002794号