September 16, 2025 • 14 mins
This week on Build, Create & Learn – A Maker’s Journey, I took a big step forward: moving my drone telemetry logger off the breadboard and into a real enclosure.
It wasn’t smooth sailing. Desoldering headers damaged some pads, wiring bugs kept piling up, and I spent hours chasing errors from the SD card, BME280, and GPS module. But after rerouting pins and rewriting code, I finally got the system logging properly again.
The real payoff? A short car test drive that produced my first dataset — GPS coordinates, speed, and altitude — all saved to the SD card. I visualized the track in JupyterLabs with Folium and GPX Studio, and it was incredibly satisfying to see the results line up with reality.
What you’ll hear in this episode:
- Why moving from breadboard to wires is never as easy as it looks
- The lessons I learned from desoldering headers and torn pads
- Debugging SD card, BME280, and GPS issues one by one
- Designing and 3D printing my first enclosure box
- Logging real data on a short test drive (instead of a flight)
- Visualizing GPS tracks and speed data in Jupyter
- Next steps: battery indicators, antennas, and the first drone flight
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 and Make a Journey.
I’m Stefan and today I want to share what was probably the most intense two weeks of this drone telemetry project so far.
Last time I wrapped up Episode 5 feeling like I was just one step away from flight testing my little logger.
(00:23):
I had the Federer RP2040 working with CircuitPython, I had the sensors reading out and SD card logging finally working reliably.
I thought the next step would be pretty simple, just drop everything into an enclosure and boom, first flight test.
Oh boy, how far I was from reality.
(00:43):
This episode is all about things that happened next.
Desoldering mistakes, debugging broken connections, redesigning my enclosure and finally the first real field test.
Not with the drone yet, but with my car.
And I have to say pulling that microSD card out afterwards and seeing real data was one of the most satisfying moments I’ve had in this whole project so far.
(01:08):
So let’s start at the beginning.
My first task was pretty straightforward.
Move my breadboard setup into something more permanent, no more floppy jumper wires.
I wanted to hardwire the connections so that I could actually mount the components into a box.
And right away I run into a problem.
(01:29):
All my breakout boards still had the standard pin headers soldered on.
That’s fine for breadboarding, but tried to mount these into an enclosure and it gets really messy.
So I decided I had to desolder the headers and go straight to wires.
That turns out to be way trickier than I thought.
My first attempt was to heat up the whole row of pins at once and just pull the headers out.
(01:53):
That didn’t work at all.
Then I tried adding more flux, hoping it would loosen things up, but I didn’t want to overheat the board and risk damaging it.
In the end the method that worked best was something I saw on YouTube.
Cut the headers into single pins, remove the plastic part and then desolder each pin one by one.
(02:14):
It’s a bit tedious, but it gets the job done.
Here’s the catch though.
I did a pretty poor job on my feta board.
Some pads were weakened, one even tore slightly and this came back haunt me later.
After that I moved on to the BME280 board and I was a bit more careful, but still far from perfect.
(02:36):
If I were to do this again I would take a different approach entirely.
Next time I would probably solder female sockets onto the perf boil and plug the breakout pins into that.
It’s cleaner, reversible and most importantly it avoids the risk of tearing up the pads on the microcontroller.
Lesson learned.
(02:56):
Now while I was doing all the desoldering I realized something else.
I was trying to hold the board with one of these cheap helping hand tools that came with my soldering iron kit.
You know those ones.
Tiny metal arms, wobbly base, a couple of alligator clips.
(03:17):
Every time I applied even the slightest bit of force the whole thing collapsed and shifted.
It was just nerve wrecking.
And it got me thinking.
This is a typical maker dilemma.
Do you keep struggling with cheap tools because they work very well or do you invest in something more robust that makes the work easier and less frustrating?
(03:38):
I am starting to think that for certain tasks like desoldering or rework having a solid fixture isn’t just deluxury.
It’s almost a necessity.
I haven’t found the perfect solution yet but I am on the lookout for something more stable and maybe there is something I will design myself one day.
A more robust maker proof helping hand.
(04:03):
Ok so back to the project.
Since the headers mostly removed I turned to the enclosure.
My original plan was to mount the boards on standoffs inside the case but once I tried it I realized it was getting too complicated so I pivoted to a much simpler design.
Just a plain rectangular box big enough to hold everything with a lid that fits snugly and screws down.
(04:27):
No hinges, no fancy mechanism.
Just a secure lid that won’t pop up mid-flight.
Sometimes simple is best.
I designed the box in CAD about 80 by 50 by 20mm, printed a few test versions and was actually really happy with the result.
The lid had a small ridge to slot in neatly and I added holes in two diagonal corners for threaded inserts and screws.
(04:54):
Already it felt much more solid than anything I’ve done before.
Now came the wiring part and if you ever move the project from breadboard to wires you will know this is where things can get messy.
On the breadboard everything looks neat and modular but the moment you replace jumper wires with solid connections the stakes get higher.
(05:20):
Every mistake is harder to fix.
I started out optimistic.
I used solid 22AWG wire, one component at a time, carefully moving my setup over from the breadboard.
First up was the BME280 sensor.
I kept the breadboard nearby for reference, basically mirroring the wiring as closely as possible.
(05:42):
Then I added the microSD breakout, then the GPS.
It looked pretty clean and I thought ok this isn’t so bad.
Then came the moment of truth.
I plugged the Feather into my computer and watched the serial console.
And boom.
OS error, no SD card.
At first I assumed I had to be something simple, maybe a cold solder joint.
(06:06):
So I checked the connections with my multimeter, reheated the pads with flux and tried again.
Same error, over and over.
This is where the process got tedious.
I would reflow a connection, test it, swap out the wire, test it.
Each time hoping the problem would magically vanish but nothing worked.
(06:27):
Finally I got out my magnifying glass and took a closer look at the Feather itself.
And that’s when I spotted it.
The pads for GPIO 18, the pin I was using for the SD card clock line, looked damaged.
The solder wasn’t just sticking well and the wires wobbled if I nudged it.
My earlier desoldering had weakened it more than I realized.
(06:50):
That was a gut punch moment.
It meant the problem wasn’t just the loose wire, it was the board itself.
And the fix.
Abandoning GPIO 18 entirely and reassigning the SPI lines to another pin.
So I rewired the SD card to D10, D11 and D12, updated the code and finally the SD card initialized.
(07:14):
That little victory felt huge.
But of course the celebration didn’t last long.
The next error popped up almost immediately.
Value error, no I2C device at address.
That was the BME280 sensor refusing to respond.
At first I thought maybe it was another damaged pad.
(07:36):
I ran an I2C scan on the REPL and got nothing.
An empty list.
No device found.
I grabbed my multimeter again and tested the SDA and SCL lines against 3 volts and see if there was a short.
Everything looked fine.
So I reflowed the solder joints with more flux just in case it was another cold joint.
(07:59):
Still no luck.
And here’s where I had to make a tough makers choice.
Keeping grinding on this one problem or step aside and try another part of the system.
I decided to put the BME280 aside for now and move on to the more important GPS.
Well, that didn’t go smoothly either.
(08:19):
The GPS didn’t throw a code error this time but the NeoPixel on the fader just blinked red.
Which basically means something is wrong.
It wasn’t getting a fix and the logger was just spitting out empty or zero values.
I tried adding more logging to the code so I could at least see what was happening behind the scenes.
(08:41):
The CSV file showed nothing but zeros.
So I stripped the GPS down to the basics and run a raw NMEA sniffer in the ripple.
The result?
Just a stream of zeros.
At that point I started to worry I had killed the GPS breakout too.
But then I checked the model itself, the onboard LED was blinking red.
(09:03):
Meaning it was alive, just not communicating with the fader.
Back to the magnifying glass and sure enough another pad looked dodgy.
This time it was one of the UART pins on the fader.
Another casualty of my not so great desordering job.
Honestly it felt like one step forward, two steps back.
(09:24):
So once again I rerouted.
I switched the GPS to a different UART port, figured out the right pin names, updated the code and suddenly there it was.
Real NMEA strings scrolling across the terminal.
Finally.
There was one more hiccup of course, an argument error in the time function, but the quick online search fixed that.
(09:47):
And with that the GPS was back online.
At the end of this Marathon debugging session I basically had the same functionality I had on the breadboard just in a wired version.
SD card working, GPS working, but the BME280 is still out of action.
It was frustrating, but also kind of liberating.
(10:08):
Because by this point I had accepted that this wasn’t about getting everything perfect the first time.
It was about moving the project forward, one working piece at a time.
With the wiring stabilized and the components in the enclosure, I was ready for my first real test.
(10:29):
The weather wasn’t great, lots of rain, so instead of mounting the unit on my drone, I decided to take it for a drive in my car.
I loaded everything into the box, drilled a small hole for the SME connector, so I could attach the external GPS antenna and powered it up.
blue LED for GPS fix, perfect.
(10:50):
The drive was short, maybe 5 kilometers, but I was glued to the speedometer the whole time, mentally noting the values so I could compare them with the locked data later.
Back home I popped out the microSD card, slid it into my computer, and opened the CSV file.
And then it was, timestamps, latitude, longitude, speed, altitude, real data captured with my own little logger.
(11:18):
That moment seemed the numbers on the screen was the payoff for all these hours of soldering, debugging and swearing at broken pads.
But raw CSV files aren’t that fun to look at.
I wanted to see if the data actually made sense, if the GPS coordinates really matched that route I’d driven, so I opened a Jupyter notebook and started experimenting.
(11:44):
I used the Folium package to plot the coordinates on an OpenStreetMap background, and suddenly the little route I’d driven showed up on the map, almost perfectly aligned.
It was a magical moment turning plain numbers into something visual and recognizable.
I also plotted speed over time and altitude over time.
(12:06):
That’s when I noticed something interesting.
There was a bit of noise in the altitude data and some fluctuation in speed that didn’t perfectly match my car’s speedometer.
That’s totally normal for GPS data of course, but it’s something I want to dig into more in the next steps.
Finally I exported the data as GPX file and loaded it into an online tool called GPX Studio.
(12:31):
That let me visualize the track in even more detail, almost like reliving the drive.
And honestly for a project that started with me just trying to blink an LED, seeing a real GPS track of my own test drive felt amazing.
So where do I go from here?
(12:53):
The big one is obvious, mounting the unit on the drone and collect real flight data.
But before I do that I want to improve a few things.
A battery level indicator would be super useful, as would be a cleaner way to mounting the GPS and LORI antennas.
And of course I need to fix and replace the BME to a Renate device so I can also get environmental data back into the mix.
(13:19):
Still I feel like I’ve hit a big milestone.
Even though this first test wasn’t in the air, the data showed that the system works and that means I’m a lot closer to my original goal of a Flight Ready telemetry logger.
So that’s where I leave it for today.
This episode was really about moving from a fragile breadboard stage into something more permanent and all the lessons that came with it.
(13:45):
If you would like to see the companion article including code snippets and some of the visualizations I’ve mentioned, head over to my site at hurdlebauer.com.
And of course if you want a weekly behind the scene peek at what I’m tinkering with projects that don’t always make it into the podcast, subscribe to my Makers Lockbook newsletter.
Thanks again for following along.
(14:08):
Let’s keep building, creating and learning together.
Hey everyone, welcome back to Build, Create & Learn and Make a Journey.
I’m Stefan and today I want to share what was probably the most intense two weeks of this drone telemetry project so far.
Last time I wrapped up Episode 5 feeling like I was just one step away from flight testing my little logger.
(00:23):
I had the Federer RP2040 working with CircuitPython, I had the sensors reading out and SD card logging finally working reliably.
I thought the next step would be pretty simple, just drop everything into an enclosure and boom, first flight test.
Oh boy, how far I was from reality.
(00:43):
This episode is all about things that happened next.
Desoldering mistakes, debugging broken connections, redesigning my enclosure and finally the first real field test.
Not with the drone yet, but with my car.
And I have to say pulling that microSD card out afterwards and seeing real data was one of the most satisfying moments I’ve had in this whole project so far.
(01:08):
So let’s start at the beginning.
My first task was pretty straightforward.
Move my breadboard setup into something more permanent, no more floppy jumper wires.
I wanted to hardwire the connections so that I could actually mount the components into a box.
And right away I run into a problem.
(01:29):
All my breakout boards still had the standard pin headers soldered on.
That’s fine for breadboarding, but tried to mount these into an enclosure and it gets really messy.
So I decided I had to desolder the headers and go straight to wires.
That turns out to be way trickier than I thought.
My first attempt was to heat up the whole row of pins at once and just pull the headers out.
(01:53):
That didn’t work at all.
Then I tried adding more flux, hoping it would loosen things up, but I didn’t want to overheat the board and risk damaging it.
In the end the method that worked best was something I saw on YouTube.
Cut the headers into single pins, remove the plastic part and then desolder each pin one by one.
(02:14):
It’s a bit tedious, but it gets the job done.
Here’s the catch though.
I did a pretty poor job on my feta board.
Some pads were weakened, one even tore slightly and this came back haunt me later.
After that I moved on to the BME280 board and I was a bit more careful, but still far from perfect.
(02:36):
If I were to do this again I would take a different approach entirely.
Next time I would probably solder female sockets onto the perf boil and plug the breakout pins into that.
It’s cleaner, reversible and most importantly it avoids the risk of tearing up the pads on the microcontroller.
Lesson learned.
(02:56):
Now while I was doing all the desoldering I realized something else.
I was trying to hold the board with one of these cheap helping hand tools that came with my soldering iron kit.
You know those ones.
Tiny metal arms, wobbly base, a couple of alligator clips.
(03:17):
Every time I applied even the slightest bit of force the whole thing collapsed and shifted.
It was just nerve wrecking.
And it got me thinking.
This is a typical maker dilemma.
Do you keep struggling with cheap tools because they work very well or do you invest in something more robust that makes the work easier and less frustrating?
(03:38):
I am starting to think that for certain tasks like desoldering or rework having a solid fixture isn’t just deluxury.
It’s almost a necessity.
I haven’t found the perfect solution yet but I am on the lookout for something more stable and maybe there is something I will design myself one day.
A more robust maker proof helping hand.
(04:03):
Ok so back to the project.
Since the headers mostly removed I turned to the enclosure.
My original plan was to mount the boards on standoffs inside the case but once I tried it I realized it was getting too complicated so I pivoted to a much simpler design.
Just a plain rectangular box big enough to hold everything with a lid that fits snugly and screws down.
(04:27):
No hinges, no fancy mechanism.
Just a secure lid that won’t pop up mid-flight.
Sometimes simple is best.
I designed the box in CAD about 80 by 50 by 20mm, printed a few test versions and was actually really happy with the result.
The lid had a small ridge to slot in neatly and I added holes in two diagonal corners for threaded inserts and screws.
(04:54):
Already it felt much more solid than anything I’ve done before.
Now came the wiring part and if you ever move the project from breadboard to wires you will know this is where things can get messy.
On the breadboard everything looks neat and modular but the moment you replace jumper wires with solid connections the stakes get higher.
(05:20):
Every mistake is harder to fix.
I started out optimistic.
I used solid 22AWG wire, one component at a time, carefully moving my setup over from the breadboard.
First up was the BME280 sensor.
I kept the breadboard nearby for reference, basically mirroring the wiring as closely as possible.
(05:42):
Then I added the microSD breakout, then the GPS.
It looked pretty clean and I thought ok this isn’t so bad.
Then came the moment of truth.
I plugged the Feather into my computer and watched the serial console.
And boom.
OS error, no SD card.
At first I assumed I had to be something simple, maybe a cold solder joint.
(06:06):
So I checked the connections with my multimeter, reheated the pads with flux and tried again.
Same error, over and over.
This is where the process got tedious.
I would reflow a connection, test it, swap out the wire, test it.
Each time hoping the problem would magically vanish but nothing worked.
(06:27):
Finally I got out my magnifying glass and took a closer look at the Feather itself.
And that’s when I spotted it.
The pads for GPIO 18, the pin I was using for the SD card clock line, looked damaged.
The solder wasn’t just sticking well and the wires wobbled if I nudged it.
My earlier desoldering had weakened it more than I realized.
(06:50):
That was a gut punch moment.
It meant the problem wasn’t just the loose wire, it was the board itself.
And the fix.
Abandoning GPIO 18 entirely and reassigning the SPI lines to another pin.
So I rewired the SD card to D10, D11 and D12, updated the code and finally the SD card initialized.
(07:14):
That little victory felt huge.
But of course the celebration didn’t last long.
The next error popped up almost immediately.
Value error, no I2C device at address.
That was the BME280 sensor refusing to respond.
At first I thought maybe it was another damaged pad.
(07:36):
I ran an I2C scan on the REPL and got nothing.
An empty list.
No device found.
I grabbed my multimeter again and tested the SDA and SCL lines against 3 volts and see if there was a short.
Everything looked fine.
So I reflowed the solder joints with more flux just in case it was another cold joint.
(07:59):
Still no luck.
And here’s where I had to make a tough makers choice.
Keeping grinding on this one problem or step aside and try another part of the system.
I decided to put the BME280 aside for now and move on to the more important GPS.
Well, that didn’t go smoothly either.
(08:19):
The GPS didn’t throw a code error this time but the NeoPixel on the fader just blinked red.
Which basically means something is wrong.
It wasn’t getting a fix and the logger was just spitting out empty or zero values.
I tried adding more logging to the code so I could at least see what was happening behind the scenes.
(08:41):
The CSV file showed nothing but zeros.
So I stripped the GPS down to the basics and run a raw NMEA sniffer in the ripple.
The result?
Just a stream of zeros.
At that point I started to worry I had killed the GPS breakout too.
But then I checked the model itself, the onboard LED was blinking red.
(09:03):
Meaning it was alive, just not communicating with the fader.
Back to the magnifying glass and sure enough another pad looked dodgy.
This time it was one of the UART pins on the fader.
Another casualty of my not so great desordering job.
Honestly it felt like one step forward, two steps back.
(09:24):
So once again I rerouted.
I switched the GPS to a different UART port, figured out the right pin names, updated the code and suddenly there it was.
Real NMEA strings scrolling across the terminal.
Finally.
There was one more hiccup of course, an argument error in the time function, but the quick online search fixed that.
(09:47):
And with that the GPS was back online.
At the end of this Marathon debugging session I basically had the same functionality I had on the breadboard just in a wired version.
SD card working, GPS working, but the BME280 is still out of action.
It was frustrating, but also kind of liberating.
(10:08):
Because by this point I had accepted that this wasn’t about getting everything perfect the first time.
It was about moving the project forward, one working piece at a time.
With the wiring stabilized and the components in the enclosure, I was ready for my first real test.
(10:29):
The weather wasn’t great, lots of rain, so instead of mounting the unit on my drone, I decided to take it for a drive in my car.
I loaded everything into the box, drilled a small hole for the SME connector, so I could attach the external GPS antenna and powered it up.
blue LED for GPS fix, perfect.
(10:50):
The drive was short, maybe 5 kilometers, but I was glued to the speedometer the whole time, mentally noting the values so I could compare them with the locked data later.
Back home I popped out the microSD card, slid it into my computer, and opened the CSV file.
And then it was, timestamps, latitude, longitude, speed, altitude, real data captured with my own little logger.
(11:18):
That moment seemed the numbers on the screen was the payoff for all these hours of soldering, debugging and swearing at broken pads.
But raw CSV files aren’t that fun to look at.
I wanted to see if the data actually made sense, if the GPS coordinates really matched that route I’d driven, so I opened a Jupyter notebook and started experimenting.
(11:44):
I used the Folium package to plot the coordinates on an OpenStreetMap background, and suddenly the little route I’d driven showed up on the map, almost perfectly aligned.
It was a magical moment turning plain numbers into something visual and recognizable.
I also plotted speed over time and altitude over time.
(12:06):
That’s when I noticed something interesting.
There was a bit of noise in the altitude data and some fluctuation in speed that didn’t perfectly match my car’s speedometer.
That’s totally normal for GPS data of course, but it’s something I want to dig into more in the next steps.
Finally I exported the data as GPX file and loaded it into an online tool called GPX Studio.
(12:31):
That let me visualize the track in even more detail, almost like reliving the drive.
And honestly for a project that started with me just trying to blink an LED, seeing a real GPS track of my own test drive felt amazing.
So where do I go from here?
(12:53):
The big one is obvious, mounting the unit on the drone and collect real flight data.
But before I do that I want to improve a few things.
A battery level indicator would be super useful, as would be a cleaner way to mounting the GPS and LORI antennas.
And of course I need to fix and replace the BME to a Renate device so I can also get environmental data back into the mix.
(13:19):
Still I feel like I’ve hit a big milestone.
Even though this first test wasn’t in the air, the data showed that the system works and that means I’m a lot closer to my original goal of a Flight Ready telemetry logger.
So that’s where I leave it for today.
This episode was really about moving from a fragile breadboard stage into something more permanent and all the lessons that came with it.
(13:45):
If you would like to see the companion article including code snippets and some of the visualizations I’ve mentioned, head over to my site at hurdlebauer.com.
And of course if you want a weekly behind the scene peek at what I’m tinkering with projects that don’t always make it into the podcast, subscribe to my Makers Lockbook newsletter.
Thanks again for following along.
(14:08):
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.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.