-
TECHNOLOGIEFELD
-
Einige hierin offenbarte Ausführungsbeispiele beziehen sich auf Navigationssysteme im Allgemeinen.
-
HINTERGRUND
-
Die ersten kommerziellen GPS + GLONASS-Produkte tauchten 1996 [1] auf (Hinweis: dies ist die erste von mehreren Literaturstellen im gesamten Dokument aus den unten aufgeführten „Referenzen” bzw. „Literaturnachweisen”) („GPS” ist das Global-Positioning-System und „GLONASS” ist das GLObal'naya NAvigationnaya Sputnikovaya Sistema, ein funkgestütztes Satelliten-Navigationssystem, das von der früheren Sowjetunion entwickelt wurde und nun für die russische Regierung betrieben wird). Später wurde die weltweit erste GPS + GLONASS-RTK-Technologie angekündigt und implementiert [2], [3]. Zu dieser Zeit war die GLONASS-Konstellation umfangreich, aber ein paar Jahre später hat sie sich dramatisch reduziert.
-
Nach Jahren der Schwache ist GLONASS zum GNSS-(Global-Navigation-Satellite-System-)Markt zurückgekehrt. Die aktuelle Konstellation ist noch unvollständig aber es gibt einige berechtigte Hoffnungen, dass GLONASS schließlich wie geplant heutzutage eingesetzt wird. Daher unterstützen viele Hersteller nunmehr GLONASS für professionelle Anwendungen.
-
Im Vergleich zu den neunziger Jahren, in denen keine Interoperabilitätsprobleme bestanden (weil es nur eine unzureichende Anzahl von Mitwirkenden gab), ist heutzutage die GLONASS-Kompatibilität zwischen Empfängern von unterschiedlichen Herstellern ein wichtiges Element für den professionellen GNSS-Markt, insbesondere für die RTK (d. h. REAL-TIME-KINEMATIC bzw. Echtzeitkinematik).
-
ZUSAMMENFASSUNG DER BESCHREIBUNG
-
Nachfolgend werden Systeme und Verfahren zur Bereitstellung einer Trägerphasen-Abweichungskalibrierung beschrieben.
-
Die nachfolgende Offenbarung umfasst Verfahren und Vorrichtungen, die diese Kalibrierung durchführen, einschließlich Datenverarbeitungssysteme und computerlesbare Medien, die Befehle enthalten, die eine Durchführung dieser Kalibrierung auf den Systemen bewirken, wenn sie auf den Datenverarbeitungssystemen ausgeführt werden
-
Weitere Merkmale werden aus den anliegenden Zeichnungen und der nachfolgenden Beschreibung ersichtlich.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
Die Ausführungsbeispiele sind in den anliegenden Zeichnungen beispielhaft und ohne Beschränkung veranschaulicht, in denen gleiche Bezugszeichen gleichartige Elemente kennzeichnen.
-
1 zeigt ein Beispiel eines geschätzten Single-Difference-Trägerphasen-Abweichungsmusters gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
-
2 zeigt ein vereinfachtes Schema eines GLONASS-Trägerphasen-Kalibrierungsvorgangs gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
-
3 zeigt ein Beispiel eines 99%-Punkts zur Fixierung einer Mehrdeutigkeit für drei unterschiedlich kurze Baselines gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
-
4 zeigt ein Beispiel eines RTK-Leistungsverhaltens gemäß einem Ausführungsbeispiel der vorliegenden Erfindung, wenn gegen eine Drittpartei-Basis eines unbekannten Herstellers gearbeitet wird;
-
5 zeigt ein Beispiel einer einwandfreien GLONASS-Datenverarbeitung einer Drittpartei-Basis, die eine TTFF gegenüber einem ausschließlich verwendeten GPS bei einer langen Baseline gemäß einem Ausführungsbeispiel verbessert, und
-
6 zeigt ein Blockschema eines Datenverarbeitungssystems, das als Standard-Computer oder -Prozessor in verschiedenen Ausführungsbeispielen eingesetzt werden kann.
-
DETAILLIERTE BESCHREIBUNG
-
Die nachfolgende Beschreibung und die Zeichnungen sind als Veranschaulichung und nicht als Beschränkung zu interpretieren. Es werden zahlreiche spezifische Details zum vollständigen Verständnis beschrieben. Jedoch werden in einigen Fällen bekannte oder konventionelle Details nicht beschrieben, um Unklarheiten der Beschreibung zu vermeiden. In der vorliegenden Offenbarung sind Referenzen auf das eine oder ein Ausführungsbeispiel nicht notwendigerweise Referenzen auf das gleiche Ausführungsbeispiel und derartige Referenzen beziehen sich zumindest auf eines.
-
In dieser Beschreibung bedeutet eine Referenz auf „das eine Ausführungsbeispiel” oder „ein Ausführungsbeispiel”, dass ein spezielles Merkmal, eine Struktur oder Charakteristik, das/die in Verbindung mit dem Ausführungsbeispiel beschrieben ist, in zumindest einem Ausführungsbeispiel der Offenbarung enthalten ist. Die an verschiedenen Stellen in der Beschreibung auftretenden Ausdrücke „in einem Ausführungsbeispiel” beziehen sich nicht notwendigerweise alle auf das gleiche Ausführungsbeispiel, noch sind sie getrennte oder alternative Ausführungsbeispiele, die sich von anderen Ausführungsbeispielen nicht gegenseitig ausschließen. Darüber hinaus werden mehrere Merkmale beschrieben, die einige Ausführungsbeispiele aufweisen können, andere aber nicht. Gleichermaßen werden viele Anforderungen beschrieben, die Anforderungen für einige Ausführungsbeispiele sein können, aber nicht für andere Ausführungsbeispiele.
-
GLONASS-Hardwareabweichungen stellen aufgrund der in diesem Satellitensystem verwendeten FDMA-(Frequency-Division-Mutiple-Access-)Technik (Mehrfachzugangsverfahren) ein Problem in GNSS-Empfängern dar. Signale von verschiedenen GLONASS-Satelliten durchlaufen verschiedene Bereiche eines Front-End-RF, die Group-Delay-(GD-)Änderungen (Gruppenlaufzeitänderungen) aufweisen. Demzufolge erhält jeder GLONASS-Satellit eine frequenzabhängige Verzögerung, die letztlich als Abweichung in Pseudoentfernungs- und Trägerphasen-Messungen auftritt. Wenn Positionieralgorithmen in GNSS-Empfängern entwickelt werden, muss diese Tatsache mitberücksichtigt werden.
-
Das Abweichungsproblem existiert für eine Standalone-Positionsbestimmung sowie eine differentielle Positionsbestimmung einschließlich RTK- und Netzwerk-RTK-Lösungen. In den letztgenannten Fällen treten GLONASS-Abweichungen als differentielle Abweichungen auf, die durch eine Differenz in der GD zwischen Rover- und Basis-/Netzwerk-Empfängern verursacht werden. Wenn die Basis- und Rover-Empfänger das gleiche Hardwaredesign aufweisen (vom gleichen Hersteller sind), können diese Differenzabweichungen in den meisten Fällen unbedeutend sein. Wenn jedoch Basis-/Netzwerk- und Rover-Empfänger von verschiedenen Herstellern sind, können die differenziellen Abweichungen (falls diese nicht richtig behandelt werden) das Erreichen einer zuverlässigen Positionsauflösung im Zentimeterbereich verhindern.
-
Nachfolgend wird eine effiziente Unterstützung für die GLONASS-Pseudoentfernungs- und Trägerphasen-Abweichungen mit Fokus auf eine RTK-Anwendung erläutert. Diese Unterstützung umfasst eine effektive On The Fly(OTF-)Pseudoentfernungs- und insbesondere eine Trägerphasen-Abweichungskalibrierung/-Kompensation. Diese Algorithmen können einem GPS + GLONASS-Rover letztendlich Vorteile gegenüber einem ausschließlich GPS verwendenden Rover für alle RTK-Anwendungen gegen ein Drittpartei-Netzwerk verschaffen.
-
A. GLONASS-Herausforderungen
-
GLONASS bringt in die GNSS-Welt nicht nur zusätzliche Satelliten ein. Es bringt viele Herausforderungen für Hersteller von GPS + GLONASS-Empfängern mit sich.
-
Gegenwärtig besteht eine Herausforderung darin, aktuell dank GLONASS eine Leistungsverbesserung zu erzielen. Dies ist eine Herausforderung für Verbraucher- und insbesondere für professionelle Produkte/Algorithmen. Eine GPS + GLONASS-RTK ist die Spitze einer professionellen Leistungsfähigkeit; wobei hierbei die schwierigste Aufgabe die vorteilhafte Nutzung von GLONASS ist.
-
GLONASS-Daten können objektiv (wie sie vom GLONASS-Weltraum- und Kontrollsegment bereitgestellt werden) und subjektiv (wie sie von einem Empfänger verarbeitet werden) viele Unbekannte im Aussehen und Verhalten, wie z. B. eine unvollständige/instabile Konstellation, Probleme mit Orbits und einer Satelliten-Uhr aufweisen, die bei einigen Satelliten von Zeit zu Zeit auftreten. Deshalb sollten GNSS-Empfänger in Bezug auf alle möglichen Probleme mit GLONASS eine maximale Robustheit aufweisen.
-
Andere beschreiben den Nutzen, den GLONASS in das GPS einbringt. Aber nur einige wenige diskutieren den Leistungsabfall aufgrund von GLONASS in vielen Fällen. Wenn GLONASS dem GPS hinzugefügt wird, sollte der primäre Slogan lauten:
- 1. Nutze GLONASS wann immer und wo immer möglich, aber;
- 2. Beeinträchtige die Leistungsfähigkeit niemals in allen anderen Fällen.
-
Bekanntermaßen zeigen viele Empfänger und Netzwerke beim Arbeiten im GPS + GLONASS-Modus zuweilen im Vergleich zum ausschließlich verwendeten GPS ein schlechtes Leistungsverhalten. Darüber hinaus empfehlen einige Händler ihren Benutzern, die Verwendung von GLONASS bei ihren Anwendungen zu inaktivieren. Dies beweist, dass der zweite Teil des obigen Slogans für entsprechende Empfänger/Netzwerke nicht erfüllt wird.
-
Eine Anzahl von wertvollen, robusten Lösungen in Bezug auf eine GLONASS-Verwendung/Verarbeitung wurden in der Magellan BLADE®-RTK-Engine implementiert bzw. umgesetzt. Diese Lösungen ermöglichen letztendlich die Empfehlung an Magellan-Nutzer, GLONASS in allen Fällen zu aktivieren, selbst wenn GLONASS nicht adäquat oder schlecht ist. Der Empfänger führt alle notwendigen Überprüfungen/Vorbereitungen durch, um die möglichen negativen Effekte von GLONASS zu mildem, wann immer und wo immer diese auftreten.
-
B. GLONASS-Kompatibilität
-
Es gibt auch eine Anzahl von ernsten Problemen bezüglich einer GLONASS-Kompatibilität zwischen Empfängern von unterschiedlichen Herstellern. Diese Probleme betreffen hauptsächlich professionelle Hochleistungsanwendungen wie RTK, wobei zumindest zwei Empfänger in den Positioniervorgang involviert sind.
-
Diese Diskussion bezieht sich hauptsächlich auf GLONASS-Kompatibilitätsprobleme mit RTK, wobei keine Betonung auf die oben genannten, verallgemeinerten GLONASS-Herausforderungen gelegt wird.
-
GLONASS-RTK-Kompatibilitätsprobleme betreffen üblicherweise zwei primäre Anwendungen:
- • Erzeugen von nivellierten Netzwerk-Korrekturen unter Verwendung einer Anzahl von Basisstationen, die zu verschiedenen Herstellern gehören;
- • RTK-Rover-Funktion gegenüber einer Drittpartei-Basis oder einem Netzwerk.
-
Wenn man über Netzwerk-Korrekturen spricht, ist üblicherweise eine von drei existierenden Lösungen gemeint: eine nicht-physikalische Basisstation, ein FKP und MAC. Diese werden alle für das GPS gut unterstützt, aber es gibt noch keine soliden Lösungen für GLONASS.
-
Es werden drei der am meisten bekannten differenziellen Protokolle betrachtet (die alle vom Magellan ProMARK500®-Empfänger unterstützt werden), die GPS + GLONASS Daten erzeugen: RTC-2 [4], RTCM-3 [5] und CMR/CMR+ [6]. Mit dem letztgenannten ist die urheberrechtlich geschützte Leica/Topcon-GLONASS-Nachricht gemeint, die schon von Novatel und Magellan unterstützt wird. Einige der GPS-Netzwerklösungen werden in jedem Protokoll (z. B. FKP für RTCM-2, MAC und eine nicht-physikalische Basisstation für RTCM-3) sehr gut unterstützt. Zur gleichen Zeit gibt es noch keine standardisierten Protokolle, die einen GLONASS-Netzwerkbetrieb unterstützen.
-
Jede der oben genannten Netzwerktechniken setzt zuerst die Einrichtung eines so genannten Netzbetreiber-Mehrdeutigkeitsniveaus (common carrier ambiguity level) zwischen allen (oder einigen der) Stationen im Netzwerk voraus. Üblicherweise wird darunter eine zuverlässige Fixierung einer Double-Difference-(DD-)Mehrdeutigkeit irgendeiner Masterstation und einer Anzahl von Slave-(Hilfs-)Stationen verstanden.
-
Es ist offensichtlich, dass man zur Bereitstellung einer Netzwerk-Lösung zuerst eine Lösung für eine Ganzzahl-DD-Mehrdeutigkeit für jede einzelne (oder einige) Baseline(s) finden muss. Mit anderen Worten ist eine geeignete Netzwerklösung momentan die Ableitung der klassischen Aufgabe im Zusammenhang mit der einzelnen Baseline-Verarbeitung. Aus diesem Grund betrachten wir nachstehend diesen primären Fall.
-
PROBLEME:
-
A. Halbzyklus-Mehrdeutigkeitsproblem
-
Alte GLONASS-Satelliten (momentan gibt es #1, 4, 8, die die Frequenznummern 6 und 7 belegen) übertragen nur ein P-Signal auf L2. Neue GLONASS-M-Satelliten (13 Satelliten belegen momentan die Frequenznummern –2... 5) übertragen gleichzeitig L2CA und L2P.
-
Die Zusammenfassung dieser Signale geschieht folgendermaßen:
- • Das L2CA-Signal wird durch die Daten mit einem bekannten Inhalt moduliert. Daher kann man dessen Polarität auf einfache Weise speichern und eine Trägerphasen-Überwachung mit einer ganzzahligen Zyklus-Mehrdeutigkeit bereitstellen.
- • Das L2P-Signal für die neuen GLONASS-M-Satelliten wird von den Daten mit einem unbekannten Inhalt moduliert. Daher kann man dessen Polarität im Allgemeinen nicht korrekt speichern. Somit kann dieses Signal eine Trägerphasen-Überwachung nur mit einer halbzahligen Zyklus-Mehrdeutigkeit bereitstellen.
- • Das L2P-Signal für die alten GLONASS-Satelliten wird von keinen Daten moduliert. Das heißt, man kann dessen Polarität korrekt speichern. Somit kann dieses Signal eine Trägerphasen-Überwachung mit einer ganzzahligen Zyklus-Mehrdeutigkeit bereitstellen.
-
Eine RTCM-Empfehlung für GLONASS-L2-aktivierte Empfänger ist:
- • Verfolge das L2CA-Signal für die neuen GLONASS-M-Satelliten
- • Verfolge das L2P-Signal für die alten GLONASS-Satelliten
-
Mit Sicherheit folgen die meisten modernen Empfänger dieser Empfehlung. Jedoch gibt es überhaupt keine Garantie, dass alle GLONASS-L2 aktivierten Empfänger, insbesondere Altempfänger, dies tun. Darüber hinaus gibt es keine Garantie, dass alle Empfänger das CA/P-Flag für GLONASS-L2 korrekt setzen. Zum Beispiel wurde ein Test mit einem Drittpartei-OEM-Board durchgeführt und es war überraschend zu sehen, dass alle GLONASS-Codes als CA markiert waren, obwohl das Board alte GLONASS-Satelliten verfolgte, die diesen Code für L2 nicht senden.
-
Dies bedeutet, dass nicht 100%ig sichergestellt ist, dass die von einem Rover verarbeiteten Drittpartei-Referenzdaten keine halbzahlige Abweichung für einige GLONASS-L2-Träger enthalten.
-
B. Viertelzyklus-Mehrdeutigkeitsproblem
-
Es existiert eine mögliche Mehrdeutigkeit bezüglich einer Viertelzyklus-Abweichung (Abweichung um einen 0,25 Zyklus) zwischen den Trägermessungen, die verschiedenen Signalen der gleichen Frequenz entsprechen. Derzeit steht ein einziges Problem im Focus (d. h., ob ein Empfänger GPS-L2C-Daten um einen 0,25 Zyklus auf L2P-Daten anpassen soll). Gleichzeitig ist dieses Problem umfassender und beeinträchtigt eine Anzahl von bereits existierenden Signalen sowie viele eingehende Signale.
-
Wenn ein Empfänger L2C-Daten für einige GLONASS-Satelliten erzeugt und L2P-Daten für andere GLONASS-Satelliten erzeugt, kann das Problem einer Abweichung um einen 0,25 Zyklus auftauchen. Einige Hersteller wenden eine Korrektur um einen 0,25 Zyklus an, einige tun dies nicht, und ab und an gibt es eine Uneindeutigkeit in der Interpretation von offiziellen Standards bezüglich dieser Korrektur sowie das Setzen eines CA/P-Flag für L2. Die gleiche Situation kann für GLONASS-L1CA und -L1P auftreten.
-
Dies bedeutet, dass nicht 100%ig sichergestellt ist, dass die von einem Rover-Empfänger verarbeiteten Drittpartei-Referenzdaten keine viertelzahlige Abweichung für einige GLONASS-L2-Träger enthalten.
-
C. Hardware-Abweichungsproblem
-
GLONASS-Hardwareabweichungen sind vorhanden, weil GLONASS die FDMA-Technik verwendet. Unterschiedliche Signale durchlaufen verschiedene Bereiche eines Front-End-RF, der frequenzabhängige Laufzeiten bei der Pseudoentfernung und Trägerphase einbringt.
-
Die folgenden Hauptfaktoren verursachen diese Abweichungen:
- 1. Nominale Gruppenlaufzeit-(GD-)Änderungen, die durch ein nichtideales Front-End-RF-Design verursacht werden.
- 2. Spezifische GD-Änderungen für jede Einheit, die durch Bauteilstreuungen verursacht werden.
- 3. Spezifische GD Änderungen für jede Einheit, die durch Umgebungseinflüsse (hauptsächlich Temperatureinflüsse) verursacht werden.
- 4. Spezielle Eigenschaften der Korrelations-/Verfolgungsalgorithmen, die Änderungen der festgestellten Abweichung verursachen können, die die gleiche GD liefert.
-
Eine differenzielle Hardwareabweichung zwischen Basis- und Rover-Empfängern (RTK-Modus) wird nachfolgend erläutert. Daher kann jede Änderung der Abweichungen (z. B. aufgrund der Temperatur) nicht nur durch den Rover, sondern auch durch die Basis verursacht werden.
-
Wenn die Basis und der Rover das gleiche Hardware-Design aufweisen und die gleichen Korrelations-/Verfolgungsalgorithmen verwenden, dann können die Faktoren 1 und 4 keine Veränderungen liefern. Die einzigen Quellen für Veränderungen sind die Faktoren 2 und 3. Es wurde vorläufig festgestellt, dass die Faktoren 2 und 3 Veränderungen der Pseudoentfernung verursachen können, während das Auftreten von Trägerphasenabweichungen, obwohl möglich, nicht offensichtlich beobachtet wurde.
-
Wenn die Basis und der Rover unterschiedliche Typen sind und/oder unterschiedliche Korrelations-/Verfolgungsalgorithmen verwenden, können die Faktoren 1 und 4 als Hauptquelle der Abweichungen bei der Pseudoentfernung und (insbesondere) der Trägerphase dominieren.
-
In den nachfolgenden Referenzen [7] und [8] sind viele Beispiele von Pseudoentfernungs- und Trägerphasen Abweichungen zwischen unterschiedlichen Typen von Empfängern zu finden.
-
1 zeigt ein Beispiel eines (durch eine 70 Stunden andauernde Beobachtung auf einer Null-Baseline) geschätzten Single-Difference-(SD zwischen Empfängern)Trägerphasen-Abweichungsmusters zwischen einem Magellan ProMark500 und einem Drittpartei-Empfänger (die Abweichung wurde vorbehaltlich für eine Frequenz #0 auf Null gesetzt). Obwohl ein Abweichungsmuster im Vergleich zu einer Frequenz in vielen Fällen linear ist, kann diese Annahme nicht mit 100%ger Zuverlässigkeit getroffen werden.
-
Dies bedeutet, dass ein Rover-Empfänger, der gegen Drittpartei-Referenzdaten arbeitet, unbekannte Trägerphasen-Abweichungen aufweisen wird, die die Fixierung einer ganzzahligen Mehrdeutigkeit für GLONASS verhindern kann.
-
D. Netzwerk-Problem
-
Wenn man mit seiner/ihrer eigenen Basis arbeitet, hat man zwei Wahlmöglichkeiten: (1) Verwende Empfänger des gleichen Herstellers und des gleichen Designs; und (2) Führe eine Vorkalibrierung der GLONASS-Trägerabweichungen auf einer Null-Baseline mit sehr guter Präzision durch, füge diese der benutzerdefinierten Empfängerliste hinzu und verwende diese Abweichungen im Gebiet.
-
Wenn hingegen in einem Netzwerk gearbeitet wird, tauchen einige Probleme auf: (1) das Netzwerk ermöglicht es einem Benutzer nicht, Abweichungen auf einer Null-Baseline zu kalibrieren; (2) alle Netzwerke, mit denen bisher gearbeitet wurde, senden keine Informationen über den Empfängertyp, wobei der Benutzer uninformiert bleibt und (3) die Netzwerk-Software kann noch weitere Abweichungen einbringen, wenn eine nicht-physikalische Referenzstation erzeugt wird.
-
Alt dies führt zur Schlussfolgerung, dass momentan eine OTF-Trägerabweichungskalibrierung die einzige Wahl für den Benutzer darstellt, wenn er/sie in einem Netzwerk arbeitet.
-
LÖSUNGEN
-
A. GLONASS-Trägerabweichungsmodell
-
Ein vereinfachtes SD-Messungsmodell für eine L1- oder L2-GLONASS-Trägerphase über eine kurze Baseline kann folgendermaßen ausgedrückt werden: L(j) = R(j)/lambda(j) + B(j) + n(j) wobei:
- j
- eine Nummer eines GLONASS-Satelliten bezeichnet,
- L(j)
- ein in Zyklen gemessener Träger ist,
- R(j)
- eine wahre Entfernung in Meter ist,
- lambda(j)
- eine Wellenlänge in Metern ist,
- B(j)
- eine vollständige Trägerabweichung in Zyklen ist,
- n(j)
- ein Rausch-/Mehrweg-Fehler in Zyklen ist, und
-
Werte L, R, B und n für unterschiedliche Satelliten unterschiedlich sind und sich zeitlich verändern.
-
Im Gegenzug ist eine gesamte Trägerabweichung (Zyklus) definiert als: B(j, t) = N(j) + b(j) + clock(t)(lambda(t) wobei:
- t
- die momentane Zeit in Sekunden ist,
- N(j)
- die SD-Trägerphasen-Mehrdeutigkeit in Zyklen ist,
- b(j)
- die SD-Trägerphasen-Hardwareabweichung in Zyklen ist,
- clock(t)
- die SD-Uhrabweichung in Metern ist.
-
N und b sind für jeden Satelliten unterschiedlich. Der Wert N für eine vorgegebene Sat#j (Sat.-Nr. j) ist bis auf einen Halteverlust oder Zyklus-Slip zeitlich konstant und kann nach Instandsetzen des Träger-Lock einen anderen Wert annehmen. Der Wert b ist für einen vorgegebenen Satelliten (zumindest bei stabiler Temperatur) zeitlich ungeachtet eines Lock-Verlusts konstant, da dies eine Hardwareeigenschaft ist. Der Unterschied zwischen dem Verhalten von N und b bei verlorenem Träger-Lock stellt ein wesentliches Element für den Kalibrierungsprozess der GLONASS-Hardware-Trägerabweichung dar.
-
Der Wert von clock(t) kann sich zeitlich ziemlich willkürlich verändern, ist jedoch für alle Satelliten identisch.
-
Bekanntermaßen hängt die Hardwareabweichung b indirekt von der Satelliten-Nummer #j ab. Dies bedeutet, dass b tatsächlich von der Satelliten-Frequenznummer oder von lambda(j) abhängt. Da die meisten der „gegenüberliegenden” GLONASS-Satelliten die gleiche Frequenznummer gemeinsam benutzen, weisen diese „gegenüberliegenden” Satelliten den gleichen Wert b auf.
-
In Bezug auf die gesamte Trägerabweichung müssen zwei Annahmen getroffen werden, wenn die GLONASS-Trägerdaten in der RTK-Engine verarbeitet werden:
- • Sind die Werte N ganzzahlig oder nicht?
- • Sind die Werte b gleich Null oder nicht?
-
Die Antwort hängt von den Annahmen in Bezug auf den Rover sowie die Basis-Empfänger ab.
-
Hierbei sind gegensätzliche Fälle zu beachten.
-
Wenn die Basis und der Rover das gleiche Handware-Design aufweisen, die gleiche Firmware verwenden und der RTCM-Empfehlung bezüglich der CA/P-Verfolgung auf L2 folgen, dann folgt daraus:
- • Alle Werte N sind immer ganzzahlig
- • Alle Werte b sind hauptsächlich Null
-
In diesem Fall ist das Arbeiten mit einem GLONASS-Träger dem Arbeiten mit einem GPS-Träger (obwohl einige Unterschiede bestehen) sehr ähnlich. Das bedeutet, dass die RTK die GLONASS-DD-Mehrdeutigkeit sicher ganzzahlig fixieren kann, ohne sich um eine Kalibrierung von Hardwareabweichungen (b) zu kümmern.
-
Wenn die Basis und der Rover von unterschiedlichen Herstellern sind, und der Rover nicht sicher ist, was die Besonderheiten der Firmware-Algorithmen des Basisempfängers angeht, dann folgt daraus:
- • Die Werte N für einige GLONASS-Satelliten auf L2 können zeitweise halbzahlig sein.
- • Der Rover kann für einige GLONASS-Satelliten bei N eine Abweichung von 0,25 eines Zyklus aufgrund einer Mehrdeutigkeit hinsichtlich einer durchzuführenden oder nicht durchzuführenden Anpassung von 0,25 eines Zyklus an der Basis aufweisen.
- • Alle Werte b sind generell nicht gleich Null.
-
In diesem Fall erfordert das Arbeiten mit GLONASS eine Kalibrierung der Hardwareabweichungen und die Annahme einer zusätzlichen Halb-Zyklus-Mehrdeutigkeit (und voraussichtlich einer Viertel-Zyklus-Mehrdeutigkeit) für einige Träger. Ohne eine vorausgehende Kalibrierung kann die GLONASS-DD-Mehrdeutigkeit (falls L2 nicht genau verfolgt wurde) nicht ganzzahlig oder halbzahlig fixiert werden. Sobald kalibriert wurde, können die Abweichungen b beim entsprechenden GLONASS nach einem Halteverlust oder selbst bei einem Empfänger-Neustart (der in einer BBU-Speichereinheit abgespeichert wird) angewendet werden.
-
B. GLONASS-Lösungen
-
Die Hardware-Pseudoentfernungs- und Trägerphasen-Abweichungen sowie eine mögliche Halbzyklus-/Viertelzyklus-Mehrdeutigkeit stellen die Hauptprobleme bezüglich einer nominalen GPS + GLONASS-RTK-Leistungsfähigkeit dar. In einem Ausführungsbeispiel wurde eine Strategie erarbeitet, um diese negativen GLONASS-Eigenschaften im MagellanProMark500-Empfänger (GPS + GLONASS-L1/L2) unter Verwendung einer BLADE-RTK-Engine zu überwinden. Hierbei sei angemerkt, dass der ProMark500 nachfolgend beispielhaft für ein mögliches Ausführungsbeispiel detailliert beschrieben wird.
-
Die Lösungen umfassen:
- • Eine OTF-Kalibrierung von Pseudoentfernungs-Abweichungen
- • Eine Bereitstellung und Verarbeitung des Empfängernamens
- • Eine Unterstützung einer Vollzyklus- und Halbzyklus-Mehrdeutigkeitsannahme
- • Eine optionale Viertelzyklus-Korrektur
- • Eine Unterstützung einer Empfängernamen-Datenbank
- • Eine OTF-Kalibrierung von Trägerabweichungen
-
Nachfolgend werden einige Klarstellungen für diese Lösungen beschrieben.
-
Die ProMark500-Engine schätzt GLONASS-Pseudoentfernungs-Hardwareabweichungen für L1 und L2 zusammen mit weiteren RTK-bezogenen Zuständen (Position, Geschwindigkeit, Träger-Mehrdeutigkeit, verbleibende Ionosphäre, usw.). A priori ist bekannt, dass Pseudoentfernungs-Hardwareabweichungen in Metern bis zu einer Größe von 10 m liegen und zeitlich stabil sind; demzufolge wird ein geeignetes stochastisches Modell verwendet, um diese zu modellieren. Diese Abweichungsschätzung ist an und für sich eine OTF-Kalibrierung, die in [7] beschrieben ist. Die GLONASS-Pseudoentfernungs-Abweichungskalibrierung bedeutet nicht, dass der Empfänger speziell in einen Kalibrierungsmodus versetzt werden muss. Vielmehr stellt der Empfänger eine hochqualitative Auflösung für eine float- und fixed-Mehrdeutigkeit bereit, selbst wenn die Kalibrierung im Gange ist. Der Vorgang der Pseudoentfernungs-Abweichungskalibrierung wird jedes Mal zurückgesetzt, wenn sich eine ID der Basisstation oder ein Name des Basisempfängers ändert. Der Kalibrierungsvorgang enthält unterschiedliche Schutzeinrichtungen, um ein fehlerhaftes „Freezing” bzw. Einfrieren von vorkalibrierten Abweichungswerten zu verhindern. Der Pseudoentfernungs-Kalibrierungsalgorithmus arbeitet gleichermaßen gegen die eigene oder die Drittpartei-Basis, da sich herausgestellt hat, dass Pseudoentfernungs-Hardwareabweichungen generell zwischen Empfängern mit dem gleichen Design (Veränderungen von Abtastung zu Abtastung, Temperaturänderungen, usw) vokommen können.
-
Für eine effektivere GLONASS-Datenverarbeitung ist es wünschenswert, dass der RTK-Rover den Namen des Basisempfängers kennt. Ein ProMark500-Empfänger, der als Basis verwendet wird, bietet eine derartige Möglichkeit für Drittpartei-Rover. Ein offizieller Name (ProMark500) wird standardmäßig in einer standardisierten RTCM-3 MT 1033 und einer geschützten Magellan ATOM®-Nachricht erzeugt. Der ProMark500-Empfänger, der als Rover verwendet wird, kann sich den Basis-Namen, falls verfügbar, zu Nutze machen. Dies erfolgt für die RTCM-3 MT 1033 automatisch, die eine Drittpartei-Basis erzeugen kann, oder manuell durch eine Eingabe des Namens eines a priori bekannten Basis-Empfängers am Rover. Da die Unterstützung des Empfängernamens heutzutage nicht voll entwickelt ist, wird die Verarbeitung des Basisempfänger-Namens hauptsächlich für den einzigen Zweck verwendet, nämlich um zwischen der eigenen („ProMark500-)Basis und einer Drittpartei-Basis zu unterscheiden. Sobald die GNSS-Gemeinde vernünftigerweise Träger-Abweichungsmuster bereitstellt, wird die Verarbeitung des Basisempfänger-Namens im ProMark500 das Arbeiten mit einer Empfängernamen-Datenbank (siehe unten) ermöglichen.
-
Der ProMark500 gewährleistet eine Vollzyklus-Träger-Mehrdeutigkeit für L1 und L2 (d. h. man folgt der RTCM-Empfehlung in Bezug auf die Verfolgung der GLONASS-L2-Signale). Standardmäßig geht ein ProMark500-RTK-Rover davon aus, dass jede Drittpartei-Basis ebenfalls eine Vollzyklus-Mehrdeutigkeit für L1 und L2 bereitstellt.
-
Deshalb arbeitet ein ProMark500-RTK-Rover ungeachtet der eigenen oder einer Drittpartei-Basis unter der Annahme einer Vollzyklus-Mehrdeutigkeit. Wenn es gleichzeitig a priori bekannt ist, dass eine Drittpartei-Basis lediglich eine Halbzyklus-Mehrdeutigkeit für L2 bereitstellen kann, dann kann dem ProMark500-RTK-Rover befohlen werden, mit einer Halbzyklus-Annahme für L2 zu arbeiten (d. h. es besteht immer noch eine Möglichkeit, eine L2-Mehrdeutigkeit halbzahlig festzulegen [natürlich vermindert sich die Leistung]).
-
Der ProMark500 kann Viertelzyklus-Korrekturen vornehmen, um GLONASS-L2CA- und -L2P-Daten „passend” zu machen („anzupassen”). Dabei ist der ProMark500-Rover einem fast linearen L2-Träger-Abweichungsmuster in Bezug auf eine Frequenz gegenüber einem Drittpartei-Empfänger (vergleiche 1) ausgesetzt. Ohne diese Korrektur wies dieses Muster für die Frequenznummern 6 und 7, die zum alten GLONASS gehören, einen Sprung von ca. 0,25 eines Zyklus auf. Abhängig von einem Basisempfänger des Typs ProMark500 kann ein Benutzer diese Korrektur eines 0,25 Zyklus aktivieren oder inaktiveren.
-
Der ProMark500 kann eine Referenz- und eine eigene GLONASS-Träger-Datenkompensation vor der RTK-Verarbeitung anwenden, wenn zuverlässige Informationen in Bezug auf Hardwareabweichungen verfügbar sind. Diese Informationen werden in einem Empfängerspeicher für jeden bekannten Empfängernamen gespeichert. Das Prinzip zur Verwendung dieser Informationen ist das gleiche wie das Prinzip einer Antennenphasenzentrum-Versatzkorrektur, das in den meisten modernen RTK-Empfängern verwendet wird. Während für Antennen offizielle IGS-/NGS-Korrekturtabellen existieren, gibt es für GLONASS-Hardwareabweichungen nichts Vergleichbares. Dies begrenzt die Möglichkeiten des ProMark500 (sowie jedes anderen Empfängers), irgendeine zuverlässige Abweichungskompensation für Drittpartei-Referenzdaten durchzuführen. Gleichzeitig wurden die nachfolgenden Tests durchgeführt. Beim Arbeiten mit einem Drittpartei-Empfänger wurde ein erstes GLONASS-Abweichungsmuster geschätzt (vergleiche 1). Dieses Muster wurde wenige Tage später bei einem anderen ProMark500-Empfänger angewendet, der milder gleichen Drittpartei-Basis arbeitete. Es wurde sichergestellt, dass die Verwendung dieses Musters zur Kompensation der vorgegebenen Drittpartei-Basisdaten letztlich zu einem abweichungsfreien DD-Träger führt. Mit einer großen Vielzahl von Drittpartei-Empfängern kann der ProMark500 eine gleichartige Kalibrierung gegenüber jedem von denen ausführen. Danach können alle Kalibrationswerte in die Empfängernamen-Datenbank übernommen werden, um eine Kompensation von Trägerphasen-Abweichungen bei jedem Basisempfänger zu ermöglichen, dessen Name in der ProMark500-Empfängerdatenbank vorhanden ist. Diese Technik (d. h. die Kalibrierung eines Drittpartei-Empfängers gegenüber dem ProMark500 oder umgekehrt) widerspricht nicht der Idee, dass jeder Anbieter die Verantwortung zur Kalibrierung (und Veröffentlichung in irgendeiner standardisierten Form) seines eigenen Empfängers gegenüber einer „absoluten” Referenz übernehmen muss.
-
In den meisten Fällen (zumindest bis alle Hersteller ihre Empfänger gegenüber jedem anderen oder gegenüber einer „absoluten” Referenz kalibriert haben) wird der ProMark500-Rover eine unvollständige Empfängernamen-Datenbank aufweisen. Dies ermöglicht keine Anwendung der oben beschriebenen Kompensationstechnik. Daher wendet der ProMark500-Empfänger automatisch eine OTF-Träger-Abweichungskalibrierungstechnik an, wenn der Basis-Empfängername entweder nicht bekannt oder in der ProMark500-Empfängernamen-Datenbank nicht vorliegt. Die Idee der OTF-Kalibrierung ist sehr einfach: man berücksichtigt SD-Träger-Hardwareabweichungen, wenn a priori unbekannte Parameter einem gleichen stochastischen Modell folgen.
-
Träger-Mehrdeutigkeiten unterliegen einer Suche einer Ganzzahl-Mehrdeutigkeit gefolgt von einer DD-Mehrdeutigkeit, die auf ganzzahlige Werte fixiert. Damit diese Suche eine Ganzzahl-Suche ist, sollten die Mehrdeutigkeiten bei Abweichungen daherselbst zum Gegenstand der Kalibrierung und Kompensation werden. Im Vergleich mit einer Kalibrierung von Pseudoentfernungs-Abweichungen wird das Schema noch komplexer (siehe 2).
-
Nach einem RTK-Kalmanfilter-Update werden derzeitige Mehrdeutigkeitsschätzungen einer GLONASS-Trägerabweichungs-Schätzeinrichtung (GLONASS Carrier Bias Estimator) zugeführt, die nicht nur Korrekturen schätzt, die an den SD-Trägermessungen vorgenommen werden sollten, sondern zudem die Entscheidung zur Modifizierung von Mehrdeutigkeiten trifft, um sicherzustellen, dass die DD ein ganzzahliger Wert wird.
-
Diese Abweichungs-Schätzeinrichtung (Biss Estimator) ist gegenwärtig eine universelle Abweichungs-Schätzeinrichtung, die ein quasi-lineares Abweichungsmuster potentiell berücksichtigen kann. Sie kalibriert eigentlich die eingespeisten SD-Mehrdeutigkeitsschätzungen für eine DD, da nur diese zeitlich konstant sind. Sie kann auch Abweichungen mit oder ohne eine Halbzyklus-Annahme schätzen, was in manchen Fallen einen Zusatznutzen erbringen kann.
-
Bei einer kurzen (weniger als 10 km langen) Baseline können Ionosphären-, Troposphären- und Orbitfehler vernachlässigt werden und die geschätzten Abweichungen sind zuverlässig. Zudem wurde eine gute Alltags-Reproduzierbarkeit beim Arbeiten mit einem Drittpartei-Empfänger festgestellt.
-
Leider sind derartige kurze Baselines normalerweise nicht der Fall, wenn der Nutzer in einem Netzwerk arbeitet. Man kann eine Baseline von 30 bis 70 km erwarten. Wenn eine Baseline länger wird (20+ km), werden Ionosphären-, Troposphären-, Orbitfehler und Trägerabweichungen ununterscheidbar. Eine lineare Annahme könnte die Situation beheben, aber sie kann wegen den vorgenannten, potentiellen Viertelzyklus- und Halbzyklusproblemen nicht angewandt werden. Obwohl eine Linearität (oder Quasi-Linearität) in den Abweichungsmustern beobachtet wird, konnte bislang kein theoretischer Beweis gefunden werden (sofern es einen solchen überhaupt gibt), dass dieses Verhalten für jedes RF-Design obligatorisch ist. Und selbst wenn dies für die derzeit auf dem Markt befindlichen Empfänger zutrifft, kann man, nichts garantieren, weil diese Industrie rasant wächst.
-
Lange Baselines stellen eine wirkliche Herausforderung für die Träger-Abweichungskalibrierung dar. Unter Verwendung eines geeigneten stochastischen Modells können Abweichungen mit guter Präzision geschätzt werden, und obwohl diese Schätzungen aufgrund von Ionosphären-, Troposphären- und Orbitfehler selbst leicht „abweichend” („verzerrt”) ausfallen, bilden sie dennoch eine gute Grundlage bei der Mehrdeutigkeitsfixierung im Falle einer kurzen Blockierung des Himmels oder eines Halteverlusts.
-
Die zusätzlichen Schutzeinrichtungen stehen kontinuierlich zur Verfügung, um jede vermutete Abweichung zu erfassen und zu verhindern, dass dieser Satellit bei der Mehrdeutigkeitssuche verwendet wird und starten den Kalibrierungsvorgang an einem ausgewählten Satelliten neu. Darüber hinaus berücksichtigt der spezielle Schutz mögliche Drifts der Abweichungen aufgrund der Temperatur, wodurch eine leichte Abweichungskorrektur ohne einen Reset der Kalibrierung ermöglicht wird. Sobald sich die Basis-ID oder der Empfängername ändert, erfolgt ein Reset der OTF-Kalibrierung.
-
Zusammenfassend kann man sagen, dass der Magellan ProMark500-Empfänger eine OTF-Kalibrierung erfolgreich durchführen kann. Hierbei sei angemerkt, dass dies keine spezielle Hardware- oder Softwareinstallation vom Nutzer erfordert; der Kalibrierungsvorgang startet, sobald der Empfänger Korrekturen von der Drittpartei-Basis erhält. Während dem Kalibrierungsvorgang ist der ProMark500-RTK-Empfänger immer noch in der Lage, eine float- und fixed-Mehrdeutigkeitsauflösung bereitzustellen, so dass der Kalibrierungsvorgang dem Nutzer verborgen bleibt.
-
VALIDIERUNG
-
A. Methodik
-
Alle in diesem Dokument dargelegten Kennzahlen (Leistungsangaben) wurden mit Standard-RTK-Einstellungen erreicht. Insbesondere wurde keine statische Annahme bei der Verarbeitung der Stammdaten getroffen. Alle Tests wurden mit einem vorgegebenen 99%igen Zuverlässigkeitsniveau durchgeführt. In allen Fällen wurde die Zuverlässigkeitsbedingung eingehalten (in den meisten Tests wurde eine absolute Zuverlässigkeit erreicht).
-
Alle Kennzahlen wurden auf einem Computer mit zuvor gesammelten Daten unter Verwendung einer PC-Version der RTK-Engine abgeleitet, die im Empfänger in präziser Echtzeit gelaufen ist.
-
Alle Kennzahlen sind statistisch; es wurden genügend Daten verwendet, um diese Kennzahlen mit einem hohen statistischen Sicherheitsniveau zu evaluieren bzw. auszuwerten.
-
Normalerweise verbessert GLONASS eine fixierte RTK-Genauigkeit im Vergleich mit GPS allein nicht (verschlechtert diese aber auch nicht). Die primäre Rolle von GLONASS besteht darin, eine Fixierung der Mehrdeutigkeit zuverlässiger und schneller zu machen, sowie diese fixierte Auflösung unter Problembedingungen besser beizubehalten. In dieser Diskussion liegt der Schwerpunkt auf der Ableitung einer so genannten Time-To-First-Fix-(TTFF-)Statistik.
-
Der Leistungsevaluierungsvorgang bestand in jedem Fall aus einem Lauf der RTK-Engine mit einem automatischen Reset alle 600 Sekunden (der GLONASS-Trägerphasen-Kalibrator wurde nicht zurückgesetzt), um eine ausreichende Anzahl von unabhängigen RTK-Versuchen mit fixierten Längen zu erhalten. Ein jeweiliges Ergebnis jedes Versuchs wurde danach in einen Aufbau einer kumulierten TTFF-Verteilung integriert.
-
Im Gegensatz zu einigen anderen Autoren wird die Versuchsmethodik mit einer fixed-Länge (im Vergleich zu Versuchen mit einer float-Länge) verwendet, da nur dieser Ansatz für statistisch adäquat erachtet wird. Dies ist generell pessimistischer als die Versuche mit einer float-Länge [9].
-
Um das Leistungsverhalten zu veranschaulichen, werden ausgewählte Kennzahlen, wie z. B. 50%-, 90%- und 99%-Punkte der TTFF-Verteilung dargestellt. In allen fällen werden die miteinander vergleichbaren TTFF-Kennzahlen mit einer „Referenz” mit einem ausschließlich verwendeten GPS verglichen.
-
Man beachte, dass in vielen Fallen der Leistungsunterschied zwischen der ”Referenz” und den „weiterentwickelten” („advanced”) Fällen hinsichtlich des 50%-Punkts der TTFF nicht so offensichtlich ist. Gleichzeitig kann dieser Unterschied hinsichtlich der 90%- und insbesondere der 99%-Punkte drastisch sein. Diese Punkte beziehen sich auf einen so genannten Worst Case bzw. ungünstigsten Fall (nämlich den, den der Nutzer normalerweise befürchtet), bei dem die „weiterentwickelte” Technologie ihre Leistungsfähigkeit zeigt
-
B. RTK gegen eine eigene Basis
-
3 zeigt einen 99%-Punkt zum Fixieren einer Mehrdeutigkeit für drei unterschiedliche kurze Baselines. Alle Datensätze wurden mit Magellan ProMark500-GPS + GLONASS-L1 & L2-Empfängern unter einem relativ offenen Himmel gesammelt und mit drei unterschiedlichen Annahmen verarbeitet:
- • Nur GPS, d. h. es wurden keinerlei GLONASS-Daten verwendet.
- • GPS + GLONASS mit der Annahme einer „Drittpartei-Basis”. In diesem Fall wurden a priori nicht bekannte Differenzial-Trägerphasenabweichungen angenommen und der Empfänger durchlief eine OTF-Trägerabweichungskalibrierung.
- • GPS + GLONASS mit der Annahme einer „eigenen Basis”. In diesem Fall waren GLONASS-Differenz-Trägerphasenabweichungen bekannt, die gleich Null waren.
-
Man kann (gemäß 3) erkennen, dass an kurzen Baselines:
- • eine GLONASS-Verwendung eine deutliche Verbesserung im Vergleich mit dem Fall eines ausschließlich verwendeten GPS bringt;
- • eine OTF-GLONASS-Trägerphasen-Abweichungskalibrierung (d. h. die Annahme einer „Drittpartei-Basis”) ein ähnliches Leistungsverhalten mit der Annahme einer „eigenen Basis” aufweist.
-
C. RTK gegen ein Drittpartei-Netzwerk
-
4 zeigt ein RTK-Leistungsverhalten beim Arbeiten gegen eine Drittpartei-Basis eines unbekannten Herstellers (d. h. eine OTF-Trägerabweichungskalibrierung läuft). Es ist ersichtlich, dass die Verwendung von GLONASS-Daten von einer Drittpartei-Basis das TTFF-Leistungsverhalten drastisch verbessern kann. Dies ist noch offensichtlicher im Test mit einer absichtlich verwendeten 20-Grad-Höhemaske (Elevation-Mask), für die der 99%-Punkt der TTFF nicht einmal in einem Intervall von 600 Sekunden erreicht wurde.
-
Eine 10 km lange Baseline ist kein typischer Fall, wenn in einem Netzwerk gearbeitet wird. Gewöhnlich arbeitet ein Rover auf Baselines von 30–70 km, die innerhalb oder außerhalb des Netzwerk Abdeckungsbereichs liegen. Wie oben bereits erläutert, ist eine effektive OTF-GLONASS-Trägerabweichungskalibrierung für lange Baselines nicht so einfach wie auf kurzen Baselines. Jedoch zeigt 5, wie gut die Drittpartei-Basis-GLONASS-Datenverarbeitung die TTFF gegenüber dem Fall mit einem ausschließlich verwendeten GPS selbst für eine 58 km lange Baseline verbessert. Es sind zusammenfassende Statistiken dargestellt, die die Ergebnisse von zwei Datensätzen zusammenführen, die mit dem gleichen Empfänger/gleichen Antenne und Netzwerk-Mount-Punkt, aber im zeitlichen Abstand von zwei Wochen, gesammelt wurden.
-
Während der 50%-Punkt der TTFF, wie ersichtlich, für beide Fälle zumeist äquivalent ist, ergibt sich eine drastische Verbesserung für den 90%-Punkt dank der Verwendung der GPS + GLONASS-Lösung. Mit anderen Worten ist GLONASS in Fällen nicht so entscheidend ist, bei denen das GPS allein kraftvoll ist, während es in ungünstigsten Fällen von großer Bedeutung ist, wenn die Leistung des GPS allein nicht ausreichend ist, um eine schnelle fixierte Auflösung zu erhalten.
-
ZUSAMMENFASSUNG
-
GLONASS kehrt wieder in unser Leben und unsere Empfänger zurück. Im Vergleich zu den neunziger Jahren stellen mehr und mehr Hersteller Echtzeit- und Weiterverarbeitungsanwendungen mit GLONASS bereit. Obwohl es (selbst perspektivisch) nicht so stark wie GPS ist, kann GLONASS nichtsdestotrotz als gute Grundlage zur Erweiterung des GPS angesehen werden.
-
Daher stellen viele GPS + GLONASS-RTK-Nutzer Fragen wie diese:
- • Warum ist GLONASS nicht so gut wie GPS?
- • Kann man in seinen eigenen Anwendungen irgendeinen Vorteil mit GLONASS ziehen?
- • Welche Technologie wird im eigenen Empfänger/in der eigenen Software verwendet, um ein zufriedenstellendes Leistungsverhalten mit GLONASS bereitzustellen?
-
Normalerweise stellen Hersteller gleichartige Informationen für ihre Nutzer bereit: einige empfehlen die Verwendung von GLONASS, andere empfehlen die Verwendung von GLONASS auf eigenes Risiko oder verwenden GLONASS unter gewissen Umständen nicht. Gleichermaßen liefert Magellan seinen Standpunkt bezüglich dieser Probleme und Lösungen.
-
Augenblicklich versteht jeder in der GNSS-Welt, dass nur eine sorgfältige Vorgehensweise beim Hinzufügen von GLONASS-Daten zum GPS-RTK Vorteile bringt.
-
Die obige Diskussion bezieht sich auf folgendes:
- • GLONASS hat in die GNSS-Welt nicht nur zusätzliche Satelliten, sondern auch viele Unbekannte und Mehrdeutigkeiten eingebracht.
- • Nichtsdestotrotz ist es möglich, [problematische] GLONASS-Daten zu verarbeiten und das Leistungsverhalten des ausschließlich verwendeten GPS nicht zu beeinträchtigen.
- • Selbst die aktuell unvollständige GLONASS-Konstellation kann für RTK-Anwendungen von Vorteil sein.
- • Dieser Vorteil kann unter bevorzugten Bedingungen (z. B. offenem Himmel, kurzer Baseline) nicht so offensichtlich sein, kann aber unter sogenannten Worst-Case-Bedingungen von großem Wert sein.
- • Das objektiv existierende GLONASS-Abweichungs-Interoperabilitätsproblem kann durch die Verwendung von verbesserten Verarbeitungsalgorithmen gemildert werden.
- • Ungeachtet der verbesserten GLONASS Verarbeitungsalgorithmen, die jeder Hersteller in seinen Empfängern einsetzt, besteht eine Nachfrage hinsichtlich der Beschleunigung einer standardisierten Aktivität in Bezug auf die GLONASS-Observables.
-
Die jüngsten Veränderungen bei GLONASS geben Anlass zur Hoffnung, dass die GLONASS-Technologie und die Empfänger, wie sie zum Ende der neunziger Jahre waren, nicht aus unserm Leben verschwinden werden. Diese positiven Veränderungen sind folgende: eine stabil anwachsende Konstellation; eine ganz zuverlässige Prognose; eine GLONASS-M-Dominanz; ein verfügbarer, ziviler L2C-Code; ein angepasstes PZ-90-Datum; und einige andere.
-
Es gibt augenblicklich 16 die Ende umkreisende GLONASS-Satelliten. Augenscheinlich werden Ende dieses Jahres drei von diesen außer Betrieb gehen (zumindest wird regelmäßig berichtet, dass die nicht nutzbar sind und ihr Alter ziemlich fortgeschritten ist). Diese drei sind glücklicherweise alte GLONASS (nicht GLONASS-M), die normalerweise die größten Herausforderungen darstellen.
-
Gleichzeitig sehen aktuellen Planungen den Abschuss von 6 zusätzlichen GLONASS dieses Jahr vor, von denen zumindest alle GLONASS-M sind. Wenn sich diese Vorhersage als korrekt erweist, dann wird die GNSS-Gemeinde zu Beginn des Jahres 2009 19 GLONASS haben, was für mehr als ausreichend gehalten wird, um das GPS effektiv zu erweitern und noch weitere Verbesserungen zu erzielen.
-
Es werden außerdem vollständige GLONASS-Netzwerklösungen ähnlich denen bei GPS (FKP, MAC, nicht-physikalische Referenzstation) erwartet.
-
Ein Beispiel eines Systems, das zur Implementierung des obigen Verfahrens in einem Ausführungsbeispiel genutzt werden kann, wird im
United Stetes Patent Nr. 5,914,685 (mit dem Titel „RELATIVE POSITION MEASURING TECHNIQUES USING BOTH GPS AND GLONASS CARRIER PHASE MEASUREMENTS” beschrieben, das am 22. Juni 1999 an Dmitry Kozlov et. al. ausgegeben wurde), das hiermit in seiner Gesamtheit durch Bezugnahme miteinbezogen wird. Das U.S.-Patent Nr. 5,914,685 ist im nachfolgenden Detailabschnitt A enthalten.
-
Das
U.S.-Patent Nr. 5,914,685 (das '685-Patent) beschreibt, dass GLONASS-Trägerphasenmessungen in einem kombinierten GNSS-Empfänger zusammen mit einer GPS- und GLONASS-DD-Träger-Mehrdeutigkeit verarbeitet werden können, die ganzzahlig fixiert werden kann. Früher waren fast keine GLONASS-Akteure auf dem Markt und das '685-Patent unterstellte die Verarbeitung einer Baseline zwischen Empfängern mit dem gleichen Hardwaredesign (Hersteller), wobei in diesen Fällen GLONASS-Trägerphasenabweichungen bei einer SD gelöscht wurden.
-
Aktuell gibt es viele GPS + GLONASS-Empfänger von verschiedenen Herstellern auf dem Markt. Jeder Hersteller verwendet sein eigenes Hardwaredesign. Demzufolge enthalten SD-Träger, die Basis- und Rover-Empfänger von verschiedenen Herstellern verwenden, a priori ein GLONASS-Abweichungsmuster, das für jedes spezielle Paar von Herstellern einzigartig ist. In einem Ausführungsbeispiel ist es in diesen Fällen möglich, die oben beschriebenen neuen Verfahren in die Hardware und Verarbeitung zu implementieren, die im '685-Patent beschrieben wurden. Die GLONASS-Trägerabweichungen sollten wie oben beschrieben kalibriert/kompensiert werden.
-
-
REFERENZEN/LITERATURNACHWEISE
-
Alle nachfolgend aufgelisteten Referenzen/Literaturnachweise werden in ihrer Gesamtheit hiermit durch Bezugnahme miteinbezogen und werden ferner ausdrücklich durch Bezugnahme auf ihre Lehre, sowie insbesondere in Bezug auf die obigen individuellen Literaturstellen, miteinbezogen.
[1]
"The GG24 Combined GPS + GLONASS Receiver", S. Gourevitch, S. Sila-Novitsky, F. van Diggelen, Proceedings of ION-GPS '96, Sept 17–20, Kansas City, Missouri.
[2]
"Centimeter Level Real-Time Kinematic Positioning with GPS + GLONASS C/A Receivers", D. Kozlov, M. Tkachenko, Navigation: Journal of the Institute of Navigation, vol. 45, No. 2, Summer 1998, pp. 137–147.
[3] D. Kozlov, A. Povaliaev, L. Rapoport, S. Sila-Novitsky, V. Yefriemov, ”Relative Position Measuring Techniques Using Both GPS and GLONASS Carrier Phase Measurements”,
US Patent No. 5,914,685 , Jun. 22, 1999.
[4]
RTCM STANDARD FOR DIFFERENTIAL GNSS SERVICE – VERSION 2.3, RTCM SPECIAL COMMITTEE NO. 104, AUGUST 20, 2001.
[5]
RTCM STANDARD FOR DIFFERENTIAL GNSS SERVICES – VERSION 3, RTCM SPECIAL COMMITTEE NO. 104, AUGUST 11, 2006.
[6]
A GLONASS Observation Message Compatible With The Compact 30 Measurement Record Format, Leica Geosystems AG.
[7]
"Statistical Characterization of Hardware Bisses in GPS + GLONASS Receivers", D. Kozlov, M. Tkachenko, A. Tochilin, Proceedings of ION-GPS '2000, Salt Lake City, Utah.
[8]
"Combined Processing of GPS, GLONASS and SBAS Code Phase and Carrier Phase Measurements", L. Wanninger, S. Wallstab-Freitag, Proceedings of ION-GPS '2007, Fort Worth, Texas.
[9]
"L1 RTK System with Fixed Ambiguity: What SBAS Ranging Brings", A. Boriskin, D. Kozlov, G. Zyryanov, Proceedings of ION-GPS '2007, Fort Worth, Texas.
-
6 zeigt ein Blockschema eines Datenverarbeitungssystems, das optional als Standard-Computer oder -Prozessor in verschiedenen Ausführungsbeispielen eingesetzt werden kann. Obwohl 6 verschiedene Komponenten eines Computersystems veranschaulicht, soll dies keine bestimmte Architektur oder Art und Weise des Zusammenbindens der Komponenten darstellen. Andere Systeme, die weniger oder mehr Komponenten aufweisen, können ebenfalls verwendet werden.
-
In 6 umfasst das System 201 eine Verbindungsvorrichtung 202 (z. B. einen Bus und eine System-Kernlogik), die einen (mehrere) Mikroprozessor(en) 203 und eine Speichervorrichtung 208 miteinander verbindet. Der Mikroprozessor 203 ist im Beispiel von 6 mit einem Cachespeicher 204 gekoppelt.
-
Die Verbindungsvorrichtung 202 verbindet den (oder die) Mikroprozessor(en) 203 und die Speichervorrichtung 208 miteinander und verbindet sie ferner mit einem Display-Controller und einer Displayvorrichtung 207 und peripheren Vorrichtungen, wie z. B. Eingabe-/Ausgabe-(I/O-)Vorrichtungen 205, über einen (mehrere) Eingabe-/Ausgabe-Controller 206. Typische I/O-Vorrichtungen umfassen Mäuse, Keyboards, Modems, Netzwerkschnittstellen, Drucker, Scanner, Videokameras und weitere im Stand der Technik bekannte Geräte.
-
Die Verbindungsvorrichtung 202 kann einen Bus oder mehrere Busse umfassen, der/die miteinander über mehrere Brücken, Controller und/oder Adapter verbunden ist (sind). Die Speichervorrichtung 208 kann ein ROM (Reed Only Memory, ein volatiles RAM (Random Access Memory) und einen nicht-volatilen Speicher, wie z. B. eine Festplatte, einen Flashspeicher, usw. umfassen.
-
Das volatile RAM ist normalerweise als dynamisches RAM (DRAM) ausgeführt, das eine kontinuierliche Stromversorgung erfordert, um die Daten in der Speichervorrichtung zu aktualisieren oder aufrechtzuerhalten. Der nicht-volatile Speicher ist normalerweise eine magnetische Festplatte, eine magneto-optische Festplatte oder eine optische Festplatte (z. B. ein DVD-RAM) oder ein anderer Typ eines Speichersystems, das Daten aufrechterhält, selbst wenn die Stromversorgung vom System getrennt wird. Der nicht-volatile Speicher kann auch ein Random Access Memory sein.
-
Der nicht-volatile Speicher kann ein lokales Gerät sein, das mit den restlichen Komponenten im Datenverarbeitungssystem direkt verbunden ist. Ein vom System weit entfernter nicht-volatiler Speicher, wie zum Beispiel eine Netzwerk-Speichervorrichtung, die mit dem Datenverarbeitungssystem über eine Netzwerkschnittstelle, wie z. B. ein Modem oder ein Ethernet-Interface, verbunden ist, kann ebenfalls verwendet werden.
-
Die Ausführungsbeispiele der vorliegenden Erfindung können über den (die) Mikroprozessor(en) 203 und/oder die Speichervorrichtung 208 implementiert werden. Zum Beispiel können die beschriebenen Funktionalitäten teilweise über eine Hardwarelogik im (in den) Mikroprozessor(en) 203 implementiert werden und teilweise die in der Speichervorrichtung 208 gespeicherten Befehle verwenden. Einige Ausführungsbeispiele können unter Verwendung des (der) Mikroprozessor(en) 203 ohne zusätzliche in der Speichervorrichtung 208 gespeicherten Befehle implementiert werden. Einige Ausführungsbeispiele können unter Verwendung der in der Speichervorrichtung 208 gespeicherten Befehle zur Ausführung durch einen oder mehrere Standard-Mikroprozessoren 203 implementiert werden. Demzufolge ist die Offenbarung nicht auf eine spezielle Konfiguration einer Hardware und/oder Software beschränkt.
-
In dieser Beschreibung können verschiedene Funktionen und Operationen zur Vereinfachung der Beschreibung als von einem Software-Code durchgeführt oder bewirkt dargestellt sein. Jedoch wird der Durchschnittsfachmann erkennen, dass durch solche Ausdrücke gemeint ist, dass die Funktionen aus einer Ausführung des Codes durch einen Prozessor, wie z. B. einen Mikroprozessor, resultieren. Die Funktionen und Operationen können alternativ oder kombiniert unter Verwendung einer speziellen Sonderzweck-Schaltungsanordnung mit oder ohne Softwarebefehle, wie z. B. unter Verwendung eines Application-Specific Integrated Circuit (ASIC) oder Field Programmable Gate Array (FPGA), implementiert sein. Die Ausführungsbeispiele können unter Verwendung einer festverdrahteten Schaltungsanordnung ohne Softwarebefehle oder in Kombination mit Softwarebefehlen implementiert werden. Daher sind die Techniken weder auf irgendeine spezifische Kombination einer Hardware-Schaltungsanordnung oder Software noch auf irgendeine spezifische Quelle für die Befehle beschränkt, die vom Datenverarbeitungssystem durchgeführt werden.
-
Obwohl einige Ausführungsbeispiele in voll funktionsfähige Computer und Computersysteme implementiert werden können, können verschiedene Ausführungsbeispiele als Computerprodukt in einer Vielzahl von Formen verbreitet werden und können ungeachtet des speziellen Maschinentyps oder der computerlesbaren Medien angewandt werden, die die Verteilung effektiv bewirken.
-
Zumindest einige Aspekte der Offenbarung können, zumindest in Teilen, in einer Software eingebettet werden. Das heißt, dass die Techniken in einem Computersystem oder einem anderen Datenverarbeitungssystem als Reaktion auf dessen Prozessor, wie z. B. einen Mikroprozessor, ausgeführt werden der, Ausführungsfrequenzen von in einer Speichervorrichtung, wie z. B. einem ROM, volatilen RAM, nicht-volatilen Speicher, Cache oder Fernspeichervorrichtung, enthaltenen Befehlen ausführt.
-
Die zur Durchführung der Ausführungsbeispiele implementierten Routinen können als Teil eines Betriebssystems, einer Middleware, Service-Delivery-Plaform, SDK-(Software Development Kit)Komponente, Web-Dienste, oder eine andere spezifische Anwendung, Komponente, Programm, Objekt, Modul oder Befehlsfolge implementiert sein, die als „Computerprogramme” bezeichnet werden. Invocation-Schnittstellen für diese Routinen können einer Software-Entwicklungs-Gemeinschaft als API (Application Programming Interface) ausgestellt werden. Die Computerprogramme weisen normalerweise einen oder mehrere Befehle auf, der/die zu verschiedenen Zeiten, in verschiedenen Speichervorrichtungen und Speichergeräten in einem Computer festgelegt sind und bewirken, dass der Computer Operationen durchführt, die zur Ausführung von Elementen erforderlich sind, die die verschiedenen Aspekte beinhalten, wenn der oder die Befehle von einem oder mehreren Prozessoren in einem Computer gelesen und durchgeführt werden.
-
Ein maschinenlesbares Medium kann zur Speicherung der Software und von Daten verwendet werden, die bei der Ausführung durch ein Datenverarbeitungssystem bewirken, dass das System verschiedene Verfahren durchführt. Die ausführbare Software und die Daten können an verschiedenen Stellen, einschließlich z. B. eines ROM, volatilen RAM, nicht-volatilen Speichers und/oder Cache gespeichert werden.
-
Teile dieser Software und/oder Daten können in irgendeinem dieser Speicher gespeichert werden. Außerdem können die Daten und Befehle von zentralisierten Servern und/oder Peer-To-Peer-Netzwerken bezogen werden. Unterschiedliche Teile der Daten und Befehle können von unterschiedlichen zentralisierten Servern und/oder Peer-To-Peer-Netzwerken zu unterschiedlichen Zeiten und in verschiedenen Kommunikationssitzungen oder in der gleichen Kommunikationssitzung bezogen werden. Die Daten und Befehle können in ihrer Gesamtheit vor der Ausführung der Anwendungen bezogen werden. Alternativ können Teile der Daten und Befehle dynamisch, just-in-time (bedarfsorientiert), bezogen werden, wenn sie für die Durchführung benötigt werden. Daher ist es nicht erforderlich, dass die Daten und Befehle auf einem maschinenlesbaren Medium in ihrer Gesamtheit zu einem spezifischen Zeitpunkt vorliegen.
-
Beispiele von computerlesbaren Medien umfassen, ohne darauf beschränkt zu sein, u. a. beschreibbare und nicht-beschreibbare Medien, wie z. B. volatile und nicht-volatile Speichergeräte, ein Read Only Memory (ROM), Random Access Memory (RAM), Flashspeichergeräte, Disketten- und andere Wechselplatten, Magnetplatten-Speichermedien, optische Speichermedien (z. B. Compact Disk Read Only Memory (CD-ROM's), Digital Versatile Disks (DVD's), usw.). Die Befehle können in digitalen oder analogen Nachrichtenverbindungen für elektrische, optische, akustische oder andere Formen von verbreiteten Signalen, wie z. B. Trägerwellen, Infrarotsignale, digitale Signale, usw verkörpert sein.
-
Im Allgemeinen umfasst ein maschinenlesbares Medium jeglichen Mechanismus, der Informationen in einer Form bereitstellt (d. h. speichert und/oder überträgt), auf die die von einer Maschine (z. B. einem Computer, einer Netzwerkvorrichtung, einem Minicomputer, einem Herstellerwerkzeug, irgendeiner Vorrichtung mit einem Satz von einem oder mehreren Prozessoren, usw) zugegriffen werden kann.
-
In verschiedenen Ausführungsbeispielen kann eine festverdrahtete Schaltungsanordnung in Kombination mit Softwarebefehlen verwendet werden, um die Techniken zu implementieren. Daher sind die Techniken weder auf irgendeine Kombination einer Hardware-Schaltungsanordnung und Software noch auf irgendeine spezielle Quelle für die Befehle beschränkt, die vom Datenverarbeitungssystem durchgeführt werden.
-
Obwohl einige der Zeichnungen eine Anzahl von Operationen in einer speziellen Reihenfolge veranschaulichen, können Operationen, die nicht von einer Reihenfolge abhängen, neu geordnet werden und weitere Operationen können kombiniert oder herausgebrochen werden. Während einige Neuordnungen oder andere Gruppierungen besonders erwähnt sind, werden dem Durchschnittsfachmann weitere einleuchten und daher wurde keine erschöpfende Liste von Alternativen aufgeführt. Darüber hinaus sollte angemerkt werden, dass die Stadien in einer Hardware, Firmware, Software oder irgendeiner Kombination daraus implementiert werden können.
-
ZUSÄTZLICHE INFORMATIONEN
-
Im Gegensatz zu GPS verwendet GLONASS die FDMA-Technik für verschiedene Satelliten. Es ist bekannt, dass dieser Unterschied die Quelle von frequenzabhängigen Abweichungen in Pseudoentfernungs- und Trägerphasen-Messungen ist, die von einem kombinierten GNSS-Empfänger erzeugt werden. Diese Abweichungen können für jedes Empfänger-Hardwaredesign einzigartig sein und können außerdem in Abhängigkeit von den Empfänger-Firmware-Algorithmen variieren. Aus Sicht der differentiellen GNSS-Positonierung (einschließlich RTK) kann die Differenz in den GLONASS-Abweichungen zwischen dem Basis- und Rover-Empfänger ein gesamtes Fehlerbudget dominieren, insbesondere wenn die Basis- und Rover-Empfänger ein unterschiedliches Hardware-Design aufweisen (d. h. von verschiedenen Herstellern produziert wurden). Gleichzeitig können GLONASS Abweichungen zeitlich ziemlich konstant sein und können für ein vorgegebenes Empfängerpaar aus der gesamten Empfängerfamilie geschätzt werden. Diese geschätzten (dafür kalibrierten) Abweichungen können lange Zeit mit dem gleichen Empfänger verwendet werden, wobei der negative FDMA-Effekt reduziert wird.
-
Vorzugsweise sollte eine derartige Kalibrierung in einen Empfänger implementiert werden, der keine spezifischen Kalibrierungsvorgänge (d. h. die Implementierung einer On-The-Fly-(OTF-)GLONASS-Pseudoentfernungs- und Trägerphasen-Abweichungskalibrierung für eine differentielle Positionierung einschließlich RTK) verwendet.
-
GLONASS, das auf die gleiche Weise wie GPS verarbeitet wird, kann keine merkliche Leistungs-(Genauigkeits-)Verbesserung in kombinierten GPS + GLONASS-Empfängern erbringen. Die speziellen Maßnahmen sind erforderlich, damit GLONASS das GPS effizient erweitern kann.
-
Der schwächste Auftritt GLONASS sind Abweichungen zwischen Kanälen, die oftmals das Fehlerbudget dominieren.
-
Der größte Nutzen kann mit einer geeigneten GLONASS-Abweichungsbearbeitung für die differentielle GNSS-Positionierung und primär für die RTK erreicht werden.
-
Diese Maßnahmen sollten eine sorgfältige Bearbeitung der GLONASS-Pseudoentfernungs- und Trägerphasen-Abweichungen zwischen Basis- und Rover-Empfänger umfassen. Die so genannte On-The-Fly-(OTF-)Kalibrierungstechnologie muss implementiert werden, um der ineffektiven Werkskalibrierung einer „Vorinbetriebnahme”-Kalibrierung zu entgehen.
-
Derartige Algorithmen wurden entwickelt. Ohne diese Algorithmen, ist ein effektiver Einsatz des GLONASS im RTK-Prozess, insbesondere wenn mit einem Drittpartei-Basisempfänger gearbeitet wird, nicht praktikabel. Darüber hinaus wird die GPS + GLONASS-RTK ein im Vergleich mit dem ausschließlich verwendeten GPS schlechteres Leistungsverhalten aufweisen.
-
In der obigen Beschreibung wurde die Offenbarung mit Bezug auf spezifische beispielhafte Ausführungsformen beschrieben. Es ist offensichtlich, dass verschiedene Modifikationen darin erfolgen können, ohne von dem in den nachfolgenden Ansprüchen dargelegten weiteren Sinn und Umfang abzuweichen. Die Beschreibung und Zeichnungen sind dementsprechend im Sinne einer Veranschaulichung anstatt einer Beschränkung anzusehen.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- US 5914685 [0105, 0106, 0109]
-
Zitierte Nicht-Patentliteratur
-
- ”Algorithms to Calibrate and Compensate for GLONASS Bisses in GNSS RTK Receivers working with 3rd party Networks” vom 17. September 2008 (dieses Datum dient nur zu Planungszwecken – es ist noch keine Veröffentlichung erfolgt) von Alexey Boriskin und Gleb Zyryanov [0108]
- ”The GG24 Combined GPS + GLONASS Receiver”, S. Gourevitch, S. Sila-Novitsky, F. van Diggelen, Proceedings of ION-GPS '96, Sept 17–20, Kansas City, Missouri [0109]
- ”Centimeter Level Real-Time Kinematic Positioning with GPS + GLONASS C/A Receivers”, D. Kozlov, M. Tkachenko, Navigation: Journal of the Institute of Navigation, vol. 45, No. 2, Summer 1998, pp. 137–147 [0109]
- RTCM STANDARD FOR DIFFERENTIAL GNSS SERVICE – VERSION 2.3, RTCM SPECIAL COMMITTEE NO. 104, AUGUST 20, 2001 [0109]
- RTCM STANDARD FOR DIFFERENTIAL GNSS SERVICES – VERSION 3, RTCM SPECIAL COMMITTEE NO. 104, AUGUST 11, 2006 [0109]
- A GLONASS Observation Message Compatible With The Compact 30 Measurement Record Format, Leica Geosystems AG [0109]
- ”Statistical Characterization of Hardware Bisses in GPS + GLONASS Receivers”, D. Kozlov, M. Tkachenko, A. Tochilin, Proceedings of ION-GPS '2000, Salt Lake City, Utah [0109]
- ”Combined Processing of GPS, GLONASS and SBAS Code Phase and Carrier Phase Measurements”, L. Wanninger, S. Wallstab-Freitag, Proceedings of ION-GPS '2007, Fort Worth, Texas [0109]
- ”L1 RTK System with Fixed Ambiguity: What SBAS Ranging Brings”, A. Boriskin, D. Kozlov, G. Zyryanov, Proceedings of ION-GPS '2007, Fort Worth, Texas [0109]
