Flight Computer Engineering Notes
Scope
The Flight Computer is the main compute and data-recording board in the flight stack. I helped with parts of the schematic/layout review, but the part I really owned was bring-up, interface validation, debugging, and keeping the board working through integration.
I treat this page as a bring-up/test case study rather than pretending the original board architecture was mine.
Bring-Up
I treated bring-up like a checklist and only added complexity once the previous step was boring:
- assembly inspection and resistance checks;
- current-limited power;
- power sequencing;
- processor boot/debug;
- digital-bus enumeration;
- sensor plausibility;
- ADC/reference checks;
- flash read/write;
- telemetry, USB, and Recovery interfaces;
- integrated flight-stack operation.
That made later debugging much easier because I always had a known-good stopping point.
5 V Converter Characterization
| Output load | 5 V output | Measured ripple |
|---|---|---|
| 0.1 W | 4.997 V | 19.8 mVpp |
| 1 W | 4.994 V | 21.4 mVpp |
| 2.5 W | 4.985 V | 25.8 mVpp |
| 5 W | 4.960 V | 31.0 mVpp |
| 6.25 W | 4.952 V | 34.2 mVpp |
| 8.33 W | 4.936 V | 34.4 mVpp |
| 12.5 W | 4.910 V | 36.2 mVpp |
The efficiency sweep peaked at 95.879% at 12.167 W output / 12.69 W input.
On the input ramp, the 5 V and 3.3 V rails started regulating at about 29.84 V VBUS. I also captured a 1.136 W → 12.5 W load step so I could see how the converter behaved when the board load changed quickly.
System Validation
Once the rails looked good, I moved through processor boot, sensors, ADC scaling, flash, telemetry/USB, and the Recovery interface in the same order every time.
That repeatable baseline ended up being useful during vehicle integration. If something broke, I could pull the problem back to one subsystem and figure out whether the fault was on the Flight Computer, in the harness, or somewhere else in the stack.
Operational Ownership
I kept supporting the board after the initial bring-up too. That mostly meant reproducing weird integration failures, keeping a known-good bench setup around, and helping trace issues that crossed hardware/software/harness boundaries.