PML Intruder Level 2 Certification Flight

On September 27, 2026, I flew my PML Intruder on a J motor at the Tripoli The Netherlands launch site near Exloo, and passed my Tripoli Level 2 certification. It’s the same rocket that got me my Level 1 certification in March, now with dual deployment, a camera section, and about two and a half times the total impulse.

What Level 2 Means

#

Level 1 allows H and I motors. Level 2 opens up J, K and L motors, up to 5,120 Ns of total impulse. To get there with Tripoli you need two things:

• A written exam on rocketry knowledge and the safety code.
• A successful certification flight on a J, K or L motor, with a safe recovery and a rocket that’s fit to fly again, observed by a Tripoli prefect.

I passed the written exam.

From L1 to L2: What Changed on the Rocket

#

The Intruder is still the same 80 mm (3.1 in) Public Missiles Ltd kit, with Quantum body tubes, fibreglass fins and a 38 mm (1.5 in) motor mount. For the L1 flight it had a single deployment: two parachutes on one shock cord, ejected at apogee. For L2 I made three changes:

1. Dual deployment. A drogue parachute comes out at apogee and the main much lower, so the rocket drops quickly through most of the descent and doesn’t drift far.
2. A camera section behind the nose cone.
3. A bigger motor: an AeroTech J instead of an H.

Before settling on the final layout, I modelled several variants in OpenRocket. One had the camera next to the avionics bay, one had the camera behind the nose cone, and two more added a set of canards up front. The canard version flew fine in simulation, but its stability margin dropped to 2.5 calibers and it added another thing that could go wrong. Winds were low on launch day, so I left the canards off.

The Camera Section

#

The camera section is a 250 mm (9.8 in) piece of body tube between the nose cone and the main parachute bay. It’s built around the 3D-printed module from my RunCam Thumb controller post : a green PLA housing with room for a 2S LiPo, a boost converter and the ESP32 controller, and a red aerodynamic fairing on the outside that holds the camera and looks down the side of the rocket.

The camera for the flight was a RunCam Thumb Pro W. In the final week before launch day I reprinted the camera bay, with the fairing as a separate part that bolts on.

In the end I didn’t fly the ESP32 controller. While testing, I noticed that the camera sometimes didn’t start recording on power-up, as it was programmed to. For the flight I connected the RunCam directly to an external LiPo through a screw switch instead.

Recovery System

#

The Eggtimer Proton from the L1 flight now drives four channels, set up as two redundant pairs:

All four ejection charges were 1.5 g of black powder, which made for a rather energetic deployment. The drogue is an 850 mm (33 in) chute in the lower body tube, pushed out by the kit’s piston. The main is a 48-inch (1.2 m) chute in the upper body tube, between the avionics bay and the camera section, and it has a piston of its own to push it out. The Vaisala RS41 radiosonde tracker I reprogrammed for the L1 flight went along again.

Simulation

#

The final OpenRocket model, with everything weighed:

The camera section and its hardware add weight up front, which is why the stability margin went from about 3 calibers on the L1 flight to nearly 5.

The Motor: AeroTech HP-J425R-14 DMS

#

I used a Disposable Motor System again, for the same reason as last time: nothing to assemble on launch day. The AeroTech J425R is a 38 mm (1.5 in) Redline motor:

• Total impulse: 677 Ns (J class)
• Average thrust: 417 N, peak 453 N
• Burn time: 1.6 seconds
• Thrust-to-weight: about 11:1

I flew the motor with its full ejection charge in and the 14-second delay unmodified, as a third layer of redundancy: if neither of the Proton’s drogue charges fired, or they didn’t manage to push the drogue out, the motor’s charge could still save the flight. Fourteen seconds after burnout is about 15.6 seconds after lift-off, well after the predicted apogee at 13.2 seconds, so the Proton’s charges should always go first.

Launch Day: September 27, 2026

#

It was a sunny day with little wind, which suited a rocket going up almost a kilometre (about 3,000 ft). We launched from a potato field that hadn’t been harvested yet, with permission from the five neighbouring farmers to fly over their land.

The prep table, above, has the fin can on the left, the J425R in its black casing, and the avionics bay with its blue 3D-printed end caps and yellow charge wells. The flight card is in the box at the bottom.

The Flight

#

The rocket left the rail at about 12:27. From the flight line, the J425R pushes it off the pad on a long white exhaust trail, and the camera follows it up until it disappears into the sky:

A phone at the foot of the launch rail, pointing up, caught the same moment from underneath. The Intruder sits on the rail, the pad disappears in smoke, and the rocket is already a flame at the top of the trail:

The Proton’s altitude log shows the whole flight. The time axis in this chart is corrected for the logger’s sample rate; see below .

All four charges fired and every parachute came out.

Simulation vs. Flight Data

#

This table puts the OpenRocket prediction next to what the Proton recorded. Speeds are also given in km/h, which is easier to picture than m/s. The last column corrects the Proton’s timestamps; the next section explains why that’s needed.

Apogee is within 1% of the prediction. The Proton reports 919 m (3,016 ft) as the peak, but that comes from a single-sample spike in the barometric data at the moment of an early deployment (more on that below ); the readings on either side level off at about 903 m (2,963 ft). Under the chutes, the rocket came down at about the speeds the model predicts. The main charges fired lower than in the model because I set the Proton to 600 ft (183 m) and 500 ft (152 m) rather than the model’s 200 m (656 ft). The model’s flight time is longer mainly because it has the rocket coming down more slowly under the drogue, at about 7 m/s (23 ft/s).

A Logger That Ran Slow

#

As logged, the timing looked badly wrong. The motor seemed to burn for only 0.97 seconds, the rocket seemed to reach apogee 5 seconds early, and its top speed came out at only 60% of the prediction. Yet the apogee altitude was spot on, and on both videos the motor clearly roars for the full 1.6 seconds.

The Proton logs two independent sensors, a barometer for altitude and an accelerometer, and on the logged time axis they disagree:

• The two speed estimates don’t agree. Speed worked out from the altitude readings came out much higher than speed integrated from the accelerometer. They only match if every logged time is multiplied by 1.67. That factor is the same at every point I checked, from 220 m/s (722 ft/s) all the way down to 60 m/s (197 ft/s). An error in the pressure reading caused by airflow would change with speed.
• The altitude readings show impossible braking. On the logged time axis, the rocket would have been slowing by 2 to 3.7 G during the coast, even at 40–60 m/s (130–200 ft/s), where drag is almost nothing and it should slow by about 1 G. The accelerometer shows the expected 1.0 to 1.6 G.

Multiplying the logged times by 1.67 fixes everything at once: burnout moves to 1.62 s, exactly the motor’s rated burn time; apogee moves to 13.2 s, exactly the simulation; and the top speed becomes 160 m/s (525 ft/s) against 161 m/s (529 ft/s) predicted.

The timestamps in the log go up in perfect 1/33 s steps, which matches the 33 samples per second I set for the launch phase. So the Proton appears to count samples and assume each one took 1/33 s, rather than timing them. 33 ÷ 1.67 means it actually managed about 20 samples per second. After nose-over it drops to 2 samples per second, and that part of the log looks right: the 10.6 m/s (35 ft/s) drogue descent is what an 850 mm (33 in) chute should give on a 3.4 kg rocket. Every event after nose-over is therefore shifted by a fixed 5.7 seconds, which is what the corrected column and the chart above show.

None of this affected the flight: the Proton deploys on altitude and on nose-over, not on time.

A Deployment Before Apogee

#

With the time axis corrected, one event in the log stands out. At 12.2 seconds after lift-off, about a second before apogee and while the rocket was still climbing, the accelerometer shows a sudden jolt of −6.3 G toward the tail. It eases back to the normal −1 G of the coast over about half a second. Together that takes roughly 10 m/s (33 ft/s) off the rocket’s speed, which is about all the upward speed it had left. The spike in the altitude readings that produced the 919 m (3,016 ft) “apogee” comes in the same sample. After that, the rocket hangs at the top, level within about a metre (3 ft), until the Proton detects nose-over two seconds later.

The zoomed view above shows seven seconds around apogee. The top panel is altitude and the bottom panel is acceleration, on the same corrected time axis. The jolt and the barometric spike line up in the same sample at 12.2 s, a second before apogee. The Proton’s two drogue charges follow at 14.2 and 14.7 s, once it has detected nose-over.

The Proton didn’t cause this. Its two drogue charges fired at 14.2 and 14.7 seconds, and the pad camera confirms that: its audio has two sharp bangs 0.45 seconds apart, arriving 2.6 seconds later, which is how long sound takes to come down from 900 m (2,950 ft). That also confirms the corrected time axis with a separate clock.

The most likely explanation is the motor’s own ejection charge. It should have fired 14 seconds after burnout, at about 15.6 seconds. The jolt came 10.6 seconds after burnout, about 3.4 seconds early. The shape of the jolt fits a separation: a sudden kick as the sections fly apart, which the Proton could easily miss at about 20 samples per second, followed by the yank of the shock cord going tight and the drag of the drogue. The audio is quiet at 15.6 seconds, where a charge fired on time would have been heard, so the motor charge had already gone.

So the drogue was already out when the Proton’s 1.5 g charges fired into an open bay. The rocket was only moving at about 10 m/s (33 ft/s) by then, so the early deployment did no harm. But the motor charge I added as the last line of backup ended up going first, before apogee.

Recovery

#

The RS41 kept sending positions until the rocket was almost on the ground, which made it easy to walk straight to it. It had landed in one piece, spread out along its shock cords: nose cone and camera section, main chute, avionics bay, drogue and fin can.

There was no damage: no zippering, no burned chutes, and the fins were fine. The only thing on them was some dirt from the field.

One disappointment: when I got home, the RunCam’s SD card was empty. The camera flew, but there’s no onboard video of the flight. After what I’d seen in testing, I should have checked on the pad that the camera was actually recording.

Certification Achieved

#

Steve, the Tripoli NL prefect, checked the flight and the recovered rocket and signed off my Level 2 certification. Many thanks to him and to Tripoli The Netherlands for another well-run launch day.

Resources

#

• PML Intruder Level 1 Certification Flight : the build of this rocket and its first flight
• Controlling a RunCam Thumb Camera with an ESP32-C3 : the camera module I designed for this rocket (the controller didn’t fly this time)
• Tripoli The Netherlands
• Tripoli Rocketry Association
• Eggtimer Rocketry — Proton flight computer
• OpenRocket
• AeroTech Division