When the SD Card Won: Why I Switched to CircuitPython for My Drone Telemetry Project

Build, Create & Learn — A Maker’s Journey Episode 4. I’m happy to share the latest updates of my projects in my new podcast episode.

After two weeks of small wins, big frustrations, and lots of reflection, I’ve made a bold pivot in my drone telemetry project. If you’ve been following along, you know my goal is to log GPS data and environmental readings mid-flight. The GPS parser worked beautifully — but the SD card shield? That turned into a rabbit hole I couldn’t climb out of.

When the SD Card Won

My STM32 setup refused to cooperate with the Seeed Studio SD card shield. I tried everything: switching from SPI1 to SPI2, isolating peripherals, even stripping the code down to a bare minimum. Nothing worked. The deeper I dug into wiring quirks, clock mismatches, and 3.3V vs 5V logic levels, the more I realized something: I wasn’t learning anymore — I was just grinding.

That was my turning point.

Why CircuitPython Makes Sense

I know Python. I’ve built Django apps, APIs, and data pipelines with it. I can debug it. I can reason about it. And when I discovered how mature the CircuitPython ecosystem has become — with ready-to-use libraries for GPS modules, BME280 sensors, and SD card logging — it clicked.

This wasn’t about “taking the easy way out.” It was about choosing the right tool for my maker workflow.

I’m not building production-grade firmware where every byte of RAM matters. I’m prototyping, experimenting, and trying to actually finish projects. CircuitPython lets me move forward instead of getting stuck.

The Hardware Pivot

Along with the language shift came a hardware change. I ordered the Adafruit Feather RP2040, a small, Python-friendly board with great documentation. Even better, Adafruit makes an “Adalogger” version with built-in SD support (sadly out of stock for now) that’s basically designed for my use case: collecting sensor data and logging it to an SD card.

For stability, I’ll need to move beyond breadboards. I’m still debating between soldering to a protoboard or jumping straight into designing my first PCB. Either way, the goal is the same: a flight-ready telemetry unit that can survive real-world testing on a drone.

Lessons Learned

Looking back, this project reminded me of something important:

Choosing the right tool for you isn’t a shortcut — it’s the difference between finishing a project and abandoning it.

Yes, I could have kept wrestling with STM32 and C, but I know myself. My shelf of “almost finished” projects is already too full. This time, I want a working prototype, even if it means pivoting the tech stack.

What’s Next

My immediate goals:

• Set up CircuitPython on the RP2040
• Reconnect the GPS and BME280 sensors
• Try SD logging again with a reliable Adafruit breakout

If all goes well, I’ll finally have a stable base for testing my telemetry system under real flight conditions.

🎧 Want the full story — including my GPS parser setup, external antenna tests, and the thought process behind this pivot?
Listen to Podcast Episode 4: When the SD Card Won… and Why I’m Switching to CircuitPython for My Drone Telemetry.

Have you ever had to make a hard pivot in your own projects — switching tools, languages, or hardware? Drop a comment below, I’d love to hear your story.

Let’s keep building, creating, and learning — together.