A low-Earth-orbit satellite gives any one rooftop only a few minutes of contact before geometry closes the link. Connecting many rooftops turns those short local windows into wider geographic coverage—but “open-source ground station” now describes several very different bargains.

TinyGS starts with a small ESP32-class LoRa radio and makes packet reception inexpensive. SatNOGS connects software-defined receivers to a shared scheduler, satellite database, and public observation archive. UniClOGS begins where a university mission team needs to transmit commands as well as receive telemetry. These are not three rungs on a maturity ladder. They are three lanes separated by radio bandwidth, operator authority, data products, licensing, and tolerance for best-effort infrastructure.

That distinction matters before anyone buys an antenna. A mission whose beacon fits a supported low-power modem can gain enormous value from thousands of TinyGS receivers. A researcher who needs waterfalls, audio, or satellite-specific GNU Radio processing is asking for the broader SatNOGS receive stack. A team that must send authenticated telecommands needs its own licensed, controlled ground segment; public reception networks can supplement that system, but they cannot inherit its authority.

Image context: the cover is a real SatNOGS v2 station deployed at FOSDEM in 2015, the year after the project won the Hackaday Prize. Its crossed antennas and visible mechanics keep this map grounded in physical infrastructure rather than cloud-service metaphor.[12][13]

Read the lanes by their contract

The table is a routing aid, not a compatibility promise. Frequency is only the first gate. A useful match also requires the right modulation, bandwidth, data rate, antenna pattern, Doppler handling, decoder, horizon, and legal authority. “There is a station nearby” says little until those fields line up.

TinyGS makes the receiver the smallest useful unit

TinyGS compresses the station edge into a Wi-Fi-connected microcontroller board with an integrated LoRa-class transceiver. Its repository describes ESP32 and ESP32-S3 boards paired with SX126x or SX127x radios, including supported 433 MHz and 863–928 MHz variants. A browser installer handles the first flash, while optional over-the-air updates and server-side auto-tuning can prepare the receiver for upcoming passes.[7]

The low entry cost comes from a deliberately bounded radio path. A board such as a Heltec WiFi LoRa 32 or TTGO LoRa32 can demodulate modes supported by its transceiver and firmware without hosting a Linux system, GNU Radio, or a general SDR. That is excellent leverage when a spacecraft’s downlink matches. It is the wrong abstraction when a project needs arbitrary I/Q capture, a wide experimental bandwidth, an unsupported waveform, or several bands through one front end.

The hardware boundary also makes deployment legible. The antenna must match the band; a 433 MHz RF path does not become an 868 MHz path through a dashboard setting. One station can be cheap enough for a classroom or remote site, while geographic density compensates for the brief pass visible at each location. A satellite operator gets timestamped packets from many receivers without owning every roof.

TinyGS is designed first as a receive network, although its programmatic API documents a transmission endpoint. That API is marked as under development, requires transmit to be explicitly enabled in station firmware, and does not itself grant regulatory or mission authority.[7][8] The combination is a warning against treating community uplink as a routine command channel: a technically present endpoint is not the same thing as licensed access, authenticated mission control, or scheduled operational responsibility.

SatNOGS makes the observation the shared unit

SatNOGS puts a more capable computer and radio at the edge, then shares an observation rather than only a decoded packet. Its reference station architecture includes satnogs-client, satellite-specific and generic satnogs-flowgraphs, GNU Radio, gr-soapy for SoapySDR devices, gr-satnogs, configuration tooling, and optional Hamlib rotator control.[2]

The handoff begins in two public information systems. SatNOGS DB supplies satellite and transmitter records through an openly readable, CC BY-SA REST API. SatNOGS Network handles stations, scheduled jobs, observations, and returned data through its own API.[4][5] Keeping those responsibilities separate matters: a transmitter’s frequency and mode describe what might be heard, while an observation records what one station attempted during one pass.

At the station, the client pulls jobs, calculates Doppler correction, selects a receiver path, invokes the relevant flowgraph, moves a compatible rotator if present, and uploads results. The versioned Client 2.1.1 documentation exposes operational details rather than hiding them behind a single “connect” switch: SATNOGS_API_TOKEN and SATNOGS_STATION_ID bind an installation to its Network identity; the default job-query interval is 60 seconds; the default observation-post interval is 180 seconds; and precise latitude, longitude, and elevation improve Doppler correction while reducing location privacy.[3]

The physical station can therefore vary much more than a TinyGS node. SatNOGS recommends a Raspberry Pi as the best-supported entry point, but the receive chain may use a fixed omnidirectional antenna for stronger passes or a directional Yagi or helix on a rotator for fainter CubeSats. An SDR, low-noise amplifier, filter, feed line, local interference, horizon mask, clock error, and compute budget all influence the result. The common software contract makes heterogeneous stations schedulable; it does not make their measurements interchangeable.[1][2][14]

This is why the archive keeps failed observations meaningful. SatNOGS announced its 14 millionth observation on 6 May 2026—and that observation, a Riga station’s attempt to receive LUSAT, was marked failed. The project presented the failure as evidence for network density and backup coverage, not as a record to discard.[6] A miss can reflect a silent spacecraft, stale orbital or transmitter data, low elevation, obstruction, interference, gain, frequency error, decoder mismatch, or a station fault. One negative result rarely identifies which cause won.

The public network is large but not the whole system. Libre Space Foundation reports more than 500 operational and more than 4,000 registered stations, alongside an active service-oriented refactor. It also publishes the software and hardware under open licences.[1] The useful distinction is between reproducibility and availability: source access allows another operator to inspect or deploy components, while the reach of the public instance comes from a hosted scheduler, maintained databases, and hundreds of people contributing working radios.

UniClOGS makes command authority local

Receive diversity and spacecraft command are different trust domains. UniClOGS—University Class Open Ground Station—was developed by the Portland State Aerospace Society after its OreSat team found the SatNOGS receive model valuable but insufficient for sending commands. The resulting design adds a mission-owned transmitter, configurable RF hardware, GNU Radio processing, and control software while retaining an open-hardware and open-software approach.[10][11]

That change moves the station into another cost and governance class. A 2024 Small Satellite Conference paper describes UHF, L-, S-, and X-band options, commercial off-the-shelf RF components, transmit capability for amateur-radio missions, and an estimated complete-station range of roughly $10,000 to $25,000. The same paper explicitly contrasts UniClOGS with the receive-only SatNOGS network and explains why remote sharing of non-amateur uplinks is difficult.[10]

The extra zeros buy more than antenna gain. A command station needs controlled credentials, approved frequencies and power, transmit interlocks, pass procedures, operator roles, logs, time synchronization, spacecraft-safe command sequencing, and a recovery path. It also needs a link budget proven against the actual satellite. Open schematics and software make those responsibilities inspectable and reusable; they do not transfer them to a volunteer network.

UniClOGS therefore complements the public receive lanes. A university can use TinyGS or SatNOGS observations to discover where a beacon was heard, compare reception across geography, or obtain post-launch evidence outside its own horizon. Its local UniClOGS installation can remain the authoritative route for telecommand and higher-bandwidth mission links. The seam is data and planning, not shared possession of the transmit key.

Interoperability begins with metadata, not logos

An independent 2024 comparison of TinyGS and SatNOGS found the former simpler and cheaper to implement, while the latter had decoded a broader satellite set in the study’s 29 July 2023 snapshot. The authors also showed why raw station totals are a poor universal score: geographic distribution, supported satellites, frequency, hardware, and network definitions differed.[9] Those counts are now historical; the durable lesson is to compare a mission against the lane’s receive contract, not declare one network the winner.

For a spacecraft team, the interoperability record should include at least:

1. the spacecraft identifier and current orbital elements used for pass prediction;
2. every downlink’s center frequency, bandwidth, modulation, baud rate, framing, and expected Doppler range;
3. the station position, horizon mask, antenna, radio, gain/filter chain, clock source, and software versions;
4. the observation or packet identifier, UTC start and end, raw or derived artifact, decoder version, and quality verdict;
5. whether the path was public reception, private reception, or licensed command—and who held authority.

That record lets a TinyGS packet, a SatNOGS waterfall or decoded frame, and a mission-owned UniClOGS contact inform the same investigation without pretending they are the same artifact. It also preserves the failure boundary. If two networks miss a pass, the team can ask whether they shared the same transmitter metadata. If one station hears it and another does not, the antenna, horizon, noise floor, tuning, and decoder become testable variables.

Choose coverage only after choosing the signal

TinyGS is the sharpest on-ramp when the downlink fits supported low-cost radio hardware and the desired product is a packet stream. SatNOGS is the richer shared receive lane when the mission benefits from scheduled SDR observations, open transmitter metadata, waterfalls, audio, or extensible demodulation. UniClOGS is the relevant pattern when the organization must own uplink and mission operations as well as reception.

None of the three turns a rooftop into guaranteed coverage. Community stations go offline. Antennas see different horizons. Local noise moves. Central services need maintenance. Decoders and orbital elements age. Transmission remains regulated. The sound design is layered: prove the waveform on one controlled station, use public networks for geographic diversity and independent evidence, and keep safety-critical command authority inside an operated ground segment.

The ecosystem’s advantage is precisely that these lanes can remain different. TinyGS can optimize for the smallest useful receiver, SatNOGS for the most reusable public observation, and UniClOGS for a replicable mission station. Open interfaces then let a satellite team combine their evidence without asking one project to become every kind of ground station.

Sources

1. Libre Space Foundation, “SatNOGS” — current project scope, Network/Client/DB roles, operational scale, licences, milestones, and service-oriented direction.
2. SatNOGS documentation, “SatNOGS Station Architecture” — Client, GNU Radio flowgraphs, SoapySDR, configuration, rotator control, and upload boundaries.
3. SatNOGS Client 2.1.1 documentation, “Environment variables” — station identity, API polling, artifacts, radio and rotator configuration, and the location-precision tradeoff.
4. SatNOGS Network documentation, “API” — scheduled jobs, observation uploads, OpenAPI reference, and CC BY-SA data access.
5. SatNOGS DB documentation, “API” — public satellite and transmitter metadata and CC BY-SA access.
6. SatNOGS, “New Milestone for SatNOGS: 14M Observations!” (28 May 2026) — milestone date, failed observation #14000000, network-density argument, and open-data context.
7. TinyGS, official firmware repository — ESP32 and SX126x/SX127x hardware support, band variants, installation, hosted data path, auto-tuning, supported modes, and GPL-3.0 licence.
8. TinyGS, “Programmatic API” — beta-status warning, authentication, and firmware-gated station transmission endpoint.
9. João Sá Gomes and Alexandre Ferreira da Silva, “TinyGS vs. SatNOGS: A Comparative Analysis of Open-Source Satellite Ground Station Networks,” Telecom 5(1), 2024 — independent comparison with an explicitly dated 2023 network snapshot.
10. Glenn LeBrasseur et al., “University Class Open Ground Station (UniClOGS),” Small Satellite Conference, 2024 — transmit-capable university use, RF bands, cost range, GNU Radio stack, and the receive-network boundary.
11. OreSat, “Ground Stations” — UniClOGS origin, operational purpose, transmit requirement, SatNOGS relationship, and Portland State deployment.
12. David Schneider, “The Hackaday Prize Awarded to Satellite Ground Station Project,” IEEE Spectrum (13 November 2014) — independent contemporary account of SatNOGS’s origin and central-server network concept.
13. Nikos Roussos, “SatNOGS v2 in FOSDEM 2015,” Wikimedia Commons — source and provenance for the 31 January 2015 archival ground-station photograph used as the cover, licensed CC BY 2.0.
14. SatNOGS Wiki, “Build” — current reference platforms, fixed and rotating antenna paths, radios, amplification, and hardware-support boundaries.