Entry 01 // Systems engineering
High-Altitude Balloon Flight System
A recoverable 30 km payload covering structural, thermal, avionics, telemetry, power, and recovery subsystems. Fully built, integrated, and ground-tested in 16 weeks. ATC denied airspace access on launch day, so the article never flew.
1.0 Mission
The system delivers a recoverable scientific payload to roughly 30 km, collecting environmental and positional data through ascent, float, and descent while maintaining structural integrity, communications, and recovery performance. The payload has to return to the ground with its data intact and minimal damage, inside a 16-week academic term and a fixed $1,500 budget.
Those two constraints shaped the architecture more than any technical preference did.
2.0 Systems engineering approach
The project ran on formal methodology: structured trade studies, risk management, and requirement traceability driving design decisions rather than following them.
- Work breakdown structure: five major phases from planning to flight success
- Functional breakdown structure: every function required for mission success
- Functional flow diagram: function sequencing across the mission lifecycle
- N² interface analysis: subsystem interactions and dependencies
- Risk assessment: technical and operational risks with mitigations
3.0 Requirements
Primary
- Climb to 30 km (100,000 ft)
- Transmit real-time temperature to the ground station
- Transmit acceleration data to the ground station
- Recover the payload after landing
- Log data onboard as backup telemetry
Secondary
- Transmit HD color images to the ground station
- Transmit humidity data
- Track balloon location
- Operate below −94 °F for at least 3 hours
4.0 Selected architecture
Chosen through weighted trade-off analysis:
| Subsystem | Selection |
|---|---|
| Structural | Single-string suspension attachment |
| Thermal protection | Expanded polystyrene (EPS) foam enclosure |
| Avionics | Hybrid Raspberry Pi + microcontroller |
| Communications | Satellite tracker with RF telemetry |
| Power | Lithium-ion battery system |
| Recovery | Single parachute with crush-structure base |
Single-string suspension won on integration complexity, structural mass, load path simplicity, and manufacturability inside the 16-week schedule. That was a schedule-driven decision, and we made it deliberately.
5.0 Ground verification campaign
Every test below was completed on the built article. Results are drawn from the design and verification report.
- Endurance / logging
- Roughly 7 hours of continuous operation, split between simulated flight and post-landing power-save, with data logged throughout.
- Pass
- Telemetry range
- RFM95W LoRa transceiver delivered 1 Hz packets at test range with content intact.
- Pass
- Parachute drop
- Deployed correctly from a low-altitude drop, producing a controlled, stable descent.
- Pass
- Suspension load
- Shock cord, swivel, and attachment points sustained the applied load with no deformation or failure.
- Pass
- Cold soak
- All sensors and the Raspberry Pi initialized after cold exposure, but lab equipment could not reach the full −70 °C target.
- Partial
- GPS ground accuracy
- NEO-M8N and u-blox M10 both produced fixes within ±10 m of a known position.
- Pass
- Software verification
- SPI, I2C, and UART interfaces confirmed; fault handling reviewed.
- Pass
6.0 Outcome
Flight: not conducted
ATC denied airspace access on the launch date and a NOTAM was not secured in time, following procurement and budget delays. The article never left the ground.
Verification status of 22 system requirements
11 verified4 partially verified7 not verified
Of 22 system requirements and constraints, 11 were fully verified through ground testing, analysis, inspection, or demonstration, and 4 were partially verified to the limit of what ground conditions allowed.
The two altitude-dependent requirements, altitude achievement and ascent rate, could not be assessed in any form without flying, since both depend entirely on in-flight GPS data.
- Budget: not met. Final system cost exceeded the $1,500 limit.
- Schedule: met. Built, integrated, and ground-tested inside the 16-week term.
- Remaining nine constraints: met, with the system designed to FAA Part 101 and FCC Part 15.
7.0 What the team would do differently
Retrospective
- Build launch contingency into the schedule from the start. When ATC denied access, there was no fallback date. This is the single largest lesson from the project.
- Coordinate with ATC early rather than treating clearance as a formality. Submitting the NOTAM request sooner and following up would likely have surfaced the problem while it was still fixable.
- Order long-lead components earlier. A GPS module shipping delay cost 1–2 weeks of assembly time, recovered only by parallelizing other tasks.
- Track budget continuously rather than at milestones. The overrun was visible in hindsight well before it was addressed.
Full report
Design & Verification Report with requirements, trade studies, test procedures, and results.