Intro

For a few years now, a small box on my harness has decided how my thermals sound. The Stodeus UltraBip is a lovely piece of hardware: an STM32WB55 with Bluetooth, a barometer, an IMU, a GNSS module, a piezo, a speaker and a solar cell, packed into something the size of a matchbox. I once opened it, looked at everything, and gave it a new voice (Custom voice for UltraBip variometer & teardown). The firmware stayed the way it was, and it was the small things that bothered me: long, loud jingles at every turn of the button, only three profiles, and algorithms that could do their job better.

This was meant as a small experiment: what happens if I let an AI (Claude Code) write the whole thing? The division of labour settled quickly. It reads, writes and builds. I decide what the device should do, hold it in my hand, test, measure, judge what comes back, and keep the whole thing on course. That last part turned out to need more backbone than expected.

What happened was five days, about 18 hours of the AI at work, and a vario that flies.

The device stayed closed

There is no source code, no schematic, and I did not want to attach a debugger. What I had was the Android app, which also ships firmware updates, my old teardown notes, and a backup of the SD card.

That turned out to be enough. The AI took the app apart, followed it to the firmware download, took the update file apart, and then read the stock firmware itself, instruction by instruction. Out came a pin map, the power-up sequences and the sleep modes. The first thing it wrote was not a vario but a small hardware check that asked me questions over USB: cover the solar cell, now hold it to the lamp, did you hear the speaker? I mostly stared at blinking LEDs. It worked anyway.

The screwdriver came out exactly once, to solder a wire to the battery for the power profiler. Everything else was learned from the outside, by the binary and by asking me what I heard.

Keeping the house rules

One rule from the start: never lose the way back. Our firmware goes in through the manufacturer's own bootloader, the same way an official update does, and the original goes back just as easily. On day two, the first real build hung on the spot. The bootloader's recovery function (hold the button, plug in USB) brought it back after a few nervous beeps. From then on I trusted it.

The other rule was: stay compatible. The original voice packs play, the original configuration is read, and the manufacturer's app pairs with a button press, reads the settings and writes new ones. I recorded the phone's Bluetooth traffic with the stock firmware, and the AI rebuilt the protocol from those captures and the decompiled app.

Finding what I would never have found

The GNSS chip is a Sony part, and its command set is not something you just find. The AI found it anyway, in the manual of a different module that uses the same chip, and with it ten position fixes per second instead of one. It found the stock firmware's own log files on the SD card, which told us more about the original than any document.

This is the part that still surprises me most. Not that it writes code quickly, but that it knows where to look.

The low point

On the way home from work, the GNSS went silent. The stock firmware, put back to check, said "GPS error, please contact support". Spare modules are not for sale anywhere. Hardware dies, I thought. So I bought a second vario at the flight school, checked it with the stock firmware, went flying, and put our firmware on. It found satellites. Then it went silent again.

That was 600 € of quiet GPS, and I was not polite about it. The AI had told me nothing in the GNSS commands had changed. Something had. The module keeps its own backup memory, and since we had switched it to the fast mode, it had saved the fast baud rate there too. It was not dead at all. It was talking at 460800 baud to everyone listening at 115200, the stock firmware included.

And then the other side of the...