tinyGS: An ESP32 Ground Station Network for LoRa Satellites

TinyGS Reception Scope for Satellite and Probe Operators

TinyGS addresses a specific ground station problem: receiving transmissions from low-orbit or otherwise airborne devices without requiring a large, purpose-built station. It began as the ESP32 Fossa Groundstation for FossaSAT-1, then expanded into a network that accepts compatible radio transmissions from satellites, weather probes, and other flying objects. The intended users are radio experimenters, satellite teams, students, and hobbyists who can place an inexpensive ESP32 receiver at a useful location and contribute received packets to a shared service.

The project describes support for LoRa satellites and compatible modulation types including FSK, GFSK, MSK, GMSK, LoRa, and OOK. That range makes TinyGS broader than a single-satellite receiver, but it does not mean every radio or frequency is supported automatically. The hardware section specifically centers on ESP32 boards carrying sx126x or sx127x modules. Board templates can be created for other ESP32 combinations, while an OLED is optional for custom builds.

The network publishes received packets through tinygs.com. The site also lists ground stations and supported satellites, and the personal area permits remote editing of some station parameters. This arrangement serves two distinct needs. Local access remains available through a website on the station and its serial console, while the hosted service provides a community view and a remote configuration surface. The README says an API is being developed, so application developers should not treat API-based packet access as a documented current feature.

ESP32 and LoRa Hardware Required by TinyGS

TinyGS is firmware and configuration for specific hardware combinations rather than a vendor-neutral software receiver. Officially supported examples include Heltec WiFi LoRa 32 V1 and V2, TTGO LoRa32 V1 and V2, a manually modified TTGO LoRa32 V2, T-BEAM variants with OLED, and the FOSSA 1W Ground Station. It also lists ESP32 development boards fitted with sx126X hardware using either a crystal or TCXO, ESP32 development boards with sx127X, and two ESP32-S3 configurations based on HELTEC LORA32 V3 SX1262 and custom SX1278 hardware.

Frequency matters. The board list includes 433 MHz, 863 to 928 MHz, and 868 to 915 MHz versions for several commercial boards. A board name alone therefore does not prove compatibility. The exact radio variant and frequency must match the supported configuration or be represented by a suitable board template. TinyGS does not document a universal self-calibration routine that makes arbitrary radios safe to use.

The local and serial interfaces also provide different depths of control. The station website is intended for data and configuration access, while the serial port exposes a basic console. That distinction matters when diagnosing setup problems: a browser may be useful for station operation, but the serial console is the documented fallback for observing basic boot or operating information. The README does not enumerate every serial command, so users needing command-level control must consult the linked wiki or the board source rather than assume a complete CLI.

TinyGS Web Installer and First Station Setup

The shortest documented setup path is the TinyGS web installer. The README requires Google Chrome and supports Linux, Windows, or macOS. It directs users to the installer URL and says to follow the on-screen instructions for the first flash. Since no terminal commands are supplied in the README, there is no defensible command sequence to reproduce here.

Begin by confirming the exact board, radio family, and frequency band against the supported hardware list. Open `https://installer.tinygs.com` in Google Chrome, select the board configuration requested by the installer, connect the ESP32 in its flashing mode, and complete the prompts. The expected first outcome is firmware already installed on a board that can present its local website and serial console. The README does not specify LED patterns, serial text, or a default local URL, so those details should be taken from the installer and configuration documentation rather than invented.

PlatformIO is the documented alternative for flashing the latest release. The Arduino IDE is also supported, but the README describes that route as longer because it requires manual dependency installation. After initial operation, TinyGS documents two update mechanisms: local web OTA and automatic server updates. Both are optional. An operator supporting only one known satellite may prefer fixed settings and controlled local upgrades rather than automatic changes.

TinyGS Local Console, Web Dashboard, and Network Data Flow

A configured station has two documented forms of local access. Its own website provides station data and configuration, while the hardware serial port shows a basic console. Once connected, received packets are also sent into the TinyGS network presentation at tinygs.com, where users can inspect supported satellites, ground stations, and community packets in real time according to the README.

This creates a split between device-level administration and network-level visibility. Local access is the closer interface for inspecting or changing a particular station. The hosted website aggregates the network perspective and includes a personal area for editing some parameters remotely. The documentation does not define whether every local operation is available remotely, nor does it specify packet-retention limits, authentication behavior, or service availability. Those omissions matter for anyone considering TinyGS as operational telemetry infrastructure.

Radio tuning can be automated after connection. The README says the server can remotely configure a ground station so it can listen for the next satellite pass with the correct settings. Operators can opt out, which is appropriate when a station is intentionally dedicated to one satellite or transmitter. The practical trade-off is clear: automation can reduce manual retuning between passes, while opting out provides more control over fixed operating parameters. The linked Radio Tuning Guide, rather than the README alone, is the source for the tuning mechanism and configuration fields.

TinyGS OTA Updates and Dependency Maintenance

TinyGS supports two OTA routes after the initial flash: a local web update and an automatic update method. The README also describes optional server-driven OTA once a station is alive and connected. Automatic updating and auto tuning can be disabled separately in the ground station configuration. This gives operators a direct control over unattended firmware changes and radio retuning.

The main cost is not only flashing a board. The firmware relies on RadioLib, ArduinoJson, ESP8266_SSD1306, IoTWebConf2, PubSubClient, ESPNTPClient, and FailSafeMode. PlatformIO is intended to manage the embedded build path, while the Arduino IDE route requires dependencies to be installed manually. Custom hardware support may also require creating or adapting a board template, which increases verification work beyond ordinary application dependency installation.

TinyGS is licensed under GPL-3.0. For distributed firmware or derived source, that license carries source availability, notice, and copyleft obligations. This review does not interpret how those obligations apply to a particular deployment; the project license and applicable distribution circumstances need separate review. The repository is not archived, and its last push was on 2026-10-14. The listed releases include `2603242` from 2026-04-07, `2403241` from 2024-03-24, and `v2402091` from 2024-02-09. These dates indicate recent repository activity, but the README does not publish a long-term support policy or compatibility promise for automatic updates.

TinyGS Constraints Compared with a Standalone Receiver

The clearest alternative is a standalone local receiver that keeps reception, decoding, logging, and station control on the operator's own equipment without depending on the TinyGS community service. The difference is architectural rather than cosmetic: TinyGS couples an ESP32 station to local interfaces, community packet publication, remote parameter editing, automatic tuning, and optional server-driven OTA. A standalone design can avoid that service coupling, although the README does not document a specific alternative implementation or claim that every packet format can be decoded independently.

TinyGS also has clear boundaries within its own design. Its documented hardware focus is ESP32 with sx126x or sx127x modules. Other ESP32 combinations may work through templates, but that is a configuration task, not an automatic guarantee. The API is described as under development, so the public website and community channels are the documented data routes. The console is described only as basic, not as a documented automation interface. Finally, automatic OTA and tuning are server-dependent capabilities that can be disabled, which is useful for fixed installations but removes some convenience.

For a controlled experiment on one transmitter, opting out of remote automation may be preferable. For a distributed listening network where packet sharing and remote station management are desired, TinyGS provides a more integrated operating model than a collection of unrelated receivers.

Editorial conclusion

TinyGS fits experimenters and operators who want inexpensive ESP32 receivers, shared community data, and web-based station management. It does not fit deployments requiring a documented API, guaranteed OTA service, or radio hardware outside the supported ESP32 and sx126x or sx127x combinations. Verify first that the exact board and frequency version are supported, then confirm the configuration and serial console behavior documented in the wiki before relying on unattended reception.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. tinygs/tinyGS on GitHub