SondeDocs · Using SondeFox
Decoder support
Every decoder in SondeFox runs inside a portable C++17 core with no radio, USB, or UI dependencies. The same code powers the Android app and the host-side sonde_replay CLI. This page explains the decode pipeline and gives the current status of each sonde type.
How decoding works
From antenna to telemetry, one frame of a radiosonde signal passes through this chain:
- IQ capture
The SDR streams over USB OTG (12-bit real samples from an Airspy, synthesized to IQ in software, or native 8-bit IQ from an RTL-SDR), and the capture bridge pushes complex-float blocks into a lock-free ring for the DSP thread.
- Channelize & demodulate
A DC blocker, frequency translator, and decimator isolate the sonde's channel (about ±5 kHz for RS41), then a narrow-FM/GFSK demodulator recovers the baseband waveform.
- Bit sync
Symbol-timing recovery locks onto the bit clock (4800 baud for RS41), and matched-filter header correlation identifies the sonde type and finds frame boundaries.
- Frame decode
The frame is de-whitened and split into its sub-packets: for RS41, TLV packets carrying serial, GPS, and PTU data inside a 320-byte frame.
- Error correction
Forward error correction repairs channel damage: two interleaved Reed-Solomon RS(255,231) codewords for RS41, Hamming(8,4) for DFM. Per-packet CRC-16 checks gate what counts as a valid frame.
- Telemetry
The parser converts raw fields into position, velocity, altitude, and UTC time (ECEF → WGS84 for RS41), plus temperature and humidity once enough calibration data has accumulated. Results feed the map, the chase pointer, and (opt-in) SondeHub.
Because the core is hardware-agnostic, every decoder can be exercised offline: sonde_replay plays recorded .cf32 IQ or .wav files through the identical pipeline, which is how new decoders are developed and regression-tested before they ever touch a live signal.
Status matrix
| Sonde type | Status | Notes |
|---|---|---|
| RS41 (Vaisala) | Beta | Full decode: serial, GPS position/velocity, and PTU with real calibration math. Reed-Solomon RS(255,231) error correction; PTU becomes available once the 51-subframe calibration accumulator fills. Validated against real flights, with humidity checked against frame-matched SondeHub data and official sounding archives. |
| DFM17 (Graw) | Beta | Detection, framing, and GPS extraction with Hamming(8,4) error correction. The decode has been independently validated against SondeHub's multi-station data. Caveat: DFM serials are unreliable until they stabilize across several frames. |
| DFM06 / DFM09 (Graw) | In validation | Same decoder path as DFM17: detection, framing, and GPS extraction with Hamming(8,4) error correction. The serial caveat above applies here too. Field validation remains in progress; from v0.14.14 that evidence status is independent of upload eligibility. |
| M10 / M20 (Meteomodem) | In validation | Shared decoder with checkM10 checksum verification. M10 runs at ≈9616 baud vs the M20's 9600; the two are disambiguated by the frame's type byte. Field validation remains in progress; from v0.14.14 that evidence status is independent of upload eligibility. |
| iMet-4 / iMet-1-RS (Intermet) | In validation | AFSK (Bell-202) decode with CRC-checked GPS and PTU frames. Engages automatically when tuned inside the met band. Field validation remains in progress; from v0.14.14 an iMet decode with a consensus-latched identity and the other strict telemetry gates may be submitted under its exact SondeHub mapping. |
| iMet-54 (Intermet) | Roadmap | Type is recognized in the registry; decoder not yet implemented, so it emits no telemetry and cannot upload. |
| LMS6 (Lockheed Martin) | Roadmap | Planned; not yet implemented, so it emits no telemetry and cannot upload. |
| Meisei | Roadmap | Planned; not yet implemented, so it emits no telemetry. Meisei also has no valid exact SondeHub type mapping and remains client-blocked. |
| MRZ | Roadmap | Planned; not yet implemented, so it emits no telemetry and cannot upload. |
| MTS01 | Roadmap | Planned; not yet implemented, so it emits no telemetry and cannot upload. |
These decoders are implemented and unit-tested against synthetic signals: the framing, error correction, and GPS extraction all pass on generated test data. What they have not had yet is enough real flights, with genuine fading, Doppler, and frequency drift, to be independently validated. That is exactly where beta testers help most. If DFM06/09, M10/M20, or iMet sondes fly near you, your field reports and IQ recordings move a decoder from "in validation" to validated.
SondeFox is in beta, and we keep the evidence tiers strict: roadmap types are never listed as supported, and "in validation" means exactly that. A decoder's badge does not advance until its output has been independently validated against real signals in the field. From v0.14.14 this evidence status is deliberately independent of telemetry transmission eligibility. If a listed status ever looks stale, tell us at [email protected].
Telemetry remains off by default and requires explicit opt-in plus a callsign. SondeFox considers only genuine radiosonde decodes with an exact SondeHub type mapping, and only after CRC, confirmed strict identity, GPS time/position, freshness, and plausibility checks. SondeHub's server-side denylist then decides which exactly mapped protocols it accepts, so that policy can change without an installed-app update. RS92's approximate RS41 mapping, Meisei's missing mapping, generic LMS6's unresolved 400/1680 MHz variant, APRS, WSPR, Meshtastic, C50, and Unknown remain client-blocked or local-only.