How I Lost a Weekend to a Flight Controller (and Learned More Than I Planned To).

I assumed the flight controller would be the boring part of this build.

Pick a board, wire it up, flash ArduPilot, move on. I’ve spent years dealing with messy systems, ambiguous failures, and tools that don’t quite do what they promise. How hard could a small STM32-based autopilot really be?

That assumption lasted about thirty minutes.

The airframe is a Stallion fixed-wing UAV. Nothing exotic: ArduPlane, long endurance, digital FPV, ExpressLRS, Mission Planner on Windows. I started with a Mateksys F405-Wing because it’s widely recommended, compact, affordable, and—crucially—“ArduPilot compatible”.

That phrase turned out to be doing a lot of heavy lifting.

I plugged the board into USB and immediately fell into a strange half-working state. The red LED was solid, the blue LED blinked sometimes, Windows would occasionally make a USB sound, and Mission Planner showed absolutely nothing useful. No heartbeat. No horizon movement. No MAVLink connection. Just timeouts and cryptic errors about missing COM ports.

At first I assumed I’d wired something wrong, but the board was bare. No ESCs, no servos, no receiver. Just USB power. Still nothing.

This is where the first mistake surfaced, although I didn’t recognize it at the time. I had “installed” Mission Planner by downloading the ZIP and running it directly. It turns out the installer quietly sets up a whole collection of USB serial drivers and dependencies that you don’t think about until they’re missing. The ZIP version does none of that. So now I had a flight controller that might be in bootloader mode and a ground station that didn’t fully understand USB devices. Not a great combination.

Things got more interesting from there. At some point the Matek entered DFU mode permanently. Solid red and blue LEDs. Windows identified it as “STM32 BOOTLOADER”. Mission Planner couldn’t connect because there was no ArduPilot firmware actually running. Force bootloader didn’t help. Sometimes the board wouldn’t enumerate over USB at all.

If you’ve ever debugged an OS that boots the kernel but never reaches user space, it felt exactly like that. Something was alive, but not in a way that wanted to talk to me.

The documentation didn’t help as much as I expected. A lot of ArduPilot docs implicitly assume Pixhawk-style hardware. When a page says “plug in your autopilot and connect Mission Planner,” what it really means is “plug in a board that already has an ArduPilot bootloader, proper USB descriptors, and known-good firmware behavior.” The Matek technically supports ArduPilot, but it doesn’t behave like a Pixhawk during first bring-up. That difference isn’t obvious until you’re already stuck.

At peak confusion I asked myself a simple question: am I trying to learn flight control, or am I learning STM32 recovery procedures?

The honest answer was the second one.

There’s nothing wrong with that if your goal is firmware archaeology, but it wasn’t why I started this project. So I stopped being stubborn and switched to a Holybro Pixhawk 6C.

The difference was immediate and honestly a little shocking. I plugged it into USB, Windows created a COM port, Mission Planner connected instantly, the heartbeat appeared, and the horizon moved when I tilted the board. No DFU tools. No driver hacks. No rituals involving unplugging and replugging at exactly the right second.

That moment alone justified the decision.

What I learned from this detour is that “supported” does not mean “smooth.” Matek boards are powerful and flexible, but they assume you’re comfortable flashing firmware, dealing with DFU states, and recovering boards manually. Pixhawk boards optimize for predictable behavior and fewer failure modes, especially early in the build when everything else is still unknown.

I also learned that USB drivers are part of the system whether you like it or not. If your ground station isn’t installed properly, everything lies to you. COM ports flicker, errors look like hardware faults, and you end up chasing ghosts.

Do I regret starting with the Matek? Not really. I learned far more than I expected. But if your goal is to fly rather than reverse-engineer bootloaders, Pixhawk-class hardware earns its reputation.

Next time, I’ll still read the documentation. I’ll just read the installation section first.