Wiznet makers

What Is an Aerostat?

An aerostat is a tethered balloon — not a free-floating weather balloon that drifts with the wind, but one anchored to the ground by a cable, held at a fixed altitude above a specific location. The applications range from military surveillance and border monitoring to civilian uses like persistent atmospheric research, agricultural monitoring, and communications relay. Because they stay in one place, aerostats can run 24/7, continuously collecting data in a way a drone or free-floating balloon cannot.

Running sensors continuously at altitude creates a specific set of engineering problems. The platform vibrates in the wind. Temperatures swing between extremes as the balloon rises and falls. The tether cable limits what you can run between ground and sky. And because the balloon may be up for days or weeks at a time, the firmware has to be robust — a crash that requires manual intervention is not just inconvenient, it is operationally unacceptable.

The Aerostat Mega Sensor Hub, built by Prvin-Embed, addresses all of these constraints in a clean, open-source design that splits the work across two microcontrollers and brings W5500 Ethernet connectivity to the ground-station link.

A Two-MCU Architecture

The most interesting architectural decision in this project is the deliberate separation of concerns across two microcontrollers: an Arduino Mega and an ESP32, each with a distinct role.

The Arduino Mega is the sensor front-end. It handles the full environmental and mechanical measurement stack: dual BMP390 barometric pressure and temperature sensors (one on I2C, one on SPI for redundancy), an MPU9250 nine-axis IMU for attitude data, an HX711 load cell amplifier for tether tension measurement, an anemometer for wind speed, and a DS3231 RTC for accurate timestamping. It also manages two relays for controlling external hardware. All of this data is collected under an RTOS-style cooperative scheduler with a hardware watchdog, then streamed as a CSV row over Serial1 (pin 18) at a defined interval.

The ESP32 is the communications and logging hub. It receives the Mega's CSV stream over UART, merges in its own sensor readings — a BNO055 orientation sensor and a DHT22 for humidity — and produces a final 17-field CSV record. That record goes two places simultaneously: an SD card for local logging, and a W5500 Ethernet interface that transmits over TCP port 5000 down the optical fiber cable (OFC) to the ground station.

The split is deliberate. The Mega has more I2C and SPI peripherals, more UART ports, and more GPIO for analog sensors and relays. The ESP32 brings Wi-Fi, Bluetooth, and crucially for this application, easy integration with the W5500 for wired Ethernet. Neither microcontroller alone handles the full job as cleanly as the two together.

The Sensor Stack in Detail

The choice of sensors reflects the specific demands of aerostat monitoring, where reliability matters more than cost minimization.

Dual BMP390 — Running two barometric sensors simultaneously, on different buses, is a redundancy strategy. The BMP390 is a high-accuracy pressure sensor capable of measuring altitude with better than 10 cm resolution. Having one on I2C and one on SPI means a bus fault on either interface does not take out the entire pressure measurement capability. For a system designed for 24/7 operation, this kind of hardware redundancy is the difference between a data gap and a complete measurement failure.

MPU9250 — A nine-axis IMU combining a 3-axis accelerometer, 3-axis gyroscope, and 3-axis magnetometer. On an aerostat, this provides attitude data — how the balloon platform is oriented and how it is moving — which is essential context for interpreting the environmental sensor readings. A wind speed reading means something different if the platform is tilting 20 degrees than if it is hanging level.

HX711 load cell — Tether tension measurement is unique to aerostat applications. The HX711 is a precision analog-to-digital converter designed specifically for load cells and strain gauges. Monitoring tether tension provides early warning of abnormal aerodynamic loading, useful for safety and for understanding balloon behavior in changing wind conditions.

Anemometer — Wind speed at altitude. Combined with the IMU's attitude data and the pressure sensors' altitude readings, this builds a picture of the atmospheric conditions at the balloon's operating altitude.

DS3231 RTC — A hardware real-time clock with a dedicated crystal oscillator and battery backup, ensuring accurate timestamps on every data record even across power interruptions. Software-based timekeeping on a microcontroller drifts; the DS3231 does not.

BNO055 and DHT22 (ESP32 side) — The BNO055 is a nine-axis sensor with an integrated sensor fusion processor, meaning it outputs calibrated orientation (quaternion or Euler angles) rather than raw gyroscope and accelerometer data. The DHT22 adds humidity to the atmospheric picture. Together they give the ground station a complete environmental and attitude picture in the final 17-field CSV.

The W5500 as the Ground Link

In most remote monitoring applications, wireless is the obvious choice for data transmission. Wi-Fi, LoRa, cellular — all of these work well for ground-level deployments where the transmitter and receiver are separated by air. On an aerostat, the physics are different.

The tether cable is a physical connection that already exists between the balloon and the ground. Running an optical fiber conductor through or alongside that tether turns it into a reliable, high-bandwidth, zero-latency, interference-immune data link. There is no RF propagation to worry about, no frequency allocation, no atmospheric fading, no competing signals from other equipment on the ground.

The WIZnet W5500 is what makes the ESP32 a full Ethernet participant at the balloon end of that fiber link. Over SPI, the W5500 provides the ESP32 with a complete hardwired TCP/IP stack — it handles ARP, IP, TCP, UDP, ICMP, and IGMP in hardware, without loading the ESP32's CPU with network stack processing. The ESP32 opens a TCP socket on port 5000 and streams the 17-field CSV records down the fiber to the ground station as fast as it produces them.

The ground station receives a clean, reliable TCP stream. It does not need to poll, it does not need to handle dropped packets at the application level, and it does not need to deal with the link-quality variations that plague wireless links in electrically noisy environments. The W5500 abstracts all of that into a standard Ethernet connection.

Reliability Engineering: RTOS Scheduling and the Watchdog

Two firmware choices stand out as particularly well-suited to 24/7 unattended operation.

RTOS-style cooperative scheduling on the Mega — Rather than a simple loop() that runs everything in sequence, the Mega's firmware implements a task-based cooperative scheduler where each sensor has a defined read interval and the scheduler runs the appropriate task when its time comes. This prevents slow sensors (the load cell's HX711 conversion takes time) from blocking fast ones (the IMU needs to be read frequently for useful attitude data), and it makes the timing of the output CSV stream predictable.

Hardware watchdog — A hardware watchdog timer resets the microcontroller if the firmware stops kicking it within a defined period. If the firmware crashes, hangs in a loop, or gets stuck waiting for a sensor that stops responding, the watchdog fires and the system reboots — automatically, without human intervention. For a balloon that may be up for a week, this is not optional. Software has bugs; the watchdog is the last line of defense against a firmware fault taking down the entire monitoring system.

Two Versions, One Trajectory

The repository contains two versions of the firmware, and the evolution between them tells a clear story about where the project is headed.

V1 runs everything on the Arduino Mega — sensors, IMU, SD logging, and all. It is a capable single-MCU design and proves out the sensor integration and scheduling approach.

V2 is the two-MCU split described in this article. It moves the IMU, humidity sensor, SD logging, and Ethernet transmission to the ESP32, leaving the Mega to focus on what it does best: managing a large number of diverse sensors on multiple buses. The result is a cleaner architecture with better separation of responsibilities and a more capable ground link.

The natural next step, visible in the architecture's design, is adding the OFC ground station receiver code and a more capable ground-side data processing system — but that is a future iteration.

Why This Design Matters

The Aerostat Mega Sensor Hub is a well-engineered piece of firmware that solves a genuinely difficult problem: keeping a diverse multi-sensor system running continuously and reliably on a platform subject to vibration, temperature extremes, and uncertain power conditions, while getting that data reliably to the ground.

The choice to use a tethered OFC cable rather than wireless for the ground link is particularly notable. It is not the default choice for an embedded developer — wired Ethernet requires more hardware — but it is the correct choice for this application. The W5500 makes it practical by giving the ESP32 a complete Ethernet implementation over a four-wire SPI connection, without requiring the ESP32 to sacrifice significant CPU headroom to network stack management.

The dual-MCU split, the redundant sensor configuration, the RTOS-style scheduler, and the hardware watchdog are all decisions that reflect the reality of deploying embedded systems in conditions where you cannot easily reach the hardware to fix problems. They are the difference between a prototype that works in the lab and a system you can actually trust in the sky.

Related Projects

Two projects from the WIZnet Maker community are worth exploring alongside this one. The Arduino Mega Compatible Secure Connectivity Development Platform by Lihan__ is an open hardware platform that pairs Arduino Mega-compatible form factor with WIZnet Ethernet for secure wired-network applications — a close cousin to the aerostat hub's Mega + W5500 combination, focused on the security and connectivity side rather than the sensor stack. The ESP32 Environmental Monitoring via WIZnet W5500 Ethernet, MQTT, and SQLite Logging project by josephsr covers the same ESP32 + W5500 + environmental sensor + local logging combination at the core of the aerostat hub's V2 ESP32 node, making it a useful reference for the data pipeline design.