Phoenix Ground Station: W5500 MACRAW Ethernet for Rocket Ground-Control Firmware

URL Links

• GitHub Repository
  https://github.com/rocketproplab/phoenix-gs
• Rocket Propulsion Laboratory
  https://www.rocketproplab.org/
• Phoenix Project
  https://www.rocketproplab.org/phoenix
• Related Phoenix Flight Computer Content
  https://maker.wiznet.io/matthew/projects/phoenix%2Dflight%2Dcomputer/
• Related CMS Avionics Content
  https://maker.wiznet.io/Aimee0/projects/cms%2D%2Drocket%2Ddeveloped%2Dby%2Dthe%2Dpurdue%2Dspace%2Dprogram%2Dliquids%2Dteam/

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

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)

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)

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

Launch Mode

Launch Mode manages four principal states.

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

┌────────────────────────────────────────┐
│ 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

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

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

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:

7 pressure-related values
3 load-cell values
2 temperature-related values

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

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:

Application state or telemetry
→ Custom Layer-2 Ethernet frame
→ W5500 Socket 0 in MACRAW mode
→ Local wired Ethernet segment

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

Phoenix GS uses two principal frame types.

Command Frame

Destination MAC — 6 bytes
Source MAC      — 6 bytes
EtherType       — 0x63e4
Control state   — 1 byte

Telemetry Frame

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)

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)

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)

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
https://maker.wiznet.io/matthew/projects/phoenix%2Dflight%2Dcomputer/

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.

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
https://maker.wiznet.io/Aimee0/projects/cms%2D%2Drocket%2Ddeveloped%2Dby%2Dthe%2Dpurdue%2Dspace%2Dprogram%2Dliquids%2Dteam/

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)

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.