August 5, 2025 • 12 mins
Ever wish you could ditch that annoying USB cable while working on your microcontrollers? In this episode, I share how I finally untethered my embedded development board using a Raspberry Pi – a real game-changer for my workflow!
Then, we dive into the exciting world of GPS for my FPV drone telemetry system. Join me as I recount the struggles (C++ library headaches and mysterious scrambled data) and the triumphs of getting the MTK3339 GPS sensor talking to my STM32. You'll hear about the detective work to find the right pins, the debugging breakthroughs, and the sheer excitement of finally getting a solid satellite fix.
It's an honest look at the real-world challenges and rewarding "aha!" moments of building complex systems. Tune in to hear the full story and what's next for our drone telemetry project!
In this episode, you'll discover:- My new wireless embedded programming setup
- The unexpected hurdles of integrating the MTK3339 GPS sensor
- My debugging journey to finally get clean NMEA data.
- The thrill of achieving a satellite fix and verifying my location
- A sneak peek at future plans for better accuracy and data logging.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Hi everyone and welcome back to Build, Create and Learn a Maker’s Journey.
I’m your host Stefan and I’m really excited to dive into Episode 3 with you today.
If you are being following along you know that we are on a mission to build the custom FPV drone telemetry system.
(00:20):
In our last episode we celebrated some big wins, getting the STM32 Cube IDE setup, restling with some small printfbox and finally seeing real world datastream from our BME 280 environmental sensor.
It was a journey of small victories and it really sets the stage for what’s next.
But before we jump into the main event, getting GPS data, I want to talk about something that have been a bit of a nagging problem for me and honestly a game changer for my entire embedded development workflow.
(00:51):
It’s about breaking free from the USB cable.
As an embedded system enthusiast I like to think around with microcontrollers but there is always that one inescapable truth.
You need a physical USB cable.
It connects your powerful development environment directly to the embedded hardware, letting you flash new firmware and debugging that tricky sensor issues.
And here’s the truth, that physical bonds severely limit my flexibility.
(01:15):
I love working from different spots, sometimes from my desk, sometimes from the bed or sometimes out in the garden.
Even needing to flash new firmware or debug a sensor but your dev board is stuck in the workshop.
Or perhaps you are like me constantly on the go with a mobile laptop, plugging and unplugging totally disrupts your flow.
It felt like I was constantly tied up to a leash similar to my old issue with the SSD mount which you can read about on my blog.
(01:43):
This nagging problem kept bugging me.
How could I break free?
I want to work remotely independent of where the hardware actually sets.
Sure, if I am fiddling with buttons or making visible connections, I still need to be next to the board.
But for much of what I do, grabbing sensor data, optimizing internal algorithms or fine tuning low level drivers, the board could generally be anywhere.
(02:06):
That’s when I decided to dive deep into this making embedded programming over network, a reality for my setup.
And the star of this solution?
A trusty Raspberry Pi.
This wireless setup makes development so much more comfortable because it eliminates tangible cables, let me work from the couch and allows for quick reflashing without physically moving to the board.
(02:28):
It truly is a game changer for my workflow.
I have already documented the entire process including the dead ends in a detailed article that will be released soon on my blog.
That article will cover all the nitty gritty setup and configuration details for the Raspberry Pi solution.
This episode will serve as a high level overview, giving you a sneak peek into how I finally unthedered my development board.
(02:51):
Ok, with that exciting detour out of the way, let’s get back to our drone telemetry system.
The main component for this episode is the GPS sensor, the MTK3339.
Part 1 - The Initial Hurdles with Tackling the GPS Sensor So I started with any good maker does, reading the documentation.
(03:16):
I grabbed the EdoFruit breakout board documentation for the MTK3339.
It was really a nice introduction to the component and its basic functionality and it gave me the first steps into understanding GPS data.
I learned about the chipset, its impressive sensitivity and its ability to update 10 times a second.
I also discovered its output data in the standard NMEA 0183 format and that its default board rate is 9600.
(03:43):
What really surprised me though, were the features I wasn’t even aware of when I bought it, built in data login and support for an external active antenna.
That was a pleasant bonus, especially for future drone use.
The introduction of NMEA string was particularly helpful.
Understanding the scripted clients of text is key of getting useful data.
(04:03):
My first instinct to establish communication with the sensor was to try and use the comprehensive EdoFruit library.
I meant why reinvent the wheel, right?
The examples were all focused on the Arduino IDE and how to program it with an Arduino.
I tried to add the library to my STM32 project but I quickly hit the wall.
I realized that the library was written in C++ and my project was in C.
(04:27):
Now there are definitely similarities between the two languages and you can often mix them but I quickly understood that I wasn’t fluent enough in both to handle that properly.
It was a humbling moment realizing I knew some basics but needed to really freshen up my knowledge on the integrated details of each language.
I want to master them along the way but it’s clearly needed more effort and time than I had for this specific task.
(04:51):
So I looked online for others who had worked with the MTK3339 and the STM32.
I found an example that was built on the MBed library.
The source files seemed somewhat understandable and I thought great, I can integrate this easily into my project but I was wrong again.
The library was also written in C++ and converting it was also very unsuccessful.
(05:13):
I even considered converting my entire project to C++ to utilize this library.
I thought after hours of trying to get the files to build, hitting linker errors and complex class structures I couldn’t resolve, I changed my approach.
It was a classic make-up pivot.
Sometimes the path you think it’s easier turns out to be the dead end and you just have to step back and try something completely different.
(05:39):
R2, UART and the first terminal string.
My new approach was to start from scratch, aiming for the absolute minimal working setup, just establish a simple serial connection to the sensor.
In my STM32 pinout configuration I noticed that UART1 was already pre-configured by my development board.
(06:03):
My first thought was "perfect, I will just use that".
But then a bit of skepticism creeped in.
Why was it pre-configured?
Was it already being used by something else?
This led me down the rapid hole of detective work.
I started reading about common issues with UART ports and then dug deeper into the user manual of my specific nuclear development board.
(06:24):
There it was, described nicely and explained exactly how the STM link debugger on my board was connected to the STM32 chip.
And sure enough, my concern was correct, UART1 was indeed being used as a serial COM port for the STM link debugger, which is how my laptop communicates with the board.
With that information it was crystal clear that I had to switch to another available UART port.
(06:49):
So, I activated the UART2 port on pins 9 and 10, which meant I had to slightly adjust the physical wiring on the GPS breakout board to my deafboard pins.
With this new UART port configured, I had compile and code and it ran on the board.
But I still didn’t get any output on my laptop.
My immediate thought was, is the board still not working or is my code wrong?
(07:13):
But then I remembered, I need a serial terminal to see the actual connection coming from the debugger’s COM port.
After some quick research, I figured out how to set it up this terminal directly in my STM32Cube IDE.
And wouldn’t you know it, when I connected, there was some output.
But it was cryptic, scrambled and definitely not what I was expecting.
(07:36):
First I was just happy to see any response in the terminal at all.
But after the initial excitement, I realized, those look really off.
They were fragmented and didn’t look correct at all.
My first idea was to ask JetJGPD if it could figure out and identify the issue.
I checked all the recommendations, board rate of the GPS model, board rate of my serial communication and the wiring.
(07:59):
Everything looked fine.
But the output was still garbage.
So I tried two more things.
And one of them, or perhaps both, solved the issue.
First I double checked the pinout configuration again and pinned the connections for pin 9 and 10 and then recompiled it.
I also changed the main loop function where I was forwarding the serial response from UART2, the GPS model, to UART1.
(08:21):
The debugger and my laptop.
I switched to a simpler UART receive and UART transmit approach.
This resulted in a proper readable response in the terminal.
And there it was, my first NMEA string.
Part 3 - The Satellite Fix and Verification Seeing those NMEA strings was a huge step.
(08:47):
But the critical part for GPS is getting a fix on a satellite.
I quickly learned to look for specific indicators in the NMEA string.
GPRMC A, so where the A means a valid fix.
And the GPPP A1, where 1 stands for the fix of the quality.
Then 2 is for a GPS signal and so on and so on.
(09:10):
My initial string, despite being readable, showed no fix.
This was because I was relying on an internal GPS antenna of the breakout board.
And I was, of course, indoors.
To establish a connection to a satellite I had to move the board outside.
And believe me, this was where my new wireless Raspberry Pi setup truly shown.
(09:33):
I could easily move the board and the Pi outside, plug the Pi into the socket of my terrace and let it run.
I connected to my board via the network from inside and just after a few minutes of starting the debugger and the serial terminal, I got the right NMEA string showing that I had a solid fix to a satellite.
It was really an exciting moment to finally see real satellite data coming to my little board.
(09:58):
Truly amazing.
To verify the coordinates I took a block of the serial response and put it into chatGPT, asking it to convert it to Google Maps address.
Then using Google Maps internal tool I measured the distance between the position given by the GPS module and my actual location.
The result?
Only 160 meters off from the real position.
(10:20):
Which I think is fairly acceptable for the first test with a tiny internal antenna.
It was incredible, fascinating and very interesting to not only get the GPS coordinates but also the real Greenwich Mean Time directly from the satellite.
Part 4.
Conclusion and what’s next?
(10:42):
So this episode has been a ride.
We started by un-thattering the embedded development with a new wireless setup, a true game changer for flexibility.
Then we dove into the new world of GPS, battling with C++ libraries, navigating UART conflicts and finally getting our first proper NMEA string after some crucial debugging.
(11:05):
And Ultimal Triumph, getting a solid satellite fix outdoors and verifying our own location data.
It’s a powerful reminder that the maker’s journey is full of these small aha moments, tiny frustrations that led to a big lesson and simple victories that fuel the motivation.
It’s about learning, adapting and most importantly not being afraid to stumble and figuring out along the way.
(11:29):
That’s where the real growth happens.
For what’s next my immediate goal is to convert those raw NMEA strings into usable coordinates programmatically within my code.
I also just ordered an active external GPS antenna.
This should give me much better range and accuracy for future use cases, especially when mounting the device on the high-speed FPV drone.
(11:52):
The breakout board actually has a reasonable amount of built-in storage for data, but I’m planning to use an SD card next time.
This will give me much better storage capability, allow me to include multiple data points, not just GPS but also the data from the BME 280 sensor and crucially let me experiment with login frequency.
(12:13):
As I’m not sure the internal 15 seconds login interval will be sufficient for my fast moving drone.
If you enjoyed this honest look at the early stage of my embedded project, please subscribe to Build, Create and Learn a Maker’s Journey wherever you get this podcast.
And remember that detailed article on this wireless embedded programming setup I mentioned.
(12:34):
Keep an eye on my blog for the deep dive soon.
Drop me a message, connect on social media or leave a comment on the blog post for this episode.
I would love to hear about your own debugging nightmares and big breakthroughs.
Let’s keep building, creating and learning together.
Hi everyone and welcome back to Build, Create and Learn a Maker’s Journey.
I’m your host Stefan and I’m really excited to dive into Episode 3 with you today.
If you are being following along you know that we are on a mission to build the custom FPV drone telemetry system.
(00:20):
In our last episode we celebrated some big wins, getting the STM32 Cube IDE setup, restling with some small printfbox and finally seeing real world datastream from our BME 280 environmental sensor.
It was a journey of small victories and it really sets the stage for what’s next.
But before we jump into the main event, getting GPS data, I want to talk about something that have been a bit of a nagging problem for me and honestly a game changer for my entire embedded development workflow.
(00:51):
It’s about breaking free from the USB cable.
As an embedded system enthusiast I like to think around with microcontrollers but there is always that one inescapable truth.
You need a physical USB cable.
It connects your powerful development environment directly to the embedded hardware, letting you flash new firmware and debugging that tricky sensor issues.
And here’s the truth, that physical bonds severely limit my flexibility.
(01:15):
I love working from different spots, sometimes from my desk, sometimes from the bed or sometimes out in the garden.
Even needing to flash new firmware or debug a sensor but your dev board is stuck in the workshop.
Or perhaps you are like me constantly on the go with a mobile laptop, plugging and unplugging totally disrupts your flow.
It felt like I was constantly tied up to a leash similar to my old issue with the SSD mount which you can read about on my blog.
(01:43):
This nagging problem kept bugging me.
How could I break free?
I want to work remotely independent of where the hardware actually sets.
Sure, if I am fiddling with buttons or making visible connections, I still need to be next to the board.
But for much of what I do, grabbing sensor data, optimizing internal algorithms or fine tuning low level drivers, the board could generally be anywhere.
(02:06):
That’s when I decided to dive deep into this making embedded programming over network, a reality for my setup.
And the star of this solution?
A trusty Raspberry Pi.
This wireless setup makes development so much more comfortable because it eliminates tangible cables, let me work from the couch and allows for quick reflashing without physically moving to the board.
(02:28):
It truly is a game changer for my workflow.
I have already documented the entire process including the dead ends in a detailed article that will be released soon on my blog.
That article will cover all the nitty gritty setup and configuration details for the Raspberry Pi solution.
This episode will serve as a high level overview, giving you a sneak peek into how I finally unthedered my development board.
(02:51):
Ok, with that exciting detour out of the way, let’s get back to our drone telemetry system.
The main component for this episode is the GPS sensor, the MTK3339.
Part 1 - The Initial Hurdles with Tackling the GPS Sensor So I started with any good maker does, reading the documentation.
(03:16):
I grabbed the EdoFruit breakout board documentation for the MTK3339.
It was really a nice introduction to the component and its basic functionality and it gave me the first steps into understanding GPS data.
I learned about the chipset, its impressive sensitivity and its ability to update 10 times a second.
I also discovered its output data in the standard NMEA 0183 format and that its default board rate is 9600.
(03:43):
What really surprised me though, were the features I wasn’t even aware of when I bought it, built in data login and support for an external active antenna.
That was a pleasant bonus, especially for future drone use.
The introduction of NMEA string was particularly helpful.
Understanding the scripted clients of text is key of getting useful data.
(04:03):
My first instinct to establish communication with the sensor was to try and use the comprehensive EdoFruit library.
I meant why reinvent the wheel, right?
The examples were all focused on the Arduino IDE and how to program it with an Arduino.
I tried to add the library to my STM32 project but I quickly hit the wall.
I realized that the library was written in C++ and my project was in C.
(04:27):
Now there are definitely similarities between the two languages and you can often mix them but I quickly understood that I wasn’t fluent enough in both to handle that properly.
It was a humbling moment realizing I knew some basics but needed to really freshen up my knowledge on the integrated details of each language.
I want to master them along the way but it’s clearly needed more effort and time than I had for this specific task.
(04:51):
So I looked online for others who had worked with the MTK3339 and the STM32.
I found an example that was built on the MBed library.
The source files seemed somewhat understandable and I thought great, I can integrate this easily into my project but I was wrong again.
The library was also written in C++ and converting it was also very unsuccessful.
(05:13):
I even considered converting my entire project to C++ to utilize this library.
I thought after hours of trying to get the files to build, hitting linker errors and complex class structures I couldn’t resolve, I changed my approach.
It was a classic make-up pivot.
Sometimes the path you think it’s easier turns out to be the dead end and you just have to step back and try something completely different.
(05:39):
R2, UART and the first terminal string.
My new approach was to start from scratch, aiming for the absolute minimal working setup, just establish a simple serial connection to the sensor.
In my STM32 pinout configuration I noticed that UART1 was already pre-configured by my development board.
(06:03):
My first thought was "perfect, I will just use that".
But then a bit of skepticism creeped in.
Why was it pre-configured?
Was it already being used by something else?
This led me down the rapid hole of detective work.
I started reading about common issues with UART ports and then dug deeper into the user manual of my specific nuclear development board.
(06:24):
There it was, described nicely and explained exactly how the STM link debugger on my board was connected to the STM32 chip.
And sure enough, my concern was correct, UART1 was indeed being used as a serial COM port for the STM link debugger, which is how my laptop communicates with the board.
With that information it was crystal clear that I had to switch to another available UART port.
(06:49):
So, I activated the UART2 port on pins 9 and 10, which meant I had to slightly adjust the physical wiring on the GPS breakout board to my deafboard pins.
With this new UART port configured, I had compile and code and it ran on the board.
But I still didn’t get any output on my laptop.
My immediate thought was, is the board still not working or is my code wrong?
(07:13):
But then I remembered, I need a serial terminal to see the actual connection coming from the debugger’s COM port.
After some quick research, I figured out how to set it up this terminal directly in my STM32Cube IDE.
And wouldn’t you know it, when I connected, there was some output.
But it was cryptic, scrambled and definitely not what I was expecting.
(07:36):
First I was just happy to see any response in the terminal at all.
But after the initial excitement, I realized, those look really off.
They were fragmented and didn’t look correct at all.
My first idea was to ask JetJGPD if it could figure out and identify the issue.
I checked all the recommendations, board rate of the GPS model, board rate of my serial communication and the wiring.
(07:59):
Everything looked fine.
But the output was still garbage.
So I tried two more things.
And one of them, or perhaps both, solved the issue.
First I double checked the pinout configuration again and pinned the connections for pin 9 and 10 and then recompiled it.
I also changed the main loop function where I was forwarding the serial response from UART2, the GPS model, to UART1.
(08:21):
The debugger and my laptop.
I switched to a simpler UART receive and UART transmit approach.
This resulted in a proper readable response in the terminal.
And there it was, my first NMEA string.
Part 3 - The Satellite Fix and Verification Seeing those NMEA strings was a huge step.
(08:47):
But the critical part for GPS is getting a fix on a satellite.
I quickly learned to look for specific indicators in the NMEA string.
GPRMC A, so where the A means a valid fix.
And the GPPP A1, where 1 stands for the fix of the quality.
Then 2 is for a GPS signal and so on and so on.
(09:10):
My initial string, despite being readable, showed no fix.
This was because I was relying on an internal GPS antenna of the breakout board.
And I was, of course, indoors.
To establish a connection to a satellite I had to move the board outside.
And believe me, this was where my new wireless Raspberry Pi setup truly shown.
(09:33):
I could easily move the board and the Pi outside, plug the Pi into the socket of my terrace and let it run.
I connected to my board via the network from inside and just after a few minutes of starting the debugger and the serial terminal, I got the right NMEA string showing that I had a solid fix to a satellite.
It was really an exciting moment to finally see real satellite data coming to my little board.
(09:58):
Truly amazing.
To verify the coordinates I took a block of the serial response and put it into chatGPT, asking it to convert it to Google Maps address.
Then using Google Maps internal tool I measured the distance between the position given by the GPS module and my actual location.
The result?
Only 160 meters off from the real position.
(10:20):
Which I think is fairly acceptable for the first test with a tiny internal antenna.
It was incredible, fascinating and very interesting to not only get the GPS coordinates but also the real Greenwich Mean Time directly from the satellite.
Part 4.
Conclusion and what’s next?
(10:42):
So this episode has been a ride.
We started by un-thattering the embedded development with a new wireless setup, a true game changer for flexibility.
Then we dove into the new world of GPS, battling with C++ libraries, navigating UART conflicts and finally getting our first proper NMEA string after some crucial debugging.
(11:05):
And Ultimal Triumph, getting a solid satellite fix outdoors and verifying our own location data.
It’s a powerful reminder that the maker’s journey is full of these small aha moments, tiny frustrations that led to a big lesson and simple victories that fuel the motivation.
It’s about learning, adapting and most importantly not being afraid to stumble and figuring out along the way.
(11:29):
That’s where the real growth happens.
For what’s next my immediate goal is to convert those raw NMEA strings into usable coordinates programmatically within my code.
I also just ordered an active external GPS antenna.
This should give me much better range and accuracy for future use cases, especially when mounting the device on the high-speed FPV drone.
(11:52):
The breakout board actually has a reasonable amount of built-in storage for data, but I’m planning to use an SD card next time.
This will give me much better storage capability, allow me to include multiple data points, not just GPS but also the data from the BME 280 sensor and crucially let me experiment with login frequency.
(12:13):
As I’m not sure the internal 15 seconds login interval will be sufficient for my fast moving drone.
If you enjoyed this honest look at the early stage of my embedded project, please subscribe to Build, Create and Learn a Maker’s Journey wherever you get this podcast.
And remember that detailed article on this wireless embedded programming setup I mentioned.
(12:34):
Keep an eye on my blog for the deep dive soon.
Drop me a message, connect on social media or leave a comment on the blog post for this episode.
I would love to hear about your own debugging nightmares and big breakthroughs.
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.