Certification flight · September 2026
Predicting a Rocket Flight
Tripoli Level 1 on a LOC-IV X2, flown 5 September 2026. I built the flight computer that went in the electronics bay and wrote a 1-DOF trajectory model before the launch to see how close I could get to the measured altitude.
Over the summer, I grew interested with rocketry. I got a great Estes Alpha rocket and learned a lot with it. I went to a Tripoli high power rocketry event near me and saw an L motor rocket launch. I immediately ordered the LOC-IV X2 rocket kit that would allow me to get my L1 and eventually L2 High Power Rocketry certifications.
How cool would a self-landing model rocket be. Difficult for the L1 but possible eventually. The first step to that was an L1 for the higher power motors and getting experience with computers at altitude for avionics. The LOC-IV X2's electronics bay with an altimeter and IMU allows me to see how high my rocket would go and better tune my simulations in future builds.
The Rocket Build
I spent a lot of time reading about the various parts that could go wrong with an L1 rocket build — epoxying, weak joints, a misbalance of the CG/CP ratio — and I wanted to get everything right. I realized cutting and epoxying would be the hardest to fix if I messed up so I took extra care with those steps. I was also aware that the technology in the Ebay could be damaged and not recoverable if something failed in flight.
The epoxy was the biggest learning curve to overcome. Getting the technique right to apply epoxy and look good is something I got better at throughout the process. I used 15-minute epoxy that allowed more error in the application process so I could wipe away excess epoxy.
The LOC-IV X2 and many high power rockets feature through-the-tube fins for added support. This was different than the Estes Alpha rocket I built and a bit worrisome being a tight fit with epoxy and if it was messed up, the build would be ruined. However, after a few dry fittings and preparation, it went in smoothly and epoxied together great. I did the fins last and for good reason. It closes up the motor mount and everything within the body tube is inaccessible. But more importantly, it was one of my last epoxies and a more visible one on the build. Due to my improvement in epoxying over the build, they looked significantly better than some of the earlier ones, and they are the most structurally significant to the flight.
Logger
For interest's sake, I put a logger in the rocket's Ebay even though I didn't do dual deployment. I wanted to see measured results from something I built.
I used an Adafruit Feather RP2040 Adalogger for the microcontroller, a Bosch BMP581 and a Goertek SPA06-003 for two redundant altimeters, and a LSM6DSOX Arduino Modulino movement board for the IMU. The logger was powered by a 500 mAh LiPo and the data was stored to a microSD card plugged into the Adalogger.
On the field, I used the base measurements from the ground as height 0 m. Then from the barometric data through air holes in the body tube of the Ebay, I could calculate how high it went using the standard atmosphere formula referenced to the pad.
I also put an AirTag in the Ebay to help find it when it came down in the soy field. This was something I learned after losing the Estes Alpha on a C motor that took it above the clouds.
The difference between the two altimeters during the flight was interesting. While their absolute calibrations were off from each other by about 1.194 hPa, if you take each relative to its own starting point then they both hold to about 19 mm of noise sitting on the pad, and their noise floors match each other within .2 mm. Their measured apogees are 1.2 meters apart (.4% difference). However, their ascents differ by up to 40 meters throughout. This was due to the sampling lag inherent in them. My logger samples at 55 Hz, but the BMP581 only produces a new reading at 43 Hz and the SPA06-003 at 3.4 Hz, so the SPA is showing a delayed updated height in comparison to the BMP and the semi-static pause at apogee allowed them to sample very close heights.
1-DOF Flight Simulation
While I used Open Rocket to test my build against the flight-site's launch waiver of 4500', I decided to make a 1 degree of freedom flight simulation in MATLAB to see how close I could get to my logger's measured altitude.
For this, I used a 1-DOF trajectory model integrated as an initial value problem with ode45 (Dormand-Prince 5(4)) with an adaptive RelTol 10−8 tolerance, terminated by an apogee event. I initially tested it given my expected temperature, pressure, impulse, and drag coefficient before the flight. However, the day after my launch I noticed that my measured altitude was quite off from the simulation's expected altitude of 1209 feet (368.5 m). So I analyzed it with forward uncertainty propagation with a Monte Carlo simulation over four sampled inputs and global sensitivity analysis by correlation after the launch.
With that model, I used a Monte Carlo analysis adjusting the drag coefficient (Cd), pressure (p), temperature (T), and impulse (Fc).
I chose a 1-DOF model because rockets essentially go straight up and the offsets tend to happen after parachute deployment, which is not what I am concerned with when finding the apogee. Therefore the 1 degree of freedom seemed adequate and more than enough for the given situation. This was a pretty good assumption with my gyroscope showing a 0.42 degree tilt through the entire boost phase. The effect that had on it is about 3 parts per hundred thousand or about 8.4 mm off and while it could have had a greater effect in different conditions, it justified my decision for a 1-DOF model on this flight.
I could not measure the drag coefficient before actually launching the rocket. My Open Rocket simulation calculated a Cd of .45 given my model and I read online that L1 model rockets tend to range from .45 to .75. So I took that as a good range to test. The temperature was assumed to be around 20 degrees Celsius plus or minus 5 degrees from the forecast and I used the International Standard Atmosphere sea level pressure of 1013.25 hPa plus or minus 10 hPa.
For the impulse, according to the NAR AeroTech G76G certification report a manufacturer's own motor could have 1-2% impulse variation. The report finds 115.0 N·s with a standard deviation of 1.8, a relative standard deviation of 1.6%. Then I saw that there is a regulatory ceiling of 6.7% standard deviation in accordance with NFPA 1125 §8.2.7. Inferring that both those could apply to my motor as well, I used an assumption of plus or minus 3% for a medium between the two as my Monte Carlo variation to see how it would affect altitude.
The model found a mean height of 343.9 meters (1128.3 feet) across N=10,000. The 2.5, 50, and 97.5 percentiles were 303.5 m, 342.5 m, and 391.3 m respectively. The standard deviation was 22.6 meters from the mean.
What I found when I launched it was that the apogee turned out to be 311.2 meters (1021 feet) above the launch pad by the standard atmosphere formula above. That formula assumes a 15 degree Celsius sea level temperature and the air on launch day was around 23 degrees, which is a less dense column, so the same pressure drop covers more altitude than the formula allows for.
Correcting it to the pad pressure my barometer measured and the warmer air on the day gives 1052 feet (320.6 m), about 3% higher, and that is the number I compare the simulation against since the simulation runs on real air rather than a standard one. This differed from the expected altitude of 1209 feet (prior to the launch and Monte Carlo) by 157 feet. However, within the Monte Carlo the measured apogee was at the 14.8 percentile, that is low in the distribution (though within the central 95% interval). Some factors came into play that I predicted inaccurately. The main driver of this difference between the expected mean 1128 feet (343.9 m) and the measured 1052 feet was the drag coefficient.
I measured the acceleration at 12.58 g against 12.5 (.6% difference), burnout was inside 4% of the motor's published figure, and peak velocity was 92.2 m/s against the 93.07 predicted (.9%). That means that the mass model, thrust curve, and parser were all checked against direct measurement and the boost phase was likely not the cause. The error seemed dominantly within the coasting phase. In the coasting phase the only forces are drag and gravity, so it's the phase with drag as the primary contributor. My real rocket was far draggier than I anticipated. The actual drag coefficient is about 0.75 calculated from the corrected measured altitude. Far higher than the assumed 0.45.
The Monte Carlo also showed the correlation of each input. The major share of variance was the Cd with 57.6% (r = -.7588, r2 = .5758), impulse also contributed heavily with 40.6% (r = .6368, r2 = .4055). Temperature (r = .079, r2 = .0062) and pressure (r = -.0415, r2 = .0017) contributed almost nothing at .6% and .2%, respectively.
What I Will Do Differently
There was a lot I learned about building and preparing something for a scheduled launch through this project. I discovered that despite my efforts to think of everything that could go wrong prior to the launch day, I still showed up and had to sand parts down due to an RSO saying it fit too tight to fly.
Additionally, with this new drag coefficient, I will be able to better simulate future launches with this rocket for when I plan to do my L2 next month as dual deployment. That will give me a more accurate expected height than I would have had without the measured data and not known the error in my Cd. Further, I plan to add a camera onboard for that flight as well as test out a Kalman filter for estimating and smoothing terms out during flight for parachute deployment. This will also be necessary for future projects I plan to do such as a targeted landing with parafoil deployment.