\chapter{Grundlagen} Dieses Kapitel startet mit der Beschreibung des vorhandenen Fahrzeugs, dem Rover, anhand der darüber verfassten Projektarbeit. Dabei ist die Systemarchitektur und die vorhandene Schnittstellen von besonderer Relevanz, da diese genutzt werden müssen, um die nötigen Implementierungen für diese Arbeit ausführen zu können. Im weiteren Verlauf des Kapitels werden die notwendigen Protokolle erläutert. In diesem Abschnitt wird besonderes auf die Erläuterung der Funktionsweise von GNSS und den Möglichkeiten für Korrekturen der Positionsdaten eingegangen. Darauf folgt eine Beschreibung der Funktionen von Hardwarekomponenten. Geschlossen wird das Kapitel mit der Erläuterung von benötigter und verwendeter Software. \section{Rover} \label{sec:rover} Dieser Abschnitt beschreibt das in der zugrundeliegenden Projektarbeit \cite{Klein2023} erstellte Gesamtsystems des Rovers für diese Arbeit. \par Der Rover wird durch einen 3-Zellen Lithium-Ionen-Akkumulator mit Strom versorgt, dabei wird der Motortreiber und somit auch die beiden Motoren für den Skid-Antrieb mit der anliegenden Spannung des Akkus von nominal \(11,1V\) versorgt. Der Akkumulator und der Motortreiber befinden sich nebeneinander auf der Unterseite des Hauptträgers der Komponenten, auf dem Bild \ref{fig:rover} das blaue Plastik. Je einer der beiden Motoren treibt eine der Fahrzeugseiten an, diese bestehen aus jeweils drei Rädern welche alle über einen Riemen mit der Ausgangswelle des Getriebes zur Untersetzung verbunden sind. An der dieser Ausgangswelle befindet sich ein Encoder-Rad welches durch eine einfache Gabellichtschranke ausgelesen wird, dafür wird der in Hardware implementierte Pulsecounter des verbauten Prozessors verwendet. \par Die restlichen Komponenten werden mit \(5V\) versorgt, die \(5V\) werden über einen Spannungsregler mit einem maximalen dauerhaften Ausgangsstrom von \(1A\) bereitgestellt. Der Spannungsregler befindet sich auf der Hauptplatine, welche wiederrum auf der oberseite des Hauptträgers zentral verbaut ist. Diese Platine verbindet alle Komponenten mit dem auf einem aufgesteckten Entwicklungsboard verbauten ESP32 Prozessor. Der ESP32 stellt verschiedene Schnittstellen über die GPIO (General Purpose Input Output) Pins zur Verfügung, davon werden für den Rover die Bussysteme I2C und SPI, ein ADC Kanal (Analog Digital Converter) und PWM (Pulsweitenmodulation) genutzt. Weitere Kommunikation findet auf dem drahtlosen Weg statt, dafür wird das WiFi-Modul genutzt, mit diesem kann eine Verbindung zum einem \(2,4GHz\) WLAN aufgebaut werden und es wird mit dem Protokoll ESPNow über das selbe Frequenzband eine Verbindung zu der Fernbedienung hergestellt. Zur Verwaltung des Funkmoduls und der Bewältigung anderen Aufgaben, welche an den Prozessor gestellt werden, verfügt dieser über zwei Xtensa 32bit LX6 Kerne, welche mit bis zu \(240MHz\) takten. Als SRAM stehen 540 KB bereit und der Flash-Speicher für die Software ist 4 Megabyte groß. \par Mit auf der Hauptplatine befindet sich das ebenfalls aufgesteckte Entwicklungsboard von Sparkfun. Das Board nutzt den SPI-Bus um die Kommunikation zwischen dem ESP32 und dem ZED-F9K herzustellen. Bei dem ZED-F9K handelt es sich um einen hochpräziser multi-band GNSS Receiver, welcher die Signale von allen öffentlichen Satelliten gestützten Navigationssystemen verarbeiten kann. Zusätzlich können Korrekturdaten verarbeitet werden mit welchen die Genauigkeit der Positionsbestimmung auf den Bereich einstelliger Centimeter erhöht wird. Auf der Platine befindet sich eine SMA-Buchse mit welcher die GNSS-Antenne verbunden ist. Die Antenne befindet sich am Heck des Rovers auf dem grünen T-Träger. \par Der I2C-Bus wird benutzt um den letzten Sensor und ein Display anzubinden. Bei dem Sensor handelt es sich um einen Kompass, welcher möglichst weit entfernt von anderen Komponenten sein sollte und deshalb auf dem Mast der neben dem Display nach oben ragt montiert ist und die aktuelle Himmelsrichtung bei richtiger Kalibrierung auf \(2^{\circ}\) genau angeben kann. Bei dem Display auf dem Querbalken handelt es sich um ein 16 x 2 Zeichen LCD, dieses wird von einem I2C-Seriell Adapterinterface betrieben. \par Zu dem Rover gehört eine Fernbedienung, welche über sieben Tasten und einem Joystick als Eingabemöglichkeit verfügt. Vier Tasten bilden ein Steuerkreuz, um das navigieren im Menü zu ermöglichen. Zwei Weitere Tasten werden zum bestätigen und ablehnen genutzt. Die letzte Taste wird als Action-Button bezeichnet und wird betätigt, wenn der Joystick gedrückt wird. Die Taste ist für spezielle Aktionen der verschiedenen Betriebsmodi des Rovers vorgesehen. An der Fernbedienung wurde ebenfalls das zuvor genannte LCD verbaut, dieses spiegelt das Display am Rover. Die Fernbedienung wird ebenfalls von einem ESP32 gesteuert, dieser stellt die Kommunikation über das genannte ESPNow Protokoll zu dem Rover her. Um die Fernbedienung mit Energie zu versorgen wird eine Powerbank benötigt an der das heraushängende USB-Kabel vom Typ A angeschlossen werden kann. \par Die vorhandene Software für den Rover ist Objektorientiert und Modular aufgebaut. Zusätzlich ist der Programmcode für die Benutzeroberfläche von dem restlichen Code getrennt. Die Struktur des Codes wird wesentlich durch zwei Interfaces bestimmt. Das erste wird als 'Component' bezeichnet und muss implementiert werden um eigenständige wiederkehrende Aufgaben zu implementieren. Das zweite Interface mit dem Namen 'DriveModi' definiert welche Mindestanforderungen an einen Betriebsmodus des Rovers gestellt werden und stellt die Komponenten für die Benutzereingaben, die Sensorverwaltung und die Bewegungsreglung zur Nutzung im Betriebsmodus bereit. Andere Komponenten überwachen den Akku, steuern das Display, verwalten die Benutzeroberfläche, überwachen Benutzereingaben oder verarbeiten Sensordaten. \section{Protokolle} Dieser Abschnitt beschreibt die verschiedenen Protokolle, welche von unterschiedlichen Teilsystemen genutzt werden um die Funktionalität des Gesamtsystems zu ermöglichen. \subsection{GNSS} GNSS ist das Akronym für \textbf{G}lobal \textbf{N}avigation \textbf{S}atellite \textbf{S}ystem. Inzwischen gibt es mehrere dieser Systeme deren Hauptzweck die Positionsbestimmung auf dem gesamten Globus und auch darüber ist. In der Tabelle \ref{tab:sats} sind diese aufgelistet. Die Positionsbestimmung wird unter anderem für die Navigation in allen Bereichen, zur Vermessung und Zeitmessung verwendet. Ein anderer Anwendungsfall liegt in der Landwirtschaft, mit Hilfe von Korrekturdaten wird die Positionsbestimmung ausreichend genau, um Traktoren im Feld eine exakt gerade Linie fahren zu lassen, damit der laufende landwirtschaftliche Prozess optimal ausgeführt werden kann. \begin{table}[ht] \centering \begin{tabular}{|l|l|c|c|} \hline \textbf{Name} & \textbf{Betreiber} & \textbf{Verfügbar seit} & \textbf{Anzahl Satelliten} \\ \hline NAVSTAR GPS & USA & 1995 & 24 \\ \hline GLONASS & Russische Föderation & 1993 & 24 \\ \hline Galileo & Europäische Union & 2020 & 28 \\ \hline Beidou & China & 2011 & 35 \\ \hline \end{tabular} \caption{Satelliten zur Positionsbestimmung \cite{Klein2023}} \label{tab:sats} \end{table} \subsubsection{Allgemeine Funktionsweise} Bauer \cite[S. 67ff]{Bauer2018} beschreibt, dass mindestens die Sicht auf vier Satelliten gegeben sein muss um die eigene Position bestimmen zu können Die Verbindung zwischen den Satelliten und dem Empfänger ist einseitig, deshalb stehen dem GNSS-Empfänger nur die Informationen zur Verfügung die mit Signal übertragen werden können. Eine dieser Informationen ist die zwingend benötigte Position des Satelliten, welche aus den übermittelten Bahndaten errechnet wird. \par Die Position des GNSS-Nutzers wird durch die Berechnung der Signallaufzeiten von dem Satelliten zu dem Empfänger errechnet. Alle Satelliten senden in einem festgelegten und synchronisierten Interval ihr Signal. Der Empfänger besitzt aufgrund der Systemarchitektur Informationen darüber wie das Signal erzeugt wird und erzeugt intern ebenfalls ein Signal. Die Zeitdifferenz \(\Delta t_i\) wird für jedes ankommendes Signal zu dem erzeugten Signal gemessen. Durch die sehr präzisen Atomuhren in den Satelliten können diese bis auf einen Fehler im niedrigen Nanosekundenbereich den Interval einhalten, allerdings ist dies nicht für den Empfänger möglich, da weder eine ähnlich genaue Uhr zur Verfügung steht noch die vorhandene Uhr mit dem GNSS synchronisiert ist. Deshalb muss von dem gemessenen \(\Delta t_i\) die Uhrzeitdifferenz \(\Delta t\) zwischen dem Empfängers und dem GNSS subtrahiert werden. Für die Berechnung der Strecke wird außerdem die Ausbreitungsgeschwindigkeit \(v\) des Signals benötigt. Im Vakuum beträgt die Ausbreitungsgeschwindigkeit für die genutzten Mikrowellen annähernd Lichtgeschwindigkeit. !!!Nochmal lesen ob das so ist mit v = c!!! Da es sich bei der Erdatmosphäre um keine Vakuum handelt und auch nicht um ein anderes konstantes Medium, muss die Ausbreitungsgeschwindigkeit ebenfalls ermittelt werden. \par Die Berechnung einer Position im Raum enthält die drei unbekannten für die X-, Y- und Z-Koordinate in einem kartesischen Koordinatensystem. Hinzu kommt die unbekannte Uhrzeitdifferenz \(\Delta t\). Daher ergibt sich die Mindestanforderung von vier Sichtbaren Satelliten, um für jede der unbekannten Variablen eine Gleichung aufstellen zu können. Bauer gibt folgende \cite[Gleichung 1.24]{Bauer2018} zur Ortsbestimmung an: !!!Formel verstehen!!! \begin{eqnarray} (\Delta T_i \cdot v + \Delta t \cdot v)^2 = (X_i - X_E)^2 + (Y_i - Y_E)^2 + (Z_i - Z_E)^2;i = 1,2,3,4 \end{eqnarray} Dabei steht \({Koordinate_E}\) für die unbekannte Empfänger Position und \({Koordinate_i}\) für die bekannte Position des Satelliten. Auf die Ausbreitungsgeschwindigkeit \(v\) wird gleich noch eingegangen. Hergeleitet wurde die Formel aus dem räumlichen Pythagoras. \subsubsection{Signallaufzeit} Grundsätzlich breiten sich elektromagnetische Wellen jeder Frequenz im Vakuum mit der Lichtgeschwindigkeit \(c\) aus. Jedes Medium vermindert diese Geschwindigkeit. Die Geschwindigkeitsabnahme hängt von dem Medium ab. Im Kontext von GNSS handelt es sich bei den Medien um die Schichten der Erdatmosphäre. Von Bauer \cite[S. 116ff]{Bauer2018} wird erläutert, dass die Lichtgeschwindigkeit \(c\) mit dem Brechungsindex \(n\) des jeweiligen Mediums multipliziert werden muss um die passende Geschwindigkeit bei den Berechnungen zu nutzen. Er definiert den Brechungsindex wie folgt: \begin{eqnarray} n = \frac{c}{v} = \frac{[Geschwindigkeit \: des \: Signals \: im \: Vakuum]}{[Geschwindigkeit \: des \: Signals \: im \: Medium]} \end{eqnarray} Für die Signallaufzeit wird zunächst der ionisierte Teil der Erdatmosphäre betrachtet. Die Änderung der Signallaufzeit wird auch Refraktion genannt. Die Ionosphäre beginnt ungefähr bei \(50km\) und endet bei \(1000km\) über der Erdoberfläche. Das Signal wird durch die freie Elektronen beeinflusst. Die Anzahl der freien Elektronen wird mit der Elektronendichte \(N_e\) angegeben, diese variiert nach Tages- und Jahreszeit, sowie nach verschieden Schichten in der Ionosphäre. In dem Kapitel \glqq{}Ionosphärische Refraktion\grqq{} \cite[S. 123f]{Bauer2018} zeigt Bauer die Herleitung für folgende Formel: \begin{eqnarray} n_{PH} = 1 - \frac{40,3 \cdot N_e}{f^2} \label{eq:brechungsindexIonosphäre} \end{eqnarray} Diese Gleichung zeigt, dass der Brechungsindex für die Phasengeschwindigkeit von der Elektronendichte \(N_e\) und der Frequenz \(f\) des Senders bestimmt wird. Aufgrund der unstetigen Elektronendichte in der Ionosphäre gibt es beispielsweise das \textbf{Klobuchar-Modell} \cite[128]{Bauer2018}, welches stetig an den Tag und die Sonnenaktivität angepasst wird und von den Satelliten an die Empfänger publiziert wird. Mit diesem Modell können \(50\%\) der ionosphärischen Laufzeitfehler korrigiert werden. \par Eine aufwendigere und genauere Alternative bietet die Zweifrequenzkorrektur, aufgrund der Abhängigkeit des Brechungsindexes von der Frequenz kann durch die Messung von zwei unterschiedlichen Frequenzen, im Fall von GNSS meist im L1 und L5 Band, auf die Refraktion in der Ionosphäre geschlossen werden. \par Sobald die Signale die Ionosphäre durchquert haben, treffen diese erst auf Stratosphäre und anschließend auf die Troposphäre, in welcher sich typischerweise der Empfänger befindet. In der Strato- und Troposphäre wird das Signal hauptsächlich durch die Zusammensetzung der Gase, dem Luftdruck und der Temperatur in diesen Schichten beeinflusst. Diese Zusammensetzung ist allerdings über den Planeten verteilt relativ homogen, weshalb dieser Fehler gut kalkuliert werden kann. In Troposphäre stellt die Luftfeuchtigkeit ein zusätzliches Hindernis für den Signallaufweg dar. Dieser Fehler ist Orts- und Zeitabhängig und deshalb schwerer zu modellieren. Es gibt mehrere Modelle zur Berechnung des aktuell wirkenden einflusses, hier zu nennen wären das Modell von Hopfield und das Modell von Saastamoinen, wie von Bauer \cite[131]{Bauer2018} beschrieben. \subsubsection{Andere Fehlerquellen} In der folgenden List werden mögliche Fehlerquellen dargestellt, welche eine Positionsbestimmung behindern können: \begin{itemize} \item \textbf{Mehrwegeausbreitung} beschreibt den Umstand, dass die Antenne das Signal des Satelliten auf mindesten zwei Wegen empfängt. Der erste Weg ist der direkte vom Satelliten zu dem Empfänger, der so auch gewünscht ist. Die anderen Wege stammen von Reflexionen des Signals. Die unerwünschten Reflexionen können meist dadurch erkannte werden, dass die Dämpfung des Signals deutlich höher als die des direkt empfangenen Signals ist. \item \textbf{Signalbeugung} beschreibt den Empfang eines Signals von einem Satelliten, welcher durch ein Hindernis abgeschattet ist. Das ist möglich weil ein Signal, welches zum Beispiel auf eine Gebäudekante trifft abgelenkt (gebeugt) wird. Wenn ein Satelliten von dem Empfänger schon beobachtet wird, kann dieser Fehler erkannt werden, weil die Signaldämpfung unvorhergesehen zunimmt. \item \textbf{Aktive Störung} können bei GNSS mit wenig Aufwand herbeigeführt werden. Bauer beschreibt \cite[169]{Bauer2018}, dass die Signalstärke von GNSS bei lediglich \(-160dBW\) liegt, was umgerechnet \(1 \cdot 10^{-16}W\) entspricht. Deshalb ist es möglich mit geringen Sendeleistungen von wenigen \(W\) bereits Bereich mit mehreren \(10km\) zu stören. \end{itemize} \subsubsection{Aufbau} Bauer beschreibt in dem Kapitel "Die Systemkomponenten" \cite[S. 201ff]{Bauer2018} von GNSS. Diese werden in drei Kategorien aufgeteilt: \setlist{noitemsep} \begin{itemize} \item Weltraumsegment, \item Bodensegment, \item Nutzersegment. \end{itemize} \setlist{} Das Weltraumsegment besteht aus den GNSS-Satelliten. Ein Empfänger an einem beliebigen Ort auf Erde muss immer 4 Satelliten sehen können um eine Ortung durchführen zu können. Dementsprechend wurden die Satellitenumlaufbahnen von den verschiedenen Systembetreibern gewählt. Im Falle von GPS sind es 24 Satelliten, welche auf 6 Bahnebenen aufgeteilt sind. Ein Satellit wird über Sonnenpaddel mit Strom versorgt. In dem Satelliten befindet sich unter anderem die hochgenaue Atomuhr. An Hülle befindet sich eine Sendevorrichtung für das GNSS-Signal und eine Kommunikationsvorrichtung um mit Bodensegment kommunizieren zu können. Viele Systeme sind in den Satelliten redundant ausgelegt um die Lebenserwartung zu erhöhen, diese liegt bei moderne Satelliten bei 15 Jahren. Die Satelliten der unterschiedlichen Generationen und Systeme sehen unterschiedlich aus, als Beispiel siehe Abbildung \ref{fig:satellite} \begin{figure}[h] \centering \includegraphics[width=\linewidth]{img/satellite.jpg} \caption{Modell eines Satelliten von dem GNSS Galileo \protect\footnote[1]{This file comes from Science Museum Collections, a website operated by Science Museum Group, a non-departmental public body in the UK. This tag does not indicate the copyright status of the attached work. A normal copyright tag is still required. See Commons:Licensing. (\url{https://commons.wikimedia.org/wiki/File:Galileo_satellite_model.jpg}), \url{https://creativecommons.org/licenses/by/4.0/legalcode}}} \label{fig:satellite} \end{figure} Das Bodensegment hat die Aufgabe die Satelliten mit den aktuellen Information zu versorgen, welche über die Satelliten an die Nutzer weitergegeben werden. Für diese Aufgabe werden mehrere Stationen genutzt: \begin{itemize} \item \textbf{Überwachungsstationen} messen die Daten der GNSS-Satelliten und übermitteln diese an die Zentralstation. \item In der \textbf{Zentralstation} werden die Daten verarbeitet. Aus diesen Daten werden die aktuellen Bahndaten mit einer Genauigkeit von 1 bis 2m der einzelnen Satelliten bestimmt. Die Ergebnisse werden der Sendestation übergeben. \item Die \textbf{Sendestationen} übermitteln die Ergebnisse an die Satelliten. \end{itemize} Das Nutzersegment wird durch die GNSS-Empfänger gebildet. \subsection{DGNSS} Da die Genauigkeit von GNSS lediglich einige Meter beträgt, wurden verfahren Entwickelt, um die Positionsbestimmung zu optimieren. Ein Prinzip ist dabei das \textbf{Differenzielle}-GNSS, dabei gibt es immer eine ortsfeste Referenzstation oder ein Netz dieser und den GNSS-Empfänger im Feldeinsatz (Rover). Zusätzlich muss eine Verbindung zwischen diesen beiden Empfängern bestehen. Über diese Verbindung werden Code"=Beobachtungskorrekturen von der Referenzstation an den Rover übermittelt. Diese Korrekturen ermöglichen es den Fehler der Positionsbestimmung in Echtzeit auf bis zu \(1m\) zu reduzieren. \cite[vgl.][S. 248]{Bauer2018} \subsubsection{RTK} \label{sssec:rtkDescription} \textbf{R}eal \textbf{T}ime \textbf{K}inematic bezeichnet ebenfalls eine DGNSS-Methode, im gegensatz zu der zuvor beschriebenen sind mit RTK Echtzeitpositionierungen im einstelligen \(cm\)-Bereich möglich. Die zusätzlich gewonnene Genauigkeit kommt laut Bauer\cite[249]{Bauer2018} bei diesem Verfahren durch die Erhebung von Phasendaten zustande. Die Verwendung der Phasendaten ist aufwendiger als die Code-Daten dafür aber auch genauer. Außerdem werden typischerweise Zweifrequenzen-Phasendaten erzeugt, damit schneller eine Mehrdeutigkeitslösung gefunden werden kann. Der Rover muss dementsprechend die gleichen Frequenzen empfangen können um die Korrekturdaten anwenden zu können. Die Daten werden im Sekundentakt an den Rover übermittelt. \subsubsection{SBAS durch EGNOS} Die sogenannten \textbf{S}atellite-\textbf{B}ased \textbf{A}ugmentation \textbf{S}ystem stellen Erweiterungen zu den GNSS Diensten dar um beispielsweise die Genauigkeit zu erhöhen. Ein großer Nutzeranteil wird durch die Luftfahrt gestellt um Landungen zu vereinfachen. \par Bei SBAS handelt es sich um geostationäre Satelliten. Diese Art von Satelliten stehen für einen Beobachter auf der Erde fest am Horizont, daher kann mit dieser Art von Satelliten nur ein gewähltes Gebiet mit Informationen versorgt werden. Dadurch gibt es mehrere dieser Systeme, im folgenden wird kurz das in Europa betriebene EGNOS (European Geostationary Navigation Overlay System) beschrieben. \par Mit Messstationen werden im Sekunden Takt Rohdaten unterschiedlicher GNSS und die Entfernung zu den EGNOS-Satelliten gesammelt. Die gesammelten Daten werden von mehreren Mission Control Center (MMC) verarbeitet um daraus DGNSS-Nachrichten zu formulieren. Die Nachricht enthält unter anderem Korrekturen für die Satellitenuhren, Korrekturen der Umlaufbahnen und Werte zur Berechnung der ionosphärischen Einflüsse. Diese Nachricht wird dann die Satelliten weiter gegeben, welche diese dann wiederrum über das L1-Band senden und damit GNSS-Empfängern in Reichweite zur Verfügung stellen. Mit Anwendung der verschickten Korrekturdaten kann eine Positionsbestimmung mit \(1m\) Genauigkeit erzielt werden.\cite[vgl.][S. 393ff]{Bauer2018} \subsection{RINEX} Das RINEX-Format ist aus der Notwendigkeit einer unabhängigen Möglichkeit des Datenaustausches zwischen GNSS-Modulen unterschiedlicher Hersteller entstanden. Das Format wurden nach seinen Anforderungen benannt und heißt daher ausgeschrieben \textbf{R}eceiver \textbf{IN}dependent \textbf{EX}change. Die erste Version des Formats wurde 1989 von Werner Gurtner veröffentlicht. Nach einigen weiteren Versionen, welche das Format unter anderem für weitere GNSS erweiterte, wird die Versionspflege inzwischen von der IGS und dem RTCM-SC104 übernommen. \par Das RINEX-Format bietet die Dateitypen für Beobachtungs- (*.obs), Navigations- (*.nav) und Meteorologischendaten (*.sbs) an. Für diese Arbeit werden für die Einmessung der Antenne lediglich die Beobachtungsdaten benötigt, welche mit einem Header für allgemeingültige Daten beginnt und danach unter anderem Daten zu den Messzeiten, Pseudostrecken, Trägerphasen, Signalrauschen und Dopplereffekt enthält. Die gesammelten Daten während der einmessung können dann durch eine PostProcessingService verarbeitet werden, dabei werden weitere Daten von Beobachtungsstationen verwendet um eine möglichst genaue Position der Antenne errechnen zu können.\cite[vgl.][S. 107ff]{Ogaja} \subsection{RTCM} RTCM ist ein Standard zur Echtzeitübertragung von Daten zwischen GNSS-Empfängern. Dieses Format wurde zunächst in 1985 von der namensgebenden Organisation \textbf{R}adio \textbf{T}echnical \textbf{C}ommission for \textbf{M}aritime Services veröffentlicht. Aktuell ist die Version 2.3 aus dem Jahr 2001 noch stark verbreitet, welche sich stark an den Nachrichtenstruktur von GPS orientiert. Mit jeder neuen Version wurden Möglichkeiten geschaffen um weitere Daten übertragen zu können. Um das in Abschnitt \ref{sssec:rtkDescription} beschrieben RTK anwenden zu können empfiehlt sich die Version 3 des Formats. Insbesondere die Version 3.2 und 3.3 eigenen sich besonders gut, da ab diesen Versionen auch die neueren GNSS mit einbezogen werden können und diese Versionen Raum für Erweiterungen lassen.\cite[vgl.][S. 249ff]{Bauer2018} \par RTCM bietet noch weitere Funktionen wie eine Netzwerkkomponente, für diese Arbeit sind jedoch lediglich die Übertragungen der Code- und Phasenkorrekturen von Bedeutung, da die Übertragung der RTCM-Nachrichten mit dem NTRIP umgesetzt wird, siehe Abschnitt \ref{ssec:ntripDescription}. Nachfolgenden wird die Tabelle \ref{tab:rtcmMsg} dargestellt, welche die in dieser Arbeit Anwendung findenden Nachrichten Typen beschreibt.\cite[vgl.][S. 113f]{Ogaja} \begin{table}[h] \centering \begin{tabular}{|l|l|} \hline \textbf{RTCM 3 Msg-Nr.} & \textbf{Inhalt} \\ \hline 1005 & Koordinaten der Referenzstation \\ \hline 1074 & GPS MSM4 \\ \hline 1084 & GLONASS MSM4 \\ \hline 1094 & Galileo MSM4 \\ \hline 1124 & BeiDou MSM4 \\ \hline 1230 & GLONASS L1 und L2 Code-Phase Biases \\ \hline \end{tabular} \caption{Auszug von Ethernet Übertragungsstandards nach IEEE 802.3} \label{tab:rtcmMsg} \end{table} MSM ist Akronym für Multiple Signal Messages und ist aufgeteilt in sieben Nachrichtentypen, wobei mit aufsteigender Nummer mehr Informationen übertragen werden. Die in Tabelle \ref{tab:rtcmMsg} bezeichnete MSM4 enthält die Pseudorange, Phaserange und CNR (Carrier to Noise Ratio). \cite[vgl.][114]{Ogaja} \subsection{NTRIP} \label{ssec:ntripDescription} NTRIP wird ausgeschrieben zu \textbf{N}etworked \textbf{T}ransport of \textbf{R}TCM via \textbf{I}nternet \textbf{P}rotocol. Dieses Transferprotokoll wurde zunächst von dem Bundesamt für Kartographie und Geodäsie mit Hilfe der Technischen Universität Dortmund entwickelt. Es wird von der NTRIP Working group of RTCM Special Committee 104 (SC104) standardisiert und weiterentwickelt. Seit 2009 ist die verbesserte und abwärtskompatible Version 2 standardisiert. \cite[vgl.][]{FACG} \par Damit das Protokoll möglichst gut unterstützt wird, orientiert es sich stark an dem HTTP (Hypertext Transfer Protokoll)in der Version 1.1. Im nachfolgenden wird das übernommene Beispiel einer minimal Verbindung gezeigt. \cite[siehe][2]{NTRIPWorkingGroup2023} \begin{minted}{http} GET /MountPtName HTTP/1.1 Host: Acaster.com:2101 Ntrip-Version: Ntrip/2.0 User-Agent: NTRIP ProductName/Version \end{minted} An diesem Beispiel ist die Ähnlichkeit zum HTTP sehr deutlich zu sehen, es werden bekannte HTTP-Methoden eingesetzt sowie gleiche Zeilen Abschlüsse genutzt. \par Das System basiert auf diesen drei Komponenten \cite[vgl.][S. 2-1]{FACG2004}: \begin{itemize} \item Ein \textbf{Ntrip-Caster} ist eine Serveranwendung die einem Webserver ähnelt. Die Kommunikation wird immer von einem Client, ähnlich dem Beispiel, initialisiert. Für diese Arbeit wird der Service rtk2go als Caster genutzt, welcher in Abschnitt \ref{ssec:rtk2go} kurz beschrieben wird. \item Der \textbf{Ntrip-Server} stellt die Daten als Client für den Ntrip-Caster zur Verfügung. Dieser wird auf der Basisstation mithilfe der RTKLib ausgeführt siehe dafür Abschnitt \ref{sec:Basisstation} und \ref{sssec:rtklib} \item Der \textbf{Ntrip-Client} ist ein ebenfalls ein Client des Ntrip-Caster und bezieht die Korrekturdaten. Da die Korrekturdaten auf dem Rover benötigt werden, wird in Abschnitt \ref{ssec:ntripclient} die Implementierung eines Ntrip-Clients für den ESP32 beschrieben. \end{itemize} Wie auch das HTTP, verwendet das Ntrip Protokoll, TCP (Transmission Control Protocol) für die Verbindung zwischen den Komponenten. \subsection{WLAN} Das Akronym WLAN wird ausgeschrieben zu \textbf{W}ireless \textbf{L}ocal \textbf{A}rea \textbf{N}etwork. Dabei handelt es sich um drahtlose lokal begrenzte Netzwerke, welche dafür vorgesehen sind mobile Endgeräte direkt oder über eine Vermittlungsstelle, wie einem Router, miteinander oder anderen Netzwerken zu verbinden. Diese Art von Netzwerken werden am häufigsten durch den IEEE 802.11 Standard \cite{WLAN} realisiert. \par Der genannte Standard wurde erstmals 1997 veröffentlicht und wird seit dem immer wieder dem aktuellen Anforderungen angepasst. Zunächst wurde die Physikalische Ebene in dem \( 2,4 GHz\) Frequenzband definiert. In der ersten Erweiterung (IEEE 802.11a) von 1999 wurde das \(5GHz\) Band dem Standard hinzugefügt. In dem ersten Frequenzband können die Frequenzen \( 2,3995GHz - 2,4845GHz\) genutzt werden, dafür wird dieser Bereich in 13 sogenannten Kanäle aufgeteilt. Es werden Kanalbreiten von \(20MHz\) und \(40MHz\) genutzt. Das \(5GHz\) ist in zwei Frequenzbereiche aufgeteilt, zum einen von \(5,15GHz - 5,35GHZ\) und zum anderen von \(5,5GHz - 5,7GHz\), dabei werden die Kanäle von 36 bis 64 und von 100 bis 140 angeben. Die Kanalbreite kann zwischen \(20MHz\), \(40MHz\), \(80MHz\) und \(1600MHz\) variiert werden. Dabei ist zu beachten, dass die verschiedenen Kanalbreiten erst mit späteren Standards implementiert wurden. \par Die verschieden Korrekturen und Erweiterungen des Standard dienen im allgemeinen dazu eines oder mehrere der folgenden Kriterien zu verbessern: Geschwindigkeit, Reichweite, Zuverlässigkeit und Effizienz. Die Fortsetzungen wurden beginnend mit dem Buchstaben 'a' begonnen, nachdem das Alphabet vollständig genutzt wurde, werden nun zwei Buchstaben genutzt. Es handelt sich dabei um ein Zahlensystem zur Basis 26. In der Tabelle \ref{tab:wlan} sind einige wichtigere oder bekanntere Erweiterungen des Standards aufgeführt. \begin{table}[h] \centering \begin{tabular}{|l|c|c|c|} \hline \textbf{Standard} & \multicolumn{1}{l|}{\textbf{Verabschiedung}} & \multicolumn{1}{l|}{\textbf{\begin{tabular}[c]{@{}l@{}}Frequenzband\\ {[}GHz{]}\end{tabular}}} & \multicolumn{1}{l|}{\textbf{\begin{tabular}[c]{@{}l@{}}max. Brutto\\ Datenrate\end{tabular}}} \\ \hline 802.11a & 1999 & 2,4 \& 5 & \(54\frac{MBit}{s}\) \\ \hline 802.11b & 1999 & 2,4 & \(11\frac{MBit}{s}\) \\ \hline 802.11g & 2003 & 2,4 & \(54\frac{MBit}{s}\) \\ \hline 802.11n & 2009 & 2,4 \& 5 & \(600\frac{MBit}{s}\) \\ \hline 802.11ac & 2013 & 5 & \(3,4\frac{GBit}{s}\) \\ \hline 802.11ax & 2019 & 2,4 \& 5 & \(12\frac{GBit}{s}\) \\ \hline 802.11be & ausstehend & 2,4, 5 \& 6 & \(46\frac{GBit}{s}\) \\ \hline \end{tabular} \caption{Ausschnitt verschiedener IEEE 802.11 Standards} \label{tab:wlan} \end{table} Die Verbreitung von WLAN in das alltägliche private Leben begann mit dem 802.11b Standard, weil mehrere Hersteller begannen Geräte für einen moderaten Preis zu verkaufen und diese durch den Standard Kompatibel zu einander sein müssen. Dadurch wurde es viel leichter Laptops und andere mobile Gräte kabellos mit dem Netzwerk zu verbinden. Heute sind in fast jedem Gebäude WLAN-Netzwerke zu finden. \par Auch in der Industrie ist WLAN eine essentielle Technik, zum Beispiel für automatisierte Lagersysteme mit mobilen Robotern. \subsection{Ethernet} Ethernet beschreibt nach dem Standard IEEE 802.3 \cite{Ethernet} verschiedene kabelgebundene Möglichkeiten \textbf{L}ocal \textbf{A}rea \textbf{N}etworks (LANs) aufzubauen. Diese Netzwerke werden typischerweise in Gebäuden eingesetzt mit einer Sterntopologie. Bei der installation wird hauptsächlich mehradriges Kupferkabel oder Glasfaserkabel genutzt. Das Kupferkabel wird auch Twisted-Pair-Kabel genannt und wird in verschiedene Kategorien eingeteilt, durch diese ist es möglich die maximale Geschwindigkeit des Kabels abzulesen. Einige dieser Kategorien können in der Tabelle \ref{tab:ethernet} abgelesen werden. \par Glasfaserkabel werden nur in zwei Kategorien eingeteilt. Multimode-Glasfaserkabel werden oft in LANs benutzt, da sie sich eher für kürzere Distanzen eignen. Die Distanz wird durch die Brechung des Lichts und der Verwendung mehrerer Lichtmoden in dem Lichtleiter eingeschränkt. Die Reichweite ist der von Twisted-Pair-Kabeln trotzdem deutlich überlegen. Aufgrund der höheren Fertigungskosten der Singlemode-Glasfaserkabel sind diese eher selten in LANs zu finden. Der Kerndurchmesser des Lichtleiters ist bei diesen Kabeln um ein vielfaches geringer. Die Reduzierung von \(50\mu m\) bzw. \(62,5\mu m\) auf typischerweise \(8\mu m\) bis \(10\mu m\) und der ausschließlichen Übertragung einer Lichtmode ermöglicht nochmals längere Signalwege. Außerdem bietet die Glasfasertechnologie den Vorteil unabhängig von elektromagnetischen Störungen zu sein. \par Die Tabelle \ref{tab:ethernet} zeigt einige Übertragungsstandards von Ethernet, dabei wurde unter anderem die Übertragungsmöglichkeiten über Coaxialkabel aus den Anfängen von Ethernet ausgelassen. \begin{table}[h] \centering \begin{tabular}{|l|c|c|r|} \hline \textbf{Standard} & \multicolumn{1}{l|}{\textbf{max. Geschwindigkeit}} & \multicolumn{1}{l|}{\textbf{Medium}} & \multicolumn{1}{l|}{\textbf{max. Segmentlänge}} \\ \hline 10BASE-T & \(10\frac{MBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Twisted-Pair\\ min. Cat3\end{tabular} & 100m \\ \hline 100BASE-TX & \(100\frac{MBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Twisted-Pair\\ min. Cat5\end{tabular} & 100m \\ \hline 1000BASE-T & \(1\frac{GBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Twisted-Pair\\ min. Cat5e\end{tabular} & 100m \\ \hline 1000BASE-SX & \(1\frac{GBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Glasfaser\\ Multimode\end{tabular} & 550m \\ \hline 1000BASE-LX & \(1\frac{GBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Glasfase\\ Singlemode\end{tabular} & 5km \\ \hline 10GBASE-T & \(10\frac{GBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Twisted-Pair\\ min. Cat6\end{tabular} & \begin{tabular}[c]{@{}r@{}}55m\\ 100m mit Cat6a\end{tabular} \\ \hline 10GBASE-SR & \(10\frac{GBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Glasfaser\\ Multimode\end{tabular} & 400m \\ \hline 10GBASE-LR & \(10\frac{GBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Glasfase\\ Singlemode\end{tabular} & 10km \\ \hline \end{tabular} \caption{Auszug von Ethernet Übertragungsstandards nach IEEE 802.3} \label{tab:ethernet} \end{table} \subsubsection{PoE} \label{sssec:PoE} PoE ist die Abkürzung für \textbf{P}ower \textbf{o}ver \textbf{E}thernet und meint damit die Funktion neben den Daten zusätzlich die Stromversorgung für kleinere Netzwerkgeräte über ein Twisted-Pair-Kabel zu ermöglichen. PoE wird ebenfalls im IEEE 802.3 \cite{Ethernet} Standard definiert. Eingeführt wurde PoE 2003 in IEEE 802.3af mit einer Leistung von 15 Watt. Seit dem wurde PoE erweitert um mehr Leistung bieten zu können. Dies geschah mit den Standards 802.3at und 802.3bt. Die erste Erweiterung wird auch als PoE+ bezeichnet und kann 30 Watt je Port zur Verfügung stellen. Der aktuelle Stand wird auch PoE++ genannt. Bei der Verwendung von PoE++ wird zwischen dem Typ 3 und 4 unterschieden, da Typ 3 60 Watt leisten kann und Typ 4 100 Watt. Die Spannungen auf dem Ethernetkabel liegen bei PoE zwischen 44 und 57 Volt. \par PoE wird unter anderem oft für Telefone, Kameras und AccessPoints eingesetzt. \subsection{USBIP} \section{Hardware} In diesem Abschnitt wird zunächst die allgemeine Funktionalität von GNSS-Hardware allgemein und speziell der aktuell auf dem Rover verbauten erklärt. Darauf folgt die Funktionsbeschreibung von PoE-Hardware die zur späteren Anbindung der RTK-Basisstation benötigt wird. In dem Abschnitt \ref{sec:PoE-Hardware} wird auf die konkret verwendete PoE-Hardware eingegangen, während Abschnitt \ref{sec:GNSS-Hardware} die Auswahl der GNSS-Hardware für die Basisstation beschreibt. \subsection{GNSS-Modul} Auf dem Markt sind eine vielzahl von GNSS-Modulen erhältlich. Dessen allgemeine Aufgabe es immer ist die Position auf der Erde durch die über eine Antenne Empfangen Signale zu bestimmen. Die erhältlichen Module unterscheiden sich hauptsächlich in der Genauigkeit und der verfügbaren Features. Die günstigsten Module bieten keine Möglichkeit die Rohdaten auszugeben oder Korrekturdaten einzuspeisen, weshalb sich weder extern und intern Fehlerkorrekturen anwenden lassen und somit die Genauigkeit im 10 Meter Bereich liegt. Bei professionelleren Modulen kann beides möglich sein, wodurch sich Positionsbestimmungen im niedrigen Centimeter Bereich realisieren lassen. \par In dem Rover ist ein GNSS-Chip von u-blox auf einem Entwicklungsmodul von Sparkfun verbaut. Der Chip wird unter dem Namen ZED-F9K-00B vermarktet. Dem Datenblatt des Herstellers \cite{zed-f9k} sind folgende Informationen zu entnehmen. Das Modul unterstützt die Bänder L1/L2/E5b, damit können die Daten von den GNSSystemen BeiDou, Galileo, GLONASS und GPS verarbeitet werden. Unter normalen Bedingungen ist die Position bei einem Kaltstart nach spätestens 30 Sekunden ermittelt und bei einem Warmstart nach 2 Sekunden. In dieses Modul können Korrekturdaten eingespeist werden, allerdings ist es nicht in der Lage diese zu erzeugen. Im RTK-Modus ist die Genauigkeit mit 0,2 Meter angegeben. \subsection{GNSS-Antenne} Die Antennen von GNSS-Modulen können extern ausgeführt werden oder direkt am Modul verbaut sein und dienen dazu die Signale der Satelliten zu empfangen. Dabei bieten externe Antennen den Vorteil unabhängig und für den Empfang optimiert aufgestellt/verbaut werden zu können. Für externe Antenne steht häufig mehr Platz zur Verfügung, deshalb wird Empfangsqualität nicht durch mangelnden Bauraum beeinflusst. \par Die auf dem Rover extern installierte Antenne wurde wie das GNSS-Modul ebenfalls von u-blox entwickelt und auf die F9-Reihe abgestimmt. Dabei handelt es sich laut Datenblatt \cite{antenneKlein} um eine aktive Antenne welche die Bänder des GNSS-Moduls unterstützt und darüber hinaus noch die Bänder B2a und NavIC. Das Gehäuse der Antenne misst 60mm x 82mm, wobei die Position der eigentlichen im Gehäuse zentriert ist. Angeschlossen wir die Antenne über einen SMA-Stecker. \subsection{PoE Hardware} \subsubsection{PoE Extender} Ein PoE Extender wird dafür genutzt die Reichweite eines mit PoE versehenen Twisted-Pair-Kabel zu verlängern. Die Reichweite wird durch die begrenzte Segmentlänge des verwendeten Mediums beschränkt. Im Fall von Twisted-Pair-Kabeln beträgt diese \(100m\). Der Extender nutzt die über PoE verfügbare Energie zur Signalaufbereitung und gibt das Signal inklusive PoE wieder aus, dabei ist zu beachten, dass aufgrund der verbrauchten Energie das ausgangsseitige PoE um einen Typen verringert wird und somit weniger Leistung zur Verfügung stellt. \par Speziellere Extender können zusätzlich als Switch fungieren. Diese Extender verfügen typischerweise über zwei Ethernet Ausgänge. Die verfügbare PoE Leistung wird dann auf diese beiden Ports aufgeteilt. !!!Datenblatt!!! \subsubsection{PoE Splitter} Der PoE Splitter trennt die Daten und den Strom vom Ethernetkabel. Diese Geräte haben typischerweise drei Anschlüsse, dabei ist der erste der PoE Eingang. Bei den anderen beiden handelt es sich um die Ausgänge für die Daten und den Strom. Bei dem Anschluss für die Daten ohne Strom handelt es sich normalerweise wieder um ein Ethernet anschluss mit einer RJ-45 Buchse. Der Strom wird über Anschlussklemmen oder einen Terminalblock ausgegeben. Die Ausgegebene Spannung hängt von dem gewählten Splitter ab, wird aber meistens von der höheren PoE Spannung (siehe Unterabschnitt \ref{sssec:PoE}) auf typische Spannungen von Netzteilen wie \(12V\) reduziert. !!!Datenblatt!!! \section{Software} Im folgenden wird die benötigte Software für diese Arbeit beschrieben. Dabei wird zunächst das Betriebssystem der Basisstation beschrieben, gefolgt von der verwendeten Software mit spezifischen Bezug auf die GNSS-Thematik. \subsection{Debian} \label{ssec:debian} Als Betriebssystem wird das freie Debian ohne grafische Oberfläche verwendet. Debian ist eine GNU/Linux-Distribution, welche bereits seit 1993 entwickelt und weiterentwickelt wird und als Basis für viele weitere sehr erfolgreichen und bekannten Betriebssystemen wie Ubuntu verwendet wird. Daher kann Debian als ein stabiles und hartes Betriebssystem angesehen werden, welches auch in der Industrie für viele Server eingesetzt wird und bei Cloud-Services als Betriebssystem für virtuelle Maschinen angeboten wird. \subsubsection{Systemd} Systemd wird von dem Wiki Ubuntuusers\cite{systemd} als ein Teil des Betriebssystems, welcher für die Verwaltung und das Starten der Dienste des Systems zuständig ist, da alle Prozesse während des Bootvorgangs von Systemd gestartet werden erhält Systemd immer die Prozess-ID 1. \par Die Konfiguration erfolgt über eine Datei für jeden Service, in welcher unter anderem folgende Einstellungen getätigt werden können: \begin{itemize} \item eine Kurzbeschreibung des Service, \item eine Bedingung für den Start, \item die Art des Service, \item das als Service auszuführende Programm \item und den Betriebsmodus des Betriebssystems. \end{itemize} Durch dieses System wird es ermöglicht, dem Betriebssystem mit geringen Entwicklungsaufwand weitere Services hinzuzufügen, was in dieser Arbeit für Installation der Basisstation von Vorteil ist. \subsection{ser2net} Die auf GitHub und über die Paketquellen von Debian veröffentliche Software ser2net\cite{ser2net} wird dem Betriebssystem bei Installation als Service hinzugefügt. Mit diesem Service können unter anderem verfügbare Geräte mit einem seriellen Interface dem Netzwerk über eine TCP-Verbindung zugänglich gemacht werden. Dafür müssen die zu veröffentlichen Interfaces inklusive der verwendeten Einstellungen wie die Baudrate in der Konfigurationsdatei unter dem Pfad \url{/etc/ser2net/ser2net.yaml} definiert werden. \par Dadurch ist es möglich das GNSS-Modul der Basisstation, der U-Blox Software (siehe Abschnitt \ref{sssec:u-blox}) auf einem im Netzwerk erreichbaren Computer mit Windows als Betriebssystem zur Verfügung zu stellen. \subsection{com0com und com2tcp} Diese beiden Programme bilden das Gegenstück zu ser2net auf einem Computer mit Windows als Betriebssystem. Dabei stellt das Programm den Treiber für virtuelle COM-Ports zur Verfügung und ermöglicht es mehrere dieser virtuellen Ports miteinander zu verbinden. Dies ist nötig, weil nur ein Programm zur Zeit auf einen COM-Port zugreifen kann. Durch die Brücke von zwei virtuellen COM-Ports kann ein Port von der U-Blox Software genutzt werden. \par Der andere Port wird von dem zweiten Programm (com2tcp) genutzt um die Verbindung zu ser2net herzustellen. Dafür muss die IP-Adresse des Servers und der Port auf dem das Interface veröffentlicht wird bekannt sein. \subsection{GNSS} Dieser Abschnitt beschreibt Programme die direkt mit GNSS-Modul interagieren oder dessen Daten verarbeiten. \subsubsection{GNSS PostProcessing} Für die Errichtung einer Basisstation muss die Position der Antenne möglichst exakt bestimmt werden. Die exakteste Möglichkeit bieten dafür sogenannte Post Processing Dienste. Um diese Nutzen zu können muss der Receiver zunächst die Beobachtungsdaten erstellen und diese im Anschluss im RINEX-Format an der Post Processing Dienst senden. \par Für die Einmessung der zu errichtenden Basisstation wird in dieser Arbeit der kostenlose Service Canadian Spatial Reference System Precise Point Positioning (CSRS-PPP) \cite{canada} genutzt. Zur Berechnung nutzt dieser globale Bahn- und Uhrendaten der Satelliten. Nachdem die Beobachtungsdaten übersendet wurde, wird nach ein paar Stunden, das Ergebnis per E-Mail übersandt. Neben den berechneten Koordinaten mit angaben zur Genauigkeit, werden Graphen der beobachteten Satelliten dargestellt. Durch diese Graphen kann kontrolliert werden ob die Antenne freie Sicht auf den Himmel hatte. \subsubsection{RTKLib} \label{sssec:rtklib} Die RTKLib\cite{rtklib} ist eine Sammlung von Open Source Programmen für GNSS Positionierung. Für Windows gibt es die Programme fertig compiliert und mit einer grafischen Oberfläche, zur Nutzung unter Linux muss der Quellcode eigenständig compiliert werden. Die Hälfte der Programme verfügt über eine CLI und ist somit ohne grafische Benutzeroberfläche nutzbar. Aus dieser Sammlung sind für diese Arbeit zwei der Programme von Bedeutung, welche auch beide über eine CLI verfügen. \begin{itemize} \item \textbf{Communication Server} - Für die Verwendung können mehrere Ein- und Ausgänge konfiguriert werden. Die Eingänge werden zusammengeführt und an alles Ausgänge weitergeleitet. Der Eingang ist in dem Kontext dieser Arbeit immer das GNSS-Modul und der Ausgang ist entweder ein NTRIP-Caster oder eine Datei. Die Ausgabe in der Daten in eine Datei ermöglicht es die Beobachtungsdaten zu persistieren. \item \textbf{RINEX Converter} - Mit diesem Konverter können die Beobachtungsdaten, welche im proprietären Format von U-Blox vorliegen in das RINEX-Format konvertiert werden. \end{itemize} \subsubsection{u-center} \label{sssec:u-blox} Das u-center\cite{u-center} ist laut dem Hersteller u-blox eine GNSS Evaluierungssoftware für Windows. \par Mit dieser lassen sich die Module von u-blox konfigurieren und die eingehenden Daten der Satelliten und des Moduls analysieren und loggen. Besonders die grafische Möglichkeit der Konfiguration erleichtert den Umgang mit diesen Modulen. Für die Evaluation lassen sich Graphen mit die den Drift der Position, die Laufbahn der Satelliten, die Anzahl der Satelliten mit Signalpegel und weitere Werte anzeigen. \par Das Programm bietet zusätzlich Tools an um als NTRIP-Client zu fungieren oder Daten mittels MQTT zu versenden. \subsubsection{RTK2go} \label{ssec:rtk2go} RTK2go\cite{rtk2go} ist kostenlos nutzbarer NTRIP-Caster. Damit eine Basisstation sich mit RTK2go verbinden kann, muss diese zunächst registriert werden, damit eine Mount Point erstellt werden kann. Anschließend können Korrekturdaten über den Caster veröffentlicht werden dabei kann jeder auf die veröffentlichten Daten zugreifen. Als Client zur Datennutzung muss lediglich als Benutzername eine valide E-Mail Adresse hinterlegt werden, die ausschließlich als Kanal für Fehlermeldungen mit der Verbindung genutzt wird. Eine Registrierung als Rover ist daher nicht notwendig.