Flight Computer Wiki
Under construction
These notes are being tightened as final screenshots, measurements, and layout callouts are added.
Purpose
The Flight Computer is the central compute, sensing, telemetry, and data-recording board in the flight avionics stack. It talks to the vehicle sensor suite, onboard storage, telemetry system, recovery controller, current-loop sensors, and external debug equipment.
My Responsibility
I supported portions of the schematic and PCB layout and participated in design reviews. After fabrication, I led board bring-up, system-level debugging, interface validation, and day-to-day operation.
That distinction matters. This project shows real hardware ownership without implying that I was the sole original schematic or PCB designer.
Architecture
The board combines:
- Primary compute and control
- Power regulation
- IMU, barometer, and magnetometer sensing
- ADC-based measurement
- Onboard flash storage
- Current-loop sensor interfaces
- Telemetry
- USB
- Recovery-system communication
- Flight-stack connectors
Together, those functions make the board both the central controller and the primary flight-data recorder.
Design Review Focus
My schematic and layout review focused on:
- Rail sequencing and accessible measurement points
- Sensor supply and reference integrity
- ADC filtering and signal polarity
- Digital-bus connectivity
- Flash and telemetry interfaces
- Recovery-system signal ownership
- Connector pinout consistency
- Return-path continuity around sensitive measurements
Bring-Up Strategy
Bring-up was split into functional stages:
- Assembly inspection and resistance checks
- Current-limited rail bring-up
- Processor boot and debug access
- Digital-bus enumeration
- Sensor identity and sanity checks
- ADC scaling and reference checks
- Flash read/write verification
- Telemetry and USB communication
- Recovery-system interface testing
- Integrated flight-stack operation
This sequence kept failures in one subsystem from being hidden by the activity of the complete board.
Operations Ownership
After initial validation, I stayed responsible for keeping the board operational during subsystem tests and integrated vehicle work. That included reproducing failures, figuring out whether faults came from the board or an external interface, coordinating fixes, and maintaining a known-good test setup.
Featured Evidence
The page should eventually prioritize:
- A labeled board image showing functional regions
- Rail bring-up captures
- Sensor enumeration or telemetry evidence
- A flight-stack interface diagram
- One concrete debug story
- A photo of the integrated avionics stack
Next Revision
Add dedicated interface-test documentation for every external connector and record a baseline set of known-good waveforms and telemetry values for rapid regression testing.