--- title: "phoenix-gs (Phoenix Ground Station)" url: "https://maker.wiznet.io/matthew/projects/phoenix-gs-phoenix-ground-station/" markdown_url: "https://maker.wiznet.io/matthew/projects/phoenix-gs-phoenix-ground-station/md" type: "UCC: User Created Content" author: "Rocket Propulsion Laboratory" author_url: "https://github.com/rocketproplab/phoenix-gs" editor: "WIZnet" editor_url: "https://maker.wiznet.io/" original_author: "Rocket Propulsion Laboratory" original_url: "https://github.com/rocketproplab/phoenix-gs" published: "2026-07-13" language: "en" likes: 0 views: 159 comments: 0 source: "WIZnet Makers (https://maker.wiznet.io/)" --- # phoenix-gs (Phoenix Ground Station) > UC San Diego RPL’s Phoenix Ground Station uses W5500 MACRAW Ethernet to send valve-state commands and receive sensor telemetry. Original author: Rocket Propulsion Laboratory (source: https://github.com/rocketproplab/phoenix-gs) ## Article ### Phoenix Ground Station: W5500 MACRAW Ethernet for Rocket Ground-Control Firmware ### URL Links - **GitHub Repository** - **Rocket Propulsion Laboratory** - **Phoenix Project** - **Related Phoenix Flight Computer Content** - **Related CMS Avionics Content** > **Source Snapshot** > > **Original source: rocketproplab/phoenix-gs** > **Branch: main** > **Reviewed commit: a9ec62e49f388bd8b2865d01feb0c60a95867d09** > **Review date: July 13, 2026** > **Main files reviewed:** > **- README.md** > **- gs/gs.ino** > **- gs/w5500.h** > **- gs/w5500.cpp** > **- gs/constants.h** --- ### PROJECT AT A GLANCE | Item | Description | | --- | --- | | Project type | Open-source Arduino ground-station firmware | | Developer / Organization | Rocket Propulsion Laboratory at UC San Diego | | Target project | Phoenix dual-cryogenic liquid rocket | | WIZnet device | WIZnet W5500 chip | | Hardware form | Third-party W5500-based Ethernet module | | Ground-station MCU | Arduino-compatible controller; exact model not published | | Host interface | SPI | | Network mode | W5500 Socket 0, MACRAW | | Command protocol | Custom Layer-2 frame, EtherType `0x63e4` | | Telemetry protocol | Custom Layer-2 frame, EtherType `0x8889`, CSV payload | | W5500 implementation status | Confirmed in the public source code | | Static-fire deployment status | Not established by current public evidence | | Project status | Publicly presented as an active development program | The repository describes Phoenix GS as an Arduino-based ground station and lists a W5500 Ethernet module in its physical specifications. The firmware initializes the device and directly uses it for MACRAW frame transmission and reception. --- ## COMPONENTS ### Hardware Components - W5500-based Ethernet module using the WIZnet W5500 chip - Arduino-compatible ground-station controller - Arm switch - Abort and Launch buttons - Launch, Fueling, and Dev mode selectors - Pressure-, flow-, and vent-related control switches - 20×4 I2C LCD - SPI interface - Wired Ethernet connection - Remote relief-valve controller - Remote sensor interface or Phoenix flight computer The repository states that the ground station is Arduino-based but does not identify its exact board model. Although the companion Phoenix Flight Computer repository specifies an Arduino Mega 2560 for the flight-computer side, that specification should not automatically be applied to Phoenix GS. The ground-station pin mapping, SPI pins, and chip-select configuration should be checked before reproduction. --- ## PROJECT DESCRIPTION ### Overview Phoenix Ground Station, or Phoenix GS, is Arduino-based ground-control firmware published by the Rocket Propulsion Laboratory, a student-led rocket organization at the University of California, San Diego. RPL was founded in the spring of 2017 by Cameron Flannery, Michael Phalen, and Alex Lim. The organization aims to provide students with opportunities to participate in real rocket design, manufacturing, testing, and documentation while developing technical knowledge, leadership skills, and hands-on engineering experience. ([Rocket Propulsion Laboratory](https://www.rocketproplab.org/about-us)) Phoenix is RPL’s dual-cryogenic liquid rocket project using liquid methane and liquid oxygen. According to the official Phoenix page, the Avionics subteam is responsible for the flight computer, ground station, communication between the two, data acquisition, valve actuation, and recovery-deployment electronics. ([Rocket Propulsion Laboratory](https://www.rocketproplab.org/phoenix)) Within this architecture, Phoenix GS performs two main functions: 1. It converts physical operator switch and button inputs into a valve and control state. 2. It transmits that state to remote controllers and receives sensor telemetry. Phoenix GS is therefore more than a basic Ethernet-module test. It is the **ground-side network endpoint connecting the operator control panel to remote valve and sensor electronics**. --- ### How Phoenix Ground Station Works When an operator uses the Arm, Abort, Launch, or valve-related controls, the firmware reads the inputs and applies debounce processing. The current code uses 30 ms debounce intervals for buttons and switches. It then uses the selected Launch, Fueling, or Dev mode logic to encode seven valve-related states into one byte. That state is inserted into the payload of a custom Ethernet frame and transmitted through the W5500. The current source sends command frames to two destinations: a relief-valve controller and the sensor or flight-computer node identified as `MAC_SENSOR_GIGA`. In the reverse direction, Phoenix GS receives telemetry frames sent by `MAC_SENSOR_GIGA`. The firmware checks the sender MAC and EtherType, separates the CSV payload into pressure, load-cell, and temperature values, and outputs the result through the serial interface in a JSON-like format. The LCD serves as a local operating-status display for the current mode, launch state, and individual valve-related states rather than as a complete telemetry dashboard. --- ### Operating Modes![](https://maker.wiznet.io/upload/ckeditor5/410146339%5F1783917564%2Epng) #### Launch Mode Launch Mode manages four principal states. | State | Firmware behavior | | --- | --- | | `PRE_ARM` | Default state with all encoded valve bits cleared | | `ARMED` | Enables the LNG and LOX pressure-related bits | | `LAUNCH` | Enables pressure- and flow-related bits | | `ABORT` | Enables vent-related bits and remains latched until reset | In the current implementation, an Abort transition can occur from `PRE_ARM`, `ARMED`, or `LAUNCH`. Once the system enters `ABORT`, the state remains latched until the system is reset. #### Fueling Mode Fueling Mode allows the operator to change the GN2, LNG, and LOX vent-related states. The LNG and LOX pressure- and flow-related bits are forced into the closed state by the firmware. #### Dev Mode Dev Mode allows all seven valve-related states to be changed individually. The README describes it as a high-risk development mode intended for testing valve openings before fueling. This state machine represents software logic contained in the repository. It does not constitute an independently validated launch-safety procedure, hardware interlock, or functional-safety certification. --- ### System Architecture![](https://maker.wiznet.io/upload/ckeditor5/410146339%5F1783917357%2Epng) ```plaintext ┌────────────────────────────────────────┐ │ Phoenix Ground-Control Panel │ │ │ │ Arm / Abort / Launch │ │ Mode and valve-related switches │ └───────────────────┬────────────────────┘ │ GPIO ▼ ┌────────────────────────────────────────┐ │ Arduino Ground-Station Firmware │ │ │ │ - Input debounce │ │ - Mode selection │ │ - State-machine logic │ │ - One-byte control-state encoding │ │ - Telemetry parsing │ └──────────────┬─────────────────┬───────┘ │ I2C │ SPI ▼ ▼ ┌─────────────────────┐ ┌─────────────────────────┐ │ 20×4 LCD │ │ WIZnet W5500 │ │ Mode / state display│ │ Socket 0: MACRAW │ └─────────────────────┘ └────────────┬────────────┘ │ Wired Ethernet ┌────────────────────┴────────────────────┐ │ │ ▼ ▼ ┌────────────────────────────┐ ┌──────────────────────────────┐ │ Relief-valve controller │ │ Sensor / flight computer │ │ Receives state command │ │ Receives command │ └────────────────────────────┘ │ Produces telemetry │ └──────────────┬───────────────┘ │ └── Telemetry to GS ``` Phoenix GS is better described as an operator-side command source and telemetry receiver than as an actuator driver that directly applies voltage to the final valves. Actual valve-state application is performed by a remote controller or the companion flight computer. The companion repository likewise identifies command reception, valve actuation, sensor sampling, and telemetry return as its main functions. --- ### Control Data Flow ```plaintext Operator switch or button → digitalRead() → Debounce processing → Operating-mode selection → Mode-specific state logic → One-byte valve/control state → Custom Ethernet frame → W5500 sendFrame() → Remote controllers ``` ![](https://maker.wiznet.io/upload/ckeditor5/410146339%5F1783917591%2Epng)The current main firmware calls `sendRocketState()` when at least 200 ms has elapsed since the previous transmission. A source-code comment says that the main loop runs every 50 ms, but the code does not contain a fixed delay that guarantees a 50 ms loop period. The most accurate description is therefore that **command frames are scheduled at approximately 200 ms intervals**. --- ### Telemetry Data Flow ```plaintext Pressure / load-cell / temperature sensors → Remote sensor or flight computer → ASCII CSV payload → Custom Ethernet telemetry frame → W5500 → Phoenix Ground Station → Sender and EtherType validation → CSV parsing → Serial JSON output ``` The ground-station parser currently expects 12 values: ```plaintext 7 pressure-related values 3 load-cell values 2 temperature-related values ``` ![](https://maker.wiznet.io/upload/ckeditor5/410146339%5F1783917632%2Epng)The parsed data is converted into structured serial output containing `pt`, `tc`, and `lc` arrays together with a firmware-generated timestamp. --- ### Role and Application of the WIZnet W5500 #### WIZnet Device **WIZnet W5500 chip** #### Hardware Form The README links to a third-party Ethernet module built around the WIZnet W5500 chip, not to a WIZnet-manufactured evaluation board. #### Role of the W5500 The W5500 serves as the SPI Ethernet interface between the Arduino-compatible ground-station controller and the local wired Ethernet network. It is used for: - Local MAC-address configuration - Socket 0 MACRAW operation - Custom Ethernet command-frame transmission - Custom telemetry-frame reception - Communication with relief-valve and sensor or flight-computer nodes - Frame transfer through the W5500’s internal TX and RX memory The firmware includes `w5500.h`, creates a `Wiznet5500` instance, and initializes it with the ground-station MAC address. It calls `sendFrame()` for command transmission and `readFrame()` for telemetry reception. The bundled driver allocates RX and TX memory to Socket 0 and opens that socket in MACRAW mode. #### Evidence of W5500 Use | Evidence | Status | | --- | --- | | W5500 module listed in the README | Confirmed | | W5500 driver included | Confirmed | | `Wiznet5500` object instantiated | Confirmed | | Device initialized with `begin()` | Confirmed | | `sendFrame()` used for commands | Confirmed | | `readFrame()` used for telemetry | Confirmed | | Socket 0 opened in MACRAW mode | Confirmed | | W5500 identified in the official ground-station photo | Not confirmed | | Current firmware used during the static-fire attempt | Not confirmed | | W5500 communication validated during the static fire | Not confirmed | > **The public source confirms that the W5500 is the implemented network interface for the Phoenix GS command and telemetry path. However, current public evidence does not establish field validation of this implementation during Phoenix’s static-fire attempt.** --- ### Network Stack Note Phoenix GS does not use the W5500 as a conventional TCP client, TCP server, UDP endpoint, HTTP device, or Internet-connected node. Its principal communication path is: ```plaintext Application state or telemetry → Custom Layer-2 Ethernet frame → W5500 Socket 0 in MACRAW mode → Local wired Ethernet segment ``` ![](https://maker.wiznet.io/upload/ckeditor5/410146339%5F1783917683%2Epng)Although the W5500 provides hardware TCP/IP functionality, the Phoenix GS command and telemetry path uses MACRAW mode instead of TCP or UDP sockets. The application directly constructs and interprets destination MAC addresses, source MAC addresses, EtherTypes, and payloads. Accordingly, Phoenix GS is best described as a custom Layer-2 command-and-telemetry application using a SPI-connected W5500 in MACRAW mode. --- ### Custom Ethernet Protocol![](https://maker.wiznet.io/upload/ckeditor5/410146339%5F1783917653%2Epng) Phoenix GS uses two principal frame types. | Direction | EtherType | Payload | | --- | --- | --- | | Ground Station → Remote controllers | `0x63e4` | One-byte valve/control state | | Sensor/flight computer → Ground Station | `0x8889` | ASCII CSV telemetry | #### Command Frame ```plaintext Destination MAC — 6 bytes Source MAC — 6 bytes EtherType — 0x63e4 Control state — 1 byte ``` #### Telemetry Frame ```plaintext Destination MAC — 6 bytes Source MAC — 6 bytes EtherType — 0x8889 Telemetry — ASCII CSV payload ``` The companion Phoenix Flight Computer repository documents the same operational values: `0x63e4` for command frames and `0x8889` for telemetry frames. This architecture allows devices on the same Ethernet segment to communicate without IP addresses. The following capabilities would still need to be implemented separately at the application level: - Command acknowledgment - Guaranteed delivery - Packet-sequence validation - Automatic retry - Authentication and authorization - Communication timeout - Stale-command protection - Communication-loss safe state --- ### Public Project Evidence RPL publicly shares its student rocketry activities through its official website, GitHub, Instagram, Facebook, and LinkedIn. The official website includes an Instagram feed and links to the organization’s Instagram, Facebook, and LinkedIn channels. ([Rocket Propulsion Laboratory](https://www.rocketproplab.org/)) #### Official Website The official Phoenix page states that the Avionics subteam is responsible for the flight computer, ground station, and communication between them. The same page publishes a real hardware image captioned `Avionics Ground Station for Static Fire`. This confirms that RPL presents the Phoenix Ground Station as a physical project system, not only as a software repository. ([Rocket Propulsion Laboratory](https://www.rocketproplab.org/phoenix)) The official page does not identify the Ethernet module, confirm the presence of a W5500, or name the firmware revision used by the photographed system. #### GitHub The official `rocketproplab` GitHub organization features `phoenix-gs` alongside `phoenix-flight-computer` and `rpl-blast`, supporting its status as an official Phoenix Avionics repository. #### Phoenix Static-Fire Result RPL published the result of Phoenix’s first static-fire attempt through its official LinkedIn page. According to the post, the test was conducted on February 14 at the Friends of Amateur Rocketry facility. During the ignition sequence, a leak through the LOX main valve caused an unexpected combustion event, dislodging the solenoid stem and venting LOX through the exposed line. RPL did not describe the test as a complete success. Instead, the organization stated that the team collected data, identified root causes, and defined improvements and next steps for the following attempt. ([LinkedIn](https://www.linkedin.com/company/rocket-propulsion-laboratory)) The available post and official Phoenix page do not establish: - Whether the current `phoenix-gs` firmware was used during the static fire - Whether the photographed ground station contained the linked W5500 module - Whether W5500 communication operated correctly during the test - Whether command and telemetry frames were delivered without errors - How much Phoenix GS contributed to the collected test data The test can therefore be used as evidence that Phoenix is an active development and testing program. It should not be presented as field validation of the W5500 Ground Station. --- ### Project Status and Technical Limitations The repository provides a substantial firmware implementation, but public materials do not establish production readiness or safety certification. #### 1. Unspecified Ground-Station Board The repository states that the system is Arduino-based but does not identify the exact ground-station board. Pin mapping and SPI compatibility must be verified against the intended hardware. #### 2. Unchecked W5500 Initialization Result The bundled driver’s `begin()` function returns a Boolean success result. The current `setup()` does not check that result before printing `Ethernet Start Success`. A field implementation should separately handle initialization failure and PHY link state. #### 3. TX Error-Check Type Issue `sendFrame()` is declared to return `uint16_t` but returns `-1` on failure. Phoenix GS compares the result with `< 0`; because the value is unsigned, this check may not detect the intended error condition. #### 4. Telemetry EtherType Comment Mismatch One telemetry comment still refers to `0x8886`, while the executable filter and companion repository use `0x8889`. The operational EtherType should be documented as `0x8889`. #### 5. Telemetry Field-Count Mismatch The Phoenix GS parser handles seven pressure values, three load-cell values, and two temperature values, for a total of 12 fields. The current companion flight-computer source constructs seven pressure values, three load-cell values, and five thermocouple values. The sender and receiver schemas should therefore be synchronized so that the additional thermocouple fields are not omitted from the ground-station output model. #### 6. Safety and Fault Handling The reviewed public materials do not fully document: - End-to-end command acknowledgment - Communication-loss safe state - Hardware emergency stop - Independent hardware interlock - Watchdog and stale-command timeout - Redundant communication path - Fault-injection results - Formal safety validation - Network-performance logs from a static fire These limitations do not remove the project’s educational or technical value. They mean that Phoenix GS should be presented as an **active student-engineering firmware reference**, not as a validated commercial launch-control product. --- ### WIZnet Strategic Relevance The most important WIZnet aspect of Phoenix GS is its use of **Layer-2 MACRAW communication**, which differs from conventional TCP, UDP, MQTT, or HTTP projects. The project demonstrates that an Arduino-class controller can use the W5500 to directly manage: - Source and destination MAC addresses - Custom EtherTypes - Compact command payloads - Local non-IP communication - Application-defined telemetry formats - Integration between an embedded state machine and Ethernet interface > **Its value lies in demonstrating the W5500 as a custom Layer-2 command-and-telemetry interface between an Arduino-based operator console and remote control electronics—not in claiming aerospace certification or proven field reliability.** --- ### Related Existing WIZnet Maker Content #### 1. Phoenix Flight Computer **URL** ##### Similarity Both projects belong to the Phoenix network and use W5500 MACRAW communication. ##### Difference The Phoenix Flight Computer receives ground-station commands, applies valve targets, samples sensors, and generates telemetry. Phoenix GS converts physical operator input into commands and receives telemetry for LCD or serial output. The companion repository explicitly documents this bidirectional relationship. ```plaintext Operator → Phoenix Ground Station → 0x63e4 W5500 MACRAW command → Phoenix sensor / flight computer → 0x8889 W5500 MACRAW telemetry → Phoenix Ground Station ``` ##### Connection Value Publishing both endpoints allows Maker Site readers to understand the complete protocol flow and how the W5500 is used by both the command-sending and command-receiving sides of the network. --- #### 2. CMS Avionics — Purdue Space Program Liquids **URL** ##### Similarity Both projects apply W5500 Ethernet to avionics or ground-support systems developed by university student rocket organizations. ##### Difference CMS Avionics is a distributed network connecting multiple RP2040-based flight computers through an Ethernet switch. It uses UDP for SensorNet and TCP for CommandNet. Phoenix GS focuses on an operator-side control console communicating with remote controllers through custom Layer-2 frames using W5500 Socket 0 in MACRAW mode. ([WIZnet Makers](https://maker.wiznet.io/Aimee0/projects/cms--rocket-developed-by-the-purdue-space-program-liquids-team/)) | CMS Avionics | Phoenix GS | | --- | --- | | Distributed multi-board network | Ground-console and remote-controller network | | Ethernet-switch backbone | Local raw-Ethernet segment | | UDP SensorNet | Custom telemetry EtherType | | TCP CommandNet | One-byte command frame | | Hardware TCP/IP sockets | Socket 0 MACRAW | | RP2040-based nodes | Arduino-compatible controller | ##### Connection Value CMS demonstrates the W5500 as an IP-based distributed avionics interface, while Phoenix GS demonstrates it as a programmable Layer-2 frame interface. --- ### Summary Phoenix Ground Station is Arduino-based ground-control firmware published by UC San Diego’s Rocket Propulsion Laboratory for the Phoenix liquid-rocket project. The firmware reads physical operator inputs, applies Launch, Fueling, or Dev mode logic, and encodes valve-related states into one byte. It transmits that state to relief-valve and sensor or flight-computer controllers through the WIZnet W5500 in MACRAW mode. In the reverse direction, it receives custom telemetry frames, parses CSV sensor data, and outputs structured information through the serial interface. W5500 use is confirmed directly in the public source code rather than only in the README. The device is initialized, placed into Socket 0 MACRAW mode, and used for command and telemetry frame transfer. RPL has published an official photograph of an Avionics Ground Station for static fire and has reported the result of Phoenix’s first static-fire attempt through LinkedIn. Current public evidence, however, does not establish whether the photographed system contained the linked W5500 module, whether the current GitHub firmware was used during the test, or whether W5500 communication operated correctly. > **Phoenix Ground Station is a student-engineering reference for W5500-based custom Layer-2 command and telemetry communication in a rocket ground-control system.** --- ### FAQ #### Q. Is the WIZnet W5500 actually used? Yes. The application includes the W5500 driver, initializes a W5500 object, and calls `sendFrame()` and `readFrame()` in the operational command and telemetry paths. #### Q. Does it use TCP or UDP? Not in the principal communication path. The firmware opens W5500 Socket 0 in MACRAW mode and exchanges custom Layer-2 frames identified by custom EtherTypes. #### Q. Was the W5500 validated during a static fire? RPL has published a static-fire ground-station photo and the result of a Phoenix static-fire attempt. Public sources do not establish whether the current firmware or W5500 implementation was used or whether communication operated correctly during that test. #### Q. Is it a safety-certified system? No formal safety certification, complete hardware-interlock documentation, redundant network design, or communication-loss safe-state validation has been identified in the public materials. --- Source: https://maker.wiznet.io/matthew/projects/phoenix-gs-phoenix-ground-station/