Frequently asked questions

A radiosonde is a small instrument package carried aloft by a weather balloon. As it climbs, it broadcasts its position, altitude, temperature, and humidity on the 400–406 MHz band as part of the public meteorological service. Weather agencies launch them worldwide roughly twice a day, around 00 and 12 UTC. Eventually the balloon bursts and the sonde falls back to earth. That is where the chase begins.

SondeFox scans for these signals, decodes the telemetry, maps the flight with a predicted landing point, and guides you to the sonde on the ground.

In most places, yes: weather services generally don't collect landed sondes, and finders keepers is the norm among chasers. Rules do vary by country, though, so check your local guidance before making a habit of it. And wherever you chase: never trespass. If a sonde lands on private property, ask permission first.

Generally no. Radiosonde telemetry on 400–406 MHz is unencrypted, broadcast for the public meteorological service, and receiving it is legal in most jurisdictions. SondeFox does not transmit radio-frequency signals; its optional network features are described separately below.

Laws vary, so check your local regulations before going further than listening, in particular before uploading telemetry or chasing. See license & legal for the longer version.

Yes. SondeFox is free for beta testers, and there is no plan to charge for it. The project spans the Android app, the portable C++ decoder core, a host-side replay CLI, and the reviewed sdr-fox companion driver used for RTL-SDR support. Licensing and source-availability terms for the public release are still being finalized and will be announced before launch. During the closed beta the app is distributed by invitation; see the beta program for how to get in.

When beta validation completes; there's no date to announce. The RS41 decode chain is validated end-to-end and live over-the-air reception is being proven on real hardware. The closed beta exists to prove it across more devices, antennas, and launch sites before a wider release. If you'd like to help get it there, join the beta, or try the live demo right now, no install needed.

Three things. An Android 10+ phone or tablet with USB-OTG support. An SDR connected over an OTG cable: an Airspy Mini or R2, or an RTL-SDR dongle with an R820T/R820T2/R828D tuner (including the RTL-SDR Blog V3 and V4). An antenna for 400–406 MHz: a quarter-wave whip (about 17 cm) works, a small Yagi works better. A powered OTG hub is recommended, since these radios draw significant current. Full details in the hardware guide.

Yes. Alongside the Airspy Mini and R2, SondeFox drives RTL2832U dongles with R820T/R820T2/R828D tuners (including the RTL-SDR Blog V3/V4) directly over Android's USB host API, with the same no-root, no-driver setup. Discovery is by USB vendor/product ID, so a dongle that is not on the supported list is never found at all rather than rejected with a message; if your dongle uses an E4000 or FC001x tuner, the app will simply not see it. The Airspy's 12-bit samples give it more dynamic-range headroom in crowded RF, but an inexpensive RTL dongle is enough to chase with. If both are plugged in, the Airspy wins.

Any Android 10 or newer device with USB host (OTG) support. Because these SDRs draw significant current over USB, some phones need a powered OTG hub; we recommend one for long chases regardless. A foreground service keeps capture and decode running with the screen dimmed, so the app survives a pocket.

No. SondeFox talks to your SDR through Android's standard USB host APIs: no root, no kernel drivers, no custom firmware. Plug in, grant the USB permission prompt, and you're receiving.

RS41 · DFM17 The Vaisala RS41 and Graw DFM17 are the working decoders. Both have been validated against SondeHub's own multi-station data and are cleared to publish telemetry to SondeHub; uploading itself stays opt-in and off by default. Wider field validation continues, which is what the beta is for.

DFM06/09 · M10/M20 · iMet-4 Graw DFM06/09, Meteomodem M10/M20, and InterMet iMet-4 decoders are implemented and tested on synthetic signals, but still in validation against real RF. They decode on-device; their telemetry is held from SondeHub upload until each protocol clears validation.

iMet-54 · LMS6 · Meisei · MRZ · MTS01 On the roadmap; not decoding yet.

The decoder support page tracks status in detail.

Yes, with the 2D renderer. Decoding is fully local (no cloud in the signal path), and MapLibre 2D provider content that you browse or explicitly prefetch may be reused from the on-device cache, so a prepared chase area keeps rendering without coverage. The last known target and landing prediction remain available too. Native Google 3D is online-only, and SondeFox provides no offline store for Google content.

SondeHub features need a connection: syncing a saved flight, community landing predictions, any uploads you have opted in to, and—only in the separately installed SondeFox Test debug build—the explicitly activated SondeHub Live preview. Production v0.14.0 does not expose the Network Live source or authorize its REST/MQTT runtime. If you enable Saved Flights Auto-update, Android may make network-constrained exact-history refresh requests in the background about every 15 minutes, following your Wi-Fi-only or cellular choice. The debug preview pauses when offline; flights already imported into Saved Flights stay readable.

No, and none is planned. SondeFox exists because Android's USB host API lets an app drive an SDR directly over OTG with no root and no drivers. iOS offers no equivalent path for this kind of hardware access.

Not as SondeHub upload data unless you deliberately switch an upload on. Uploading decoded telemetry is off by default and requires an explicit opt-in plus a configured callsign. Be aware that telemetry uploads do not carry only the sonde's position: when the phone has a recent GPS fix, each record also includes your receiver's own position, at full resolution, as uploader_position. The telemetry opt-in is the only gate on that; the position toggles do not affect it.

The user-controlled features that can send your own position as application data are the uploader_position field inside telemetry uploads, the station-position and chase-car toggles (both off by default), a manually confirmed recovery report when it uses the phone's current GPS fix, and the developer capture flows, which send exact GPS to the private debug server. A recovery report also sends coordinates including altitude, callsign or reporter name, recovered/not-found status, notes, a SondeFox recovery-software identifier, and a planned-status flag. Separately, SondeHub Live is currently available only in the separately installed SondeFox Test debug build. Production v0.14.0 does not expose the Network Live source or authorize its REST/MQTT runtime. In the debug preview, closer zooms send the viewed 2D map centre and search radius after you select the preview and accept its network disclosure; following your device can therefore reveal an approximate location. Broad views do not send the centre. SondeHub also receives ordinary request metadata such as your IP address. Native 3D discovery currently fails closed rather than estimating this viewport.

One caveat: anything you do upload joins the public SondeHub stream and may be redistributed. Details in the SondeHub guide and the privacy notes.

No. The experimental chirp monitor is off by default and recovers raw PHY-level bits from chirp-spread-spectrum (CSS) transmissions only. It is meant for signals you're authorized to receive: your own devices, amateur-radio telemetry under your license, ISM-band experiments, and other legally authorized public telemetry.

It contains no key extraction, no payload decryption of any kind, and no private-network interception. That is a deliberate design boundary, not a missing feature. See Chirp monitor.