# radiosonde_auto_rx: turning an RTL-SDR into a weather balloon tracker > radiosonde_auto_rx is a set of utilities that decode telemetry from weather balloons and upload the positions to SondeHub, APRS-IS and ChaseMapper, built on rs1729's RS demodulators and packaged as a C program with per-sonde-type subdirectories plus a Python web interface. The support matrix for fifteen sonde models is where the real limits of the project are visible. **projecthorus/radiosonde_auto_rx** — Automatically Track Radiosonde Launches using RTLSDR or AirSpy SDRs - Repository: https://github.com/projecthorus/radiosonde_auto_rx - Stars: 617 · Forks: 152 - Language: C - License: GPL-3.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/projecthorus-radiosonde-auto-rx ## What the project does, and where it sits in the hobby The description is plain: automatically track radiosonde launches using RTLSDR or AirSpy SDRs. The README expands it. The project is built around rs1729's RS demodulators, and provides a set of utilities, called auto_rx, that allow automatic reception and uploading of radiosonde positions to multiple services. A radiosonde is the instrument package carried aloft on a weather balloon, and its job is to send back pressure, temperature and humidity as it climbs. The interesting part of the hobby is that you do not need to be near the launch site. The telemetry is transmitted on a frequency band that reaches much further than you would expect, so a single receiver with an antenna pointed at the right direction can pick up launches across a wide area, and the useful work is decoding the weak signal reliably and reporting the position as it climbs. That is what auto_rx does, and the destinations show what a tracker is for. The SondeHub Radiosonde Tracker is described as a tracking website specifically designed for tracking radiosondes. APRS-IS is an amateur radio position service, and the README notes that aprs.fi now blocks radiosonde traffic, which is a real operational detail for anyone choosing an upload target. ChaseMapper is for mobile radiosonde chasing. There is a web interface for seeing the live status of your station and for reviewing and analysing previous radiosonde flights, and collected meteorological data can be plotted in the common Skew-T format, which is the standard presentation for atmospheric sounding data. The primary language is C, the licence is GPL-3.0, the last push was on 2026-09-19, and the recent releases are v1.9.0 from 2026-09-19, v1.8.2 from 2026-02-01 and v1.8.1 from 2025-02-21. The repository is not archived. ## The support matrix is the honest documentation of this project The support matrix in the README is the most useful thing in it, because it says exactly what works and what does not, per model, per field. Fifteen manufacturers and models are listed, and the columns are position, temperature, humidity, pressure and XDATA. Vaisala RS92-SGP/NGP has all five. The RS41-SG/SGP/SGM has position, temperature, humidity and XDATA, with humidity marked as applying to the SGP variant. Intermet Systems iMet-4 has all five, and the iMet-54 has position, temperature and humidity with pressure marked as not sent. Graw DFM06/09/17 has position, temperature and XDATA, with humidity and pressure marked as unavailable. The rest of the table is a mixture of full support and partial support, and the pattern is informative. Meteomodem M10 and M20 give position, temperature and humidity with pressure not sent and XDATA unavailable, and the M20 marks XDATA as applying to some models. Meisei iMS-100, RS11G and the Meteo-Radiy MRZ-H1 give position, temperature and humidity. Meteosis MTS01 and Changfeng CF-06 give position and temperature only. Changwang GTH-6 has all five fields with XDATA not sent, and Meteolabor SRS-C50 has all five with XDATA unavailable. So the honest summary is that position and temperature are broadly supported across the range, while pressure, humidity and the auxiliary XDATA channel are where coverage varies by model, and in several cases the sonde simply does not transmit the field at all. That distinction between not supported by the decoder and not sent by the sonde matters when you are diagnosing a station that seems to be missing a value. The project also asks for help in a way that is unusually specific: support for other radiosondes may be added as required, and if you have information about telemetry formats they would like to hear about it. The project wants the hardware, and the decoder work is bounded by what someone can bring to test with. ## Where the code lives, and how it is structured The top-level tree is the clearest description of the internals. There is an auto_rx/ directory for the Python side, a demod/ directory for the demodulators, and then a directory per sonde family: c50/ for the Meteolabor SRS-C50, imet/ for the Intermet iMet series, m10/ for the Meteomodem M10, meisei/ for the Meisei models, mk2a/ for the Mar radiosonde, scan/ for the band scanner, dropsonde/ for dropsonde support, utils/ for shared helpers, and weathex/ for the weather and cross-section decoding. The Makefile confirms the shape. It defines a list of subdirectories, demod/mod, imet, c50, mk2a, scan, dropsonde, utils and weathex, and the all target recurses into each one. The compiler flags are -O3 with warnings suppressed, and the version string is injected at compile time with a define, pulled from the Python package by running the autorx.version module. That last detail is worth a moment, because it explains a design choice that would otherwise look strange. The version that the C binary reports comes from the Python side, because the Python side is where the station configuration and the web interface live, and the two have to agree. The C is the signal path and the Python is the control plane, and the Makefile keeps them in sync. The demod/ directory is the part that comes from upstream. The README says the project is built around rs1729's RS demodulators, that improvements from the upstream RS codebase will be merged into this codebase when and where appropriate, and it thanks rs1729 for continuing to develop the decoders. So the demodulators are a vendored upstream dependency that is periodically re-synced, and auto_rx is the station software wrapped around them. ## The container build, and what it compiles from source The Dockerfile in the repository is worth reading, because it shows the full dependency set of a working station, and it builds several things from source rather than taking them from packages. The base image is debian:bookworm-slim, and the build stage installs the usual autotools and build-essential set plus cmake, ninja-build and pkg-config, along with a set of libraries that map directly to what the software does: libsamplerate0-dev for audio resampling, libusb-1.0-0-dev for the SDR hardware, libatlas-base-dev, libfftw3-dev for the signal processing, libiniparser-dev for configuration parsing, libogg-dev and libopus-dev, and libavahi-client-dev for the network audio discovery used by the weathex component. Then three components are compiled from source. rtl-sdr comes from a fork of the steve-m librtlsdr repository, configured with DETACH_KERNEL_DRIVER=ON, which is what lets an RTL-SDR work without root on modern kernels. spyserver_client, from miweber67, is built with make and is the client for AirSpy-style network receivers. And ka9q-radio is cloned and built on 64-bit architectures, with the architecture selected through the build argument, which is the same ka9q-radio code that shows up in the release notes. The Python side is installed with pip3 from the requirements file in auto_rx, and the build also copies in any pre-built wheels it finds. The final stage is a runtime image that carries the compiled binaries. So the dependency surface is substantial but conventional: an SDR driver, an SDR network client, a radio and audio stack, and the demodulator code. None of it is exotic, and the fact that the rtl-sdr build detaches the kernel driver is the detail that decides whether a station can run without root. ## Licensing, and who to talk to There are three licences in play and they cover different things. The software itself is GPL-3.0, with the full text in the LICENSE file. Radiosonde telemetry data captured through the software and uploaded into the SondeHub database is licensed under Creative Commons BY-SA v2.0. Telemetry data uploaded into the APRS-IS network is generally considered to be released into the public domain. The practical point is the last sentence of that section: by uploading data into these systems, by enabling the relevant uploaders within the station.cfg file, you as the user agree for your data to be made available under those licences. Uploading to SondeHub is enabled by default, so a station that is set up and left alone is publishing its observations under a share-alike licence without anyone having decided to. That is worth knowing before the first launch, because the data is meteorology in most cases but the mechanism does not distinguish. The contacts are two people. Mark Jessop, listed with a call sign and an address at rfhead.net, and Michaela Wheeler, listed with a radiosonde address. The wider community is reached through a Google Group for the project and a channel in the SondeHub Discord server. The project also asks users to update regularly, because the software is under regular development and the wiki page for performing updates is linked from the README. That is a normal request for a project where decoder support depends on the hardware, and the support matrix, with its request for people to send sondes for testing, is the reason: a new sonde model only enters the matrix when someone brings the hardware and the telemetry format details. ## What to check before you set up a station The evaluation for this project is unusually practical, because the README tells you what to look at. First, the model. Find the exact manufacturer and model of the sonde you intend to receive, and read its row in the support matrix. If humidity or pressure is marked as unavailable or not sent for your model, no amount of configuration will produce that value, and the matrix is the place to find out before you buy a receiver. Second, the receiver. The project targets RTLSDR and AirSpy hardware, and the container build compiles both the rtl-sdr driver with kernel driver detachment and the spyserver client for network receivers, so the supported paths are visible in the build file rather than only in prose. Third, the upload targets. SondeHub is the primary one and is enabled by default, APRS-IS is an alternative with the note that aprs.fi now blocks radiosonde traffic, and ChaseMapper is the mobile companion. Which of those you enable determines the licence your observations are published under, which is the one thing to decide deliberately. Fourth, and most importantly, the project tells you the most current information is in the wiki, not the README, and points there first. The wiki holds the installation guide, the web interface guide, the performing updates page and the supported platforms information. The README itself is a good summary of scope and support, but for setup details the wiki is the source. Finally, the two presentations in the README are a hint about the community's shape. The project has been presented at Linux.conf.au 2019 and at the UKHAS Conference 2019, and the author explicitly thanks rs1729 for the demodulator work the whole thing rests on. This is a project built on other people's decoders, and that dependency is the thing to keep in mind when you are deciding how much to invest in it. ## Conclusion Adopt radiosonde_auto_rx if you want to receive weather balloon telemetry yourself with a cheap RTL-SDR or an AirSpy and publish the tracks to SondeHub, and if you are comfortable with a C and Python stack built around a vendored upstream demodulator. Do not adopt it expecting every sonde model to yield every field, because the support matrix shows humidity, pressure and XDATA missing for a good number of models, and do not leave the default configuration alone without reading what the uploaders mean for the licence of the data you publish. Before you commit, find the row for your exact sonde model, check the wiki for the current setup and the supported platforms, and decide deliberately whether SondeHub, APRS-IS or ChaseMapper is the target you want, since enabling an uploader is what publishes your observations. ## FAQ ### What does the radiosonde_auto_rx project do? It provides a set of utilities, auto_rx, for automatic reception and uploading of radiosonde positions to multiple services, built on rs1729's RS demodulators. It works with RTLSDR or AirSpy SDRs and can upload to SondeHub, APRS-IS and ChaseMapper, and includes a web interface for station status and flight review. ### Which radiosonde models does radiosonde_auto_rx support? The support matrix covers fifteen models from Vaisala, Graw, Meteomodem, Intermet Systems, Lockheed Martin, Meisei, Meteo-Radiy, Meteosis, Changfeng, Changwang and Meteolabor. Position and temperature are broadly covered, while pressure, humidity and XDATA vary by model, and the project asks for people to send sondes so new formats can be added. ### What does the radiosonde_auto_rx container build compile from source? It compiles rtl-sdr from a steve-m fork with kernel driver detachment enabled, spyserver_client from the miweber67 repository, and ka9q-radio on 64-bit architectures, on top of a debian:bookworm-slim base with the SDL, audio and signal processing libraries installed from packages. ### Under what licence is data uploaded by radiosonde_auto_rx published? Telemetry uploaded into the SondeHub database is licensed under Creative Commons BY-SA v2.0, while data uploaded to APRS-IS is generally considered released into the public domain. The software itself is GPL-3.0, and uploading to SondeHub is enabled by default in the station configuration. ### How do I know the current setup instructions for radiosonde_auto_rx? The README says to refer to the auto_rx wiki for the latest information, and links the guide for performing updates, the web interface guide and the supported platforms information. It also asks users to update regularly, since the software is under regular development and decoder support depends on the hardware available for testing. ## Sources - [Issues](https://github.com/projecthorus/radiosonde_auto_rx/issues) - [License: GPL-3.0](https://github.com/projecthorus/radiosonde_auto_rx/blob/master/LICENSE) - [projecthorus/radiosonde_auto_rx on GitHub](https://github.com/projecthorus/radiosonde_auto_rx) - [README](https://github.com/projecthorus/radiosonde_auto_rx/blob/master/README.md) - [Releases](https://github.com/projecthorus/radiosonde_auto_rx/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/projecthorus-radiosonde-auto-rx