UltraBip R: an alternative firmware nobody ask for | Details

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 same machine showed up. Within the next hour and a quarter it had found the cause, written a search over all baud rates, and a command that clears the module's backup. Both modules came back, and they still have their fast hot start.

The same evening, the new vario's motion sensor stopped answering, under our firmware only. The AI guessed a loose contact. I insisted it was software. Two hours of old builds later, it went back into the stock binary and found it: the original switches the sensor supply off and on at every boot. The new vario is a newer board revision and needs exactly that. My old one never cared.

It makes mistakes, and it makes them with a straight face. Had I simply followed its first opinion both times, I would have written off a GNSS module as dead and blamed a perfectly healthy sensor on the hardware. The technical judgement still has to come from the human holding the device. But once pushed in the right direction, it is very good at getting out of its own mistakes. I doubt I could have found either of these in a week, and I am fairly sure most embedded developers would not have done the whole thing in five days.

Zero lines read

I did not read or review a single line of the code. About 28,000 lines across firmware, web configurator and a log analyzer, in 96 commits, and I know them only from the outside: by what they do, how they sound, and what the logs say.

First it rebuilt what the stock firmware already does: the vario tones, the voice announcements, the IGC recording, the configuration, the app. Then the small things that had bothered me for years went in, one by one: short, quiet sounds instead of jingles, up to ten profiles with my own spoken names, and the algorithms got a second look, with the barometer and the motion sensor working together and a log analyzer to tune them on real flights. Whatever came to mind on the way went in too.