Dennis Sarsozo

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

The System Behind Our SmallSat 2026 Demo

If you met our team at SmallSat 2026, stopped by the booth, or saw one of our posters, this is the system behind the demonstration: a thermal camera, a small spacecraft computer, a microcontroller, a constrained UHF radio, and ground software working together to turn a payload measurement into a verified product on a laptop.

The project is called C3M—CubeSats for Climate Change Monitoring. It combines compact infrared-sensing research with the practical systems work required to capture, store, transmit, recover, and interpret science data on small-satellite hardware.

This overview video introduces the mission and the hardware our team has been developing:

Open the C3M overview video directly in Google Drive.

HSFL, Artemis, and C3M

The Hawaiʻi Space Flight Laboratory at the University of Hawaiʻi at Mānoa develops small-satellite missions, payloads, and the enabling systems around them. One of those systems is the Artemis CubeSat Kit, a modular, low-cost, open 1U CubeSat platform that gives students and researchers a shared foundation for spacecraft development.

C3M uses that foundation to mature compact, low-power infrared sensing and spectroscopy for greenhouse-gas point sources and natural hazards in Hawaiʻi and across the Pacific. The science targets include carbon dioxide, methane, sulfur dioxide, wildfire and thermal anomalies, and volcanic activity.

The target instrument is a Fabry–Perot spatial Fourier-transform spectrometer spanning approximately 2.5–12 micrometers. That full interferometric instrument is still under development. The demonstrated system uses a FLIR Lepton thermal camera to establish the supporting foundation: payload capture, avionics, data handling, radio transport, ground reconstruction, and field operation.

That distinction matters. C3M is an active payload-and-platform maturation effort, not a frozen orbital mission with every flight decision already closed.

The end-to-end data path

The demonstrated path is intentionally built from accessible commercial hardware:

  1. A FLIR Lepton captures a 160×120 thermal image.
  2. A Raspberry Pi Zero W handles the camera and higher-level payload work.
  3. A Teensy 4.1 performs deterministic spacecraft control, packet handling, and radio duties.
  4. An RFM23BP 433 MHz UHF radio sends the data over the air.
  5. A ground Teensy, RFM23BP, and Yagi antenna receive the packets.
  6. Laptop software reconstructs the image, checks its integrity, and presents it to the operator.

A typical Lepton product is roughly 38.4–40 KB. That is small by everyday computing standards, but large compared with the radio’s packet limit. RadioHead exposes a maximum 50-byte message because of the radio FIFO constraints, and the link is half-duplex: each side must take turns transmitting.

The hardware is affordable and modifiable, but it forces the software to be deliberate. The system cannot treat the radio like a reliable network connection or assume that a large file will arrive intact.

SNACK: request only what is missing

Our answer is a software-defined selective-negative-acknowledgment protocol, or SNACK.

Each packet is indexed so the receiver knows where it belongs. The C3M packet carries up to 49 application bytes: 45 bytes of image data and four bytes of overhead. Packet-level CRC16 checks help reject corrupted fragments, and a full-image CRC verifies the reconstructed product.

Instead of acknowledging every packet individually, the sender transmits a burst of indexed fragments. The receiver records which fragments arrived and then returns a compact bitmap identifying only the missing packets. One 45-byte SNACK bitmap represents 360 packet statuses—the equivalent of as much as 16.2 KB of missing science data in a single request.

The sender then retransmits only the requested fragments. This reduces turnaround overhead on a half-duplex link and avoids repeatedly sending data the ground already has.

The protocol does not make packet loss disappear. It makes loss visible, bounded, and repairable.

What the field tests established

The team tested the system progressively rather than jumping directly to the longest range. Tests moved from 5 meters to 30 meters, then approximately 140 meters, and finally 1.6 kilometers.

The published SNACK results report:

The broader C3M paper summarizes the demonstrated link as 99% integrity with 72.2 kbps peak throughput.

The tests also went beyond sending synthetic bytes. The team captured and downlinked a thermal image across the 1.6 km link. An airborne demonstration carried the system on a drone at approximately 100 meters above ground level while recording GPS and inertial-measurement data alongside the imagery.

These measurements belong specifically to the bare-metal C3M/SNACK implementation used in the conference papers. They are terrestrial field-test results—not orbital-link performance—and they should not be presented as measured performance for our newer F´ integration.

Where F´ fits

The published field results prove the core data path: capture a payload product, divide it into radio-sized packets, recover missing fragments, verify the reconstructed file, and display it on the ground.

Our ongoing NASA F´ work carries those lessons into a more reusable flight-software architecture for Artemis. F´ provides the command, event, telemetry, storage, and component framework around the mission. The payload and RF path still have to respect the same physical constraints: limited packet space, half-duplex operation, interrupted reception, and end-to-end integrity checks.

I worked on the embedded software and end-to-end data path that turns a payload measurement into a verified product on the ground. That includes payload capture, Raspberry Pi-to-Teensy transport, reliable packetized RF downlink, retry and CRC repair, ground decoding, and forward F´ integration.

The important claim boundary is simple: the conference papers’ 72.2 kbps, 99%, and 1.6 km figures describe the bare-metal implementation. The F´ architecture is related integration work, not a relabeling of those measurements.

What comes next for C3M

The next payload stage moves from the Lepton foundation toward a Boson+ 320 camera and custom optics. From there, the team plans to integrate the Fabry–Perot interferometer and begin spectral validation, initially focusing on sulfur dioxide.

Mission studies also explore how a scalable constellation could improve revisit over Hawaiʻi and the Pacific. The final orbit, constellation size, flight radio, and closed spacecraft budgets remain in development. Those study parameters are useful for engineering, but they are not selected flight facts yet.

The bridge to Neutron 2

Neutron 2 is a separate mission with a different science payload, but it benefits from the same enabling architecture and software lessons.

The concept is to measure neutron and gamma-ray flux in high-inclination or polar low Earth orbit and compare those measurements with geomagnetic position, time, altitude, spacecraft orientation, and solar activity. Its planned approximately 1.5U payload uses a TLYC scintillator and pulse-shape discrimination to separate neutron and gamma events. Gadolinium shielding supports comparison of thermal and epithermal neutron directions.

The current design estimate is 1.8 kg including margin and less than 6.3 W. Those are design figures, not final flight measurements. The current FlatSat uses a payload simulator; the real detector has not yet been integrated into that test chain. No final orbit or launch has been selected.

What C3M and Neutron 2 share is the engineering flow around the payload:

command → collect → store → RF downlink → ground review

A thermal image and a neutron event record are different science products, but both need a dependable spacecraft-and-ground system around them. That reusable path is where Artemis and the F´ architecture can provide lasting value across missions.

Built by a team

This work is collaborative. The SmallSat SNACK paper was written by Samantha Mallari and me, with Miguel Nunes as faculty advisor. The C3M system paper was authored by Miguel Nunes, Noah Thompson, Jharrell Sim, Samantha Mallari, Dennis Sarsozo Jr., Junjie Huang, Jaycee Hasegawa, Mari Murillo, and Paul Lucey.

The hardware, payload research, field testing, protocol work, ground tools, and mission studies reflect contributions across that team. My focus has been the embedded flight software and data path—not inventing or building the entire mission alone.

If you want to talk about CubeSat flight software, constrained communications, F´, payload integration, or university mission development, get in touch. I’m always happy to compare notes on what it takes to move from a payload measurement to something an operator can trust.