www.albrecht57.de -

Im Internet existiert eine riesige Sammlung aller Ephemeriden von GPS-Satelliten seit 1992. Diese wird von der NASA unter der URL

https://cddis.nasa.gov

zur Verfügung gestellt. Man läuft schnell Gefahr, in dieser enormen Datensammlung verloren zu gehen, deshalb nachfolgend eine schrittweise Anleitung, wie man schnell zu den richtigen Daten gelangt. Auf der Eingangsseite wählt man im Menü "Data and Products" den EIntrag "GNSS":

Auf der folgenden Seite wählt man links den Eintrag "Broadcast ephemeris data":

Auf der nächsten Seite geht es weiter mit dem Link https://cddis.nasa.gov/archive/gnss/data/daily, den man abkürzend natürlich auch direkt aufrufen kann:

Dieser Link führt quasi auf einen ftp-Server, auf welchem die Jahre als Unterverzeichnisse aufgeführt sind:

Nach der Auswahl des gewünschten Jahres kommt man auf eine Seite, auf welcher die Tage dieses Jahres als Unterverzeichnisse aufgeführt sind. Diese Aufzählung scrollt man ganz nach unten und wählt den letzten Eintrag "brdc".

Die folgende Seite enthält zwei verschiedene Ephemeridensammlungen des gewählten Jahres. Für uns ist die zweite Gruppe relevant, die sich auf dieser Seite weiter unten befindet.

Die für uns interessanten Ephemeriden-Sammlungen haben die Bezeichnung brdcDDD0.YYn.gz, wobei DDD die dreistellige Angabe des gewünschten Tages im gewählten Jahr ist und YY die zweistellige Angabe des Jahrs. Wichtig nach der Jahresangabe ist der Kleinbuchstabe "n", da dieser die GPS-Ephemeriden bezeichnet. Dateien mit dem Kennbuchstaben "g" enthalten die GLONASS-Ephemeriden.

Die gewünschte Datei wird durch Anklicken ausgewählt und heruntergeladen. Nach dem Entpacken, das vom jeweiligen Betriebssystem i.d.R. automatisch vorgenommen wird, kann die Datei in einem Texteditor geöffnet werden:

Die Datei enthält die Ephemeriden aller Satelliten des gewählten Tags, so wie diese im zweistündigen Abstand von den Satelliten erneuert und ausgestrahlt wurden.

Fehlen in der selbst aufgezeichneten und erstellen RINEX-Navigationsdatei aus irgendwelchen Gründen die Ephemeriden von einem oder mehreren Satelliten, so können die Ephemeriden des fehlenden Satelliten zur benötigten Uhrzeit aus der CDDIS-Datei kopiert und in die eigene Datei eingefügt werden.

Hat man selbst gar keine Navigationsdatei aufgezeichnet, so kann man sich behelfen, indem in der CDDIS-Datei die Ephemeriden aller nicht benötigten Zeitpunkte gelöscht werden und nur die Ephemeriden derjenigen Satelliten dort verbleiben, von denen man Beobachtungsdaten aufgezechnet hat. Wichtig ist allerdings, dass der Header in der Datei verbleibt, da Maxima beim Einlesen der Datei auf die Zeile "END OF HEADER" angewiesen ist!

Details: Zugriffe: 47

Anpassung an die von RTKCONV erzeugte OBS-Datei

Unterschiede in den RINEX-Dateien

Die mit den neueren Chips NEO-M8P-2 und ZED-F9P erzeugten ubx-Dateien können nicht mehr mit dem Programm teqc in RINEX-Dateien konvertiert werden, vielmehr kann nun das benutzerfreundlichere Programm RTKCONV verwendet werden. Leider lässt sich RTKCONV nicht umgekehrt zur Konvertierung der mit dem NEO-6P-Chip generierten Aufnahmen verwenden, da es die jeweiligen NAV-Dateien nicht erzeugt. Im Gegensatz zu den von teqc erzeugten RINEX-Beobachtungsdaten liefert RTKCONV diese Dateien allerdings in einer leicht veränderten Struktur, so dass wir die im Buch vorgestellten Transferfunktionen verändern müssen.

Zum Vergleich der Beginn einer traditionell mit teqc erstellten Beobachtungsdatei:

Im Unterschied dazu dieselbe Beobachtungsdatei, die von RTKCONV erstellt wurde:

Die Beobachtungscluster werden in beiden Versionen immer von einer Einleitungszeile mit dem Aufnahmedatum und der Aufnahmezeit sowie der Anzahl der empfangenen Satelliten eingeleitet. Während in der teqc-Version darauf unmittelbar die Nummern der Satelliten folgen, schreibt RTKCONV diese Satellitennummern als erste Spalte in den Beobachtungsblock, so dass die Zeilen den einzelnen Satelliten schnell und eindeutig zugeordent werden können.

In der Einleitungszeile der RTKCONV-Version wird die Jahreszahl vierstellig angegeben, außerdem beginnt diese Zeile mit einem ">"-Zeichen. Dadurch erhöhen sich die Indices der weiteren Listenelemente um eins.

Die Pseudoentfernungen stehen in der teqc-Version in der dritten Spalte, während diese in der RTKCONV-Version direkt nach den Satellitennummern in der zweiten Spalte aufgeführt werden.

Diese strukturellen Unterschiede sind im Übrigen unabhängig von der in RTKCONV gewählten RINEX-Version, so dass für die Nutzung der neueren GPS-Chips die Maximafunktionen zum Erstellen der "obsmatrix" verändert werden müssen.

Die Navigationsdatei ist nur marginal verändert: Eine von RTKCONV erzeugte Navigationsdatei gibt die Satellitennummer immer dreistellig mit vorangstelltem "G" als Kennung für einen GPS-Satelliten an, außerdem wird die Jahreszahl des Datums wie in der Beobachtungsdatei vierstellig angegeben. Diese Unterschiede hat aber für den Einlesevorgang keine Auswirkung, sie wurden bereits mit der im Buch vorgestellten Funktion zum Erstellen der "navmatrix" berücksichtigt.

Anpassung einzelner Funktionen

Um jeweils beide Versionen der zu verändernden Funktionen behalten zu können, wird als Unterscheidungsmerkmal jeweils die Ziffer "8" an die neuen Versionen angehängt.

read_obstime()

Die Funktion zum Lesen der Beobachtungszeit muss aufgrund des in der Einleitungszeile vorangestellten ">"-Zeichens und der nun vierstellig angegebenen Jahreszahl verändert werden. Die Indices werden jeweils um eins erhöht und die Addition von 2000 zur Jahreszahl entfällt:

read_obstime8(zeile):=
gps_time(julday(zeile[2],zeile[3],zeile[4],zeile[5],zeile[6],zeile[7]));

read_satnr()

Zum Lesen der jeweiligen Satellitennummer und zur Überprüfung, ob es sich um einen GPS-Satelliten handelt, von welchem zudem Navigationsdaten vorliegen, muss die Funktion read_satnr() angepasst werden. Durch den einfacheren Aufbau der Beobachtungsdatei, wo nun Satellitennummer und Pseudoentfernung jeweils direkt nebeneinander in einer Zeile stehen, wird diese Funktion etwas einfacher:

read_satnr8(eintrag):=block(
[zeichenkette,z,e,navsatlist],
zeichenkette:string(eintrag),
satnr:if charat(zeichenkette,1)="G" then
(
z:eval_string(charat(zeichenkette,2)),
e:eval_string(charat(zeichenkette,3)),
z*10+e
)
else 0,
navsatlist:make_navsatlist(),
if member(satnr,navsatlist) then satnr else 0
);

make_obslist()

Die Beobachtungen eines Zeitpunkts werden durch die Funktion make_obslist() in einer Liste zusammengefasst. Auch diese Funktion wird leicht verändert:

make_obslist8(rinex_obsdata,z_nr):=block(
[satanzahl,beobachtungen,sat_nr],
satanzahl:rinex_obs[z_nr][9],
time:read_obstime8(rinex_obsdata[z_nr]),
beobachtungen:[time,satanzahl],
for i:z_nr+1 thru z_nr+satanzahl do
(
sat_nr:read_satnr8(rinex_obsdata[i][1]),
prange:rinex_obsdata[i][2],
if sat_nr#0 then beobachtungen:endcons([sat_nr,prange],beobachtungen)
),
beobachtungen
);

make_obsmatrix()

Damit wird auch eine neue Version der Funktion für die Zusammenstellung aller Beobachtungszeitpunkte in der globalen Datenstruktur obsmatrix nötig:

make_obsmatrix8(rinex_obsdata):=block(
[z_nr,ranges_at_time,num_sats,svlist],
obsmatrix:[],
z_nr:1,
while z_nr<length(rinex_obsdata) do

(
ranges_at_time:make_obslist8(rinex_obsdata,z_nr),
obsmatrix:endcons(ranges_at_time,obsmatrix),
num_sats:rinex_obsdata[z_nr][9],
z_nr:z_nr+num_sats+1
),
svlist:[],
print(length(obsmatrix),"Beobachtungen"),
for obs in obsmatrix do
(
for i:3 thru length(obs) do
svlist:endcons(obs[i][1],svlist),
print(obs[1][2],sort(svlist)),
svlist:[]
),
obsmatrix);

einlesen()

Schließlich ändern wir noch die Funktion einlesen() zum komfortablen Einlesen der Daten in Maxima. Dort muss lediglich der Aufruf der veränderten Funktion make_obsmatrix8() angepasst werden:

einlesen8():=block(
name:read_name(),
pfad:make_path(name),
rinex_nav:read_rinex(pfad[1]),
make_navmatrix(rinex_nav),
rinex_obs:read_rinex(pfad[2]),
make_obsmatrix8(rinex_obs),
return(true));

Da diese angepassten Funktionen aufgrund der Verwendung des ublox NEO-M8P-2 nötig wurden, sind eben diese Funktionen durch Anhängen der Ziffer "8" an den usrprünglichen Funktionsnamen unterscheid- und zuordenbar.

Anpassung an die OBS-Dateien aus Misra/Enge: GPS

Auf der Homepage zum Buch von Misra und Enge sind RINEX-Dateien von drei Orten (Durmid Hill, Piegeon Point und Vandenberg) eingestellt. Diese Daten sind allerdings sehr umfangreich: Es sind jeweils über einen ganzen Tag Aufnahmen im Halbminutentakt und damit 24 x 60 x 2 = 2.880 Messungen in einer Beobachtungsdatei enthalten. Auch die Navigationsdatei enthält die Ephemeriden aller empfangenen Satelliten im Zweistundentakt. Diese exorbitanten Datenmengen sprengen unseren Rahmen bei weitem. Um nun nicht unzählige Maxima-Funktionen anpassen zu müssen, kürzen wir besser die vorliegenden und uns interessierenden Dateien. Für die beiden Dateien vb091800.nav und vb091800.obs aus dem Verzeichnis Data/Vandenberg/September_18_2000 wurde eine mögliche Kürzung beispielhaft durchgeführt. Die gekürzten Dateien vb091800_nav.txt und vb091800_obs.txt sind über den Menüpunkt Empfängerpositionen erreichbar.

Zunächst ist es sinnvoll, sich auf eine Zwei-Stunden-Periode des Aufnahmetags festzulegen, innerhalb derer einige Messungen ausgewertet werden sollen. Für die genannten Beispiele wurde die Periode von 12 bis 14 Uhr gewählt. Dies bedeutet, dass in der Navigationsdatei nur diejenigen Ephemerideneinträge belassen werden, welche eine Ausgabezeit von 12 Uhr haben. Dabei muss man ggf. auch Ausgaben von 13:59 Uhr tolerieren. Allerdings darf jeder Satellit im gewählten Zeitfenster nur einmal auftreten, es darf keine Doubletten geben. Alle vorhergehenden Einträge ab 0 Uhr bis 10 Uhr und alle folgenden Einträge ab 14 Uhr werden in der RINEX-NAV-Datei gelöscht. Dabei muss allerdings der Header erhalten bleiben, da sonst das Einlesen über Maxima mit den bereits erstellten Funktionen nicht korrekt arbeitet. Schließlich muss man auch darauf achten, dass am Ende der gekürzten Datei nicht noch Leerzeilen vorhanden sind!

Hat man sich nun durch Auswahl der Ephemeriden auf einen Zwei-Stunden-Zeitraum festgelegt, so sollte man in der Beobachtungsdatei aus eben diesem Zeitraum einige wenige aufeinanderfolgende Aufnahmen auswählen (2 – 3 sind schon völlig ausreichend) und alle zeitlich davor und dahinterliegenden Aufnahmen konsequent löschen! in der Beispieldatei sind sechs Aufnahmezeitpunkte von 12:06:00 bis 12:08:30 enthalten. Auch in der Beobachtungsdatei muss der Header ganz am Anfang erhalten bleiben!

Die Beobachtungsdaten von Pigeon Point und Vandenberg sind alle genau gleich strukturiert:

Zunächst fällt auf, dass in den hier blau umrandeten Einleitungszeilen zu den einzelnen Messungen Leerzeichen zwischen dem Großbuchstaben "G" und der Satellitennummer enthalten sind. Dies ist bei allen einstelligen Satellitennummern der Fall. Erst in späteren Jahren wurde im RINEX-Format statt des Leerzeichens eine führende Null vorangestellt. Um unsere Maxima-Einlesedateien nicht verändern zu müssen, ist es einfacher, diese Veränderung per "Suchen und Ersetzen" im Texteditor innerhalb der bereits gekürzten Beobachtungsdatei vorzunehmen. Man lässt nach "G " (G und Leerzeichen) suchen und durch "G0" (G und Ziffer Null) ersetzen. Damit hat man dieses Problem elegant aus der Welt geschafft.

Als nächstes fällt auf, dass für jeden Satellit jeweils sieben Messwerte angegeben sind und daher ein Zeilenumbruch innerhalb der Werte eines Satelliten vorkommt. Die beiden letzten Werte in der Folgezeile sind sowohl positiv als auch negativ, außerdem kann es sich bei diesen Werten offensichtlich nicht um die von uns benötigten Pseudoranges handeln. Wir löschen somit konsequent die kompletten Zeilen mit den oben rot hinterlegten Werte in allen Messungen der gekürzten Beobachtungsdatei!

Bei genauerem Hinschauen stellt man fest, dass je drei der verbliebenen fünf Zahlen fast identische Werte aufweisen und es sich dabei um unsere Pseudoentfernungen handeln könnte. Dies führt zu der Frage, welche Messwerte denn für jeden Satelliten aufgeführt sind. Hierüber gibt der Header Auskunft: Aus der oben grün umrandeten Angabe geht hervor, dass jeweils sieben Beobachtungsdaten angegeben sind und zwar in der Reihenfolge: C1 L1 L2 P1 P2 D1 D2

Um zu erfahren, welche Daten konkret aufgeführt sind, zieht man die Rinex-Spezifikation RINEX.txt im Verzeichnis Documents heran. Dort erfährt man die folgende Zuordnung:

C1 : Pseudorange using C/A-Code on L1
L1, L2: Phase measurements on L1 and L2
P1, P2: Pseudorange using P-Code on L1, L2
D1, D2: Doppler frequency on L1 and L2

Die Zeilen mit den beiden letzten Angaben haben wir somit zurecht gelöscht, da es sich hierbei um nicht von uns benötigte Angaben zur Dopplerfrequenz handelt.

Gleich der Wert C1 in der ersten Spalte ist somit der von uns benötigte Pseudoentfernungswert, welcher aus dem C/A-Code der öffentlichen L1-Frequenz gewonnen wurde.

Dann folgen zwei Werte, welche sich auf die Messung der Codephase der Trägerwelle beziehen. Diese sind für uns ebenfalls uninteressant.

Die Aufnahmen wurden offensichtlich mit militärischen Empfängern gemacht. Die geht aus den nächsten Daten P1 und P2 hervor. Dabei handelt es sich ebenfalls um Pseudoentfernungen, welche im ersten Fall allerdings aus dem P-Code der L1 Frequenz und im zweiten Fall aus dem P-Code der L2-Frequenz gewonnen wurden. Wir erinnern uns, dass der verschlüsselte P-Code nur von militärischen Empfängern ausgewertet werden kann. Für uns könnte es interessant sein, Positionsbestimmungen mit diesen verschiedenen Pseudoentfernungen vorzunehmen und die Ergebnisse miteinander zu vergleichen. Dies insbesondere bei Dateien, bei welchen die Selective Availability noch eingeschaltet war. Dies geht jeweils aus der Datei readme.txt hervor, welche sich im Verzeichnis der RINEX-Dateien befindet.

Aufgrund unserer Vorarbeiten und der etwas anderen Anordnung der Pseudoentfernungen in der Beobachtungsdatei müssen wir nur eine Maxima-Funktion ändern. Es handelt sich dabei um die Funktion read_prange_rinex(), mit welcher die Pseudoentfernungen aus der RINEX-Datei ausgelesen werden. Diese Funktion hat im Original die Form:

read_prange_rinex(rinex_obsdata,cluster,i):=block(
[prange],
prange:rinex_obsdata[cluster+i][2],
if prange<10 then prange:rinex_obsdata[cluster+i][3],
prange);

Wir können diese Funktion zum Einlesen dieser Dateien kürzer fassen:

read_prange_rinex(rinex_obsdata,cluster,i):=
rinex_obsdata[cluster+i][1];

So wie diese Funktion hier mit dem Index [1] angegeben ist, wird der "übliche", aus dem C/A-Code gewonnene Wert für die Pseudoentfernung ausgelesen. Verwendet man stattdessen den Index [4], so erhält man den aus dem P-Code und der L1-Frequenz ermittelten Pseudorangewert und mit [5] erhält man den Pseudorange aus dem P-Code und der L2-Frequenz.

Für das Experimentieren mit den Daten aus dem Buch von Misra und Enge ist es am sinnvollsten, zunächst die vorhandene Maxima-Bibliothek zu laden und dann die Funktion read_prange_rinex() mit der eben vorgestellten Fassung zu überschreiben.

Die Beobachtungsdaten von Durmid Hill weichen leider ebenfalls ein wenig vom eben vorgestellten Format ab. Zunächst sind diese Dateien für unsere Zwecke ebenfalls viel zu umfangreich und müssen, genau wie oben dargestellt, gekürzt werden!

Dann wurde eine Konvertierung verwendet, die ausschließlich GPS-Satelliten voraussetzt, so dass daruaf verzichtet wurde, den Buchstabe "G" jeweils den Satellitennummern voranzustellen. Es dürfte wieder am Einfachsten sein, diese Ersetzungen in der gekürzten Beobachtungsdatei von Hand vorzunehmen. Dabi muss darauf geachtet werden, dass für jede Satellitenbezeichnung genau drei Stellen zur Verfügung stehen. Statt "1" also "G01", statt "13" eben "G13" usf.

Die uns interessierenden Pseudoentfernungen stehen in der dritten (C1), vierten (P1) bzw. fünften (P2) Spalte. Je nachdem, mit welchen Pseudoentfernungen man rechnen will, muss die zugehörige Spaltennummer als Index in der Funktion read_prange_rinex() angegeben werden.

Details: Zugriffe: 182

Für all diejenigen, die keinen Rohdatenempfänger besitzen, sind auf dieser Seite einige Dateien zum eigenen Nachvollziehen der Positionsbestimmung zusammengestellt. Dabei handelt es sich zunächst um die vom Programm u-center generierte proprietäre ubx-Datei. Diese muss mittels teqc oder RTKCONV in eine RINEX-Beobachtungs- und -Navigationsdatei konvertiert werden. Wer auch diesen Schritt scheut, kann hier auf die Beobachtungs- und Navigationsdaten der jeweiligen Aufnahme im RINEX-Format zugreifen. Außerdem ist zu jeder Aufnahme eine passende Almanach-Datei vorhanden. Für die Überprüfung des selbst ermittelten Ergebnisses gibt es ein Bildschirmfoto mit der von u-center berechneten Aufnahmeposition. Manchmal liegen zudem Fotos vom Aufnahmeort vor, so dass ein direkter Vergleich markanter Geländepositionen in Google Maps vorgenommen werden kann. Die Dateien der ersten Tabellenzeile ("sonnenpfad"-Dateien) bilden die Grundlagen für alle im Buch dargestellten Berechnungen.

Empfänger: Navilock NL6002U mit ublox NEO-6P

Die Empfängerdaten dieses Abschnitts können mit den im Buch beschriebenen Verfahren ausgewertet werden.

ubx-Datei	Beobachtungsdatei	Navigationsdatei	Almanachdatei	Position in u-center	Foto
sonnenpfad.ubx	sonnenpfad_obs.txt	sonnenpfad_nav.txt	sonnenpfad_alm.txt	sonnenpfad_uc.png	sonnenpfad.jpg
dorfer.ubx	dorfer_obs.txt	dorfer_nav.txt	dorfer_alm.txt	dorfer_uc.jpg
flochberg.ubx	flochberg_obs.txt	flochberg_nav.txt	flochberg_alm.txt	flochberg_uc.jpg
freilass.ubx	freilass_obs.txt	freilass_nav.txt	freilass_alm.txt	freilass_uc.jpg	freilass.jpg
golfplatz.ubx	golfplatz_obs.txt	golfplatz_nav.txt	golfplatz_alm.txt	golfplatz_uc.jpg
hellenstein.ubx	hellenstein_obs.txt	hellenstein_nav.txt	hellenstein_alm.txt
kulturzentrum.ubx	kulturzentrum_obs.txt	kulturzentrum_nav.txt	kulturzentrum_alm.txt	kulturzentrum_uc.jpg	kulturzentrum.jpg
speyerdom.ubx	speyerdom_obs.txt	speyerdom_nav.txt	speyerdom_alm.txt	speyerdom_uc.jpg
steinbruch.ubx	steinbruch_obs.txt	steinbruch_nav.txt	steinbruch_alm.txt	steinbruch_uc.jpg
timmersdorf.ubx	timmersdorf_obs.txt	timmersdorf_nav.txt	timmersdorf_alm.txt	timmersdorf_uc.jpg

Empfänger: SparkFun GPS-RTK Board (GPS-15005) mit ublox NEO-M8P-2

Die Daten dieses Empfängers wurden mit RTKCONV in RINEX-Dateien der Version 3 konvertiert. Dies hat eine alternative Struktur der Beobachtungsdatei zur Folge, so dass die im Buch beschriebenen Routinen für das Einlesen der RINEX-Beobachtungsdatei verändert werden müssen! Hinweise dazu befinden sich unter dem Menüeintrag Anpassungen in Maxima.

ubx-Datei	Beobachtungsdatei	Navigationsdatei	Almanachdatei	Position in u-center	Foto

Empfänger: SparkFun GPS-RTK Board (GPS-16481) mit ublox ZED-F9P

Da die Daten dieses Empfängers ebenfalls mit RTKCONV in RINEX-Dateien der Version 3 konvertiert wurden, gilt das oben Gesagte zu den benötigten alternativen Einleseprozeduren hier ebenfalls.

ubx-Datei	Beobachtungsdatei	Navigationsdatei	Almanachdatei	Position in u-center	Foto

Beispieldateien des Buchs: "Global Positioning System" von Misra und Enge

Das empfehlenswerte Buch von Pratap Misra und Per Enge: "Global Positioning System – Signals, Measurements and Performance" verweist auf eine zum Buch gehörige WWW-Seite: https://www.gpstextbook.com. Von dieser Seite können weitere Daten (OBS- und NAV-Dateien im RINEX-Format) zur Positionsbestimmung bezogen werden. Es handelt sich dabei um Aufnahmen, die mit militärischen Empfängern erstellt wurden, so dass die benötigten Pseudoranges in den Beobachtungsdaten gleich dreimal enthalten sind: Zunächst als Pseudoentfernungen, welche aus dem C/A-Code der L1-Frequenz gewonnen wurden, dann aber zusätzlich auch als Pseudoentfernungen, die aus dem verschlüsselten P-Code erstellt wurden, der zum einen auf der L1 und auch auf der L2-Frequenz gesendet wird. Da auch Aufnahmen mit aktiver Selective Availability und eine Angabe zur exakten Empfängerposition in der Sammlung enthalten sind, können Vergleiche mit der jeweils erzielbaren Genauigkeit angestellt werden.

Da die Aufnahmen jeweils über einen ganzen Tag erfolgten, sind diese RINEX-Dateien sehr umfangreich und zudem in ihrer Struktur ebenfalls leicht verändert, so dass die Dateien insbesondere gekürzt und Funktionen in Maxima angepasst werden müssen. Konkrete Hinweise dazu befinden sich unter dem Menüeintrag Anpassungen in Maxima. Hier ist ein Paar beispielhaft gekürzter Dateien (Vandenberg vom 18.09.2000) verfügbar:

vb091800_nav.txt und vb091800_obs.txt

Details: Zugriffe: 180

Hinweise zum Programm u-center

Programminstallation

Die Firma ublox stellt das Programm u-center als Analysetool für ihre GPS-Chips zur freien Verfügung. Es bietet ein Unzahl an Möglichkeiten, Chips zu konfigurieren und deren Status auszulesen. So lange man nicht genau weiß, was man tut, sollte man keine Konfigurationsänderungen in die Chips zurückspeichern. Zu groß ist die Gefahr unerwünschter Resultate! Uns dient u-center nur für die Aufzeichnung der vom Empfängerchip generierten Rohdaten.

Das Programm ist über die Homepage von ublox erhältlich. Von dort kann die jeweils neueste Version heruntergeladen werden. Leider treten bereits bei der Installation des Programms Probleme auf:

Beim erstmaligen Aufruf des Programms kann eine Fehlermeldung erscheinen, welche besagt, dass die Bibliotheksdateien msvcp120.dll und msvcr120.dll nicht gefunden werden können. Diese Dateien sind in aller Regel im Verzeichnis Windows/System32 vorhanden. Kopiert man beide Dateien in das Verzeichnis Windows/SystemWOA, dann erscheint diese Fehlermeldung nicht mehr.

Die gerade aktuelle u-center-Version 21.02 bricht u.U. sofort nach dem Start ab! Eine Ursache hierfür konnte noch nicht ermittelt werden.

Problemlos läuft allerdings die Version 19.11.01, die wie andere Vorgängerversionen ebenfalls auf der ublox-Seite vorhanden, dort aber leider etwas versteckt ist. Auf der angegebenen Seite wählt man unten rechts den Link "Documentation & ressources"

Auf der erscheinenden Seits scrollt man ganz nach unten und klickt dort auf die Schaltfläche "Show Legacy Documents"

In der Liste "Evaluation Software" findet man unschwer die Version 19.11.01, deren Download durch Anklicken gestartet wird.

Arbeiten mit dem Programm

Die grundsätzliche Bedienung von u-center ist bereits im Buch ausführlich beschrieben, hier werden daher die Unterschiede im Hinblick auf die Aufzeichnung von Daten des NEO-M8P-Chips beschrieben. In beiden Fällen öffnet man zuerst über das Menü "View / Messages View" das entsprechende Fenster. Dort wählt man im Datenpfad den Eintrag UBX und aktiviert über die rechte Maustaste den Eintrag "Enable Child Mesages". Desselbe wiederholt man beim untergordneten Eintrag RXM.

Die Pseudoentfernungen des NEO-M8P- und des ZED-F9P-Chips werden nun im Datenzweig RAWX dargestellt ...

und die Ephemeriden im Zweig SFRBX: Die Übertragung eines Subframs dauert 6 Sekunden, diese Zeitspanne wird im Fenster rechts oben hochgezählt. Ein Frame besteht aus 5 Subframes; welcher Subframe gerade empfangen wurde, kann man in der Spalte MSG ablesen.

Die Aufzeichnung selbst startet in der gewohnten Weise über "Player / Record" und endet mit "Player / Eject". Um alle Ephemeridendaten aufzuzeichnen, sollte die Aufnahme mindestens 30 Sekunden dauern!

Sowohl der NEO-M8P- als auch der ZED-F9P-Chip können neben dem GPS noch andere Systeme (Glonass, Beidou, ...) empfangen. Da wir die Signale dieser Systeme nicht auswerten, sollte deren Datenempfang ausgeschaltet werden. Dies geschieht über den Zweig UBX–CFG-GNSS. Dort sind die jeweils verfügbaren Systeme aufgeführt:

In der Spalte "Enable" entfernt mal alle Häkchen bis auf dasjenige bei "GPS" und klickt danach auf die Schlatfläche "Send" unterhalb des Verzeichnisbaums. Damit werden nur noch GPS-Signale empfangen.

Um die Auswahl permanent zu speichern, so dass diese auch bein nächsten Einschalten noch gültig ist, muss man in den Pfad UBX–CFG–CFG wechseln, dort die Option"Save current configuration" wählen und nochmals auf die Schaltfläche "Send" klicken.

Details: Zugriffe: 161

Der im Buch vorgestellte und verwendete Navilock-Empfänger NL-6002U enthält den GPS-Chip NEO-6P von ublox. Auf der Homepage von ublox findet sich allerdings eine "End-of-life notification" vom 12. Mai 2020. Das letzte Auslieferungsdatum für diesen Chip ist dort auf den 30. April 2021 festgelegt. Es ist damit davon auszugehen, dass auch der Navilock NL-6002U nicht mehr allzulange produziert werden kann. Ein verlässliches Statement hierzu wollte Navilock leider nicht abgeben. Es war aber auch unabhängig davon nötig, sich nach alternativen Empfängern umzusehen, welche ebenfalls die für unsere Zwecke benötigten Pseudoentfernungen ausgeben. Von ublox gibt es (mindestens) zwei Nachfolgerchips, welche den Empfang von Rohdaten ermöglichen. Es handelt sich hierbei um die Chips NEO-M8P und ZED-F9P. Die Verwendung dieser beiden Chips unterscheidet sich von den im Buch gemachten Angaben. Die für uns wesentlichen Unterschiede und daraus folgenden Änderungen bei der Datenaufnahme werden nachfolgend dargestellt.

NEO-M8P-2

Bisher hat Navilock keinen betriebsbereiten GPS-Empfänger mit diesem Chip im Angebot, so dass man auf alternative Lösungen ausweichen und etwas "basteln" muss. Die amerikanische Firma SparkFun stellt u.a. sogenannte Breakout-Boards mit verschiedenen GPS-Chips von ublox her. Ein Breakout-Board enthält elektronische Schaltungen auf Platinen, welche die winzigen Anschlüsse der Chips "aufbrechen", so dass man jeden Kontakt einzeln via Klemme abgreifen und nach Belieben auslesen/weiterverarbeiten kann. Die SparkFun-Boards werden in Deutschland beispielsweise von BerryBase vertrieben.

BreakoutBoard von SparkFun mit dem ublox NEO-M8P

Die gesamte Platine ist 41 mm x 34 mm groß, sie stellt einen vollwertigen GPS-Empfänger dar. Rechts oben befindet sich ein Micro-USB-B-Anschluss zur Verbindung mit dem Computer, über diesen Anschluss erhält die Platine auch ihre Stromversorgung. Der winzige kreisrunde Kontakt unterhalb der rechten Ecke des Chips dient dem Antennenanschluss. Dabei handelt es sich um einen sogenannten U.FL-Steckkontakt, ein Standard für Miniatur-HF-Steckverbinder bis zu 6 GHz. Dieser empfindliche Kontakt ist ausschließlich für dauerhafte Verbindungen innerhalb elektronischer Geräte vorgesehen und für nur wenige Steckvorgänge spezifiziert. Da es ohnehin keine GPS-Antennen mit dem passenden Gegenstück gibt, benötigt man ein Adapterkabel, welches auf der einen Seite die passende U.FL-Buchse und auf der Gegenseite beispielsweise eine SMA-Buchse für den Anschluss des Antennenkabels aufweist.

Beim Anstecken des Adapterkabels auf den U.FL-Kontakt der Platine muss man größte Sorgfalt walten lassen: Die Buchse muss genau zentrisch über dem Stecker platziert sein und exakt parallel eingeclipst werden. SparkFun stellt hierfür eine detaillierte Anleitung zur Verfügung! Es ist empfehlenswert, das Adapterkabel nach dem Anschluss vorsichtig mit einem Kabelbinder am benachbarten Befestigungsloch der Platine zu fixieren, um mögliche Krafteinwirkungen vom Steckkontakt fernzuhalten,

Weiter ist es sinnvoll, die Platine so in ein kleines Gehäuse einzubauen, dass der USB-Steckanschluss noch von außen erreichbar ist. Das andere Ende des U.FL–SMA–Adapterkabels mit der SMA-Buchse befestigt man ebenfalls am Gehäuse, so dass das eigentliche Antennenkabel dort von außen aufgeschraubt werden kann.

M8P Gehaeuse

Das andere Ende des USB-Kabels mit dem üblichen USB-A-Stecker verbindet man mit dem Computer, startet u-center und stellt die Verbindung über den angebotenen COM-Port her.

Datenaufnahme

Wie gewohnt interessiert uns nur der UBX-Pfad im "View"-Fenster. Wieder klicken wir auf UBX und selektieren mit der rechten Maustaste "Enable child messages". Dasselbe machen wir im Zweig RXM.

Der NEO-M8P-Chip kann neben den Signalen von GPS-Satelliten auch noch diejenigen der Systeme Beidou und Glonass empfangen und dadurch hochpräzise Posiitonsbestimmungen durchführen. Da wir uns nur für die GPS-Signale interessieren, schalten wir im Datenpfad UBX–CFG–GNSS alle anderen Systeme aus, indem wir eventuell gesetzte Haken in der Spalte "enable" entfernen.

Klicken auf die Schaltfläche "Send" überträgt die getroffene Wahl in den Empfänger. Um die Auswahl dort permanent zu speichern, so dass diese auch bein nächsten Einschalten noch gültig ist, muss man in den Pfad UBX–CFG–CFG wechseln, dort die Option"Save current configuration" wählen und nochmals auf die Schaltfläche "Send" klicken.

Im Datenpfad UBX–RXM–RAWX werden die Rohdaten der empfangenen Satelliten dargestellt, in der vierten Spalte die uns interessierenden Pseudoentfernungen.

Im Datenpfad UBX–AID–ALM ist der Almanach zu sehen, dieser kann von dort – wie im Buch beschrieben – über die Schaltfläche "Load" heruntergeladen werden.

Im selben Zweig UBX–AID findet man unter dem Eintrag EPH die Ephemeriden der empfangenen Satelliten:

Leider funktioniert die im Buch beschriebene Vorgehensweise zum Aufnehmen der Roh- und Ephemeridendaten nun nicht mehr, da die Ephemeriden nicht mehr im RXM-Zweig dargestellt werden! Man muss jetzt den Weg über das Fenster UBX–RXM–SFRBX gehen. In diesem Fenster wird der Inhalt der Subframes der Satellitennachrichten dargestellt und die Subframes 2 und 3 enthalten ja genau die Navigationsdaten des jeweiligen Satelliten.

Für die Datenaufnahme überprüft man zunächst, ob im Zweig UBX–RXM–RAWX genügend Satelliten empfangen werden und die Daten im Sekundenrythmus erneuert werden. Im Zweig UBX–RXM–SFRBX sollten ebenfalls genügend Satelliten dargestellt werden und dieses Fenster sollte alle sechs Sekunden ein Update erfahren. Sind diese beiden Voraussetzungen erfüllt, so startet man die Aufnahme und zeichnet den Datenstrom mindestens eine Minute lang auf. Diese längere Zeitspanne ist nötig, um auch genügend Ephemeridendaten zu erhalten.

Datenkonvertierung

Bei der Konvertierung der ubx-Dartei wird eine weitere Änderung nötig: Das seither verwendete Programm teqc für die Konvertierung in RINEX-Dateien funktioniert nicht mehr für diese Darstellung der Ephemeriden. teqc kann zwar noch die Beobachtungsdatei erstellen, als Navigationsdatei wird allerdings immer nur eine leere Datei geliefert! Da teqc seit Anfang 2019 nicht mehr weiterentwickelt wird, scheidet diese Möglichkeit damit aus.

Erfreulicher Weise gibt es inzwischen jedoch ein Windwos-Programm, welches die benötigte Konvertierung der mit dem NEO-M8P erzeugten ubx-Dateien sowohl für die Beobachtungs- als auch die Navigationsdatei durchführt. Dies ist das Programm RTKCONV, welches aus einer Sammlung mehrerer Routinen für die Bearbeitung von GPS-Daten – der RTKLIB – stammt. Leider funktioniert RTKCONV nicht für Dateien, die mit dem NEO-6P aufgezeichnet worden sind, dafür muss weiterhin das Programm teqc verwendet werden!

Das gesamte Programmpaket kann über die Seite http://rtkexplorer.com bezogen werden. Diese Seite ist insgesamt eine gute Informationsquelle im Zusammenhang mit mit der GPS-Positonsbestimmung, so ist dort auch ein ausführliches Handbuch zu den Programmen der RTKLIB verfügbar. Hier soll es znächst jedoch nur um den Bezug des Programms RTKCONV gehen. Dazu wählt man auf der genannten Seite den Menüpunkt "Downloads / RTKLIB code" und klickt auf "Demo5 b34b binaries". Man erhält ein Verzeichnis mit allen Programmen, das ggf. erst noch entpackt werden muss. In diesem Verzeichnis befindet sich u.a. das Programm rtkconv.exe für Windows, welches man am Besten in das gps-Verzeichnis kopiert und von dort mit einem Doppelklick aufruft. Es erscheint das folgende Fenster:

In die oberste Eingabezeile schreibt man den Namen der zu konvertierenden Datei, wobei eine komfortable Auswahl durch Klicken auf die hier rot markierte Befehlsschaltfläche mit den drei Punkten geschehen kann. Nach der Auswahl werden sofort die Namen der Beobachtungs- und der Navigationsdatei in die entsprechenden Zeilen eingetragen. Diese Vorschläge kann man ebenfalls mit den jeweils rechts der Zeile befindlichen Schaltflächen mit den drei Punkten verändern. Dann muss man nur noch auf die Schaltfläche "Convert" klicken, um den Prozess zu starten. Nach dem Konvertierprozess können die Ergebnisse sofort durch Klicken auf die hier blau eingekreisten Schaltflächen zur Ansicht gebracht werden. Man wird anfangs feststellen, dass die Beobachtungsdatei problemlos erstellt wurde, die Navigationsdatei aber entweder leer geblieben ist oder aber nur ein Teil der in u-center angezeigten Ephemeriden übernommen wurde. Die Aufzeichnung der Ephemeridendaten dauert nun ganz offensichtlich deutlich länger als bei der im Buch beschriebenen Vorgehensweise.

Beim aufmerksamen Betrachten des Fenster UBX–RXM–SFRBX wird deutlich, dass die Sekundenanzeige in der rechten oberen Ecke immer auf sechs zählt und dann der Fensterinhalt erneuert wird. Dies korrespondiert mit der Tatsache, dass die Übertragunsdauer eines jeden der fünf Unterrahmen genau sechs Sekunden dauert und das Akronym SFRBX steht für den Subframe-Inhalt der jeweiligen Satellitennachicht. Jeder Frame besteht aus 5 Subframs, die Nummer des empfangenen Subframes wird im SFRBX-Fenster in der zweiten, mit MSG gekennzeichneten Spalte angegeben. Beim Aufzeichnen der Daten in u-center sollte man den Durchlauf aller fünf Subframes und damit mindestens 30 Sekunden – besser eine ganze Minute – abwarten, bevor man die Aufnahme beendet.

Am besten konvertiert man die aufgenommenen Daten umgehend mit RTKCONV und überprüft, ob die Ephemeriden aller empfangenen Satelliten vollständig in der Navigationsdatei vorhanden sind. Dem Nachteil, dass nun recht lange Beobachtungsdaten mit über 30 Aufzeichnungszeitpunkten entstehen, kann man begegnen, indem diese RINEX-Beobachtungsdaten in einem Editor exakt auf nur wenige Zeitpunkte gekürzt werden. Damit kann die Verarbeitungsgeschwindigkeit beim Einlesen der Beobachtungsdatei in Maxima signifikant verkürzt werden!

Datenauswertung

Da RTKCONV die RINEX-Dateien in einem etwas anderen Format darstellt, müssen die Maxima-Routinen zum Einlesen der RINEX-Dateien angepasst werden. Die hierfür notwendigen Änderungen sind unter dem Menüpunkt Anpassungen in Maxima beschrieben.

ZED-F9P

Ein weiterer Chip aus dem Haus ublox, welcher Rohdaten liefert, ist der ZED-F9P. SparkFun hat ein BreakoutBoard mit diesem Chip unter der Bestellnummer GPS-16481 im Angebot, das in Deutschland u.a. ebenfalls von der Firma BerryBase vertrieben wird. Chip und Platine sind etwas größer als beim NEO-8MP, die Platine hat die Maße 43.5 mm x 43.2 mm

Dieses BreakoutBoard ist zwar geringfügig teurer als das oben vorgestellte, auf der anderen Seite hat es bereits einen SMA-Anschluss für die GPS-Antenne, so dass die Anschaffung eines entsprechenden Adapterkabels und dessen nichtganz unkritischer Anschluss entfallen. Natürlich ist auch der enthaltene Chip deutlich leistungsfähiger, dies spielt allerdings für unsere Zwecke keine Rolle, da wir ohnehin nur die Pseudoentfernungen auswerten.

Angemerkt werden muss, dass dieses Board zum Anschluss an den Laptop über eine USB Typ-C-Anschlussmöglichkeit verfügt, so dass ein entsprechendes Adapterkabel benötigt wird.

Um mechanische Beanspruchungen der Platine zu vermeiden, empfiehlt sich wiederum der Einbau in ein Gehäuse. Im unten gezeigten Beispiel wurde der SMA-Antennenanschluss durch einen Adapeter aus dem Gehäuse geführt und der USB-C-Anschluss ebenfalls. Der USB-Adapter wurde mit dem Gehäuse verklebt und bietet an seinem anderen Ende eine Anschlussmöglichkeit für ein übliches USB-A-Kabel.

Da der ZED-F9P neben dem GPS auch noch Galileo-, BeiDou und Glonass-Satelliten empfangen kann, empfiehlt es sich, diese Systeme – wie bereits weiter oben beschrieben – vor der Datenaufnahme wie beim NEO-M8P über u-center ebenfalls abzuschalten.

Datenaufnahme

Die Aufnahme der Beobachtungs- und Navigationsdateien geschieht genau wie bereits oben beim NEO-M8P beschrieben.

Bei der Verwendung des ZED-F9P-Chips sind allerdings auch Unterschiede zu beachten. So wird der Almanach leider nicht im Datenpfad UBX–AID–ALM dargestellt. u-center bietet im zugehörigen Fenster zwar die Möglchkeit, den Almanach aus dem WWW zu beziehen, allerdings erscheint bei einem entsprehenden Versuch die Fehlermeldung, dass es beim Lesen der Datei zu einem Fehler gekommen ist. Dieses Problem kann relativ einfach umgangen werden:

Man klickt auf die Schaltfläche "Get WWW", wählt als Yuma-Server den Eintrag

http://www.celestrak.com/GPS/almanac/Yuma/almanac.yuma.txt

und klickt dann auf die Schaltfläche "Test". Damit wird der Browser geöffnet und es erscheint die zugehörige Seite mit dem aktuell gültigen Almanach. Dieser kann direkt aus dem Browserfenster heraus lokal gespeichert werden.

Details: Zugriffe: 237