A Maker’s Journey – Episode 3: Drahtloses Embedded & GPS-Abenteuer

Build, Create & Learn — A Maker’s Journey Episode 3. Ich freue mich, dir in dieser neuen Podcast-Folge die neuesten Projekt-Updates zu präsentieren.

Hinweis: Der Podcast ist ausschließlich auf Englisch verfügbar.

Heute tauchen wir ein in die spannende Welt der GPS-Daten für mein individuelles FPV-Drohnen-Telemetriesystem. Aber bevor wir da landen, möchte ich einen Durchbruch teilen, der mein Embedded-Workflow komplett verändert hat: Ich habe mich vom USB-Kabel befreit.

Kabellos werden – Mein Embedded-Labor per Funk

Als Embedded-Enthusiast bastele ich ständig mit Mikrocontrollern – etwa für mein Drohnenprojekt. Aber da ist diese eine Sache, die immer gleich ist: Du brauchst immer ein physisches USB-Kabel! Es verbindet deinen leistungsstarken Rechner mit dem Embedded-Gerät, um neue Firmware zu flashen oder Bugs in Sensoren zu debuggen.

Und ganz ehrlich – diese physische Verbindung hat mich richtig genervt! Ich liebe es, von überall zu arbeiten – mal am Schreibtisch, mal gemütlich mit dem MacBook im Bett oder draußen im Garten. Stell dir vor, du willst eine neue Firmware flashen oder einen Sensor prüfen, aber dein Dev-Board steckt irgendwo in der Werkstatt. Oder du bist wie ich ständig mobil mit dem Laptop – dauernd ein- und ausstecken – absoluter Flow-Killer. Es war, als ob ich permanent an der Leine hinge, genau wie damals bei meinem SSD-Halterungsproblem.

Dieses nervige Problem hat mich echt verfolgt: Wie kann ich mich endlich davon befreien?! Ich wollte wirklich ortsunabhängig arbeiten – egal, wo die Hardware gerade steckt. Klar, wenn ich physisch etwas umstecke oder Tasten drücke, muss ich dabei sein. Aber bei Sensor-Daten, Algorithmus-Tuning oder Low-Level-Treibern – das Board kann auch im Nebenraum sein! Also habe ich mich reingestürzt: “Embedded-Programmierung über Netzwerk” sollte Realität werden.

Und der Held der ganzen Lösung? Mein treuer Raspberry Pi!

Dieses kabellose Setup macht das Arbeiten einfach so viel angenehmer. Keine Kabel mehr, ich kann entspannt vom Sofa aus arbeiten, schnelle Flash-Vorgänge – alles ohne auch nur in die Nähe der Hardware zu gehen. Ich habe das Ganze auch in diesem detaillierten Blogartikel dokumentiert, inklusive aller Rückschläge.

GPS-Zeit! Der MTK3339-Sensor

Zurück zum eigentlichen Thema: unser GPS-Sensor MTK3339 für das Drohnenprojekt.

Natürlich habe ich zuerst die Doku gewälzt – wie es sich für einen Maker gehört! Das Adafruit-Breakoutboard-Datenblatt war ein guter Einstieg. Ich lernte die Basics zum MTK3339-Chipsatz, seine Empfindlichkeit von -165 dBm und dass er bis zu 10 Updates pro Sekunde liefern kann. Standardkommunikation ist über NMEA 0183, Baudrate: 9600.

Was ich beim Kauf nicht wusste: Das Board unterstützt auch internes Logging und eine externe aktive Antenne – genial für spätere Flüge. Auch die Einführung in die kryptischen NMEA-Zeichenketten war Gold wert.

Mein erster Gedanke: Einfach die Adafruit-C++-Bibliothek nutzen. Doch dann die Erkenntnis: Alle Beispiele sind für die Arduino-IDE, und die Bibliothek war in C++ geschrieben – mein Projekt aber basiert auf reinem C.

C++ bringt mit Klassen und anderen Datei-Strukturen viel Komplexität rein. Klar, ich kenne die Basics, aber das ständige Switchen zwischen den Sprachen war ein echter Denk-Knoten. Nach einigem Suchen fand ich ein Beispiel basierend auf der mbed-Bibliothek – wieder C++. Ich dachte, das passt. Aber der Port auf mein C-Projekt war erneut mühsam. Ich spielte sogar mit dem Gedanken, das ganze Projekt auf C++ umzustellen. Doch nach stundenlangem Kämpfen mit Linker-Fehlern und Konstruktorproblemen: Abbruch. Klassischer Maker-Pivot – man erkennt, dass ein anderer Weg her muss.

UART-Detektivarbeit & Erste NMEA-Zeichenkette

Mein neuer Ansatz: Minimalismus. Ich wollte einfach nur eine serielle Verbindung zum Sensor aufbauen. Ich sah, dass USART2 auf dem Board bereits vorkonfiguriert war – praktisch, dachte ich. Aber nach Blick ins Handbuch wurde klar: USART2 ist belegt durch den ST-Link-Debugger – also nicht nutzbar.

Also auf zu USART1

Ich konfigurierte stattdessen USART1 über Pin 9 und 10, passte die Verkabelung an und bereitete den Code entsprechend vor.

Der Code kompilierte, aber kein Output im Terminal. Dann erinnerte ich mich: Ich brauche ein Terminal! Ich aktivierte das eingebaute Terminal in STM32CubeIDE – und endlich kam eine Antwort! Zwar unleserlich, aber immerhin.

Endlich lesbare NMEA-Daten!

Ich prüfte Baudrate, Verdrahtung, alles – aber der Output war „Müll“. Ich änderte meine Weiterleitungslogik in der Main-Loop – statt komplexer Methoden nutzte ich einfache HAL_UART_Receive und HAL_UART_Transmit. Und siehe da: sauber lesbare GPS-Daten im Terminal! Mein erster NMEA-Satz – ein echtes Highlight.

int main(void)
{
	HAL_Init();
	SystemClock_Config();

	MX_GPIO_Init();
	MX_USART2_UART_Init();
	MX_I2C1_Init();
	MX_USART1_UART_Init();

	const char *msg = "GPS pass through ready\r\n";
	HAL_UART_Transmit(&huart2, (uint8_t*)msg, strlen(msg), HAL_MAX_DELAY);

	while (1)
	{
		if (HAL_UART_Receive(&huart1, rx_buffer_pc, 1, HAL_MAX_DELAY) == HAL_OK)
		{
			HAL_UART_Transmit(&huart2, rx_buffer_pc, 1, HAL_MAX_DELAY);
		}
	}
}

Natürlich wäre für die Produktion DMA oder Interrupts die bessere Wahl – aber für den Anfang perfekt.

Der Satelliten-Fix & Validierung

NMEA-Daten sind gut, aber ein GPS braucht einen Fix auf Satelliten. Dafür analysierte ich die $GPRMC- und $GPGGA-Sätze. Erstere zeigt ‘A’ (aktiv) oder ‘V’ (ungültig), letztere die Fix-Qualität (‘0’ = kein Fix, ‘1’ = GPS-Fix, ‘2’ = DGPS).

Zuerst: keine Satellitenverbindung. Ich war auch noch drinnen – die winzige Antenne reichte nicht. Also rauf auf die Terrasse. Hier kam mein Raspberry-Pi-Setup wieder zum Tragen! Ich schloss das Board draußen an und arbeitete drinnen über Netzwerk weiter.

Nach wenigen Minuten: $GPGSA,A,3,… – ein valider 3D-Fix! Ich fütterte ChatGPT mit den Koordinaten – Ergebnis: etwa 160 Meter Abweichung. Für eine erste Messung mit winziger Antenne: absolut in Ordnung!

Fazit & Ausblick

Was für eine Etappe! Wir haben das USB-Kabel gekappt, unser Embedded-Setup über Netzwerk steuerbar gemacht, C++-Hürden gemeistert, UART sauber konfiguriert und am Ende echte GPS-Koordinaten erhalten – ein echter Meilenstein!

Es sind genau diese Momente – kleine „Aha!“-Erlebnisse, unerwartete Fehler, und das Glücksgefühl bei ersten echten Daten – die den Maker-Weg ausmachen.

Was kommt als Nächstes? Ich will aus den NMEA-Zeichen echte Koordinaten im Code extrahieren. Außerdem: Eine aktive GPS-Antenne ist bestellt, die Reichweite soll besser werden. Und ich will ein SD-Karten-Logging einbauen – mehr Speicher, flexiblere Aufzeichnung für GPS & BME280-Daten.

Wenn du diesen ehrlichen Einblick mochtest, abonniere meinen Podcast “Build, Create & Learn – A Maker’s Journey”. Und schau bald wieder auf dem Blog vorbei – dort kommt bald der Deep Dive zum Wireless-Setup!

Lass uns weiter bauen, gestalten und lernen – gemeinsam.