Aurora Rocketry · Borealis & Nemesis
Rocket avionics, power, and verification.
PCB design, power, telemetry, and the verification lessons I took from two student rocket projects.
From the PCB layout to the integrated hardware
At Aurora Rocketry, I worked first on power and then as avionics lead. I designed most of our ground-station PCB, contributed to the onboard PCB design, and helped assemble and test the hardware.
For Borealis, I assembled and tested custom PCBs interfacing with more than 30 sensors. The work combined board-level tasks with the practical checks needed to make the electronics operate as part of the rocket.
Seeing hardware I had helped design operate during a launch was one of the most satisfying parts of the project. It also made the interfaces between boards, wiring, power, and firmware much more tangible.
Improving the data link on Nemesis
For Nemesis, I developed a 900 MHz telemetry link, including microcontroller firmware for packetization and error checking. I also tested antennas and telemetry connections.
The percentage refers to the comparison with the team’s previous vehicle. It describes the change in data dropouts, rather than a guaranteed link range or packet-reception rate.
My work covered both the radio connection and the handling of the data being sent. A useful telemetry system depends on the hardware and firmware working together, so I spent time checking the complete path rather than treating the antenna as an isolated part.
Power and practical verification
I worked on a redundant power architecture using LiFePO₄ batteries and a supercapacitor backup, with more than six hours of autonomous operation. My hardware work also included debugging and vibration and thermal-cycling tests.
Leading the avionics and power work meant keeping the electrical design, firmware, and integration tasks aligned. A change in one part could affect the checks needed elsewhere.
The failure at EuRoC 2025
At EuRoC 2025, a defective e-match prevented parachute deployment and our rocket crashed. We had not tested that component before integration.
After the launch, we changed our verification procedure to require individual component testing before integration. That experience made me more careful about the difference between having a system assembled and having evidence that its components work.
A change in how we worked
Component-level verification became a required step before integration. The failure made that requirement concrete for our team.
It was a difficult outcome. The useful part of the experience was the procedural change that followed, and the attention it brought to hardware reliability.
What I took forward
I enjoy hardware work because it gives direct feedback: a connection works, a board powers up, or a test reveals a problem. Aurora taught me to connect that practical work to verification planning and subsystem responsibility.
I now bring those questions into habitat design: what needs to be checked at component level, what must be demonstrated after integration, and what happens when a required function fails?
The board photographs come from my existing public project notes. Borealis and Nemesis are separate vehicles; the 900 MHz link and dropout comparison refer to Nemesis.