Mission summary.
What we're building, what my formal subsystem owns, and where the work extends into vehicle-level integration.
Project BlueSpear is AIAA at UTA's student space launch vehicle program. The program objective is to safely design, build, test, and operate a rocket that exceeds the Kármán line — 100 km above mean sea level — with engineering margins.
I serve as the Avionics & Command and Data Handling (CDH) Lead. Formally, CDH owns onboard computing, command/data paths, logging, and subsystem data interfaces. In practice, the work is broader than a narrow CDH box: I am helping define the early avionics architecture, requirements flowdown, power-interface needs, data paths, sensor coverage, documentation control, hazard controls, and integration logic before the team commits to a specific board or PCB layout.
The main impact so far is that the avionics problem has moved from “pick a flight computer” into a traceable engineering package: a working requirements baseline, a document-control protocol, an initial hazard assessment, architecture decision matrices for the flight computer and onboard data logging, and a clearer set of questions for Power Production and Storage, Communications, Structures, Thermal Determination and Control, Propulsion, and recovery-related interfaces.
Avionics & CDH objectives.
Near-term subsystem goals tied to reviewable outputs.
- OBJ-01 · Requirements flowdown. Maintain an avionics/CDH requirements baseline that is specific enough to drive architecture decisions, but not overfit to components that have not been selected yet.
- OBJ-02 · Flight-computer architecture. Use decision matrices to define the control, backup, logging, and telemetry architecture before jumping directly to a single board or vendor.
- OBJ-03 · Data architecture. Separate full-resolution engineering data from minimum mission-critical data so post-flight reconstruction does not depend on one device, one bus, or one storage path.
- OBJ-04 · Cross-subsystem interfaces. Define what avionics/CDH needs from Power Production and Storage, Communications, Structures, Thermal Determination and Control, Propulsion, and recovery-related functions before hardware layout.
- OBJ-05 · Safety and verification. Convert avionics/CDH hazards into controls that can be inspected, tested, demonstrated, or verified before flight.
Avionics/CDH architecture.
Preliminary architecture baseline from the current decision matrices.
Architecture decision package.
Results shown without inventing unavailable component scores.
These are architecture-level decisions, not final component selections. The purpose was to reduce design risk before committing to schematics, PCB layout, procurement, or flight software.
| Decision Area | Selected Baseline | Why It Won | Open Closure Item |
|---|---|---|---|
| Flight Computer Architecture | Custom primary avionics/CDH board + independent COTS backup | Balances mission-specific avionics growth, custom data handling, interface flexibility, and independent backup reliability. | Component selection, schematic architecture, and interface budget closure. |
| Onboard Data Logging Architecture | Custom full-data logger + independent COTS core-data logger | Preserves high-rate engineering data while keeping minimum mission data on an independent path. | Storage technology down-select and data-rate budget. |
| Power Interface Strategy | PPS-owned batteries/regulators feeding CDH-required protected rails | Keeps battery ownership with Power Production and Storage while giving CDH clear voltage/current requirements. | Voltage rails, peak current, connector pinout, and protection allocation. |
| Safety Controls | Default-safe outputs, inhibits, watchdog/brownout logic, ESD and harness controls | Turns hazard analysis into testable hardware, software, harnessing, and procedure requirements. | Verification matrix and bench-test procedures. |
Result: architecture baselines are closed enough to guide the next matrices. Final flight hardware is not yet selected.
Phases & milestones.
Progress to date and the next engineering closures.
Avionics/CDH leadership role established
Took ownership of the Command and Data Handling subsystem while also driving the broader avionics architecture discussion: requirements, interfaces, data paths, power needs, sensor coverage, and reviewable outputs for a five-member team.
CLOSEDConfiguration-control foundation drafted
Authored the CDH Document Control Protocol so requirements, interfaces, analyses, test plans, verification records, and change orders follow a consistent numbering and release system.
CLOSEDInitial CDH hazard assessment completed
Built a first-pass hazard log covering power faults, ESD, unintended outputs, processor resets, data-bus corruption, vibration-driven connector failures, thermal limits, EMI, and recovery handling.
CLOSEDArchitecture decision matrices completed
Completed flight-computer and onboard data-logging architecture decisions. The converged baseline is a custom primary avionics/CDH board with independent COTS backup, plus custom full-data logging with independent COTS core-data logging.
CURRENTStorage, interfaces, and test planning
Close the storage technology trade, define power and data budgets, release interface-control content, and convert the hazard controls into a bench-test and verification plan.
OPENWhat I actually do.
Specific responsibilities and engineering impact.
As Avionics & CDH Lead, I am responsible for keeping the flight-computer, sensing, logging, timing, safety-state, data-interface, and integration-planning work coherent before the team commits to hardware. The title is broader than CDH because the work crosses into early avionics architecture and systems engineering: requirements first, architecture second, components third, PCB layout only after interfaces and budgets are credible.
- Requirements discipline. Maintain avionics/CDH requirements as the basis for trade matrices instead of letting a preferred component define the mission.
- Architecture decisions. Lead flight-computer and data-logging trade studies with explicit assumptions, risks, and closure items.
- Documentation system. Created the CDH document-control protocol to make requirements, analyses, interface documents, verification records, and change orders traceable.
- Hazard reduction. Built the initial avionics/CDH hazard assessment and tied major failure modes to practical controls and verification methods.
- Cross-team integration. Define what avionics/CDH needs from Power Production and Storage, Communications, Structures, Thermal Determination and Control, Propulsion, and recovery-related interfaces.
- Lead-level communication. Present architecture decisions, open items, and rationale to other subsystem leads, the Chief Engineer, and the Project Manager so CDH decisions are not made in isolation.
The page is intentionally honest: this is not presented as flown hardware yet. The value is the systems-engineering and avionics architecture work that prevents a premature, fragile design from reaching schematic capture before the interfaces, hazards, and budgets are understood.
End of brief. Questions, corrections, or interview requests — open a channel.