Wiznet makers

What the Project Does

MIRAGE, short for Methane InfraRed Absorption Gas Experiment, is a BEXUS 39 balloon experiment from Uppsala University. The project aims to measure stratospheric methane concentration using an off-the-shelf NDIR gas sensor instead of a more expensive laser-based measurement setup. REXUS/BEXUS lists MIRAGE as a BX39 experiment with a planned October 2026 launch, and describes its goal as low-cost stratospheric methane measurement using an NDIR sensor.

The engineering problem is not simply “read a gas sensor.” At stratospheric altitude, air pressure drops so far that the absolute number of methane molecules inside a normal sensing volume becomes too small for reliable detection. The provided system document states that MIRAGE addresses this by compressing outside air and feeding it into a custom measurement chamber at around 3 bar, allowing a Senseair K96 NDIR sensor to measure CH₄, CO₂, and H₂O under controlled pressure and temperature conditions.

The payload is built as a compact autonomous experiment module for the BEXUS gondola. According to the provided design description, the experiment is approximately 200 × 200 × 150 mm, weighs about 3 kg, is powered from the BEXUS 28.8 V battery line, and has an average power consumption of 13.13 W with a peak of 66.20 W. Its flight profile includes ascent, float, descent, and post-landing phases, with different control behavior in each phase.

MIRAGE has three major embedded control domains. The Main MCU, an ESP32-C5, collects science and housekeeping data, stores it to microSD, sends telemetry to the ground, and supervises the other controllers. The Pressure MCU, an Arduino Nano ESP32-S3, controls vacuum pumps, a compressor, pressure sensors, and a solenoid valve to maintain the chamber pressure. The Thermal MCU, also ESP32-S3 based, controls heater films, a Peltier element, and temperature monitoring to prevent condensation, freezing, and sensor drift.

The data path is mission-oriented. The K96 NDIR sensor generates CH₄, CO₂, and H₂O data over UART/Modbus. SHT45 sensors provide temperature and humidity measurements. MS5607 and ABP2 sensors provide pressure data. The ESP32-C5 validates and timestamps this data, writes it to local storage, and sends selected telemetry packets to the ground station through the BEXUS E-Link path using the WIZ850io Ethernet module.

System Block Diagram

Created By Gemini

Where WIZnet Fits

The WIZnet device in this project is WIZ850io, a compact Ethernet module based on the W5500 chip. In the MIRAGE architecture, it connects to the ESP32-C5 Main MCU over SPI and provides the wired Ethernet interface to the BEXUS E-Link system. The provided design document describes WIZ850io as the hardware TCP/IP stack module used to send UDP packets from the payload to the ground station.

Its role is specific: real-time telemetry transport. MIRAGE already logs data to a 16 GB microSD card, but local storage alone is not enough during a balloon flight. The team needs live visibility into chamber pressure, temperature, humidity, methane measurement status, and subsystem health. WIZ850io provides the wired Ethernet path that carries this reduced but mission-critical telemetry stream to a Python ground-station GUI.

W5500 is a good match because the telemetry load is modest but operationally important. The document specifies an average downlink rate of about 32.8 kbps, with a maximum of 100 kbps, and an uplink rate up to 10 kbps for ground commands. This is not a high-throughput networking problem. It is a reliability and integration problem: the MCU must keep reading sensors, controlling pressure, controlling temperature, writing to SD, and feeding the watchdog while still sending telemetry.

The BEXUS environment also favors wired Ethernet over Wi-Fi. A stratospheric balloon payload cannot assume normal Wi-Fi infrastructure, and the gondola already provides an E-Link interface for experiment communication. In this context, WIZ850io gives the ESP32-C5 a direct SPI-to-Ethernet path that can be integrated into the experiment electronics without adding a large networking subsystem. The REXUS/BEXUS programme itself is built around student-designed experiments launched on rockets and balloons under special atmospheric conditions, with BEXUS providing balloon flight opportunities rather than ordinary terrestrial networking environments.

Implementation Notes

No firmware repository or source code was provided for MIRAGE, so the following code is not claimed to be from the project. It is a conceptual integration example based on WIZnet ioLibrary that shows the core pattern MIRAGE would need: initialize W5500, open a UDP socket, and send compact telemetry frames to the ground station.

Conceptual integration example based on WIZnet ioLibrary

#include "wizchip_conf.h"
#include "socket.h"

#define UDP_SOCKET      0
#define LOCAL_PORT      5000
#define GROUND_PORT     6000

uint8_t ground_ip[4] = {192, 168, 1, 20};

typedef struct {
    uint32_t timestamp_ms;
    float ch4_ppm;
    float chamber_pressure_bar;
    float chamber_temp_c;
    float humidity_rh;
    uint8_t mode;
    uint8_t fault_flags;
} mirage_packet_t;

void ethernet_start(void) {
    uint8_t tx_size[8] = {2,2,2,2,2,2,2,2};
    uint8_t rx_size[8] = {2,2,2,2,2,2,2,2};

    wizchip_init(tx_size, rx_size);

    wiz_NetInfo netinfo = {
        .mac  = {0x00, 0x08, 0xDC, 0x39, 0x00, 0x01},
        .ip   = {192, 168, 1, 39},
        .sn   = {255, 255, 255, 0},
        .gw   = {192, 168, 1, 1},
        .dhcp = NETINFO_STATIC
    };

    wizchip_setnetinfo(&netinfo);
    socket(UDP_SOCKET, Sn_MR_UDP, LOCAL_PORT, 0);
}

void send_telemetry(const mirage_packet_t *packet) {
    sendto(
        UDP_SOCKET,
        (uint8_t *)packet,
        sizeof(mirage_packet_t),
        ground_ip,
        GROUND_PORT
    );
}

What this code explains

The first key idea is explicit network setup. Balloon experiments are normally integrated into a predefined communication environment, so the payload should not depend on ad-hoc discovery. A static IP configuration is often simpler for a fixed E-Link setup, although DHCP could also be used if the BEXUS network configuration requires it.

The second key idea is one UDP socket for repeated telemetry frames. MIRAGE does not need to establish a long-lived TCP session for every packet. UDP is appropriate for frequent status frames because it has low overhead and does not block the control loop waiting for retransmission. This fits the design document’s telemetry model, where the payload sends a continuous stream to the ground GUI while also preserving the full dataset on SD card.

The third key idea is small binary packets with timestamps and fault flags. A science balloon payload should make each packet independently useful. If the ground station misses a packet, the next packet should still contain enough timing, mode, and health information to interpret the state of the experiment. For MIRAGE, fields such as CH₄ value, chamber pressure, chamber temperature, humidity, mode, and fault status are more important than verbose text strings.

The fourth key idea is separation between telemetry and control. The Main MCU should not let Ethernet transmission block sensor polling, pressure control, thermal control, or watchdog servicing. The provided design already describes separate queues for SD logging and E-Link transmission, which is the right pattern for this type of system.

Mission Software Flow

MIRAGE is not a simple single-loop sensor logger. It operates as an autonomous flight payload with multiple modes.

Boot / Initialization
        │
        ▼
Autonomous Mode
        │
        ├── Standby
        │     - read housekeeping sensors
        │     - log to SD
        │     - send heartbeat telemetry
        │     - wait for pressure / altitude condition
        │
        ├── Measurement
        │     - read K96 NDIR data
        │     - control chamber pressure target
        │     - control chamber temperature target
        │     - log science data
        │     - send UDP telemetry via WIZ850io
        │
        ├── Humidity Loop
        │     - close valve
        │     - restrict pumping
        │     - heat internal volume
        │     - wait for safe humidity state
        │
        └── Connection-Lost Behavior
              - continue autonomous decisions
              - keep logging locally
              - restore telemetry when link returns

In standby mode, the system reads sensors, timestamps data, writes to storage, sends a telemetry heartbeat, and checks whether atmospheric conditions justify entering measurement mode. In measurement mode, the K96 sensor data is collected, pressure and temperature targets are sent to the sub-MCUs, telemetry packets are queued for WIZ850io transmission, and abnormal pressure conditions can trigger valve closure or pump shutdown.

The most important software design choice is that telemetry is not the only data path. The SD card remains the primary full-resolution record, while WIZ850io provides real-time downlink for situational awareness. That matters because balloon communication can be intermittent, and a lost packet should not mean lost science data.

Flight Timeline and W5500 Telemetry Role

Before launch, the chamber is pre-pressurized, the SD card is initialized, and the communication path should be verified with the ground station. During ascent, the pump chain and compressor work to feed the chamber, the K96 sensor records methane-related data, thermal control remains active, and telemetry is sent over E-Link through WIZ850io.

At float altitude, the design document indicates that the pumps may be turned off and the system can remain in standby while maintaining electronics temperature. During descent, the experiment prioritizes survival, storage integrity, and post-landing protection. After landing, the normally closed valve helps protect the chamber from water ingress.

Across all phases, WIZ850io is most valuable when something changes: pressure instability, humidity protection entry, thermal saturation, SD-card heating, watchdog reset, or mode transition. These events do not require large bandwidth, but they do require timely reporting. That is the operational reason to use a wired UDP telemetry path rather than only retrieving the SD card after recovery.

Practical Tips / Pitfalls

• Keep SD logging independent from UDP telemetry. UDP packets can be lost, but the science dataset should remain complete on local storage.
• Design telemetry packets for partial loss. Include timestamps, mode ID, sequence number, and fault flags so the ground GUI can detect gaps and interpret state changes.
• Avoid blocking Ethernet calls in the control loop. Pressure control, thermal control, and watchdog servicing should continue even if E-Link is temporarily unavailable.
• Validate WIZ850io and SD-card sharing on the SPI bus. Separate chip-select lines are not enough; firmware must also prevent transaction collisions.
• Test the exact E-Link IP plan before flight. The provided design notes that one IP address is assigned to the experiment and one to the ground station, so address, subnet, gateway, and UDP port assumptions should be frozen before launch.
• Add a telemetry recovery message after reset. If the TPS3813 watchdog resets the Main MCU, the ground station should receive a boot counter or reset reason in the next UDP frames.
• Keep the binary packet small. The documented average telemetry rate is about 32.8 kbps, so the useful design target is not maximum throughput but predictable periodic reporting.

FAQ

Q: Why use WIZ850io(W5500) in MIRAGE?
A: MIRAGE needs a wired Ethernet interface to send flight telemetry through the BEXUS E-Link system. WIZ850io gives the ESP32-C5 an SPI-connected W5500 Ethernet controller, allowing the payload to send UDP telemetry while continuing sensor acquisition, pressure control, thermal control, SD logging, and watchdog servicing.

Q: How does WIZ850io connect to the ESP32-C5 platform?
A: The provided design describes WIZ850io as an SPI device connected to the Main MCU board. The same Main MCU also uses SPI for microSD, so the hardware design must allocate separate chip-select lines and the firmware must serialize access to the shared SPI bus.

Q: What role does W5500 play in this project?
A: W5500 is the Ethernet interface for the real-time telemetry path. It does not measure methane and it does not control the chamber; instead, it transports selected science and housekeeping data from the ESP32-C5 to the ground station over UDP through E-Link.

Q: Can beginners follow this design?
A: A basic ESP32-to-W5500 UDP sender is beginner-friendly, but MIRAGE as a complete system is advanced. The full payload combines high-altitude environmental constraints, pressure regulation, thermal control, Modbus gas sensing, I²C sensor multiplexing, SD logging, hardware watchdog recovery, and Ethernet telemetry.

Q: Why use W5500 Ethernet instead of Wi-Fi?
A: Wi-Fi is not the right assumption for a stratospheric balloon payload integrated with a gondola communication system. MIRAGE needs to interface with BEXUS E-Link, so wired Ethernet is the natural transport path. W5500 provides that path through a compact SPI module while keeping the MCU-side integration manageable.

Source

• Original project: MIRAGE, Methane InfraRed Absorption Gas Experiment, BEXUS 39.
• Programme reference: REXUS/BEXUS lists BX39 MIRAGE from Uppsala Universitet, Sweden, with the goal of measuring stratospheric methane using an off-the-shelf NDIR sensor. 
• Programme context: DLR describes REXUS/BEXUS as a student programme for experiments on rockets and balloons under special atmospheric conditions. 
• Provided design source: MIRAGE BX39 UCC curation description based on System Engineering Document v2.0, April 2026.
• License: Not specified in the provided material.

Tags

#WIZ850io #W5500 #WIZnet #ESP32C5 #BEXUS39 #MIRAGE #MethaneSensor #NDIR #UDP #Ethernet #Telemetry #Stratosphere