DE102009043801A1

DE102009043801A1 - Kompakte Übertragung von GPS-Informationen unter Verwendung eines komprimierten Messaufzeichnungsformats

Info

Publication number: DE102009043801A1
Application number: DE102009043801A
Authority: DE
Inventors: Kendall Sunnyvale Ferguson; Benjamin W. Sunnyvale Remondi; Michael Timo Sunnyvale Allison; Michael Sunnyvale Albright
Original assignee: Trimble Navigation Ltd
Current assignee: Trimble Inc
Priority date: 2008-10-03
Filing date: 2009-09-30
Publication date: 2010-04-08
Anticipated expiration: 2029-10-01
Also published as: DE102009043801B4; US20100085253A1; US8456359B2; US8031111B2; US8044849B2; CN101713822A; US20100085249A1; US20100085248A1; CN101713822B

Abstract

Ein Format zur Bereitstellung von Nachrichten innerhalb einer GNSS-Vorrichtung umfasst das Bereitstellen eines Nachrichtenidentifizierungsblocks und eines Nachrichtenkörpers. Der Nachrichtenidentifizierungsblock umfasst Informationen zur Spezifizierung einer Nachrichtenlänge und einen Nachrichtentypblock zur Spezifizierung eines Nachrichtentyps. Anstatt dass alle Daten von einer Vorrichtung an eine andere gesendet werden, werden mehrdeutige Beobachtungsdaten zur Erhaltung der Bandbreite gesendet. Beim Absender ermöglicht eine Dekonstruktion des GNSS-Codes und der Trägerbeobachtungen unter Benutzung des Wissens der Signalstrukturen und Konstellationsgeometrie zusammen mit den Vereinfachungen der atmosphärischen Modelle das Entfernen derjenigen Information von den Beobachtungsdaten, die ohne weiteres verständlich ist oder durch den Empfänger nachgebildet werden kann. Dies ermöglicht, dass nur die notwendige Information zur Übertragung an den Empfänger paketiert wird.

Description

Die vorliegende Erfindung betrifft die Kommunikation von Daten unter Empfängern, virtuellen Referenzstationen, Datenverarbeitungszentralen, Erkundungselementen und anderen Einrichtungen eines globalen Navigations-Satellitensystems („GNSS”), und insbesondere Techniken zum Übertragen dieser Daten in einem Format, das die Verwendung der Bandbreite, die für die Datenübertragung verfügbar ist, beibehält. In den vorliegenden Unterlagen wird die Erfindung im Hinblick auf eine Verwendung mit dem US-amerikanischen globalen Positionsbestimmungssystem („GPS”) beschrieben, die Begriffe GNSS und GPS werden jedoch austauschbar verwendet, um sich auf ein beliebiges globales Navigations-Satellitensystem zu beziehen, sei es auf Satelliten basierend, die von den Vereinigten Staaten oder von anderen Ländern bereitgestellt werden, z. B. GLONASS (Russland), Galileo (Europäische Union), GAGAN (Indien), usw. Wie es ersichtlich werden wird, ist die hier beschriebene Technologie auf eine Verwendung mit einem beliebigen GNSS-System, einschließlich GPS, anwendbar.
Eine als Echtzeit kinematische (RTK) Positionsbestimmung bekannte Technik wird gewöhnlich verwendet, um die Position eines Erkundungs-GNSS-Empfängers im Verhältnis zu einem bekannten Referenzpunkt zu bestimmen. Dieses Verfahren erfordert, dass Daten von einem Referenzempfänger oder von einem Netz von Referenzstationen in Echtzeit an das Erkundungselement übertragen werden. Die RTK-Technik wird routinemäßig für Vermessungs-, Kartierungs- und präzise Positionsbestimmungsanwendungen im Bergbau, Bauwesen und vielen anderen Industriezweigen verwendet. Bei der RTK-Positionsbestimmung verfolgt eine Gruppe von GNSS-Empfängern GNSS-Signale einer Satellitenkonstellation. Bei einer typischen Anwendung wird eine Referenzstation an einem bekannten Ort aufgestellt, wie etwa an einem zuvor vermessenen Ort, einem Fixpunkt oder an einer anderen gewünschten Position. Diese Referenzstation liefert dann GNSS-Messungen an eine Erkundungsstation, um es der Erkundungsstation zu ermöglichen, ihren präzisen Ort im Verhältnis zu einem zuvor bestimmten Bezugspunkt zu berechnen. Die Erkundungsstation, die oft in einem Rucksack oder auf einer sich fortbewegenden Maschine angebracht wird, ist dann in der Lage, sich am Standort zu bewegen und Signale von der Referenzstation zu verwenden, um gewünschte Positionen am Standort präzise zu orten. Die Kommunikation zwischen der Referenzstation und dem Erkundungssystem wird über eine Datenverbindung bereitgestellt, z. B. unter Verwendung einer privaten konzessionierten Funktechnologie, einer nicht konzessionierten Funktechnologie, einer Satelliten-, zellularen oder anderen Kommunikationstechnologie. Am Erkundungselement werden die Daten empfangen und zur Verarbeitung und/oder Anzeige für den Benutzer des Systems verwendet.
Die Zuteilung von Funk-, zellularen oder anderen drahtlosen Frequenzbändern erfolgt gewöhnlich über eine Regierungsbehörde. In den Vereinigten Staaten bestimmt die „Federal Communications Commission” die geeignete Zuteilung des Frequenzspektrums, und in anderen Ländern erfolgt dieser Dienst durch ähnliche Behörden. Die steigende Nachfrage bei der Frequenzzuteilung für neue Funk-, zellulare und Satellitenanwendungen hat jedoch zu einem Mangel an verfügbarer Bandbreite geführt. Gleichzeitig nimmt die Datenmenge, die es zwischen GNSS-Empfängern zu kommunizieren gilt, weiter zu. Es hat sich daher als immer wünschenswerter erwiesen, diese Daten unter Verwendung von möglichst wenig Bandbreite zu kommunizieren.
Eine vorbekannte Technik zum Kommunizieren von Daten unter GNSS-Empfängern wurde von dem Rechtsnachfolger der vorliegenden Erfindung, Trimble Navigation, entwickelt und wird gewöhnlich als „Kompakte Messungsaufzeichnung” (CMR) bezeichnet. Eine Beschreibung dieser Technik ist bei N. Talbot, "Compact Data Transmission Standard for High-Precision GPS," Proceedings of ION-GPS-96, Kansas City, Missouri, 861–871 (1996), zu finden. Obwohl dieses Format nun weit verbreitet ist, benötigt das Format weiterhin eine minimale Datenrate, die in dem Maße ansteigt, wie weitere Satelliten in der verfügbaren Konstellation von Satelliten, deren Verwendung erwünscht ist, hinzugefügt werden; die Bereitstellung der Dienstleistung in Echtzeit bedeutet, dass mehr Bandbreite benötigt wird, und dass die Bandbreite über die derzeitige Auswahl von Kommunikationsdiensten vielleicht nicht verfügbar ist. Die meisten Kommunikationsdienste verfügen über eine festgelegte Bandbreite, die nicht überschritten werden kann. Entsprechend zielt die vorliegende Erfindung auf eine Technik ab, um die unter GNSS-Empfängern zu sendende Informationsmenge weiter zu reduzieren, wenn Bandbreite knapp bemessen ist, nicht erweitert werden kann, oder in Situationen, wie bei Satellitentranspondern, bei denen erweiterte Bandbreite nur zu hohen Kosten verfügbar ist.
KURZDARSTELLUNG DER ERFINDUNG
Wir haben eine Technik entwickelt, um Daten unter GNSS-Verarbeitungseinheiten oder anderen globalen Positionsbestimmungs-Satelliteneinrichtungen zu kommunizieren. Diese Technik wird im Hinblick auf das US-amerikanische GPS-System beschrieben. Bei der Kommunikation derartiger Daten kann z. B. ein Benutzer eines GPS-Systems über eine Referenzstation verfügen, die sich an einem bekannten Ort befindet und Daten von einem „Erkundungselement” empfangen oder an dieses senden soll. Ein Erkundungselement besteht aus einer beweglichen Station, wie sie z. B. von einem Vermesser oder bei einer ähnlichen Nutzung verwendet wird.
Die Kommunikationstechnik wird hier als „Komprimierte Messungsaufzeichnung – Erweitert” (hier oft „CMRx”) bezeichnet. Die CMRx stellt zahlreiche Vorteile bereit, zu denen eine hohe Komprimierung der unaufbereiteten GPS-Beobachtungsdaten gehört. Durch das Senden so genannter „mehrdeutiger Beobachtungsdaten” statt vollständiger Daten von einer Beobachtung wird die Datenmenge, die gesendet werden muss, reduziert, was es ermöglicht, mehr Daten für eine bestimmte Datenrate zu senden, was ein Dienstleistungswachstum in Datendienstleistungsumgebungen mit beschränkter Bandbreite ermöglicht. Die „mehrdeutige” Form ist jedoch für den Empfänger ausreichend bekannt, um eine vollständige Rekonstruktion der Beobachtungsdaten zu ermöglichen. Die CMRx komprimiert Daten nicht so, wie man es unter dem Begriff „komprimieren” normalerweise versteht, z. B. im Zusammenhang mit einer „Zip-”Datei, die an einen Computer gesendet wird. Stattdessen wird die Komprimierung, bzw. die Reduzierung der Datenmenge, dadurch erzielt, dass nur die GPS-Daten gesendet werden, die der Empfänger „benötigt”. (Selbstverständlich können diese Daten als solche noch im mathematischen Sinne komprimiert werden, z. B. indem sie in eine Zip-Datei eingefügt werden). Am Sender ermöglicht es eine Dekonstruktion der GPS-Code- und Trägerbeobachtungen unter Verwendung der Kenntnis der Signalstruktur und der Konstellationsgeometrie zusammen mit Vereinfachungen atmosphärischer Modelle, dass von den Beobachtungsdaten diejenigen Informationen entfernt werden, die vom Empfänger implizit verstanden oder wiederhergestellt werden können. Dadurch ist es möglich, nur die notwendigen Informationen für die Übertragung an den Empfänger zu paketieren.
Zu den Kenntnissen, die Sender und Empfänger gemeinsam haben, gehört das Wissen, dass die beobachteten Umlaufbahnen der Satelliten nahezu gleich sind, die Position des Senders, die über die Kommunikationsverbindung bei niedrigen Datenraten „verstreut” werden kann, ein Algorithmus zum Entfernen und Rekonstruieren des größten Teils der Signalverzögerung, die durch die Ionosphäre verursacht wird, um den Bereich der Beobachtungsgrößen zu reduzieren, ein Algorithmus zum Entfernen und Rekonstruieren des größten Teils der Signalverzögerung, die durch die Troposphäre verursacht wird, mit einem vereinfachten Modell, das eine minimale Berechnung benötigt, das Abkürzen von Code mit einer Fenstermethode, das Abkürzen des Trägers unter Verwendung einer Fenstermethode, die auf dem rekonstruierten Codewert basiert, eine variable Fensterdimensionierung für Code und Träger und ein zweistufiger Zähler zum Signalisieren von Zeiträumen ohne Zyklusfehlleistung. Z. B. wissen zwei miteinander kommunizierende GPS-Empfänger, dass die zwischen ihnen ausgetauschten Daten von GPS-Satelliten stammen und dass der Empfänger bereits über Informationen bezüglich der Satelliten, ihrer Umlaufbahnen, ungefähren Entfernungen, usw. verfügt.
Das Hauptziel der CMRx ist es, die Anzahl der Bits zu reduzieren, die benötigt werden, um die GNSS-Beobachtungsdaten und -informationen zu transportieren. Zudem stellt die CMRx für den Empfänger eine komprimierte Nachricht bereit, die genug Informationen enthält, um ihre Dekomprimierung zu ermöglichen, um den Inhalt der ursprünglichen Ausgangsbeobachtungsdaten zu bestimmen.
Ein weiterer Vorteil ist die einheitliche Verwendung der verfügbaren Bandbreite. Viele von der CMRx anvisierte Anwendungen verwenden Kommunikationsmittel, die bezüglich der Bandbreite stark eingeschränkt sind. Viele GNSS-Systeme unterstützen Formate, die öffentlich verfügbar sind und sehr unterschiedliche Nachrichten und Nachrichtengrößen haben. Eine Formate können z. B. ein reduziertes Beobachtungsformat unterstützen, benötigen jedoch eine große Fremdnachricht, wie z. B. bei Rundfunkumlaufbahnen oder Referenzpositions-/Referenzrahmeninformationen. Wenn derartige Informationen gesendet werden, ist ein Anstieg der Datenmenge notwendig, der entweder mehr Zeit zum Übertragen oder mehr Bandbreite benötigt, um die Daten in einem vorgegebenen Zeitraum abzuhandeln, oder die Beobachtungsdaten werden nicht gleichzeitig gesendet. Die CMRx gleicht die Bandbreitenverwendung aus, indem sie diese Fremdinformationen in kleinen kurzen Bitgruppen „verstreut”, die über einen längeren Zeitraum verteilt werden, und indem sie somit die Bandbreite regelmäßiger verwendet.
Die CMRx-Daten vermeiden auch möglichst Zeitabhängigkeiten. Um Zeitabhängigkeiten zu reduzieren, ermöglichen die CMRx-Nachrichten es dem Empfänger, die unaufbereiteten Beobachtungsdaten ohne Abhängigkeiten von der Zeit zu rekonstruieren. Z. B. enthalten die CMRx-Beobachtungsdaten keine Raten oder Werte, die von früheren oder späteren CMRx-Epochendaten abhängig sind.
Ein weiterer Vorteil der Erfindung ist, dass die CMRx Informationen über Position und Koordinatenrahmen der Referenzstation umfasst. Diese Informationen können ebenfalls über mehrere CMRx-Nachrichten „verstreut” werden, um die Bandbreitenverwendung im Zeitablauf zu glätten.
Die CMRx unterstützt Datensender auf beweglichen Plattformen, z. B. bewegliche Referenzstationen und Erkundungselemente, die unaufbereitete Beobachtungen an andere Verarbeitungsstandorte übertragen. Das CMRx-Nachrichtensystem umfasst auch wahlweise Orbitalinformationen, um zu gewährleisten, dass der Empfänger der CMRx-Nachrichten Zugriff auf die Orbitalinformationen des Satelliten hat. Wenn Integritätsprozesse betroffen sind, stellt die Tatsache, dass die Endbenutzer von der CMRx gesendete Orbitaldaten verwenden, sicher, dass auf Integrität kontrollierte Daten oder präzise Orbitalinformationen verwendet werden.
Die Größe der CMRx-Nachrichten wird weiter reduziert, indem atmosphärische Daten entfernt und/oder gesendet werden, z. B. Daten über die Ionosphäre, jedoch auch in einem mehrdeutigen, abgekürzten Format. Zudem kann das CMRx-Nachrichtenformat auf andere Arten der Satellitenbeobachtung, z. B. GLONASS-Satelliten, erweitert werden und kann andere Modelle, wie etwa das NOAA-Troposphärenmodell, unterstützen. Die CMRx ermöglicht es, das Format der Daten den Bedürfnissen der Systementwicklern und -integratoren anzupassen, so dass sie die Konfigurationen auswählen können, die sich auf die Größe der Elemente und der Optionen auswirken, um die Komprimierung zu aktivieren, die den Bedürfnissen ihres Systems am besten entspricht. Da das Formt selbstbeschreibend ist, können die Empfänger von CMRx-Nachrichten den gesamten Inhalt der gesendeten Nachrichten verstehen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Es zeigen:
1 ein Funktionsschema einer Durchführung der Erfindung.
2 ein Flussdiagramm des Betriebs des Nachrichten-Managers.
3 ein Diagramm, das eine Fenstertechnik abbildet.
4 ein Diagramm, dass eine Bit/Byte-Ausrichtung abbildet.
5 das Format der CMRx-Nachricht.
6 das Format des ID-Blocks der CMRx-Nachricht.
7 das Format des GPS-Beobachtungsdatenblocks der CMRx.
8 das Format des GPS-Beobachtungs-Kopfzeilenblocks der CMRx.
9 das Format des Positionsblocks.
10 das Format des unsegmentierten Positionskonstrukts.
11 das Format der vollständigen Positionsnachricht.
12 das Format der über 2 Epochen gesendeten Positionsnachricht.
13 das Format des Standortinformationsblocks.
14 das Format des unsegmentierten Standortinformationskonstrukts.
15 das Format der Standortinformationen pro Epoche.
16 das Formt des einen Segments der über vier Epochen verstreuten Standortinformationen.
17 das Format des VRS/PBS-Blocks.
18 das Format des unsegmentierten PBS-Konstrukts.
19 das Format des PBS-Blocks.
20 das Format der vollständigen PBS pro Epoche.
21 das Format des VRS-Netzwerkresteblocks.
22 das Format des VRS-Netzwerkresteblocks pro Satellit.
23 das Format des Beobachtungsblocks.
24 das Format der Definitionsbits des Beobachtungsblocks.
25 ein Diagramm, dass eine Technik zum Ausgleichen von ionosphärischen Effekten abbildet.
26 das Format der Hauptdaten der Umlaufbahnen.
27 das Format der Satellitenbeobachtungsdaten.
28 das Format eines einzelnen Satellitenbeobachtungsdatenelements.
29 das Format der Nebendaten der Umlaufbahn.
30 das Format eines Iono/Tropo-Fensterblocks.
31 die Ephemeridenzeit.
32 das Format eines Textnachrichtenblocks.
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
Einleitung
Die vorliegende Erfindung betrifft globale Navigations-Satellitensysteme und insbesondere die Übertragung von Informationen unter den Verarbeitungsvorrichtungen eines globalen Navigations-Satellitensystems, wie etwa Empfängern, virtuellen Referenzstationen, Datenverarbeitungszentralen und Erkundungselementen. Die Empfänger von Positionsbestimmungsinformationen von Satelliten möchten gegebenenfalls diese Informationen anderen Stationen kommunizieren, um Informationen über die relativen Positionen der Stationen bereitzustellen. 1 ist ein Flussdiagramm, das den typischen Betrieb eines die Erfindung einsetzenden Systems abbildet. Wie abgebildet, werden GPS-Daten gesammelt, die an einer Referenzstation oder einer anderen Station empfangen werden und hier als „Observablen” bezeichnet werden. Die Daten umfassen typischerweise sowohl Code- als auch Trägerphaseninformationen.
Ein GPS-Empfänger bestimmt die Laufzeit eines Signals von einem Satelliten aus, indem er den „Pseudozufallscode”, den der Empfänger erzeugt, mit Code vergleicht, der in dem Signal von dem Satelliten übertragen wird. Der Empfänger vergleicht seinen eigenen erzeugten Code mit dem Code von dem Satelliten, wobei er seinen Code zeitlich immer weiter verschiebt, bis er mit dem Code des Satelliten übereinstimmt. Die Laufzeit entspricht dem Zeitunterschied zwischen dem Satelliten und dem Bodenstandort. Somit ortet die Laufzeit des Signals von einem Satelliten aus die Empfangsstation an einer Gruppe von Punkten, die von dem Satelliten äquidistant sind. Unter Verwendung von Signalen von mindestens vier Satelliten kann eine X, Y und Z Position bestimmt werden, zusammen mit dem Fehler des lokalen Empfängertaktgebers. Diese Koordinaten können in geografische Breite, Länge und Höhe umgesetzt werden.
Der Zeitraum des Pseudozufallscodes ist jedoch so lang, dass der Ort des Empfängers nur mit einer Präzision von vielen Metern bestimmt werden kann. Weiter entwickelte GPS-Empfänger beginnen mit dem Pseudozufallscode, verwenden dann aber zusätzliche Messungen, die auf der Trägerfrequenz für diesen Code basieren. Diese Trägerfrequenz ist viel höher, wodurch ihre Wellenlänge viel kürzer ist, und daher eine genauere Positionsbestimmung ermöglicht. Der Empfänger kann jedoch nur die relative Phase einer einzigen Wellenlänge messen. Unter der Annahme, dass keine Zyklusfehlleistung vorliegt, kann der Empfänger somit die Bereichsänderung messen. Bei jeder nachfolgenden Messung fehlt dann die ursprüngliche Ambiguität seit Beginn der Nachverfolgung. Um die Trägerphasenmessungen zu verwenden, muss der Empfänger Gesamtanzahl der Wellenlängen zwischen seiner Antenne und dem Satelliten abschätzen. Die gesamte Wegelänge besteht somit aus einer ganzzahligen Anzahl von Wellenlängen plus Wellenlängenbruchteil, der durch den GNSS/GPS-Empfänger bestimmt wird. Die hier vorliegende Unbekannte wird als „ganzzahlige Ambiguität” oder allgemeiner als „Ambiguität” bezeichnet.
Wie in 1 gezeigt, werden bei der vorliegenden Erfindung die Codephaseninformationen und die Trägerphaseninformationen (soweit vorhanden) berücksichtigt, um die Stationsobservablen 10 zu sein. Wie oben erwähnt, ist die Station typischerweise eine GPS-Referenzstation, es können jedoch auch andere Stationen verwendet werden. Diese Daten, sowie andere dem Empfänger bekannte Informationen, werden einem Nachrichten-Manager 12 bereitgestellt. Der Nachrichten-Manager 12 verarbeitet die Daten, um Informationen zu entfernen, die zwischen Sender und Empfänger bekannt sind, und komprimiert dann die sich ergebenden Daten. Die Verarbeitung und Komprimierung werden nachstehend ausführlicher beschrieben. Im Wesentlichen werden die Daten jedoch verarbeitet, um Informationen zu entfernen, die dem Sender und dem Empfänger der Daten gewöhnlich bekannt sind. Z. B. wissen sowohl der Sender als auch der Empfänger, dass die Daten GNSS-bezügliche Daten sind, mit anderen Worten, dass ihr Inhalt auf Signalen von Satelliten basiert, die bekannte Umlaufbahnen haben, deren Satellitensignale sowohl an der Referenzstation als auch am Erkundungselement verfügbar sind. In einer vernetzten Stationsgruppe kennt z. B. eine Station mindestens ungefähr den Ort der Referenzstation und kennt daher die Umlaufbahnen der Satelliten, die von der Sendestation beobachtet werden. Sobald die Daten verarbeitet und paketiert sind, werden sie dann zu einer Nachricht 15 formatiert zur Übertragung an einen entfernten Ort, typischerweise eine Erkundungs-GNSS-Empfängerstation, die in einem Rucksack oder auf einer beweglichen Einrichtung angebracht ist. Das Nichtsenden der unnötigen Informationen macht die Nachrichten kleiner, sodass weniger Zeit benötigt wird, was es ermöglicht, die verfügbare Bandbreite für eine zusätzliche Datenübertragung zu verwenden.
Der CMRx-Manager 12 ist auch dafür verantwortlich zu entscheiden, welche Verstreuungsstufen und welche Positionsausgaberaten notwendig sind. Verstreute Nachrichten sind Nachrichten, bei denen Daten in kürzere Stücke segmentiert und über einen größeren Zeitraum gesendet werden als er für eine ununterbrochene Signalübertragung benötigt würde. Somit überbrückt eine „verstreute” Nachricht mehr als eine RTK-Informationsepoche vom Referenzempfänger, einer CMRx-Sendevorrichtung oder einem Netzwerk. Eine vollständige Datenfolge wird über mehrere Epochen verstreut und besteht typischerweise aus Informationen, die sich wiederholen oder für den Echtzeitbetrieb weniger wesentlich sind. Die Position der Referenzstation ist beispielsweise eine Information, die für den RTK-Start wesentlich ist. Geht man von einer statischen Basisstation aus, so wird, nachdem die Position empfangen wurde, von diesem Punkt ab für die Verarbeitung dieselbe Position verwendet. Die Position muss also nicht allzu oft empfangen werden. Das Format ermöglicht das Verstreuen derartiger Positionsinformationen über mehrere Epochen. Dies erfolgt derart, dass ein Empfänger mit Almanach-Informationen wissen kann, ob der Empfänger die gesamte Folge verstreuter Informationen empfangen muss, ehe er einen Schnellstart mit einer Almanach-Position ausführen kann. Der Manager 12 ändert auch die Codierungsoptionen je nach Bedarf, um die verfügbare Bandbreite zu verwenden und/oder ihre Verwendung einzuschränken. Der Manager 12 schränkt alle Daten ein, die codiert werden sollen. Wenn die Einschränkung der Nachrichtengröße z. B. dadurch erreicht wird, dass die Anzahl der Satelliten eingeschränkt wird, stellt der Manager dem Codierungsprozess Epochendaten bereit, die nur die zu paketierenden Satelliten enthalten. Er kann auch je nach den spezifischen Anwendungsbedürfnissen Konfigurationsoptionen andern, um Komprimierungsmodi und/oder -stufen anzupassen, um die Größen der in die Nachricht paketierten Elemente zu ändern. Da die CMRx selbstbeschreibend ist, ist der CMRx-Decodierer in der Lage, die Änderung sofort – spontan – zu verstehen.
Am entfernten Ort empfängt ein Decodierer 18 die Informationen und decodiert sie, wobei er sie schließlich als Ausgangsinformationen 19 zur Verwendung durch einen Computer, eine GPS-Station oder ein anderes gewünschtes Gerät bereitstellt. Der Decodierer 18 führt keine Rahmenerkennung aus, d. h. er identifiziert nicht die Bits und Bytes, die eine CMRx-Nachricht bilden. Die CMRx-Nachrichten sind in andere Protokolle eingewickelt, z. B. TrimComm, erhältlich bei Trimble Navigation (Rechtsnachfolger der vorliegenden Erfindung), was es noch weiter ermöglicht, die Nachrichtengröße klein zu halten.
Der Decodierer 18 kann jedoch das Ende einer Epoche erkennen. Der Manager 12 ist für eventuelle Zeitüberschreitungen verantwortlich, die verwendet werden, um das Ende einer Warteperiode zu erstellen, um eine vollständige Epoche zu empfangen, und zeigt das Ende einer Epoche über einen API-Aufruf an den CMRx-Decodierer 18 an. Wenn ein Ende einer Epoche entweder durch die automatischen Verfahren oder durch einen externen Manageraufruf angezeigt wird, sendet der Decodierer 18 zurück, was er zu diesem Zeitpunkt über die Epoche weiß.
2 ist ein Flussdiagramm des Betriebs des Nachrichten-Managers. Wie hier gezeigt, werden die Observablen 10 der Referenzstation zunächst analysiert, um die Daten in Schritt 12 vorzubereiten. In diesem Vorbereitungsschritt werden unvollständige oder korrupte Daten verworfen, die sich aus einer Reichweitenmessung zwischen einer Bodenstation und einem Satelliten ergeben. Die Reichweitenmessung, und gegebenenfalls die Trägerdaten, werden dann für ionosphärische und troposphärische Effekte, wie in Schritt 14 gezeigt, korrigiert. Dann wird in Schritt 15 ein Fensterindex, wie nachstehend ausführlicher beschrieben wird (siehe 3), bestimmt. Der Fensterindex ermöglicht eine zusätzliche Datenkomprimierung. In Schritt 16 werden codierte Observablen unter Verwendung des Fensterindex, der korrigierten Reichweitenmessungen und gegebenenfalls der Trägerdaten erstellt. Die Daten werden dann in Schritt 18 paketiert und in Schritt 19 wird eine Nachricht gesendet.
3 bildet das Konzept des Fensterindex ab, wie er bei CMRx verwendet wird. Eine „Fenstertechnik” ermöglicht es, die Reichweite zwischen der Station 30 und dem Satelliten 38 in eine ganzzahlige Anzahl von Fenstern 32 genannten Längensegmenten, z. B. 49 Meter lang, zusammen mit einem restlichen Bruchteilfenster 33 zu unterteilen. Das Bruchteilfenster stellt nämlich den Rest der Reichweite dar, die in die Anzahl von ganzen Fenstern unterteilt wird. Die Fenstergröße wird basierend auf den Resten und anderen Faktoren, wie etwa bekannten maximalen Verschiebungen der Umlaufbahnen, ausgewählt.
Die Verwendung des Fensterindex erlaubt es der die Informationen sendenden Station, einfach die ganzzahlige Anzahl von Fenstern und den Rest ΔW anstelle der Reichweite in Meter, Zentimetern oder einem anderen Format zu senden, das mehr Bandbreite verbrauchen würde. Somit ist es nur der „Rest”, der eine hohe Präzision zum Senden an die Empfangsstation benötigt. Wie rechts in 3 gezeigt, umfasst das Bruchteilfenster 33 einen Entfernungsfaktor „ΔW”, der die Unterteilung wiedergibt, zusammen mit einer ionosphärischen Korrektur und einer troposphärischen Korrektur. Die Art und Weise, in der diese Korrekturen berechnet und übertragen werden, sowie eine ausführlichere Erklärung des Lösungsansatzes der Fenstertechnik, werden jeweils nachstehend besprochen.
Bitausrichtung
In den Figuren der vorliegenden Beschreibung werden binäre Zahlen mit der niedrigen Zahl ganz links und mit der hohen Bitzahl ganz rechts abgebildet. Die Bits auf der rechten Seite sind die niedrigstwertigen Stellen der Zahlen, während die auf der linken Seite die höchstwertigen Stellen sind. Somit sind CMRx-Nachrichten eine Komprimierung auf Bit-Ebene, welche die bestimmte Bitreihenfolge angibt. 4 zeigt eine zusammenhängende Ausrichtung sowohl der Bits als auch der Bytes. Diese stellen die Speicherreihenfolge in CMRx-Nachrichten dar. Zahlen, die in diesem komprimierten Format gespeichert werden, werden mit den höchstwertigen. Bits nach links gespeichert. Beispielhaft beginnt die in 13 Bits gespeicherte Zahl 3637 mit einer Reihe von Bits („beliebige” Bits), auf die das Bitmuster 0111000110101 folgt, um 3637 darzustellen.
Alle Mengenangaben im CMRx-Format sind ganzzahlig. Gleitkommazahlen werden in eine Ganzzahl umgewandelt, indem die Gleitkommazahl skaliert und auf die nächste Ganzzahl gerundet wird. Wenn die Ganzzahl durch die CMRx-Decodierungsprozesse entnommen wird, wird der Skalierungsfaktor angewendet, um die ursprüngliche Menge zu erhalten, weniger einer gewissen Rundungsmenge, die durch den Skalierungs-/Rundungsprozess herbeigeführt wird.
Annahmen
Bei der bevorzugten Ausführungsform für die Durchführung der CMRx werden Annahmen gemacht. Diese Annahmen sind herkömmlich, es können jedoch andere Annahmen zur Durchführung in einem beliebigen gewünschten System verwendet werden. Insbesondere geht die Durchführung hier davon aus, dass die Beobachtungsdaten für ein Nullantennenmodell angepasst wurden. Das CMRx-Format geht ebenfalls davon aus, dass die Daten, die ihm zur Komprimierung bereitgestellt werden, für ein Nullantennenmodell angepasst sind. Die tatsächlich verwendete Antenne wird in dem unten beschriebenen Standortinformationsblock dokumentiert.
CMRx geht ebenfalls davon aus, dass die ihr zur Komprimierung bereitgestellten Satellitenbeobachtungsdaten für das Antennenphasenzentrum (APC) angepasst sind. Diese APC-Koordinaten werden in dem unten beschriebenen Positionsblock angegeben. Die Höhe über der Markierung ist in dem Standortinformationsblock enthalten.
Der Versatz des Empfängertaktgebers wird nicht als Teil der CMRx-Beobachtungsdatennachrichten gespeichert. Dies ist mit Bezug auf die höheren Komprimierungsstufen bei CMRx-Beobachtungsdatennachrichten wichtig, wobei die Position der Referenzstation (bis auf weniger als 50 Meter) und der Taktgeberversatz (bis auf weniger als ungefähr 150 ns) bekannt sein müssen, um die Beobachtungsdaten richtig zu entpaketieren. Obwohl es möglich ist, zum Speichern der Informationen des Empfängertaktgeberversatzes Bits zur Nachricht hinzuzufügen, erfolgt dies um Bandbreite einzusparen in der vorliegenden Durchführung nicht. Somit geht man davon aus, dass alle Daten, die dem CMRx-Codierer bereitgestellt werden, auf einen Nullversatz des Empfängertaktgebers gerichtet sind.
Ebenfalls wichtig ist die Handhabung der Millisekunden-Taktgebersprünge, die in den Satellitenbeobachtungsdaten von einigen GNSS-Empfängern vorkommen. Die CMRx-Codierung geht davon aus, dass wenn ein Taktgebersprung erfolgt, der Deltacode minus Deltaträger folgerichtig bleibt. D. h., dass ein Deltacode berechnet wird, indem die Pseudoreichweite (d. h. der Code) für einen bestimmten Satelliten in der vorherigen Epoche von der Pseudoreichweite für denselben Satelliten in der derzeitigen Epoche abgezogen wird. Die Deltaträgerphase wird berechnet, indem die Trägerphase für einen bestimmten Satelliten in der vorherigen Epoche von der Trägerphase für denselben Satelliten in der derzeitigen Epoche abgezogen wird. Wenn man davon ausgeht, dass keine Zyklusfehlleistungen vorliegen, sollte der Unterschied zwischen dem Deltaträger und dem Deltacode gering bleiben. Die Codephasen-Observablen bestimmter Empfänger werden jedoch jedes Mal beeinflusst, wenn ein Millisekundensprung im Taktgeber des Empfängers erfolgt. Diese Observablen weisen einen entsprechenden Sprung in ihrer Codephase, jedoch nicht die entsprechenden Trägerphasendaten (oder umgekehrt) auf. Daher weist der Deltacode minus Deltaträger einen Sprung auf, der die gleiche Größe aufweist, wie der Taktgebersprung. Dieser Komprimierungsalgorithmus geht davon aus, dass die Daten „repariert” werden, die an die Komprimierung weitergegeben werden, so dass dieser „Deltacode minus Träger” folgerichtig bleibt: d. h. dass er nicht diese Sprünge auf Millisekundenebene aufweist. (Die obigen Aussagen werden in dem Fall gemacht, dass eine Durchführung beschließt, die zusätzlichen Taktgeberversatzbits zu übernehmen, so dass es nicht notwendig ist, die Observablen auf einen Nullversatz auszurichten.)
Der CMRx-Decodierer ist keine Rahmenerkennungsvorrichtung, obwohl der Fachmann verstehen wird, dass eine derartige Funktion mühelos hinzugefügt werden kann. Bei der bevorzugten Durchführung erwartet der CMRx-Decodierer, dass man ihm vollständige Nachrichten übergibt, die von einem anderen Prozess aus Strömen oder Dateien entnommen wurden. Der CMRx-Decodierer decodiert dann diese Nachrichten.
Eine weitere Annahme ist, dass alle Daten für eine Epoche übertragen werden, bevor die nächste Epoche gesendet wird. Ein Epochenweiterführungs-Flag (ECF) bedeutet, dass in derselben Epoche noch etwas kommt. Der CMRx-Decodierer legt das Ende einer Epoche fest, wodurch er alle empfangenen Nachrichten ausschließt, deren ECF-Flag nach dem Empfang einer späteren Epochenzeit auf Null steht. Alles was mit einer älteren Epochenzeit empfangen wird, wird ignoriert.
Terminologie
Um zum Verständnis der hier beschriebenen Technologe beizutragen, werden, falls nicht anders angegeben, die nachstehenden Begriffe folgendermaßen verwendet.
Codierer, Sender oder Komprimierung/Decodierer, Empfänger oder Dekomprimierung
Die Begriffe Codierer, Sender oder Komprimierung (und/oder Decodierer, Empfänger oder Dekomprimierung) werden hier oft austauschbar verwendet. Die Begriffe Codierung und Komprimierung (bzw. Decodierung und Dekomprimierung) werden austauschbar verwendet. Im Zusammenhang mit der CMRx werden Nachrichten von einem Sender erstellt (d. h. codiert oder komprimiert). Diese Nachrichten werden dann über ein Mittel (über eine Kommunikationsverbindung, durch Dateien oder andere derartige Lösungsansätze) an einen Empfänger gesendet, der die Nachrichten decodiert oder dekomprimiert. Der Sender kann eine Referenzstation, ein Erkundungselement, eine Netzwerkverarbeitungsstation, wie etwa ein VRS-Anbieter, oder ein anderes Gerät sein, während ein Empfänger eine Referenzstation, ein Erkundungselement, ein anderes Gerät oder ein anderes Verarbeitungssystem, z. B. ein zentrales Verarbeitungszentrum, sein kann.
Frequenz-/Verfolgungsarten
Frequenz-/Verfolgungsarten werden verwendet, um die diversen beobachtbaren Kombinationen als Ausgabe von einem Empfänger zu beschreiben. Für GPS-Empfänger, welche die Observablen L1, L2 und L5 verfolgen und melden, gibt es drei unabhängige Frequenz-/Verfolgungsarten. Viele Empfänger sind in der Lage, mehr als eine Art von Code auf einer einzigen Frequenz zu verfolgen und verfügen über eine Trägerverfolgung/-meldung, die mit jeder Code-Verfolgung verknüpft ist. Zukünftige L1-fähige GPS-Empfänger können eventuell L1 C/A, L1c und L1E gleichzeitig verfolgen. Jedes dieser L1-Signale wird als eine unabhängige Frequenz-/Verfolgungsart angesehen. Ein GPS-Empfänger, der in der Lage ist, L1 C/A, L1c, L1E, L2c, L2E und L5 zu verfolgen und zu melden, wird als über 6 unabhängige Frequenz-/Verfolgungsarten verfügend bezeichnet.
Übergeordnet (Major) und untergeordnet (Minor)
Einige Elemente innerhalb der CMRx-Nachrichten werden unter Verwendung der Begriffe übergeordnet (Major) und untergeordnet (Minor) beschrieben. Sie werden verwendet, um Elemente oder andere Daten innerhalb der Nachricht zu beschreiben, die Informationsblöcke, Bitsets oder ein einzelnes Bit sein können. Innerhalb der CMRx-Nachrichten gibt es Elemente, die Informationen enthalten, die sich auf eine gemeinsame Informationsfolge beziehen oder darauf angewendet werden. Wenn z. B. GPS-Beobachtungen L1-C/A-Daten enthalten, kann ein Flag verwendet werden, um anzugeben, dass L1-C/A-Daten für jeden GPS-Satelliten vorliegen. Ein derartiges Flag ist ein Beispiel von übergeordneten Daten. Einige Informationen können die übergeordneten Daten erweitern, indem sie weitere Einzelheiten auf individueller Basis bereitstellen. Z. B. können übergeordnete Bits angeben, dass L2C-Daten in einer Epoche vorliegen und dass sie auf einer individuellen Satellitenbasis angegeben werden. Dann gibt es bei den Daten jedes GPS-Satelliten ein untergeordnetes Bit, das angibt, ob Daten für diesen Satelliten vorliegen oder nicht.
Nomineller Schlimmstfall
Der Begriff „Schlimmstfall” wird verwendet, um sich auf die äußersten Bedingungen zu beziehen, denen ein System ausgesetzt sein kann. Der Begriff nomineller Schlimmstfall wird verwendet, um sich auf extreme Bedingungen zu beziehen, bei denen erwartet wird, dass das System damit fertig werden muss. Unter den wirklichen Schlimmstfallbedingungen der Ionosphäre geht man z. B. davon aus, dass die GNSS-Empfänger noch nicht einmal in der Lage sind, die Satelliten zu verfolgen. Die CMRx ist dazu gedacht, Daten zu handhaben, die unter nominellen Schlimmstfallbedingungen der Ionosphäre gesammelt werden, was in diesem Fall bedeutet, dass der GNSS-Empfänger wahrscheinlich viele Verfolgungsverluste erfährt, jedoch in der Lage ist, einige Satelliten zu verfolgen.
Paketverlust, Nachrichtenbeschädigung, Nachrichtenverlust und Kommunikationsausfälle
Diese Begriffe werden nahezu austauschbar verwendet. Sie sind dazu gedacht, die Vorstellung zu vermitteln, dass über ein Übertragungsmittel mitgeteilte Daten ihr Ziel eventuell nicht erreichen, oder wenn ja, dass das Ziel wahrscheinlich beschädigt ist. Wenn eine Nachricht verloren geht, wird sie nicht decodiert. Wenn eine Rahmenerkennungsvorrichtung eine CMRx-Nachricht empfängt und die Qualitätsprüfungsmechanismen der Rahmenerkennungsvorrichtung eine beschädigte Nachricht ermitteln, wird diese nicht dem CMRx-Decodierer bereitgestellt.
Abrollen, abgerollt (mit Bezug auf Satellitendaten)
In bestimmten Betriebsarten sagt man, dass bestimmte Informationen durch aufeinanderfolgende CMRx-Nachrichten „abgerollt” werden. Es gibt z. B. Betriebsarten, die ein Träger/Rauschverhältnis (CNR) einbeziehen, bei denen 1, 4 oder 8 Satelliten CNR-Daten pro Nachricht aufweisen. Eine Datenepoche kann mehr als diese Anzahl von Satelliten aufweisen. Wenn dies vorkommt, verfügt der CMRx-Codierer über Mechanismen, um den ersten Satelliten und die Anzahl der Satelliten, die in der Nachricht enthalten sind, zu identifizieren. Für spätere Epochen werden aufeinanderfolgende Satellitendaten einbezogen. So sagt man, dass die Daten mit aufeinanderfolgenden CMRx-Nachrichten „abgerollt” werden.
Verstreuen
Von einigen Informationen, die in CMRx-Nachrichten gespeichert werden, sagt man, dass sie segmentiert sind, damit „die Daten über mehrere Nachrichten”, und oftmals über mehrere Datenepochen, „verstreut” werden können. Dadurch können Informationen mitgeteilt werden, die nicht so wesentlich wie Beobachtungsdaten sind. Es kann z. B. nützlich sein, Positionsinformationen einer Referenzstation bereitzustellen, um die Erkundungselemente bei der RTK-Verarbeitung von GNSS-Daten zu unterstützen. Oft müssen derartige Informationen durchgehend gesendet werden, damit die Erkundungselemente, die sich zu einem späteren Zeitpunkt nach dem Starten des Senders mit der Nachrichtenrundsendung anschließen, die notwendigen Informationen erhalten können. Ein CMRx-Codierer übernimmt die ganze Folge dieser Informationen und zerlegt sie in eine Gruppe von Segmenten. Ein Segment wird dann mit jeder Nachricht von verschiedenen Nachrichten gesendet, z. B. ein Segment pro Epoche. Wenn dies erfolgt, sagt man, dass die Informationen „verstreut” wurden. Das Verstreuen erleichtert eine gleichmäßigere Verwendung der verfügbaren Bandbreite. In fast allen Fällen ist die Segmentierung optional. Bei einer Durchführung der CMRx sind Segmentierung und Verstreuung für GNSS-Code- und Trägerbeobachtungsdaten nicht erlaubt. Das Verstreuen kann beispielsweise verwendet werden, wenn Positionsdaten, Standortinformationen und VRS/PBS-Informationen gesendet werden. Die Nachrichtengruppe, die erforderlich ist, um alle Segmente zu verstreuen, wird „Segmentfolge” genannt. Der Zeitraum, der erforderlich ist, um die Segmentfolge zu senden, wird als „Segmentfolgenzyklus” bezeichnet.
CMRx-Nachrichten
CMRx-Nachrichten haben die allgemeine in 5 gezeigte Form. Die CMRx fasst Informationen zu Blöcken zusammen. Viele dieser Blöcke sind optional und liegen nur vor, wenn dies durch Flags in höher eingestuften Blöcken angegeben wird (oder in Blöcken, die den betreffenden Blöcken vorangehen). Bestimmte Flags in den Blöcken werden verwendet, um Datenelemente zu beschreiben, die sich in diesem Datenblock befinden können oder nicht. Beispielhaft gibt es in der GPS-Beobachtungsdatennachricht ein Flag im Headerblock dieser Nachricht. Dieses Flag gibt an, ob GPS-Satellitenbeobachtungen in der Nachricht vorliegen (d. h. ob der Beobachtungsdatenblock vorliegt oder nicht). Innerhalb des Beobachtungsdatenblocks gibt es jedoch Flags, die angeben, ob sich beispielsweise Observablen der Frequenz L5 innerhalb dieses Beobachtungsdatenblocks befinden.
In 5 und anderen vorliegenden Figuren markieren eine punktierte Umrandung und schräg geschriebener Text optionale Elemente. Wie in 5 gezeigt, beschreibt das Nachrichtenformat keine Form von Nachrichtenvorspann, d. h. ein Muster, das von einem Algorithmus einer Nachrichtenrahmenerkennungsvorrichtung verwendet werden kann, um den Anfang einer Nachricht oder eine Prüfsumme oder eine zyklische Redundanzprüfung (CRC) auszumachen. Die Verwendung einer CRC ist innerhalb der CMRx optional. Somit würde mit der Nachrichten-ID unter Verwendung der optionalen Nachrichtenlänge und der optionalen Nachrichten-CRC ein „Rahmen” bereitgestellt, der von einer Rahmenerkennungsvorrichtung erkannt werden könnte.
Nachrichten-ID-Block
Den CMRx-Nachrichten-ID-Block haben alle CMRx-Nachrichten gemeinsam und er identifiziert Informationen über Nachrichtenart und Nachrichtenlänge. Bei der bevorzugten Ausführungsform besteht dieser Block aus drei Elementen: Nachrichtenlängenindikator (MLI), Nachrichtenlänge (falls durch MLI angegeben) und Nachrichtenart. Die Nachrichtenlängeninformationen sind optional, wie durch den MLI angegeben, damit die Nachrichtenlänge entfernt werden kann, wenn die Nachricht in ein anderes Protokoll eingefügt wird.
6 bildet die allgemeine Form des ID-Blocks der CMRx-Nachricht ab.
Innerhalb des CMRx-Nachrichten-ID-Blocks gibt es drei Felder:
a. Nachrichtenlängenindikator (MLI) (2 Bits)

Zwei Bits stellen Informationen über den Nachrichtenlängeninhalt innerhalb des Nachrichten-Headers bereit.

Wert	Beschreibung
0	Keine Längeninformationen in der CMRx-Nachricht.
1	Ein 8-Bit-Nachrichtenlängenwert folgt direkt auf diese beiden MLI-Bits. Diese 8 Bits geben an, wie viele 8-Bit-Bytes sich in der CMRx-Nachricht befinden, wobei die Nachrichtenlänge die Gesamtlänge der Nachricht ist, einschließlich des CMRx-Nachrichten-ID-Blocks selber.
2	Ein 12-Bit-Nachrichtenlängenwert folgt direkt auf diese beiden MLI-Bits. Diese 12 Bits geben an, wie viele 8-Bit-Bytes sich in der CMRx-Nachricht befinden.

b. Nachrichtenlänge (0, 8 oder 12 Bits, optional)
Wenn der Wert des MLI 1 ist, ist die Nachrichtenlänge 8 Bits lang und beschreibt die Gesamtzahl der 8-Bit-Bytes in der ganzen Nachricht (einschließlich des CMRx-Nachrichten-ID-Blocks selber). Wenn der Wert des MLI 2 ist, ist die Nachrichtenlänge 12 Bits lang und beschreibt die Gesamtzahl der 8-Bit-Bytes in der ganzen Nachricht. Es ist zu beachten, dass die CMRx-Nachricht linksbündig ist, insofern als alle wenigen Bits als eine Bitfolge von links nach rechts codiert sind. Dadurch kann es sein, dass das Ende des eigentlichen Nachrichteninhalts nicht auf eine Ganzbytegrenze fällt. Wenn dies vorkommt, werden Bits bis zur Ganzbytegrenze mit „0” aufgefüllt.
c. Nachrichtenart (8, 12 oder 16 Bits)
Die Nachrichtenart einer CMRx-Nachricht gibt die Art der Nachricht vor. Das Bit ganz links gibt an, ob es Erweiterungsbits gibt, die verwendet werden, um die mögliche Anzahl von Nachrichtenarten zu erhöhen (d. h. mit 7 Nutzdatenbits ergeben sich 128 mögliche Nachrichtenarten). Wenn das Bit ganz links auf 1 gesetzt ist, werden vier Bits hinzugefügt (nachstehend beschrieben). Eine derartige Erhöhung ergibt eine Summe von 10 möglichen Nachrichtenarten bzw. 1024 Nachrichtenartmöglichkeiten. Wenn das Bit ganz links der 4 neuen Bits auf Eins gesetzt ist, dann werden noch einmal 4 Bits hinzugefügt. Eine derartige Erhöhung ergibt eine Summe von 14 möglichen Nachrichtenarten (in 16 Bits paketiert) bzw. 16384 Nachrichtenartmöglichkeiten. Das Nachrichten-Handle kann beliebige gewünschte Informationen angeben, z. B. die Konstellation der Satelliten, wie etwa GPS, WAAS, EGNOS, QZSS, Compass, usw.
GPS-Beobachtungsdatennachricht
7 bildet das Format einer GPS-Beobachtungsdatennachricht ab, d. h. eine CMRx-Nachricht, die spezifisch zum Transportieren von GPS-Beobachtungsinformationen gedacht ist. Die Informationsinhaltsblöcke werden zuerst beschrieben. Der CMRx-Nachrichten-ID-Block und der GPS-Beobachtungs-Headerblock sind die einzigen erforderlichen Blöcke. Der GPS-Beobachtungs-Header definiert, ob die optionalen Blöcke sich in der Nachricht befinden oder nicht. Das Vorhandensein der optionalen Blöcke wird durch ein einziges Bit in dem Nachrichten-Header angegeben. Da jeder Block verschiedene Formate und Inhalte aufweisen kann, werden die ersten paar Bits der optionalen Blöcke verwendet, um das Format bzw. den Inhalt dieses Blocks zu definieren.
a. GPS-Beobachtungs-Headerblock
8 bildet den GPS-Beobachtungs-Headerblock ab. Die Größe des Headers variiert je nach der Größe der Epochenbasiszeit (wie durch das Flag der Epochenbasiszeitlänge, bzw. ETL, angegeben).
Die CMRx-Laufnummer (7 Bits) ist ein laufender Zähler, der bei jeder GPS-Epoche hochzählt. Somit hat jede CMRx-Nachrichtenart ihre eigne Laufnummer und ist mit einer Datenepoche verknüpft (oder einer Datengruppe für Nachrichten der nicht beobachtbaren Art). Wenn z. B. GPS-Beobachtungen für eine einzelne Epoche über mehrere Nachrichten hinweg gesendet werden, haben sie alle die gleiche Laufnummer.
Das ETL-Bit (Epochenbasiszeitlängenbit) (1 Bit) gibt die Größe der Epochenbasiszeit an.

Wert Beschreibung

0 Die Epochenbasiszeit ist 12 Bits lang.

1 Die Epochenbasiszeit ist 31 Bits lang.
Die Epochenbasiszeit ist ein Ausdruck aus ganzen Sekunden. Falls Geschwindigkeiten benötigt werden, die schneller als 1 Hz sind, gibt das Epochenzeitbruchteil-Flag weitere Informationen über den Bruchteil der Sekunde an. Somit ist die Epochenbasiszeit ein Ausdruck der ganzen Anzahl von Sekunden. Es werden keine Sekundenbruchteile für Datenraten benötigt, die an Ganzsekundengrenzen auftreten. Die Bitanzahl, die von der Epochenbasiszeit (wie sie von der Epochenbasiszeitlänge angegeben wird) verwendet wird, gibt ihre Ambiguität an. Wenn dieser Parameter 12 Bits lang ist, entspricht der gespeicherte Wert den Sekunden der Stunde und hat einen Wert zwischen 0 und 3599 Sekunden. Wenn dieser Parameter 31 Bits lang ist, stellt der gespeicherte Wert die Anzahl der Sekunden seit dem 6. Januar 1980 dar (der mit dem Beginn der GPS-Zeit zusammenfällt). In beiden Fällen wird der Wert im GPS-Zeitsystem ausgedrückt.
Der Übersichtlichkeit halber werden die Sekundenbruchteile der Epoche getrennt gespeichert. Der Bruchteil liegt in der CMRx-Nachricht nur vor, wenn das „EFT”-Bit des Headers angibt, dass der Epochensekundenbruchteilblock vorliegt. Das EFT (Epochenzeitbruchteilblockbit) (1 Bit) gibt an, ob die Epochenbasiszeit zusammen mit einer Zeitbruchteilkomponente kombiniert werden muss, um die vollständige Empfängerepochenzeit zu bestimmen.
Wenn sie gespeichert wird, wird die Epochenbasiszeit gekürzt. Sie folgt nicht der allgemeinen Rundungsregel für Fließkommadaten, weil ein Epochenzeitbruchteil dazu gedacht ist, sich in dem Epochenzeitbruchteilblock zu befinden.
Bei der Durchführung mit Bezug auf die zuvor erwähnten 12-Bit- und 32-Bit-Zeitambiguitätsformen gibt es Vorkehrungen innerhalb der Decodiererdurchführung, die eine „Seed”-Zeit ermöglichen, um die ursprüngliche Ambiguität aufzulösen. Bei der CMRx wird die Zeitambiguität bis zum Jahr 2048 aufgelöst, ohne eine Seedzeit zu benötigen. Wenn man für den Decodierer eine „Seed”-Zeit bereitstellt, die ungefähr innerhalb 33 Jahren von der ersten Nachricht liegt, so ist die Auflösung der Zeitambiguität über 2048 hinaus sichergestellt. Wenn CMRx-Betriebsarten verwendet werden, bei denen die 12-Bit-Zeit die einzige Form ist, die in den zu erstellenden Nachrichten vorliegt, dann wird der CMRx-Decodierer innerhalb von ungefähr 10 Minuten von der Zeit, die mit der ersten empfangenen Nachricht verknüpft ist, geseedet, oder wann immer ein Datenloch von mehr als 10 Minuten vorliegt.
Bevorzugt erstellt der CMRx-Codierer mindestens eine Konstellationsdatennachricht pro Datengruppe mit dem vollständigen 31-Bit-Zeit-Tag und verwendet 12-Bit-Zeit-Tags in den Nachrichten für andere Konstellationen. Dies ermöglicht eine Auflösung der Zeitambiguität innerhalb des Decodierers und ermöglicht die Verwendung einer reduzierten Bandbreite und erlaubt dabei immer noch eine korrekte Zeitverknüpfung der Nachrichten von verschiedenen Konstellationen.
Der Epochensekundenbruchteilblock wird verwendet, wenn Epochenintervalle von weniger als einer Sekunde verwendet werden. Dieses Bit hat folgende Bedeutung:

Wert Beschreibung

0 Kein Epochensekundenbruchteilblock in der Nachricht vorhanden.

1 Der Epochensekundenbruchteilblock ist in der Nachricht vorhanden.
Der Alias RefSta (5 Bits) speichert einen Wert von 0 bis 31 als Alias für die Referenzstation, um Daten von mehreren Referenzstationen zu identifizieren, die über einen einzigen logischen Kanal geliefert werden.
Das SHB-(Stationszustandsblock vorhanden) Bit (1 Bit) gibt an, ob der Stationszustandsblock in der Nachricht vorhanden ist. Dieses Bit hat folgende Bedeutung:

Wert Beschreibung

0 Kein Stationszustandsblock in der Nachricht vorhanden.

1 Der Stationszustandsblock ist in der Nachricht vorhanden.
Das Epochenfortsetzungs-Flag (ECF) wird verwendet um anzugeben, ob weitere CMRx-Beobachtungsdatennachrichten (für alle Konstellationsnachrichten) mit dem gleichen Epochenzeit-Tag folgen. Ein Wert von 1 bedeutet, dass weitere folgen, und ein Wert von 0 gibt das Ende der Epoche an. Somit wird bei der Decodiererverarbeitung das Epochenfortsetzungs-Flag verwendet, um das Ende einer Epoche zu ermitteln.
Das Epochenfortsetzungs-Flag wird hauptsächlich im Dekomprimierungsprozess verwendet, um das Ende einer Epoche zu ermitteln. Wenn das ECF-Flag gleich Null ist, wurde das Ende der Epoche empfangen. Da Nachrichten beschädigt und/oder verlorengegangen sein können, kann der CMRx-Decodierer auch über zusätzliche Mittel zum Ermitteln des Endes einer Epoche verfügen. Das Ende einer Epoche kann z. B. durch den Erhalt einer neuen Nachricht mit einer anderen Epochenzeit bestimmt werden. Alternativ kann ein Timeout-Wert verwendet werden. D. h. die Rahmenerkennungsvorrichtung oder der CMRx-Dekomprimierungs-Manager kann einen Zeitgeber umfassen, der verwendet wird, um zu ermitteln, wann das letzte Paket einer Epoche erwartet wird, um den Abschluss einer Epoche festzulegen, wenn dieses Timeout abgelaufen ist. Alle Daten, die nach dieser Festlegung empfangen werden und zu einer früheren Epoche gehören, würden dann ignoriert werden.
Bei einer Ausführungsform erlaubt es der CMRx-Decodierer, den Decodierer zu konfigurieren, um das ECF-Flag zu ignorieren. Dadurch kann die individuelle Nachrichteneinordnung innerhalb einer Epoche durch ein auswärtiges Protokoll gehandhabt werden, wie es z. B. benötigt wird, um Daten unter Verwendung bestimmter Funkprotokolle zu senden. Bei dieser Betriebsart ist der CMRx-Codierer davon abhängig, dass höher eingestufte Elemente eine Methode „Epochenabschluss erzwingen” aufrufen, um festzulegen, dass alle Nachrichten für eine Epoche eingetroffen sind (oder dass keine weiteren mehr erwartet werden, falls einige Nachrichten einer Epoche bei den Kommunikationen verlorengegangen sind/beschädigt wurden). In diesem Fall legt der CMRx-Decodierer ein Epochenende fest, wenn er einige Nachrichten für eine Epoche mit einem Zeit-Tag verarbeitet hat und eine Nachricht mit einem anderen Zeit-Tag empfängt.
Das Bit CRC vorhanden (1 Bit) gibt an, ob ein zyklischer Redundanzprüfungs(CRC)Block in der Nachricht vorhanden ist. Dieses Bit hat folgende Bedeutung:

Wert Beschreibung

0 Kein CRC-Block in der Nachricht vorhanden.

1 Der CRC-Block ist in der Nachricht vorhanden.
Der CRC-Block in CMRx-Nachrichten ist optional und wird durch Bits in der CMRx-Nachricht eingestellt. Wenn sie verwendet werden, können die Bits, die das Vorhandensein und die Art der CRC in der Nachricht definieren, über das Kommunikationsmittel beschädigt werden. Da das Verpackungsprotokoll bei der diesbezüglichen Ermittlung eventuell nicht zuverlässig ist, oder vielleicht gar nicht vorhanden ist, kann der Decodierer getäuscht werden, da die entnommenen Nachrichtenbits eventuell angeben, dass keine CRC in der Nachricht vorhanden ist. Um diese Möglichkeit zu umgehen, kann der CMRx-Decodierer konfiguriert werden, um ein CRC-Mindestniveau zu erwarten. Wenn somit eine Nachricht eintrifft, die diese Art minimaler CRC nicht aufweist, weist der Decodierer die Nachricht ab.
Das KIN-(Bewegung der RefSta)Bit (1 Bit) gibt an, ob die Beobachtungsdaten von einem statischen oder sich bewegenden CMRx-Codierer stammen. Bei einer dynamischen Betriebsart kann es sein, dass je nach Komprimierungsmodus häufigere Positionsaktualisierungen und größere Bandbreiten erforderlich sind. Somit können einige der Blöcke der CMRx-Nachricht je nach der Einstellung dieser Betriebsart ihre Größe oder Beschaffenheit ändern.

Wert Beschreibung

0 Keine statische Datenquelle (bzw. CMRx-Codierer ist statisch).

1 Datenquelle bewegt sich (bzw. CMRx-Codierer ist dynamisch).

Das ACC-(Zugriffskontrolle)Bit (1 Bit) gibt an, ob die Zugriffskontrolle für die Nachricht aktiviert wurde. Die Bedeutung dieses Bits wird wie folgt definiert:

Wert	Beschreibung
0	Zugriffskontrolle deaktiviert (d. h. die Nachricht ist für alle Empfänger offen)
1	Zugriffskontrolle aktiviert (d. h. die Nachricht richtet sich an eine beschränkte Empfängergruppe).

Die Zugriffskontrolle ist dazu gedacht, Datenempfänger daran zu hindern, Daten zu verwenden, die nicht für sie gedacht sind. Um dies durchzuführen, wird ein einzelnes Bit zum Header aller CMRx-Nachrichten hinzugefügt. Wenn es gesetzt ist, bedeutet dieses einzelne Bit, dass ein gewisses Niveau an Zugriffskontrolle aktiviert ist. Ein nicht gesetztes Bit bedeutet, dass die Nachricht für alle Empfänger offen ist.
Dieses optionale Merkmal kann je nach Bedarf verwendet werden. Wenn das Bit auf „1” gesetzt ist und das optionale Merkmal nicht durchgeführt wurde, hört der CMRx-Decodierer mit der Decodierung der Nachricht auf und meldet einen Decodierer-Fehlerzustand. Dadurch wird sichergestellt, dass falls eine Zugriffskontrolle durchgeführt wird, Decodierer, die nicht wissen, wie die Zugriffskontrolle durchgeführt wird, alle Nachrichten ignorieren, die nicht als für alle Empfänger offen angesehen werden.
Bevorzugt hat die Zugriffskontrolle, falls sie aktiviert ist, zwei (oder mehrere) Stufen-Abteilungszugriffskontrolle und Benutzerzugriffskontrolle. Abteilungszugriffskontrolle ist eine Schutzvorrichtung, um zu verhindern, dass Benutzereinrichtungen einer Gruppe (z. B. ein landwirtschaftlicher GNSS-Empfänger) CMRx-Nachrichten empfangen und verwenden, die von den Einrichtungen einer anderen Gruppe gesendet werden (z. B. ein GNSS-Empfänger für Vermessung/Bauwesen). Für die Benutzerzugriffskontrolle gehen derzeitige Überlegungen dahin, dass Kunden Passwörter (oder Codes) in ihre CMRx-Sendereinrichtungen eingeben, und die Empfängereinrichtungen dasselbe Passwort (bzw. denselben Code) benötigen, um diese Daten zu verwenden. Die Benutzerzugriffskontrolle kann Kommunikationen unter gemeinsam befindlichen Einrichtungen weiter einschränken, die ansonsten Datenfehler verursachen würden.
Das PBP-(Positionsblock vorhanden)Bit (1 Bit) gibt an, ob der Positionsblock in der Nachricht vorhanden ist. Dieses Bit hat folgende Bedeutung:

Wert Beschreibung

0 Kein Positionsblock in der Nachricht vorhanden.

1 Der Positionsblock ist in der Nachricht vorhanden.
Das SBP-(Standortinformationsblock vorhanden)Bit (1 Bit) gibt an, ob der Standortinformationsblock in der Nachricht vorhanden ist. Dieses Bit hat folgende Bedeutung:

Wert Beschreibung

0 Kein Standortinformationsblock in der Nachricht vorhanden.

1 Der Standortinformationsblock ist in der Nachricht vorhanden.
Das OBP-(Beobachtungsblock vorhanden)Bit (1 Bit) gibt an, ob der Beobachtungsblock in der Nachricht vorhanden ist. Dieses Bit hat folgende Bedeutung:

Wert Beschreibung

0 Kein GPS-Beobachtungsblock in der Nachricht vorhanden.

1 Der GPS-Beobachtungsblock ist in der Nachricht vorhanden.

Das VRS (VRS-Modus) Bit (1 Bit) gibt an, ob die Quelle der beobachtbaren Daten in der Nachricht eine virtuelle Referenzstation (VRS) ist. Wenn dieses Bit gesetzt ist, gibt es an, dass die Beobachtungsdaten zu einem VRS-Standort gehören und dass ein VRS/PBS-Block in der Nachricht vorhanden ist. Die Bedeutung dieses Bits wird wie folgt definiert:

Wert	Beschreibung
0	Die in der Nachricht vorhandenen Beobachtungsdaten gehören zu einem
	wirklichen Empfänger (d. h. kein VRS-Punkt), und in der Nachricht ist
	kein VRS/PBS-Block zu finden.
1	Die in der Nachricht vorhandenen Beobachtungsdaten gehören zu einem
	VRS-Punkt, ein VRS-Block ist in der Nachricht vorhanden, und alle
	Standortinformationen innerhalb der Nachricht gehören zu einer realen
	Basisstation.

Die PRN-(Pseudozufallsrauschen)Kapazitätsbits (3 Bits) werden verwendet, um die höchste paketierte PRN-Zahl zu beschreiben. Diese Bits haben folgende Bedeutung:

Wert	Beschreibung
0	Die PRN-Höchstzahl ist 32.
1	Die PRN-Höchstzahl ist 37.
2	Die PRN-Höchstzahl ist 42.
3	Die PRN-Höchstzahl ist 47.
4	Die PRN-Höchstzahl ist 52.
5	Die PRN-Höchstzahl ist 57.
6	Die PRN-Höchstzahl ist 62.
7	Die PRN-Höchstzahl ist 63.

Der Wert dieser Bits setzt die Größe des Blocks PRN vorhanden fest (nachstehend beschrieben). Wenn z. B. die PRN-Kapazität auf 0 gesetzt ist, besteht der Block PRN vorhanden aus 32 Bits, wobei jedes Bit das Vorhandensein (bzw. das Fehlen) von Daten für die PRN 1 bis 32 darstellt. Der CMRx-Codierer stellt die PRN-Kapazität basierend auf den Epochendaten, die ihm zum Erstellen von Nachrichten bereitgestellt werden, automatisch ein. Daher bestimmt die Anwendung, welche die CMRx-Komprimierung verwendet, ob PRN-ID von 33 bis einschließlich 63 geeignet sind und filtert die Daten entsprechend vor.
Das TBP-(Textblock vorhanden)Bit (1 Bit) gibt an, ob der Textnachrichtenblock in der Nachricht vorhanden ist. Dieses Bit hat folgende Bedeutung:

Wert Beschreibung

0 Kein Textnachrichtenblock in der Nachricht vorhanden.

1 Der Textnachrichtenblock ist in der Nachricht vorhanden.
Einige Bits sind nicht zugeteilt. Diese Ersatzbits können verwendet werden, um die Definition der GPS-Nachrichten falls notwendig zu erweitern.
Der CRC-Block liegt in der Nachricht vor, wenn das CRC-Bit des CMRx-GPS-Beobachtungs-Headerblocks das Vorhandensein einer CRC angibt. Wenn die CMRx-Nachricht eine CRC enthalten soll, wird die berechnete CRC an einer auf ein Byte ausgerichteten Grenze in die Nachricht gesetzt, wie nachstehend beschrieben wird. Der CRC-Block ist in Abschnitte unterteilt:
1) Definitionsbit (genannt Def).
Das CRC-Definitionsbit gibt die Art der CRC in der Nachricht an.

Wert Beschreibung

0 16-Bit-CRC (unter Verwendung des Polynoms 0x1021)

1 32-Bit-CRC (unter Verwendung des Polynoms 0xEDB88320)
2) Füllbits.
Die meisten CRC-Berechnungsalgorithmen arbeiten mit Byte-Sammlungen (nicht Bit-Sammlungen) und sind wirksam, weil sie auf einer Byte-Sequenz basierend rechnen. Dies gilt für den CRC-Wert von CMRx-Nachrichten. Als solche wird die CRC unter Verwendung einer Byte-Sequenz berechnet, die Bytes überspringt, die verwendet werden, um den berechneten CRC-Wert zu speichern. Dies bedeutet, dass der berechnete CRC-Wert auf eine Byte-Grenze fallen muss. Die Füllbits des CRC-Blocks werden verwendet, um die Position der berechneten CRC auszurichten, so dass sie auf eine Byte-Grenze ausgerichtet gespeichert wird.
3) Berechnete CRC
Der Wert der „berechneten CRC” enthält die CRC für die Nachricht. Dieser Wert umfasst alle Elemente der Nachricht aus dem CMRx-Nachrichten-ID-Block bis zum Ende des letzten in der CMRx-Nachricht gespeicherten Blocks. Der CMRx-Berechnungsalgorithmus geht davon aus, dass die gesamte Nachricht an einer Byte-Grenze aufhört, und daher muss der Codierungsprozess Füllbits (bzw. Nullbits) zum Ende der Nachricht hinzufügen, so dass die Nachricht zum Zwecke der CRC-Berechnung an einer Byte-Grenze aufhört.
Epochenzeitbruchteilblock
Die Epochenzeit besteht aus (1) einer Basisepochenzeit, welche die ganze Zahl der Sekunden seit dem 6. Januar 1980 ist, und aus einem optionalen Epochenzeitbruchteil. Wenn der Bruchteilabschnitt nicht in der CMRx-Nachricht enthalten ist, tastet der Empfänger Daten nur an Ganzsekundengrenzen ab. Bei Epochenausgabegeschwindigkeiten, die schneller als 1 Hz sind, oder wenn der Empfänger nicht an Ganzsekundengrenzen abtastet, wird der Epochenzeitbruchteilblock verwendet. Die 7 Bits des Epochenzeitbruchteilblocks ermöglichen Informationen von Epochengeschwindigkeiten von bis zu ungefähr 100 Hz.
Stationszustandsblock

Das SHB-Bit des CMRx-GPS-Beobachtungs-Headerblocks gibt an, ob der Stationszustandsblock in der CMRx-Nachricht vorhanden ist. Der Stationszustandsblock stellt für den Empfänger Informationen über den Zustand des Senderstandorts bereit. Diese Bits haben folgende Bedeutung:

Wert	Beschreibung
0	Überwacht und betriebsfähig/annehmbar
1	Nicht verwenden. Dieses Bit wird gesetzt, wenn der Standort
	experimentell, neu zugeschaltet aber noch in der Testphase ist, usw.
2	Unüberwachte Senderstation
3	Überwacht jedoch in nicht betriebsfähigem Zustand, z. B. Verletzung
	einer Trägerphasenpositionstoleranz).
4–50	Reserviert für zukünftige nicht betriebsfähige Zustände
51–63	Reserviert für zukünftige überwachte/betriebsfähige Zustände.

Positionsblock
Das Bit Positionsblock vorhanden (PBP) des CMRx-GPS-Beobachtungs-Headerblocks gibt an, ob ein Positionsblock in der Nachricht vorhanden ist. Wenn das PBP auf 1 gesetzt ist, ist der Positionsblock vorhanden. Der Positionsblock enthält nur die Positionsinformationen für den Sender (oder Verfasser) der CMRx-GPS-Beobachtungsnachricht. Dieser Block stellt die Koordinaten des Phasenzentrums bereit (aktueller ITRF, manchmal auch ITRF jeweils gültige geodätische Koordinaten genannt), in die alle Observablen übersetzt werden (d. h. das absolute Phasenzentrum der Nullantenne). Der Positionsblock einer Nachricht kann den gesamten Positionsinformationsinhalt enthalten, oder wenn die Bandbreitenverwendung reduziert wird, kann er einen Teil der Positionsinformationen enthalten. Diese Positionsinformationsteile werden Segmente genannt. Auf diese Art und Weise kann der Positionsinformationsinhalt über mehrere Nachrichten verstreut werden, indem ein Segment pro Nachricht gesendet wird. Dieser Lösungsansatz wird von anderen Blöcken der CMRx-Nachrichten verwendet und benutzt die Bandbreite regelmäßiger von einer Epoche zur anderen. Dieser Segmentierungslösungsansatz wird weiter unten beschrieben.
Innerhalb des Positionsblocks befinden sich geografische Breiten-, Längen- und Höhenkoordinaten, die absprachegemäß bei einer Ausführungsform in dem Grundkoordinatenrahmen der GPS-Konstellation ausgedrückt werden, und ein Positionsalter (AOP). Das AOP dient zwei Hauptzwecken. Erstens weiß ein Empfänger einer CMRx-Nachricht, dass neue Koordinaten eintreffen, wenn sich das AOP für einen bestimmten Referenzstationsalias geändert hat. Zweitens können, wenn segmentierte Daten über mehrere Epochen übertragen werden, Nachrichten während der Kommunikation verloren gehen oder beschädigt werden. Wenn dies vorkommt, sieht der Empfänger ein Loch oder Löcher in den segmentierten Informationen. Segmentierte Daten werden jedoch meistens durchgehend von einer CMRx-Quelle in einem sich wiederholenden Zyklus ausgegeben. Wenn das oder die fehlenden Segmente wieder eintreffen, wird das Loch bzw. werden die Löcher in dem Segment aufgefüllt. Sobald eine ganze Segmentfolge eintrifft, kann der Empfänger dann den Inhalt dieser Folge entpaketieren.

Soweit vorhanden, besteht der Positionsblock aus zwei Hauptteilen: (1) Definitionsbits; und (2) Positionsblockkörperbits, wie in 9 gezeigt. Die Größe des Körpers ist nicht festgelegt. Die Definitionsbits beschreiben sowohl den Inhalt als auch die Größe des Positionsblockkörpers. Die nachstehende Liste beschreibt das Formt dieser Blöcke, während die nachfolgenden Unterabschnitte das jeweilige Format ausführlich beschreiben. Positionsblockdefinition

0	Der Positionsblockkörper enthält die gesamte geografische Breite,
	Länge, Höhe und das Positionsalter (d. h. 98 Bits für Breite, Länge und
	Höhe und 4 Bits für Positionsalter).
1	Breite, Länge und Höhe über 2 Epochen verstreut
2	Breite, Länge und Höhe über 4 Epochen verstreut
3	Breite, Länge und Höhe über 8 Epochen verstreut
4	Breite, Länge und Höhe über 16 Epochen verstreut
5	Breite, Länge und Höhe über 32 Epochen verstreut
6	Breite, Länge und Höhe über 64 Epochen verstreut
7	Breite, Länge und Höhe über 128 Epochen verstreut

In der obigen Liste ist das AOP in jeder Nachricht enthalten. Die Definitionen 1 bis 7 übergreifen mehrere Epochen. Die Segmentzahl jedes übertragenen Teils wird unter Verwendung der geeigneten Bits der CMRx-Sequenznummer identifiziert, die im Headerblock der Nachricht zu finden ist. Wenn z. B. der Wert 2 vorgegeben wird, werden die Positionsinformationen in 4 Nachrichten vollständig übertragen. In diesem Fall beschreiben die 2 niedrigstwertigen Bits der CMRx-Sequenznummer, welches Segment der Positionsinformationen in dieser Epoche eingefügt wird.
Es besteht ein Zusammenhang zwischen Segmenten, Segment-IDs, CMRx-Sequenznummern und Nachrichtenarten. Eine Datenepoche kann Daten von mehreren Konstellationen enthalten: z. B. kann eine Datenepoche Informationen von GPS, GLONASS, usw. enthalten. Eine CMRx-Nachricht enthält jedoch Daten von nur einer Konstellation. Die CMRx-Nachrichtensequenznummern zählen auf einer Basis pro Nachrichtenart hoch. Für Beobachtungsdaten erhöht sich die CMRx-Sequenznummer nur mit jeder verarbeiteten Epoche. Somit gibt es eine CMRx-Sequenznummer für jede Konstellation, und die Sequenznummer erhöht sich nach dem Abschluss der Verarbeitung jeder Epoche.
Daten für eine einzige Konstellation können in einer oder mehreren Nachrichten der gleichen Art gesendet werden. Wenn dies der Fall ist, dann bleibt die CMRx-Sequenznummer mit jeder Nachricht für diese Konstellation für diese Epoche konstant. Wenn z. B. 9 GPS-Satelliten verfolgt werden und beschlossen wird, 3 pro CMRx-Nachricht auszusenden, dann enthält die Epoche mindestens 3 GPS-Satellitenbeobachtungs-Datennachrichten, die jede die gleiche Sequenznummer gemeinsam haben.
Positionsalter
Das Positionsalter (AOP) wird verwendet, damit ein Empfänger wissen kann, wann sich die Position innerhalb des Positionsblocks geändert hat. Im Wesentlichen verfolgt ein Empfänger den Zeitpunkt nach, an dem eine neue Koordinatengruppe für einen RefSta-Alias eingetroffen ist, und kann daher ermitteln, wann sich die Koordinaten geändert haben. Natürlich werden sie als „geändert” angesehen, wenn der Empfänger nicht über historische Positionsinformationen verfügt.
Das AOP hat zwei Hauptfunktionen: (1) Es hilft dabei zu ermitteln, dass die Positionsinformationen sich geändert haben (z. B. wenn der derzeitige AOP-Wert kleiner ist als der vorherige Wert); und (2) es trägt zu schnelleren Startzeiten bei, wenn ein Empfänger vor kurzem Daten von einem CMRx-Sender empfangen hat.
Im letzteren Fall führt ein typischer Empfänger zwischen den Betriebssitzungen einen Koordinatenalmanach (d. h. eine Tabelle, die oft in einem nichtflüchtigen Speicher oder einer Datei gespeichert ist, die den RefSta-Alias, seine Koordinaten, einen mit dem AOP verknüpften Zeitstempel und andere Informationen enthält). Zu Beginn einer neuen Sitzung und nach Erhalt der ersten Datenepoche, selbst wenn die Positionsdaten verstreut werden, kann der Empfänger bestimmen, ob die Koordinaten für den Sender bereits im Almanach gespeichert sind, und ob sie sich seit der vorherigen Sitzung geändert haben oder nicht. Das Positionsalter wird genau zu diesem Zweck verwendet. Wenn der Empfänger keinen vorhandenen Almanacheintrag für den RefSta-Alias hat oder die Zeitinformationen im Almanach für einen RefSta-Alias nicht zum AOP passen, das in der CMRx-Nachricht enthalten ist, dann muss der Empfänger offensichtlich davon ausgehen, dass er die Position nicht kennt; er muss dann warten, bis alle Segmente eingetroffen sind, bevor er die Position als bekannt festlegen kann (es sei denn, es wurden in den Decodierer des Empfängers Koordinaten durch eine andere Quelle „geseedet”). Das AOP stellt auch in diesem Fall nützliche Informationen bereit.

Das 4-Bit-AOP wird folgendermaßen ausgelegt:

AOP-Wert [Basis 2] Bedeutung
0000	Position hat sich innerhalb von weniger als 90 Sekunden geändert
0001	90 Sek.	<= Positionsänderungszeit < 3 Min.
0010	3 Min.	<= Positionsänderungszeit < 6 Min.
0011	6 Min.	<= Positionsänderungszeit < 12 Min.
0100	12 Min.	<= Positionsänderungszeit < 24 Min.
0101	24 Min.	<= Positionsänderungszeit < 48 Min.
0110	48 Min.	<= Positionsänderungszeit < 1,6 Std.
0111	1,6 Std.	<= Positionsänderungszeit < 3,2 Std.
1000	3,2 Std.	<= Positionsänderungszeit < 6,4 Std.
1001	6,4 Std.	<= Positionsänderungszeit < 12,8 Std.
1010	12,8 Std.	<= Positionsänderungszeit < 25,6 Std.
1011	25,6 Std.	<= Positionsänderungszeit < 2,133 Tage
1100	2,133	Tage <= Positionsänderungszeit < 4,266 Tage
1101	4,266	Tage <= Positionsänderungszeit < 8,533 Tage
1110	8,533	Tage <= Positionsänderungszeit
1111	Mehrdeutiges AOP: Position nicht verwenden.

Es ist zu beachten, dass alle anderen Einträge als der erste und der letzte Wiederholungen von angrenzenden Einträgen sind. Mit diesen Wiederholungen kann das AOP verwendet werden, um sowohl zu identifizieren, wenn vollständige Segmentfolgen eingetroffen sind, als auch wenn die Empfänger historische Almanache einsetzen, d. h. dass die Empfängeranwendungen Almanache einsetzen können, die einen Verlauf der Stationsposition, der Zeit-Tags und der empfangenen AOP-Werte speichern, die verwendet werden können, um die Startzeiten des Empfängers zu beschleunigen, wenn ein Empfänger vorher von einem Sender Daten empfangen hat. Mit anderen Worten sollte die Almanachverwendung des AOP nur erfolgen, wenn 0001 <= AOP <= 1110 und alle Tabelleneinträge verwendet werden, um zur Ankunftsbestimmung der vollständigen Segmentfolge beizutragen. Mit den AOP-Werten 0000 und 1111 ist eine Spezialhandhabung verbunden, wie noch beschrieben wird.
In der obigen Tabelle wird der Wert 0000 jedes Mal verwendet, wenn die Positionsinformationen geändert werden. Wenn die Position zweimal (oder öfter) innerhalb eines Zeitraums von 90 Sekunden geändert wird, wird das AOP auf den Wert 1111 gesetzt; einen Wert, der bedeutet, dass das AOP mehrdeutig ist und keine Positionsinformationen verwendet werden sollten. D. h. dass immer wenn der CMRx-Codierer Positionsänderungen innerhalb eines Zeitraums von 90 Sekunden ermittelt (was selten vorkommt), er das AOP auf den Wert 1111 setzt und diesen Wert 90 Sekunden lang behält, wonach das AOP auf 0001 gesetzt wird, wodurch man der obigen Tabelle nach dem Ambiguitätszeitraum von 90 Sekunden folgt.
Von einem Kaltstart aus (d. h. wenn der Sender seine eigene Position noch nicht kennt), zählt die ursprüngliche Einstellung der Position als eine Änderung. Z. B. nach einer Firmware-Rückstellung wird die Position des CMRx-Codierers auf unbekannt geändert. Sobald die Bedienungsperson eine Koordinatengruppe eingibt, zählt dies als erste Änderung (d. h. eine Änderung von unbekannt auf einen einzelnen Wert). Wenn die Bedienungsperson dann die Position auf einen anderen Wert ändert, wird dies als eine zweite Änderung angesehen.
Der CMRx-Codierer erlaubt es seinem übertragenen AOP, sich mitten in einem Übertragungsfolgezyklus zu ändern, vorausgesetzt, das AOP geht nicht über Null (oder auf einen kleineren Wert: diese werden später besprochen). Ein Übertragungsfolgezyklus ist dazu gedacht, alle Segmente zu bedeuten, die für eine vollständige Segmentfolge erforderlich sind, und zwar eine, die mit dem ersten Segment anfängt und mit dem letzten Segment aufhört. Dies bedeutet, dass das AOP innerhalb eines Übertragungsfolgezyklus von dem Wert 0000 auf 0001 übergehen kann, oder dass ein beliebiger Übergang von einem AOP-Wert ungleich Null auf seinen nächst höheren AOP-Wert erlaubt ist. Innerhalb eines Übertragungsfolgezyklus ist es nicht erlaubt, von einem Wert ungleich Null (außer 1111) auf 0000 überzugehen (oder etwa von 0010 auf 0001): d. h. ein solcher Fall bedeutet, dass die Position sich kürzlich geändert hat. Wenn eine neue Position in den Codierer eintritt, ist die derzeitige Position nicht mehr gültig, und somit wäre eine restliche Übertragungsfolge ungültig. Daher kann der Codierer einen unvollständigen Übertragungsfolgezyklus „unterbrechen” und die Sequenznummer wieder mit Null beginnen. Mit anderen Worten löscht der Decodierer, jedes Mal wenn er ermittelt, dass das AOP zurück gegangen ist, alle Informationen, die ihm über empfangene Positionsdaten bekannt sind.
Der CMRx-Decodierer selber behält keine Almanachinformationen in der Bibliothek. Vielmehr gibt der Decodierer andauernd Segmentinformationen und/oder eingetroffene Positionsdaten an eine Anwendung unter Verwendung des CMRx-Decodierers weiter. Somit setzt die Anwendung unter Verwendung des CMRx-Decodierers die Positionsalmanachinformationen ein, um die Almanachfunktionen des AOP auszunutzen. Mit den Informationen über Segmente, die ihr vom CMRx-Decodierer gegeben werden, kann die Anwendung dann die geeigneten Informationen in ihrem Almanach nachsehen und dann diese Informationen sowohl für ihre Datenverarbeitungselemente als auch die Decodierer-Bibliothek bereitstellen (d. h. den Decodierungsprozess mit den Koordinaten des Senders „seeden”). Ohne einen derartigen Einsatz eines Almanachs durch die Anwendung und ihren Schnittstellenaustausch mit dem CMRx-Decodierer geht der CMRx-Decodierer zu Beginn davon aus, dass keine historischen Positionsinformationen bekannt sind und verlangt eine vollständige Segmentankunft, bevor er die Position als im Decodierer bekannt festlegt.
Eine Senderanwendung, die sich nicht um das Speichern von Positionsdaten mit Zeitstempeln kümmern will, die an den CMRx-Codierer für die AOP-Berechnung weitergegeben würden, ruft den Codierer mit einem speziellen Indikator auf, der zu einem anfänglichen AOP-Wert von Null führt.
Sobald der Codierer gestartet wird, behält er die Positionsdaten, die ihm während einer einzelnen Instanziierung über seine diversen Methodenaufrufe gegeben werden. Werden einer einzigen Objektinstanziierung des Codierers über ihre Methodenaufrufe wiederholt dieselben Koordinaten bereitgestellt, so führt dies nicht zu einer Änderung ihrer Referenzzeit, die verwendet wird, um das AOP zu erzeugen. Ferner kennt sie, sobald die Position im Codierer eingestellt ist, den Zeitpunkt, zu dem diese Position eingestellt wurde, und kann anschließend das AOP für jedes Segment berechnen. Positionsänderungen von weniger als einem Millimeter werden ignoriert.
Verarbeitung des Positionsalters
Als nächstes wird erklärt, wie ein Empfänger die Ankunft von Segmenten handhabt und ihre AOPs behandelt, angesichts der Tatsache, dass Kommunikationsausfälle möglich sind. Wenn die Daten nicht segmentiert sind (d. h. der gesamte Inhalt der Positionsinformationen wird in einer Epoche gesendet), dann ist offensichtlich keine spezielle Verarbeitung erforderlich, um zu bestimmen, ob eine vollständige Segmentfolge empfangen wurde. Wenn mehr als ein Segment vorliegt, sieht sich der Decodierer das AOP und die Segmentankünfte an, um zu bestimmen, wann er eine vollständige Segmentfolge empfangen hat, und entpaketiert dann eine Position aus dieser Folge. Zudem kann eine Anwendung, die einen CMRx-Decodierer verwendet, eine Almanachfunktion einsetzen, damit sie die Position des Senders beim Erhalt nur eines einzelnen Segments kennen kann. Nehmen wir z. B. auf einer Baustelle an, dass eine Basisstation mehrere Tage am selben Ort bleibt. Am ersten Tag muss der CMRx-Decodierer im Empfänger des Erkundungselements des Vermessungstechnikers eine vollständige Segmentfolge empfangen und die Position des Senders aus dieser Folge entnehmen. Am Ende des Tages schaltet der Vermessungstechniker seine Einheit aus. Wenn dieser Empfänger bzw. diese Anwendung einen Almanach eingesetzt hat, der die Positionsdaten (und andere Informationen) speichert, dann weiß die Anwendung, wenn dieser Vermessungstechniker die Einheit am nächsten Tag anschaltet, nach dem Empfang des ersten Segments, ob sich die Position des Senders geändert hat. Somit braucht sie nicht auf eine vollständige Segmentfolge zu warten, um mit der Vermessung zu beginnen.
Bestimmen der Ankunft vollständiger Segmentfolgen
Als nächstes wird besprochen, wie Segmentankünfte angesichts diverser Kommunikationsumgebungen, die Nachrichten beschädigen können, und unter Verwendung der AOP-Werte in diesen eingetroffenen Segmenten zu behandeln sind, um zu bestimmen, dass eine vollständige Segmentfolge empfangen wurde und eine Position aus dieser Folge entpaketiert werden kann. Im Allgemeinen erfolgt das Verstreuen, indem ein Informationsblock in leicht zu identifizierende Segmente aufgelöst wird und dann ein Segment pro Nachricht gesendet wird. Da diese Segmente identifizierbar sind, kann man den ursprünglichen Block rekonstruieren. Man nehme beispielsweise einen in vier Segmente aufgelösten ursprünglichen Informationsblock. Die gemeinsame Größe der Segmente ist größer als der ursprüngliche Block, einfach aufgrund des Overheads, wie etwa das AOP und die Positionsblock-Definitionsbits, die mit jedem Segment gesendet werden. Diese Segmente werden dann in aufeinanderfolgenden CMRx- Epochennachrichten gesendet. Der Decodierer kann dann die eingetroffenen Segmente sammeln und den ursprünglichen Block wieder zusammenfügen. Die Verarbeitung ist einfach, wenn keine möglichen Nachrichtenverluste über das Kommunikationsmittel vorliegen. Mögliche Paketverluste zusammen mit dem Risiko, dass sich die Koordinaten an der Referenzstation ändern können, machen dies jedoch schwieriger.
Zur Erläuterung wird das Konzept von Segment-Mailboxen verwendet, wie sie vom Decodierer verwendet werden. Der Decodierer erstellt eine Mailbox, die Daten für jedes erwartete Segment speichert (d. h. er weiß, wie viele Mailboxen basierend auf den Positionsblock-Definitionsbits benötigt werden). In jeder Mailbox speichert er mindestens die empfangenen Segmentinhaltsbits, die Länge der Bits, den mit dem Segment verknüpften AOP-Wert und ein Zeit-Tag, das mit diesem Segment verknüpft ist. Somit führt jede Mailbox in dem CMRx-Decodierer die folgenden Informationen:

SegID. Das Modulo von FullSeqNum, der Anzahl der erwarteten Segmente. D. h. dass die in einer CMRx-Nachricht mit jedem Segment enthaltenen Informationen einen Segmentierungsmodus darstellen. Genau dieser Modus gibt die Anzahl der zu erwartenden Segmente an.
SegBitContent. Eine Kopie des Informationsinhalts in dem Segment: d. h. ein Teil des Gesamtinhalts.
SegArrTime. Die vollständige GPS-Zeit, die aus dem Headerblock der CMRx-Nachricht entnommen wurde. Wenn ein Segment eintrifft, selbst wenn der Informationsinhalt für dieses Segment der gleiche ist wie als dieses Segment das letzte Mal empfangen wurde, wird die Segmentankunftszeit aktualisiert.
AgeOfPos. Der AOP-Wert, der mit den Segmentdaten eingetroffen ist.

Verwaltung der Segment-Mailboxen
Wenn ein Segment eintrifft, wird die mit diesem Segment verknüpfte Mailbox unter Verwendung der geeigneten Bits der CMRx-Sequenznummer identifiziert. Bei dem nachstehenden Pseudocode bezieht sich die Mailbox auf die einzelne Mailbox, die durch die CMRx-Sequenznummer identifiziert wird. Die grundlegende Mailboxverarbeitung ist folgende:

A) Wenn die Länge des eingetroffenen Segments anders als die in der Mailbox gespeicherte Segmentlänge ist ODER das Positionsalter des derzeitigen Segments geringer ist als das des zuvor empfangenen Segments ODER das AOP = 1111 [Basis 2]. a.1 Die gesamte Mailboxfolge wird auf einen anfänglichen Zustand geleert. a.2 Die Segmentinhaltsbits werden in die Mailbox kopiert. a.3 Die SegID wird in der Mailbox gespeichert. a.4 Die Segmentankunftszeit (in der Mailbox) wird auf die aktuelle Zeit gesetzt. a.5 Das mit dem eingetroffenen Segment verknüpfte AOP (in der Mailbox) wird gespeichert.
B) Andernfalls, wenn die Inhaltbits des eingetroffenen Segments anders als die in der Mailbox sind ODER das konfigurierte Höchstalter der Mailbox überschritten ist (siehe Anmerkung weiter unten in diesem Abschnitt). b.1 Die Segmentinhaltsbits werden in die Mailbox kopiert. b.2 Die SegID wird in der Mailbox gespeichert. b.3 Die Segmentankunftszeit (in der Mailbox) wird auf die aktuelle Zeit gesetzt. b.4 Das mit dem eingetroffenen Segment verknüpfte AOP (in der Mailbox) wird gespeichert.
C) Andernfalls, wenn die Inhaltsbits des eingetroffenen Segments genau die in der Mailbox gespeicherten Bits sind. c.1 Die SegID wird in der Mailbox gespeichert. c.2 Die Segmentankunftszeit (in der Mailbox) wird auf die aktuelle Zeit gesetzt. c.3 Das mit dem eingetroffenen Segment verknüpfte AOP (in der Mailbox) wird gespeichert.

Die Mailboxen werden dann unter Verwendung eines Regelsatzes verarbeitet. Die Regeln stellen sicher, dass die segmentierten Daten wieder richtig von dem CMRx-Decodierer zusammengefügt werden.
Regel Nr. 1. Alle mit den erwarteten Segmenten verknüpften Mailboxen müssen Daten enthalten. Ansonsten besteht keine Möglichkeit, dass die Mailboxen eine vollständige Segmentfolge enthalten. Diese Regel ersetzt alle folgenden Regeln insofern als, wenn alle mit den erwarteten Segmenten verknüpften Mailboxen keine Daten enthalten, es dann nicht möglich ist, über eine vollständige Segmentfolge zu verfügen.
Regel Nr. 2. Wenn die Position sich zweimal (oder öfter) innerhalb eines Zeitraums von 90 Sekunden ändert, sendet der CMRx-Codierer nach der Änderung 90 Sekunden lang ein AOP = 1111. Nach dem Zeitraum von 90 Sekunden ändert sich das AOP auf 0001. Es ist zu beachten, dass von einem Kaltstart aus, wenn der Sender seine eigene Position noch nicht kennt, die anfängliche Einstellung der Position als eine Änderung zählt. Sobald die Bedienungsperson einen Koordinatensatz eingibt, zählt dies als die erste Änderung. Wenn die Bedienungsperson dann die Position auf einen anderen Wert ändert, wird dies als eine zweite Änderung angesehen.
Regel Nr. 3. Jedes Mal wenn der derzeit empfangene AOP-Wert geringer ist als der zuvor empfangene AOP-Wert oder wenn ein AOP = 1111 empfangen wird, leert der Empfänger alle Mailboxen, indem er sie auf ihren anfänglichen Zustand zurücksetzt. Der Decodierer geht dann davon aus, dass er keine Koordinaten empfangen hat. Wenn der Decodierer konfiguriert ist, um die Koordinaten in einer CMRx-Nachricht zu CMRx-Entpaketierungszwecken zu verwenden (und nicht über andere Quellen erhaltene Koordinaten), geht er davon aus, dass er nichts über die empfangenen Koordinaten weiß. Dies kann dazu führen, dass er, bis er eine neue vollständige Segmentfolge empfangen hat, unfähig ist, die Satellitenobservablen in CMRx-Beobachtungsnachrichten zu decodieren.
Definitionsgemäß bezieht sich der Begriff „ältestes Segment” auf das Segment, das in einer Mailbox mit der ältesten Ankunftszeit gespeichert ist. Der Begriff „jüngstes Segment” bezieht sich auf das Segment, das in einer Mailbox mit der Ankunftszeit gespeichert ist, die der aktuellen Zeit am nächsten ist. Der Begriff „AOP-Deckungszeit” bezieht sich auf den maximalen Zeitraum für einen bestimmten AOP-Wert, von dem man weiß, dass sich die Position nicht geändert hat. Mit einem AOP von 0000 erhält man z. B. eine AOP-Deckungszeit von 90 Sekunden.
Regel Nr. 4. Sobald alle Mailboxen Daten enthalten, wird eine vollständige Segmentfolge festgelegt, wenn die Delta-Zeit zwischen dem ältesten und jüngsten Segment geringer ist als die AOP-Deckungszeit des größten in der Mailbox befindlichen AOP-Werts. Ansonsten, wenn die Folge der eingetroffenen Mailboxen zwischen dem jüngsten und ältesten Segment eine Delta-Zeit aufweisen, die gleich oder größer ist als die AOP-Deckungszeit des größten AOP-Werts, legt der Decodierer dann fest, dass die Position nicht bekannt ist.
Regel Nr. 5. Wenn die Mailboxfolge AOP-Werte gleich 0000 und ungleich 0000 enthält, muss die Delta-Zeit zwischen dem jüngsten Segment mit einem AOP von 0000 geringer als die Hälfte der AOP-Deckungszeit der jüngsten Mailbox mit dem größten AOP ungleich 0000 sein, um die Ankunft einer vollständigen Segmentfolge festzulegen.
AOP verwenden, um zu schnellen Starts beizutragen
Das AOP und die Segmentierung ermöglichen es einem Empfänger, Informationen zurückzurufen, die zuvor in einem nichtflüchtigen Speicher gespeichert wurden; wodurch ein schnellerer Start der Datenverarbeitungs-Engines und der CMRx-Decodierungsprozesse ermöglicht wird. Jedes Mal wenn ein Empfänger eine vollständige Segmentfolge empfängt und ihren Erhalt festlegt, werden unter Verwendung des CMRx-Decodierers Informationen an die Anwendung weitergegeben. Diese Anwendung kann genug Informationen speichern, damit an einem späteren Datum oder nach einer Verbindungsunterbrechung/einem Neustart der Empfang eines einzigen AOP genügend Informationen darstellt, um zu wissen, ob diese zuvor gespeicherten Informationen die Informationen, die benötigt werden, um die Verarbeitung zu starten, enthalten oder nicht.
Algorithmus zum Paketieren von Positionskomponenten
Viele der nachstehenden Abschnitte enthalten Algorithmen in einem Format wie C/C++ Code. Diese Algorithmen sind dazu gedacht, als Durchführungsbeispiele des Codierungs-/Decodierungsprozesses zu dienen.
Für die Koordinateninformationen (d. h. die geografische Breite, Länge und Höhe) werden die Koordinaten auf gleichwertige ganzzahlige Werte skaliert. Die Breite wird in 36 Bits gespeichert, unter Verwendung einer Präzision von ungefähr 0,3 mm (d. h. einer Genauigkeit von ungefähr 0,15 mm). Die Länge wird in 37 Bits gespeichert, unter Verwendung einer Präzision von ungefähr 0,3 mm (d. h. einer Genauigkeit von ungefähr 0,15 mm). Die ellipsoidische Höhe wird in 25 Bits gespeichert, unter Verwendung einer Präzision von ungefähr 0,3 mm (d. h. einer Genauigkeit von ungefähr 0,15 mm).
Schritt 1: Datenbereiche bestätigen und bei Verletzung Fehler erzeugen.

if (fabs (dLat) > 90.0) return (CMRxV1_ERR_POSLAT); if ((dHt < –500.0)||(dHt > 9500.0)) return (CMRxV1_ERR_POSHT);

Schritt 2: Positionskomponenten in Bitdarstellungen konvertieren.

dLat += 90.0; while (dLon < 0.0) dLon += 360.0; while (dLon < 0.0) dLon += 360.0; dHt += 500.0; u64Lat = RoundDoubleToInt64 (dLat·2^36/180.0); u64Lon = RoundDoubleToInt64 (dLon·2^37/360.0); u64Ht = RoundDoubleToInt64 (dHt·2^25/10000.0);

Nach Abschluss dieses Prozesses können die 36 niedrigstwertigen Bits von u64Lat, die 37 niedrigstwertigen Bits von u64Lon und die 25 niedrigstwertigen Bits von u64Ht paketiert werden. Es ist zu beachten, dass die für Breite, Länge und Höhe paketierten Werte Zahlen ohne Vorzeichen sind (d. h. dass die paketierten Werte manipuliert werden, um sie im positiven Bereich zu halten).
PackCMRxBits (cpPosBitBuf, &iCurrPosBit, 36, I64Lat);
PackCMRxBits (cpPosBitBuf, &iCurrPosBit, 37, I64Lon);
PackCMRxBits (cpPosBitBuf, &iCurrPosBit, 25, I64Ht);
Unsegmentiertes Positionskonstrukt
Das in 10 gezeigte unsegmentierte Positionskonstrukt wird verwendet, um die Komponenten der Position zu beschreiben, die im Speicher zusammenhängend gespeichert werden. Ein derartiges Konstrukt kann in dem Codierungsprozess verwendet werden, um die Bits zu enthalten, die in Segmente gesetzt werden. Während des Decodierens kann es verwendet werden, um Segmentdaten sofort zu speichern, wenn sie eintreffen. Für Positionsdaten enthält dieses Konstrukt die 36 Bits der Breite, dann die 37 Bits der Länge und dann die 25 Bits der ellipsoidischen Höhe. Die Werte für die geografische Breite, Länge und Höhe werden zuerst in eine ganzzahlige Darstellung konvertiert, wie oben beschrieben.
Vollständige Position pro Nachricht
Die in 11 gezeigte Option der vollständigen Position wird verwendet, wenn die Positionsblock-Definitionsbits den Wert 0 enthalten. In diesem Modus werden 105 Bits im Positionsblock gespeichert. Von diesen 105 Bits sind 3 Bits für die Positionsblock-Beschreibungsbits (alle drei Bits sind auf Null gesetzt), 4 Bits speichern das Positionsalter und 98 Bits werden verwendet, um die Position (Breite, Länge und ellipsoidische Höhe) zu speichern. Die Werte für die geografische Breite, Länge und Höhe (jeweils 36 Bits, 37 Bits und 25 Bits), die in ihre ganzzahligen Darstellungen konvertiert wurden.
Position über 2 Epochen verstreut
Wenn die Positionsblock-Definitionsbits den Dezimalgegenwert des Werts 1 enthalten, wird der Inhalt der Positionsinformationen segmentiert und über 2 Epochen gesendet, während das Positionsalter mit jedem Segment über 2 Epochen gesendet wird. Dies ist in 12 abgebildet.
Wie oben erwähnt, werden Datenabschnitte mit jeder CMRx-Nachricht gesendet, und diese Abschnitte werden durch Segmentnummern identifiziert. Segmentnummern entsprechen den geeigneten Bits der CMRx-Sequenznummer. Der Bitwert „X” bedeutet „Beliebig”. Die Segmentdaten enthalten die Werte für die geografische Breite, Länge und Höhe (jeweils 36 Bits, 37 Bits und 25 Bits). Der Lösungsansatz des Verstreuens der Positionsdaten über mehr als zwei Epochen entspricht dem, der in 11 gezeigt wird.
Standortinformationsblock
Das Standortinformationsblock-Präsenzbit (SBP) des CMRx-GPS-Beobachtungs-Headerblocks (siehe 8) gibt an, ob der Standortinformationsblock in der Nachricht vorhanden ist. Wenn dieses Bit auf 1 gesetzt ist, ist der Standortinformationsblock in der Nachricht vorhanden. Der Standortinformationsblock enthält den Standortnamen aus 16 Zeichen, den Standortcode aus 16 Zeichen, 8 Bits für die Punktquelle, eine Angabe der Punktqualität (codiert, 0 = normal und 1 = überprüfen), die Antennenhöhe (0,0 bis 4,0955 Meter, die Antennenart (codiert: 0 bis 1023), die Methode zur Messung der Antennenhöhe (codiert: 0 bis 7) und die GPS-Empfängerart (codiert: 0 bis 511).

Soweit vorhanden, besteht der Standortinformationsblock (siehe 13) aus zwei Hauptteilen: (1) Standortinformationsdefinitionsbits und (2) Standortinformationskörperbits: Die Standortinformationsdefinitionsbits werden in der nachstehenden Liste gezeigt: Standortinformationsdefinition

0	Der gesamte Standortinformationskörper wird in einer Epoche (d. h. 300 Bits)
	und Standortaltersinformationen (4 Bits) gesendet.
1	Standortinformationen werden über 2 Epochen verstreut
2	Standortinformationen werden über 4 Epochen verstreut
3	Standortinformationen werden über 8 Epochen verstreut
4	Standortinformationen werden über 16 Epochen verstreut
5	Standortinformationen werden über 32 Epochen verstreut
6	Standortinformationen werden über 64 Epochen verstreut
7	Standortinformationen werden über 128 Epochen verstreut

Bevor jedes der einzelnen Formate beschrieben wird, werden gemeinsame Elemente des Standortinformationskörpers beschrieben. Es handelt sich um segmentierte Informationen, Standortaltersinformationen und den Algorithmus zum Konvertieren der Standortinformationskomponenten in eine ganzzahlige Darstellung. Wie oben beschrieben übergreifen die Formate 1 bis 7 mehrere Epochen. Mit jeder CMRx-Beobachtungsdatennachricht wird ein Abschnitt des gesamten Informationsinhalts unter Verwendung der oben beschriebenen Segmentierungs- und Verstreuungstechniken übertragen.
Der Standortinformationsblock stellt die folgenden Informationen bereit:

1. Den Standortnamen aus 16 Zeichen
2. Den Standortcode aus 16 Zeichen
3. Punktquelle
4. Punktqualität
5. Antennenhöhe
6. Antennenart
7. Methode zum Messen der Antennenhöhe
8. GNSS-Empfängerart

Unsegmentiertes Standortinformationskonstrukt
14 bildet das Format des unsegmentierten Standortinformationskonstrukts ab. Das unsegmentierte Standortinformationskonstrukt wird verwendet, um die Komponenten der Standortinformationen zu beschreiben, die im Speicher zusammenhängend gespeichert sind. Es kann in dem Codierungsprozess verwendet werden, um die Bits zu enthalten, die in Segmente gesetzt werden. Während des Decodierens kann es verwendet werden, um Segmentdaten sofort zu speichern, wenn sie eintreffen. Nach Abschluss der Segmentankunft ist das unsegmentierte Standortinformationskonstrukt der Block, aus dem Standortinformationskomponenten des Standortinformationsblocks entnommen werden.
Standortinformationen pro Nachricht
15 bildet die Option der Standortinformationen ab, die verwendet wird, wenn die Definitionsbits des Standortinformationsblocks den Wert 0 enthalten. Bei diesem Modus besteht der Standortinformationsblock aus 307 Bits. Von diesen 307 Bits sind 3 Bits für die Standortinformationsdefinitionsbits, 4 Bits sind für die Standortaltersinformationen und 300 sind Standortinformationsinhalt. Die Werte für Positionsinformationskomponenten sind diejenigen, die in eine ganzzahlige Darstellung konvertiert wurden.
Vollständige Standortinformationen verstreut
Wenn das Standortinformationsblock-Definitionsbit den Wert 1 enthält, wird der Inhalt der Standortinformationen segmentiert und über 2 Epochen gesendet, während die Standortaltersinformationen mit jedem Segment über 2 Epochen gesendet werden. Datenabschnitte werden mit jeder CMRx-Nachricht gesendet, und diese Abschnitte werden durch Segmentnummern identifiziert. Segmentnummern entsprechen den geeigneten Bits der CMRx-Sequenznummer. Wenn die Standortinformationsblock-Definitionsbits den Wert 2 enthalten, wird der Inhalt der Standortinformationen segmentiert und über 4 Epochen gesendet, während die Standortaltersinformationen mit jedem Segment über 4 Epochen gesendet werden. Wenn die Standortinformationsblock-Definitionsbits den Wert 3 enthalten, wird der Inhalt der Standortinformationen segmentiert und über 8 Epochen gesendet, während die Standortaltersinformationen mit jedem Segment über 8 Epochen gesendet werden. Wenn die Standortinformationsblock-Definitionsbits den Wert 4 enthalten, wird der Inhalt der Standortinformationen segmentiert und über 16 Epochen gesendet, während die Standortaltersinformationen mit jedem Segment über 16 Epochen gesendet werden. Wenn die Standortinformationsblock-Definitionsbits den Wert 5 enthalten, wird der Inhalt der Standortinformationen segmentiert und über 32 Epochen gesendet, während die Standortaltersinformationen mit jedem Segment über 32 Epochen gesendet werden. Derselbe Lösungsansatz wird für bis zu 128 Epochen verwendet. 16 bildet ein Segment der Standortinformationen ab, wenn sie über vier Epochen verstreut werden.
VRS/PBS-Block
Wenn die CMRx-Beobachtungsnachricht Beobachtungsdaten für eine virtuelle Referenzstation transportiert, können die GNSS-Beobachtungsprozessoren Netzwerkinformationen ausnutzen. Aus diesem Grund werden oft zusätzliche Informationen für Daten zugeführt, die mit einem VRS-Punkt verknüpft sind. Wenn die CMRx VRS-Beobachtungen transportiert, gelten die folgenden Regeln:

1. Für den Headerblock aller CMRx-Beobachtungsdatennachrichten, die mit der VRS verknüpft sind, muss das VRS-Bit gesetzt sein (d. h. auf 1₂ gesetzt sein), ganz gleich ob die individuellen Beobachtungsnachrichten tatsächlich die ergänzenden VRS-Informationen transportieren oder nicht (nachstehend beschrieben). Die Regel gilt für alle Beobachtungsnachrichten für alle Konstellationen für eine bestimmte Epoche. Dies stellt sicher, dass der Empfänger sich auch unter extremen Kommunikationsverlusten darüber im Klaren ist, dass die Daten zu einer VRS gehören.
2. Der Positionsblock stellt die Position bereit, die mit den Daten verknüpft ist (d. h. in diesem Fall ist es die Position der virtuellen Referenzstation).
3. Der Standortinformationsblock, der sich in einer beliebigen Nachricht einer Epoche befindet, die mit dem bestätigten VRS-Modus markiert ist, gehört zu der nächstgelegenen reale Basisstation. D. h. dass der Standortinformationsblock Informationen, wie etwa Standortnamen, Antennenart und Antennenhöhe, enthält; alles Informationen, die zu realen und nicht virtuellen Standorten gehören.

17 bildet die Struktur des VRS/PBS-Blocks ab. Die PBS- und VRS-Präsenzbits haben die nachstehenden Bedeutungen.

Feld	Bits	Beschreibung
PBS Pres	1	Wenn dieses Bit gesetzt ist, gibt es an, dass der PBS-Block als Teil des VRS/PBS-Blocks vorhanden ist. Wenn dieses Bit zurückgesetzt (d. h. auf 0 [Basis 2] gesetzt) ist, bedeutet dies, dass der PBS-Block nicht Teil des VRS/PBS-Blocks ist.
VRS Pres	1	Wenn dieses Bit gesetzt ist, gibt es an, dass der VRS-Netzwerk-Residual-Block als Teil des VRS/PBS-Blocks vorhanden ist. Wenn dieses Bit zurückgesetzt (d. h. auf 0 [Basis 2] gesetzt) ist, bedeutet dies, dass der VRS-Netzwerk-Residual-Block nicht Teil des VRS/PBS-Blocks ist.

Der PBS-Block transportiert gewöhnlich Informationen über reale Basisstationen. Diese Informationen werden von Erkundungselementen zu Gewichtungszwecken verwendet und um der Software dabei zu helfen, Vektoren zu realen Standortpositionen zu erzeugen. Der VRS-Netzwerk-Residual-Block enthält Qualitätsinformationen, die mit jedem Satelliten verknüpft sind, der von dem Netzwerk beobachtet wird, was zur Gewichtung der Beobachtungsdaten beiträgt, die in GNSS-Datenprozessoren verwendet werden.
Die PBS- und VRS-Netzwerk-Residual-Blöcke sind optional. Der PBS-Block ist ein Nebenblock innerhalb des VRS/PBS-Blocks. Er ist nur vorhanden, wenn dies durch das Bit „PBS Pres” des VRS/PBS-Blocks angegeben wird. Der PBS-Block enthält die folgenden Informationen:

1. Alias einer realen Basisstation (5 Bits). Diese Informationen sind ähnlich wie die des „RefSta-Alias” des Beobachtungsnachrichten-Headerblocks. Der RefSta-Alias gehört jedoch immer zu einer Station (oder einem Punkt), die (bzw. der) mit den Beobachtungen verknüpft ist (d. h. wenn der VRS-Modus aktiviert ist, bezieht sich der „RefSta-Alias” auf den virtuellen Punkt, der mit Beobachtungen innerhalb der Nachricht verknüpft ist). In diesem PBS-Block bezieht sich der Alias einer realen Basisstation (oder PBS-Alias) auf die Alias-ID, die mit der realen Basisstation verknüpft ist, deren Koordinaten innerhalb dieses Blocks zugeführt werden.
2. Breite (36 Bits).
3. Länge (37 Bits).
4. Höhe (25 Bits).

Unsegmentiertes PBS-Konstrukt
Das in 18 gezeigte unsegmentierte PBS-Konstrukt bildet die Komponenten des PBS-Blocks ab (siehe 19), die im Speicher zusammenhängend gespeichert werden. Ein derartiges Konstrukt kann bei dem Codierungsprozess verwendet werden, um die Bits zu enthalten, die in Segmente gesetzt werden. Während der Codierung kann es verwendet werden, um Segmentdaten sofort zu speichern, wenn sie eintreffen, und nach Abschluss der Segmentankunft ist es der Block, aus dem die diversen Komponenten des PBS-Blocks entnommen werden können. Dieses Konstrukt enthält den PBS-Alias, die 36 Bits der Breite, die 37 Bits der Länge und die 25 Bits der ellipsoidischen Höhe. Man geht davon aus, dass die Werte für die geografische Breite, Länge und Höhe in ihre ganzzahlige Darstellung konvertiert werden müssen.
Soweit vorhanden, besteht der PBS-Block wie in 19 gezeigt aus: 1) Definitionsbits; und 2) PBS-Blockkörperbits. Es kann ein PBS-Alter (AOPBS) geben, das mit den PBS-Verstreuungsinformationen gesendet wird. Es hat die gleiche Bedeutung/den gleichen Zweck wie das Positionsalter innerhalb des Positionsblocks, gilt jedoch für das Alter der PBS-Informationen, bzw. AOPBS.

Die nachstehende Tabelle erläutert die Bedeutung der PBS-Blockbits.

PBS-Blockdefinition	Kurze Beschreibung
0	Der PBS-Blockkörper enthält die gesamte geografische Breite, Länge, Höhe und das PBS-Alter, wie in Fig. 20 gezeigt.
1	Der PBS-Alias, Breite, Länge und Höhe über 2 Epochen verstreut.
1	Segment 0 1	Bitanzahl für PBS-Daten 52 + 4 Bits für PBS-Alter 51 + 4 Bits für PBS-Alter
2	Der PBS-Alias, Breite, Länge und Höhe über 4 Epochen verstreut.
2	Segment 0–2 3	Bitanzahl für PBS-Daten 26 + 4 Bits für PBS-Alter 25 + 4 Bits für PBS-Alter
3	Der PBS-Alias, Breite, Länge und Höhe über 8 Epochen verstreut.
3	Segment 0–6 7	Bitanzahl für PBS-Daten 13 + 4 Bits für PBS-Alter 12 + 4 Bits für PBS-Alter
4	Der PBS-Alias, Breite, Länge und Höhe über 16 Epochen verstreut.
4	Segment 0–6 7–15	Bitanzahl für PBS-Daten 7 + 4 Bits für PBS-Alter 6 + 4 Bits für PBS-Alter
5	Der PBS-Alias, Breite, Länge und Höhe über 32 Epochen verstreut.
5	Segment 0–6 7–31	Bitanzahl für PBS-Daten 4 + 4 Bits für PBS-Alter 3 + 4 Bits für PBS-Alter
6	Der PBS-Alias, Breite, Länge und Höhe über 64 Epochen verstreut.
6	Segment 0–38 39–63 1 + 4	Bitanzahl für PBS-Daten 2 + 4 Bits für PBS-Alter Bits für PBS-Alter
7	Der PBS-Alias, Breite, Länge und Höhe über 128 Epochen verstreut.
7	Segment 0–102 103–127	Bitanzahl für PBS-Daten 1 + 4 Bits für PBS-Alter Keine PBS-Daten

VRS-Informationen
Der VRS-Block ist ein Nebenblock innerhalb des in 17 abgebildeten VRS/PBS-Blocks. Der VRS-Block ist nur vorhanden, wenn dies durch das Bit „VRS Pres” des VRS/PBS-Blocks angegeben wird (siehe 17). Der VRS-Block enthält die folgenden Informationen:

1. Anzahl der Satelliten (6 Bits). Diese Informationen werden mit jedem VRS-Block gesendet (ganzer Block oder verstreuter Block) und werden verwendet, um zu definieren, wie viele Bytes noch für die gesamten, nachstehend besprochenen VRS-Netzwerk-Residualen zu entpaketieren sind.
2. PRN-Wortmodus (2 Bits), um die Größe eines PRN-Worts bereitzustellen.
3. PRN-Wortliste der Satelliten, für die es Netzwerk-Residualen gibt (24 bis 63 Bits).
4. Zeit-Tag, das mit den Netzwerk-Residualen verknüpft ist (9 Bits)
5. Netzwerk-Residualen pro Satellit (10 Bits).
6. Geometrische Standardabweichung (5 Bits).
7. Ionosphärische Standardabweichung (5 Bits).

Es wurden bereits mehrere Informationsblöcke besprochen, die segmentiert/verstreut werden können (z. B. Positionsblock, Standortinformationsblock und PBS-Block). Bei den Beschreibungen dieser Blöcke wurde jedoch davon ausgegangen, dass der Informationsinhalt, d. h. was segmentiert und dann verstreut wurde, eine feste Länge hatte. Die VRS-Informationen haben jedoch keine feste Größe. Ihre Größe basiert auf der Anzahl der Satelliten, für die es Netzwerk-Residualen gibt. Man kann jedoch nicht davon ausgehen, dass es VRS-Netzwerk-Residualen gibt, die mit jedem Satelliten in dem PRN-Wort (den PRN-Wörtern) der Beobachtungsnachricht verknüpft sind. Aus verschiedenen Gründen kann es nämlich sein, dass die Satellitengruppe, für die eine Beobachtungsnachricht Satellitenbeobachtungsdaten transportiert, nicht der Satellitengruppe entspricht, für die VRS-Netzwerk-Residualen bereitgestellt werden. Daher wird die Satellitenanzahl für den gesamten VRS-Netzwerk-Residual-Block (siehe 22) für eine bestimmte Konstellation als Teil der verstreuten Daten bereitgestellt.

Die VRS-Informationen haben keine feste Länge und erfordern somit eine andere Handhabung, wenn sie abgerollt werden sollen. Um dieses Problem zu lösen, gibt ein VRS-Netzwerkverarbeitungsalgorithmus dem CMRx-Codierer Daten zur rechten Zeit. Ein Bit „Time Pres” zusammen mit Zeitversatzbits sorgt für Flexibilität bei einer derartigen Verstreuung. Das Bit „Time Pres” hat zwei mögliche Einstellungen:

Wert	Beschreibung
0	Zeit der CMRx-Beobachtungsnachricht als Referenzzeit verwenden.
1	Die Referenzzeit für die Netzwerk-Residualen ist eine Kombination aus
	den Zeitversatzbits und der Zeit der CMRx-Beobachtungsnachricht.

Wenn das Bit „Time Pres” zurückgesetzt wird (d. h. den Wert 0 [Basis 2]) enthält, sind keine Zeitversatzbits in dem Block vorhanden und die Zeit der CMRx-Beobachtungsnachricht wird als Zeit-Tag verwendet, das mit den Netzwerk-Residualen verknüpft ist, die man später in dem VRS-Netzwerk-Residual-Block vorfindet. Wenn das Bit „Time Pres” gesetzt ist (d. h. den Wert 1₂ enthält), sind die Zeitversatzbits in dem Block vorhanden. Die Zeitversatzbits speichern einen Versatz in Sekundeneinheiten, der in einem negativen Sinn auf die Zeit der CMRx-Beobachtungsnachricht anzuwenden ist, um das Zeit-Tag zu erhalten, das mit den Netzwerk-Residualen verknüpft ist, die man später in dem VRS-Netzwerk-Residual-Block vorfindet. Nämlich VRS_Residt = CMRtmsg – Timeoffsetmsg

wobei	CMrtmsg	CMRx-Beobachtungszeit (einschließlich eines eventuellen
		Epochenzeitbruchteils)
	Timeoffsetmsg	Ist der Wert der Zeitversatzbits in Sekunden konvertiert; und
	VRS_Residt	das Zeit-Tag, das mit den VRS-Restinformationen verknüpft
		ist, die in dem Block folgen.

Der „PRN-Modus” definiert, wie die PRN-Liste bereitgestellt wird. Grundsätzlich wird die PRN-Liste bereitgestellt, und dann werden die mit diesen PRN verknüpften VRS-Reste bereitgestellt. Der Grund für den „PRN-Modus” ist grundsätzlich eine Möglichkeit, die Bits zu reduzieren, die erforderlich sind, wenn eine gewisse Anzahl von Satelliten erreicht wird, die in dem Block enthalten sein sollen. Man betrachte die folgende Bedeutung des PRN-Modus:

Wert	Beschreibung
0	Der Abschnitt PRN Ident enthält eine Zählung der PRN (3 Bits), gefolgt
	von einer PRN-Liste. Für jede gespeicherte PRNID nach der PRN-Zählung: a) Der für jede PRNID gespeicherte Wert ist um eine Einheit kleiner als die eigentliche ID: wenn z. B. die anzugebende ID 16 ist, dann wird der Wert 15 in den SVPRN-Bits gespeichert.
	b) Die Anzahl der Bits, die erforderlich sind, um jede PRNID zu speichern, ist von der größten SVPRN-ID abhängig, die von den PRN-Kapazitätsbits des Headerblocks der CMRx-GPS-Beobachtungsdatennachricht identifiziert wird.
1	Der Abschnitt PRN Ident ist ein Speicher nach Art eines PRN-Worts. In seiner grundlegenden Form ist dieses PRN-Wort eine 32-Bit-Zahl, wobei jedes Bit eine Satelliten-PRNID darstellt; das Bit ganz rechts stellt SVPRN Nr. 1 und das Bit ganz links SVPRN Nr. 32 dar. Die Anzahl der Bits, die in diesem PRN-Wort gesetzt sind, gibt an, wie viele Gruppen von Satellitenresten im übrigen Block gespeichert sind. Diese Reste werden basierend auf der SVPRN-Nummer gespeichert und werden gemäß den in diesem PRN-Wort gesetzten Bits in steigender Reihenfolge gespeichert.

Die Bits „PRN Ident” bestimmen die Anzahl der VRS-Netzwerk-Residualen und ihre Reihenfolge, in der mit spezifischen PRN verknüpft sind, die im übrigen VRS-Netzwerk-Residual-Block gespeichert sind. Die restlichen Informationen für jeden Satelliten haben die in 22 gezeigte Form. Die geometrischen und/oder ionosphärischen Restinformationen sind optional. Ihr Vorhandensein wird jeweils durch den Wert der Bits „Geo Res Pres” und Iono Res Pres” angegeben. Ein Wert von 1 bedeutet, dass die verknüpften Restinformationen vorhanden sind, während ein Wert von 0 bedeutet, dass die Informationen nicht vorhanden sind. Die tatsächlichen geometrischen und ionosphärischen Standardabweichungsweite sind 5-Bit-Codierungen. Mit Ausnahme von 00000 [Basis 2] und 11111 [Basis 2] wird der für eine restliche Standardabweichung gespeicherte Wert wie folgt berechnet:
wobei i der in CMRx für den Rest gespeicherte Wert ist.

Eine Verweistabelle stellt die Werte bereit.

i₁₀	I (Basis 2)	Geom. Std.-Abw. (cm)	Iono. Std.-Abw. (cm)	Restbereich (cm)
0	00000	Keine Informationen	Keine Informationen	Keine Informationen
1	00001	0,1	0,1	0,0 <= res < 0,2
2	00010	0,3	0,3	0,2 <= res < 0,45
3	00011	0,6	0,6	0,45 <= res < 0,8
4	00100	1	1	0,8 <= res < 1,25
5	00101	1,5	1,5	1,25 <= res < 1,8
6	00110	2,1	2,1	1,8 <= res < 2,45
7	00111	2,8	2,8	2,45 <= res < 3,2
8	01000	3,6	3,6	3,2 <= res < 4,05
9	01001	4,5	4,5	4,05 <= res < 5,0
10	01010	5,5	5,5	5,0 <= res < 6,06
11	01011	6,6	6,6	6,06 <= res < 7,2
12	01100	7,8	7,8	7,2 <= res < 8,45
13	01101	9,1	9,1	8,45 <= res < 9,8
14	01110	10,5	10,5	9,8 <= res < 11,25
15	01111	12	12	11,25 <= res < 12,8
16	10000	13,6	13,6	12,8 <= res < 14,45
17	10001	15,3	15,3	14,45 <= res < 16,2
18	10010	17,1	17,1	16,2 <= res < 18,05
19	10011	19	19	18,05 <= res < 20,0
20	10100	21	21	20,0 <= res < 22,5
21	10101	23,1	23,1	22,5 <= res < 24,2
22	10110	25,3	25,3	24,2 <= res < 26,45
23	10111	27,6	27,6	26,45 <= res < 28,8
24	11000	30	30	28,8 <= res < 31,25
25	11001	32,5	32,5	31,25 <= res < 33,8
26	11010	35,1	35,1	33,8 <= res < 36,45
27	11011	37,8	37,8	36,45 <= res < 39,2
28	11100	40,6	40,6	39,2 <= res < 42,05
29	11101	43,5	43,5	42,05 <= res < 45,0
30	11110	46,5	46,5	45,0 <= res < 48,05
31	11111	SV nicht verwenden	SV nicht verwenden	SV nicht verwenden

GPS-Beobachtungsblock
Das Beobachtungsblock-Präsenzbit (OBP) des CMRx-GPS-Beobachtungs-Headerblocks (7) gibt an, ob die GPS-Beobachtungen des Empfängers als Teil des CMRx-GPS-Beobachtungsdaten-Nachrichtenkörpers gespeichert werden. Der Beobachtungsblock hat die in 23 gezeigte Form.
Die Größe des GPS-Beobachtungsblocks ist hauptsächlich abhängig von (a) den Modi und Maßstäben der Beobachtungscodierung, die durch die Definitionsbits vorgegeben werden; und (b) Anzahl und Art der Satelliten, die in dem Beobachtungsblock gespeichert werden. Natürlich kann die gesamte Beobachtungsfolge mehr als eine CMRx-Beobachtungs-/Modellierungs-Datennachricht übergreifen. Wenn dem so ist, gibt das Epochenfortsetzungs-Flag des CMRx-GPS-Beobachtungs-Headerblocks an, dass eine Epoche aus mehr als einer CMRx-Nachricht besteht.
GPS-Beobachtungsblock-Definitionsbits
Format, Inhalt und Größe des GPS-Beobachtungsblocks sind von den Werten der ersten GPS-Beobachtungsblock-Definitionsbits abhängig. Das Format ist in 24 abgebildet. Bevor die Beschreibung der Definitionsbits fortgeführt wird, ist es wichtig zu beschreiben, was hier als übergeordnete (Major) und untergeordnete (Minor) Elemente bezeichnet wird. Diese Begriffe gelten für alle Satelliten innerhalb der CMRx-Nachricht und für Satelliten auf individueller Basis. Übergeordnet bezieht sich auf alles, was für alle Satellitenbeobachtungen innerhalb einer Nachricht gilt, während untergeordnet sich auf alles bezieht, was auf individueller Satellitenbasis gilt.
Um den Nutzen zu erläutern, wird der Lösungsansatz bei der Einführung von L2c betrachtet. Als L2c zum ersten Mal in die GPS-Konstellation eingeführt wurde, übertrugen nur wenige Satelliten L2c. In dem Maße wie neue Satelliten in die Konstellation eingeführt wurden, stieg die Anzahl der L2c sendenden Satelliten an. Um L2c in der Nachricht unterzubringen, könnte man einen L2c-Sendeplatz für jeden Satelliten zuteilen und eine Anzeige ungültiger Daten für den L2c-Sendeplatz senden, wenn der verknüpfte Satellit L2c nicht überträgt. Zu Beginn der Einführungsperiode ist es jedoch effizienter, in der Nachricht über L2c-Sendeslots nur für Satelliten zu verfügen, für die L2c-Daten übertragen werden. Aus diesem Grund werden einige Beobachtungsartbits als übergeordnet angesehen, da sie für alle Satelliten gelten. Eines der Bitmuster der übergeordneten L2c-Beobachtungsart gibt an, dass man sich die untergeordneten L2c-Beobachtungsbits ansehen muss, um herauszufinden, ob L2c in diesem SV vorhanden ist. Während die Anzahl der L2c-Satelliten zunimmt, kann das CMRx-Format verändert werden, um das L2c übergeordnete Bitmuster zu verwenden, das angibt, dass L2c auf allen Satelliten vorhanden ist, und dass daher die untergeordneten L2c-Bits nicht mehr in der Nachricht vorhanden sind. Dieser Lösungsansatz sorgt für einen effizienten Übergang von der Einführung neuer Signale bis zum vollständigen Einsatz dieser Signale.
Komprimierungsstufe und erweiterte Komprimierungsmodi
Die Anzahl der paketierten Bits und die Präzision der paketierten Daten sind von den Arten der in der Nachricht gespeicherten Beobachtungen, der Komprimierungsstufe und der Auswahl der erweiterten Komprimierungsmodi abhängig. Es gibt 8 Code-Komprimierungsstufen (Bits 0 bis 2 der GPS-Beobachtungsblock-Definitionsbits), 8 Träger-Komprimierungsstufen (Bits 3 bis 5 der GPS-Beobachtungsblock-Definitionsbits) und 4 erweiterte Komprimierungsmodi (Bits 6 bis 7 der GPS-Beobachtungsblock-Definitionsbits).
Für Komprimierungsstufen nimmt im Allgemeinen mit jedem Komprimierungsstufenanstieg die Anzahl der Bits, die zum Speichern von Beobachtungen erforderlich sind, und die Präzision der gespeicherten Daten ab. Eine Tabelle weiter unten beschreibt diese Werte und die Komprimierungsstufen. Die Komprimierungsstufen bedienen verschiedene Anwendungen, welche die CMRx verwenden. Sie werden von dem Rufer des CMRx-Codierers eingestellt und sind von den Bedürfnissen der Anwendung abhängig. Die Anforderungen bezüglich der Trägerauflösung können z. B. für allgemeine RTK-Zwecke geringer sein als diejenigen, die für die Lagebestimmung benötigt werden. Ferner können zukünftige GNSS-Empfänger in der Lage sein, genauere Trägermessungen bereitzustellen.
Bits 6 und 7 der GPS-Beobachtungsblock-Definitionsbits stellen die Einstellungen der erweiterten Komprimierungsmodi bereit. Wenn der Dezimalgegenwert dieser Bits 0 ist, sind keine erweiterten Komprimierungsmodi aktiviert. Wenn die erweiterten Komprimierungsmodi aktiviert sind, werden die benötigten Bits und die Datenpräzision zum Speichern der Beobachtungen gemäß der nachstehenden Tabelle reduziert.
Die erweiterten Komprimierungsmodi nutzen bekannte physikalische Größen und speichern Abweichungen von erwarteten Werten (Abweichungen, die etwa auf Mehrwegübertragung, Umlaufbahnfehler, nicht modellierte Troposphäre und nicht berücksichtigte Ionosphäre zurückzuführen sind). Um die Anzahl der benötigten Bits zu reduzieren, kennen die sowohl die Komprimierungs- als auch die Dekomprimierungsprozesse Satellitenpositionen, Antennenposition und Empfängertaktgeberversätze für jede CMRx-Epoche. Nachstehend wird ein Überblick über diese Größen sowohl für die Komprimierungs- als auch für die Dekomprimierungsprozesse bereitgestellt, wenn die erweiterten Komprimierungsmodi aktiviert sind.
Komprimierungsprozess
Position. Die Position wird vom Benutzer eingegeben oder aus einer Tabelle ausgewählt. Die Position bis auf +/– 50 Meter wird dem Komprimierungsprozess zugeführt.
Taktgeberversatz
Der Taktgeberversatz ist bis auf ungefähr 150 ns bekannt.
Navigationsnachrichten
Um die Positionen der Satelliten zu berechnen, muss eine Quelle für Navigationsnachrichten zur Verfügung stehen. Die Bereiche der beobachtbaren Mengen, die in der CMRx-Nachricht gespeichert sind, wurden derart ausgewählt, dass sie die Komprimierungs- und Dekomprimierungsprozesse für die IODE-Probleme der Übertragungsnavigationsumlaufbahnen unempfindlich machen. Somit müssen die Navigationsnachrichten (rundgesendete oder präzise), die für den CMRx-Komprimierungsprozess verwendet werden, nicht genau die gleichen sein, die in dem Dekomprimierungsprozess verwendet werden.
Dekomprimierungsprozess
Position
Der Dekomprimierungsprozess erhält die Position aus lokalen, vom Benutzer eingegebenen Koordinaten, einem Tabellenverweis, der auf der Standort-ID und/oder dem Standortnamen basiert, oder als Teil der CMRx-Nachricht empfangen.
Taktgeberversatz
Der Taktgeberversatz des Empfängers ist für den Dekomprimierungsprozess mit der gleichen Präzision wie die der Komprimierungsseite bekannt.
Navigationsnachrichten
Um die Beobachtungsdaten zu rekonstruieren, muss die Dekomprimierungsseite die Satellitenpositionen kennen. Wenn die CMRx-Nachricht, die von der CMRx-Komprimierungsseite gesendet wird, orbitale Informationen umfasst, dann kann die Dekomprimierungsseite diejenigen verwenden, die in der CMRx-Nachricht empfangen werden. Alternative Quellen für Navigationsnachrichten stammen von dem lokalen GPS-Empfänger oder von schnellen präzisen Umlaufbahnen aus dem Internet.
Wenn entweder CNR oder ORB, oder beide, gesetzt sind, ist SV Cnt vorhanden, um die Anzahl der SV anzugeben, für die CNR- oder ORB-Daten vorhanden sind. Das SVPRN führt den ersten Satelliten im PRN-Wort auf, der diese Daten enthält. Weil diese Beobachtungen innerhalb einer Nachricht sequenziell gespeichert werden, wenn SV Cnt mehr als ein SV angibt, geben die SVPRN-Bits das erste SV für die Zählung an. Die übrigen SV folgen unmittelbar in dem GPS-Beobachtungsblock. Wenn SV Cnt und SVPRN mehr als ein SV angeben, z. B. 4 SV, und die PRNID Ergebnisse bei weniger als der in der Nachricht verbleibenden angab, um SV Cnt zu erreichen (z. B. gibt SVPRN SV 22 an, und die SV 1, 3, 5, 7, 22, 23 und 24 liegen in der Nachricht vor, dann gibt die SV Cnt von 4 an, dass es 4 SV geben müsste, aber nur die SV 22, 23 und 24 in der Nachricht übrigbleiben. Somit sind nur diese 3 in der Nachricht enthalten.
Troposphären-Ionosphären-Korrekturen
Für den erweiterten Komprimierungsmodus, der für die Ionosphäre/Troposphäre optimiert ist, wird eine weitere Komprimierung erzielt, indem vor der Komprimierung eine modellierte Troposphäre aus den Beobachtungen und eine modellierte Ionosphäre aus jeder der Beobachtungen entfernt wird. Um die ionosphärische Größe zu berechnen, muss der Empfänger mindestens ein Doppelfrequenz-Codephasen-Empfänger sein. Bei CMRx bedeutet dies, dass mindestens zwei der mit L1-, L2- und L5-Daten verbundenen Bits ungleich Null sein müssen. Für die Troposphäre sollte das gleiche Troposphärenmodell von den Komprimierungs- und Dekomprimierungsprozessen verwendet werden. Es werden die gleichen Troposphären- und Ionosphärenmodelle von den Komprimierungs- und Dekomprimierungsprozessen verwendet.
Es ist wohlbekannt, dass die Ausbreitungsgeschwindigkeit von GPS-Signalen durch den unteren Teil der Erdatmosphäre langsamer ist als durch luftleeren Raum. Der untere Teil der Atmosphäre besteht hauptsächlich aus Stickstoff, Sauerstoff und Wasserdampf. Der größte Teil des Wasserdampfs befindet sich unterhalb von 4 Kilometer, wobei sich im Wesentlichen der gesamte Wasserdampf unterhalb von 12 Kilometer befindet. Die Trockengase Stickstoff und Sauerstoff treten jedoch in allmählich dünner werdenden Mengen auf, wenn die Höhe auf mehrere hundert Kilometer ansteigt. Die globalen Auswirkungen dieser atmosphärischen Gase auf ein GPS-Signal werden gewöhnlich als troposphärischer Effekt bezeichnet. Daraus ergibt sich, dass der Satellit eine scheinbare Reichweite hat, die länger ist als ihr tatsächlicher Wert.
Bei einer Durchführung der CMRx wird eine Näherung des Hopfield-Modells der Troposphäre mit einer angenommenen Verzögerung von 2,5 Meter verwendet. Die Näherung ist weniger rechenintensiv, ist jedoch eine gute Näherung, wenn man ihr typische meteorologische Werte bereitstellt. Für den erweiterten Komprimierungsmodus stellt das Troposphärenmodell daher nur den Unterschied zwischen der angenommenen 2,5m-Verzögerung und der tatsächlichen Troposphärenverzögerung, wie sie basierend auf der Höhe der Referenzstation berechnet wird, bereit.

//NOMINELLE TROPOSPHÄRENVERZÖGERUNG BERECHNEN: d. h. UNTER
VERWENDUNG EINER NOMINELLEN 2,5m-ZENITVERZÖGERUNG – WENN
DER HÖHENWINKEL KLEINER ALS 2,5 GRAD IST, WIRD DIE TROPOSPHÄRE
EINER 2,5-GRAD-HÖHE BERECHNET.// dTropoE1 = dSatE1Degrees; if (dTropoE1 < 2.5) dTropoE1 = 2.5; dTemp = dPositionHeight_meters/5254.478; dTemp = 2.31·exp (–dTemp); dTropoDelay = dTemp/sin (DegreesToRadians (dTropoE1))
Die Ionosphäre erstreckt sich von ungefähr 50 km bis ungefähr 1000 km über der Erde. Es handelt sich um ein Gebiet ionisierter Gase, die hauptsächlich durch die Sonnenstrahlung hervorgerufen werden. Das Ausmaß der Auswirkung der Ionosphäre auf GPS-Signale hängt von der Sonnentätigkeit, der Tageszeit und anderen Faktoren ab. Es ist ebenfalls wohlbekannt, dass die Auswirkung der Ionosphäre auf GPS-Signale von den relativen Ausrichtungen zwischen den Satelliten und der Position des GPS-Empfängers auf der Erde abhängt. Dies ist in 25 abgebildet. Wie hier gezeigt, gehen für einen ersten Satelliten A direkt über einem Punkt X die GPS-Signale durch einen Abschnitt der Erdatmosphäre, der mit „a” bezeichnet ist. Wie in dieser Figur gezeigt, nimmt das Ausmaß, in dem das GPS-Signal durch die Ionosphäre geht zu, je mehr sich die Satellitenpositionen dem Horizont nähern. Z. B. hat der Satellit C, der tief am Himmel steht, eine relative Ausrichtung zu Punkt X, die verursacht, dass sein Signal durch einen größeren Abschnitt der Ionosphäre geht, der in 25 mit c bezeichnet ist. Z. B. mit Bezug auf 25 geht man davon aus, dass der Satellit A keine Ionosphärenverzögerung aufweist, während der Satellit C eine Ionosphärenverzögerung von c-a aufweist, die dem Komprimierungsalgorithmus bereitgestellt wird. 25 zeigt die Ionosphäre als eine dünne gleichmäßige Schicht. In Wirklichkeit ist die Ionosphäre ungleichmäßig (dicker an verschiedenen Durchdringungswinkeln) und ändert sich mit der Zeit. Um die Bits zu reduzieren, behandelt die CMRx die Ionosphäre als ob sie gleichmäßig wäre, indem sie eine durchschnittliche senkrechte Ionosphäre unter Verwendung des gemeinsamen Ganzen der Doppelfrequenz-(oder Multifrequenz) Daten in jeder Epoche berechnet. Diese Mittelwertbildung erfolgt, um einen großen Abschnitt der Ionosphäre zu entfernen, der das Signal beeinflusst. Der restliche Abschnitt, der nicht entfernt wird, wird als Beobachtungsinformationen (zusammen mit anderen nicht berücksichtigten Einflüssen, wie etwa die Troposphäre und Mehrwegübertragung) gesendet, die der Empfänger zusammen mit der durchschnittlichen senkrechten Ionosphäre dann zur ursprünglichen Beobachtung rekonstruiert.
Um die Ionosphärengröße zu berechnen, muss der Empfänger mindestens ein Doppelfrequenz-Codephasen-Empfänger sein (d. h. es müssen mindestens zwei der mit den L1-, L2- und L5-Daten verbundenen Bits ungleich Null sein). Für jeden Satelliten wird die Ionosphärenbeobachtung unter Verwendung der folgenden Gleichung berechnet (angenommen, es werden L1 und L2 verwendet). bGAMMASQ = (77.0/60.0)^2 dObservedIono = (dCodeObsL2 – dCodeObsL1)/(bGAMMASQ – 1.0)
Diese Ionosphärenbeobachtungen werden jeweils auf die Senkrechte abgebildet (siehe Satellit A in 25), so dass eine gemittelte senkrechte Ionosphäre berechnet werden kann. Nachstehend wird der Algorithmus gezeigt, der verwendet wird, um jede beobachtete Ionosphäre auf die Senkrechte abzubilden: dIonoSlntFact = 1.0 + 2.0·pow ((96.0 – dSatE1Degrees)/90.0, 3.0); dVertObsIono = dObservedIono/dIonoSlntFact;
Der Komprimierungsalgorithmus kann dann die senkrecht abgebildeten Ionosphärenwerte mitteln. Dieser senkrecht abgebildete Durchschnitt wird dann aus den Beobachtungen entfernt, bevor die Daten komprimiert werden (d. h. die gemittelte senkrechte Ionosphäre wird dann wieder für jeden Satelliten zurück auf seine Höhe abgebildet und diese abgebildete Größe wird dann aus der Beobachtung entfernt). Der Wert dieser gemittelten senkrecht abgebildeten Ionosphäre wird als Teil der Nachricht in dem für Ionosphäre/Troposphäre optimierten Fensterblockteil des Beobachtungsblocks gesendet.

Die folgende Tabelle beschreibt die Bitbedeutungen der erweiterten Komprimierungsmodi.

Feld	Bits	Beschreibung
Erw. Mod.	2	Diese Bits bezeichnen einen „erweiterten” Komprimierungsmodus.

		Wert	Beschreibung
		00	Kein erweiterter Modus (d. h. Standardkomprimierung)
		01	Erweiterter Komprimierungsmodus
		10	Für Ionosphäre/Troposphäre optimierter erweiterter Komprimierungsmodus
		11	Reserviert

Beobachtungsfolgebits
Die Beobachtungsfolgebits der GPS-Beobachtungsblock-Definitionsbits (d. h. 8 bis 19 der GPS-Beobachtungsblock-Definitionsbits – siehe 24) stellen Informationen über die GPS-Satellitenbeobachtungen bereit, die in dem GPS-Beobachtungsblock der Nachricht gespeichert sind. Wie zuvor angegeben, werden hier GPS und GNSS austauschbar verwendet. Jede GNSS-Satellitenkonstellation verwendet jedoch verschiedene Frequenzen und Codestrukturen. Somit sind die Arten der Beobachtungen, die für andere Konstellationen transportiert werden (wie etwa GLONASS, Galileo oder Compass) anders als die für GPS. Dies bedeutet, dass Beobachtungsblöcke (die Beobachtungsblock-Definitionsbits umfassen, Observablen, die in der Nachricht gespeichert sind, usw.) bei den verschiedenen Konstellationen unterschiedlich sind. Trotzdem sind die wesentlichen grundlegenden Konzepte der Biteinsparung/Komprimierung bei den diversen CMRx-Nachrichten für jede GNSS-Konstellation die gleichen.
Die RefCode-Bits geben die Art der Codephase an, die als CMRx-Referenzcode verwendet wird. Ein Prinzip der CMRx ist ihre Verwendung eines Referenzcodes. Die CMRx speichert einen Referenzcode pro Satellit, und dann werden alle anderen Beobachtungen für diesen Satelliten mit Bezug auf diesen Referenzcode gespeichert. Es gibt folgende Referenzcodes:

Wert Beschreibung

00 L1 C/A ist der Referenzcode.

01 L2c ist der Referenzcode.

10 L5 ist der Referenzcode.

11 L1c ist der Referenzcode.
Das RP-Bit gibt die Anzahl der vorhandenen Bereiche in den Beobachtungsdaten des GPS-Beobachtungsdatenblocks an.

Wert Beschreibung

0 Alle vorgegebenen Codes sind vorhanden (alle Träger vorhanden)

1 Nur Referenzcode vorhanden (alle Träger vorhanden)
Das L1 C/A-Bit ist nur vorhanden, wenn der Referenzcode nicht auf L1 C/A gesetzt ist (d. h. wenn der Referenzcode L1 C/A ist, dann geht man davon aus, dass die L1 C/A-Daten vorhanden sind). Dieses Bit hat die folgenden Bedeutungen:

Wert Beschreibung

0 L1 C/A-Daten ist für jedes SV vorhanden.

1 Keine L1 C/A-Daten in den Beobachtungsdaten vorhanden.
Das L2e-Bit gibt an, ob L2e-Daten vorhanden sind.

Wert Beschreibung

0 L2e-Daten für jedes SV vorhanden.

1 Keine L2e-Daten in den Beobachtungsdaten vorhanden
Das L1e-Bit gibt an, ob L1e-Daten vorhanden sind.

Wert Beschreibung

0 L1e-Daten für jedes SV vorhanden.

1 Keine L1e-Daten in den Beobachtungsdaten vorhanden
Die L2c-Bits kann man als L2c übergeordneten Indikator ansehen. Eine Bitkombination setzt voraus, dass man das L2c untergeordnete Bit überprüfen muss, das mit jedem Satelliten in den Satellitenbeobachtungsdaten verknüpft ist. Es ist jedoch zu beachten, dass wenn L2c als Referenzcode ausgewählt wird, diese Bits nicht in den Definitionsbits vorhanden sind. Wenn L2c der Referenzcode ist, dann enthalten alle einbezogenen Beobachtungen bevorzugt mindestens L2c-Code- und Trägerdaten.

Wert Beschreibung

00 L2c-Daten für alle SV vorhanden

01 Keine L2c-Daten vorhanden

10 Individuelle SV haben einen untergeordneten Header, um L2c

anzugeben

11 Reserviert
Die L5-Bits sind die gleichen wie für L2c, gelten jedoch für L5-Daten. Die L1c-Bits sind die gleichen wie für L2c, gelten jedoch für L1c-Daten.
„Beste Wahl” Modus
Der GPS „Beste Wahl”-Modus nutzt die Tatsache, dass viele RTK-Anwendungen nur Code- und/oder nur Trägerdaten von einer einzigen Verfolgungsart für jede Frequenz verarbeiten. Dies gilt insbesondere während der Einführung von L2c- und L1c-GPS-Satellitenfähigkeiten. Dies bedeutet, dass obwohl ein Empfänger L2E und L2c verfolgen und melden kann, verwenden die derzeitigen typischen RTK-Verarbeitungs-Engines für SV, die sowohl herkömmliche L2-Signale als auch moderne L2c-Signale übertragen, nur eines der beiden Signale. Daher ist es erwünscht, dass die CMRx in diesen Fällen die „beste Wahl” von entweder L2E oder L2c bereitstellt. Ähnlich ist es erwünscht, die „beste Wahl” von L1 C/A und L1c zu senden, wenn die GPS-Satelliten mit der Übertragung des L1c-Signals beginnen.
Eine Anwendung, die den CMRx-Codierer verwendet, kann den „Beste Wahl”-Modus als Konfigurationswahl aktivieren oder deaktivieren. Wenn er aktiviert ist, ermittelt der CMRx-Codierer basierend auf den zugeführten Epochendaten, ob der „Beste Wahl”-Modus beim Paketieren der Daten verwendet werden sollte oder nicht. Wenn er verwendet wird, wird vom Codierer eine spezielle Codierung verwendet, um anzugeben, ob sich GPS-L1- und/oder L2-Daten in diesem „Beste Wahl”-Modus befinden. Durch diese spezielle Codierung weiß der Decodierer, dass der Modus aktiviert ist.
Der Begriff „Unverfügbar”, wie er hier verwendet wird, soll folgendes beschreiben: (a) den Epochendaten, die dem Codierer zugeführt werden, fehlt ein bestimmtes Datenelement, entweder wegen eines Vorfiltern oder weil der Empfänger diese Daten nicht verfolgt/gemeldet hat. Wenn z. B. keine L2c-Daten in den Epochen-Daten vorhanden sind, dann könnte es entweder sein, dass der Empfänger diese Daten nicht verfolgt/gemeldet hat oder dass die Daten aus Epochendaten vorgefiltert wurden, die dem CMRx-Codierer zugeführt wurden, oder (b) die Konfiguration des CMRx-Codierers gibt spezifisch an, dass L2c-Daten zu ignorieren sind. Damit also Daten als verfügbar angesehen werden, müssen die Beobachtungsdaten in den dem CMRx-Codierer zugeführten Epochendaten vorhanden sein, und der CMRx-Codierer muss konfiguriert sein, um diese Daten zuzulassen.
Wenn der CMRx-Codierer konfiguriert ist, um den L2 „Beste Wahl”-Modus zu aktivieren, bedeutet dies nicht unbedingt, dass der „Beste Wahl”-Modus verwendet wird. Die CMRx verwendet die folgenden Regeln für den „Beste Wahl”-Modus.

1. Der L2 „Beste Wahl”-Modus ist immer deaktiviert, wenn der CMRx-Codierer derart konfiguriert ist: d. h. die übrigen Regeln gelten nicht, wenn der „Beste Wahl”-Modus deaktiviert ist.
2. Wenn die Epochendaten dem CMRx-Codierer zugeführt werden und es mindestens einen GPS-Satelliten gibt, bei dem sowohl L2E als auch L2c verfügbar sind, wird der L2 „Beste Wahl”-Modus für diese Epoche deaktiviert; diese Feststellung erfolgt durch den Codierer bei der Erstellung jeder CMRx-Nachricht.
3. Wenn ein L2-Code als Referenzcode ausgewählt wird, dann wird entweder L2E oder L1c ausgewählt. Wenn eine L2-Verfolgungsart als Referenzcode ausgewählt wird, geht man davon aus, dass der konfigurierte Referenzcode für alle GPS SV verfügbar ist; und der L2 „Beste Wahl”-Modus wird deaktiviert: d. h. er wird jedes Mal deaktiviert, wenn eine beliebige L2-Verfolgungsart als Referenzcode ausgewählt wird.

Ähnlich wie bei L2 ist eine Einführung von L1c für die GPS-Konstellation geplant. Der „Beste Wahl”-Modus für L1 hat ähnliche Regeln und ist von dem für L2 im CMRx-Codierer unabhängig. Die Durchführung für „L1” ist die gleiche wie für „L2”, der „Beste Wahl”-Modus für L1 wird jedoch nur für die L1 C/A- und L1c-Daten in Betracht gezogen. D. h. dass wenn L1c von einem GPS-Satelliten übertragen wird, die Empfänger eventuell L1 C/A-, L1c- und L1E-Observablen gleichzeitig verfolgen und melden können. Für L1-Daten des Empfängers hat L1E eine spezielle Bedeutung. Mit Bezug auf L1:

1. Der L1 „Beste Wahl”-Modus ist immer deaktiviert, wenn der CMRx-Codierer derart konfiguriert ist: d. h. die übrigen Regeln gelten nicht, wenn der „Beste Wahl”-Modus deaktiviert ist.
2. Wenn die für den CMRx-Codierer bereitgestellten Epochendaten ein SV mit L1E enthalten, dann wird der L1 „Beste Wahl”-Modus nicht verwendet.
3. Wenn die Epochendaten dem CMRx-Codierer zugeführt werden und es wenigsten einen GPS-Satelliten gibt, bei dem sowohl L1 C/A als auch L1c verfügbar sind, wird der L1 „Beste Wahl”-Modus für diese Epoche deaktiviert.
4. Wenn ein L1-Code für den Referenzcode ausgewählt wird, dann wird entweder der L1 C/A-Code, der L1c-Code oder der L1E-Code ausgewählt. Wenn eine L1-Verfolgungsart als Referenzcode ausgewählt wird, geht man davon aus, dass der konfigurierte Referenzcode für alle GPS-SV verfügbar ist; und der L1 „Beste Wahl”-Modus wird für diese Epoche deaktiviert.

e. Ergänzende Beobachtungsverfolgungsinformationen

Die ergänzenden Beobachtungsverfolgungsinformationen stellen zusätzliche Informationen bezüglich der L2c-, L5- und L1c-Beobachtungsarten bereit, soweit diese vorhanden sind. Diese Bits werden verwendet, um die Art der bereitgestellten Codeinformationen anzugeben. Es wird der folgende Lösungsansatz verwendet. Die Werte sind in Basis 2.

Feld	Num. Bits	Wert	Beschreibung
L2c	2	00	CL für L2c
		01	CM für L2c
		10	CM/CL für L2c
		11	Reserviert
L5	2	00	I für L5
		01	Q für L5
		10	I + Q für L5
		11	Reserviert.
L1c	3	000	BOC (1,1) Pilot für L1c
		001	BOC (1,1) Daten für L1c
		010	BOC (1,1) Pilot + Daten für L1c
		011	MBOC (1,1) Pilot für L1c
		100	MBOC (1,1) Daten für L1c
		101	MBOC (1,1) Pilot + Daten für L1c
		110	Reserviert
		111	Reserviert

In der obigen Tabelle gibt es ergänzende Informationsbits für L2c, L5 und L1c. Diese sind in den GPS-Beobachtungsblock-Definitionsbits vorhanden, wenn die Bits der Beobachtungsfolge (d. h. entweder der Referenzcode oder die Bits für L2c, L5 oder L1c) dies angeben. Wenn z. B. die Kombination der Beobachtungsfolgebits angibt, dass L2c und L1c vorhanden sind, dann gibt es nur verknüpfte ergänzende Bits für diese Arten und es gibt keine ergänzenden Bits für L5).
Träger-Rauschverhältnis Präsenzbit, Orbitsbit und SVPRN
Träger-Rausch-(oder Träger-Rauschverhältnis-) und Orbitinformation werden grundsätzlich als unassoziiert angesehen. Um Platz zu sparen, kombiniert CMRx einige Elemente. Träger-Rausch- und eindeutige Orbitalinformation gelten als in CMRx durchgelaufen. Das heißt, es gibt Modi, in denen CMRx nicht versucht, die Daten für jedes SV zu jeder Epoche zu senden. Die Daten werden vielmehr für einen oder mehrere Satelliten – aber nicht für alle – pro Epoche gesendet. Sodann kann man alle Satelliten durchlaufen lassen, während sukzessive Epochen gesendet werden.
Die Bedeutung des CNR-Bits innerhalb der Beobachtungsblockdefinitionsbits (Basis 2) ist:

Bit-Muster CNR-Bedeutung

0 Kein CNR vorhanden.

1 CNR-Daten vorhanden.

Die Bedeutung der ORB-Bits innerhalb der Beobachtungsblockdefinitionsbits ist:

Bit-Muster	ORB-Bedeutung
00	Keine Orbits vorhanden.
01	Referenzmodus Orbits und/oder Taktgeberverschiebung
	vorhanden
10	Relativmodus Orbits und/oder Taktgeberverschiebung
	vorhanden
11	Reserviert

Da Träger-Rausch- und Orbitinformation für diesen Durchlauf kombiniert werden, werden die SV Cnt-Bits in den Beobachtungsblockdefinitionsbits vorhanden sein, wenn entweder die CNR- oder ORB-Bits eingestellt sind; das Vorhandensein von SVPRN-Bits hängt allerdings von dem Wert der Sv Cnt-Bits ab. Der oben beschriebene Durchlauf erfordert diese Identifikation der Satelliten, die mit jeder Epoche durchlaufen werden. Dies wird mit Hilfe von zwei Werten erreicht: Sv Cnt und SVPRN. Sv Cnt, welcher kodiert ist, zeigt die Anzahl der gesendeten SVs an. Die bevorzugten Basis 2 Werte der Sv Cnt sind wie folgt:

Wert Beschreibung

00 Information für Ein SV ist vorhanden

01 Information für 4 SVs vorhanden

10 Information für 8 SVs vorhanden

11 Information für alle SVs vorhanden
Wenn der Sv Cnt-Wert den ALLE SVs-Modus anzeigt (d. h. der Wert ist 112), dann besteht kein Bedarf an der SVPRN-Information. Wenn Sv Cnt ein SV anzeigt, dann identifiziert die Bedeutung von SVPRN den einzelnen Satelliten mit der angezeigten Träger-Rausch- und/oder Orbitinformation. Wenn Sv Cnt mehr als ein SV aber nicht alle SVs anzeigt, dann identifiziert SVPRN den ersten Satelliten, der diese Information aufweist. Da CMRx die Beobachtungen in aufsteigender Reihenfolge je nach Identifikation durch das/die SVPRN Wort/Wörter speichert, sind die IDs der anderen Satelliten bekannt, die die angezeigte Träger-Rausch- und/oder Orbitinformation enthalten. Wenn SV Cnt eine Zahl anzeigt, die größer als die verbleibende Anzahl der SVs in der Nachricht ist, dann wird jedoch das Paketieren oder Entpaketieren der Träger-Rausch- und/oder Orbitinformation angehalten, sobald die höchste ID erreicht wird.
Das CNR-Bit der GPS-Beobachtungsblockdefinitionsbits zeigt an, ob CNR-Daten (d. h. Träger-Rausch-Verhältnisse) in den Beobachtungsdaten vorkommen oder nicht: d. h., ein Wert von 1 zeigt das Vorhandensein an, und 0 zeigt an, dass keine CNR-Daten vorhanden sind. Außerdem zeigen die Werte der Sv Cnt und SVPRN, die auch Teil der Definitionsbits sind, an, welche und wie viele SVs diese Daten aufweisen werden. Für jedes SV, das die Daten enthält, wird die Träger-Rauschinformation als Teil der Daten für jeden Frequenz-/Verfolgungstyp gespeichert.
Ähnlich den Angaben im vorangegangen Abschnitt wird das Vorhandensein von präzisen Orbitdaten durch die Kombination der ORB, SV Cnt und SVPRN-Bits der Beobachtungsblockdefinitionsbits angezeigt. Im Gegensatz zu den CNR-Werten gibt es jedoch lediglich ein Auftreten von präziser Orbitalinformation pro SV bezüglich welcher angezeigt wird, dass sie Orbitinformation aufweist.
Encoder-Auswahl der CNR und ORB-Satelliten
Wenn CNR oder ORB-Daten in einer Nachricht vorhanden sein sollen, benutzt der CMRx-Encoder bei der Auswahl des ersten Satelliten einen „oldest first (ältester zuerst)” genannten Ansatz. Dieser Ansatz berücksichtigt den ersten Satelliten mit Bezug zu den verbleibenden Satelliten. Wenn zum Beispiel das älteste SV 21 ist in der Nachricht, die SVs 1, 2, 5, 7, 10, 12, 18, 21, 23, 24 und 26 enthält und Sv Cnt 8 SVs anzeigt, dann ist SV 7 das als erste SV ausgewiesene, welches SV 21 umfasst.
Der CMRx-Encoder benutzt ein Prioritätsschema, das sich auf die Kombination von ORB und CNR-Daten gründet, die vorhanden sein müssen. Wenn Orbits in der Nachricht einzubeziehen sind, bestimmt er, ob Orbitdaten für die aktuelle Nachricht vorhanden sein sollten. Wenn dann keine Orbits einzubeziehen sind, CNR jedoch einzubeziehen ist, wählt er den ältesten Satelliten aus aufgrund desjenigen Satelliten, der seit CNR-Sendung die längste Zeit aufweist. Wenn somit sowohl CNR als auch Orbits einzubeziehen sind, wird immer der „älteste” Satellit ausgewählt aufgrund der Orbitinformation, deren Sendung am längsten her ist; jedoch sind CNR und Orbit-Daten für jedes SV vorhanden, wie durch Sv Cnt und SVPRN-Bits angezeigt.
Decoder-Handhabung der Satelliten mit CNR und ORB
Wenn ein CMRx-Decoder ein SV mit CNR-Daten trifft, sollte der extrahierte CNR-Wert gehalten werden und dann mit jeder sukzessiv empfangenen/dekodierten Epoche nach vorne prorogiert werden, bis entweder ein Timer ausläuft oder ein neuer CNR-Wert für dieses SV extrahiert wird. Der CMRx-Decoder propagiert diese bis zu 30 Sekunden nach vorne. Dies erfolgt in erster Linie deshalb, weil die CNR-Daten für die Diagnose verwendet werden. Wenn eindeutigere oder zeitnahe Daten benötigt werden, dann werden die Modi der Sv Cnt benutzt, die zu häufigeren Daten führen.
Fortführender Verfolgungszähler Präsenzbits
Die CTC-Präsenzbits der GPS-Beobachtungsblockdefinitionsbits zeigen an, ob fortführende Verfolgungszähldaten in den Beobachtungsdaten vorhanden sind oder nicht. Ein Nicht-Nullwert zeigt das Vorhandensein an, und 0 zeigt an, dass CTCs nicht vorhanden sind. Selbst wenn die CTC-Präsenzbits anzeigen, dass in der Nachricht keine CTC vorhanden sein werden, ist in den Beobachtungsdaten ein Zyklusschlupf-Flag pro SV vorhanden. Das Zyklusschlupfbit zeigt einen Schlupf in mindestens einem Beobachtungstyp an, und jeder Decoder behandelt das als einen Zyklusschlupf bezüglich aller Beobachtungen für diesen SV. Wenn CTC-Präsenzbits das Vorhandensein von CTC-Daten anzeigen, ist der Master-CTC auch in den GPS-Beobachtungsblockdefinitionsbits vorhanden. Der Master-CTC ist ein 6-Bitwert der benutzt wird, um einen Erhebungswinkel zwischen 0 und 90 Grad auszudrücken.
Ziel von CMRx ist die Reduzierung der Anzahl von Bits, die zum Tragen der GNSS-Information erforderlich sind. Dadurch stellt CMRx dem Empfänger eine komprimierte Nachricht zur Verfügung, die genug Information enthält, um es dem Empfänger zu ermöglichen, den Inhalt der Originalquellbeobachtungsdaten zu dekomprimieren und bestimmen.
Es besteht das Problem des Verlusts der Zugriffssperrzähler und der fortführenden Verfolgungszähler, die durch den Empfänger benutzt werden, um Verluste bei der fortführenden Verfolgung zu erlernen. Diese Werte stellen zeitabhängige Information dar. In der Realität treten jedoch im Zuge der Übertragung über verschiedene Medien Verluste und Korruption von Nachrichten auf.
Ein wichtiges Element der Zugriffssperrzähler und der fortführenden Verfolgungszähler besteht darin, dass einige Nachrichtenstrukturen keine Fälle zulassen, bei denen Daten als zyklusschlupffrei markiert werden, wenn die Daten solche enthalten könnten. Für das Beispiel der Berücksichtigung eines fortführenden Verfolgungszählers, der 3 Bits lang ist und sich mit jeder Epoche erhöht solange die Verfolgung beibehalten wird (jedoch anhält, wenn der Wert 7 erreicht), bedeutet das, dass er sich auf 0 zurücksetzt sobald die Verfolgung nicht fortführend ist. Wenn weiterhin ein Epochenintervall von 1 Sekunde angenommen wird, erreicht der Zähler dementsprechend einen Wert von 7 in 8 Sekunden ab dem ersten Nullwert. Der Zähler verbleibt sodann bei 7 solange die Verfolgung beibehalten wird. Um ein Problem bei einem derartigen Ansatz vom Standpunkt der Nachricht hervorzuheben, sei angenommen, dass man eine Radioverbindung hat und dass der Zähler auf 7 stand, kurz bevor man die Kommunikation verlor und dass er auf 7 stand, als die Kommunikation nach 3 Sekunden wieder hergestellt wurde. In diesem Fall gab es keine Zyklusschlupfe bei den Ausgangsbeobachtungen, obwohl wir nicht alle Epochen der Daten empfangen haben. Unter der nunmehrigen Annahme, dass der Kommunikationsausfall 9 Sekunden oder länger dauerte, können wir keine Annahmen bezüglich der Kontinuität der Daten machen. Der GNSS-Empfänger könnte beispielsweise die Verfolgung sofort verloren und diese dann 0,5 Sekunden später wieder aufgenommen haben.
Der Ansatz des fortführenden Verfolgungszählers (CTC), der innerhalb CMRx benutzt wird, löst die oben erhobenen Bedenken. Insbesondere reduziert er die Anzahl der Gesamtbits, wobei sogar in schlechten Umgebungen gute Information erteilt wird. Der CTC stellt genug Information bezüglich der fortführenden Verfolgung bereit, um Kommunikationsausfälle zu überbrücken, reduziert jedoch die Anzahl der erforderlichen Bits. In den Fällen, in denen die fortführende Verfolgung nicht eindeutig ist, muss das Dekodierungsverfahren das Schlimmste annehmen und die Daten so markieren, als ob sie einen Zyklusschlupf erfahren hätten.
Die Größe und Bedeutung des CTC-Werts hängt von der Dynamik des CMRx-Encoders ab. Die Dynamik wird durch das KIN-(oder kinematische)Flag im Headerblock der CMRx-Beobachtungsdatennachrichten angezeigt. Sowohl die Größe als auch die Bedeutung der CTC-Daten hängen von dem Status des KIN-Flag ab.
Es gibt zwei CTC-Indikatoren in CMRx, unabhängig vom statischen oder dynamischen Bewegungsindikator im Headerblock, die annehmen, dass die CTC-Präsenzbits der GPS-Beobachtungsblockdefinitionsbits anzeigen, dass CTCs vorhanden sind. Im Folgenden wird die CTC-Umsetzung beschrieben.
Master-CTC
Der Master-Indikator ist ein Erhebungswert, der am Anfang des Beobachtungsdatenblocks der Nachricht vorkommt. Diese Zahl wird durch den CMRx-Decoder benutzt, um zu bestimmen, welcher der Satelliten für mindestens X Minuten fortführend verfolgt wurde, wobei der Wert von X aufgrund des statischen oder dynamischen Modus unterschiedlich ausfallen kann. Daher kennt der CMRx-Decoder die genaue Liste der SVs, für welche über X Minuten Kontinuität beibehalten wurde. Der Master-CTC wird über alle Frequenzen und Verfolgungsschleifen angewendet, die für die inklusive Satellitenfolge berichtet werden, die unter Benutzung des Master-CTC entwickelt wurde. Dies ermöglicht dem CMRx-Decoder, sich aus der Funkabdeckung zu begeben oder über X Minuten keine guten Nachrichten aufzuweisen und zu wissen, welche Satelliten die Zugriffssperre beibehalten haben.
Bei einer Ausführung ist es jedoch wünschenswert, Abrundungsfehler aufgrund leichter Präzisionsunterschiede in dem CMRx-Encodergerät bezüglich Satellitenerhebungsberechnungen zwischen denjenigen zu vermeiden, die an der Grundlinie berechnet wurden im Vergleich zu denjenigen, die am CMRx-Decoder berechnet wurden. Um solche Komplikationen zu vermeiden, wird während des Dekodierungsverfahrens mindestens 1 Grad zu der zu diesem Zweck berechneten Erhebung hinzugerechnet. Außerdem kann der Master CTC-Indikator den Wert 90 speichern. Wenn dieses Flag 90 Grad anzeigt, gibt es keine Satelliten, die dieses Erfordernis der X Minuten dauernden fortführenden Verfolgung erfüllen. Dies ermöglicht während dem Dekodieren, dass bekannt ist, welche Satelliten über X Minuten fortführende Verfolgung beibehalten haben. Daher weiß der CMRx-Decoder genau, welche Satelliten während der Ausfallperiode keine Zyklusschlupfe aufwiesen, wenn ein Kommunikationsausfall für einen weniger als X Minuten dauernden Zeitraum besteht. Auf der anderen Seite nimmt der CMRx-Decoder Verlust der Kontinuität an und markiert alle Satelliten, als ob sie Kontinuitätsverlust erfahren hätten, wenn der Kommunikationsverlust für mehr als X Minuten besteht.
Minor-CTC
Das/die Minor-CTC-Bit(s) ist/sind auf allen Satelliten und Frequenzen vorhanden. Dieses Flag stellt Indikationen für fortführende Verfolgung für keine oder sehr kurze Kommunikationsausfälle bereit. Es sei angenommen, dass das Minor-CTC ein Ein-Bit-Flag sei, die 1 wird, sobald ein Satellit für 16 Sekunden fortführend verfolgt wurde. Es sei weiterhin angenommen, dass sie sich bei jedem Zyklusschlupf, der durch den Empfänger berichtet wurde, auf Null zurückstellt. Daher können Kommunikationsausfälle über einen kurzen Zeitraum von weniger als 16 Sekunden vorliegen, und daher ist bekannt, welche Satelliten über diesen Ausfallzeitraum verfolgt wurden. Wenn der Ausfall insbesondere weniger als 16 Sekunden betrug und das Minor-CTC vor und nach dem Ausfall einen Wert von 1 hatte, dann behielt dieser Satellit über diesen Zeitraum die fortführende Verfolgung bei. Wenn sich das Minor-CTC vor oder nach dem Ausfall von 1 auf 0 änderte, dann ist Verlust der Kontinuität anzunehmen. Obwohl dies keine Lücken handhabt, die größer als 16 Sekunden sind, können die Master-CTC helfen. Für diejenigen Korruptions-/Ausfallperioden, die länger als 16 Sekunden dauern, listen die Master-CTC diejenigen Satelliten auf, die über diesen Zeitraum die Zugriffssperre beibehalten haben.
Major- und Minor-CTC-Zusammenspiel:
Die oben dargestellte Kombination der Major- und Minor-CTC-Werte führt während der Inbetriebnahme zu einem hochgradigen Anfälligkeitszeitraum von 16 Sekunden. Das bedeutet, dass – wenn von einem CMRx-Encoder an einen CMRx-Decoder Daten berichtet werden – wenn diese Quelle anfangs angestellt wird, sie keine fortführende Verfolgung über die ersten 16 Sekunden annehmen kann. Insbesondere wird der Master-CTC auf 90 Grad eingestellt, und alle Minor-CTCs werden auf Null eingestellt. Der CMRx-Decoder nimmt an, dass die Verfolgung nicht fortführend war. Weiterhin besteht Anfälligkeit für Kommunikationsausfallperioden jenseits der Größe des Master-CTC. Wenn der CMRx-Decoder keine Nachrichten vom CMRx-Encoder innerhalb des Zeitraums des Master-CTC empfängt, dann nimmt er an, dass die fortführende Verfolgung nicht beibehalten wurde. Alle Satelliten werden so behandelt, als hätten sie einen Zyklusschlupf erfahren.
Eine weitere Anfälligkeit tritt auf, wenn sich der CMRx-Encoder in einem Bereich befindet, der schlechte oder teilweise blockierte Verfolgung bereitstellt. Man betrachte zum Beispiel eine Referenzstation in der nördlichen Hemisphäre, die sich an einem Standort befindet, der eine hohe Erhebungshemmung nach Süden aufweist. Über bestimmte Tagesabschnitte stellt der Master-CTC begrenzte Versorgung bereit, weil die Anzahl der Satelliten über der durch den Master-CTC angezeigten Anzahl zur Überbrückung des über einen Kommunikationsausfall angetroffenen Zyklusschlupfs möglicherweise nicht ausreicht. Eine weitere Anfälligkeit tritt bei der Inbetriebnahme aufgrund des Zusammenspiels der Master- und Minor-CTC auf. So besteht beispielsweise – wenn 1 Bit Minor-CTC 16 Sekunden bedeutet, wenn es eingestellt ist und ein Master-CTC 10 Sekunden bedeutet – ein Unsicherheitszeitraum, wenn Datenverlust für mehr als 16 Sekunden eintritt. In diesem Fall war der CMRx-Encoder nicht lange genug an, um den 10 Minuten Master-CTC zu erreichen. Daher muss jeder CMRx-Decoder, der während dieser Inbetriebnahme für mehr als 16 Sekunden Nachrichten verliert, Zyklusschlupfe annehmen.
Minor-CTC-Verbesserung

Um die oben beschriebene Anfälligkeit zu reduzieren, stellt CMRx eine besondere Bedeutung der Trägerphasenobservablen innerhalb der CMRx Nachrichten bereit. Um einem „schlechten Flag” die Interpretation der oben beschriebenen Single-Bit Minor-CTC zu geben, bei dem ein Single-Bit Minor-CTC-Wert von 0 oder 1 eine Verfolgung von 60 Sekunden unterstellt, sollte die folgende Tabelle betrachtet werden:

Minor-CTC-Wert [Basis 2]	Träger markiert (gut/schlecht)	Bedeutung
0	Schlecht	Schlupf bei der Trägerbeobachtung dauert 4 Sekunden
0	Gut	Empfänger hat Zugriffssperre für mindestens 4 Sekunden beibehalten
1	Gut	Empfänger hat Zugriffssperre für mindestens 60 Sekunden beibehalten
1	Schlecht	Einfach eine schlechte Trägerbeobachtung: D. h. es ist zum Zwecke der Markierung des Zyklusschlupfs egal, ob der Träger gut oder schlecht ist.

Verbesserte statische 1-Bit Minor-CTC
Obige Tabelle gilt nur für diejenigen SVs, die nicht durch den Major-CTC abgedeckt sind. Daher zeigt der CMRx-Decoder einen Zyklusschlupf an, immer wenn er die Minor-CTC = 0 und schlechte Trägermarkierung antrifft. Wenn die Minor-CTC = 0 und der Träger als gut markiert ist, hat der Empfänger für mindestens 4 Sekunden verfolgt. Das bedeutet, dass wenn der Decoder eine Nachrichtenlücke von weniger als 4 Sekunden aufweist, er klar versteht, ob ein Schlupf während der Nachrichtenlücke vorlag. Wenn der Minor-CTC = 1, bedeutet dies, dass der Empfänger die Zugriffssperre für mindestens 60 Sekunden beibehalten hat.
CTC in GPS-Beobachtungsblockdefinitionsbits
Als nächstes wird die CMRx-Umsetzung des CTC beschrieben. Die CTC-Präsenzbits innerhalb der GPS-Beobachtungsblockdefinitionsbits erfüllen zwei Zwecke: (1) Anzeige, ob CTC in Betrieb ist und (2) Anzeige der Anzahl der im Minor-CTC benutzten Bits. Immer wenn der CTC benutzt wird, besteht ein Major-CTC. Wenn die zwei Bits für CTC-Präsenz auf 002 eingestellt sind, dann ist kein CTC in der Nachricht vorhanden. In diesem Fall gibt es ein einziges Zyklusschlupf-Flag für jedes SV, das auf alle Frequenz-/Verfolgungstypträgerobservablen dieses Satelliten anzuwenden ist.
Wenn CTC-Präsenzbits nicht Null sind, dann werden in dem CMRx-Encoder und Decoder Nachschlagetabellen verwendet, um die Anzahl der verwendeten Bits und die Bedeutung der mit jedem Satelliten assoziierten Minor-CTC zu bestimmen. Diese Nachschlagetabellen unterscheiden sich je nach dem Wert des KIN-Flags (unten diskutiert) des GPS-Beobachtungs-Headerblocks.
Statische Quelle
Wenn der CMRx-Encoder ein statischer Standort ist, bezieht sich der Master-CTC auf diejenigen Satelliten, die über die letzten 10 Minuten die Zugriffssperre beibehalten haben. Der Master-CTC ist eine Zahl, die in 6 Bits gespeichert ist. Das niedrigstwertige Bit, das ungefähr äquivalent zu 1,421875 Grad ist: d. h. 91/2^6 bei 91 in der Berechnung, wird ausschließlich alle Winkel von 0 bis 90 handhaben. Wenn alle Bits auf 1 eingestellt werden (d. h. das Muster ist 111111₂) bedeutet das 90 Grad und dass keine Satelliten über die letzten 10 Minuten verfolgt wurden.
Die Minor-CTC-Größen und Bedeutungen basieren darauf, ob die CTC-Präsenzbits der Beobachtungsblockdefinitionsbits Null sind. Sind sie Null, sind in der Nachricht keine Major- oder Minor-CTC-Bits vorhanden. Anstatt dessen ist ein einzelnes Zyklusschlupf-Flag auf einer pro-Satellit-Basis vorhanden. Dieses Flag gilt für die Träger aller Frequenz-/Verfolgungstypen für diesen Satelliten. Sie wird auf 1 eingestellt ist, wenn ein Zyklusschlupf zwischen einer Epoche und der vorherigen, in CMRx gesendeten, auftritt. Wenn die CTC-Präsenzbits der Beobachtungsblockdefinitionsbits einen Nicht-Nullwert speichern, bestimmen die Nachschlagetabellen die Größe und Bedeutung jedes Minor-CTC, der mit jedem Trägerfrequenz-/Verfolgungstyp assoziiert ist.
Statische Minor-CTC wenn CTC-Präsenz 01 ist

Wenn die zwei Bits der CTC-Präsenzbits innerhalb der GPS-Beobachtungsblockdefinitionsbits einen Wert von 01 haben (und das KIN-Bit des GPS-Beobachtungs-Headerblocks eine statische Quelle anzeigt), dann liegt ein Minor-CTC-Bit bei jedem Trägerfrequenz-/Verfolgungstyp vor, wie unten gezeigt.

Minor-CTC-Wert [Basis 2]	Träger markiert (gut/schlecht)	Bedeutung
0	Schlecht	Schlupf bei der Trägerbeobachtung in den letzten 4 Sekunden
0	Gut	Empfänger hat Zugriffssperre über mindestens 4 Sekunden beibehalten
1	Gut	Empfänger hat Zugriffssperre über mindestens 60 Sekunden beibehalten
1	Schlecht	Eine schlechte Beobachtung

Statische Minor-CTC wenn CTC-Präsenz 10 ist

Wenn die zwei CTC-Präsenzbits innerhalb der GPS-Beobachtungsblockdefinitionsbits einen Wert von 10 haben (und das KIN-Bit des GPS-Beobachtungs-Headerblocks eine statische Quelle anzeigt), dann liegt ein 2-Bit Minor-CTC bei jedem Trägerfrequenz-/Verfolgungstyp vor, wie unten gezeigt.

Minor-CTC-Wert [Basis 2]	Träger markiert (gut/schlecht)	Bedeutung
00	Schlecht	Schlupf bei der Trägerbeobachtung dauert mindestens 4 Sekunden
00	Gut	Empfänger behielt Zugriffssperre auf SV für 4 Sekunden bei
01	X	Empfänger hat Zugriffsperre für mindestens 8 Sekunden beibehalten (es ist zum Zwecke der Markierung des Zyklusschlupfs egal, ob der Träger gut oder schlecht ist)
10	X	Empfänger hat Zugriffsperre für mindestens 16 Sekunden beibehalten (es ist zum Zwecke der Markierung des Zyklusschlupfs egal, ob der Träger gut oder schlecht ist).
10	X	Empfänger hat Zugriffsperre für mindestens 32 Sekunden beibehalten (es ist zum Zwecke der Markierung des Zyklusschlupfs egal, ob der Träger gut oder schlecht ist).

Das obige Bit-Muster wird benutzt zur Beschreibung der Dauer der fortführenden Verfolgung eines einzelnen Satelliten und Frequenz-/Verfolgungsschleife. Als Beispiel für die Versorgung sei angenommen, dass der CMRx-Decoder über 15 Sekunden keine Nachrichten empfängt. Wenn der Minor-CTC auf 10 eingestellt war [Basis 2] auf der letzten Nachricht kurz vor dem Kommunikationsverlust und dann auf 01 gestellt wurde, als die Kommunikation wieder hergestellt wurde, dann wurde die fortführende Verfolgung nicht eingehalten. Wenn der Minor-CTC auf 10 eingestellt war, als die Kommunikation wiederhergestellt wurde, dann war die Verfolgung jedoch fortführend über den Zeitraum des Kommunikationsverlusts.
Statische Minor-CTC wenn CTC-Präsenz 11 ist

Wenn die zwei CTC-Präsenzbits innerhalb der GPS-Beobachtungsblockdefinitionsbits einen Wert von 11 haben (und das KIN-Bit des GPS-Beobachtungs-Headerblocks eine statische Quelle an zeigt), dann liegt ein 2-Bit Minor-CTC bei jedem Trägerfrequenz-/Verfolgungstyp vor, wie unten gezeigt.

Minor-CTC-Wert [Basis 2]	Träger markiert (gut/schlecht)	Bedeutung
00	Schlecht	Schlupf bei der Trägerbeobachtung in den letzten 8 Sekunden
00	Gut	Empfänger behielt Zugriffssperre auf SV für 8 Sekunden bei
01	X	Empfänger hat Zugriffsperre für mindestens 16 Sekunden beibehalten (es ist zum Zwecke der Markierung des Zyklusschlupfs egal, ob der Träger gut oder schlecht ist).
10	X	Empfänger hat Zugriffsperre für mindestens 32 Sekunden beibehalten (es ist zum Zwecke der Markierung des Zyklusschlupfs egal, ob der Träger gut oder schlecht ist).
10	X	Empfänger hat Zugriffsperre für mindestens 64 Sekunden beibehalten (es ist zum Zwecke der Markierung des Zyklusschlupfs egal, ob der Träger gut oder schlecht ist).

Kinematische Quelle
Wenn der CMRx-Encoder ein dynamischer Standort ist (beweglich), bezieht sich der Master-CTC auf diejenigen Satelliten, die über die letzten 10 Minuten die Zugriffssperre beibehalten haben. Die Minor-CTC-Größe und Bedeutung gründet sich in erster Linie darauf, ob die CTC-Präsenzbits der Beobachtungsblockdefinitionsbits Null sind oder nicht Null. Wenn sie Null sind, sind in der Nachricht keine Major- oder Minor-CTC-Bits vorhanden. Anstatt dessen ist ein einzelnes Bit Zyklusschlupf-Flag auf einer pro-Satellitenbasis vorhanden. Dieses Flag gilt für Träger aller Frequenz-/Verfolgungstypen für diesen Satelliten. Sie wird auf 1 eingestellt, immer wenn zwischen dieser Epoche und der vorherigen, in CMRx gesendeten, ein Zyklusschlupf auftritt. Wenn CTC-Präsenzbits der Beobachtungsblockdefinitionsbits einen Nicht-Nullwert speichern, bestimmen die Nachschlagetabellen die Größe und Bedeutung jedes Minor-CTC, der mit jedem Trägerfrequenz-/Verfolgungstyp assoziiert ist. Diese werden in den folgenden Tabellen beschrieben.
Kinematische Minor-CTC wenn CTC-Präsenz 01 ist

Wenn die zwei Bits der CTC-Präsenzbits innerhalb der GPS-Beobachtungsblockdefinitionsbits einen Wert von 01 haben [Basis 2] (und das KIN-Bit des GPS-Beobachtungs-Headerblocks eine kinematische Quelle anzeigt), dann liegt ein 3-Bit Minor-CTC-Bit bei jedem Trägerfrequenz-/Verfolgungstyp vor, wie unten gezeigt.

Minor-CTC-Wert [Basis 2]	Träger markiert (gut/schlecht)	Bedeutung
000	Schlecht	Schlupf bei der Trägerbeobachtung in der letzten 1 Sekunde
000	Gut	Empfänger hat Zugriffsperre für mindestens 1 Sekunde beibehalten
001	X	Empfänger hat Zugriffsperre für mindestens 2 Sekunden beibehalten
010	X	Empfänger hat Zugriffsperre für mindestens 4 Sekunden beibehalten
011	X	Empfänger hat Zugriffsperre für mindestens 8 Sekunden beibehalten
100	X	Empfänger hat Zugriffsperre für mindestens 16 Sekunden beibehalten
101	X	Empfänger hat Zugriffsperre für mindestens 32 Sekunden beibehalten
110	X	Empfünger hat Zugriffsperre für mindestens 64 Sekunden beibehalten
111	X	Empfänger hat Zugriffsperre für mindestens 128 Sekunden beibehalten

Kinematische Minor-CTC wenn CTC-Präsenz 10 ist

Wenn die zwei Bits der CTC-Präsenzbits innerhalb der Beobachtungsblockdefinitionsbits einen Wert von 10 haben [Basis 2] (und das KIN-Bit des GPS-Beobachtungs-Headerblocks eine kinematische Quelle anzeigt), dann liegt ein 2-Bit Minor-CTC-Bit bei jedem Trägerfrequenz-/Verfolgungstyp vor, wie unten gezeigt.

Minor-CTC-Wert [Basis 2]	Träger markiert (gut/schlecht)	Bedeutung
00	Schlecht	Schlupf bei der Trägerbeobachtung in den letzten 4 Sekunden
00	Gut	Empfänger hat Zugriffsperre an SV für 4 Sekunden beibehalten
01	X	Empfänger hat Zugriffsperre für mindestens 8 Sekunden beibehalten
10	X	Empfänger hat Zugriffsperre für mindestens 16 Sekunden beibehalten
10	X	Empfänger hat Zugriffsperre für mindestens 32 Sekunden beibehalten

Kinematische Minor-CTC wenn CTC-Präsenz 11 ist

Wenn die zwei Bits der CTC-Präsenzbits innerhalb der GPS-Beobachtungsblockdefinitionsbits einen Wert von 11 haben [Basis 2] (und das KIN-Bit des GPS-Beobachtungs-Headerblockses eine kinematische Quelle anzeigt), dann liegt ein 3-Bit Minor-CTC-Bit bei jedem Trägerfrequenz-/Verfolgungstyp vor, wie unten gezeigt.

Minor-CTC-Wert [Basis 2]	Träger markiert (gut/schlecht)	Bedeutung
000	Schlecht	Schlupf bei der Trägerbeobachtung in den letzten 0,5 Sekunden
000	Gut	Empfänger hat Zugriffsperre an SV für 0,5 Sekunden beibehalten
001	X	Empfänger hat Zugriffsperre für mindestens 1 Sekunde beibehalten
010	X	Empfänger hat Zugriffsperre für mindestens 2 Sekunde beibehalten
011	X	Empfänger hat Zugriffsperre für mindestens 4 Sekunde beibehalten
100	X	Empfänger hat Zugriffsperre für mindestens 8 Sekunde beibehalten
101	X	Empfänger hat Zugriffsperre für mindestens 16 Sekunde beibehalten
110	X	Empfänger hat Zugriffsperre für mindestens 32 Sekunde beibehalten
111	X	Empfänger hat Zugriffsperre für mindestens 64 Sekunde beibehalten

Orbit-Hauptblock
CMRx-Orbits haben zwei Hauptmodi und zwei Schlüsselelemente. Die zwei Hauptmodi werden grob gesprochen als „Referenzmodus” und „Relativmodus” bezeichnet. Die beiden Schlüsselelemente, die als Teil der Orbitdaten getragen werden, sind: (a) Satellitenpositionen und (b) Satellitenuhrdaten (die sich auf die Satellitenuhrfehler beziehen). Die Mischung der Elemente, die in einer einzelnen Nachricht enthalten sind, ist optional und gründet sich auf die Applikationsbedürfnisse. Weiterhin kann der Orbitmodus zwischen den CMRx-Nachrichten wechseln. So sendet man beispielsweise den Referenzmodus Orbits und Taktgeber alle 15 Sekunden und den Referenzmodus Taktgeber alle 5 Sekunden.
Ehe jeder Modus beschrieben wird, ist eine Diskussion bezüglich der grundsätzlichen Konzepte des Referenzmodus im Gegensatz zum Relativmodus angebracht. Wir werden außerdem Nachrichtendauertags beschreiben, die sich auf Orbit-/Taktdaten beziehen. Weiterhin müssen außerdem Begriffe vorgestellt werden, die mehrdeutige Daten beschreiben.
Der Referenzmodus ist ein Modus, in dem vollständigere Daten gesendet werden. Sie sind dadurch vollständiger, dass deren Versenden nicht von der Übertragung weiterer Daten abhängt. In diesem Modus können lediglich langsame Uhr, lediglich langsame Satellitenpositionen oder beides bestehen. Bei sowohl dem Referenzmodus als auch dem Relativmodus werden Daten zur Präzisierung der Orbits gesendet. Der Unterschied liegt lediglich in der Größe der Ambiguität und der Auflösung. Im Relativmodus besteht eine höhere Auflösung, um den compoundierenden Quantisierungseffekt zu reduzieren. Für den Relativmodus werden weniger Bits benötigt, und es wird normalerweise eine höhere Auflösung benutzt.
Bei der Betrachtung der Orbits und Satellitenuhrfehler besteht ein Bedürfnis danach, eine Referenzzeit dieser Daten zu kennen. In den CMRx-Beobachtungsnachrichten reflektiert das Zeitdauertag im Header die Epochenzeit. Für die Satellitenbeobachtungsdaten innerhalb der Nachricht bedeutet diese Zeit den Zeitpunkt des Empfangs. Die in derselben Beobachtungsnachricht enthaltenen Orbitdaten werden jedoch derart berechnet, dass die Satellitenpositionen und Taktgeber die im Header angezeigt Zeit angeben. Für CMRx-Satelliten-Taktgeber werden relativistische Korrekturen je nach Anwendung betrachtet. Es werden keine Sagnac-Korrekturen benötigt, da sich der Rahmen der CMRx-Orbitpositionen auf die Satelliten bezieht und die Erdrotation ignoriert.
Die Begriffe angestoßene Orbits, angestoßene Taktgeber oder angestoßene Orbits/Taktgeber beziehen sich auf – und werden beschrieben von Dr. Benjamin Remondi in den US-Patent Anmeldungen mit dem Titel „Conveying Orbit Information via Ambiguous Position Information” (Übertragung von Orbitinformation über mehrdeutige Positionsinformationen), Seriennummer 12/008893, eingereicht am 16. Januar 2008 und „Nudged Broadcast Orbit Drift Correction” (Angestoßene Broadcast-Orbitabdriftkorrektur), Seriennummer 12/136536, eingereicht am 10. Juni 2008, deren Inhalte hiermit durch Bezugnahme Teil dieser Beschreibung sind. Diese Patentanmeldungen beschreiben ein Verfahren, bei dem eine Anpassung eines übertragenen Orbits und/oder dessen Uhrdaten vorgenommen werden, um die ephemerischen Elemente einzupassen. Man kann beispielsweise durch Empfang eines präzisen Orbits mit der ephemerischen Position X, Y und Z einen übertragenen Orbit anpassen, um die präzisen Orbitdaten besser an die Zeit der ephemerischen Daten X, Y und Z anzupassen. Durch den Empfang zweier solcher ephemerischer Punkte (bevorzugterweise zeitlich getrennt, oft bis zu 30 Sekunden) können durch dieses Anstoßverfahren Abdriftungen ausgewiesen werden. Dieser Ansatz ermöglicht es, einen angestoßenen Orbit für eine Minute zu benutzen, ohne eine große Trennung zwischen dem tatsächlichen präzisen Orbit und der Satellitenposition zu sehen, die unter Benutzung des angestoßenen Orbits errechnet wurde. Dasselbe Verfahren kann auf die Taktgeber angewendet werden.
Der Begriff Einzel-Anstoß (Single-nudged) wird zur Beschreibung des übertragenen angestoßenen Orbits benutzt, basierend auf dem Empfang von lediglich einer präzisen ephemerischen Nachricht oder zu viel Zeitverlauf zwischen dem Empfang von zweien. Der Begriff Doppelt-Anstoß (double-nudged) wird zur Beschreibung des übertragenen angestoßenen Orbits benutzt, basierend auf dem Empfang von mindestens zwei präzisen ephemerischen Nachrichten. Der Referenzmodus wird normalerweise für die allererste präzise ephemerische Nachricht benötigt und wird dazu benutzt, einen Einzel-Anstoßorbit und/oder eine Einzel-Anstoßuhr zu erzeugen. Der Referenzmodus oder Relativmodus kann dann zur Erzeugung der Doppelt-Anstoßdaten benutzt werden.
Es besteht ein Konzept für mehrdeutige Daten. Betrachten wir lediglich die X-Komponente der Satellitenposition im Referenzmodus. Der CMRx-Encoder kann den präzisen Orbit-X-Wert auf beispielsweise 1000 Meter „fmod”en und den Restbetrag-Rx (den mehrdeutigen Wert) in der Nachricht halten. Mit anderen Worten, die Position ist der Restbetrag des präzisen Orbit-X-Werts, wenn er durch 1000 geteilt wird. Der Decoder hat die präzisen Orbits nicht, hat aber die übertragenen Orbits. Es liegt auf der Hand, dass die übertragenen Orbits besser als 1000 Meter sind, sodass der Decoder die Position des Satelliten von den übertragenen Orbits errechnet und dann diesen Wert auf 1000 Meter kürzt. (d. h. BasisX = Boden (X/1000,0)·1000,0). Einfach ausgedrückt, erhält der Decoder dann die rekonstruierten Werte als BasisX + Rx.
Der tatsächliche Algorithmus für die Rekonstruktion berücksichtigt jedoch die Unterschiede, die möglicherweise zwischen den Berechnungen am Encoder und denen am Decoder bestehen (wie z. B. die übertragenen IODE-Unterschiede zwischen dem Encoder und Decoder). Als solcher setzt der Decoder tatsächlich eine for-Schleife um und passt in jeder Iteration BasisX um 1000,0 Meter an und stellt sicher, dass 1000,0 Mehrfachwerte ober- und unterhalb des Anfangswerts von BasisX durch Betätigung der for-Schleife umfasst werden und hält an, wenn BasisX + Rx innerhalb von 500,0 Metern des errechneten übertragenen Orbitwerts liegen.
Der Encoder nimmt für die Relativmodusorbits und -Taktgeber an, dass der Decoder mindestens einen Einzel-Anstoßorbit aufweist. In dem Beispiel wurde ein Basiswert von 1000,0 Meter benutzt, um diesen mehrdeutigen Wert zu bilden. In CMRx kann jedoch der Basiswert unterschiedlich gewählt werden und wird als „Ambiguitätsfenster” bezeichnet. Weiterhin wird die Ambiguitätsgröße des Relativmodus kleiner sein (d. h. Reduzierung der Anzahl von Bits die erforderlich sind, um Relativmodusdaten zu senden), weil wir annehmen, dass im Relativmodus das Ambiguitätsausflösungsverfahren durch den Decoder Zugriff auf mindestens Einzel-Anstoßorbits und/oder Einzel-Anstoß-Taktgeber haben wird.
Auswahl der ältesten Satelliten zuerst (Oldest-First)
Die Auswahl „älteste zuerst” wurde im Zusammenhang mit der Bezugnahme auf SVs beschrieben, die für CNR- und Orbitdateneinbezugnahme in die CMRx-Nachricht in Erwägung gezogen wurde. Orbitdaten haben Priorität vor CNR-Daten, weil die Orbitdaten als lebensnotwendiger angesehen werden als die CNR-Daten. Der CMRx-Encoder ist mit einer Referenzmodusrate, einer Relativmodusrate und der Anzahl erwünschter SVs pro Nachricht/Epoche konfiguriert.
Die Referenzmodusrate ist typischerweise seltener als die des Relativmodus. Man kann beispielsweise die Referenzmodusrate bei 12 Sekunden und den Relativmodus bei 6 Sekunden konfigurieren. Angesichts der Tatsache, dass 12 ein Mehrfaches von 6 ist, scheinen die Relativmodusdaten mit den Referenzmodusdaten in Konflikt zu stehen. Tritt ein solcher Konflikt auf, wählt der CMRx-Encoder den Referenzmodus und nicht den Relativmodus aus. Die Referenzmodusdaten und Relativmodusdaten koexistieren nicht in derselben Nachricht. Daher sucht der CMRx-Encoder zunächst nach der ältesten Zeit der zuvor gesendeten Referenzmodusdaten in Bezug zur Laufzeit. Wenn er feststellt, dass diese ältesten Daten der spezifizierten Referenzmodusrate gleichen oder diese überschreiten, dann wählt er dieses SV als das „älteste” und zeigt an, dass Referenzmodusdaten benutzt werden. Er durchläuft dann dasselbe Verfahren für den Relativmodus. Wenn er am Ende keine „ältesten” Satelliten findet, an die er entweder im Referenz- oder Relativmodus berichten kann, berichtet er an das „älteste” Satellitenauswahlverfahren, dass er für die Orbitdaten keine (Satelliten) hat. Dieses Satellitenauswahlverfahren kann dann, wenn der CNR-Outputmodus ausgewählt ist, die ältesten CNR-Daten finden).
Orbit-Majordaten
Wie beschrieben, gibt es „Major-” und „Minor-”Orbit-/Uhrdatenelemente. Diese Elemente im Orbitmajorblock beziehen sich auf alle SVs, die innerhalb der Nachricht Orbit-/Uhrdaten aufweisen. Die SV-Minor-Orbitdaten sind Informationen, die sich auf spezifische SVs innerhalb des Beobachtungsdatenblocks der Nachricht beziehen. Dieser Abschnitt beschreibt die Major-Orbitdaten sowohl für den Referenzmodus als auch den Relativmodus: ,Orbit-/Uhrinformation in der Nachricht vorhanden'. Das heißt, es wird die Information beschrieben, die auf alle SVs anzuwenden ist, die Orbitdaten innerhalb der Nachricht aufweisen.
Die Major-Orbitdaten zeigen an, welche Elemente bereit zu stellen sind (d. h. Orbit XYZ und/oder Taktgeber) sowie deren Größe und Präzisionsstufe für alle Satelliten, die Orbitdaten aufweisen. Wie oben erklärt, beschreiben die Sv Cnt und SVPRN-Bits der Beobachtungsblockdefinitionsbits, welche Satelliten diese Orbitalelemente in den Minor-Orbitdaten aufweisen werden. Welche Elemente bereit gestellt werden, Präzisionsstufe und Größen werden alle unter Benutzung des CMRx-Encoders durch die Applikation spezifiziert. Die „welche Elemente werden bereitgestellt” und „Präzisionsstufe” sind applikationsabhängig. Die Präzision der PPP Orbits/Taktgeber ist beispielsweise grundsätzlich höher als die für eine RTK-Typ Applikation benötigte: d. h. die Differential-Orbitalgenauigkeitsbedürfnisse sind viel geringer als die in einem PPP-Fall benötigten. Daher ermöglicht der CMRx-Encoder dem Benutzer, diese Konfigurationen einzustellen. Die „Ambiguitätsfenstergröße” kann auch als Teil der Konfiguration eingestellt werden.
Angenommen, ein Netzwerk von GNSS-Empfängern ist beispielsweise zur Errechnung und Bestimmung der präzisen Orbits einsatzbereit, die es an einen/mehrere Benutzer übertragen möchte. Angenommen weiterhin, dieses Netzwerk ist seit einem Jahr in Betrieb. Dieses Netzwerk könnte den Maximalunterschied zwischen jedem übertragenen Orbit und den präzisen Orbits bestimmen (unter Berücksichtigung von Überschneidungen bei den IODE-Änderungen). Um das Verfahren zu beginnen, zieht man jedoch eventuell in Erwägung, die anfängliche Ambiguitätsgröße auf einen größeren Wert einzustellen. Dieser könnte dann die Ambiguitätsfenstergröße demgemäß spontan verändern (etwa 2 mal die Größe des maximal beobachteten Delta). Auf diese Art und Weise kann das Netzwerk die Ambiguitätsfenstergrößen konstant anpassen, um die Bandbreite optimal zu nutzen, während die Inbetriebnahme geschützt ist. Die Major-Orbitdaten benutzen das in 26 gezeigte Format.
Die grundsätzliche Bedeutung/Interpretation der Bits für die Major-Orbitdaten des Referenzmodus und Relativmodus ist grundsätzlich dieselbe. Die Diskussion über beide ist in den folgenden Unterabschnitten zu finden.
Referenzmodus Major-Orbitdaten

Die Tabelle unten zeigt die Elemente des Major-Orbitblocks für den Referenzmodus auf.

Element	Bits	Beschreibung
XYZs vorhanden	1	Wenn auf 1 eingestellt, sind in den SV Minor-Orbitdaten Satellitenpositionen (XYZs) für jeden bezeichneten Satelliten vorhanden. Ein Wert von 0 bedeutet, dass die SV Minor-Orbitdaten keine Satellitenpositionen aufweisen.
Uhr vorhanden	1	Wenn auf 1 eingestellt, sind in den SV Minor-Orbitdaten Satellitenuhrdaten (XYZs) für jeden bezeichneten Satelliten vorhanden. Ein Wert von 0 bedeutet, dass die SV Minor-Orbitdaten keine Satellitenuhrdaten aufweisen.
XYZs Ambiguitätsfenster	4	Ambiguitätsfenster = 2^N+4 (Millimeter), wobei N der Ganzzahlwert der 4 Bits ist. N = 0 bis 15 stellt einen Bereich von 16 bis 524288 mm für das Ambiguitätsfenster bereit. Diese Bits sind lediglich vorhanden, wenn die XYZ-Präsenzbits anzeigen, dass Satellitenpositionen vorhanden sind. Sind sie vorhanden, beschreiben diese Bits die Größe des Ambiguitätsfensters für die Position der XYZ Werte. Bei Kombination mit den XYZs Präzisionsindikationen stellt dies die Größe jedes gespeicherten X, Y und Z Komponenten bereit.
XYZs Präzision	4	XYZ Präzision = 2^M (Millimeter), wobei M der Ganzzahlwert der 4 Bits ist. Somit ist N = 0 ... 15, und ergibt einen Präzisionsbereich von XYZ Werten von 1 ... 32768 mm: d. h. die Präzision der LSB. Diese Bits sind lediglich vorhanden, wenn XYZ-Präsenzbits anzeigen, dass Satellitenpositionen vorhanden sind. Dieser Wert stellt die Präzision der XYZ Orbitdaten bereit.
Uhr Quellen-Flag	1	Dieses Flag ist lediglich dann vorhanden, wenn das Uhr-Präsenzbit anzeigt, dass Satelliten-Taktgeber vorhanden sind. Das Flag zeigt die Quelle der Uhrinformation an, die innerhalb der Minor-Daten enthalten ist. Die Werte des Flags und deren Bedeutung sind:
Uhr Quellen-Flag	1	Wert 0 1	Bedeutung Taktgeber sind Standard-Satellitenuhrfehler Taktgeber sind phasenabgeleitet
Uhr Ambiguitätsfenster	4	Diese Bits sind lediglich vorhanden, wenn das Uhr-Präsenzbit anzeigt, dass Satelliten-Taktgeber vorhanden sind. Die Ausdehnung ist dieselbe wie die des XYZ-Ambiguitätsfensters.
Uhr Präzision	4	Diese Bits sind lediglich vorhanden, wenn das Uhr-Präsenzbit anzeigt, dass Satelliten-Taktgeber vorhanden sind. Die Ausdehnung ist dieselbe wie die der XYZ-Präzision.

Relative Major-Orbitdaten

Die Tabelle unten zeigt die Elemente des Major-Orbitblocks für den Relativmodus auf.

Element	Bits	Beschreibung
XYZs vorhanden	1	Wenn auf 1 eingestellt, sind in den SV Minor-Orbitdaten Satellitenpositionen (XYZs) für jeden bezeichneten Satelliten vorhanden. Ein Wert von 0 bedeutet, dass die SV Minor-Orbitdaten keine Satellitenpositionen aufweisen.
Uhr vorhanden	1	Wenn auf 1 eingestellt, sind in den SV Minor-Orbitdaten Satellitentaktdaten (XYZs) für jeden bezeichneten Satelliten vorhanden. Ein Wert von 0 bedeutet, dass die SV Minor-Orbitdaten keine Satellitenuhrdaten aufweisen.
XYZs Ambiguitätsfenster	4	Ambiguitätsfenster = 2^N+4 (Millimeter), wobei N der Ganzzahlwert der 4 Bits ist. N = 0 bis 15 stellt einen Bereich von 16 bis 524288 mm für das Ambiguitätsfenster bereit. Diese Bits sind lediglich vorhanden, wenn XYZ-Präsenzbits anzeigen, dass Satellitenpositionen vorhanden sind.
XYZs Präzision	4	XYZ Präzision = 2^M (Millimeter), wobei M der Ganzzahlwert der 4 Bits ist. Somit ist N = 0 bis 15 und ergibt einen Präzisionsbereich von XYZ Werten von 1 bis 32768 mm: d. h. die Präzision der LSB. Diese Bits sind lediglich vorhanden, wenn die XYZ-Präsenzbits anzeigen, dass Satellitenpositionen vorhanden sind.
Uhr Quellen-Flag	1	Dieses Flag ist lediglich dann vorhanden, wenn das Uhr-Präsenzbit (oben in dieser Tabelle beschrieben) anzeigt, dass Satelliten-Taktgeber vorhanden sind. Das Flag zeigt die Quelle der Uhrinformation an, die innerhalb der Minor-Daten enthalten ist. Die Werte des Flags und deren Bedeutung sind:
Uhr Quellen-Flag	1	Wert 0 1	Bedeutung Taktgeber sind Standard-Satellitenuhrfehler Taktgeber sind phasenabgeleitet
Uhr Ambiguitätsfenster	4	Diese Bits sind lediglich vorhanden, wenn das Uhr-Präsenzbit anzeigt, dass Satelliten-Taktgeber vorhanden sind. Die Ausdehnung ist dieselbe wie die des XYZ-Ambiguitätsfensters, ist jedoch auf die Uhr anzuwenden.
Uhr Präzision	4	Diese Bits sind lediglich vorhanden, wenn das Uhr-Präsenzbit anzeigt, dass Satelliten-Taktgeber vorhanden sind. Die Ausdehnung ist dieselbe wie die der XYZ-Präzision, ist jedoch auf die Uhr anzuwenden.

PRN-Beobachtungen
Wie oben dargelegt, hängt die Anzahl der benötigten Bits für jeden Satelliten von den in den Beobachtungsblockdefinitionsbits (24) eingestellten Optionen ab. Die Anzahl der Satelliten und die Reihenfolge in der diese Satelliten gespeichert werden, wird durch das PRN-Wort in der Reihenfolge zunehmender PRN ID angezeigt. Die grundsätzliche Form der Satellitenbeobachtungsdaten innerhalb CMRx ist in 27 gezeigt, und die grundsätzliche Form der auf pro Satellitenbasis komprimierten Form ist in 28 abgebildet. Information mit Bezug zu den Beobachtungen für den Referenzfrequenz-/Verfolgungstyp (d. h. Ref Mnr CTC, Ref CNR Data, Ref Code Obs und Ref Carr Obs) werden vor den Beobachtungen von anderen Frequenz-/Verfolgungstypen gespeichert.
In den 27 und 28 werden lediglich die Code- und Trägerdaten für den Referenzbeobachtungstyp benötigt. Die GPS-Bebachtungsblockdefinition (24) beschreibt, welcher Frequenz-/Verfolgungstyp als Referenz für die GPS-Beobachtungen benutzt wird. Die mit diesem Referenzfrequenz-/Verfolgungstyp assoziierten Daten werden als erste Beobachtungsdaten für diesen SV gespeichert. Für alle anderen Observablen sind die Werte mit Bezug zu der Codephase dieser Referenzbeobachtung die komprimierten Werte. Für die anderen Nicht-Referenzcodephasenobservablen, einschließlich des Trägers für den Referenzfrequenz-/Verfolgungstyp, wird Verschlüsselung benutzt zur Anzeige, ob diese Beobachtungen schlecht sind oder nicht. Der paketierte Wert für eine „schlechte” Beobachtung ist Null, d. h. alle Bits der Beobachtung sind auf Null gestellt.

Die Tabelle unten liefert weitere Erläuterungen zu den Elementen der 27 und 28.

Element	Bits	Beschreibung
SV Orbit Minor-Daten	Variabel	Unten beschrieben
Iono-/Tropo Optimierter Fensterblock	Variabel	Unten beschrieben
Minor Beobachtungen vorhanden	Variabel	Ein Minor-Lx-Bit ist für jedes L2c, L5 und L1c vorhanden für jeden Fall, wo das assoziierte Major-Präsenzbit anzeigt, dass ein Bedürfnis zur Markierung des Vorhandenseins von Daten auf einer individuellen Satellitenbasis besteht. Die Bedeutung des Minor-Präsenzbits verändert sich je nachdem ob der „Best Of” Modus aktiviert ist.
Schlupfbit	1	Das Schlupfbit ist lediglich vorhanden, wenn die Beobachtungsblockdefinitionsbits anzeigen, dass der CTC nicht in der Nachricht vorhanden ist. Es wird dazu benutzt, um anzuzeigen, dass ein Zyklusschlupf auf den Satellitenträgerdaten stattgefunden hat. Ein Wert 0 bedeutet kein Schlupf, und ein Wert 1 bedeutet, dass bezüglich der vorherigen Datenepoche ein Schlupf eingetreten ist.
Ref Mnr CTC	Variabel	Dies ist lediglich vorhanden, wenn die Beobachtungsblockdefinitionsbits anzeigen, dass der CTC in der Nachricht vorhanden ist. Wenn der CTC in der Nachricht vorhanden sind, treten CTC-Bits (die Anzahl hängt von dem in den Beobachtungsblockdefinitionsbits angezeigten CTC-Modus ab) für jeden Frequenz-/Verfolgungstyp auf. In diesem Fall ist dies der Minor-CTC-Wert für den Träger von der Verfolgungsschleife mit Bezug zu dem Referenzcode.
Ref CNR Daten	6	Diese Bits sind lediglich vorhanden, wenn die Beobachtungsblockdefinitionsbits dies anzeigen. Diese Bits halten bei Vorhandensein den Träger-Rauschverhältniswert des Trägers von der Verfolgungsschleife mit Bezug zum Referenzcode (LSB = 1 DbHz: d. h. von 0 bis 63).
Ref Code Beob.	Variabel	Referenzcodebeobachtungsdaten
Ref Carr Beob.	Variabel	Referenzcodebeobachtungsdaten
Xf Mnr CTC	Variabel	„f” bedeutet Daten von Verfolgungsschleifen, die nicht mit dem Referenzcode assoziiert sind. Diese Bits beziehen sich auf den CTC für die Nicht-Referenzfrequenzverfolgungstypdaten, die in den Beobachtungsdaten enthalten sind. Es ist vorhanden, wenn die Beobachtungsblockdefinitionsbits anzeigen, dass die CTCs in der Nachricht vorhanden sind. Für jeden Frequenz-/Verfolgungstyp werden dieses und die nächsten drei Elemente für alle Beobachtungstypen für den Satelliten wiederholt.
Xf CNR Daten	Variabel	„f” bedeutet Daten von Verfolgungsschleifen, die nicht mit dem Referenzcode assoziiert sind. Der Träger-Rauschwert für den Träger der Verfolgungsschleifen bildet einem Nicht-Referenzcode. Er ist vorhanden, wenn die Beobachtungsblockdefinitionsbits dies anzeigen.
Rf Code Beob.	Variabel	„f” bedeutet hier Daten von Verfolgungsschleifen, die nicht mit dem Referenzcode assoziiert sind. Nicht-Referenzcodebeobachtungsdaten.
Xf Carr Beob.	Variabel	„f” bedeutet hier Daten von Verfolgungsschleifen, die nicht mit dem Referenzcode assoziiert sind. Nicht-Referenzcodebeobachtungsdaten.

SV Minor-Orbitdaten
Es gibt Major-Orbitdaten, die auf alle Satelliten in der Nachricht Anwendung finden und Minor-Orbitdaten, die auf jeden Satelliten auf einer individuellen Basis Anwendung finden. Das Vorhandensein beider wird angezeigt durch die ORB-Bits der GPS-Beobachtungsblockdefinitionsbits. Die ORB-Bits zeigen an, ob die Nachricht Referenzmodus- oder Relativmodusorbits umfasst oder nicht. Die Major-Orbitdaten beschreiben, welche Elemente und die Größe eines jeden, im Minor-Orbitblock gefunden werden. 29 liefert eine grundsätzliche Beschreibung des Minor-Orbitdatenblocks für jeden der beiden Referenz- und Relativmodi.
Referenz- und Relativmodus SV Minor-Orbitdaten

Die Tabelle unten beschreibt die Minor-SV Orbitdaten, d. h. Daten, die für jeden Satelliten bereitgestellt werden und für die angezeigt ist, dass im Beobachtungsdatenblock Orbitdaten vorhanden sind.

Element	Bits	Beschreibung
Gültiges Flag	1	Wenn dieses Bit 0 ist, ist lediglich das „Gute Sv Flag” in der Nachricht vorhanden: d. h. keine anderen verbleibenden Elemente in dieser Tabelle werden für das SV gespeichert. Wenn dieses Bit auf 1 eingestellt ist, werden die verbleibenden Elemente gespeichert.
Gutes Sv Flag	1	Wenn auf 1 eingestellt, wird der Satellit als brauchbar angesehen (übertragene oder präzise Orbits). Wenn auf 0 eingestellt, wird der Satellit als unbrauchbar angesehen. Der Wert dieses Flags hat keine Bedeutung dafür, ob die verbleibenden Elemente dieses Blocks vorhanden sind oder nicht.
A/B Modus Flag	1	Referenz- und Relativmodus Orbitdaten können in der CMRx GPS-Orbit-/Uhrnachricht gemischt werden, es existiert jedoch für jeden individuellen Satelliten ein Einzelmodus. Insbesondere kann ein Modus für einen Satellitensatz benutzt werden und ein anderer Modus für einen anderen Satellitensatz, sogar innerhalb derselben Nachricht. Wenn dieses „A/B Mod Bit” vorhanden ist, hat es die folgende Bedeutung:
A/B Modus Flag	1	Wert 0 1	Beschreibung Referenzmodusdaten für diesen Satelliten. Relativmodusdaten für diesen Satelliten.
WL BP Flag	1	Dieses Bit ist lediglich vorhanden, wenn Orbit-/Uhr-Major-Daten anzeigen, dass Uhrdaten vorhanden sind, d. h., wenn das Uhr-Präsenzbit der Orbit-/Uhr-Major-Daten auf 1 eingestellt ist. Dieses Bit zeigt an, ob die „Wide-Lane-Verschiebungs”-Bits innerhalb dieser pro-Satellit-Minor-Daten anwesend sind oder nicht. Wenn das Bit auf 1 eingestellt ist, ist die Wide-Lane-Verschiebung vorhanden, und wenn dieses Bit auf 0 eingestellt ist, ist die Wide-Lane-Verschiebung nicht vorhanden.
CLK BP Flag	1	Dieses Bit ist lediglich vorhanden, wenn Orbit-/Uhr-Major-Daten anzeigen, dass Uhrdaten vorhanden sind. Wenn dieses Bit auf 1 eingestellt ist, ist die Uhrverschiebung vorhanden, und wenn dieses Bitt auf 0 eingestellt ist, ist die Uhrverschiebung nicht vorhanden.
Taktgebersprung Flag	1	Wenn der Orbit-Major-Block anzeigt, dass Satellitenuhrdaten phasenabgeleitet sind, dann ist dieses Bit vorhanden. Wenn es vorhanden ist, hat dieses Bit die folgende Bedeutung:
Taktgebersprung Flag	1	Wert 0 1	Bedeutung kein Sprung in der Uhr aufgetreten. Sprung in phasenabgeleiteter Uhr ist eingetreten.
XYZ Qualität	3	Diese Bits sind lediglich vorhanden, wenn Orbit-/Uhr-Major-Daten anzeigen, dass Orbitdaten vorhanden sind. Diese Bits stellen die Qualität der X, Y und Z Elemente der Orbits dar. Diese Werte werden je nach Bereitstellung ohne Interpretation weitergeleitet. Am CMRx-Decoder werden diese Bits von der Nachricht extrahiert und an den Anstoßorbit-/Uhrmanager weitergeleitet.
X, Y und Z Positionskomponenten	Variabel	Diese Bits sind lediglich vorhanden, wenn Orbit-/Uhr-Major-Daten anzeigen, dass Orbitdaten vorhanden sind. Wenn sie vorhanden sind, repräsentieren die Bits ein Dreifaches der mehrdeutigen Satellitenantennenphasencenterpositionen (x, y, z). Sowohl die Anzahl der benötigten Bits als auch die Bedeutung jedes Bits wird durch das XYZ-Ambiguitätsfenster und XYZ Präzisionselemente des Orbit-/Uhr-Major-Blocks definiert.
Uhrqualität	3	Diese Bits sind lediglich vorhanden, wenn Orbit-/Major-Uhrdaten anzeigen, dass Uhrdaten vorhanden sind. Wenn vorhanden, liefern diese Bits die Qualität des Orbituhrfehlers. Diese Werte werden je nach Bereitstellung ohne Interpretation weitergeleitet. Der CMRx-Decoder extrahiert diese Bits von der Nachricht und leitet sie zu dem Anstoßorbit-/Uhrmanager weiter.
Uhrfehler	Variabel	Diese Bits sind lediglich vorhanden, wenn Orbit-/Uhr-Major-Daten anzeigen, dass Uhrdaten vorhanden sind. Wenn vorhanden, ist eine mehrdeutige Form des Satellitenuhrfehlers, bevorzugt in Meter, in der Nachricht. Sowohl die Anzahl der benötigten Bits als auch die Bedeutung jedes Bits wird durch das „Uhrambiguitätsfenster” und die „Uhrpräzisions”-Elemente des Orbit-Major-Blocks definiert.
Wide-Lane Verschiebung	7	Diese Bits sind lediglich vorhanden, wenn das „Wide-Lane Verschiebungs”-Bit auf 1 eingestellt ist. Die fundamentalen Elemente dieses Werts sind in entpaketierter Form Wide-Lane Zyklen, das heißt, die wide-lane Kombination von L1 und L2 Trägern. Die Bedeutung ist:
Wide-Lane Verschiebung	7	Wert 7F₁₆ 7E₁₆ 00₁₆ to 7D₁₆	Bedeutung Fehlerzustand – Diesen SV nicht benutzen Für diese Verschiebung steht keine Information zur Verfügung –1.0 bis 1.0 Zyklen (LSB ~0.0159 Zyklen)
Uhrverschiebung	7	Diese Bits sind lediglich vorhanden, wenn „Uhrverschiebungs-Präsenz”-Bit auf 1 eingestellt ist. Die fundamentalen Elemente dieses Werts sind Meter. Die Parameter werden in einem Bereich von –2,0 bis +2,0 Meter in 7 Bits gespeichert. Die Bedeutung ist:
Uhrverschiebung	7	Wert 7F₁₆ 7E16 00016 bis 7D16	Bedeutung Fehlerzustand – Diesen SV nicht benutzen Für diese Verschiebung steht keine Information zur Verfügung –2,0 to 2,0 Meter (LSB ~0.0317 Meter)
Taktgebersprung	6	Diese Bits sind lediglich vorhanden, wenn das „Taktgebersprung-Flag”-Bit auf 1 eingestellt ist. Wenn vorhanden, zeigt das Bit an, dass ein Sprung in der phasenabgeleiteten Uhr stattgefunden hat. Wenn das „Taktgebersprung-Flag” auf Null eingestellt ist, dann hat kein kürzlicher Sprung in der Uhr stattgefunden. Dieses Feld zeigt an, wie lange es her ist, mit Bezug auf die Referenzzeit der Uhrinformation, dass die phasenabgeleitete Uhr einen Sprung erfuhr. Das am wenigsten wichtige Bit des Felds repräsentiert 5 Sekunden und wird um 5 Sekunden versetzt, was bedeutet, dass der Wert 000000₂ ist Wenn der Wert 000001₂ ist, bedeutet das, dass innerhalb der letzten 10 Sekunden ein Taktgebersprung eingetreten ist. Der größte Wert, d. h., 111111₂ wird für den zukünftigen Gebrauch reserviert. Der CMRx-Encoder akzeptiert den bereit gestellten Wert und paketiert ihn ohne Modifikation oder Skalierung. Der CMRx-Decoder entpaketiert diesen Wert und berichtet den entpaketierten Wert an die Applikation.

Iono-/Tropo-optimierter Fensterblock
Wenn der Iono-/Tropo-optimierte erweiterte Komprimierungsmodus aktiviert ist, werden Ionosphären- und Troposphärendaten von den Ausgangsbeobachtungen entfernt, wodurch die Anzahl der Bits reduziert wird, die erforderlich sind, um die Beobachtungsdaten zu speichern. Um dies zu bewerkstelligen, werden weitere Informationen darüber, was mit den Daten gemacht wurde, an die CMRx-Nachricht geliefert, sodass CMRx-Decoder die Originaldaten wieder herstellen können.
In dem Iono-/Tropo-optimierten erweiterten Komprimierungsmodus werden Ionosphären- und Troposphärenwerte von den Beobachtungen entfernt, ehe sie komprimiert werden. Da die Ionosphären- and Troposphärenkomponenten von den Beobachtungen entfernt wurden, ist der residuale Teil der Beobachtung reduziert. Dies ermöglicht CMRx, Träger- und Codebeobachtungen in einer mehrdeutigen Form zu senden, weil der CMRx-Empfänger den mehrdeutigen Teil neu berechnen kann. Wie angegeben, wird von sowohl durch den Komprimierungs- als auch durch den Dekomprimierungsalgorithmus ein Troposphärenmodel benutzt, das auf Satellitenerhebung basiert, um die von den Daten entfernte Troposphäre zu berechnen. Für die Ionosphäre wird die auf allen guten/gültigen Satelliten basierende gemittelte vertikale Ionosphäre durch das Komprimierungsverfahren berechnet. Für jede Beobachtung wird die vertikale Ionosphäre zum angemessenen Erhebungswinkel für jeden Satelliten kartiert, und dieser kartierte Wert wird von den Beobachtungsdaten entfernt. Wenn der Iono-/Tropo-optimierte erweiterte Komprimierungsmodus aktiviert ist, wird diese gemittelte vertikale Ionosphäre mit jeder CMRx-Nachricht gesendet. Auf diese Art und Weise kann ein CMRx-Empfänger den selben Wert berechnen, der vor der Komprimierung von den Daten entfernt wurde und diesen Wert wieder hinzufügen, um die Originalbeobachtung wieder herzustellen.
Während des Komprimierungsverfahrens reduziert der Komprimierungsalgorithmus die Anzahl der Bits, die für jede Beobachtung erforderlich ist, indem die Ionosphären- und Troposphärenwerte entfernt werden. Das Komprimierungsverfahren bestimmt sodann die Anzahl der Bits, die erforderlich ist, um die verbleibende Information zu speichern. Das Komprimierungsverfahren bestimmt auf einer pro-Bebachtungstyp-Basis für alle Satelliten der Epoche die Anzahl der erforderlichen Bits aufgrund der Residualen. Für jeden Beobachtungstyp gibt es vier mögliche „Fenster”. Jedes Fenster spezifiziert den zu sendenden Minimal- und Maximalwert sowie die Anzahl der erforderlichen Bits für dieses Fenster. Träger „fenster” sind unabhängig vom Codefenster. Daher wird die gemittelte vertikale Ionosphäre im Iono-/Tropo-optimierten Fensterblock gespeichert und der Index des Fensters für jeden Bebachtungstyp paketiert:

1) Gemittelter vertikaler Ionosphärenindex (5 Bits)
2) Referenzcode Ambiguitätsfensterindex (2 Bits)
3) Träger (des Referenzverfolgungstyps) Ambiguitätsfensterindex (2 Bits)
4) Ra Ambiguitätsfensterindex (2 Bits)
5) La Ambiguitätsfensterindex (2-Bits) bis
r) Rx Ambiguitätsfensterindex (2 Bits)
s) Lx Ambiguitätsfensterindex (2-Bits). wobei die ,a' und ,x' Werte (in Ra, La, Rx und Lx) Daten aus dem Frequenz-/Verfolgungstyp des Nicht-Referenzcodes repräsentieren und ,a' ... ,x' Frequenz-/Verfolgungstypen sind.

Die Bebachtungsfolgebits des Beobachtungsblocks identifizieren den Referenzcodetyp und die anderen Beobachtungen, die in den Beobachtungsdaten vorhanden sind. Daher enthält das Iono-/Tropo-optimierte Fenster lediglich Daten für diejenigen Beobachtungstypen, die in die Beobachtungsfolgebits angezeigt sind. Die Abfrage der Information mit Bezug zum Verfolgungstyp und zur Frequenz ist dieselbe wie die in den Beobachtungsfolgebits, die Fensterfunktion mit Bezug zum Referenzfrequenz-/Verfolgungstyp steht jedoch an erster Stelle. Die Reihenfolge der Fensterindexspeicherung für jeden Referenzfrequenz-/Verfolgungstyp ist Code-Ambiguitätsfensterindex gefolgt von dem des Trägers.
Das Vorhandensein der Fensterfunktionsinformation für die Nicht-Referenzcodetypdaten innerhalb des Block hängt davon ab, wie das RP-Bit der Beobachtungsfolgebits eingestellt ist. Wenn RP alle anzeigt, dann wird die Fensterfunktionsinformation für alle Codetypen verfolgt. Wenn das RP anzeigt, dass lediglich die Referenzcodeinformation gespeichert wird, dann wird lediglich für den Referenzcodetyp die Fensterfunktionsinformation gespeichert. Die grundsätzliche Form des Iono-/Tropo-optimierten Fensterblocks wird in 30 gezeigt.
Wie oben erwähnt, ist der vertikale Ionosphärenindex die gemittelte vertikale Ionosphäre gespeichert in Metereinheiten unter Verwendung von 5 Bits, mit einem LSB von 2 Metern. Der vertikale Index wird dann gefolgt von den Code- und Träger-Ionosphären-Fensterfunktionsindexen. Im Iono-/Tropo-optimierten Komprimierungsmodus werden die Ionosphären- und Troposphärenwerte von den Beobachtungen entfernt, ehe sie komprimiert werden. Somit wird der residuale Teil der Beobachtung reduziert.
Für die Ionosphäre wird die gemittelte vertikale Ionosphäre basierend auf allen guten/gültigen Satelliten mit dem Komprimierungsverfahren berechnet. Die vertikale Ionosphäre wird für jede Beobachtung zu dem angemessenen Erhebungswinkel für jeden Satelliten kartiert, und dieser kartierte Wert wird von den Beobachtungsdaten entfernt. Diese gemittelte vertikale Ionosphäre wird mit jeder CMRx-Nachricht gesendet. Der CMRx-Empfänger kann dann denselben, von den Daten vor der Komprimierung entfernten, Wert berechnen und diesen Wert wieder hinzufügen, um die Originalbeobachtung wieder herzustellen.
Die Beobachtungsfolgebits des Beobachtungsblocks identifizieren den Referenzcodetype und die anderen Beobachtungen, die in den Beobachtungsdaten vorhanden sind. Somit enthält das Iono-/Tropo-optimierte Fenster lediglich Daten für diese, durch die Beobachtungsfolgebits angezeigten, Beobachtungstypen. Die Abfrage der Information mit Bezug zu Verfolgungstyp und Frequenz ist dieselbe wie die in den Beobachtungsfolgebits, die Fensterfunktion mit Bezug zum Referenzfrequenz-/Verfolgungstyp steht jedoch an erster Stelle. Die Reihenfolge für jeden Referenzfrequenz-/Verfolgungstyp ist Code-Ambiguitätsfensterindex gefolgt von dem des Trägers.
Wenn die L2c Bits Beobachtungsfolgebits anzeigen, dass die L2c Typendaten vorhanden sind, entweder durch die Anzeige aller oder ausgewählter SVs, dann enthält der Iono-/Tropo-optimierte Fensterblock Fensterfunktionsinformation für die Trägerdaten. Das Vorhandensein von Fensterfunktionsinformation für die Nicht-Referenzcodetypdaten in dem Block hängt davon ab, wie das RP-Bit der Beobachtungsfolgebits eingestellt ist. Wenn RP alle anzeigt, dann ist Fensterfunktion für alle verfolgten Codetypen vorhanden. Wenn RP anzeigt, dass nur die Referenzcodebeobachtung gespeichert wird, dann wird lediglich für den Referenzcodetyp Fensterfunktionsinformation gespeichert. Dieselben Konzepte und Komprimierungsverfahren gelten für die L5 und L1c-Bits der Beobachtungsfolgebits.
Komprimierungsalgorithmus
Wegen der verschiedenen Komprimierungsoptionen, Komprimierungsmodi und der Anzahl der Satelliten pro Epoche variiert die Größe des Beobachtungsblocks. Es ist ebenfalls schwer, die vollständige Komprimierung der Beobachtungsdaten in einem einzelnen Algorithmus zu beschreiben. Daher zeigen wir algorithmische Elemente (und erwarten, dass der Leser in der Lage ist, auf kompliziertere/kombinierte Algorithmen zu extrapolieren). Ehe wir beginnen, stellen wir eine detailliertere Beschreibung der Komprimierungsstufen bereit, da diese vorausgesetztes Wissen in den danach bereit gestellten Algorithmen sind.
Komprimierungsstufen
In vorherigen Beschreibungen innerhalb dieses Dokuments stellten wir Komprimierungsstufen vor, gaben aber an, dass wir bezüglich deren detaillierter Beschreibung warten würden, einfach weil die Thematik Komplexität einführen könnte und dadurch das Verständnis des in diesen Abschnitten vorgestellten Materials erschweren würde. Nun streben wir eine detailliertere Beschreibung der Komprimierungsstufen an.
Die Komprimierungsstufen sind im Wesentlichen Indexe in Tabellen, die die Größe und damit assoziierten Werte der Elemente produzieren, die auf der Encoderseite benutzt werden, um die Werte in die CMRx-Nachrichten zu paketieren, sowie die Elemente, die benutzt werden, um die Originaldaten auf der Decoderseite wieder herzustellen. Diese Komprimierungsstufen werden im Zusammenhang der drei Komprimierungsmodi betrachtet – Standard, Erweitert und Iono-/Tropo-optimiert-erweitert – deren gegenseitige Beziehung über die Tabellen und Beschreibungen innerhalb dieses Abschnitts erklärt werden.
In jedem der folgenden Tabellen bedeutet RC die Referenzcodebeobachtung, und Rx bedeutet alle anderen Codebeobachtungen. Die Elemente, die Car innerhalb ihrer beschreibenden Namen aufweisen, stehen in Bezug zu den Trägerobservablen. Notationen mit einer Initiale w, wie z. B. wRC und wRx, sind mit dem Iono-/Tropo-optimierten erweiterten Komprimierungsmodus assoziiert.

Für Standard-Modus Code-Komprimierungsstufen:

Komprimierungsstufen	RC-Bits (Bitanzahl)	RC-Skalierung (m)	Rx-Bits (Bitanzahl)	R-Skalierung (m)
0	31	0,00375	15	0,00375
1	30	0,0075	14	0,0075
2	29	0,015	13	0,015
3	28	0,030	12	0,030
4	27	0,060	11	0,060
5	26	0,120	10	0,120
6	25	0,240	9	0,240
7	24	0,480	8	0,480

Für Erweiterte Komprimierungsmodus Code-Komprimierungsstufen:

Komprimierungsstufen	RC-Bits (Bitanzahl)	RC-Skalierung (m)	Rx-Bits (Bitanzahl)	Rx-Skalierung (m)
0	17	0,00375	15	0,00375
1	16	0,0075	14	0,0075
2	15	0,015	13	0,015
3	14	0,030	12	0,030
4	13	0,060	11	0,060
5	12	0,120	10	0,120
6	11	0,240	9	0,240
7	10	0,480	8	0,480

Die obige Tabelle stellt die Bitgrößen und Präzisionen bereit, die benutzt werden, um CMRx-Codebeobachtungen für alle Komprimierungsstufen von zweien der drei Komprimierungsmodi – Standard und Erweitert – zu erstellen, jedoch nicht für den Iono-/Tropo-optimierten erweiterten Modus. Für den erweiterten Komprimierungsmodus berechnen wir die Ambiguitätsgröße des Codefensters, das für jede Komprimierungsstufe benutzt wird, als: dRCAmbiguitySize = pow (2.0, RCBits)·RCScale;
Die obigen zwei Tabellen ermöglichen uns außerdem, Minimal- und Maximal-Codewerte zu berechnen, die in einer CMRx-Nachricht aufgrund der verfügbaren Bits für diese Elemente gespeichert werden können):
Nun werden die Iono-/Tropo-optimierten erweiterten Komprimierungsmodi berücksichtigt. In der folgenden Tabelle definieren wir die vier Fenster für jeden Satellitencode-Frequenz-/Verfolgungstyp. Zur Bezugnahme auf ein Element aus der Tabelle benutzen wir T.

Fenster Index wRC-Bits (Bitanzahl) wRx-Bits (Bitanzahl)

0 (T RC Bits) (T Rw Bits)

1 (T RC Bits)-1 (T Rw Bits)-1

2 (T RC Bits)-2 (T Rw Bits)-2

3 (T RC Bits)-3 (T Rw Bits)-3
Die obige Tabelle stellt die Bitgrößen und Präzisionen bereit, die benutzt werden, um CMRx-Codebeobachtungen für den Iono-/Tropo-optimierten Fenstermodus zu erstellen. Für diesen Modus ist die Ambiguitätsgröße des Codefensters, das für jedes Fenster einer vorgegebenen Komprimierungsstufe benutzt wird: dRCAmbiguitySize = pow (2.0, wRCBits)·TRCScale;
Dies ermöglicht die Berechnung der Minimal- und Maximalwerte für jedes der vier Fenster mit einer vorgegebenen Komprimierungsstufe, unter Benutzung der folgenden Werte für jedes Fenster: dLowRCWinM = –(pow (2.0, wRCBits-1)·TRCScale); dHighRCWinM = (pow (2.0, wRCBits-1) – 1.0)·TRCScale; dLowRXWinM = –(pow (2.0, wRxBits-1)·TRxScale); dHighRXWinM = (pow (2.0, wRxBits-1) – 1.0)·TRxScale;
Sowohl für den Standardmodus als auch den Erweiterten Modus sind die Trägerkomprimierungsstufen:

Komprimierungsstufen Car Bits (Bitanzahl) CarCycWin (Zyklen)

0 20 4000,0

1 19 4000,0

2 18 4000,0

3 17 4000,0

4 16 4000,0

5 15 4000,0

6 14 4000,0

7 13 4000,0
Hieraus folgt eine Skalierung, die zur Umrechnung der CMRx-Trägerbeobachtungen in eine Ganzzahlform benutzt wird: //Berechne den Wert, der zur Berechnung des Trägerskalierungsfaktors benutzt wird. dCarRange = pow (2.0, CarBits);//Zyklen.
Ein ähnliche Fenster-basierende Tabelle für den Iono-/Tropo-optimierten erweiterten Komprimierungsmodus folgt. Bei Bezugnahme auf ein Tabellenelement 2.2.8.5.1-4 benutzen wir die Notation T.

Fenster Index wCar-Bits (Bitanzahl) wCarCycWin (Zyklen)

0 (T Car Bits) (T CarCycWin)

1 (T Car Bits)-1 (T CarCycWin)/2

2 (T Car Bits)-2 (T CarCycWin)/4

3 (T Car Bits)-3 (T CarCycWin)/8
Die obige Tabelle stellt die Bitgrößen und Präzisionen bereit, die benutzt werden, um CMRx-Trägerbeobachtungen für alle Komprimierungsstufen und alle Fenster innerhalb des Iono-/Tropo-optimierten erweiterten Modus zu erstellen. Die Skalierung, die zur Umrechnung der CMRx-Trägerbeobachtungen auf eine Ganzzahlform benutzt wird, ist: //Berechne den Wert, der zur Berechnung des Trägerskalierungsfaktors benutzt wird. dWinCarRange = pow (2.0, wCarCycWin);//Zyklen.
Fensterfunktion
Dieser Abschnitt beschreibt die Fensterfunktion innerhalb von CMRx. Um die Fensterfunktion zu verstehen, wird zunächst die Empfängercodephase beschrieben. Wenn ein Satellit seine codierte Information überträgt, ist die Zeit bekannt, zu der jedes Bit den Satelliten verlässt. Es sei angenommen, dass die Empfänger-Taktgeber zeitlich perfekt mit der Satelliten-Taktgeber abgestimmt ist und dass sich das Signal durch ein perfektes Vakuum ausbreitet. Korrekturen für jede dieser Annahmen werden unten diskutiert. Es sei weiterhin angenommen, dass die lineare Distanz eines einzelnen Bits 300 Meter sei und die Bitrate ungefähr 1.000.000 Bits pro Sekunde.
Der Empfänger kann den genauen Anstieg/Abfall eines Bits in dessen Signalverarbeitung nicht messen. Es sei jedoch angenommen, dass er nah genug ist und sich innerhalb von etwa 3 Meter befindet (d. h. ein Hundertstel eines Codezyklus). Da bekannt ist, wann das Bit den Satelliten verlies und wann es empfangen wurde, kann eine Entfernung berechnet werden. Diese Entfernung lokalisiert den Empfänger auf der Oberfläche einer Sphäre zu dieser Distanz von dem Satelliten. Es sei daran erinnert, dass uns der Satellit in seiner Nachricht Informationen bereitstellt, die es uns ermöglichen, dessen Position – übertragener Orbit genannt – präzise zu berechnen. Die Verfolgung dreier Satelliten gibt uns den Schnittpunkt von drei Sphären, der einen Punkt auf der Erdoberfläche ergibt.
Wir haben zuvor die Tatsache ignoriert, dass der Taktgeber des Empfängers, die für die Messung dieser Entfernung entscheidend ist, in Bezug zu der GPS-Satellitenzeit abweicht. Daher weicht der Taktgeber des Empfängers in Bezug zum GPS ab. Dieser Fehler wird der Empfänger-Taktgeber-Versatz genannt. Um dem abzuhelfen, werden Daten von einem vierten Satelliten benutzt, die die Bestimmung des Fehlers im Empfänger-Taktgeber mit Bezug zur GPS-Zeit ermöglichen.
Der Einfachheit halber haben wir oben die Tatsache ignoriert, dass das Signal durch mehrere Umgebungselemente hindurchgeht, die das Signal länger oder kürzer erscheinen lassen. Die Ionosphäre und Troposphäre haben eine Auswirkung auf die Signalausbreitungsrate und verzögern grundsätzlich die Ankunft des Signals, wodurch die Entfernung zum Satelliten länger erscheint. Außerdem können andere Auswirkungen das Signal weiterhin verzögern. Die Empfängerantenne(n) befindet(n) sich möglicherweise in der Nähe von Bauwerken, die die Signale vom Satelliten reflektieren. Diese Signalprellungen oftmals als Mehrwegübertragung bezeichnet, führen zu mehrfachen Inputs am selben Antennenstandort. Jeder Input lässt den Satelliten so erscheinen, als habe er aufgrund der hinzugefügten Distanz von der Signalreflektierung eine scheinbar unterschiedliche Entfernung.
Außerdem erschweren diese Multi-Inputs die Ermittlung des Anstiegs/Abfalls jedes Bits. Dies verändert die Bestimmung des Empfängers, wann das Signal ankommt und korrumpiert somit die Entfernungsmessung. Alle diese Faktoren beeinträchtigen die Signale von allen Satelliten und beeinträchtigen somit die Fähigkeit des Empfängers zur präzisen Bestimmung der Entfernungen und des Taktgeber-Versatzes. Dies ist der Grund für die Terminologie – Pseudoentfernung (oder falsche Entfernung).
Code-Fensterfunktion
Die grundsätzliche Ausgangsfrage lautet: „Wenn eine Codeobservable (d. h. ein Pseudo-Enfernungsobservable) von einem CMRx-Sender an einen CMRx-Empänger gesendet wird, kann man komprimieren, indem ein Delta zwischen eine berechnete Entfernung und die tatsächliche Entfernung gesendet wird?” Das bedeutet, wenn bekannt ist, wo der Satellit ist (weil die übertragene Nachricht vom Satelliten sowohl dem Sender als auch dem Empfänger einer Nachricht verfügbar ist) und bekannt ist, wo der Empfänger ist (weil die Koordinaten der Sendestation bekannt sind), dann können sowohl der Sender als auch der Empfänger die tatsächliche Entfernung berechnen. Warum sendet man dann nicht einfach nur den Unterschied zwischen der berechneten Entfernung und der Pseudoentfernung? Die vorrangige Antwort ist die IODE (Ausgabe von Datenephemeriden, Issue of Data Ephemeris).
Wir haben zuvor angegeben, dass der Satellit seine Orbitaldaten überträgt und es einem ermöglicht, die Position des Satelliten zu jeder Zeit präzise zu berechnen. Obwohl dies grundsätzlich wahr ist, ist der übertragene Orbit (den der Satellit als Teil seines Signals überträgt) nicht perfekt. Er wird durch eine Reihe von Bodenverfolgungssystemen formuliert, die den Orbit „voraussehen” und dann diese Orbits auf die Satelliten zur Übertragung hochladen. Diese Voraussagen sind um einen zentralen Punkt herum sehr gut, fallen jedoch im Zuge der Wegbewegung von diesem zentralen Punkt ab. Dieser zentrale Punkt wird durch eine Orbitreferenzzeit angezeigt, die Toe (oder Ephemeridenzeit – Time of Ephemeris) genant wird. Bitte 31 berücksichtigen.
Bei Betrachtung zweier sukzessive übertragener Orbits über denselben Zeitraum, sind die Orbitalbögen nicht dieselben. Dies liegt daran, dass der Orbit vorausgesehen und um den Toe herum optimiert wird. Somit kann man nicht einfach die berechnete Entfernung minus der Pseudoentfernung in einer Nachricht senden, weil dies voraussetzen würde, dass der Empfänger genau dieselbe orbitale Nachricht sieht, und wegen (kurzer oder langer) Blockierungen im Himmel (wie z. B. Baumäste und Brücken) kann man nicht annehmen, dass der Empfänger den selben Orbit hat wie der Sender.
Wenn ein neuer Orbit auf den Satelliten hochgeladen wird, ändert sich seine Toe, und eine 8-Bit Zahl, die seinen Orbit anzeigt (genannt IODE), ändert sich ebenfalls. Die IODE ist definiert zur eindeutigen Identifizierung der Orbits durch einen individuellen Satelliten über einen vorgegebenen Zeitraum. Die berechnete Entfernung minus der Pseudoentfernung kann gesendet werden, wenn die IODE ebenfalls gesendet wird. Dies ermöglicht dem Empfänger die Kenntnis des zur Wertberechnung benutzten Orbits. Dies ist im Wesentlichen das, was die RTCM-Korrektur macht – sie sendet einen Codekorrekturbegriff und eine IODE. Dieser Ansatz hat jedoch zwei Nachteile: (1) benötigt er 8 zusätzliche Bits pro SV pro Nachricht (die 8-Bit IODE muss mit jeder Nachricht gesendet werden), und (2) der Sender kann eine IODE empfangen, die der Empfänger noch nicht hat, zum Beispiel aufgrund eines ansteigenden Satelliten und der räumlichen Trennung zwischen Sender und Empfänger oder weil der Empfänger ein Rover mit momentanen Blockaden bezüglich dieses Satelliten ist.
Um diese Probleme in CMRx zu umgehen, formuliert und sendet der Sender eine mehrdeutige Codeentfernung. Er tut dies durch Senden eines Wertes, der das Restglied folgender Division ist: CMRxRange = fmod (Pseudoentfernung, Fenstergröße)wobei:
die Fenstergröße die Größe des Ambiguitätsfensters ist (unten beschrieben);
die Pseudoentfernung die Entfernungsobservable ist, die durch den GPS-Empfänger bereitgestellt wird, und
CMRxRange ist der in der CMRx-Nachricht paketierte und gespeicherte Wert.
Der Empfänger empfängt diese CMRx-Enfernung und rekonstruiert dann die fehlenden Ambiguitäten. Er tut dies, indem er die Entfernung zu dem Satelliten unter Benutzung des übertragenen Orbits und der mit der CMRx-Entfernung assoziierten Zeit berechnet, die er von der CMRx-Nachricht empfangen hat (d. h. die Zeit der Daten ist in der Nachricht enthalten). Er kann dann die vollständige Entfernung unter Benutzung des folgenden Ansatzes rekonstruieren:

1. Berechnung der Anzahl der „Fenster” in der geometrischen Entfernung (d. h. dRho, die geometrische Entfernung, wird unter Benutzung des übertragenen Orbits und der Koordinaten des Senders berechnet). dRcN = (dRho – CMRxRange)/Fenstergröße;
2. Erhalt einer Ganzzahl der fehlenden Fenster (durch Abrunden). dRcN = Round (dRcN);
3. Rekonstruktion der vollständigen Entfernung Pseudo-Range = CMRxRange + (dRcN·Fenstergröße);

Es ist wichtig, eine kleine Fenstergröße zu haben. Ein Ansatz hierfür wäre der der typischen GPS-Empfänger (wegen der 1 Millisekunde PRN-Codelänge), nämlich das Senden einer Zahl, die zu 1 Millisekunde mehrdeutig ist. Um jedoch 1 Millisekunde Code zu senden, benötigt man eine Zahl, die 300.000 Meter erreicht. Bei einer Millimeter-Auflösung und Senden einer Ganzzahl bedeutet dies, dass man eine Zahl senden muss, die mindestens 300000000 mm ist, (was ungefähr 29 Bits entspricht).
Anstatt in CMRx wird die Fenstergröße unter Berücksichtigung vieler Faktoren ausgesucht. Diese umfassen Ionosphäre, Troposphäre, Mehrweg, grundsätzliche Geräusche und IODE-Änderungen. In einem Fall, in dem CMRx nicht versucht, die Troposphäre abzubilden oder die Ionosphäre zu entfernen, wird diese Zahl auf ungefähr 500 eingestellt, welche erheblich kleiner ist und viel weniger Bits erfordert. CMRx wählt die Ambiguitätsgröße, um in einem nominalen Schlimmstfall das Zweifache aller dieser Faktoren zu berücksichtigen und erfordert weniger Bits als der oben beschriebene 1 Millisekunde-Ansatz.
Träger-Fensterfunktion
Um den Träger innerhalb von CMRx zu verstehen, wird zunächst beschrieben, wie der Träger durch den GPS-Empfänger gemessen wird: d. h. die Bedeutung der Quantitäten. Bei der ersten Probennahme (t = 0) der Trägerphase erhält der Empfänger eine Bruchteilsphasenmessung (d. h. eine Zahl kleiner als 1 aber größer oder gleich Null). Es ist klar, dass dies nur ein Teil der wahren Entfernung zum Satelliten ist. Dieser Messung fehlt eine Quantität, die eine Ganzzahl der Trägerzyklen ist (nennen wir sie N). Im Zuge der Vornahme jeder sukzessiven Messung verfolgt der Empfänger die Veränderung in der Entfernung zum Satelliten als Teil des Trägers: d. h. beim nächsten Muster fehlt derselbe anfängliche N-Wert. Daher kann die Pseudo-Trägerentfernung zu dem Satelliten folgendermaßen ausgedrückt werden: Θja (t) = Pja (t) + N + εja (t)wobei,

a: den Empfänger bezeichnet
j: den Satelliten bezeichnet
t: Zeit
P: die tatsächliche Entfernung zu dem Satelliten (genannt Rho)
ε: Fehler (wie z. B. Mehrweg, Ionosphäre, Troposphäre)
Q: beobachtete/gemessene Trägerphase.

Diese Gleichung zeigt faktisch, dass dem vom Empfänger zwischen einem Empfänger und einem Satelliten gemessenen Träger zu jeder Zeit ein konstanter Term fehlt. Wenn dieser konstante Term (N) bekannt wäre, dann ist die Trägerentfernung bei jeder Probennahme bekannt. Dies ist die vorrangige Basis der Trägerphasenverarbeitung, wobei sobald N gelöst wurde (genannt die Ambiguität) präzise Trägerentfernungen zu dem Satelliten bekannt sind. Der Wert von N ist eine Ganzzahl, d. h. die Anzahl der Trägerzyklen.
Betrachtung der folgenden Änderung an der obigen Gleichung: Θja (t) + N• = Pja (t) + N' + εja (t)
Ein konstanter Wert (z. B. N^•) wurde auf beiden Seiten der Gleichung hinzugefügt. Da die Verarbeitungsaufgabe des Trägers darin liegt, N in der ersten Gleichung zu lösen, kann man eine Ganzzahl von Zyklen zu der beobachteten Trägerphase (N^•) hinzufügen. N' wird letztendlich, wie unten gezeigt, bestimmt, was dann eine vollständig konstruierte Entfernung zu dem Satelliten ergibt.
N^• wird bei der Formulierung der CMRx-Trägerdaten benutzt. Die Pseudoentfernung wird zur Ableitung eines Werts für N^• wie folgt benutzt: N• = Rja (tk) – Θja (tk)wobei

a: den Empfänger bezeichnet
j: den Satelliten bezeichnet
t_k: Zeit, zu der man die Entfernung bestimmen möchte
R: die Empfänger-Pseudoentfernungsmessung N^•.
Q: beobachtete/gemessene Trägerphase.

Somit kann man nun eine Art Trägerentfernung zu dem Satelliten formulieren: Θ'ja (t) = Θja (t) + N• wobei

a: den Empfänger bezeichnet und
Q': die konstruierte Trägerentfernung.

Diese „konstruierte Trägerentfernung” ist keine wahre Entfernung wie unter Benutzung einer Pseudoentfernungsbeobachtung konstruiert. Sie ist daher weniger akkurat als die Trägerentfernung, und einige der Pseudoentfernungsfehler verhalten sich anders als diejenigen im Träger. Der Wert stellt jedoch eine annähernde Entfernung zu dem Satelliten in den Trägerzyklen dar. Weil dieser Wert von N^• von Messung zu Messung konstant ist, besteht außerdem die Gesamtauswirkung dahingehend, dass der konstante Wert N' zu allen Messungen zu diesem Satellit hinzugefügt wurde.
CMRx erzeugt den gesendeten Wert an jeder Nachricht für jeden Satelliten für jede Trägerbeobachtung unter Benutzung der folgenden Gleichung: CMRxTräger = Rja (t) – Θ'ja (t)
Das heißt, der in der CMRx-Nachricht gespeicherte CMRx-Träger ist die gemessene Pseudoentfernung minus dieser „konstruierten Trägerphase”. Dieses Verfahren funktioniert, weil der Empfänger die Pseudoentfernung des Senders wie zuvor beschrieben rekonstruieren kann.
Es ist darauf zu achten, dass der Wert von R_a ^j(t) an dem CMRx-Nachrichtkonstruktionsende genau gleich dem durch den CMRx-Decoder wieder hergestellten Wert ist. Daher erzeugt der CMRx-Encoder seinen R_a ^j(t), der paketiert wird und dann zur Erzeugung aller anderen CMRx-Nachrichtenobservablen benutzt wird. R_a ^j(t) an dem CMRx-Nachrichtkonstruktionsende genau gleich dem durch den CMRx-Decoder wieder hergestellten Wert ist. Daher erzeugt der CMRx-Encoder seinen R_a ^j(t), der paketiert wird und dann zur Erzeugung aller anderen CMRx-Nachrichtenobservablen benutzt wird.
Iono-/Tropo-Fensterfunktion
Iono- und Troposphären-Fensterfunktion ermöglichen die Reduzierung des Werts der zuvor bezeichneten Fenstergröße. Die Codeobservablen werden im Wesentlichen dazu benutzt, um die Ionosphäre zu berechnen. Eine gemittelte vertikale Ionosphäre wird durch Kartierung jeder unabhängig berechneten Ionosphäre zu der Vertikalen aufgestellt und nachfolgender Formulierung des Mittels:
In der ersten Gleichung ist die linke Seite der Multiplikation eine industriebekannte Gleichung zur Berechnung der Ionosphäre aus der Codephase. Die rechte Seite ist eine Kartierungsfunktion zur Kartierung der Ionosphäre, basierend auf den Satellitenerhebungen, auf einen vertikalen Wert.
Für die Troposphäre wird ein Berechnungsalgorithmus benutzt, der weitgehend dem abgeänderten Hopfield-Modul entspricht, einem Modell, das grundsätzlich in GPS-Verfahren benutzt wird. Im Gegensatz zu Hopfield, wonach eine Vielzahl von Umgebungsinputs (wie Temperatur, Druck und relative Luftfeuchtigkeit) zugelassen werden, stellt dieses Verfahren hier Berechnungen aufgrund von Standardwerten für Temperatur, Druck und relative Luftfeuchtigkeit auf. Dies ist gar nicht so unerwünscht, wie man denken könnte, da die meisten GPS-Empfänger keine Umgebungssensoren haben. Daher benutzen sie Standardwerte, wenn sie das Hopfield-Modell anwenden. Weiterhin ist die wahre Atmosphäre keine lineare Regressionstroposphäre, wie im Hopfield-Modell vorgebildet, selbst wenn die meisten GPS-Empfänger Umgebungssensoren hätten. Das heißt, dies sind Modelle, die eine konsistente Atmosphäre unterstellen, während die wahre Atmosphäre Schichten variierender Temperatur und Wasserinhalte aufweist. Somit ist das Vorhandensein von Sensoren in den GPS-Empfängern bestenfalls lediglich ein lokales Bodenmaß.
Der CMRx-Encoder macht die Iono-/Troposphären-Fensterfunktion durch Berechnung und nachfolgende Entfernung der Ionosphäre und Troposphäre, wie oben beschrieben. Zu beachten ist, dass der CMRx-Encoder die gemittelte vertikale Ionosphäre als Teil der Nachricht an den Rover sendet. Der Encoder kartiert sich auf die Erhebung des Satelliten zurück und entfernt sodann diesen Wert von dem Code und den Trägerdaten. Dieses ganze Verfahren reduziert die Unsicherheit der Observablen und kann somit die Fenstergröße reduzieren.
CMRx sieht sich die Residuale an und passt die Fenstergröße an, um die Residuale und andere Faktoren (z. B. IODE-Unterschiede zwischen dem Encoder und Decoder) zu berücksichtigen. Eine Anpassung in der Fenstergröße führt zu einer Änderung in der Anzahl der gesendeten Bits: d. h. je kleiner die Residuale, umso weniger Bits sind erforderlich, um die Daten zu senden. Der CMRx-Encoder sendet die Fenstergröße auf einer Basis eines Frequenz-/Verfolgungstyps als Teil der Nachricht. Bei Benutzung dieses Verfahrens erfordert die Fenstergröße pro Frequenz-/Verfolgungstyp 2 Bits, was über die Anzahl der Satelliten in der Nachricht amortisiert wird, wobei die Möglichkeit besteht, dass die Größe jeder Observablen für diesen Frequenz-/Verfolgungstyp jeweils um 3 Bits reduziert wird. Im Durchschnitt führt dies zu einer Verringerung von ungefähr 2,5 Bits pro Frequenz-/Verfolgungstyp. Beispiel: Wenn 9 Satelliten sowohl Code als auch Träger für L1 C/A, L2E und L5 berichten, führt dies zu 6 zusätzlichen Bits (d. h. Speicherung von 2-Bit-Werten für die Fenstergröße, eins für L1 C/A, eins für L2E und eins für L5) mit einer Verringerung von 162 Bits für die Observablen (d. h. 3 Bits verringert für Träger und Code auf jeweils L1, L2 und L5 [d. h. 18 Bits pro Satellit]). Der Gesamtgewinn ist 156 Bits (d. h. 162 – 6).
Komprimierungsalgorithmus
Wegen der Modi, Optionen und der Anzahl der Satelliten pro Epoche variiert die Größe des Beobachtungsblocks. Eine Beschreibung des Komprimierungsverfahrens wird unten dargelegt.
Die Pseudoentfernung des Referenz-Frequenz-/Verfolgungstyps wird in die Nachricht paketiert. Dies deshalb, weil diese Beobachtung (im Folgenden als „RC” bezeichnet) als Basis für die Paketierung aller anderen Beobachtungen, die in der CMRx-Nachricht gespeichert werden, benutzt wird. Die Paketierung der Referenz-Pseudoentfernungsbeobachtung erfordert, dass die Quellen-RC-Beobachtung in einer Entfernung von 19000000,005 m bis 27053063,670 m liegt. Wenn der Empfänger-Taktgeber-Versatz verursacht, dass die RC-Werte außerhalb dieser Grenzen fallen, erzeugt das Komprimierungsverfahren einen Fehler und zeigt an, dass der RC-Wert außerhalb des Grenzbereichs liegt.
a. Standard Komprimierung von RC (Code-Komprimierungsstufe 2)
Ausgangsalgorithmus:

1) Einstellung RC = Ausgangsempfänger Codephasenbeobachtung als Referenz bezeichnet
2) RCt = RC auf die nächsten 1,5 cm runden.
3) RCt speichern zur Benutzung bei der Paketierung anderer Observablen.

Algorithmus zur Erstellung von RC zur Paketierung:

1) RCp = RCt·100.0
1) RCp = RCp – 1900000000,500
2) RCp = RCp/1,5
3) RCp = RCp auf die nächste Ganzzahl runden. -- Nun ist 0 <= RCp <= 536,870,911 (d. h. 2^29 – 1)

b. Standard Komprimierung von RC (Code-Komprimierungsstufe 7)
Der obige Algorithmus unterstellt Komprimierungsstufe 2. Der Observablen-Skalierungsfaktor und die Anzahl der paketierten Bits sind für jede Komprimierungsstufe unterschiedlich. Wenn z. B. die Komprimierungsstufen-Bits den Wert 7 enthalten, dann würde RC unter Benutzung von 24 Bits gespeichert und hätte eine Skalierung von 0,480 Meter. Das Folgende zeigt einen Algorithmus, wenn eine Komprimierungsstufe 7 benutzt wird:
Ausgangsalgorithmus:

1) Einstellung RC = Ausgangsempfänger Codephasenbeobachtung als Referenz bezeichnet.
2) RCt = RC auf die nächsten 0,480 cm abrunden.
3) RCt speichern zur Benutzung bei der Paketierung anderer Observablen.

Algorithmus zur Erstellung RC zur Paketierung:

1) RCp = RCt·100.0
2) RCp = RCp – 18999999,840
3) RCp = RCp/48,0
4) RCp = RCp auf die nächste Ganzzahl runden. -- Nun ist 0 <= RCp <= 16,777,215 (d. h., 2^24 – 1)

Beim Vergleich des Algorithmus bei einer Komprimierungsstufe von 7 mit demjenigen von Stufe 2, ist folgendes zu beachten:

a) Die Skalierung der Referenzcodephase ist 0,480 Meter;
b) Die Zahl der verfügbaren Bits für die Referenzcodephase ist 24.
c) Der niedrigste für die Referenzcodephase zulässige Wert ist nun 18999999,840 Meter (d. h. das nächste Mehrfache von 0,480 zu den original 19000000,005 Meter) und
d) Der größte zulässige Wert basiert auf dem Wert 2²⁴ – 1.

c. Erweiterte Komprimierung von RC (Code-Komprimierungsstufe 2)
Obige zwei Algorithmen nehmen an, dass der erweiterte Komprimierungsmodus nicht benutzt wird. Wenn der erweiterte Komprimierungsmodus aktiviert ist, wird eine mehrdeutige Form der RC-Beobachtungen paketiert. Der Algorithmus der folgt, zeigt das Komprimierungsverfahren, wenn die mehrdeutigen Formen von RC benutzt werden.
Algorithmus zur Erzeugung der mehrdeutigen Form von RC zum Paketieren:

1) Einstellung des Ambiguitätsfensters auf ein Mehrfaches von 1,5 Zentimeter (d. h. die niedrigste Granularität unserer Komprimierung). AmbigSize = 0.015·215
2) Einstellung von RCScale, um den Wert von jedem Bit zu repräsentieren, das paketiert werden soll. Zum Beispiel ist RCScale für die Code-Komprimierungsstufe 2 0,015 Meter, während RCScale für Stufe 7 0,480 Meter ist.
3) Berechnung des mehrdeutigen RC-Werts (d. h. Entfernung aller ganzen Fenster von der Entfernung). FracRC = RC/AmbigSize; FracRC = FracRC – (lang)(FracRC); FracRC = FracRC·AmbigSize;
4) Den Bruchteil (d. h. den mehrdeutigen RC) in komprimierbare Form stellen. RCp = (lang)(FracRC/RCScale + 0.5);

Wenn der Iono-/Tropo-optimierte erweiterte Komprimierungsmodus aktiviert ist, wie in 21 gezeigt, wird der Iono-/Tropo-optimierte Fensterblock genau vor den Beobachtungsdaten hinzugefügt. Dieser Block beschreibt die gemittelte Ionosphäre entfernt von den Beobachtungsdaten und die Größe der Datenfenster für jeden in der Nachricht gespeicherten Beobachtungstyp. Diese „Fenster” stellen die Größe der Ambiguitäten dar, die von diesen paketierten Ausgangsdaten entfernt wurden, d. h. das was paketiert wird, ist das Gleitkomma-Arithmethik-Modul [fmod] der Beobachtungsdaten durch die Fenstergröße. Auf diese Art und Weise kann der Dekomprimierungsstandort die Anzahl der ganzen Fenster bestimmen, die von den Daten entfernt wurden und diese zu den entpaketierten Daten wieder hinzufügen, um so die originalen Ausgangsdaten wieder herzustellen.
Der grundsätzliche Algorithmus zur Bestimmung der Bits, die die Iono-/Tropo-erweiterte Fensterkomprimierung beschreiben, hängt ab von der Kenntnis (i) der Position der Senderstation (bis zu innerhalb von 50 Metern), (ii) die übertragenen Orbits jedes teilnehmenden Satelliten; (iii) mindestens die duale Frequenz der Codedaten; (iv) den nominal zu erwartenden und den zu erwartenden Schlimmstfall der Ionosphäre und Troposphäre und (v) den nominal zu erwartenden und den zu erwartenden Schlimmstfall des Mehrwegs.
Weil diese Werte bekannt sind und/oder durch sowohl den Komprimierungsalgorithmus als auch den Dekomprimierungsalgorithmus berechnet werden können, können sowohl der Sender als auch der Empfänger der Daten diese Werte berechnen. Dies trifft auch dann zu, wenn die Stationen weit auseinander liegen. Das heißt, es gibt Zeiten zu denen die durch die Komprimierung übertragenen Orbits leicht von den Dekomprimierungsalgorithmen abweichen: z. B. wenn eine Seite vor der anderen eine Orbitänderung empfängt (d. h. eine neue IODE).
Der erste Schritt ist die Bestimmung der Größen der Iono-/Tropo-optimierten Fenster. Es sind diese Größenwerte, die als Teil der Bits des Iono-/Tropo-optimierten Fensterblocks gespeichert werden. Als Teil dieses Verfahrens werden die berechneten Werte der Ionosphäre und Troposphäre von den Ausgangsbeobachtungsdaten entfernt. Die Entfernung dieser Werte von den Ausgangsbeobachtungsdaten ermöglicht eine wesentlich verkleinerte Fenstergröße und reduziert so die Gesamtbits pro paketiertem Satellit. In diesem Verfahren wird eine unabhängige Fenstergröße für jeden Beobachtungstyp in der Nachricht bestimmt. Die für einen Beobachtungstyp ausgewählte Fenstergröße wird dann für alle Satelliten dieser Epoche benutzt. Diese Fensterinformation wird als Teil des Iono-/Tropo-optimierten Fensterblocks gespeichert.
Zur Bestimmung der Größen der Ambiguitätsfenster werden berechenbare Elemente der Beobachtungsdaten von den Ausgangsbeobachtungen entfernt. Unter Benutzung der Dualfrequenz-Codebeobachtungen aller Satelliten wird ein gemittelter beobachteter vertikaler Ionosphärenwert berechnet. Dieser wird auf die nächste Ganzzahl gerundet, und der gerundete Wert wird als Teil des Iono-/Tropo-optimierten Fensterblocks gespeichert. Der gerundete Wert wird von dem Ausgangscode und den Trägerbeobachtungen für jeden Satellit entfernt. Dann: w2 (d. h. der gemittelte vertikale Ionosphärenwert wird auf den Erhebungswert kartiert, der mit jedem Satelliten assoziiert ist, und dieser kartierte Wert wird von den Beobachtungen entfernt). Dann wird eine Troposphärenberechnung von allen Beobachtungen von jedem Satelliten entfernt.
Um die Fenstergrößen für die Codephasendaten zu bestimmen, werden vorgegebene, bekannte Werte für die Positionen (i) und (ii) oben benutzt, um ein Modell der beobachteten Daten zu erstellen. Dieses Model berücksichtigt den Satelliten-Taktgeber und den Empfänger-Taktgeber. Für jeden Codephasentyp werden Coderesiduale durch Abgrenzung der modellierten Daten von den neu geformten Iono-/Tropo-Daten geformt. Diese Residualen berücksichtigen den Teil der Code-Beobachtungsdaten, die durch den Einzelempfänger nicht berechnet werden können. Da das Dekomprimierungsverfahren diese selben bekannten Werte benutzt, kann es dasselbe Troposphärenmodell, denselben Satelliten-Taktgeber und denselben Empfänger-Taktgeber berechnen. Dem Dekomprimierungsverfahren wird auch der Ionosphärenwert gegeben, der für jede Beobachtung entfernt wurde. Mit diesen berechneten Werten kann die Dekomprimierungsseite dann die Originaldaten wieder herstellen. Somit sagen diese berechneten Coderesiduale auf der Komprimierungsseite aus, wie groß das Codephasenfenster sein muss. Z. B. werden die L1 C/A Residuale, wenn L1 C/A in der Nachricht vorhanden sein soll, für alle Satelliten der Epoche mit den Fenstergrenzen von 4 möglichen L1 C/A-Fenstern verglichen (die Größe dieser wird gleich aufgezeigt), um das Maximalfenster für L1 C/A zu bestimmen. Die L2c Residuale werden gleichermaßen, wenn L2c in der Nachricht vorhanden sein soll, für alle Satelliten der Epoche mit den Fenstergrenzen von 4 möglichen L2c Fenstern verglichen (die Größe dieser wird gleich aufgezeigt), um das Maximalfenster für L2c zu bestimmen. Dies wird dann für jede Codephasenbeobachtung in der Nachricht in ähnlicher Weise durchgeführt.
Die Größen der Codephasenfenster werden in Abhängigkeit von der Komprimierungsstufe berechnet. Das Codephasenfenstergrenzen und Ambiguitätsgrößen der Codefenster werden wie unten gezeigt berechnet. Die Anzahl der Bits und Skalierungsfaktoren werden in den C/C++ ähnlichen Algorithmen bereitgestellt, die in späteren Abschnitten folgen. Die Notation RC bedeutet die Referenz-Codephase für die Nachricht, und RX bedeutet alle anderen Nicht-Referenz-Codephasen für die Epoche.
Fenster 1 (Index 0):

LowEnd_RC [0] = –(pow (2.0, Bits_for_Ambiguous_RC – 1)·RC_Scale_Factor)
HighEnd_RC [0] = (pow (2.0, Bits_for_Ambiguous_RC – 1) – 1.0)·RC_Scale_Factor
LowEnd_RX [0] = –(pow (2.0, Number_of_Bits_for_RX – 1)·RX_Scale_Factor)
HighEnd_RX [0] = (pow (2.0, Number_of_Bits_for_RX – 1) – 1.0)·RX_Scale_Factor

Fenster 2 (Index 1):

LowEnd_RC [1] = –(pow (2.0, Bits_for_Ambiguous_RC – 2)·RC_Scale_Factor)
HighEnd_RC [1] = (pow (2.0, Bits_for_Ambiguous_RC – 2) – 1.0)·RC_Scale_Factor
LowEnd_RX [1] = –(pow (2.0, Number_of_Bits_for_RX – 2)·RX_Scale_Factor)
HighEnd_RX [1] = (pow (2.0, Number_of_Bits_for RX – 2) – 1.0)·RX_Scale_Factor

Fenster 3 (Index 2):

LowEnd_RC [2] = –(pow (2.0, Bits_for_Ambiguous_RC – 3)·RC_Scale_Factor)
HighEnd_RC [2] = (pow (2.0, Bits_for_Ambiguous_RC – 3) – 1.0)·RC_Scale_Factor
LowEnd_RX [2] = –(pow (2.0, Number_of_Bits_for_RX – 3)·RX_Scale_Factor)
HighEnd_RX [2] = (pow (2.0, Number_of_Bits_for_RX – 3) – 1.0)·RX_Scale_Factor

Fenster 4 (Index 3):

LowEnd_RC [3] = –(pow (2.0, Bits_for_Ambiguous_RC – 4)·RC_Scale_Factor)
HighEnd_RC [3] = (pow (2.0, Bits_for_Ambiguous_RC – 4) – 1.0)·RC_Scale_Factor
LowEnd_RX [3] = –(pow (2.0, Number_of_Bits_for_RX – 4)·RX_Scale_Factor)
HighEnd_RX [3] = (pow (2.0, Number_of_Bits_for_RX – 4) – 1.0)·RX_Scale_Factor

Somit würden sich bei einer Komprimierungsstufe 3 die folgenden Fenstergrößen ergeben:
Fenster 1 (Index 0):

LowEnd_RC [0] = –245,76 m
HighEnd_RC [0] = 245,64 m
LowEnd_RX [0] = –61,44 m
HighEnd_RX [0] = 61,32 m

Fenster 2 (Index 1):

LowEnd_RC [1] = –122,88 m
HighEnd_RC [1] = 122,76 m
LowEnd_RX [1] = –30,72 m
HighEnd_RX [1] = 30,60 m

Fenster 3 (Index 2):

LowEnd_RC [2] = –61,44 m
HighEnd_RC [2] = 61,32 m
LowEnd_RX [2] = –15,36 m
HighEnd_RX [2] = 15,24 m

Fenster 4 (Index 3):

LowEnd_RC [3] = –30,72 m
HighEnd_RC [3] = 30,60 m
LowEnd_RX [3] = –7,68 m
HighEnd_RX [3] = 7,56 m

Bei der derzeitigen Komprimierungsstufe kann der Komprimierungsalgorithmus die Minimal- und Maximalfenstergrößen für das Fenster zu jedem Index berechnen. Die RC Residuale für alle Satelliten der Epoche werden dann mit den Fenstergrenzen der 4 möglichen RC-Fenster verglichen, um das kleinste Fenster zu bestimmen, das die Residualen enthalten kann (d. h. für alle Referenzcode-Phasenbeobachtungen). Gleichermaßen werden dann die RX-Residualen für alle Satelliten der Epoche mit den Fenstergrenzen der 4 möglichen RX-Fenster verglichen, um das kleinste Fenster zu bestimmen, das diese Residualen halten kann (d. h. für alle Nicht-Referenzcode-Phasenbeobachtungen). Diese Residualen werden für dieses Vergleichsverfahren auf einen leicht höheren Wert skaliert.
Die tatsächliche Komprimierung der RC-Daten folgt dem Beschriebenen, jedoch mit zwei Ausnahmen. Die erste Ausnahme ist, dass die oben beschriebenen neu gebildeten Iono-/Tropo-freien Beobachtungen paketiert sind. Die zweite ist eine Änderung bei der Berechnung des Fenster-Ambiguitätsgrößenwerts. Das heißt man benutzt: AmbigSize = RC_Scale_Factor·2^(Bits_for_Window)
Wenn beispielsweise die Komprimierungsstufe auf Stufe 3 eingestellt wäre und der ausgewählte RC-Fensterindex 2 wäre, dann würde AmbigSize (Ambiguitätsgröße) wie folgt berechnet werden: AmbigSize = 0.120·2(12-2)
Die Pseudoentfernung auf der Nicht-Referenzcodephase („RX”) ist paketiert, wenn die Beobachtungsfolge anzeigt, dass die RX-Observable paketiert werden soll.
d. Standard Komprimierung von RX (Komprimierungsstufe 2)
In dem folgenden Algorithmus wurde die Komprimierungsstufe zwei ausgewählt. Das heißt, dass die Anzahl der benutzten Bits für die Nicht-Referenzcodephase 13 Bits ist, der zu paketierende Wert RC – RX ist, der Wert einen niedrigsten Wert von –40,95 Meter hat.
Algorithmus zur Erstellung von RX zur Paketierung:

1) Einstellung RXt = RX auf die nächsten 1,5 cm abrunden.
2) RXp = (RXt – RCt)/0,015
3) RXp = RXp auf die nächste Ganzzahl abrunden.
4) Bestätigung, dass –2730 <= RXp <= 5461
5) RXp = RXp – (–2730) -- Nun ist 0 <= RXp <= 8191 (d. h. 2¹³ – 1)
6) WENN (RXp == 0) DANN
6.1) RXp = 1 da Null die besondere Bedeutung von nicht vorhanden hat.

e. Standard Komprimierung von RX (Komprimierungsstufe 6)
Der Algorithmus setzte die standardmäßig eingestellte Komprimierungsstufe (d. h. Stufe 2) voraus. Insbesondere sind der zu beobachtende Skalierungsfaktor und die Anzahl der paketierten Bits für jede Komprimierungsstufe verschieden. Wenn beispielsweise die Komprimierungsstufenbits den Wert 6 enthalten, dann würde RX unter Benutzung von 9 Bits gespeichert werden und hätte eine Skalierung von 0,240 Meter. Bei Benutzung einer Komprimierungsstufe von 6 gilt:
Algorithmus zur Erstellung von RX zur Paketierung:

1) Einstellung RXt = RX auf die nächsten 24,0 cm runden.
2) RXp = (RXt – RCt)/0,240
3) RXp = RXp auf die nächste Ganzzahl runden.
4) Bestätigung, dass –171 <= RXp <= 340
5) RXp = RXp – (–171) -- Nun ist 0 <= RXp <= 511 (d. h. 2⁹ – 1)
6) WENN (RXp == 0) DANN
6.1) RXp = 1 da Null die besondere Bedeutung von nicht vorhanden hat.

f. Iono-/Tropo-optimierte erweiterte Komprimierung von RX
Um die Ambiguitätsfenstergröße für RC zu berechnen. Für RX ist die Berechnung wie folgt AmbigSize = RX_Scale_Factor·2^(Bits_for_Window)
Wenn beispielsweise die Komprimierungsstufe auf Stufe 3 eingestellt wäre und der ausgewählte RC-Fensterindex 2 wäre, dann würde AmbigSize wie folgt berechnet:
g. Trägerphasendaten
Die Trägerphase für einen gegebenen Frequenz-/Verfolgungstyp („Lf”) wird paketiert, wenn die Beobachtungsfolge anzeigt, dass diese Observable zu paketieren ist. Die Lf-Observable, die paketiert wird, basiert auf dem Wert „RCt”.
h. Standardkomprimierung der Trägerdaten (Komprimierungsstufe 2)
Im folgenden Algorithmus wurde die Komprimierungsstufe zwei ausgewählt. In diesem Modus ist die Anzahl der Bits pro Träger 18, und die Größe des Träger-Ambiguitätsfensters ist 4000 Zyklen. Vor der Paketierung ist an der ersten Epoche von Daten einzustellen:

1) Einstellung Nf[sat] = 999,999,999 für alle „sat” [1 ... 32]

Algorithmus zur Erstellung von Lf zur Paketierung:

bYf sei = die Wellenlänge der Lf-Daten (in Meter/Zyklus).

1) Einstellung Lf = Trägerbeobachtungen vom Frequenz-/Verfolgungstyp „f”.
2) WENN (fabs (RCt – bYf·(Nf[sat] + Lf)) > 2000·bYf) DANN
2,1) Nf[sat] = (long) ((RCt – bYf·Lf)/bYf) – 1000 Zyklen.
3) Lf = Lf + Nf[sat]
4) Lf = fmod (Lf, 4000)
5) Lfp = Lf/(4000/2¹⁸)
6) Lfp = Lfp auf die nächste Ganzzahl runden
7) WENN (Lfp == 0) DANN
7.1) Lfp = 1 da Null die besondere Bedeutung von nicht vorhanden hat. Beachte, dass die Berechnungen der Schritte 5 und 6 sich leicht unterscheiden, um eine Entfernung von 1 bis 2^18-1 zu ermöglichen: d. h. der Nullwert wird freigelassen und bedeutet schlechte Daten. Diese sind wie folgt:
5') Lfp = Lf/(4000/(2¹⁸ – 1))
6') Lfp = Lfp auf die nächste Ganzzahl runden
6'') Lfp += 1

i. Standardkomprimierung der Trägerdaten (Komprimierungsstufe 5)
Der obige Algorithmus unterstellte eine Komprimierungsstufe von 2, der Observablen-Skalierungfaktor und die Anzahl der paketierten Bits sind jedoch für jede Komprimierungsstufe unterschiedlich. Wenn die Komprimierungsstufenbits beispielsweise den Wert 5 enthalten, dann wird der Lf-Träger unter Benutzung von 15 Bits gespeichert (mit einer Trägerfenstergröße von 4000 Zyklen). Das Folgende zeigt einen Algorithmus, wenn eine Komprimierungsstufe von 5 benutzt wird.
Vor der Paketierung ist an der ersten Epoche von Daten einzustellen:

1) Einstellung Nf[sat] = 999,999,999 für alle „sat” [1 ... 32]
1)

Algorithmus zur Erstellung von Lf zur Paketierung:

bYf sei = die Wellenlänge der Lf-Daten (in Meter/Zyklus).

1) Einstellung Lf = Trägerbeobachtung vom Frequenz-/Verfolgungstyp „f”.
2) WENN (fabs (RCt – bYf·(Nf[sat] + Lf)) > 2000·bYf) DANN -- BEACHTE: In diesem Modus wird 1/4 der Fenstergröße entfernt (d. h. 1000 Zyklen), um den Wert vom Rand des Fensters entfernt zu halten (da Iono/Tropo noch nicht berücksichtigt wurde).
2.1) Nf[sat] = (lang) ((RCt – bYf·Lf)/bYf) – 1000 Zyklen.
3) Lf = Lf + Nf[sat]
4) Lf = fmod (Lf, 4000)
5) Lfp = Lf/(4000/215)
6) Lfp = Lfp auf die nächste Ganzzahl runden
7) WENN (Lfp == 0) DANN
7.1) Lfp = 1 da Null die besondere Bedeutung von nicht vorhanden hat.

Beachte: In der Realität weicht die Berechnung der Schritte 5 und 6 etwas voneinander ab, um eine Entfernung von 1 to 2^18-1 zu ermöglichen: d. h. der Nullwert wird freigelassen und bedeutet schlechte Daten. Diese sind wie folgt:

5') Lfp = Lf/(4000/(2¹⁵ – 1))
6') Lfp = Lfp auf die nächste Ganzzahl runden
6'') Lfp += 1

Beim Vergleich von einem Algorithmus mit einer Komprimierungsstufe 5 mit einem von Stufe 2, ist zu beachten:

a) Die Anzahl der verfügbaren Bits für die Lf-Trägerphase ist 15, und
b) Der benutzte Skalierungsfaktor, um die Lf-Träger in dessen Bitrepräsentation zu bekommen, ist nun „Lf/((4000/215) – 1)”.

In dieser Ausführungsform wurden diese Werte generalisiert aufgrund von Nachschlagetabellen, die durch den spezifizierten Komprimierungsstufenmodus indiziert wurden.
j. Iono-/Tropo-optimierte erweiterte Komprimierung von Trägerdaten
Beim ersten Durchgang wird erstrebt, den Träger an die Codebebachtung anzugleichen, indem die Ganzzahl-Ambiguität für jeden Satelliten und Trägerfrequenz mit Bezug zu den Referenzcodedaten (RC) berechnet werden. Im Weiteren wird derselbe Ambiguitätswert für die folgenden Epochen bis zum Eintreten eines Zyklusschlupfs genommen (oder es besteht eine Verletzung, wodurch die Kombination von N und dem Träger minus der Codebeobachtung uns dazu zwingt, die Fenstergrenzen zu erweitern).
Zur Bestimmung der Fenstergrößen für die Trägerphasendaten (d. h. nur das Fenster für jeden Trägerbeobachtungstyp für einen Satelliten) benutzen wir die Referenzcodephase (RC). Trägerresiduale werden durch Abgrenzung der RC-Observablendaten gebildet und die neu gebildeten Iono-/Tropo-freien Trägerobservablen (kombiniert mit der für diesen Satelliten bestimmten Ambiguität und Frequenz-/Verfolgungstyp). Da das Dekomprimierungsverfahren dieselben bekannten Werte benutzt (d. h. Referenzposition und Orbitaldaten), kann es dasselbe Troposphäremodell und Satelliten-Taktgeber berechnen. Dem Dekomprimierungsverfahren wird auch der für jede Beobachtung entfernte Ionosphärenwert gegeben. Mit diesen berechneten Daten kann die Dekomprimierungsseite daher die Originaldaten wieder herstellen. Auf der Komprimierungsseite sagen diese Trägerresiduale daher aus, wie groß die Fenster sein müssen. Die Lf Residuale für alle Satelliten dieser Epoche werden dann mit den Fenstergrenzen von 4 möglichen Lf-Fenstern verglichen (deren Größen sogleich gezeigt werden), um das Maximalfenster für Lf zu bestimmen. Gleichermaßen durchlaufen die Daten von allen anderen Trägerbeobachtungen (d. h. Frequenz-/Verfolgungstypen für jeden Satelliten) dieses Verfahren. um zu bestimmen, welche der 4 möglichen Fenster für jeden Typ das Maximum repräsentieret.
Das Trägerfenster basiert auf der Standardkomprimierungsmodus-Trägerfenstergröße (d. h. 4000 Zyklen). Nach dem Iono-/Tropo-optimierten erweiterten Komprimierungsansatz gibt es vier Fenster: dCarAmbWin [0] = 4000; dCarAmbWin [1] = dCarAmbWin [0]/2,0; dCarAmbWin [2] = dCarAmbWin [0]/4,0; dCarAmbWin [3] = dCarAmbWin [0]/8,0;
Daher ist der Algorithmus für die Komprimierung der Lf-Trägerphase nach der Iono-/Tropo-optimierten erweiterten Komprimierung:
Vor der Paketierung an den ersten Epochendaten einstellen:

1) Einstellung Nf[sat] = 999,999,999 für alle „sat” [1 ... 32]

Algorithmus zur Erstellung von Lf zur Paketierung:

bY1 sei = die Wellenlänge von Lf (in Meter/Zyklen).

1) Einstellung Lf = Iono/Tropo-free Lf
2) Einstellung dCarCycLfWin = dCarAmbWin [ausgewähltes Lf-Fenster]
3) Einstellung 1NumLfBits = Anzahl der Bits für Lf-Fenster
4) Einstellung dLfScale = pow (2,0, 1NumLfBits-1);
5) WENN (fabs (RCt – bYf·(Nf[sat] + Lf)) > (dCarCycLfWin/2.0)·bf1) DANN -- BEACHTE: In diesem Modus wird 1/4 oder Fenstergröße nicht entfernt, da wir Iono/Tropo in Betracht gezogen haben.
5.1) Nf[sat] = (lang) ((RCt – bYf·Lf)/bYf)
6) Lf = Lf + Nf[sat]
7) Lf = fmod (Lf, dCarCycLfWin)
8) Lfp = Lf/(dCarCycLfWin/dLfScale)
9) Lfp = Lfp auf die nächste Ganzzahl runden
10) WENN (Lfp == 0) DANN
10.1) Lfp = 1 da Null die besondere Bedeutung von nicht vorhanden hat.

k. Textnachrichtenblock
Wenn der Wert Textblockpräsenz (TBP) des CMRx GPS-Beobachtungs-Headerblocks (7) anzeigt, dass eine Nachricht vorhanden ist, ist dieser Bock in der CMRx GPS-Beobachtungsdatennachricht vorhanden. Eine besondere Verschlüsselung wird benutzt zur Unterscheidung zwischen den Textnachrichten, die für den Endbenutzer bestimmt sind und den Nachrichten, die zur Verarbeitung durch das Endbenutzersystem bestimmt sind.
Die grundsätzliche Form des Textnachrichtenblocks wird in 32 gezeigt. Dieser wird in drei Abschnitte geteilt:

1) Nachrichtenlänge (6 Bits) Diese Bits definieren die Länge des Nachrichtenkörperteils des Blocks. Der Wert wird in Einheiten von 4 Bytes ausgedrückt, wobei 000000 4 Bytes und 111111 256 Bytes bedeutet.
2) Nachrichtencode (4 Bits) Der Nachrichtencode wird zur Unterscheidung besonderer Nachrichten von grundsätzlichen Benutzertextnachrichten verwendet. Bei Einstellung auf 0000 enthält der Nachrichtenkörper das Set der ASCII-Charakter, die auf der Anzeige des Empfängers anzuzeigen sind. Wenn der Code auf einen anderen Wert eingestellt ist, bezweckt dies eine Nachricht mit speziellem Zweck definiert durch den Umsetzer der CMRx-Nachricht. Zum Beispiel kann ein Nachrichtencodewert von 0005 bedeuten, dass der Nachrichtenkörper GIS-Barcodeinformation, etc. enthält.
3) Nachrichtenkörper Die Interpretation des Nachrichtenkörpers wird definiert durch den Nachrichtenlängeteil des Nachrichtenkörpers.

Das Voranstehende war eine detaillierte Beschreibung eines Kommunikationssystems zur Ermöglichung schnellerer, niedrigerer Bandbreiten, Kommunikation unter GNSS-aktivierten Verarbeitungselementen und Vorrichtungen. Obwohl zahlreiche Details mit Bezug zu der spezifischen Umsetzung des Systems bereitgestellt wurden, wird es begrüßt, dass der Schutzumfang der Erfindung durch die angefügten Ansprüche definiert wird.
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 Nicht-Patentliteratur

- N. Talbot, ”Compact Data Transmission Standard for High-Precision GPS,” Proceedings of ION-GPS-96, Kansas City, Missouri, 861–871 (1996) [0004]

Claims

Ein Nachrichtenformat für die Übertragung von Daten zwischen einer ersten globalen Navigationssatellitensystem-(GNSS)-Vorrichtung an einem ersten Standort zu einer zweiten GNSS-Vorrichtung an einem zweiten Standort, bestehend aus: einem Nachrichtenidentifizierungsblock mit einem Nachrichtenlängenblock zur Spezifizierung einer Nachrichtenlänge und einem Nachrichtentypblock zur Spezifizierung eines Nachrichtentyps und einem Nachrichtenkörper.
Nachrichtenformat nach Anspruch 1, wobei der Nachrichtenlängenblock eine von drei Nachrichtenlängen spezifiziert, von denen Null Bit eine Nachrichtenlänge darstellt.
Nachrichtenformat nach Anspruch 1, wobei der Nachrichtenkörper aus GNSS-Beobachtungsdaten von der ersten GNSS-Vorrichtung besteht.
Nachrichtenformat nach Anspruch 3, wobei die GNSS-Beobachtungsdaten bestehen aus: einem GNSS-Beobachtungs-Headerblock, der mindestens eine Sequenznummer spezifiziert, die sich mit jeder GNSS-Epoche erhöht und einer Epochenzeitbasisbitlänge, die eine Größe in Bits der Epochenzeitbasis spezifiziert.
Nachrichtenformat nach Anspruch 4, wobei der GNSS-Beobachtungs-Headerblock weiterhin aus mindestens einem des Folgenden besteht: ein Epochenfortführungs-Flag zur Kennzeichnung, ob es zusätzliche Nachrichten mit derselben Epochenzeitbasis gibt; ein zyklisches Redundanzprüfungs-Flag zur Kennzeichnung, ob in der Nachricht zyklische Redundanzprüfdaten vorhanden sind und ein kinematisches Flag zur Kennzeichnung, ob sich die erste GNSS-Vorrichtung an einem festen Standort befindet oder sich bewegt.
Nachrichtenformat nach Anspruch 4, weiterhin bestehend aus mindestens einem des Folgenden: einem Bit zur Anzeige des Vorhandenseins des Stationsgesundheitsblocks zur Kennzeichnung, ob in der Nachricht ein Stationsgesundheitsblock vorhanden ist; einem Bit zur Anzeige des Vorhandenseins eines Positionsblocks, zur Anzeige, ob in der Nachricht ein Positionsblock vorhanden ist und einem Standortsinformationsblockbit, zur Anzeige, ob in der Nachricht ein Standortinformationsblock vorhanden ist.
Nachrichtenformat nach Anspruch 6, wobei: wenn das Bit zur Anzeige des Vorhandenseins des Stationsgesundheitsblocks aktiv ist, dann ein Stationsgesundheitsblock in der Nachricht vorhanden ist, der spezifiziert, ob die GNSS-Vorrichtung am ersten Standort verwendbar ist, überwacht wird aber ungesund ist oder überwacht wird und gesund ist; wenn das Bit zur Anzeige des Vorhandenseins des Positionsblocks aktiv ist, dann ist ein Positionsblock vorhanden und zeigt mindestens einen Teil des Breiten- und Längengrades des ersten Standorts an und wenn das Bit zur Anzeige des Vorhandenseins der Standortinformation aktiv ist, dann ist ein Standortinformationsblock vorhanden und zeigt mindestens einen Standortnamen und Stanortcode an.
Nachrichtenformat nach Anspruch 7, weiterhin bestehend aus einem pseudozufälligen Geräuschkapazitätsspezifikationsblock zur Definition einer Anzahl von in einem pseudo-zufälligen Geräuschblock vorhandenen Bits.
Nachrichtenformat nach Anspruch 8, weiterhin bestehend aus einem Bit zur Anzeige des Vorhandenseins eines GNSS-Beobachtungsblocks zur Anzeige, ob in der Nachricht ein GNSS-Beobachtungsblock vorhanden ist.
Nachrichtenformat nach Anspruch 9, wobei, wenn das Bit zur Anzeige des Vorhandenseins eines GNSS-Beobachtungsblocks aktiv ist, ein GNSS-Beobachtungsblock in der Nachricht vorhanden ist, wobei der GNSS-Beobachtungsblock Positionsinformationen für den ersten Standort bereitstellt.
Nachrichtenformat nach Anspruch 10, wobei der GNSS-Beobachtungsblock aus einem Definitionsblock besteht, welcher eine Anzahl von Epochen spezifiziert, über welche die Positionsinformation für den ersten Standort überragen wird und die Positionsinformation für den ersten Standort.
Nachrichtenformat nach Anspruch 11, wobei sich die Anzahl der Epochen von eins bis 2n erstreckt, wobei n eine ganze Zahl ist.
Nachrichtenformat nach Anspruch 4, wobei der GNSS-Beobachtungs-Headerblock aus mindestens einem des Folgenden besteht: einem Epochenblock für den Bruchteil der Sekunden zur Bestimmung, ob Epochenintervalle von unterhalb einer Sekunde vorhanden sind und einem Bezugnahmestationsaliasblock zur Bereitstellung eines Aliases an die erste GNSS-Vorrichtung zur Identifikation von Daten von mehrfachen GNSS-Vorrichtungen, die über einen einzelnen logischen Kanal geliefert werden.
Nachrichtenformat nach Anspruch 10, wobei der GNSS-Beobachtungsblock umfasst: einen Block zur Angabe des Positionsalters zur Anzeige ob der erste Standort sich seit einer vorherigen Nachricht geändert hat und die Positionsinformation für den ersten Standort umfasst Breiten-, Längengrade und die Höhe.
Nachricht nach Anspruch 7, wobei der Standortsinformationsblock weiterhin besteht aus: Standortinformationsdefinitionsbits zur Spezifizierung einer Anzahl von Epochen über welche die Standortinformation übertragen wird und Information über mindestens eine der Antennen, die mit der ersten GNSS-Vorrichtung und der GNSS-Vorrichtung selbst verbunden ist.
Nachrichtenformat nach Anspruch 1, wobei der Nachrichtenkörper besteht aus: einem GNSS-Beobachtungsdaten-Headerblock, der ein Bit zur Anzeige des Vorhandeneins der GNSS-Beobachtungsdaten umfasst, welches bei Aktivierung anzeigt, dass GNSS-Beobachtungen von der ersten GNSS-Vorrichtung im Nachrichtenkörper enthalten sind und wenn das Bit zur Anzeige des Vorhandeneins der GNSS-Beobachtungsdaten aktiviert ist, einem GNSS-Beobachtungsblock, der die GNSS-Beobachtungen des ersten GNSS-Empfängers umfasst.
Nachrichtenformat nach Anspruch 16, wobei der GNSS-Beobachtungsblock weiterhin besteht aus: einem Definitionsblock zur Spezifikation der Information über die GNSS-Beobachtungen; mindestens einem PRN-Wort zur Spezifikation einer Anzahl von Satelliten, für welche die Nachricht Beobachtungen umfasst und einem Ionosphären-/Troposphärenblock zur Bereitstellung von Informationen über die Ionosphären- und Troposphärenkorrektur für die GNSS-Beobachtungen.
Nachrichtenformat nach Anspruch 17, wobei der Ionosphären-/Troposphärenblock umfasst: eine Distanzmessung einer durchschnittlichen vertikalen Ionosphärenkorrektur für Satelliten, für welche gültige Daten zur Verfügung stehen und eine Grundliniendistanz für eine troposphärische Korrektur.
Nachrichtenformat nach Anspruch 17, wobei der Definitionsbock besteht aus: einem Kompressionspegelblock zur Spezifikation eines Kompressionspegels für jeden der Codes und der Trägerdaten; einer Beobachtungsblockgruppe zur Anzeige eines Codephasentyps, der als Referenzcode pro Satellit benutzt wird, für welchen Daten bereit zu stellen sind und einem CNR-Block zur Anzeige einer Anzahl von Satelliten, für welche Daten über das Träger-Rauschverhältnis vorhanden sind.
Nachrichtenformat nach Anspruch 19, wobei der Definitionsblock weiterhin besteht aus: einem ORB-Bit, welches, wenn es aktiviert ist, anzeigt, dass in dem GNSS-Beobachtungsblock Umlaufdaten vorhanden sind und einem SV Cnt-Block zur Spezifikation einer Anzahl von Satelliten, für welche in dem GNSS-Beobachtungsblock jeweils mindestens Daten über das Träger-Rauschverhältnis und Umlaufdaten vorhanden sind.
Nachrichtenformat nach Anspruch 16, wobei der GNSS-Beobachtungsblock weiterhin besteht aus: einem Definitionsblock zur Spezifikation von Informationen über GNSS-Beobachtungen und der Definitionsblock umfasst ein Master-CTC-Bit, welches, wenn es aktiviert ist, anzeigt, dass der Definitionsblock Master-Fortführungsverfolgungszähler-Informationen umfasst.
Nachrichtenformat nach Anspruch 21, wobei der GNSS-Beobachtungsblock für jeden Satellit weiterhin aus Folgendem besteht: einem untergeordneten Beobachtungsanzeigeblock, der, wenn er aktiviert ist, anzeigt, dass Informationen über einen Zeitraum zur Verfügung stehen, über welchen der Satellit verfolgt wurde; einem Schlupfbit zur Kennzeichnung, ob ein Zyklusschlupf aufgetreten ist, wobei das Schlupfbit lediglich vorhanden ist, wenn fortführende Verfolgungszählerinformationen nicht verfügbar sind und Codesignal- und Trägersignalbeobachtungen.
Verfahren zur Kommunikation von Satellitenbeobachtungsinformationen von einer ersten globalen Navigationssatellitensystem-(GNSS)-Vorrichtung an einem ersten Standort zu einer zweiten GNSS-Vorrichtung an einem zweiten Standort, bestehend aus: Bestimmung an der ersten GNSS-Vorrichtung, welche Satelliten in einer Satellitenkonstellation über einen vorher ausgewählten Zeitraum fortführend verfolgt wurden, um dadurch ein erstes Satellitenset zu definieren, welches fortführend über den ausgewählten Zeitraum verfolgt wurde; Bestimmung eines Erhebungswertes für jeden Satelliten, welcher über den vorher ausgewählten Zeitraum fortführend verfolgt wurde, wobei die Erhebungswerte aus einer Messung der Nähe des Satelliten zu einer horizontalen Ebene, die den ersten Standort durchlauft, besteht und Übertragung einer Nachricht von der ersten GNSS-Vorrichtung auf die zweite GNSS-Vorrichtung, die lediglich den Erhebungswert eines untersten Satelliten aus dem ersten Satellitenset umfasst, für welches alle Satelliten mit höheren Erhebungswerten über den ausgewählten Zeitraum fortführend verfolgt wurden, wobei der niedrigste Satellit und das Set aller Satelliten höherer Erhebungswerte, die über den ausgewählten Zeitraum fortführend verfolgt wurden, ein zweites Satellitenset bilden.
Verfahren nach Anspruch 23, wobei jeder der Satelliten in der Satellitenkonstellation Zeitablaufinformationen überträgt, wodurch die erste GNSS-Vorrichtung in die Lage versetzt wird, deren Standort zu bestimmen, wobei das Verfahren an der zweiten GNSS-Vorrichtung weiterhin besteht aus der Benutzung von Zeitablaufinformationen von lediglich dem zweiten Satellitenset.
Verfahren nach Anspruch 24, wobei die Nachricht aus einem ersten Indikator in einem ersten Abschnitt der Nachricht besteht, wobei der erste Indikator spezifiziert, ob ein zweiter Abschnitt der Nachricht die fortlaufende Verfolgungsinformation umfasst.
Verfahren nach Anspruch 25, wobei der zweite Abschnitt der Nachricht den Erhebungswert des niedrigsten Satelliten in dem ersten Satellitenset umfasst.
Verfahren nach Anspruch 26, wobei, wenn der erste Indikator nicht spezifiziert, dass der zweite Abschnitt der Nachricht die fortlaufende Verfolgungsinformation umfasst, dann kein zweiter Abschnitt der Nachricht an die zweite GNSS-Vorrichtung bereitgestellt wird.
Verfahren nach Anspruch 23, wobei die vorherige ausgewählte Zeit aus einem ersten längeren Zeitintervall besteht und das Verfahren weiterhin besteht aus: Bestimmung an der ersten GNSS-Vorrichtung, welche Satelliten in einer Satellitenkonstellation über ein vorheriges kürzeres Zeitintervall fortlaufend verfolgt wurden, um dadurch ein drittes Satellitenset zu definieren, das über das kürzere Zeitintervall fortlaufend verfolgt wurde; Bestimmung eines Erhebungswerts für jeden Satelliten, der fortlaufend über das kürzere Zeitintervall verfolgt wurde, wobei die Erhebungswerte aus einer Messung der Nähe des Satelliten zur horizontalen Ebene bestehen und Übertragung von der ersten GNSS-Vorrichtung an die zweite GNSS-Vorrichtung einer weiteren Nachricht, die nur den Erhebungswert eines niedrigsten Satelliten in dem dritten Satellitenset umfasst, für welches alle Satelliten der höheren Erhebungswerte fortlaufend über das kürzere Zeitintervall verfolgt wurden, wobei der niedrigste Satellit und das Set aller Satelliten der höheren Erhebungswerte, die fortlaufend über das kürzere Zeitintervall verfolgt wurden, einen viertes Satellitenset bilden.
Verfahren nach Anspruch 28, wobei jeder der Satelliten in der Satellitenkonstellation Zeitablaufinformation überträgt, wodurch die erste GNSS-Vorrichtung in die Lage versetzt wird, ihren Standort zu bestimmen, wobei das Verfahren weiterhin besteht aus der Verwendung von Zeitablaufinformationen an der zweiten GNSS-Vorrichtung von lediglich dem vierten Satellitenset.
Verfahren nach Anspruch 29, wobei die weitere Nachricht aus einem zweiten Indikator in einem dritten Abschnitt der Nachricht besteht, wobei der zweite Indikator spezifiziert, ob ein vierter Abschnitt der Nachricht die fortlaufenden Verfolgungsinformation für das vierte Satellitenset umfasst.
Verfahren nach Anspruch 30, wobei der vierte Abschnitt der Nachricht den Erhebungswert des niedrigsten Satelliten in dem vierten Satellitenset umfasst.
Verfahren nach Anspruch 31, wobei, wenn der zweite Indikator nicht spezifiziert, dass der vierte Abschnitt der Nachricht die fortlaufende Verfolgungsinformation umfasst, dann kein vierter Abschnitt der Nachricht an die zweite GNSS-Vorrichtung bereit gestellt wird.
Verfahren nach Anspruch 25, wobei: wenn die Nachricht nicht den ersten Indikator umfasst, die Nachricht für jeden Satelliten ein Bit zur Kennzeichnung umfasst, ob Daten in der Nachricht für diesen Satelliten eine Zyklusfehleinstellung umfassen und wenn das Bit für einen Satelliten einen Zyklusschlupf umfasst, dann werden die Daten für diesen Satelliten durch die zweite GNSS-Vorrichtung nicht benutzt.
Verfahren nach Anspruch 23, wobei die von der ersten GNSS-Vorrichtung an die zweite GNSS-Vorrichtung übertragene Nachricht den Erhebungswert spezifiziert und lediglich den Erhebungswert eines niedrigsten Satelliten umfasst.
Verfahren nach Anspruch 34, wobei, wenn der Erhebungswert 90 Grad beträgt, das zweite Satellitenset aus null Satelliten besteht.
Verfahren nach Anspruch 28, wobei das kürzere Zeitintervall eine Dauer aufweist und der vierte Abschnitt der Nachricht weiterhin die Dauer des kürzeren Zeitintervalls anzeigt.
Verfahren zur Kommunikation von Korrekturen für Information mit Bezug zu Satellitensignalen von einer ersten globalen Navigationssatellitensystem-(GNSS)-Vorrichtung an einem ersten Standort zu einer zweiten GNSS-Vorrichtung an einem zweiten Standort, bestehend aus: Bestimmung einer ersten Ionosphärenkorrektur für Ionosphärensignalwegverzögerung an der ersten GNSS-Vorrichtung für einen ersten Satelliten in einer Satellitenkonstellation; Vergleich der ersten Ionosphärenkorrektur mit einer zweiten Ionosphärenkorrektur für Ionosphärensignalwegverzögerung, wobei die zweite Korrektur für Ionosphärensignalwegverzögerung für einen Satelliten bestimmt ist, von dem angenommen wird, dass er sich direkt über dem ersten Standort befindet und Übertragung einer Nachricht von der ersten GNSS-Vorrichtung an die zweite GNSS-Vorrichtung, die nur einen Unterschied zwischen der ersten Ionosphärenkorrektur und der zweiten Ionosphärenkorrektur umfasst.
Verfahren nach Anspruch 37, weiterhin bestehend aus: Bestimmung einer korrespondierenden Ionosphärenkorrektur für Ionosphärensignalwegverzögerung für jede Pluralität zusätzlicher Satelliten in der Satellitenkonstellation; Vergleich jeder der korrespondierenden Ionosphärenkorrekturen mit der zweiten Korrektur; Übertragung einer Nachricht von der ersten GNSS-Vorrichtung an die zweite GNSS-Vorrichtung, die lediglich die Unterschiede zwischen der korrespondierenden Ionosphärenkorrektur für Ionosphärensignalwegverzögerung und der zweiten Korrektur umfasst.
Verfahren nach Anspruch 38, wobei: die erste Ionosphärenkorrektur besteht aus einer Festlegung einer ersten Weglänge durch die Ionosphäre für das erste Satellitensignal und die zweite Ionosphärenkorrektur besteht aus einer Festlegung einer zweiten Weglänge durch die Ionosphäre für den Satelliten, von dem angenommen wird, dass er sich direkt über dem ersten Standort befindet.
Verfahren nach Anspruch 39, wobei der Unterschied zwischen der ersten Ionosphärenkorrektur und der zweiten Ionosphärenkorrektur aus dem Unterschied zwischen der ersten Weglänge und der zweiten Weglänge besteht.
Verfahren nach Anspruch 39, wobei: für jede der Pluralität zusätzlicher Satelliten in der Satellitenkonstellation die korrespondierende Ionosphärenkorrektur für Ionosphärensignalwegverzögerung eine Bestimmung einer Weglänge durch die Ionosphäre für jeden solchen Satelliten zu dem ersten Standort umfasst; für jede der Pluralität zusätzlicher Satelliten die Weglänge durch die Ionosphäre mit der zweiten Weglänge verglichen wird und für jede der Pluralität zusätzlicher Satelliten eine Nachricht von der ersten GNSS-Vorrichtung an die zweite GNSS-Vorrichtung übertragen wird, die lediglich die Ergebnisse des Schritts umfasst, mit dem die Weglänge durch die Ionosphäre mit der zweiten Weglänge verglichen wird.
Verfahren nach Anspruch 37, weiterhin bestehend aus: Bestimmung einer ersten Troposphärenkorrektur für Troposphärensignalwegverzögerung an der ersten GNSS-Vorrichtung für einen ersten Satelliten in einer Satellitenkonstellation; Vergleich der ersten Troposphärenkorrektur mit einer zweiten Troposphärenkorrektur auf Troposphärensignalwegverzögerung, wobei die zweite Troposphärenkorrektur eine Troposphärenkorrektur für Troposphärensignalwegverzögerung in einem festgelegten Umfang ist und Übertragung einer Nachricht von der ersten GNSS-Vorrichtung an die zweite GNSS-Vorrichtung, die lediglich einen Unterschied zwischen der ersten Troposphärenkorrektur und dem festgelegten Umfang umfasst.
Verfahren nach Anspruch 42, weiterhin bestehend aus: Bestimmung einer korrespondierenden Troposphärenkorrektur für Troposphärensignalwegverzögerung für jede der Pluralität zusätzlicher Satelliten in der Satellitenkonstellation; Vergleich jeder der korrespondierenden Troposphärenkorrekturen mit der zweiten Korrektur; Übertragung einer Nachricht von der ersten GNSS-Vorrichtung an die zweite GNSS-Vorrichtung, die lediglich Unterschiede zwischen der korrespondierenden Troposphärenkorrektur für Troposphärensignalwegverzögerung und der zweiten Korrektur umfasst.
Verfahren nach Anspruch 43, wobei: die erste Troposphärenkorrektur aus einer Bestimmung einer ersten Weglänge durch die Troposphäre für das erste Satellitensignal besteht und die zweite Troposphärenkorrektur aus einem festgelegten Wert besteht.
Verfahren nach Anspruch 44, wobei: für jede der Pluralität von zusätzlichen Satelliten in der Satellitenkonstellation die korrespondierende Troposphärenkorrektur für die Troposphärensignalwegverzögerung eine Bestimmung einer Weglänge durch die Troposphäre für jeden derartigen Satelliten zu dem ersten Standort umfasst; die Weglänge durch die Ionosphäre mit dem festgelegten Wert für jede der Pluralität von zusätzlichen Satelliten verglichen wird und für jede der Pluralität von zusätzlichen Satelliten von der ersten GNSS-Vorrichtung an die zweite GNSS-Vorrichtung eine Nachricht übertragen wird, die lediglich die Ergebnisse des Schritts umfasst, mit dem die Weglänge durch die Troposphäre mit dem festgelegten Wert verglichen wird.
Verfahren nach Anspruch 44, wobei der festgelegte Wert durch Benutzung einer Approximation des Hopfield-Modells für Troposphärensignalverzögerung festgelegt wird.
Verfahren zur Kommunikation von Korrekturen für Informationen mit Bezug zu Satellitensignalen von einer ersten globalen Positionsbestimmungssystem-(GNSS)-Vorrichtung an einem ersten Standort zu einer zweiten GNSS-Vorrichtung an einem zweiten Standort, bestehend aus: Bestimmung einer ersten Troposphärenkorrektur für Troposphärensignalwegverzögerung an der ersten GNSS-Vorrichtung für einen ersten Satelliten in einer Satellitenkonstellation; Vergleich der ersten Troposphärenkorrektur mit einer zweiten Troposphärenkorrektur auf Troposphärensignalwegverzögerung, wobei die zweite Troposphärenkorrektur eine Troposphärenkorrektur auf Troposphärensignalwegverzögerung in einem festgelegten Umfang ist und Übertragung einer Nachricht von der ersten GNSS-Vorrichtung an die zweite GNSS-Vorrichtung, die lediglich einen Unterschied zwischen der ersten Troposphärenkorrektur und dem festgelegten Umfang umfasst.
Verfahren nach Anspruch 47, weiterhin bestehend aus: Bestimmung einer korrespondierenden Troposphärenkorrektur für Troposphärensignalwegverzögerung für jede der Pluralität zusätzlicher Satelliten in der Satellitenkonstellation; Vergleich jeder der korrespondierenden Troposphärenkorrekturen mit der zweiten Korrektur; Übertragung einer Nachricht von der ersten GNSS-Vorrichtung an die zweite GNSS-Vorrichtung, die lediglich Unterschiede zwischen der korrespondierenden Troposphärenkorrektur für die Troposphärensignalwegverzögerung und der zweiten Korrektur umfasst.
Verfahren nach Anspruch 48, wobei: die erste Troposphärenkorrektur aus einer Bestimmung einer ersten Weglänge durch die Troposphäre für das erste Satellitensignal besteht und die zweite Troposphärenkorrektur aus einem festgelegten Wert besteht.
Verfahren nach Anspruch 49, wobei: für jede der Pluralität zusätzlicher Satelliten in der Satellitenkonstellation die korrespondierende Troposphärenkorrektur für die Troposphärensignalwegverzögerung eine Bestimmung der Weglänge durch die Troposphäre für jeden derartigen Satelliten zu dem ersten Standort umfasst; für jede der Pluralität zusätzlicher Satelliten die Weglänge durch die Ionosphäre zu dem festgelegten Wert verglichen wird und für jede der Pluralität zusätzlicher Satelliten von der ersten GNSS-Vorrichtung an die zweite GNSS-Vorrichtung eine Nachricht übertragen wird, die lediglich die Ergebnisse des Schritts umfasst, mit dem die Weglänge durch die Troposphäre zu dem festgelegten Wert verglichen wird
Verfahren nach Anspruch 50, wobei der festgelegte Wert durch Benutzung des Hopfield-Modells für Troposphärensignalverzögerung festgelegt wird.
Verfahren nach Anspruch 47, weiterhin bestehend aus: Bestimmung einer ersten Ionosphärenkorrektur für Ionosphärensignalwegverzögerung an der ersten GNSS-Vorrichtung für einen ersten Satelliten in einer Satellitenkonstellation; Vergleich der ersten Ionosphärenkorrektur mit einer zweiten Ionosphärenkorrektur auf Ionosphärensignalwegverzögerung, wobei die zweite Ionosphärenkorrektur für Ionosphärensignalwegverzögerung bestimmt ist, die für einen Satelliten bestimmt ist, von dem angenommen wird, dass er sich direkt über dem ersten Standort befindet und Übertragung einer Nachricht von der ersten GNSS-Vorrichtung an die zweite GNSS-Vorrichtung, die lediglich einen Unterschied zwischen der ersten Ionosphärenkorrektur und der zweiter Ionosphärenkorrektur umfasst.
Verfahren nach Anspruch 52, weiterhin bestehend aus: Bestimmung einer korrespondierenden Ionosphärenkorrektur für Ionosphärensignalwegverzögerung für jede einer Pluralität von zusätzlichen Satelliten in der Satellitenkonstellation; Vergleich jeder der korrespondierenden Ionosphärenkorrekturen mit der zweiten Korrektur; Übertragung einer Nachricht von der ersten GNSS-Vorrichtung an die zweite GNSS-Vorrichtung, die lediglich die Unterschiede zwischen der korrespondierenden Ionosphärenkorrektur für Ionosphärensignalwegverzögerung und der zweiten Korrektur umfasst.
Verfahren nach Anspruch 53, wobei: die erste Ionosphärenkorrektur aus einer Bestimmung der ersten Weglänge durch die Ionosphäre für das erste Satellitensignal besteht und die zweite Ionosphärenkorrektur aus einer Bestimmung der zweiten Weglänge durch die Ionosphäre für das Satellitensignal besteht, für das angenommen wird, dass es sich direkt über dem ersten Standort befindet.
Verfahren nach Anspruch 54, wobei der Unterschied zwischen der ersten Ionosphärenkorrektur und der zweiten Ionosphärenkorrektur aus dem Unterschied zwischen der ersten Weglänge und der zweiten Weglänge besteht.
Verfahren nach Anspruch 55, wobei: für jede der Pluralität zusätzlicher Satelliten in der Satellitenkonstellation die korrespondierende Ionosphärenkorrektur für Ionosphärensignalwegverzögerung eine Festlegung einer Weglänge durch die Ionosphäre für jeden derartigen Satelliten zu dem ersten Standort umfasst; die Weglänge durch die Ionosphäre mit der zweiten Weglänge für jede der Pluralität zusätzlicher Satelliten verglichen wird und für jede der Pluralität zusätzlicher Satelliten eine Nachricht von der ersten GNSS-Vorrichtung an die zweite GNSS-Vorrichtung übertragen wird, die lediglich die Ergebnisse des Schritts umfasst, mit dem die Weglänge durch die Ionosphäre mit der zweiten Weglänge verglichen wird.