August 19, 2025 • 11 mins
This week on Build, Create & Learn – A Maker’s Journey, I hit a wall with my STM32 drone telemetry project. My GPS parser worked beautifully, but the SD card shield? Not so much. After days of debugging SPI conflicts, wiring quirks, and endless C/C++ frustration, I had to face a tough question: keep grinding, or pivot to a tool that actually fits my maker workflow?
In this episode, I share the full story of why I’m switching from STM32 and C to CircuitPython on the RP2040 for my drone telemetry logger. We’ll talk about NMEA strings (RMC & GGA), testing external GPS antennas, and the lessons I learned from failing at SD card logging. More importantly, I’ll reflect on the maker’s mindset: knowing when to push through and when to change tools so you can keep learning, building, and actually finish projects.
What you’ll hear in this episode:
- How I parsed GPS NMEA data (RMC & GGA) and added a motion filter
- Why my STM32 + SD card shield setup refused to cooperate
- The moment I realized C wasn’t helping me move forward
- Why CircuitPython + RP2040 is the better fit for my telemetry project
- My next steps: reconnecting sensors, logging to SD, and moving toward a flight-ready prototype
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Hey everyone, welcome back to Build, Create & Learn A Maker’s Journey.
I’m your host Stefan and today’s story is a mix of wins, frustrations, and a big decision that I think will shape how I work on this drone telemetry project and maybe even how I approach projects in general.
(00:21):
If you’ve been following it along, you know I’m building a telemetry system for my FPV drone.
The idea is simple enough.
I’ll log environmental reading and GPS position during flight so I can analyze them later.
In the last episode we finally got GPS data flowing.
The next step sounds straightforward.
Passing the data and then saving it to an SD card.
(00:43):
Of course that’s not exactly how things went.
Part 1 A solid win.
My GPS parser works.
Let’s start with the good news because there was some.
I got my GPS parser working and it’s actually doing exactly what I want.
Right now I’m passing two specific NMEA sentence types.
(01:07):
RMC and GGA.
If you’re new to GPS data, NMEA sentences are lines of text that the GPS model sends out usually every second.
Think of them as little status reports.
GGA is a global position system fixed data.
It tells you things like the exact time, your latitude, longitude, the quality of the GPS fix, how many satellites are locked in and your altitude.
(01:34):
RMC is recommended minimum navigation information.
That’s where you get your time, position, speed, over ground and heading.
Between these two you basically have all the core information needed for a flight log.
Where you were, when you were there and how you were moving.
I also added a motion threshold to the code so the system only locks when you’re actually moving.
(01:57):
This helps filters out little jumps and wobbles GPS can sometimes report when you’re still in the steel.
And here’s another win.
I tested my new external active GPS antenna and the difference was night and day.
With the internal antenna my readings were constantly about 160 meters off from the actual position.
(02:17):
With the external antenna the offset was gone and I had a solid fix with at least 5 satellites.
I still had to be near a window but the accuracy was exactly where I wanted it to be.
These moments when something actually works better than you expected are what keeps you going on projects like this.
Part 2 - The SD card saga.
(02:42):
Now for the part that didn’t go so smoothly logging the data on the SD card.
I’m using a Seeed Studio Arduino SD card shield.
On paper it’s simple.
Plug it in, talk to it over SPI, that’s the serial peripheral interface bus and start saving files.
In reality nothing worked.
I started with the most obvious setup.
(03:04):
Mounting the shield directly on the Arduino compatible socket on my STM32 development board.
When I realized it was expecting to use the SPI-1 but SPI-1 on my board was already tied up by the onboard LED and the SWD debug board.
Quick beginner note SPI is like a little high speed data highway that lets your microcontroller talk to peripherals like SD cards.
(03:32):
But you only have so many lanes and exits and if one’s already taken you can’t just plop another device onto it without causing a traffic jam.
So I tried using jumper wires to connect the shield to different pins.
Still no luck.
Then I decided to move everything to SPI-2 and put the shield back directly onto the board.
(03:53):
Nope.
At this point I was suspicious of everything.
Maybe the other sensors GPS, BME280 were interfering, maybe my code was too messy so I stripped the setup down to just the SD card and the microcontroller.
Started a brand new project in the IDE with minimal code and still nothing.
(04:14):
I went through every possible culprit.
Voltage mismatch, was it a 5V vs 3.3V logic level thing?
Flaky chip select pin, noisy power, wrong SPI mode, clock mismatch, some obscure library incompatibility.
Maybe it could have been any one of them or worse a combination of several.
(04:39):
Part 3 When the code isn’t yours.
Here’s the truth.
I can write some C and C++ but with this project I’ve been heavily relying on JetGPD to generate some example code.
And that’s fine until something goes wrong.
And the code didn’t work I often wasn’t confident enough in C to know the right next debugging step.
(05:02):
That’s a tough place to be in because instead of making informed changes I was just throwing ideas at the wall and see what stuck.
In Python I know the syntax, I know the libraries and I can debug efficiently.
In C I was spending most of my mental energy just trying to understand the code in front of me not solving the actual problem.
(05:22):
And then it hit me.
I was on the verge of turning this fun experimental build into a tedious grind.
And I have been there before.
Shelfs full of projects that are 80% done but never finished because the fun got replaced by frustration.
Part 4 The Maker’s period.
(05:43):
That’s when I revisited MicroPython and CircuitPython.
For those who haven’t heard of them there are versions of Python that run directly on microcontrollers.
They are slower than C, sure, but they are much easier to work with if you already know Python and especially in the prototyping phase.
And I know Python, I’ve built web apps, APIs and data pipelines, even some automation scripts for my workshop.
(06:06):
I’m comfortable there and when I looked into CircuitPython’s library ecosystem I saw ready to use well documented modules for my GPS, for my BME280 and yes for an SD card.
So I made the call.
I’m switching to CircuitPython.
Not because I gave up on C but because I wanted to finish this project.
(06:27):
I’m not building a flight computer for a commercial airliner, I’m building a Maker’s prototype.
My goal is to prove the concept, test it in the air and move on to the next idea.
If I ever needed the absolute fastest, most memory efficient version I can always rewrite critical parts in C later.
Part 5 New hardware and hardware.
(06:50):
Here’s my new energy.
Once I made that decision the hardware choice becomes obvious.
The STM32 board is great but it’s not exactly designed for CircuitPython.
So I ordered an Adafruit Feather RP2040, a small, efficient, Python friendly board with great documentation.
(07:11):
While browsing I’ve found the Adafruit Feather RP2040 Adalogger.
Basically my dream telemetry board completed with built in microSD support.
Naturally it’s out of stock but just knowing it exists confirms my approach makes sense.
I also ordered an Adafruit SD breakout board that’s known to play nicely with CircuitPython.
(07:33):
If this works I will be back there where I wanted to be weeks ago but without fighting the language the whole way.
Part 6 Thinking about the bill.
There is another decision upcoming.
How to package the prototype for testing.
I could keep it on a breadboard, throw it into an enclosure and call it a day.
(07:56):
Or I could try solder it to a protoboard or even design my own PCB.
Even if the PCB isn’t perfect it would be an amazing learning experience.
And here’s the practical side of it.
Since I still plan to test my device on a drone under real conditions it needs to be stable and mounted well.
I don’t think the breadboard in the enclosure will be a good solution here.
(08:19):
Vibrations, loose wires and sudden landings all of that can ruin a test flight if the hardware isn’t locked down.
Designing a PCB feels intimidating but I know it would force me to think more carefully about the layout, connections and long time durability.
It would also open up skills I could reuse for future projects.
(08:42):
Part 7 The bigger reflection.
Here’s the bigger lesson I’m taking away.
Choosing the right tool for your style is not cheating.
It’s smart.
For years I thought pushing through with the hard tool made me a better maker.
But the truth is making isn’t about suffering through the process.
It’s about finishing, learning and moving on to the next challenge with more skills than you had before.
(09:06):
This decision to switching is about momentum.
It’s about keeping the project fun and engaging because that’s what fuels creativity.
If I’m dreading every work session the project dies.
If I’m excited to sit down and make progress it lives.
And maybe that’s the part of the maker’s mindset we don’t talk about enough.
It’s not just about problem solving in a technical sense.
(09:28):
It’s problem solving in how we approach projects.
Knowing when to pivot is just as valuable as knowing how to solder or code.
Part 8 What’s next?
Before the next episode my plan is to first set up CircuitPython on the RP2040, second reconnect the BME280 and GPS sensor and third trying SD login again with the new breakout board.
(09:56):
Best case I will have a fully working prototype logging both GPS and environmental data.
Best case I will have at least a new platform that feels like a natural extension of my skills.
One I can debug without headaches.
After that I will start thinking seriously about the physical design.
Whether it’s a protoboard build or my first custom PCB.
(10:19):
The goal will be the same.
A stable flight ready telemetry unit.
Part 9 Closing Thoughts So that’s where I’m at.
Two weeks of mixed results.
One working GPS parser, one stubborn SD card and one big decision that I think will save the project.
I’m leaving the frustration behind and leaning into a language and workflow that I know will let me keep moving.
(10:44):
If you have ever had to make a hard pivot in a project whether it’s changing tools, materials or even the end goal I would love to hear about it.
Drop me a message, connect on social or please leave a comment.
If you like hearing about my project you will love the Makers Lockbook, a weekly behind the scene email newsletter.
Thanks for listening to Build, Create & Learn and Makers Journey.
(11:05):
And if you enjoy following along the ups and downs, the aha moments, please subscribe wherever you get this podcast.
Let’s keep building, creating and learning together.
Hey everyone, welcome back to Build, Create & Learn A Maker’s Journey.
I’m your host Stefan and today’s story is a mix of wins, frustrations, and a big decision that I think will shape how I work on this drone telemetry project and maybe even how I approach projects in general.
(00:21):
If you’ve been following it along, you know I’m building a telemetry system for my FPV drone.
The idea is simple enough.
I’ll log environmental reading and GPS position during flight so I can analyze them later.
In the last episode we finally got GPS data flowing.
The next step sounds straightforward.
Passing the data and then saving it to an SD card.
(00:43):
Of course that’s not exactly how things went.
Part 1 A solid win.
My GPS parser works.
Let’s start with the good news because there was some.
I got my GPS parser working and it’s actually doing exactly what I want.
Right now I’m passing two specific NMEA sentence types.
(01:07):
RMC and GGA.
If you’re new to GPS data, NMEA sentences are lines of text that the GPS model sends out usually every second.
Think of them as little status reports.
GGA is a global position system fixed data.
It tells you things like the exact time, your latitude, longitude, the quality of the GPS fix, how many satellites are locked in and your altitude.
(01:34):
RMC is recommended minimum navigation information.
That’s where you get your time, position, speed, over ground and heading.
Between these two you basically have all the core information needed for a flight log.
Where you were, when you were there and how you were moving.
I also added a motion threshold to the code so the system only locks when you’re actually moving.
(01:57):
This helps filters out little jumps and wobbles GPS can sometimes report when you’re still in the steel.
And here’s another win.
I tested my new external active GPS antenna and the difference was night and day.
With the internal antenna my readings were constantly about 160 meters off from the actual position.
(02:17):
With the external antenna the offset was gone and I had a solid fix with at least 5 satellites.
I still had to be near a window but the accuracy was exactly where I wanted it to be.
These moments when something actually works better than you expected are what keeps you going on projects like this.
Part 2 - The SD card saga.
(02:42):
Now for the part that didn’t go so smoothly logging the data on the SD card.
I’m using a Seeed Studio Arduino SD card shield.
On paper it’s simple.
Plug it in, talk to it over SPI, that’s the serial peripheral interface bus and start saving files.
In reality nothing worked.
I started with the most obvious setup.
(03:04):
Mounting the shield directly on the Arduino compatible socket on my STM32 development board.
When I realized it was expecting to use the SPI-1 but SPI-1 on my board was already tied up by the onboard LED and the SWD debug board.
Quick beginner note SPI is like a little high speed data highway that lets your microcontroller talk to peripherals like SD cards.
(03:32):
But you only have so many lanes and exits and if one’s already taken you can’t just plop another device onto it without causing a traffic jam.
So I tried using jumper wires to connect the shield to different pins.
Still no luck.
Then I decided to move everything to SPI-2 and put the shield back directly onto the board.
(03:53):
Nope.
At this point I was suspicious of everything.
Maybe the other sensors GPS, BME280 were interfering, maybe my code was too messy so I stripped the setup down to just the SD card and the microcontroller.
Started a brand new project in the IDE with minimal code and still nothing.
(04:14):
I went through every possible culprit.
Voltage mismatch, was it a 5V vs 3.3V logic level thing?
Flaky chip select pin, noisy power, wrong SPI mode, clock mismatch, some obscure library incompatibility.
Maybe it could have been any one of them or worse a combination of several.
(04:39):
Part 3 When the code isn’t yours.
Here’s the truth.
I can write some C and C++ but with this project I’ve been heavily relying on JetGPD to generate some example code.
And that’s fine until something goes wrong.
And the code didn’t work I often wasn’t confident enough in C to know the right next debugging step.
(05:02):
That’s a tough place to be in because instead of making informed changes I was just throwing ideas at the wall and see what stuck.
In Python I know the syntax, I know the libraries and I can debug efficiently.
In C I was spending most of my mental energy just trying to understand the code in front of me not solving the actual problem.
(05:22):
And then it hit me.
I was on the verge of turning this fun experimental build into a tedious grind.
And I have been there before.
Shelfs full of projects that are 80% done but never finished because the fun got replaced by frustration.
Part 4 The Maker’s period.
(05:43):
That’s when I revisited MicroPython and CircuitPython.
For those who haven’t heard of them there are versions of Python that run directly on microcontrollers.
They are slower than C, sure, but they are much easier to work with if you already know Python and especially in the prototyping phase.
And I know Python, I’ve built web apps, APIs and data pipelines, even some automation scripts for my workshop.
(06:06):
I’m comfortable there and when I looked into CircuitPython’s library ecosystem I saw ready to use well documented modules for my GPS, for my BME280 and yes for an SD card.
So I made the call.
I’m switching to CircuitPython.
Not because I gave up on C but because I wanted to finish this project.
(06:27):
I’m not building a flight computer for a commercial airliner, I’m building a Maker’s prototype.
My goal is to prove the concept, test it in the air and move on to the next idea.
If I ever needed the absolute fastest, most memory efficient version I can always rewrite critical parts in C later.
Part 5 New hardware and hardware.
(06:50):
Here’s my new energy.
Once I made that decision the hardware choice becomes obvious.
The STM32 board is great but it’s not exactly designed for CircuitPython.
So I ordered an Adafruit Feather RP2040, a small, efficient, Python friendly board with great documentation.
(07:11):
While browsing I’ve found the Adafruit Feather RP2040 Adalogger.
Basically my dream telemetry board completed with built in microSD support.
Naturally it’s out of stock but just knowing it exists confirms my approach makes sense.
I also ordered an Adafruit SD breakout board that’s known to play nicely with CircuitPython.
(07:33):
If this works I will be back there where I wanted to be weeks ago but without fighting the language the whole way.
Part 6 Thinking about the bill.
There is another decision upcoming.
How to package the prototype for testing.
I could keep it on a breadboard, throw it into an enclosure and call it a day.
(07:56):
Or I could try solder it to a protoboard or even design my own PCB.
Even if the PCB isn’t perfect it would be an amazing learning experience.
And here’s the practical side of it.
Since I still plan to test my device on a drone under real conditions it needs to be stable and mounted well.
I don’t think the breadboard in the enclosure will be a good solution here.
(08:19):
Vibrations, loose wires and sudden landings all of that can ruin a test flight if the hardware isn’t locked down.
Designing a PCB feels intimidating but I know it would force me to think more carefully about the layout, connections and long time durability.
It would also open up skills I could reuse for future projects.
(08:42):
Part 7 The bigger reflection.
Here’s the bigger lesson I’m taking away.
Choosing the right tool for your style is not cheating.
It’s smart.
For years I thought pushing through with the hard tool made me a better maker.
But the truth is making isn’t about suffering through the process.
It’s about finishing, learning and moving on to the next challenge with more skills than you had before.
(09:06):
This decision to switching is about momentum.
It’s about keeping the project fun and engaging because that’s what fuels creativity.
If I’m dreading every work session the project dies.
If I’m excited to sit down and make progress it lives.
And maybe that’s the part of the maker’s mindset we don’t talk about enough.
It’s not just about problem solving in a technical sense.
(09:28):
It’s problem solving in how we approach projects.
Knowing when to pivot is just as valuable as knowing how to solder or code.
Part 8 What’s next?
Before the next episode my plan is to first set up CircuitPython on the RP2040, second reconnect the BME280 and GPS sensor and third trying SD login again with the new breakout board.
(09:56):
Best case I will have a fully working prototype logging both GPS and environmental data.
Best case I will have at least a new platform that feels like a natural extension of my skills.
One I can debug without headaches.
After that I will start thinking seriously about the physical design.
Whether it’s a protoboard build or my first custom PCB.
(10:19):
The goal will be the same.
A stable flight ready telemetry unit.
Part 9 Closing Thoughts So that’s where I’m at.
Two weeks of mixed results.
One working GPS parser, one stubborn SD card and one big decision that I think will save the project.
I’m leaving the frustration behind and leaning into a language and workflow that I know will let me keep moving.
(10:44):
If you have ever had to make a hard pivot in a project whether it’s changing tools, materials or even the end goal I would love to hear about it.
Drop me a message, connect on social or please leave a comment.
If you like hearing about my project you will love the Makers Lockbook, a weekly behind the scene email newsletter.
Thanks for listening to Build, Create & Learn and Makers Journey.
(11:05):
And if you enjoy following along the ups and downs, the aha moments, please subscribe wherever you get this podcast.
Let’s keep building, creating and learning together.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
My Favorite Murder with Karen Kilgariff and Georgia Hardstark
My Favorite Murder is a true crime comedy podcast hosted by Karen Kilgariff and Georgia Hardstark. Each week, Karen and Georgia share compelling true crimes and hometown stories from friends and listeners. Since MFM launched in January of 2016, Karen and Georgia have shared their lifelong interest in true crime and have covered stories of infamous serial killers like the Night Stalker, mysterious cold cases, captivating cults, incredible survivor stories and important events from history like the Tulsa race massacre of 1921. My Favorite Murder is part of the Exactly Right podcast network that provides a platform for bold, creative voices to bring to life provocative, entertaining and relatable stories for audiences everywhere. The Exactly Right roster of podcasts covers a variety of topics including historic true crime, comedic interviews and news, science, pop culture and more. Podcasts on the network include Buried Bones with Kate Winkler Dawson and Paul Holes, That's Messed Up: An SVU Podcast, This Podcast Will Kill You, Bananas and more.
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.