Dennis Sarsozo

Developer & photographer on Oʻahu, Hawaiʻi.
Let's build 🤙🏽

CubeSat Thermal Imaging Payload

C3M thermal-imaging payload team at the Hawaii Space Flight Laboratory
The C3M team and mission at the Hawaii Space Flight Laboratory.

At the Hawaii Space Flight Laboratory, I lead embedded flight software development for the EPSCoR C3M thermal-imaging payload. The current implementation is a complete F Prime mission slice: command a real FLIR Lepton camera on the satellite Raspberry Pi, capture a thermal Data Product, store it, packetize it for the constrained radio, reconstruct and verify it on the ground, and render the image for an operator.

From payload prototype to reusable flight software

The original C3M pipeline proved the concept with C/C++ firmware, a Raspberry Pi, Teensy 4.1, FLIR/Seek Thermal hardware, and a 1-watt 433 MHz RFM23BP link. I worked across that entire stack: libuvc camera capture, UART framing, RadioHead transmission, missing/duplicate packet tracking, CRC16 validation, Python tooling, temperature averaging, and calibration datasets.

The later EPSCoR C3M F Prime branch turns that mission-specific prototype into one payload driver inside the shared Artemis flight-software architecture. PayloadDriver_Lepton owns camera-specific capture and produces Lepton .fdp Data Products. Generic payload, storage, communications, and downlink components remain shared with Neutron-2. The same mission stack can therefore run a Lepton camera for C3M or a neutron simulator/board for Neutron-2 by swapping the payload driver and ground decoder.

That separation matters more than the class names. Camera and libuvc details stay at the hardware edge; mission logic only asks for a capture. Storage tracks the latest science product. The communications application requests its downlink. A payload downlink component breaks it into packets sized for the RF budget, while the ground receiver reconstructs the .fdp file and validates the final CRC before displaying it.

The real end-to-end path

The validated demonstration crosses four computers:

  1. fprime-gds sends the collection/downlink commands from the laptop.
  2. A ground Teensy packetizes the command for the RFM23BP radio.
  3. The satellite Teensy reconstructs it and passes CCSDS bytes over the multiplexed UART to the Raspberry Pi Zero W.
  4. F Prime commands the real Lepton capture, then sends the resulting Data Product back over the separate channel-1 payload path to the C3M receiver web app.

The ground application shows packet progress, CRC proof, thermal decoding, and capture history. The frozen C3M release was validated by three consecutive live hardware-in-the-loop runs on July 9, 2026. It includes pinned Teensy binaries, a Pi Zero W ARMv6/libuvc deployment and dictionary, flash/deploy scripts, checksums, operator documentation, replay data, and an atomic Pi installer with rollback.

The exact architecture and operational evidence are public:

The biggest lesson was learning to engineer for a system where every abstraction eventually meets physical reality. The Pi Zero W is ARMv6. The camera requires real libuvc dependencies. The radio is lossy and carries only small packets. CCSDS frames are CRC-protected and cannot tolerate missing bytes. Solving the problem meant designing clean component boundaries while still measuring the actual link, checking hashes and CRCs, and documenting what was—and was not—proven on the bench.

UH students: if you’re interested in writing real flight software for satellites this summer, hit me up on campus. We’re always looking for people who want to build.

Earlier payload sources: hsfl/epscor-c3m-payload and hsfl/epscor-c3m-flirlepton