steeman.be

For a little over two years I have been building a rocket motor of my own: a reloadable aluminium motor, 42 mm (1.65 in) across, that burns home-made RNX-71V epoxy propellant and is designed for about 400 Ns (90 lbf·s) of total impulse. That puts it in the I class, and it is where the name comes from: the I400. The project started on paper in September 2024. The casing and nozzle were turned in the autumn of that year, the first propellant was mixed in February 2025, and on 20 September 2025 the motor fired on the test stand. It worked, and when I took it apart the hardware could be used again as it was; only the liner and the O-rings need replacing. Since then the work has gone into making the grains better and more repeatable, and in October 2026 the next two sets of six grains came out of the moulds.

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.

In 2008 I built a load cell amplifier to capture the thrust curve of a rocket motor. It was a PIC with a 10-bit analogue-to-digital converter and an INA125 instrumentation amplifier, it enumerated as a COM port, and the data ended up in HyperTerminal and from there, by copy and paste, in an Excel sheet. Two years later the Static Test Controller added chamber pressure and break wires to the same idea, and we used it for the Ballistic Evaluation Motor tests .

My son has to know 1051 Latin words. They come from the vocabulary list in the back of his school book, spread over seven caputs and 35 sections, and they arrive at the rate of a section or two per week. Flashcard apps exist, of course, but every one of them wants an account, a subscription, a phone in his hand and a network connection, three things I did not want in the same room as his homework.

In the previous post I showed you the wireless rocket launch controller I built for VRO , two ESP32-S3 units, an encrypted radio link, and a handful of relays between an operator’s thumb and a pyrotechnic igniter. That post was the what and the why. This one is the how: the functional design, the decisions everything else derives from, the firmware architecture, the full catalogue of safety measures, the radio protocol, the sensing and display internals, and how the whole thing was tested and built. It’s long. That’s the point.

The last time I built launch electronics for a rocket, it was 2008 and the brain of the thing was a PIC16F88 running a four-channel flight timer. Eighteen years later I found myself building something rather bigger: a two-unit, wireless launch controller for VRO, Vlaamse Raket Organisatie , built on a pair of ESP32-S3s, that sits between the LCO’s thumb and a pyrotechnic igniter. Over a radio link. That last part usually raises an eyebrow. Wireless and pyrotechnics sound like they belong in different rooms. But somewhere along this build I arrived at a counterintuitive position: done properly, a wireless link can be safer than a spool of copper, because you can’t trust a radio the way you lazily trust a wire. The wire invites you to assume safety. The radio forces you to design it.

A few weeks ago I vibecoded my first Fri3d Camp 2026 badge app , a hardware self-test screen. It was a great first project: it touched every part of the badge, and it was genuinely useful. But it was also a toy. It used the badge as a single device on my desk. The Fri3d badge has a property I wanted to use: roughly 700 people carry the same little computer at the same time, each with a screen, buttons, a battery, and a Bluetooth radio. One badge on a desk is a gadget. Seven hundred of them in a field is a network. So the next app had to do something with that.

I have written code before. Once upon a time I was even trained as a software developer, though I never ended up using that skill professionally. I do still write code and firmware now and then. But it takes time. And I’d never have justified spending much of it on a simple badge app. So when the new Fri3d Camp 2026 badge landed in my hands, I figured the really cool apps would have to come from someone with more time to spare.

The Fri3d Camp 2024 badge is an ESP32-S3, which makes it a first-class target for ESPHome , and therefore a native citizen of Home Assistant. This post documents a complete ESPHome configuration for the badge: which component drives each piece of hardware, the non-obvious choices that were required, and the entities that show up in Home Assistant once it is flashed. It is a companion to my earlier post on programming the badge with Claude Code ; that one covers the stock firmware and writing MicroPython apps, this one covers replacing the firmware with ESPHome.

Every Fri3d Camp hands out a badge, and the 2024 one is a serious little machine: an ESP32-S3 with a 2-inch colour LCD, five NeoPixels, a joystick, a buzzer, an IMU and a microSD slot, all in a Game-Boy-ish shell that boots straight into a retro game emulator. It’s a lovely object. But the thing that excited me most wasn’t playing Doom on it; it was the idea of writing my own software for it. And this time, rather than fighting datasheets alone, I paired up with Claude Code on the terminal.