Taking C3M Outside: Commanding and Downlinking Thermal Data with F Prime
Software that works across a lab bench still has something to prove outside. In our latest field test at the Hawaii Space Flight Laboratory, the NASA EPSCoR C3M team separated the CubeSat hardware from the ground station, pointed a Yagi antenna downrange, and tried the complete mission path over the air: command a thermal image, request its downlink, recover missing packets, and reconstruct the image on the ground.
HSFL captured the test in this short behind-the-scenes video:
F Prime GDS as the operator interface
The laptop in the video is running the F Prime Ground Data System. F Prime GDS gives us the operator side of the spacecraft: it loads the deployment dictionary, presents available commands, and displays the events and telemetry returned by the flight software.
For this test, we use GDS to send a command to the C3M flight software running on the spacecraft hardware. The command triggers the infrared payload to capture a new image. Once the flight software reports that the science data is ready, we send a second command requesting the downlink.
That simple interaction represents the system I have been developing for our Artemis CubeSat platform. A command leaves GDS, travels through the ground radio hardware, crosses the RF link, and reaches the F Prime deployment on the spacecraft. The resulting thermal data then makes the reverse trip through a packetized payload channel built for our constrained radio link.
Range worked; the remaining faults are on the ground side
The outdoor test confirmed the main question we brought outside: the Yagi RF link can both command the spacecraft and downlink science data at range. The current blocker is not basic RF range, the F Prime mission software, or the satellite node. It is intermittent behavior on the ground-station side.
The video is valuable because it shows a real engineering test, not a polished animation. Partway through the transfer, packets are missed and the ground node stops receiving. Its watchdog power-cycles the radio through the shutdown pin, the link returns, and the transfer continues without restarting F Prime GDS or the Teensy.
Eventually the receiver reaches 100 percent and reconstructs the 160×120 thermal image taken downrange. The complete transfer contains 1,100 of 1,100 packets, passes CRC verification, and takes about 58 seconds. You can see the person and the warmer grass in the recovered image. The test closes the full loop:
- Send a payload command from F Prime GDS.
- Capture infrared data on the spacecraft hardware.
- Request the science-product downlink.
- Transfer the packetized file over the outdoor RF link.
- Recover from interrupted reception and missing packets.
- Reassemble and display the completed thermal image on the ground.
That recovery behavior matters as much as the final picture. A useful flight system cannot assume a perfect connection. It needs bounded packets, retry behavior, health monitoring, and enough ground-side visibility for operators to understand what is happening.
We currently see two intermittent, reset-recoverable ground-side faults. The USB serial transmit path can stall during science downlink, and the ground RFM23BP can occasionally remain stuck in transmit mode. I call these “GDS-side” issues because they happen on the ground half of the link, but the evidence does not point to a bug in fprime-gds. The likely fault domain sits below the GUI: the USB CDC transport, ground Teensy, or the RFM23BP power, SPI, and control path.
The stuck-transmit fault also reproduces with the satellite powered off. That isolates it from distance, a missing remote acknowledgment, and the satellite itself. I added bounded recovery that records the fault, power-cycles the ground radio, and restores the link. The next investigation is hardware-focused: compare 28 versus 30 dBm operation, scope radio power during transmit, inspect SPI and interrupt signals, verify the ground-board power and backfeed topology, and test whether the fault follows the Teensy or remains with the ground OBC/radio assembly.
From flight software to a complete mission system
My work on C3M has focused on developing the F Prime flight-software architecture that connects these pieces. The Raspberry Pi runs the F Prime deployment and commands the infrared payload. Teensy-based radio bridges carry command and telemetry traffic between the spacecraft and ground equipment. A separate packetized path moves larger science products without overwhelming normal spacecraft telemetry, while the ground software tracks progress and rebuilds the final file.
Outdoor testing moves us beyond proving individual components on a desk. This test established that the long-range command and downlink path works, then narrowed the remaining reliability work to a specific ground-side fault domain. That is exactly what a useful field test should do: replace broad uncertainty with evidence and a focused next investigation.
C3M—CubeSats for Climate Change Monitoring—is a NASA EPSCoR-funded 1U mission built on HSFL’s modular Artemis CubeSat Kit. The broader goal is to advance low-cost thermal remote sensing for applications such as wildfire detection, volcanic-hazard monitoring, and climate research in Hawaiʻi and beyond.
For me, this test is an exciting milestone because the software is no longer only a diagram, build log, or bench setup. A team can stand outside, use F Prime GDS like a spacecraft operator, command our payload through the radio link, and receive an actual thermal product back.