Wenn auf dem Feld plötzlich die GPS-Korrektursignale ausfallen, kann das schnell zu großen Problemen bei der maschinellen Arbeit führen: Ablenkungen bei der Spurführung, Qualitätsverlust bei Sä- oder Ausbringprozessen und im schlimmsten Fall Stillstand. Ich habe mir deshalb eine robuste, kostengünstige Lösung mit einem Raspberry Pi als RTK-Failover aufgebaut, die während GNSS-Ausfällen automatisch auf lokale Quellen oder interne Filter umschaltet. In diesem Beitrag beschreibe ich meine Erfahrungen, die benötigte Hardware und Software sowie die wichtigsten Schritte zur Inbetriebnahme — praxisnah und direkt anwendbar.
Warum ein RTK‑Failover auf dem Feld sinnvoll ist
Auf modernen Betrieben ist RTK-Positionsgenauigkeit (Unter 5 cm) oft Standard. Diese hängt aber von Korrekturdaten (NTRIP, VRS, Basisstationen) und stabiler GNSS-Empfangstechnik ab. Ausfälle können durch Mobilfunkprobleme, NTRIP‑Server-Ausfälle, Antennenstörungen oder atmosphärische Effekte entstehen. Ein Raspberry Pi-basiertes Failover bietet mir:
Was ich verwende — Hardwareübersicht
Für mein Setup habe ich die folgenden Komponenten gewählt. Die Auswahl orientiert sich an Verfügbarkeit, Robustheit und Preis-Leistungs-Verhältnis.
| Komponente | Beispiel / Marke | Funktion |
| Einplatinencomputer | Raspberry Pi 4 (4GB) | Orchestrierung, NTRIP Client/Server, Logging |
| GNSS Empfänger | u‑blox ZED-F9P oder Emlid Reach M2 | RTK-fähiger Empfänger, lokale Basis oder Rover |
| Mobilfunk | LTE-USB Dongle oder Pi-HAT* | Backup-Verbindung zu NTRIP/Internet |
| Stromversorgung | 12V Adapter + stabiler Step‑Down | Farm-geeignete Stromversorgung |
| Gehäuse & Montage | Wetterfestes Gehäuse | Schutz vor Staub, Feuchte, Vibration |
*Für autarke Anwendungen nutze ich oft LTE-HATs mit SIM-Halterung; das vereinfacht die Montage im Kabinenbereich.
Software-Stack und Dienste
Ich setze auf Open-Source-Tools, kombiniert mit einigen proprietären Binarys für u‑blox oder Emlid, je nach Receiver. Die zentrale Software besteht aus:
Aufbau—Schritt für Schritt
Hier beschreibe ich das Setup in chronologischer Reihenfolge, so wie ich es auf dem Hof aufgebaut habe.
Beispiel einer einfachen Failover-Logik
Das Prinzip ist simpel: Monitor lese RTK-Status vom Receiver (NMEA GGA oder u-blox UBX MSG). Wenn Status !=FIX und Dauer >Schwelle → switch. Das kann in einem Bash- oder Python‑Daemon laufen, der str2str-Prozesse startet/stoppt.
Tipps zur Praxis — Empfang, Antenne, Montage
Fehlerdiagnose und Logs
Logging ist für mich das Herzstück — ohne Logs ist Fehlersuche auf dem Feld reine Vermutung. Ich logge:
Diese Logs analysiere ich später am Büro-PC mit RTKLIB‑Tools oder einfachen Skripten (grep, awk). Häufige Fehler sind: Netzstörungen, Antennen-Notchfilter-Effekte durch nahe Stahlkonstruktionen, oder fehlerhafte RTCM-Mountpoint-Konfigurationen in NTRIP.
Was funktioniert besonders gut — und was nicht
Besonders effektiv finde ich die Kombination aus lokaler Basis + Mobilfunk-NTRIP: Fällt das Mobilfunknetz aus, liefert die lokale Basis zuverlässig Korrekturen für einen Radius von einigen Kilometern. Schwierig ist die Synchronisation über große Entfernungen ohne hochwertige Zeitreferenz — hier begrenzen sich die Gebrauchswerte von DIY-Lösungen.
Praxisbeispiel: Einsatz bei Aussaat
Bei einer Aussaatfahrt hatte ich einmal kurzzeitig keinerlei NTRIP-Verbindung. Mein Failover schaltete binnen 3–4 Sekunden auf die lokale Basis um, der RTK-Fix blieb erhalten und die Maschine konnte ohne sichtbaren Versatz weiterarbeiten. Der Unterschied zwischen einem manuellen Eingriff (Verlust der Spurführung) und automatischem Umschalten ist betrieblich enorm.
Weiteres Vorgehen und Verbesserungen
In Zukunft möchte ich noch zusätzliche Sensorfusion ergänzen: IMU‑Daten in den Filter einspeisen, um Übergangszeiten bei GNSS‑Ausfällen zu überbrücken, sowie ein Dashboard auf dem Pi für Live‑Monitoring. Außerdem plane ich, eine kurze Anleitung für Kolleginnen auf dem Hof zu erstellen, damit lokale Mitarbeiter das System bei Bedarf neu starten oder Logs sammeln können.
Wenn ihr möchtet, kann ich euch die Skripte für mein Watchdog‑Daemon und eine Beispiel‑rtkrcv-Konfiguration zur Verfügung stellen. Schreibt mir, welche Receiver ihr verwendet — dann passe ich die Anweisungen an eure Hardware an.
