Software Architecture (how I actually built it)
Three-module setup... clean, simple, and it does what it needs to do:
1) Main Firmware (the “keep the thing alive” brain)
This handles the display, BLE stack, fan control, button input, and sensor polling.
The UI cycles through four pages: main readings, filter status, environment, and a scrolling diagnostics page where I can literally watch what the adaptive system is thinking in real time.
2) Adaptive Sensor Module (the “learning” part)
This is where the system gets smarter instead of just spitting out raw numbers.
-
Signal filtering smooths the sensor noise (because VOC sensors are drama queens).
-
Calibration learns the relationship between inlet/outlet sensors (because they never match perfectly).
-
Environmental compensation corrects for temperature/humidity changing the readings over time.
-
Baseline tracking watches the “floor” shift and flags when a sensor starts acting suspicious.
3) Event & Filter Module (the “what does this mean?” part)
This tracks what’s happening in the real world and turns it into useful outputs:
-
Detects events like active printing vs idle
-
Calculates true filter efficiency (not the naive inlet/outlet ratio)
-
Tracks filter health over time
-
Learns usage patterns and predicts remaining life
Gotchas & Lessons Learned (aka: why the first version lied to me)
Efficiency math is way harder than it looks.
My first pass was the obvious approach: inlet vs outlet. Super clean. Totally wrong.
Because if your room baseline is already garbage (or already clean), the raw ratio is misleading. Once I accounted for baseline air quality and what’s realistically removable, the numbers started matching real filter performance.
Sensors drift. Hard.
VOC sensors don’t “measure truth.” They measure vibes.
They can get stuck reporting the wrong value for hours like they’re gaslighting you. So I added drift detection + compensation logic instead of trusting raw readings.
Calibration isn’t optional.
Two “identical” sensors won’t read the same in identical air. Ever.
So the system has to learn the offset between the pair, or you’re just building a fancy random number generator.
Persistence matters.
All learned parameters save to non-volatile memory so it doesn’t forget everything after a power cut.
But you can’t write constantly or you’ll wear out flash/EEPROM… and you can’t write too rarely or you lose learning when power drops at the worst time. So yeah, balancing save frequency was a whole thing.
Current Feature List (what it can do right now)
-
Dual VOC sensors (inlet + outlet)
-
Temperature + humidity compensation
-
Sensor calibration routine (pair-specific learning)
-
Adaptive baseline tracking
-
Drift detection + correction
-
Event detection (printing vs idle)
-
True filter efficiency calculation (baseline-aware)
-
Filter health tracking over time
-
Remaining life prediction
-
PWM fan control + auto mode
-
Color display w/ multiple info pages + diagnostics view
-
BLE app for logging + graphs
-
Learned parameters persist across power cycles
Apollo Timbers
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.