F-Prime Flight Software for Artemis CubeSat

This repository is the clearest example of the software engineering work I have been doing at the Hawaii Space Flight Laboratory. I led a refactor from proven but tightly coupled bare-metal Artemis CubeSat software into a shared NASA F Prime (F’) architecture that can support two different mission profiles:

• EPSCoR C3M, which captures and downlinks FLIR Lepton thermal imagery.
• Neutron-2, a DoD AFRL University Nanosatellite Program mission demonstrating command, health telemetry, scheduled science collection, and neutron-data downlink.

The problem was not simply “put F Prime on a Raspberry Pi.” The original Artemis software proved the hardware could work, but mission logic, subsystem behavior, protocols, and drivers were coupled together. Changing a payload or radio meant invasive rewrites. I redesigned that boundary so the common spacecraft software remains stable while mission-specific hardware can change independently.

One architecture, two missions

F Prime models flight software as components connected by typed ports. I used its Application-Manager-Driver pattern to separate responsibilities:

1. Applications own mission and mode behavior: base mode, scheduled collection, health reporting, and science downlink.
2. Managers define stable subsystem contracts for payload, EPS, storage, communications, GPS, and related telemetry.
3. Drivers contain the hardware and protocol glue. Neutron-2 can use a simulated neutron payload while C3M uses a real Lepton driver, without forking the mission/application stack.

Both mission variants reuse the mission applications, subsystem managers, storage/downlink handoff, UART channel map, and radio bridge. The payload driver and ground decoder are the mission-owned edges. That is the important result of the refactor: new hardware becomes a driver and topology change rather than a rewrite of the mission.

The branch architecture documents go deeper than a normal portfolio description:

• EPSCoR C3M system architecture
• Neutron-2 system architecture

Engineering around real hardware constraints

The Artemis OBC gives the Raspberry Pi one practical UART to the satellite Teensy, so I helped turn it into three logical channels with a framed UartChannelMux:

• Channel 0: byte-pure CCSDS command, event, and telemetry traffic for fprime-gds.
• Channel 1: payload/science products using a custom packetized sidecar with indexes, retries, and CRC validation.
• Channel 2: satellite-local RPC for hardware such as the EPS/PDU; it never crosses the RF link.

That mux feeds a Teensy-to-Teensy RFM23BP link with a useful RF payload of roughly 44 bytes. Normal F Prime transfer frames were too large and fragile for that lossy, half-duplex radio, so the implementation uses smaller project-local CCSDS frames, restrained telemetry, RF segmentation/reassembly, retry policies, and a separate science-data path. Transport constants are generated from one configuration source and checked for drift across the Pi, satellite Teensy, and ground Teensy codebases.

This work crossed several layers at once: C++ F Prime components and FPP topology, C/C++ Teensy bridge firmware, Python ground tools and payload viewers, ARMv6 cross-compilation for the Raspberry Pi Zero W, systemd deployment, component unit tests, local closed-loop emulation, hardware-in-the-loop runbooks, and release artifacts with checksums.

What was actually demonstrated

The Neutron-2 MVP demonstrated the complete chain: laptop GDS command → ground Teensy → RFM23BP RF → satellite Teensy → Raspberry Pi F Prime deployment, followed by scheduled collection, science-data transfer on channel 1, CRC-verified reconstruction, and ground-side viewing. The project froze this known-good state as a reproducible demo release rather than calling it flight-ready.

The C3M variant reused that architecture with a real Lepton camera driver and Data Product path. Its frozen demo release records three consecutive live HIL runs, a Pi Zero W ARMv6/libuvc deployment, and an operator-facing web receiver showing progress, CRC proof, thermal decoding, and capture history. See the C3M frozen-release README.

How I used AI as an engineering tool

I used Codex and Claude heavily in this repository, but not as an alternative to understanding the system. I treated them as a team of fast junior engineers and reviewers operating from repo-local architecture documents, F Prime documentation, hardware contracts, and explicit skills/runbooks.

The workflow included parallel architecture audits, implementation tasks, test creation, documentation passes, and adversarial review. One second-opinion review found a real cross-thread cancellation race and over-throttled operator events during a hardening sprint. The fixes were accepted only after human review and the full validation gate passed again: generated-file drift checks, Python tests, F Prime generation/builds, component unit tests, automated local mission emulation, both Teensy builds, ARMv6 verification, and later real bench testing. The hardening sprint record preserves that process.

That is the lesson I take from this codebase: AI can dramatically increase engineering throughput, but the value comes from giving it strong context, dividing work cleanly, reviewing the output, and requiring physical evidence. On spacecraft software, a plausible answer is not enough—the build, protocol trace, CRC, hardware counters, and end-to-end demo have to agree.

Source branches: EPSCoR C3M and Neutron-2