A regenerative CO₂ preprocessor concept for future lunar habitats — prototyped by an 8th grader on his desk.
I started AERO-LITE in mid-March 2026 after an email from Space Center Houston described a Carbon Capture Challenge. I had learned a little about electronics and robotics before this, but almost nothing about air chemistry. I decided to learn it the way I usually do: by building something real and seeing what it can actually prove.
Top Individual Award · Middle School Division · NASA Carbon Capture Challenge 2026
Space Center Houston's Carbon Capture Challenge asked students to think about how future Moon habitats would manage the CO₂ that people exhale — with limited power and mass. That constraint is what pulled me in: on Earth, fresh air solves most buildings' CO₂ problems. In a sealed habitat, you have to decide where the CO₂ actually goes.
The station-grade answer today is a big machine that vents CO₂ overboard. And everything I read about keeping people alive in a surface habitat comes back to the same idea: the air will be recycled, so each part of the system — capture, release, storage — becomes part of a loop, not a one-way stream.
I am not going to pretend an 8th grader solved habitat engineering. What I had was a question from people who run a real space center, three months to try something, and a habit: when I don't understand something, prototype it small and see what the numbers say.
My first concept looked elegantly simple: pull cabin air into a compressor, squeeze it, get a concentrated CO₂ stream. One stage instead of several. Less mass, fewer parts. I liked it so much I started sketching the compressor placement before doing the arithmetic.
Cabin air is mostly nitrogen and oxygen. Squeezing it does not separate the components; it just makes harder-to-manage mixed gas. When I sat down with the composition, the "one elegant stage" stopped looking elegant — it would spend the project's energy on ~99% of the air that isn't CO₂.
So AERO-LITE reversed direction: capture CO₂ first, then — later in the design — compress a stream that is actually CO₂-rich. That single decision is why the prototype is a sorbent bed with sensors, not a compressor with plexiglass. The power and mass savings the redesign promises are estimates; testing them is exactly the work I have listed as unfinished.
The concept is a four-stage loop. Honesty check before anything else: the first two stages exist as real hardware. The last two are design stages — the concept for them exists, the hardware outcome does not.
Silica gel strips moisture first — humidity kills CO₂ capture efficiency, so this stage has to come first.
A zeolite 13X bed captures CO₂ at room temperature; nitrogen and oxygen pass through. Three live sensors watch the result.
Controlled heating would release the captured CO₂ for reuse. The first prototype only simulated heater control.
A CO₂-rich stream would be compressed into a buffer tank for possible downstream use. Not built, not integrated.
Intended control schedule: ADSORB (~5 min) → REGEN (~1 min) → PURGE (~15 s), about 6 minutes 15 seconds total. This is a design setting, not a validated full regeneration-cycle measurement. The buffer tank idea is meant to smooth the intermittent output; that integration still needs to be tested.
I wanted the first build to be the least impressive possible version of the idea: jars, beads, sensors — not a rendering, not a sci-fi panel. A bench prototype can tell you whether a component behaves; it cannot yet tell you whether the whole loop is efficient.
One recorded dashboard snapshot: cabin sensor 1,029 ppm; purified sensor 477 ppm.
These readings illustrate live sensor output from real hardware. A single snapshot does not establish capture efficiency or sustained performance.
Reliable across the three sensors — including the I²C channel selection behind them — took its own debugging story.
LIVE DASHBOARD The CO₂ dashboard is real, not a mockup — a web UI served by the ESP32-S3 that updates every second. The readings shown under OBSERVED above were captured from it as live sensor output; this page describes it through those readings and the bench photograph rather than a stylized UI frame.
“This is not a rendering. It is three mason jars on my desk, a live ESP32-S3, and a web dashboard that updates every second.”
The hard parts weren't the ones I predicted. None of these lessons would have appeared in a slideshow; they only showed up at the bench.
My original design rested on a mistake I didn't notice until I checked the composition of air. Squeezing mixed gas doesn't sort it. Catching this early cost me a week of sketches and saved the whole project — the numbers proved it, so I redesigned before building.
The three SCD41 sensors sat behind an I²C multiplexer and kept going silent. The channel-mask math was right, but the code didn't always select the right channel before each read. Three days of testing assumptions one at a time fixed it — and I now write the intended channel selection right before every sensor communication.
For releasing CO₂ from the zeolite, a pressure-swing approach would use less energy. But vacuum seals on moving hardware in rough conditions are leak risks. A PTC heater with a bimetallic cutoff is the safer path for this prototype — even if the microcontroller crashed, the cutoff would remain. That trade-off is a design decision, not a proven result.
Live readings made the project feel real — and I had to learn not to oversell them. One clean-looking number is a snapshot, not an efficiency measurement. Explaining that distinction to judges taught me as much as building it did.
Unfinished, on the record: repeatable regeneration (how much CO₂ actually comes back off the zeolite, at what concentration), compressor and buffer-tank integration, and controlled measurements of power and mass against those estimates. Next: build the regeneration stage for real, run controlled capture/release cycles with logged data, and replace the estimates above with measurements — even if the numbers get worse.
These notes cover the messier parts of this project — the calculation, the debugging, and what it took to explain it honestly.
I wanted to compress cabin air directly, but compression alone would not separate out CO₂. The numbers made me rethink the design: capture CO₂ first, then consider compressing a concentrated stream. That is where AERO-LITE changed direction.
My three SCD41 sensors were not responding reliably through the I²C multiplexer. The channel-mask calculation was correct, but my code was not consistently selecting the right channel before sensor reads. A story about testing assumptions, the Serial Monitor, and why sleep matters.
Eight slides and a prototype with live CO₂ readings. What I learned about explaining a technical project without exaggerating what my first prototype actually proved.
Firmware, system documentation, and competition materials are open source in the project repository.