© RTCM Not for reproduction or redistribution

RTCM 10403.2 RTCM Paper 104-2013-SC104-STD

RTCM STANDARD 10403.2

DIFFERENTIAL GNSS (GLOBAL NAVIGATION SATELLITE SYSTEMS)

SERVICES – VERSION 3

DEVELOPED BY RTCM SPECIAL COMMITTEE NO. 104

FEBRUARY 1, 2013

COPYRIGHT©2013 RTCM

Radio Technical Commission for Maritime Services 1611 N. Kent St., Suite 605

Arlington, Virginia 22209-2143, U.S.A. E-Mail: [email protected]

Web Site: http:/www.rtcm.org

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

The Radio Technical Commission For Maritime Services (RTCM) is an incorporated non-profit organization, with participation in its work by international representation from both government and non-government organizations. The RTCM does not work to induce sales, it does not test or endorse products, and it does not monitor or enforce the use of its standards.

The RTCM does not engage in the design, sale, manufacture or distribution of equipment or in any way control the use of this standard by any manufacturer, service provider, or user. Use of, and adherence to, this standard is entirely within the control and discretion of each manufacturer, service provider, and user.

For information on RTCM Documents or on participation in development of future RTCM documents contact:

Radio Technical Commission For Maritime Services 1611 N. Kent St., Suite 605

Arlington, Virginia 22209-2143 USA

Telephone: +1-703-527-2000 Telefax: +1-703-351-9932

E-Mail: [email protected]

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2 RTCM Paper 104-2013-SC104-STD

RTCM STANDARD 10403.2

DIFFERENTIAL GNSS (GLOBAL NAVIGATION SATELLITE SYSTEMS)

SERVICES – VERSION 3

DEVELOPED BY RTCM SPECIAL COMMITTEE NO. 104

FEBRUARY 1, 2013

COPYRIGHT©2013 RTCM

Radio Technical Commission for Maritime Services 1611 N. Kent St., Suite 605

Arlington, Virginia 22209-2143, U.S.A. E-Mail: [email protected]

Web Site: http:/www.rtcm.org

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

This page intentionally left blank

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

i

PREFACE This standard has been developed by RTCM Special Committee 104 as a more efficient alternative to Version 2 in various documents entitled "RTCM Recommended Standards for Differential Navstar GPS Service, Version 2.x”. Service providers and vendors represented on the SC-104 Committee requested the development of a new standard that would be more efficient, easy to use, and more easily adaptable to new situations. The main complaint was that the Version 2 parity scheme, which uses words with 24 bits of data followed by 6 bits of parity, was wasteful of bandwidth. Another complaint was that the parity was not independent from word to word. Still another was that even with so many bits devoted to parity, the actual integrity of the message was not as high as it should be. Plus, 30-bit words are awkward to handle. This standard, Version 3, is intended to correct these weaknesses. Unlike Version 2, the Version 3 standards do not include tentative messages. The messages in Version 3 have undergone testing for validity and interoperability, and are considered to be permanent. Future modifications of the standard may change the meaning of reserved bits or provide additional clarifying text, but no changes will be made in the data fields. Changes will require new messages to be developed. As new messages and capabilities have been demonstrated through validity and interoperability testing, they will be incorporated into future revisions of the Version 3 standard, either as amendments or as a new revision of standard 10403.x. Amendments will be made available electronically to those who have purchased the standard. Periodically, accumulated Amendments will be incorporated into a complete revision of standard 10403.x. RTCM SC-104 believes that Standard 10403.2 for DGNSS services will continue to prove useful in supporting highly accurate differential and kinematic positioning as well as a wide range of navigation applications worldwide throughout the next decade.

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

ii

This page intentionally left blank .

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

iii

TableofContents 1 INTRODUCTION AND SCOPE ......................................................................................... 1

1.1 Introduction ................................................................................................................... 1 1.2 Scope............................................................................................................................... 3 1.3 List of Abbreviations .................................................................................................... 3

2 APPLICATION LAYER ...................................................................................................... 7 3 PRESENTATION LAYER .................................................................................................. 9

3.1 Introduction ................................................................................................................... 9 3.1.1 Version 3 Database Architecture ............................................................................... 9 3.1.2 Message Groups ......................................................................................................... 9 3.1.3 Operation with Multiple Services ............................................................................ 18 3.1.4 Reference Receiver Time and Observations ........................................................... 19 3.1.5 Network RTK corrections ........................................................................................ 20 3.1.6 Proper handling of antenna phase center variation corrections ........................... 21 3.1.7 Scheduling of Network RTK messages ................................................................... 22 3.1.8 Handling of Quarter Cycle Carrier Phase Shifts ................................................... 24

3.2 Message Type Summary ............................................................................................. 26 3.3 Data Types ................................................................................................................... 31 3.4 Data Fields ................................................................................................................... 35 3.5 Messages....................................................................................................................... 98

3.5.1 GPS RTK Observable Messages .............................................................................. 98 3.5.2 Stationary Antenna Reference Point Messages .................................................... 103 3.5.3 Antenna Description Messages ............................................................................. 106 3.5.4 GLONASS RTK Observable Messages ................................................................. 108 3.5.5 System Parameter Messages .................................................................................. 113 3.5.6 GPS Network RTK Correction Messages .............................................................. 114 3.5.7 GPS Ephemerides .................................................................................................. 121 3.5.8 GLONASS Ephemerides ........................................................................................ 124 3.5.9 Unicode Text String Message ................................................................................ 126 3.5.10 Coordinate Transformation Messages .............................................................. 129 3.5.11 Network RTK Residual Error Messages ........................................................... 155 3.5.12 State Space Messages ......................................................................................... 161 3.5.13 GLONASS Network RTK Correction Messages ............................................... 186 3.5.14 FKP Network RTK Correction Messages ......................................................... 192 3.5.15 Multiple Signal Messages .................................................................................. 197 3.5.16 GLONASS Bias Information Messages ............................................................ 231

3.6 Proprietary Messages ............................................................................................... 233 4 TRANSPORT LAYER ..................................................................................................... 235

4.1 Description ................................................................................................................. 235 4.2 Example ..................................................................................................................... 237

5 DATA LINK LAYER ....................................................................................................... 239 6 PHYSICAL LAYER ......................................................................................................... 241 APPENDIX A. SUGGESTIONS AND EXAMPLES FOR NETWORK OPERATION .. A-1

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

iv

This page intentionally left blank.

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

1

1 INTRODUCTION AND SCOPE 1.1 Introduction

The Global Positioning System (GPS) and the GLObal NAvigation Satellite System (GLONASS) are satellite-based positioning systems that are currently providing global service 24 hours each day. Collectively, these two systems, plus other systems currently being designed and implemented, notably Galileo, are called Global Navigation Satellite Systems (GNSS’s). We also include as GNSS, systems that are regional at the time of this writing, but which provide GNSS-like features in the regions they serve, such as QZSS and Compass BeiDou. This standard is intended to serve those systems as well. GNSS’s typically provide navigation and positioning services having accuracies in the 5-40 meter range (2drms). Differential operation provides meter-level accuracy, while Real-Time Kinematic (RTK) operation provides decimeter accuracy or better. The RTCM Special Committee 104 (SC-104), Differential GNSS Service, has examined the technical and institutional issues and formulated recommendations on the data format and content that are designed to support the most stringent applications in an efficient manner. The Committee has attempted to accommodate the widest possible user community, including not only maritime users, but land-based and airborne users as well. Radio location, surveying, and radio navigation applications are supported. The RTCM 10403 standard series (i.e. Version 3 or Version 3.2 in the case of this specific revision) describes messages and techniques for supporting GPS and GLONASS operation with one reference station or a network of reference stations. However, the format is specifically designed to make it straightforward to accommodate new systems that are under development, Galileo in particular, as well as modifications to existing systems (e.g., new L2C and L5 signals). It can also accommodate augmentation systems that utilize geostationary satellites with transponders operating in the same frequency bands. Generically these are called Satellite-Based Augmentation Systems (SBAS’s), and they have been designed to be interoperable. The first to be implemented is the Wide-Area Augmentation System (WAAS), which has been developed by the U.S. Federal Aviation Administration to supplement the GPS. The second is the European Geostationary Navigational Overlay System (EGNOS), which is being implemented to augment both GPS and GLONASS. The new systems will be accommodated by adding new messages. A summary of the version history of this document are shown in Table 1-1.

Table 1-1: Version 3 Revision (3.x) and Amendment (A.x) Summary

Version Messages Defined Change Description

3.0 1001-1013 RTK messages for single or dual-frequency GPS and GLONASS operation.

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

2

Version Messages Defined Change Description

3.1 1001-1029 4088-4095

GPS Network RTK GPS and GLONASS Ephemeris messages Transformation messages UNICODE message

3.1 A.1 1001-1029 4001-4087

Improved messages descriptions. Addition of proprietary messages

3.1 A.2 1001-1033 4001-4095

Network RTK residual messages Physical reference station position message (for VRS) Receiver and antenna description messages

3.1 A.3 1001-1033 4001-4095

Handling of quarter-cycle phase shifts

3.1 A.4 1001-1039 4001-4095

GPS and GLONASS FKP GLONASS MAC

3.1 A.5 1001-1039 1057-1068 4001-4095

State space representation (SSR; PPP) messages

3.2 1001-1039 1057-1068 1071-1230 4001-4095

Multiple signal messages (MSM) GLONASS bias information message

The Committee assumes that Selective Availability has been permanently set to zero on the GPS satellites, so that the GPS signal variations will be dominated by natural causes. No system modifications, augmentations or new systems are considering this kind of intentional accuracy degradation. The higher efficiency of the Version 3 format, coupled with the absence of Selective Availability, makes it possible to support RTK services with significantly reduced bandwidths. The U.S. Coast Guard’s NDGPS-GWEN expansion would be able to support a decimeter-level RTK service using the new standard, as well as supporting all existing services with a reduced data broadcast burden. The Committee expects that it will find use in vessel tracking systems as well. Potential land uses include robotic mining, construction, and rapid surveying. In summary, the Version 3 format supports the most stringent and unique applications of these high-accuracy positioning techniques.

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

3

1.2 Scope

This standard defines a flexible messaging structure to support augmentation of navigation systems. It is the purpose of this structure to provide integrity and capability for existing and future applications an efficient manner. In order to promote these qualities this standard has been designed using a layered approach adapted from the Open System Interconnection (OSI) standard reference model.

1) Application Layer 2) Presentation Layer 3) Transport Layer 4) Data Link Layer 5) Physical Layer

Application Layer considerations are briefly discussed in Section 2, which includes instructions on creating and applying data for navigation and positioning applications. Section 3, which comprises the bulk of the document, addresses the Presentation Layer, and describes the messages, the data elements, and the data definitions. The Transport Layer is described in Section 4, and includes the definition of the message frames, the method of implementing variable-length messages, and the Cyclic Redundancy Check (CRC) that provides message integrity. The Data Link Layer is tailored around the Physical Layer, which defines how the data is conveyed at the electrical and mechanical level. 1.3 List of Abbreviations

ARP Antenna Reference Point AS Anti-Spoofing ASCII American Standard Code for Information Interchange C/A Coarse Acquisition CD Correction Difference CDMA Code Division Multiple Access COM Center Of Mass CPB Code-Phase Bias CNR Carrier to Noise Ratio CRC Cyclic Redundancy Check CRS Coordinate Reference System DARC FM Data Radio Channel Frequency Modulation DD Data Dictionary DF Data Field ECEF Earth Centered Earth Fixed EGNOS European Geostationary Navigational Overlay System EPC Easting at Projection Center EPSG European Petroleum Survey Group ETRF European Terrestrial Reference Frame FDMA Frequency Division Multiple Access FE False Easting FKP (German) FlächenKorrekturParameter, area correction parameter FN False Northing

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

4

GCPCD Geometric Carrier Phase Correction Difference GLONASS Global Navigation Satellite System

GNSS Global Navigation Satellite System GPS Global Positioning System ICD Interface Control Document

ICPCD Ionospheric Carrier Phase Correction Difference IERS International Earth Rotation Service IGS International GNSS Service IODC Issue of Data Clock IOD Issue of Data IODE Issue of Data Ephemeris ITRF International Terrestrial Reference Frame LAAS Local Area Augmentation System LaNO Latitude of Natural Origin LCC Lambert Conformal Conic projection (LCC1SP, LCC2SP, LCCW) LOC Loss of Continuity LoNO Longitude of Natural Origin LSB Least Significant Bit MAC Master Auxiliary Concept MLT Minimum Lock Time MMI Multiple Message Indicator MSB Most Significant Bit MSK Minimum Shift Keying MSM Multiple Signal Message NGS National Geodetic Survey Nm Number of Message Types Transmitted NPC Northing at Projection Center

M Number of characters in Target Name MJD Modified Julian Day number MSM Multiple Signal Messages N Number of characters in Source Name NGS National Geodetic Survey NMEA National Marine Electronics Association Ns No. of Satellites OGP International Association of Oil and Gas Producers OM Oblique Mercator OSI Open System Interconnection ppm Parts Per Million PPP Precise Point Positioning PRN Pseudo-Random Noise (used to denote a specific GNSS satellite) RINEX Receiver INdependent EXchange format RTCM Radio Technical Commission for Maritime Services RTK Real-Time Kinematic SBAS Satellite-Based Augmentation Systems SMF Synchronous Message Flag

SPS Standard Positioning Service

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

5

SRP Satellite Reference Point SSR State Space Representation TM Transverse Mercator TMS Tile Map Service TOW Time of Week UHF Ultra-High Frequency URA User Range Accuracy UTC Universal Coordinated Time (Seconds of Day) UTC(SU) National time scale of the Russian Federation VHF Very High Frequency VRS Virtual Reference Station WAAS Wide-Area Augmentation System

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

6


© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

7

2 APPLICATION LAYER

The Application Layer defines how the Version 3 messages can be applied for different end user applications. The fundamental feature of Differential Service is that it is a broadcast service, not a 2-way data link. As such, information is developed centrally by a Service Provider, who has an institutional or commercial interest in providing a positioning or navigation service. Recently, point-to-multipoint services using cell phones and Internet connections have become popular, but such services primarily support a one-way flow of information. In general, navigation applications are serviced very well with 1-10 meter horizontal accuracy positioning. (An exception is the GNSS-based aircraft landing system, called the Local Area Augmentation System, or LAAS. A separate standard has been developed for this by RTCM’s sister organization, RTCA, Inc., which develops aviation standards.) Conventional differential GNSS service supports these applications nicely, and they utilize broadcast links with relatively low data rates. These low data rates can be supported by low-frequency broadcasts that are received over large areas, and high accuracy is maintained over hundreds of miles. As innovative engineers and scientists have found uses for sub-meter accuracy positioning, RTK service has increased in importance. RTK service requires the transmission of significantly more data, so that generally line-of-sight broadcasts and point-to-multipoint services that utilize higher bandwidths are employed. Tropospheric and ionospheric variations cause phase and time delay variations in the GNSS signals that limit the area over which a given accuracy can be achieved. For example, relative positioning accuracies of one centimeter or better using single-frequency GNSS signals can be achieved only over distances of 10 kilometers or so (from reference station to user). Using dual-frequency GNSS signals enables one to estimate the ionospheric effects, and water vapor measurements can be made which improve tropospheric delay estimation, so that using these techniques the range can be extended to 50 kilometers or so in certain parts of the world. Dual-frequency RTK is very common, thus is supported by this standard. Because RTK provides relative positioning, the knowledge of the absolute (usually fixed) position of the reference station enables the user to achieve high absolute position accuracies, too. To achieve the highest accuracy, it is important to account for GNSS antenna variations. Antenna patterns differ slightly from manufacturer to manufacturer and even from model to model. Differential GNSS service supports this by transmitting messages with reference station antenna information. Antenna patterns can also vary between different units of the same model and can vary due to environmental effects, but these can be mitigated by manufacturing design and reference site selection, respectively. Such variations are outside the scope of this document. The applications of RTK to air, water and land operations are too many to enumerate, but a sampling is useful:

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

8

Marine – Hydrographic surveying, dredge operations, navigation in narrow channels, buoy placement and auditing, even tidal height

Air – Aerial surveying, landing system testing, calibration of other navigation systems

Land – Surveying, building and bridge construction, surface mining, agriculture, road construction, asset location and management

It turns out that the RTK requirements for all these different applications don’t vary that much. The broadcast link bandwidth and update rates are primarily determined by the accuracy requirements and the signal blockage environment. Otherwise the required services are similar for air, land and sea applications.

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

9

3 PRESENTATION LAYER 3.1 Introduction

3.1.1 Version 3 Database Architecture

Version 3 is written in a database format, loosely patterned after the NMEA 2000 standard. Whereas the NMEA standard is written for a networked set of different electronic units, the Differential GNSS Version 3 standard is written for a centralized distribution of data. For the Version 3 broadcast, every bit counts in the frequently repeated messages, so while lining up on byte boundaries is desirable, forcing each data field to occupy whole numbers of bytes is not practical.

Also, the NMEA 2000 database has a wide disparity between Data Dictionary (DD) and Data Field (DF) records. In the case of Version 3 broadcasts, there would be little difference. As a consequence, rather than utilize both DF and DD tables, these are collapsed into one DF definition. Rather than referring to “Parameter Groups”, this document will use the more familiar term “Message Types”.

For messages whose lengths don't line up with byte boundaries, the reference station designer should use zeros for undefined bits to fill out the last unfilled byte.

3.1.2 Message Groups

Message types contained in the current Version 3 standard (RTCM 10403.2) have been structured in different groups. For proper operation of a particular service the provider needs to transmit messages from each of several groups, as shown in Table 3.1-1. For example, to provide RTK services the provider must transmit at least one message type from each of the following groups: Observations, Station Coordinates, and Antenna Description. The different message types in each group contain messages with similar information content.

In some cases the shorter ones contain the minimum needed to provide the service, while the longer message types contain additional information for enhancing the performance of the service. For example, Message Type 1001 contains the shortest version of a message for GPS Observations, namely L1-only observables. For a broadcast link limited in throughput, use of 1001 might be appropriate. Message Type 1002 contains additional information that enhances performance. If throughput is not limited and the additional information is available, it is recommended to use the longer version of messages. Similarly Message Type 1003 provides minimum data for L1/L2 operation, while Message Type 1004 provides the full data content. The shorter observation messages save throughput, but contain less information. However, since the additional information in the longer observation messages does not change very often, they could be sent less often.

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

10

Table 3.1-1 Message Groups

Group Name Sub-Group Name Message Type

Observations GPS L1 1001

1002

GPS L1 / L2 1003

1004

GLONASS L1 1009

1010

GLONASS L1 / L2 1011

1012

GPS MSMs 1071-1077

GLONASS MSMs 1081-1087

GALILEO MSMs 1091-1097

Station Coordinates 1005

1006

1032

Antenna Description 1007

1008

Receiver and Antenna Description 1033

Network RTK Corrections Network Auxiliary Station Data Message

1014

GPS Ionospheric Correction Differences

1015

GPS Geometric Correction Differences

1016

Combined GPS Geometric and Ionospheric Correction Differences

1017

GPS Network RTK Residual Message

1030

GLONASS Network RTK Residual Message

1031

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

11


GPS Network FKP Gradient Message

1034

GLONASS Network FKP Gradient Message

1035

GLONASS Ionospheric Correction Differences

1037

GLONASS Geometric Correction Differences

1038

Combined GLONASS Geometric and Ionospheric Correction Differences

1039

Auxiliary Operation Information System Parameters 1013

Satellite Ephemeris Data 1019

1020

Unicode Text String 1029

GLONASS bias information 1230

Transformation Parameter Information

Helmet/Abridged Molodenski Message

1021

Molodenski-Badekas Message

1022

Representation Residual Messages

1023

1024

Projection Parameters Messages

1025

1026

State Space Representation Parameters

GPS Orbit Correction 1057

GPS Clock Correction 1058

GPS Code Bias 1059

GPS Combined Orbit and Clock

1060

GPS URA 1061

GPS High Rate Clock 1062

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

12


Correction

GLONASS Orbit Correction 1063

GLONASS Clock Correction 1064

GLONASS Code Bias 1065

GLONASS Combined Orbit and Clock

1066

GLONASS URA 1067

GLONASS High Rate Clock Correction

1068

Proprietary Information Assigned in the range 4001 – 4095

See Table 3.6-1

The basic types of RTK service supported in Version 3 are (1) GPS, (2) GLONASS, and (3) combined GPS/GLONASS. Table 3.1-2 shows various levels of services that could be supported, with the Message Types that support them. It also provides the appropriate set of messages for both the mobile and reference station receivers for each service.

Table 3.1-2 Message Types Supporting Different RTK Service Levels

Service Group Mobile Receiver

Service Provider Message Type(s)

Minimum Decoding

Requirement

Minimum Service

Operation

Full Service

Operation

Precision GPS Observations (GPS) 1001-1004 1001 1002

L1 only Station Description 1005 and 1006

1005 or 1006

1005 or 1006

Antenna and Receiver Description

1033 (see note 1)

1033 1033

Auxiliary Operation Information 1013

Precision GPS RTK, L1 & L2

Observations (GPS) 1003-1004 1003 1004

Station Description 1005 and 1006

1005 or 1006

1005 or 1006

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

13



Minimum Decoding

Requirement

Minimum Service

Operation

Full Service

Operation


1033 (see note 1)

1033 1033


Precision Observations (GLONASS) 1009-1012 1009 1010

GLONASS L1 only


1005 or 1006

1005 or 1006


1033 (see note 1)

1033 1033

Auxiliary Operation Information 1230 1013 and 1230

Precision Observations (GLONASS) 1011-1012 1011 1012

GLONASS RTK


1005 or 1006

1005 or 1006


1033 (see note 1)

1033 1033



and GLONASS Observations (GLONASS) 1009-1012 1009 1010

L1 only Station Description 1005 and 1006

1005 or 1006

1005 or 1006


1033 (see note 1)

1033 1033



and GLONASS Observations (GLONASS) 1011-1012 1011 1012

RTK, L1 & L2 Station Description 1005 and 1006

1005 or 1006

1005 or 1006


1033 (see note 1)

1033 1033


© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

14



Minimum Decoding

Requirement

Minimum Service

Operation

Full Service

Operation


Network RTK

(MAC)


1005 or 1006

1005 or 1006


1033 (see note 1)

1033 1033


Network RTK Corrections

(MAC) 1014 1014

1017 1015 and 1016 or 1017

1030

Precision GPS

Network RTK

(FKP)



1005 or 1006

1005 or 1006


1033 (see note 1)

1033 1033


Network RTK Corrections (FKP)

1034 1034

1030

Precision GLONASS Network RTK

(MAC)

Observations (GLONASS) 1011-1012 1011 1012

Station Description 1005 and

1006

1005 or

1006

1005 or

1006

Receiver and Antenna Description 1033 1033 1033


Network RTK Corrections (MAC)

1014 1014

1039 1037 and 1038 or 1039

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

15



Minimum Decoding

Requirement

Minimum Service

Operation

Full Service

Operation

1031


1035 1035

1031

Precision GLONASS Network RTK

(FKP)


Station Description 1005 and

1006

1005 or

1006

1005 or

1006

Receiver and Antenna Description 1033 1033 1033



1035 1035

1031

Precision GPS and GLONASS Network RTK

(MAC)




1005 or 1006

1005 or 1006

Receiver and Antenna Description

1033 1033 1033


Network RTK Corrections (MAC) - GPS-

1014 1014

1017 1015 and 1016 or 1017

Network RTK Corrections – (MAC) - GLONASS

1030

1039 1037 and 1038 or 1039

1031

Precision GPS and GLONASS



© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

16



Minimum Decoding

Requirement

Minimum Service

Operation

Full Service

Operation

Network RTK

(FKP) Station Description 1005 and

1006 1005 or 1006

1005 or 1006

Receiver and Antenna Description

1033 1033 1033


Network RTK Corrections (FKP) - GPS

1034 1034 1030

Network RTK Corrections (FKP) - GLONASS

1035 1035 1031

GPS SSR Orbit and Clock Corrections 1057 1058 1060

1062

1060 1057 1058

1062

Bias Correction 1059


GLONASS SSR Orbit and Clock Corrections 1063 1064 1066

1068

1066 1063 1064

1068



GPS and GLONASS SSR

Orbit Correction 1057 1058 1060 1062 1063 1064 1066 1068

1060

1066

1057 1058 1062 1063 1064

1068


1065


© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

17



Minimum Decoding

Requirement

Minimum Service

Operation

Full Service

Operation

1067 GNSS CODE-differential operation

Observations (GNSS)

MSM1-MSM7

MSM1 MSM1

Station Description

1005 and 1006

1005 or 1006

1005 or 1006

Antenna Description 1007 or 1008 or 1033

Auxiliary Operation Information 1013 GNSS RTK Standard Precision operation

Observations (GNSS)

MSM1-MSM7

MSM3 MSM5

Station Description

1005 and 1006

1005 or 1006

1005 or 1006


1033 1033 1033

Auxiliary Operation Information 1230 (if GLONASS data is transmitted)

1013 1230 (if GLONASS data is transmitted)

GNSS RTK High Precision operation

Observations (GNSS)

MSM6 and MSM7

MSM6 MSM7

Station Description

1005 and 1006

1005 or 1006

1005 or 1006


1033 1033 1033



GNSS Standard Precision Data Collection

Observations (GNSS)

MSM5 MSM5

Station Description

1005 or 1006

1005 or 1006

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

18



Minimum Decoding

Requirement

Minimum Service

Operation

Full Service

Operation


1033 1033



GNSS High Precision Data Collection

Observations (GNSS)

MSM7 MSM7

Station Description

1005 or 1006

1005 or 1006


1033 1033



Note1: MT1033 is preferred over MT1008. MT1008 is intended to be used to service legacy equipment. Service Providers can provide a variety of different services ranging from a basic to a complete service. A basic service would involve, e.g., a GPS single-frequency operation, with no attempt to optimize accuracy or ambiguity resolution time. A complete service would provide dual-frequency operations, possibly involving both GPS and GLONASS, attempting to optimize accuracy, baseline length, and ambiguity resolution time, as well as providing helpful ancillary data for quick startup and post-mission analysis. Mobile equipment should be designed to decode all the message types in a group, even if all the information is not processed. For example, by decoding a Message Type 1002, the RTK observable data that matches that of Message Type 1001 can be utilized, but the additional information may be ignored. If the mobile equipment only operates on L1, it should still be designed to decode Message Types 1003 and 1004 and to pull out the L1 information. 3.1.3 Operation with Multiple Services

Providing information for multiple GNSS’s (e.g., GNSS1=GPS and GNSS2=GLONASS) can be accommodated if guidelines are carefully followed. In particular:

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

19

1. The messages for all satellites of a particular system should be grouped in one message, if possible. For example, for GPS L1/L2 operation, each 1003 or 1004 message should contain the data for all GPS satellites that are processed. This ensures that a GPS-only mobile receiver will be certain that all relevant data has been received even if the “Synchronous GNSS Message Flag”, which indicates that more GNSS data (e.g., GLONASS) referenced to the same time epoch will be transmitted next, is set to “1”.

2. When the “extended” messages, i.e., Message Types 1002, 1004, 1010, and 1012, are transmitted, they should include the entire set of satellites processed.

3. For combined GPS/GLONASS operation, GPS data should be transmitted first. This is because it will reduce latency for GPS-only mobile receivers, while combined GPS/GLONASS mobile receivers will suffer no penalty.

4. If the GNSS1 and GNSS2 data are not synchronous (i.e., the observations are not taken within one microsecond of each other), the “Synchronous GNSS Message Flag” should be set to zero for each set.

Now that the GLONASS constellation is complete and the Galileo system should soon be operational, these rules may be re-examined and modified. 3.1.4 Reference Receiver Time and Observations

The reference receiver shall maintain its clock to align the measurement epoch times to the GNSS system time if possible. This is commonly referred to as Clock Steering. If clock steering is not possible, the observation shall be adjusted to correct for the receiver clock offset. When adjusting for clock offset, the consistency between the observations shall be maintained:

Transmitted Pseudorange = Raw Pseudorange – (Clock Offset * PhaseRange Rate) – (Clock Offset * Speed of light) Transmitted PhaseRange = Raw PhaseRange – (Clock Offset * PhaseRange Rate) – (Clock Offset * Speed of light)

The resulting receiver epoch time should align with the GNSS system epoch time to within 1 µs. Note that the PhaseRange has the same sign as the Raw Pseudorange. For combined GNSS operation, if all GNSS observables are measured at the same instant of receiver time (in other words, if GNSS1 and GNSS2 clocks are based on the same oscillator), the clock offset utilized in the formulas above should be identical for the correction of all observations across both satellite systems and frequencies. The relations of differences between different clock biases in the observations are maintained in their original form. In this case, "Single Receiver Oscillator Indicator" (DF142) should contain “1”. Also, "Synchronous GNSS Message Flag" (DF005) should indicate that GNSS measurements are synchronous as described in point 3.1.3. Some reference station installations may not allow for identical clock offsets over all the satellite systems tracked (for example, if two or more independent receiver boards produce the observations). Correspondingly, the "Single Receiver Oscillator Indicator" (DF142)

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

20

should be set to "0". However, in such a case all GNSS’s might be still synchronous, indicating that the observations have been obtained within one microsecond. The "Synchronous GNSS Message Flag" (DF005) should identify the proper state. It should be noted that the conditions for DF005 and DF142 refer to the configuration of the reference station equipment, thus do not change during the transmission of a data stream. 3.1.5 Network RTK corrections

Different concepts to provide corrections from Network RTK are supported. There are

FKP: range correction gradients Non-Physical Reference Station MAC: Master Auxiliary Concept

FKP range correction gradients With the concept of FKP (from the German word: “Flächenkorrekturparameter” = Area Correction Parameters) horizontal gradients of distance-dependent errors like ionosphere, troposphere and orbits are derived from a network of GNSS reference stations and transmitted to a rover together with raw or correction data of a corresponding reference station. Non-Physical Reference Station The Non-Physical or Computed Reference Station is typically calculated based on information from a network of reference stations. Different approaches have been established over years. The Non-Physical or Computed Reference Stations are sometimes trademarked and may not be compatible. Examples of these names are “Virtual Reference Stations”, “Pseudo-Reference Stations”, and “Individualized Reference Stations”. Master Auxiliary Concept (MAC) The fundamental functionality of networking software that combines the information of several permanent reference stations is the determination of integer ambiguities between the reference stations. The resulting integer ambiguities may be used for reducing the original raw reference station observations. This manipulation of the raw observations leaves the general properties of the carrier phase observations (troposphere, ionosphere, phase center variations, etc.) untouched, since only integer numbers have been introduced. This process is named “integer ambiguity-leveling” and the resulting observations of permanent reference stations are “(integer) ambiguity-leveled”. An application accessing ambiguity-leveled observations of a single reference station will not see any difference. The modeling requirements within the application are identical. However, when an application uses the observations of more than one reference station, the application will no longer have to account for integer ambiguities between the reference stations on the same ambiguity level. Roving user equipment receiving observations of more than one reference

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

21

station on the same ambiguity level and utilizing the observations in its positioning algorithm may switch from one reference station to another without reinitialization of its filter. In order to preserve throughput, Network RTK messages utilize data fields that extend the approach described above: the raw observations are reduced by the geometric representation of the satellite and receiver distance; and inter-reference station single differences are used (see Appendix A). Master-Auxiliary Network RTK Corrections (MAC) are designed as additional information for improved performance and precision. A service provider utilizing the network capability will broadcast Precision GPS and GLONASS RTK messages for the Master Reference Station, but will broadcast Auxiliary Reference Station information as well. Until a future version of revision of this standard is published, service providers are advised to limit the data stream to information associated with one single Master Reference Station and its associated Auxiliary Reference Stations. Participating mobile receivers must be designed to accept and process the Network RTK Corrections. Mobile equipment operating close to the Master Reference Station may be designed to use the Observation, Station Description, and Antenna Description information of the Master reference station exclusively. 3.1.6 Proper handling of antenna phase center variation corrections

Antennas designed for precise RTK operation account for so-called antenna phase center offsets and variations in the centimeter-range. These offsets and variations can be corrected within precise RTK equipment using calibration information. Antenna model type calibrations are available from several sources (e.g. IGS, and NGS). High precision applications occasionally use individual antenna calibrations. Also, within permanent reference station networks, individually calibrated antennas are increasingly being used. The proper handling of dissimilar antennas is a pressing issue for the interoperability of RTK network data. Therefore for Network RTK operation adjustments may be made to raw observations for the Master Reference Stations (message 1004, for example) for antenna biases (phase center offsets and phase center variations). When corrections of antenna phase center variations are required, one should ensure that consistent sets are used throughout the application. The best way to ensure a consistent set of antenna phase center variations is to use only information from a single source (e.g. IGS, NGS) and ensure that the same form of representation is used consistently throughout each application (note the difference between absolute and relative representations). Note that reference station network software and rover firmware are different applications and thus may use different representations. It is recommended that published antenna parameters be used as they are. It is crucial to avoid mixing different forms of representation, and/or “fine-tuning” given sets of information by assembling a new set out of different sources (e.g. mixing offsets of one calibration with phase center variations with another calibration for one antenna). Offsets and phase center variations comprise a self-consistent set of information for a particular antenna. Both parts of the information are correlated with each other. The shape of one particular antenna phase pattern may be represented in principle by an indefinite number of different consistent sets of information (e.g. the introduction of a different value in the offset will be compensated by the antenna phase center variations). In the event that it is necessary to change Master Reference Stations within a Precision Network RTK operation, a bias error could occur in the rover position as a consequence of using inconsistent phase center correction sets at the rover (e.g., obtained from different sources).

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

22

Furthermore, achieving consistency of antenna correction models within large network setups would require storing antenna phase center corrections for dozens of Master Reference Stations in order to allow use of the most accurate information that would be obtained from individually calibrated antennas. There is another approach to achieving consistent operation of user equipment, which is recommended here: namely, the observation data messages (i.e. 1004) for all Master Reference Stations of a homogenous network should be referenced to a single antenna (preferably, the ADVNULLANTENNA). The modification of the observation information with respect to antenna phase center variations must be indicated in the disseminated data stream using antenna descriptor messages (i.e. 1008). The antenna descriptor field must then state the descriptor of the antenna (e.g., ADVNULLANTENNA ). Note that the reduction to the ADVNULLANTENNA is defined through the correction of the antenna phase center offsets and variations based on the absolute antenna correction representation. 3.1.7 Scheduling of Network RTK messages

Scheduling of the Network RTK messages is a crucial procedure in the rover application. In general the concept chosen for Network RTK messages accommodates a number of different schemes. In order to achieve interoperability, some guidelines are necessary that limit the scheduling but not the resulting performance. The recommended guidelines for scheduling are:

First, dissemination of raw observation message (1003 or 1004, for example) containing Master reference station data at a high data rate (0.5 – 2 Hz) immediately when information is available (low latency).

Next, dissemination of ionospheric (dispersive) and geometric (non-dispersive) Correction Difference messages for all Auxiliary Reference Stations ((1015 and 1016) or 1017 for GPS and (1037 and 1038) or 1039 for GLONASS) at identical epoch times. The chosen epoch time should be identical to an epoch time as for the respective raw observations of the Master Reference Station. The update rate may be identical or at a lower data rate than for raw observations. For operation with Correction Difference messages (1015 and1016) or (1037 and 1038), the epoch time should be identical for both messages. The maximum interval should not exceed 15 seconds. When Correction Differences are updated at a lower rate than the Master Reference Station observations, both the ionospheric and the geometric carrier phase components may be filtered to reduce the effect of noise.

Network Auxiliary Station Data (1014): The complete set of station information messages for all Master and Auxiliary Reference Stations within the data stream may be distributed over time in order to optimize throughput. The dissemination should be completed after a maximum time span of 15 seconds (optimization of start-up time of rover operation).

Other messages with additional information as needed for proper rover operation (see Table 3.1-2) should be transmitted as required.

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

23

For combined GPS/GLONASS operation, GPS data should be transmitted first. Scheduling schemes within these bounds are recommended for best operation of a Network RTK provider service with Network RTK messages. These recommended guidelines are based on the scheduling used during interoperability testing, using two different update rates. These rates were chosen to represent typical RTK operations in the field, and are described in Tables 3.1-3 and 3.1-4. Other update rates can be employed, but a Service Provider should be aware that these are the only ones that were tested for interoperability.

Table 3.1-3 High Update Rate, for Ease of Comparison Between Different Data Streams

Group Name Message Type Update Rate

Observations (GPS) 1004 1 Hz Station Description 1005 or 1006 As typical in an RTK

operation Antenna description 1007 or 1008 As typical in an RTK

operation Network RTK Network Auxiliary

Station Data 1014

Network RTK GPS Ionospheric Correction Difference

1015 1 Hz

Network RTK GPS Geometric Correction Difference

1016 1 Hz

Table 3.1-4 Update Rate for Typical Operation

Group name Message Type Update rate

Observations (GPS) 1004 1 Hz Station Description 1005 or 1006 As typical in an RTK

operation Antenna description 1007 or 1008 As typical in an RTK

operation Network RTK Network Auxiliary

Station Data 1014

Network RTK GPS Ionospheric Correction Difference

1015 Update completed every 10 seconds

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

24

Group name Message Type Update rate

Network RTK GPS Geometric Correction Difference

1016 Update completed every 10 seconds

3.1.8 Handling of Quarter Cycle Carrier Phase Shifts

Some GNSS receiver manufacturers have implemented carrier phase encoding of Version 3 messages 1001, 1002, 1003, 1004, 1009, 1010, 1011, 1012 in a way that carrier phase observations are in phase for all carrier phases of a specific frequency, i.e. they correct for quarter cycle phase shifts. Others retain the quarter cycle offset between the carrier phase observations in the data. The following table gives the status of implementation as provided by the individual manufacturers:

Table 3.1-5 GNSS Receiver Manufacturers – Handling of Quarter-Cycle Phase Shifts

Geo++ Javad Leica Magellan NavCom NovAtel Septen-trio

Trimble Topcon

GPS L1CA

No correction

No correction

No correction

No correction

No correction

No correction

No correction

No correction

No correction

GPS L1P No correction

0.25 cycles x

λL1) ** added

GPS L2P No correction

No correction

No correction

No correction

No correction

No correction

No correction

No correction

GPS L2Y No correction

No correction

No correction

No correction

No correction

No correction

No correction

No correction

No correction

GPS L2C No correction

No correction

No correction

(0.25 cycles x

λL2) ** added

No correction

No correction

No correction

(0.25 cycles x

λL2) ** added

No correction

GLN L1CA

No correction

No correction

No correction

No correction

No correction

No correction

No correction

No correction

No correction

GLN L1P No correction

No correction

No correction

No correction

No correction

0.25 cycles x

λL1) ** subtracted

No correction

GLN L2P No correction

No correction

No correction

No correction

No correction

No correction

No correction

No correction

No correction

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

25

Geo++ Javad Leica Magellan NavCom NovAtel Septen-trio

Trimble Topcon

GLN L2CA

No correction

No correction

No correction

(0.25 cycles x

λL2) ** added

No correction

No correction

No correction

(0.25 cycles x

λL2) ** added

No correction

** L1 = L1 wavelength and L2 = L2 wavelength To avoid inconsistencies between different manufacturers a two bit indicator was introduced in the messages 1005 and 1006 indicating whether the carrier phases are corrected for satellite induced quarter-cycle phase shifts (provided carrier phase for different signals on the same frequency are available), or whether the carrier phases are not corrected. This indicator provides information only for Message Types1001, 1002, 1003, 1004, 1009, 1010, 1011, 1012. If the Quarter cycle carrier phase indicator is zero, there is no information on the correction of quarter cycle shifts. For message types 1001, 1002, 1003, 1004, 1009, 1010, 1011, 1012, each manufacturer shall maintain the phase relationship conventions specified in Table 3.1-5. This ensures backwards compatibility with legacy receivers that do not make use of the Quarter Cycle Indicator. Manufacturers not listed in this table shall not apply 1/4 cycle shifts. To augment the information in the Type 1033 message, the phase relationships shall be indicated using the Quarter Cycle Indicator in the Type 1005 and 1006 messages (see Tables 3.5-6 and 3.5-7). However, the use of the Quarter Cycle Indicator shall not contradict the information provided in Table 3.1-5. For the network message types 1015-1017 it is necessary that in the case of mixed phase observations derived from a common frequency (e.g. L2C and L2P for GPS), the network software must ensure that the observations are processed with a consistent phase relationship. Firmware updates for any manufacturer should include implementation of Message Type 1033 (to indicate the receiver type) and should also implement the definition of 2 bits in 1005 and 1006. Future messages will require that no corrections be applied to any of the signals in Table 3.1-5.

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RT

CM

10403.2

26

3.2 Message Type Summary

The message types shown in Table 3.2-1 support Real-Time Kinematic (RTK) individual and network broadcasts for GPS and GLONASS.

Table 3.2-1 Message Type Table

Message Type

Message Name No. of Bytes ** Notes

1001 L1-Only GPS RTK Observables 8.00+7.25*Ns

1002 Extended L1-Only GPS RTK Observables 8.00+9.25*Ns

1003 L1&L2 GPS RTK Observables 8.00+12.625*Ns

1004 Extended L1&L2 GPS RTK Observables 8.00+15.625*Ns

1005 Stationary RTK Reference Station ARP 19

1006 Stationary RTK Reference Station ARP with Antenna Height

21

1007 Antenna Descriptor 5-36

1008 Antenna Descriptor & Serial Number 6-68

1009 L1-Only GLONASS RTK Observables 7.625+8*Ns

1010 Extended L1-Only GLONASS RTK Observables

7.625+9.875*Ns

1011 L1&L2 GLONASS RTK Observables 7.625+13.375*Ns

1012 Extended L1&L2 GLONASS RTK Observables

7.625+16.25*Ns

1013 System Parameters 8.75+3.625*Nm Nm = Number of Message Types Transmitted

1014 Network Auxiliary Station Data 14.625

© RTCM – Not for reproduction or redistribution

RT

CM

10403.2

27

Message Type


1015 GPS Ionospheric Correction Differences 9.5 + 3.5*Ns

1016 GPS Geometric Correction Differences 9.5 + 4.5*Ns

1017 GPS Combined Geometric and Ionospheric Correction Differences

9.5 + 6.625*Ns

1018 RESERVED for Alternative Ionospheric Correction Difference Message

1019 GPS Ephemerides 61 One message per satellite

1020 GLONASS Ephemerides 45 One message per satellite

1021 Helmert / Abridged Molodenski Transformation Parameters

51.5+N+M N = Number of characters in Source Name M = Number of characters in Target Name

1022 Molodenski-Badekas Transformation Parameters

64.625+N+M N = Number of characters in Source Name M = Number of characters in Target Name

1023 Residuals, Ellipsoidal Grid Representation 72.25

1024 Residuals, Plane Grid Representation 73.75

1025 Projection Parameters, Projection Types other than Lambert Conic Conformal (2 SP) and Oblique Mercator

24.5

1026 Projection Parameters, Projection Type LCC2SP (Lambert Conic Conformal (2 SP))

29.25

1027 Projection Parameters, Projection Type OM (Oblique Mercator)

32.25

1028 (Reserved for Global to Plate-Fixed Transformation)


RT

CM

10403.2

28

Message Type


1029 Unicode Text String 9+N N = Number of UTF-8 Code Units

1030 GPS Network RTK Residual Message 7+6.125*Ns

1031 GLONASS Network RTK Residual Message

6.625+6.125*Ns

1032 Physical Reference Station Position Message

19.5

1033 Receiver and Antenna Descriptors 9+M+N+I+J+K N = Number of characters in antenna descriptor M = Number of characters in antenna serial number

I = Number of characters in receiver descriptor

J = Number of characters in firmware descriptor

K = Number of characters in receiver serial number

1034 GPS Network FKP Gradient 6.125+8.25*Ns

1035 GLONASS Network FKP Gradient 5.75+8.25*Ns

1037 GLONASS Ionospheric Correction Differences

9.125+3.5*Ns

1038 GLONASS Geometric Correction Differences

9.125+4.5*Ns

1039 GLONASS Combined Geometric and Ionospheric Correction Differences

9.125+6.625*Ns

1057 SSR GPS Orbit Correction 8.5+16.875*NS

1058 SSR GPS Clock Correction 8.375+9.5*NS

1059 SSR GPS Code Bias 8.375+1.375*NS +2.375 ∑ NCB

NCB = No. of Code Biases per individual Satellite


RT

CM

10403.2

29

Message Type


1060 SSR GPS Combined Orbit and Clock Corrections

8.5+25.625*NS

1061 SSR GPS URA 8.375+1.5*NS

1062 SSR GPS High Rate Clock Correction 8.375+3.5*NS

1063 SSR GLONASS Orbit Correction 8.125+16.75*NS

1064 SSR GLONASS Clock Correction 8+9.375*NS

1065 SSR GLONASS Code Bias 8+1.250*NS +2.375 ∑ NCB

NCB = No. of Code Biases per individual Satellite

1066 SSR GLONASS Combined Orbit and Clock Correction

8.125+25.5*NS

1067 SSR GLONASS URA 8+1.375*NS

1068 SSR GLONASS High Rate Clock Correction

8+3.375*NS

1070 Reserved MSM

1071 GPS MSM1 See Table 3.5-71







1078 Reserved MSM


RT

CM

10403.2

30

Message Type


1079 Reserved MSM

1080 Reserved MSM

1081 GLONASS MSM1 See Table 3.5-71







1088 Reserved MSM

1089 Reserved MSM

1090 Reserved MSM

1091 GALILEO MSM1 See Table 3.5-71







1098-1229

Reserved MSM


RT

CM

10403.2

31

Message Type


1230 GLONASS L1 and L2 Code-Phase Biases 32+16*N N = Number of Code-Phase Biases (max 4)

4001-4095

Proprietary Messages These message types are assigned to specific companies for the broadcast of proprietary information. See Section 3.6.

Ns = No. of Satellites

** Fill bits (zeros) must be used to complete the last byte at the end of the message data before the CRC in order to maintain the last byte boundary. Thus the total number of bytes must be the next full integer if fill bits are needed. For example, 55.125 computed bytes means 56 bytes total.

3.3 Data Types

The data types used are shown in Table 3.3-1. Note that floating point quantities are not used.

Table 3.3-1 Data Type Table

Data Type

Description Range Data Type Notes

bit(n) bit field 0 or 1, each bit Reserved bits set to “0”

char8(n) 8 bit characters, ISO 8859-1 (not limited to ASCII)

character set Reserved or unused characters: [0x00]

int8 8 bit 2’s complement integer 127 -128 indicates data not available




int15 15 bit 2’s complement integer 16,383 -16,384 indicates data not available


RT

CM

10403.2

32

Data Type




int19 19 bit bit 2’s complement integer

262,143 -262,144 indicates data not available

int20 20 bit 2’s complement integer 524, 287 -524,288 indicates data not available

int21 21 bit 2’s complement integer 1,048,575 -1,048,576 indicates data not available






int27 27 bit 2's complement integer ± 67,108,814 -67,108,815 indicates data not available


int32 32 bit 2’s complement integer 2,147,483,647 -2,147,483,648 indicates data not available




uint2 2 bit unsigned integer 0 to 3





RT

CM

10403.2

33

Data Type









uint14 14 bit unsigned integer 0 to 16,383




uint20 20 bit unsigned integer 0 to 1,048,575






uint30 30 bit unsigned integer 0 to 1,073,741,823





RT

CM

10403.2

34

Data Type


intS5 5 bit sign-magnitude integer 15 See Note 1

intS11 11 bit sign-magnitude integer 1023 See Note 1

intS22 22 bit sign-magnitude integer 2,097,151 See Note 1



intS32 32 bit sign-magnitude integer 2,147,483,647 See Note 1

utf8(N) Unicode UTF-8 Code Unit 00h to FFh 8-bit value that contains all or part of a Unicode UTF-8 encoded character

Note 1. Sign-magnitude representation records the number's sign and magnitude. MSB is 0 for positive numbers and 1 for negative numbers. The rest of the bits are the number’s magnitude. For example, for 8-bit words, the representations of the numbers “-5” and “+5” in a binary form are 10000101 and 00000101, respectively. Negative zero is not used.


RT

CM

10403.2

35

3.4 Data Fields

The data fields used are shown in Table 3.4-1. Each Data Field (DF) uses one of the Data Types of Table 3.3-1. Note that the Data Field ranges may be less than the maximum possible range allowed by the Data Type.

Table 3.4-1 Data Field Table

DF # DF Name DF Range DF

Resolution Data Type

Data Field Notes

DF001 Reserved bit(n) All reserved bits should be set to “0”. However, since the value is subject to change in future versions, decoding should not rely on a zero value.

DF002 Message Number 0-4095 uint12

DF003 Reference Station ID

0-4095 uint12

The Reference Station ID is determined by the service provider. Its primary purpose is to link all message data to their unique source. It is useful in distinguishing between desired and undesired data in cases where more than one service may be using the same data link frequency. It is also useful in accommodating multiple reference stations within a single data link transmission.

In reference network applications the Reference Station ID plays an important role, because it is the link between the observation messages of a specific reference station and its auxiliary information contained in other messages for proper operation. Thus the Service Provider should ensure that the Reference Station ID is unique within the whole network, and that ID’s should be reassigned only when absolutely necessary.

Service Providers may need to coordinate their Reference Station ID assignments with other Service Providers in their region in order to avoid conflicts. This may be especially critical for equipment accessing multiple services, depending on their services and means of information distribution.

DF004 GPS Epoch Time (TOW)

0-604,799,999 ms 1 ms uint30 GPS Epoch Time is provided in milliseconds from the beginning of the GPS week, which begins at midnight GMT on Saturday night/Sunday morning, measured in GPS time (as opposed to UTC).


RT

CM

10403.2

36



Data Field Notes

DF005 Synchronous GNSS Message Flag

bit(1)

0 - No further GNSS observables referenced to the same Epoch Time will be transmitted. This enables the receiver to begin processing the data immediately after decoding the message.

1 - The next message will contain observables of another GNSS source referenced to the same Epoch Time.

Note: “Synchronous" here means that the measurements are taken within one microsecond of each other

DF006 No. of GPS Satellite Signals Processed

0-31 uint5 The Number of GPS Satellite Signals Processed refers to the number of satellites in the message. It does not necessarily equal the number of satellites visible to the Reference Station.

DF007 GPS Divergence-free Smoothing Indicator

bit(1) 0 - Divergence-free smoothing not used 1 - Divergence-free smoothing used

DF008 GPS Smoothing Interval

See Table 3.4-4 bit(3)

The GPS Smoothing Interval is the integration period over which reference station pseudorange code phase measurements are averaged using carrier phase information. Divergence-free smoothing may be continuous over the entire period the satellite is visible.

DF009 GPS Satellite ID 1-63 (See Table 3.4-3)

uint6

A GPS Satellite ID number from 1 to 32 refers to the PRN code of the GPS satellite. Satellite ID’s higher than 32 are reserved for satellite signals from Satellite-Based Augmentation Systems (SBAS’s) such as the FAA’s Wide-Area Augmentation System (WAAS). SBAS PRN codes cover the range 120-138. The Satellite ID’s reserved for SBAS satellites are 40-58, so that the SBAS PRN codes are derived from the Version 3 Satellite ID codes by adding 80.

DF010 GPS L1 Code Indicator

bit(1)

The GPS L1 Code Indicator identifies the code being tracked by the reference station. Civil receivers can track the C/A code, and optionally the P code, while military receivers can track C/A, and can also track P and Y code, whichever is broadcast by the satellite

0 - C/A Code

1 - P(Y) Code Direct


RT

CM

10403.2

37



Data Field Notes

DF011 GPS L1 Pseudorange

0-299,792.46 m 0.02 m uint24

The GPS L1 Pseudorange field provides the raw L1 pseudorange measurement at the reference station in meters, modulo one light-millisecond (299,792.458 meters). The GPS L1 pseudorange measurement is reconstructed by the user receiver from the L1 pseudorange field by:

(GPS L1 pseudorange measurement) = (GPS L1 pseudorange field) modulo (299,792.458 m) + integer as determined from the user receiver's estimate of the reference station range, or as provided by the extended data set.

80000h - invalid L1 pseudorange; used only in the calculation of L2 measurements.

DF012 GPS L1 PhaseRange – L1 Pseudorange

± 262.1435 m

(See Data Field Note)

0.0005 m int20

The GPS L1 PhaseRange – L1 Pseudorange field provides the information necessary to determine the L1 phase measurement. Note that the PhaseRange defined here has the same sign as the pseudorange. The PhaseRange has much higher resolution than the pseudorange, so that providing this field is just a numerical technique to reduce the length of the message. At start up and after each cycle slip, the initial ambiguity is reset and chosen so that the L1 PhaseRange should match the L1 Pseudorange as closely as possible (i.e., within 1/2 L1 cycle) while not destroying the integer nature of the original carrier phase observation. The Full GPS L1 PhaseRange is constructed as follows (all quantities in units of meters): (Full L1 PhaseRange) = (L1 pseudorange as reconstructed from L1 pseudorange field) + (GPS L1 PhaseRange – L1 Pseudorange field) Certain ionospheric conditions might cause the GPS L1 PhaseRange – L1 Pseudorange to diverge over time across the range limits defined. Under these circumstances the computed value needs to be adjusted (rolled over) by the equivalent of 1500 cycles in order to bring the value back within the range. See also comments in sections 3.1.6 and 3.5.1 for correction of antenna phase center variations in Network RTK applications.

80000h - L1 phase is invalid; used only in the calculation of L2 measurements.


RT

CM

10403.2

38



Data Field Notes

DF013

GPS L1 Lock Time Indicator

See Table 3.4-2 uint7

The GPS L1 Lock Time Indicator provides a measure of the amount of time that has elapsed during which the Reference Station receiver has maintained continuous lock on that satellite signal. If a cycle slip occurs during the previous measurement cycle, the lock indicator will be reset to zero.

DF014

GPS Integer L1 Pseudorange Modulus Ambiguity

0-76,447,076.790 m

299,792.458 m

uint8

The GPS Integer L1 Pseudorange Modulus Ambiguity represents the integer number of full pseudorange modulus divisions (299,792.458 m) of the raw L1 pseudorange measurement.

DF015 GPS L1 CNR 0-63.75 dB-Hz 0.25 dB-Hz uint8 The GPS L1 CNR measurements provide the reference station's estimate of the carrier-to-noise ratio of the satellite’s signal in dB-Hz.

0 - the CNR measurement is not computed.


RT

CM

10403.2

39



Data Field Notes

DF016 GPS L2 Code Indicator

bit(2)

The GPS L2 Code Indicator depicts which L2 code is processed by the reference station, and how it is processed.

0 - C/A or L2C code 1 - P(Y) code direct 2 - P(Y) code cross-correlated 3 - Correlated P/Y

The GPS L2 Code Indicator refers to the method used by the GPS reference station receiver to recover the L2 pseudorange. The GPS L2 Code Indicator should be set to “0” (C/A or L2C code) for any of the L2 civil codes. It is assumed here that a satellite will not transmit both C/A code and L2C code signals on L2 simultaneously, so that the reference station and user receivers will always utilize the same signal. The code indicator should be set to “1” if the satellite’s signal is correlated directly, i.e., either P code or Y code depending whether anti-spoofing (AS) is switched off or on. The code indicator should be set to “2” when the reference station receiver L2 pseudorange measurement is derived by adding a cross-correlated pseudorange measurement (Y2-Y1) to the measured L1 C/A code. The code indicator should be set to 3 when the GPS reference station receiver is using a proprietary method that uses only the L2 P(Y) code signal to derive L2 pseudorange.

DF017 GPS L2-L1 Pseudorange Difference

± 163.82 m


0.02m int14

The GPS L2-L1 Pseudorange Difference field is utilized, rather than the full L2 pseudorange, in order to reduce the message length. The receiver must reconstruct the L2 code phase pseudorange by using the following formula:

(GPS L2 pseudorange measurement) =

(GPS L1 pseudorange as reconstructed from L1 pseudorange field) + (GPS L2-L1 pseudorange field)

2000h (-163.84m) - no valid L2 code available, or that the value exceeds the allowed range.


RT

CM

10403.2

40



Data Field Notes

DF018 GPS L2 PhaseRange – L1 Pseudorange

± 262.1435 m


0.0005 m int20

The GPS L2 PhaseRange - L1 Pseudorange field provides the information necessary to determine the L2 phase measurement. Note that the PhaseRange defined here has the same sign as the pseudorange. The PhaseRange has much higher resolution than the pseudorange, so that providing this field is just a numerical technique to reduce the length of the message. At start up and after each cycle slip, the initial ambiguity is reset and chosen so that the L2 PhaseRange should match the L1 Pseudorange as closely as possible (i.e., within 1/2 L2 cycle) while not destroying the integer nature of the original carrier phase observation. The Full GPS L2 PhaseRange is constructed as follows (all quantities in units of meters):

(Full L2 PhaseRange) = (L1 pseudorange as reconstructed from L1 pseudorange field) + (GPS L2 PhaseRange – L1 Pseudorange field)

Certain ionospheric conditions might cause the GPS L2 PhaseRange – L1 Pseudorange to diverge over time across the range limits defined. Under these circumstances the computed value needs to be adjusted (rolled over) by the equivalent of 1500 cycles in order to bring the value back within the range. Note: A bit pattern equivalent to 80000h in this field indicates an invalid carrier phase measurement that should not be processed by the mobile receiver. This indication may be used at low signal levels where carrier tracking is temporarily lost, but code tracking is still possible.

See also comments in sections 3.1.6 and 3.5.1 for correction of antenna phase center variations in Network RTK applications.

DF019 GPS L2 Lock Time Indicator


The GPS L2 Lock Time Indicator provides a measure of the amount of time that has elapsed during which the Reference Station receiver has maintained continuous lock on that satellite signal. If a cycle slip occurs during the previous measurement cycle, the lock indicator will be reset to zero.


RT

CM

10403.2

41



Data Field Notes

DF020 GPS L2 CNR 0-63.75 dB-Hz 0.25 dB-Hz uint8 The GPS L2 CNR measurements provide the reference station's estimate of the carrier-to-noise ratio of the satellite’s signal in dB-Hz.

0 - the CNR measurement is not computed

DF021 ITRF Realization Year

uint6

Since this field is reserved, all bits should be set to zero for now. However, since the value is subject to change in future versions, decoding should not rely on a zero value.

The ITRF realization year identifies the datum definition used for coordinates in the message.

DF022 GPS Indicator bit(1) 0 - No GPS service supported 1 - GPS service supported

DF023 GLONASS Indicator

bit(1) 0 - No GLONASS service supported 1 - GLONASS service supported

DF024 Galileo Indicator bit(1) 0 - No Galileo service supported 1 - Galileo service supported

DF025 Antenna Ref. Point ECEF-X

± 13,743,895.3471 m

0.0001 m int38 The antenna reference point X-coordinate is referenced to ITRF epoch as given in DF021.

DF026 Antenna Ref. Point ECEF-Y

± 13,743,895.3471 m

0.0001 m int38 The antenna reference point Y-coordinate is referenced to ITRF epoch as given in DF021.

DF027 Antenna Ref. Point ECEF-Z

± 13,743,895.3471 m

0.0001 m int38 The antenna reference point Z-coordinate is referenced to ITRF epoch as given in DF021.

DF028 Antenna Height 0-6.5535 m 0.0001 m uint16 The Antenna Height field provides the height of the Antenna Reference Point above the marker used in the survey campaign.

DF029 Descriptor Counter 0-31 uint8 The Descriptor Counter defines the number of characters (bytes) to follow in DF030, Antenna Descriptor


RT

CM

10403.2

42



Data Field Notes

DF030 Antenna Descriptor

char8 (n)

Alphanumeric characters. IGS limits the number of characters to 20 at this time, but this DF allows more characters for future extension.

DF031 Antenna Setup ID 0-255 uint8

0 - Use standard IGS Model 1-255 - Specific Antenna Setup ID#

The Antenna Setup ID is a parameter for use by the service provider to indicate the particular reference station-antenna combination. The number should be increased whenever a change occurs at the station that affects the antenna phase center variations. While the Antenna Descriptor and the Antenna Serial Number give an indication of when the installed antenna has been changed, it is envisioned that other changes could occur. For instance the antenna may have been repaired, or the surrounding of the antenna may have been changed and the provider of the service may want to make the user station aware of the change. Depending on the change of the phase center variations due to a setup change, a change in the Antenna Setup ID would mean that the user should check with the service provider to see if the antenna phase center variation in use is still valid. Of course, the provider must make appropriate information available to the users.

DF032 Serial Number Counter

0-31 uint8 The Serial Number Counter defines the number of characters (bytes) to follow in Antenna Serial Number

DF033 Antenna Serial Number

char8 (n)

Alphanumeric characters. The Antenna Serial Number is the individual antenna serial number as issued by the manufacturer of the antenna. A possible duplication of the Antenna Serial Number is not possible, because together with the Antenna Descriptor only one antenna with the particular number will be available. In order to avoid confusion the Antenna Serial Number should be omitted when the record is used together with reverse reduction to model type calibration values, because it cannot be allocated to a real physical antenna.

DF034 GLONASS Epoch

Time (tk) 0-86,400,999 ms 1 ms uint27

GLONASS Epoch Time of measurement is defined by the GLONASS ICD as UTC(SU) + 3.0 hours. It rolls over at 86,400 seconds for GLONASS, except for the leap second, where it rolls over at 86,401.


RT

CM

10403.2

43



Data Field Notes

DF035

No. of GLONASS Satellite Signals Processed

0-31 1 uint5

The Number of GLONASS Satellite Signals Processed refers to the number of satellites in the message. It does not necessarily equal the number of satellites visible to the Reference Station.

DF036

GLONASS Divergence-free Smoothing Indicator

bit(1)

0 - Divergence-free smoothing not used 1 - Divergence-free smoothing used

DF037 GLONASS Smoothing Interval


The GLONASS Smoothing Interval is the integration period over which reference station pseudorange code phase measurements are averaged using carrier phase information. Divergence-free smoothing may be continuous over the entire period the satellite is visible.

DF038

GLONASS Satellite ID (Satellite Slot Number)

0-63 (See Table 3.4-3)

uint6

A GLONASS Satellite ID number from 1 to 24 refers to the slot number of the GLONASS satellite. A Satellite ID of zero indicates that the slot number is unknown. Satellite ID’s higher than 32 are reserved for satellite signals from Satellite-Based Augmentation Systems (SBAS’s). SBAS PRN codes cover the range 120-138. The Satellite ID’s reserved for SBAS satellites are 40-58, so that the SBAS PRN codes are derived from the Version 3 GLONASS Satellite ID codes by adding 80.

0 – The slot number is unknown

1 to 24 – Slot number of the GLONASS satellite

>32 – Reserved for Satellite-Based Augmentation Systems (SBAS).

Note: For GLONASS-M satellites this data field has to contain the GLONASS-M word “n”, thus the Satellite Slot Number is always known (cannot be equal to zero) for GLONASS-M satellites.

DF039 GLONASS L1 Code Indicator

bit(1) 0 - C/A Code; 1 - P Code


RT

CM

10403.2

44



Data Field Notes

DF040

GLONASS Satellite Frequency Channel Number

0-20 (See Table 3.4-5)

1 uint5

The GLONASS Satellite Frequency Channel Number identifies the frequency of the GLONASS satellite. By providing both the Slot ID and the Frequency Code of the satellite, the user instantly knows the frequency of the satellite without requiring an almanac.

0 - –07 1 - –06

…

19 - +12

20 - +13

DF041 GLONASS L1 Pseudorange

0-599,584.92 m 0.02 m uint25

The GLONASS L1 Pseudorange field provides the raw L1 pseudorange measurement at the reference station in meters, modulo two light-milliseconds (599,584.916 meters). The L1 pseudorange measurement is reconstructed by the user receiver from the L1 pseudorange field by: (L1 pseudorange measurement) = (L1 pseudorange field) modulo (599,584.916 m) + integer as determined from the user receiver's estimate of the reference station range, or as provided by the extended data set.


RT

CM

10403.2

45



Data Field Notes

DF042 GLONASS L1 PhaseRange – L1 Pseudorange

± 262.1435 m


0.0005 m int20

The GLONASS L1 PhaseRange – L1 Pseudorange field provides the information necessary to determine the L1 phase measurement. Note that the PhaseRange defined here has the same sign as the pseudorange. The PhaseRange has much higher resolution than the pseudorange, so that providing this field is just a numerical technique to reduce the length of the message. At start up and after each cycle slip, the initial ambiguity is reset and chosen so that the L1 PhaseRange should match the L1 Pseudorange as closely as possible (i.e., within 1/2 L1 cycle) while not destroying the integer nature of the original carrier phase observation. The Full GLONASS L1 PhaseRange is constructed as follows (all quantities in units of meters):

(Full L1 PhaseRange) = (L1 pseudorange as reconstructed from L1 pseudorange field) + (GLONASS L1 PhaseRange – GLONASS L1 Pseudorange field)

Certain ionospheric conditions might cause the GLONASS L1 PhaseRange – L1 Pseudorange to diverge over time across the range limits defined. Under these circumstances the computed value needs to be adjusted (rolled over) by the equivalent of 1500 cycles in order to bring the value back within the range.

80000h - invalid carrier phase measurement. This indication may be used at low signal levels where carrier tracking is temporarily lost, but code tracking is still possible.

DF043 GLONASS L1 Lock Time Indicator


The GLONASS L1 Lock Time Indicator provides a measure of the amount of time that has elapsed during which the Reference Station receiver has maintained continuous lock on that satellite signal. If a cycle slip occurs during the previous measurement cycle, the lock indicator will be reset to zero.


RT

CM

10403.2

46



Data Field Notes

DF044

GLONASS Integer L1 Pseudorange Modulus Ambiguity

0-76,147,284.332 m

599,584.916m

uint7

The GLONASS Integer L1 Pseudorange Modulus Ambiguity represents the integer number of full pseudorange modulus divisions (599,584.916 m) of the raw L1 pseudorange measurement

DF045 GLONASS L1 CNR

0-63.75 dB-Hz 0.25 dB-Hz uint8 The GLONASS L1 CNR measurements provide the reference station's estimate of the carrier-to-noise ratio of the satellite’s signal in dB-Hz.

0 - the CNR measurement is not computed.

DF046 GLONASS L2 Code Indicator

bit(2)

The GLONASS L2 Code Indicator depicts which L2 code is processed by the reference station.

0 - C/A code 1- P code 2 - Reserved 3 - Reserved

DF047

GLONASS L2-L1 Pseudorange Difference

± 163.82 m


0.02m int14

The GLONASS L2-L1 Pseudorange Difference field is utilized, rather than the full L2 pseudorange, in order to reduce the message length. The receiver must reconstruct the L2 code phase pseudorange by using the following formula:

(GLONASS L2 pseudorange measurement) = (L1 pseudorange as reconstructed from L1 pseudorange field) + (L2-L1 pseudorange field)

200 h (-163.84) – there is no valid L2 code available, or the value exceeds the allowed range.


RT

CM

10403.2

47



Data Field Notes

DF048 GLONASS L2 PhaseRange – L1 Pseudorange

± 262.1435 m


0.0005 m int20

The GLONASS L2 PhaseRange - L1 Pseudorange field provides the information necessary to determine the L2 phase measurement. Note that the PhaseRange defined here has the same sign as the pseudorange. The PhaseRange has much higher resolution than the pseudorange, so that providing this field is just a numerical technique to reduce the length of the message. At start up and after each cycle slip, the initial ambiguity is reset and chosen so that the L2 PhaseRange should match the L1 Pseudorange as closely as possible (i.e., within 1/2 L2 cycle) while not destroying the integer nature of the original carrier phase observation. The Full GLONASS L2 PhaseRange is constructed as follows (all quantities in units of meters):

(Full L2 PhaseRange) = (L1 pseudorange as reconstructed from L1 pseudorange field) + (GLONASS L2 PhaseRange – L1 Pseudorange field) Certain ionospheric conditions might cause the GLONASS L2 PhaseRange – L1 Pseudorange to diverge over time across the range limits defined. Under these circumstances the computed value needs to be adjusted (rolled over) by the equivalent of 1500 cycles in order to bring the value back within the range.

80000h - invalid carrier phase measurement. This indication may be used at low signal levels where carrier tracking is temporarily lost, but code tracking is still possible.

DF049 GLONASS L2 Lock Time Indicator


The GLONASS L2 Lock Time Indicator provides a measure of the amount of time that has elapsed during which the Reference Station receiver has maintained continuous lock on that satellite signal. If a cycle slip occurs during the previous measurement cycle, the lock indicator will be reset to zero.

DF050 GLONASS L2 CNR

0-63.75 dB-Hz 0.25 dB-Hz uint8 The GLONASS L2 CNR measurements provide the reference station's estimate of the carrier-to-noise ratio of the satellite’s signal in dB-Hz.

0 – The CNR measurement is not computed.


RT

CM

10403.2

48



Data Field Notes

DF051 Modified Julian Day (MJD) Number

0-65,535 days 1 day uint16

Modified Julian Day number (MJD) is the continuous count of day numbers since November 17, 1858 midnight. For example, the first day in GPS week 0 has MJD 44244. The full MJD number shall always be transmitted. At this point in time the rollover of the MJD is quite far away in time, but experience with the Y2K problem showed that the actual life of software and applications can be considerably longer than expected. Therefore, it is foreseen to have a rollover of the MJD in calendar year 2038. At day 65,536 MJD the counter will start at 0 again.

DF052 Seconds of Day (UTC)

0-86,400 s 1 second uint17

Seconds Of Day (UTC) are the seconds of the day counted from midnight Greenwich time. GPS seconds of week have to be adjusted for the appropriate number of leap seconds.

86,400 - a leap second has been issued.

DF053

Number of Message ID Announcements

to Follow (Nm)

0-31 1 uint5

The Number of Message ID Announcements to follow informs the receiver of the number of message types and the frequency of their broadcast by the reference station.

DF054 Leap Seconds, GPS-UTC

0-254 s 1 second uint8 See the GPS/SPS Signal Specification, available from the U.S. Coast Guard Navigation Information Service.

255 - the value is not provided.

DF055 Message ID 0-4095 1 uint12 Each announcement lists the Message ID as transmitted by the reference station.

DF056 Message Sync Flag

bit(1) 0 - Asynchronous – not transmitted on a regular basis 1 - Synchronous – scheduled for transmission at regular intervals

DF057 Message Transmission Interval

0-6,553.5 s 0.1 seconds uint16 Each announcement lists the Message Transmission Interval as transmitted by the reference station. If asynchronous, the transmission interval is approximate.


RT

CM

10403.2

49



Data Field Notes

DF058 Number of Auxiliary Stations Transmitted

0 – 31 1 uint5 Number of Auxiliary Reference Stations Transmitted in conjunction with designated Master Reference Station. Defines the number of different messages received of one type.

DF059 Network ID 0 - 255 1 uint8

Network ID defines the network and the source of the particular set of reference stations and their observation information belongs to. The service provider should ensure that the Network ID is unique in the region serviced. The Network ID indicates an area and its reference stations where the service providers will provide a homogenous solution with leveled integer ambiguities between its reference stations. In general the area indicated by Network ID will comprise one subnetwork with a unique Subnetwork ID. (See description on how to use Network IDs and Subnetwork IDs in Section 3.5.6.).

DF060 Master Reference Station ID

0 – 4095 1 uint12

The Master Reference Station must have the identical ID as one of the reference stations used within the same data stream for providing observation or correction information. The Master Auxiliary Concept allows in principle for several Master Reference Stations in the same data stream. Every Master Reference Station would require a separate raw observation message transmitted for the identical reference station. However for the current version of the standard it is recommended to have only one Master Reference Station in a data stream (see also Section 3.1.5).

DF061 Auxiliary Reference Station ID

0 – 4095 1 uint12 Station ID to identify Auxiliary Reference Station used to derive attached information.


RT

CM

10403.2

50



Data Field Notes

DF062 Aux-Master Delta Latitude

±13.1071 degrees

25 x 10-6 degrees

int20

Delta value in latitude of Antenna Reference Point of “Auxiliary Reference Station minus Master Reference Station” in geographical coordinates based on GRS80 ellipsoid parameters for the same ECEF system as used in message 1005 or 1006 within the same data stream. Note: in severe ionospheric conditions it may not be possible to provide complete service over the entire allowed range, because Ionospheric Correction Differences may exceed the allowed range of DF069.

DF063 Aux-Master Delta Longitude

±26.2142 degrees

25 x 10-6 degrees

int21

Delta value in longitude of Antenna Reference Point of “Auxiliary Reference Station minus Master Reference Station” in geographical coordinates based on GRS80 ellipsoid parameters for the same ECEF system as used in message 1005 or 1006 within the same data stream. Note: in severe ionospheric conditions it may not be possible to provide complete service over the entire allowed range, because Ionospheric Correction Differences may exceed the allowed range of DF069.

DF064 Aux-Master Delta Height

±4194.303 m 1 mm int23

Delta value in ellipsoidal height of Antenna Reference Point of “Auxiliary Reference Station minus Master Reference Station” in geographical coordinates based on GRS80 ellipsoid parameters for the same ECEF system as used in message 1005 or 1006 within the same data stream.

DF065 GPS Epoch Time (GPS TOW)

0 - 603,799.9 sec 0.1 sec uint23 Epoch time of observations used to derive correction differences

DF066 GPS Multiple Message Indicator

0-1 1 bit(1) 1 - Messages with the same Message Number and Epoch Time will

be transmitted in sequence.

0 - Last message of a sequence.

DF067 Number of GPS Satellites

0 - 15 1 uint4

Number of correction differences for GPS satellites contained in message. Only one message per Auxiliary-Master Reference Station pair and Epoch Time is allowed. Each message shall contain respective correction differences for all satellites tracked at the relevant Master-Auxiliary Reference Station combination

DF068 GPS Satellite ID 1 – 32 1 uint6


RT

CM

10403.2

51



Data Field Notes

DF069

GPS Ionospheric Carrier Phase Correction Difference

±32.767 m 0.5 mm int17

Ionospheric Carrier Phase Correction Difference (ICPCD) is the Correction Difference for ionospheric part calculated based on integer leveled L1 and L2 correction differences (L1CD and L2CD).

CDLff

fCDL

ff

fICPCD 21

21

22

22

21

22

22

L1CD, L2CD, and ICPCD are presented in meters.

(See discussion of L1 and L2 corrections in Section 3.5.6.)

In extreme conditions the value of this field may lie outside the specified range. If this happens, the data block for the specific satellite containing this field (Tables 3.5-18 & 20) should not be transmitted.

DF070

GPS Geometric Carrier Phase Correction Difference

±32.767 m 0.5 mm int17

Geometric Carrier Phase Correction Difference (GCPCD) is the Correction Difference for geometric part calculated based on integer leveled L1 and L2 correction differences (L1CD and L2CD).

CDLff

fCDL

ff

fGCPCD 21

22

21

22

22

21

21

L1CD, L2CD, and ICPCD are presented in meters. (See discussion of L1 and L2 corrections in Section 3.5.6.)

DF071 GPS IODE 1 bit(8) IODE value of broadcast ephemeris used for calculation of Correction Differences.


RT

CM

10403.2

52



Data Field Notes

DF072 Subnetwork ID 0 – 15 uint4

Subnetwork ID identifies the subnetwork of a network identified by Network ID. In general the area indicated by Network ID will consist of one subnetwork. The Subnetwork ID indicates the actual solution number of integer ambiguity level (see the description of Integer Ambiguity Level in Section 3.5.6). If one network has only one subnetwork, this indicates that an ambiguity level throughout the whole network is established. In case of problems it might not be possible to have one homogenous integer ambiguity leveled solution throughout the whole network. The solution might break up into several homogeneous solutions, which can be indicated and distinguished by separate Subnetwork IDs. Every independent homogeneous integer ambiguity leveled solution needs to have an independent Subnetwork ID. Master Reference Stations with different Subnetwork IDs indicate that no hand-over from one to another Master Reference Station is possible since the solutions are not consistent and have no common stations. (See description on how to use Network IDs and Subnetwork IDs in Section 3.5.6. or Appendix A.1.)

Note: Subnetwork ID’s greater than “0” should be utilized only if the associated messages for Master Reference Station observations (1001 through 1004 for GPS or 1009 through 1012 for GLONASS) are brought to the same Ambiguity Level. It is recommended that this field be set to “0” for now. In the future a Subnetwork ID of “0” will indicate that corresponding raw data streams are not ambiguity-leveled.

Note: for RTCM 10403 of the standard, only one Master Reference Station with its associated Auxiliary Stations should be used in a single data stream. The result of this restriction is that Subnetwork ID’s may not be needed. Future versions are expected to support Subnetwork ID’s.

DF073 RESERVED for Provider ID

0 – 255 uint8 Unique ID identifying a service provider for a region. Service providers have to make that they are using a unique ID that is not used by another service provider in the region.


RT

CM

10403.2

53



Data Field Notes

DF074 GPS Ambiguity Status Flag

0 – 3 bit(2)

0 - Reserved for future use (artificial observations)

1 - Correct Integer Ambiguity Level for L1 and L2

2 - Correct Integer Ambiguity Level for L1-L2 widelane

3 - Uncertain Integer Ambiguity Level. Only a likely guess is used.

(See the description of Correct Integer Ambiguity Level and Ambiguity Status Flag in Section 3.5.6.)

DF075 GPS Non Sync Count

0 – 7 uint3

Whenever an unrecoverable cycle slip occurs this count shall be increased. The counter shall not be increased more than once per minute. (See the discussion of cycle slips and ambiguity levels in Section 3.5.6)

DF076 GPS Week number 0 -1023 1 week uint10 Roll-over every 1024 weeks starting from Midnight on the night of January 5/Morning January 6, 1980

DF077 GPS SV Acc. (URA)

N/A bit(4) Units: meters; see GPS SPS Signal Spec, 2.4.3.2

DF078 GPS CODE ON L2

0-3 1 bit(2)

00 - Reserved

01 - P code ON

10 - C/A code ON

11 - L2C ON

DF079 GPS IDOT See Note 1 2-43 semi-circles/sec int14

DF080 GPS IODE 0-255 1 uint8 see GPS SPS Signal Spec, 2.4.4.2

DF081 GPS toc 607,784 24s uint16

DF082 GPS af2 See Note 1 2-55 sec/sec2 int8

DF083 GPS af1 See Note 1 2-43 sec/sec int16

DF084 GPS af0 See Note 1 2-31 sec int22


RT

CM

10403.2

54



Data Field Notes

DF085 GPS IODC 0-1023 1 uint10 The 8 LSBs of IODC contains the same bits and sequence as those in IODE; see GPS SPS Signal Spec, 2.4.3.4.

DF086 GPS Crs See Note 1 2-5 m int16

DF087 GPS n (DELTA n)

See Note 1 2-43 semi-circles/sec int16

DF088 GPS M0 See Note 1 2-31 semi-circles int32

DF089 GPS Cuc See Note 1 2-29 rad int16

DF090 GPS Eccentricity (e)

0.03 2-33 uint32

DF091 GPS Cus See Note 1 2-29 rad int16

DF092 GPS (A)1/2 See Note 1 2-19 m1/2 uint32

DF093 GPS toe 604,784 24 sec uint16

DF094 GPS Cic See Note 1 2-29 rad int16

DF095 GPS 0

(OMEGA)0 See Note 1

2-31 semi-circles

int32

DF096 GPS Cis See Note 1 2-29 rad int16

DF097 GPS i0 See Note 1 2-31 semi-circles int32

DF098 GPS Crc See Note 1 2-5 m int16

DF099 GPS (Argument of Perigee)

See Note 1 2-31 semi-circles

int32


RT

CM

10403.2

55



Data Field Notes

DF100

GPS OMEGADOT (Rate of Right Ascension)

See Note 1 2-43 semi-circles/sec int24

DF101 GPS tGD See Note 1 2-31 sec int8

DF102 GPS SV HEALTH See GPS SPS Signal Spec, 2.4.5.3

1 uint6

MSB: 0 - all NAV data are OK; 1 - some or all NAV data are bad. See GPS SPS Signal Spec, 2.4.3.3.

DF103 GPS L2 P data flag Subframe 1, Word 4, Bit 1

1 bit(1) 0 - L2 P-Code NAV data ON 1 - L2 P-Code NAV data OFF

DF104 GLONASS almanac health

bit(1) Cn word

DF105

GLONASS almanac health availability indicator

bit(1)

0 - GLONASS almanac health is not available;

1 - GLONASS almanac health is available;

DF106 GLONASS P1 bit(2) GLONASS P1 word

DF107 GLONASS tk

bits 11-7: 0-23

bits 6-1: 0-59

bit 0: 0-1

bit(12)

Time referenced to the beginning of GLONASS subframe within the current day. The integer number of hours elapsed since the beginning of current day occupies 5 MSB. The integer number of minutes occupies next six bits. The number of thirty-second intervals occupies the LSB.

DF108 GLONASS MSB of Bn word

bit(1) The ephemeris health flag.

DF109 GLONASS P2 bit(1)

DF110 GLONASS tb 1-95 15 minutes uint7 Time to which GLONASS navigation data are referenced.


RT

CM

10403.2

56



Data Field Notes

DF111 GLONASS xn(tb), first derivative

±4.3 km/s ±2-20 km/s intS24 GLONASS ECEF-X component of satellite velocity vector in PZ-90 datum

DF112 GLONASS xn(tb) ±27000 km ±2-11 km intS27 GLONASS ECEF-X component of satellite coordinates in PZ-90 datum

DF113 GLONASS xn(tb), second derivative

±6.2*10-9 km/s ±2-30 km/s2 intS5 GLONASS ECEF-X component of satellite acceleration in PZ-90 datum

DF114 GLONASS yn(tb), first derivative

±4.3 km/s ±2-20 km/s intS24 GLONASS ECEF-Y component of satellite velocity vector in PZ-90 datum

DF115 GLONASS yn(tb) ±27000 km ±2-11 km intS27 GLONASS ECEF-Y component of satellite coordinates in PZ-90 datum

DF116 GLONASS yn(tb), second derivative

±6.2*10-9 km/s ±2-30 km/s2 intS5 GLONASS ECEF-Y component of satellite acceleration in PZ-90 datum

DF117 GLONASS zn(tb), first derivative

±4.3 km/s ±2-20 km/s intS24 GLONASS ECEF-Z component of satellite velocity vector in PZ-90 datum

DF118 GLONASS zn(tb) ±27000 km ±2-11 km intS27 GLONASS ECEF-Z component of satellite coordinates in PZ-90 datum

DF119 GLONASS zn(tb), second derivative

±6.2*10-9 km/s ±2-30 km/s2 intS5 GLONASS ECEF-Z component of satellite acceleration in PZ-90 datum

DF120 GLONASS P3 bit(1)

DF121 GLONASS n(tb) ±2-30 2-40 intS11 GLONASS relative deviation of predicted satellite carrier frequency from nominal value

DF122 GLONASS-M P 0-3 bit(2)

DF123 GLONASS-M ln (third string)

bit(1) GLONASS-M ln word extracted from third string of the subframe


RT

CM

10403.2

57



Data Field Notes

DF124 GLONASS n(tb) ±2-9 seconds 2-30 intS22 GLONASS correction to the satellite time relative to GLONASS system time

DF125 GLONASS-M Δn ±13.97*10-9 seconds

2-30 intS5 GLONASS time difference between navigation RF signal transmitted in L2 sub-band and navigation RF signal transmitted in L1 sub-band

DF126 GLONASS En 0-31 days 1 day uint5 The age of GLONASS navigation data

DF127 GLONASS-M P4 bit(1)

DF128 GLONASS-M FT 0-15 uint4 GLONASS-M predicted satellite user range accuracy at time tb

DF129 GLONASS-M NT 1-1461 1 day uint11

GLONASS calendar number of day within four-year interval starting from the 1-st of January in a leap year.

Note. For GLONASS satellites this data field (if it is not equal to zero) may contain computed calendar number of day that corresponds to the parameter tb.

DF130 GLONASS-M M 0-3 bit(2)

Type of GLONASS satellite.

01 - GLONASS-M satellite type; All GLONASS-M data fields are valid.

00 – Not GLONASS-M satellite type; All GLONASS-M data fields are invalid, thus they may contain arbitrary values.

DF131 GLONASS The Availability of Additional Data

bit(1)

The rest of the parameters of GLONASS ephemeris message contain data (data fields DF132-DF136) extracted from the fifth string of the subframe. These parameters do not belong to predefined ephemeris data; nevertheless they can be useful for positioning and timing.

1 - The additional parameters are in the message.

0 - DF132-DF136 may contain arbitrary values.

DF132 GLONASS NA 1-1461 1 day uint11 GLONASS calendar number of day within the four-year period to

which c is referenced.

DF133 GLONASS c ±1 second 2-31 intS32 Difference between GLONASS system time and UTC(SU). This parameter is referenced to the beginning of day NA.


RT

CM

10403.2

58



Data Field Notes

DF134 GLONASS-M N4 1-31 4-years interval

uint5

GLONASS four-year interval number starting from 1996

DF135 GLONASS-M GPS

±1.9*10-3 seconds 2-30 intS22 Correction to GPS system time relative to GLONASS system time.

DF136 GLONASS-M ln (fifth string)

bit(1) GLONASS-M ln word extracted from fifth string of the subframe

DF137 GPS Fit Interval Subframe 2, Word 10, Bit 17

1 bit(1) 0 - curve-fit interval is 4 hours 1 - curve-fit is greater than 4 hours

DF138

Number of Characters to Follow

0-127 1 character uint7

Provides the number of fully formed Unicode characters in the message text. It is not necessarily the number of bytes in the string.

DF139 Number of UTF-8 Code Units

0-255 1 byte uint8

DF140 UTF-8 Character Code Units

utf8(n)

DF141 Reference-Station Indicator

bit(1)

0 - Real, Physical Reference Station 1 - Non-Physical or Computed Reference Station

Note: A Non-Physical or Computed Reference Station is typically calculated based on information from a network of reference stations. Different approaches have been established over years. The Non-Physical or Computed Reference Stations are sometimes trademarked and may not be compatible. Examples of these names are “Virtual Reference Stations”, “Pseudo-Reference Stations”, and “Individualized Reference Stations”.


RT

CM

10403.2

59



Data Field Notes

DF142 Single Receiver Oscillator Indicator

bit(1)

0 - All raw data observations in messages 1001-1004 and 1009-1012 may be measured at different instants. This indicator should be set to “0” unless all the conditions for “1” are clearly met.

1 - All raw data observations in messages 1001-1004 and 1009-1012 are measured at the same instant, as described in Section 3.1.4.

DF143 Source-Name Counter

0 – 31 uint5 The Source-Name Counter defines the number of characters (bytes) to follow in Source-Name

DF144 Source-Name char8(N)

Name of source coordinate-system. If available, the EPSG identification code for the CRS has to be used. Otherwise, service providers should try to introduce unknown CRS’s into the EPSG database or could use other reasonable names.

DF145 Target-Name Counter

0 – 31 uint5 The Target-Name Counter defines the number of characters (bytes) to follow in Target-Name

DF146 Target-Name char8(N)

Name of target coordinate-system. If available, the EPSG identification code for the CRS has to be used. Otherwise, service providers should try to introduce unknown CRS’s into the EPSG database or could use other reasonable names.

DF147 System Identification Number

0 – 255 uint8

A unique system identification number has to be used for all messages related to the same sets of CRS’s. This is necessary if transformation information for more than one set of CRS’s should be transferred within one data stream.


RT

CM

10403.2

60



Data Field Notes

DF148 Utilized Transformation Message Indicator

bit(10)

This data fields says which are assigned to Transformation messages for the system identification number mentioned under DF147.

0 - Message not utilized 1 - Message utilized Bit(1) - 1023 Bit(2) - 1024 Bit(3) - 1025 Bit(4) - 1026 Bit(5) - 1027 Bit(6) - 0 (reserved) Bit(7) - 0 (reserved) Bit(8) - 0 (reserved) Bit(9) - 0 (reserved) Bit(10) - 0 (reserved)

DF149 Plate Number 0 – 31 uint5

0: unknown plate 1: AFRC - Africa 2: ANTA - Antarctica 3: ARAB - Arabia 4: AUST - Australia 5: CARB - Caribbea 6: COCO - Cocos 7: EURA - Eurasia 8: INDI - India 9: NOAM - N. America 10: NAZC - Nazca 11: PCFC - Pacific 12: SOAM - S. America 13: JUFU - Juan de Fuca 14: PHIL - Philippine 15: RIVR - Rivera 16: SCOT - Scotia 17 to 31: Reserved


RT

CM

10403.2

61



Data Field Notes

DF150 Computation Indicator

0 – 15 uint4

Transformation method to be used:

0 - standard seven parameter, approximation 1 - standard seven parameter, strict formula 2 - Molodenski, abridged 3 - Molodenski-Badekas 4 to 15: Reserved

DF151 Height Indicator 0 – 3 uint2

0 - Geometric heights result

1 - Physical heights result

If physical heights are derived via Helmert/Molodenski transformation:

H = hTarget - (Mean ∆H + ∆H (Grid interpolation))

2 = Physical heights result

Height definition is in Source System for instance if a geoid model is involved:

H = hSource - (Mean ∆H + ∆H (Grid interpolation))

3= Reserved

DF152 ΦV ± 324000 [] 2 [] int19

Area of validity (Ref.: Figure 3.5-3) of the Helmert/Molodenski transformation:

Latitude of Origin in Degrees

Coordinates defined in Source-System

DF153 ΛV ± 648000 [] 2 [] int20


Longitude of Origin in Degrees

Coordinates defined in Source-System

DF154 ∆ΦV 0 – 32766 [] 2 [] uint14


Area Extension to North and to South in Degrees

Delta Coordinates defined in Source-System

0 - undefined


RT

CM

10403.2

62



Data Field Notes

DF155 ∆ΛV 0 – 32766 [] 2 [] uint14


Area Extension to East and to West in Degrees

Delta Coordinates defined in Source-System

0 - undefined

DF156 dX ± 4194.303 m 0.001 m int23

Translation in X

(dX, dY, dZ) : Translation vector, to be added to the point's position vector in the source coordinate reference system in order to transform from source coordinate reference system to target coordinate reference system; also: the coordinates of the origin of source coordinate reference system in the target frame.

DF157 dY ± 4194.303 m 0.001 m int23 Translation in Y

DF158 dZ ± 4194.303 m 0.001 m int23 Translation in Z

DF159 R1 ± 42,949.67294 [] 0.00002 [] int32

Rotation around the X-axis in arc seconds

(RX, RY, RZ): Rotations to be applied to the coordinate reference frame. The sign convention is such that a positive rotation of the frame about an axis is defined as a clockwise rotation of the coordinate reference frame when viewed from the origin of the Cartesian coordinate reference system in the positive direction of that axis, that is a positive rotation about the Z-axis only from source coordinate reference system to target coordinate reference system will result in a smaller longitude value for the point in the target coordinate reference system.

DF160 R2 ± 42,949.67294 [] 0.00002 [] int32 Rotation around the Y-axis in arc seconds

DF161 R3 ± 42,949.67294 [] 0.00002 [] int32 Rotation around the Z-axis in arc seconds

DF162 dS ± 167.77215 PPM 0.00001 PPM int25 dS is the scale correction expressed in parts per million (PPM).


RT

CM

10403.2

63



Data Field Notes

DF163 XP ± 17,179,869.184 m

0.001 m int35

X Coordinate for Molodenski-Badekas rotation point

( PX , PY , PZ ): Coordinates of the point about which the coordinate

reference frame is rotated, given in the source Cartesian coordinate reference system.

Must always be the same within the area of a service provider

DF164 YP ± 17,179,869.184 m 0.001 m int35

Y Coordinate for Molodenski-Badekas rotation point


DF165 ZP ± 17,179,869.184 m 0.001 m int35

Z Coordinate for Molodenski-Badekas rotation point


DF166 add aS 0 – 16,777.215 0.001 m uint24

Semi-major axis of source system ellipsoid

aS = 6370000 + add aS

0 - undefined

If add aS , add bS , add aT or add bT is 0 (undefined) then only the 7 parameter transformation could be performed. The conversion to ellipsoidal coordinates, the projection and the local transformation (Helmert) have to be omitted.

DF167 add bS 0 – 33,554.431 0.001 m uint25 Semi-minor axis of source system ellipsoid

bS = 6350000 + add bS

0 - undefined (see add aS)

DF168 add aT 0 – 16,777.215 0.001 m uint24 Semi-major axis of target system ellipsoid

aT = 6370000 + add aT


DF169 add bT 0 – 33,554.431 0.001 m uint25 Semi-minor axis of target system ellipsoid

bT = 6350000 + add bT


DF170 Projection Type

0 – 63 uint6

Projection type

0 - unknown projection type


RT

CM

10403.2

64



Data Field Notes

1 - TM - Transverse Mercator (OGP 1.4.5.1, EPSG dataset coordinate operation method code

9807) 2 - TMS - Transverse Mercator (South Orientated) (OGP 1.4.5.3, EPSG dataset coordinate operation method code

9808) 3 - LCC1SP - Lambert Conic Conformal (1SP) (OGP 1.4.1.2, EPSG dataset coordinate operation method code

9801) 4 - LCC2SP - Lambert Conic Conformal (2SP) (OGP 1.4.1.1, EPSG dataset coordinate operation method code

9802) 5 - LCCW - Lambert Conic Conformal (West Orientated) (OGP 1.4.1.3, EPSG dataset coordinate operation method code

9826) 6 - CS - Cassini-Soldner (OGP 1.4.4, EPSG dataset coordinate operation method code

9806) 7 - OM - Oblique Mercator (OGP 1.4.6, EPSG dataset coordinate operation method code

9815) 8 - OS - Oblique Stereographic (OGP 1.4.7.1, EPSG dataset coordinate operation method code

9809) 9 - MC - Mercator (OGP 1.4.3, EPSG dataset coordinate operation method code

9804 or 9805) 10 - PS - Polar Stereographic (OGP 1.4.7.2, EPSG dataset coordinate operation method code

9810) 11 - DS - Double Stereographic

12 to 63 - Reserved

If the Projection type is 0 (unknown) then only the 7 parameter transformation and the interpolations for φi, λi hi (1023) could be performed. The Projection and interpolations for Ni, Ei hi (1024) have to be omitted.


RT

CM

10403.2

65



Data Field Notes

DF171 LaNO ± 90.0000 [°] 0.000000011 [°]

int34 Latitude of natural origin

(TM, TMS, LCC1SP, LCCW, CS, OS, PS, DS)

DF172 LoNO ± 180.0000 [°] 0.000000011 [°]

int35 Longitude of natural origin

(TM, TMS, LCC1SP, LCCW, CS, OS, MC, PS, DS)

DF173 add SNO 0 – 10737.41823 PPM

0.00001 PPM uint30 Scale factor at natural origin

(TM, TMS, LCC1SP, LCCW, OS, PS, DS)

SNO = 993000 + add SNO [PPM]

DF174 FE 0 – 68,719,476.735 m

0.001 m uint36 False Easting

(TM, TMS, LCC1SP, LCCW, CS, OS, MC, PS, DS)

(Contains zone term if exists)

DF175 FN ± 17,179,869.183 m

0.001 m int35 False Northing (TM, TMS, LCC1SP, LCCW, CS, OS, MC, PS, DS)

DF176 LaFO ± 90.0000 [°] 0.000000011 [°]

int34 Latitude of false origin (LCC2SP)

DF177 LoFO ± 180.0000 [°] 0.000000011 [°]

int35 Longitude of false origin (LCC2SP)

DF178 LaSP1 ± 90.0000 [°] 0.000000011 [°]

int34 Latitude of 1st standard parallel (LCC2SP)

DF179 LaSP2 ± 90.0000 [°] 0.000000011 [°]

int34 Latitude of 2nd standard parallel (LCC2SP)

DF180 EFO 0 – 68,719,476.735 m

0.001 m uint36 Easting of false origin (LCC2SP)

DF181 NFO ± 17,179,869.183 m

0.001 m int35 Northing of false origin (LCC2SP)



RT

CM

10403.2

66



Data Field Notes

DF182 Rectification Flag 0 – 1 bit(1) 0 - Not rectified (OM)

1 - Rectified Oblique Mercator projection

DF183 LaPC ± 90.0000 [°] 0.000000011 [°]

int34 Latitude of projection centre (OM)

DF184 LoPC ± 180.0000 [°] 0.000000011 [°]

int35 Longitude of projection centre (OM)

DF185 AzIL 0 – 360 [°] 0.000000011 [°]

uint35 Azimuth of initial line (OM)

DF186 Diff ARSG ± 0.369098741 [°] 0.000000011 [°]

int26 Difference from azimuth of initial line to angle from rectified to skew grid

ARSG = AzIL + Diff ARSG (OM)

DF187 Add SIL 0 – 10,737.41823 PPM

0.00001 PPM uint30 Scale factor on initial line (OM)

SIL = 993000 + add SIL [PPM]

DF188 EPC 0 – 68,719,476.735 m

0.001 m uint36 Easting at projection centre (OM)


DF189 NPC ± 17,179,869.183 m

0.001 m int35 Northing at projection centre (OM)

DF190 Horizontal Shift Indicator

0-1 bit(1) 0 - no horizontal shift

1 - apply horizontal shift

DF191 Vertical Shift Indicator

0-1 bit(1) 0 - no vertical shift

1 - apply vertical shift

DF192 Φ0 ± 324000 [ ] 0.5 [ ] int21

Latitude of Origin of the grids in Degrees (See Figure 3.5-4)

Coordinates defined in Target-System. In this context “Target system” means directly after utilizing Helmert or Molodenski transformation (1021 or 1022).


RT

CM

10403.2

67



Data Field Notes

DF193 Λ0 ± 648000 [ ] 0.5 [ ] int22

Longitude of Origin of the grids in Degrees (See Figure 3.5-4)

Coordinates defined in Target-System. In this context [“]Target system” means directly after utilizing Helmert or Molodenski transformation (1021 or 1022).

DF194 ∆φ 0 – 2047.5 [ ] 0.5 [ ] uint12

Grid area extension North to South in Degrees (See Figure 3.5-4)

Delta Coordinates defined in Target-System. In this context “Target system” means directly after utilizing Helmert or Molodenski transformation (1021 or 1022).

0 - undefined

DF195 ∆λ 0 – 2047.5 [ ] 0.5 [ ] uint12

Grid area extension East to West in Degrees (See Figure 3.5-4)

Delta Coordinates defined in Target-System. In this context [“]Target system” means directly after utilizing Helmert or Molodenski transformation (1021 or 1022).

0 - undefined

DF196 Mean ∆φ ± 0.127 [] 0.001 [] int8 Mean offset for all 16 grid points.

DF197 Mean ∆λ ± 0.127 [] 0.001 [] int8 Mean offset for all 16 grid points.

DF198 Mean ∆H ± 163.84 m 0.01 m int15

Mean height offset for all 16 grid points to cover all possible geoid heights.

If “Height Indicator” = 2

- defined in Source CRS

else

- defined in Target CRS

DF199 φi ± 0.00765 [] 0.00003 [] int9 Residual in latitude for point i (See Figure 3.5-4)

- only for small areas


DF200 λi ± 0.00765 [] 0.00003 [] int9 Residual in longitude for point i (See Figure 3.5-4)




RT

CM

10403.2

68



Data Field Notes

DF201 hi ± 0.255 m 0.001 m int9

Residual in height for point i (See Figure 3.5-4)




else


DF202 N0 ± 167,772,150 m 10 m int25 Northing of Origin of the grids in meters (See Figure 3.5-4)

Coordinates defined in local system after projection

DF203 E0 0 – 671,088,630 m 10 m uint26 Easting of Origin of the grids in meters (See Figure 3.5-4)

Coordinates defined in local system after projection

DF204 ∆N 0 – 40,950 m 10 m uint12 Grid area extension North to South in meters (See Figure 3.5-4)

Delta Coordinates defined in local system after projection

0 - undefined

DF205 ∆E 0 – 40,950 m 10 m uint12 Grid area extension East to West in meters (See Figure 3.5-4)

Delta Coordinates defined in local system after projection

0 - undefined

DF206 Mean ∆N ± 5.11 m 0.01 m int10 Mean local Northing offset for all 16 grid points.

DF207 Mean ∆E ± 5.11 m 0.01 m int10 Mean local Easting offset for all 16 grid points.

DF208 Mean ∆h ± 163.84 m 0.01 m int15

Mean local height offset for all 16 grid points to cover all possible geoid heights.



else

defined in local system after projection

DF209 Ni ± 0.255 m 0.001 m int9 Residual in local Northing for point i (See Figure 3.5-4)



RT

CM

10403.2

69



Data Field Notes

DF210 Ei ± 0.255 m 0.001 m int9 Residual in local Easting for point i (See Figure 3.5-4)


DF211 hi ± 0.255 m 0.001 m int9 Residual in height for point i (See Figure 3.5-4)


DF212 Horizontal Interpolation Method Indicator

0-3 uint2

Defining horizontal interpolation method to be used (Figures 3.5-5 through 3.5-7)

0 - Bi-linear 1 - Bi-quadratic 2 - Bi-spline 3 - Reserved

DF213 Vertical Interpolation Method Indicator

0-3 uint2

Defining vertical interpolation method to be used (Figures 3.5-5 through 3.5-7)

0 - Bi-linear 1 - Bi-quadratic 2 - Bi-spline 3 - Reserved

DF214 Horizontal Helmert/Molodenski Quality Indicator

0 – 7 uint3

Maximum approximation error after application of Helmert/Molodenski transformation within the ‘area of validity’. The quality could be further improved by application of information in the residual message (grid residuals).

0 - Unknown quality 1 - Quality better 21 Millimeters 2 - Quality 21 to 50 Millimeters 3 - Quality 51 to 200 Millimeters 4 - Quality 201 to 500 Millimeters 5 - Quality 501 to 2000 Millimeters 6 - Quality 2001 to 5000 Millimeters 7 - Quality worse than 5001 Millimeters


RT

CM

10403.2

70



Data Field Notes

DF215 Vertical Helmert/Molodenski Quality Indicator

0 – 7 uint3

Maximum approximation error after application of Helmert/Molodenski transformation within the ‘area of validity’. The quality could be further improved by application of information in the residual message (grid residuals).

0 - Unknown quality 1 - Quality better 21 Millimeters 2 - Quality 21 to 50 Millimeters 3 - Quality 51 to 200 Millimeters 4 - Quality 201 to 500 Millimeters 5 - Quality 501 to 2000 Millimeters 6 - Quality 2001 to 5000 Millimeters 7 - Quality worse than 5001 Millimeters

DF216 Horizontal Grid Quality Indicator

0 – 7 uint3

Maximum horizontal case within the given area after applying the grid residuals. Replaces the Helmert/Molodenski Quality

0 - Unknown quality 1 - Quality 0 to 10 Millimeters 2 - Quality 11 to 20 Millimeters 3 - Quality 21 to 50 Millimeters 4 - Quality 51 to 100 Millimeters 5 - Quality 101 to 200 Millimeters 6 - Quality 201 to 500 Millimeters 7 - Quality worse than 501 Millimeters

DF217 Vertical Grid Quality Indicator

0 – 7 uint3

Maximum vertical case within the given area after applying the grid residuals. Replaces the Helmert/Molodenski Quality

0 - Unknown quality 1 - Quality 0 to 10 Millimeters 2 - Quality 11 to 20 Millimeters 3 - Quality 21 to 50 Millimeters 4 - Quality 51 to 100 Millimeters 5 - Quality 101 to 200 Millimeters 6 - Quality 201 to 500 Millimeters 7 - Quality worse than 501 Millimeters


RT

CM

10403.2

71



Data Field Notes

DF218 ocs 0 - 127 mm 0.5 mm uint8 Constant term of standard deviation (1 sigma) for non-dispersive interpolation residuals

DF219 ods 0 - 5.11 ppm 0.01 ppm uint9 Distance dependent term of standard deviation(1 sigma) for non-dispersive interpolation residuals

DF220 ohs 0 - 5.11 ppm 0.1 ppm uint6

Height dependent term of standard deviation (1 sigma) for non-dispersive interpolation residuals.

The complete standard deviation for the expected non-dispersive interpolation residual is computed from DF218,DF219 and DF220 using the formula:

2Re

20

2Re

20

200 fhfdc dhsdsss

[mm]

where fdRe is the distance of the rover from the nearest physical

reference station in [km] and fdhRe is the absolute value of the height difference between nearest physical reference station and rover in [km].

DF221 Ics 0 - 511 mm 0.5 mm uint10 Constant term of standard deviation (1 sigma) for dispersive interpolation residuals (as affecting GPS L1 frequency)


RT

CM

10403.2

72



Data Field Notes

DF222 Ids 0 - 10.23 ppm 0.01 ppm uint10

Distance dependent term of standard deviation (1 sigma) for dispersive interpolation residuals. (as affecting GPS L1 frequency)

The complete standard deviation for the expected dispersive interpolation residual is computed from DF221 and DF222 using the formula:

2Re

22)L1( fIdIcI dsss [mm]

where fdRe is the distance of the rover from the nearest physical reference station in [km].

The standard deviation for the GPS L2 frequency is calculated using the formula:

21

22)1()2( LsLs II

[mm]

DF223 N-Refs 0 - 127 uint7

Number of reference stations used to derive residual statistics (1 to 127, use 127 for 127 or more stations). The number of reference stations should never be zero. If zero is encountered the rover should ignore the message.

DF224 GPS Residuals Epoch Time (TOW)

0 – 604800 s 1 s uint20

DF225 GLONASS Residuals Epoch Time (tk)

0 – 86400 s 1 s uint17


RT

CM

10403.2

73



Data Field Notes

DF226 Physical Reference Station ID

0 – 4095 uint12

The Physical Reference Station ID specifies the station ID of a real reference station, when the data stream itself is based on a non-physical reference station.

Consequently, for the Physical Reference Station ID the same notes apply as for DF003.

DF227 Receiver Type Descriptor Counter

0-31 uint8 Number of characters in the name of the receiver type

DF228 Receiver Type Descriptor

char8 (n)

DF229 Receiver Firmware Version Counter

0-31 uint8 Number of characters in the name of the receiver firmware

DF230 Receiver Firmware Version

char8 (n)

DF231 Receiver Serial Number Counter

0-31 uint8 Number of characters in the name of the receiver serial number

DF232 Receiver Serial Number

char8 (n)

DF233 GLONASS NW Epoch Time

0 – 86,400.9 sec 0.1 sec uint20 Epoch time of observations used to derive correction differences

DF234 Number of GLONASS Data Entries

0 – 15 uint4

The number of data entries (total number of satellites for which given data blocks are available).


RT

CM

10403.2

74



Data Field Notes

DF235 GLONASS Ambiguity Status Flag

0 – 3 bit(2)

0 - Reserved for future use (artificial observations) 1 - Correct Integer Ambiguity Level for L1 and L2 2 - Correct Integer Ambiguity Level for L1-L2 widelane 3 - Uncertain Integer Ambiguity Level. Only a likely guess is used.

(See the description of Correct Integer Ambiguity Level and Ambiguity Status Flag in Sections 3.5.6 and 3.5.13)

DF236 GLONASS Non Sync Count

0 – 7 uint3

Whenever an unrecoverable cycle slip occurs this count must be increased. The counter shall not be increased more than once per minute. (See the discussion of cycle slips and ambiguity levels in Section 3.5.6 and 3.5.13)

DF237

GLONASS Ionospheric Carrier Phase Correction Difference

±32.767 m

0.5 mm int17

The GLONASS Ionospheric Carrier Phase Correction Difference (ICPCDR) is the correction difference for ionospheric part calculated from integer leveled L1 and L2 correction differences (L1CDR and L2CDR).

2 22 2

2 2 2 22 1 2 1

1 2f f

ICPCDR L CDR L CDRf f f f

L1CDR, L2CDR, and ICPCDR are presented in meters. The terms 1f

and 2f represent the GLONASS L1 and L2 carrier frequencies

respectively. Note that the coefficient 2

22 2

2 1

f

f f is constant for all

GLONASS frequency channel numbers.

In extreme conditions the value of this field may lie outside the specified range. If this happens, the data block for the specific satellite containing this field (Tables 3.5-64 & 3.5-66) shall not be transmitted.

(See discussion of L1 and L2 corrections in Section 3.5.13).


RT

CM

10403.2

75



Data Field Notes

DF238

GLONASS Geometric Carrier Phase Correction Difference

±32.767 m

0.5 mm int17

The GLONASS Geometric Carrier Phase Correction Difference (GCPCDR) is the correction difference for geometric part calculated from integer leveled L1 and L2 correction differences (L1CDR and L2CDR).

2 21 2

2 2 2 21 2 1 2

1 2f f

GCPCDR L CDR L CDRf f f f

L1CDR, L2CDR, and GCPCDR are presented in meters. The terms 1f

and 2f represent the GLONASS L1 and L2 carrier frequencies

respectively. Note that the coefficients 2

12 2

1 2

f

f f and

22

2 21 2

f

f f are

constant for all GLONASS frequency channel numbers.

(See discussion of L1 and L2 corrections in Section 3.5.13).

DF239 GLONASS IOD 0-255 bit(8)

Issue Of Data (IOD) of GLONASS broadcast ephemeris.

Bits 0-5 are the 6 LSB’s of the tb field in the current ephemeris (see

DF110).

Bits 6-7 are set to zero in this version. If these bits are not equal to zero, the given satellite should be excluded from positioning.

DF240 GPS FKP Epoch Time

0 – 604799 s 1 s uint20 Seconds since the beginning of the GPS week.

DF241 GLONASS FKP Epoch Time

0 – 86400 s 1 s uint17 Seconds since beginning of GLONASS day.

DF242 N0: Geometric Gradient in North (ppm)

±20.47 ppm 0.01 ppm int12

Gradient (FKP) of the geometric (non-dispersive) error components in South-North direction in parts per million of the south-north distance to the reference station.

800h - Invalid.


RT

CM

10403.2

76



Data Field Notes

DF243 E0: Geometric gradient in east (ppm)

±20.47 ppm 0.01 ppm int12

Gradient (FKP) of the geometric (non-dispersive) error components in West-East direction in parts per million of the west-east distance to the reference station.

Note: A bit pattern equivalent to 800h in this field indicates the Geometric Gradient in East is invalid.

DF244 NI: Ionospheric gradient in north (ppm)

±81.91 ppm 0.01 ppm int14

Gradient (FKP) of the ionospheric (dispersive) error component in South-North direction.

Note: A bit pattern equivalent to 2000h in this field indicates the Ionospheric Gradient in North is invalid.

DF245 EI: Ionospheric gradient in east (ppm)

±81.91 ppm 0.01 ppm int14

Gradient (FKP) of the ionospheric (dispersive) error component in West-East direction.

Note: A bit pattern equivalent to 2000h in this field indicates the Ionospheric Gradient in East is invalid.

DF246-DF363

RESERVED


RT

CM

10403.2

77



Data Field Notes

DF364 Quarter Cycle Indicator

bit(2)

The Quarter Cycle Indicator denotes whether different carrier phase signals tracked on the same frequency have a common phase, i.e. whether or not the fractional PhaseRanges of two signals on the same frequency show a quarter cycle difference (see also section 3.1.7 for further explanation).The definition of the indicator relates exclusively to the correction status of the quarter cycle, and applies to Messages Types 1001, 1002, 1003, 1004, 1009, 1010, 1011, 1012 . Other possible corrections cannot be indicated by this indicator.

00 - Correction status unspecified 01 - PhaseRanges in Message Types 1001, 1002, 1003, 1004, 1009,

1010, 1011, 1012 are corrected in such a way that whenever PhaseRanges for different signals on the same frequency are present in these messages, they are guaranteed to be in phase and thus shall show no Quarter-Cycle bias between them (see Table 3.1-5 for details on the adjustments made). Double differences of PhaseRanges tracked with different signals shall show no Quarter- Cycle differences.

10 - Phase observations are not corrected. Double differences may show Quarter-Cycle differences for PhaseRanges based on different signals on the same frequency. Processing will require appropriate corrections.

11 – Reserved

DF365 Delta Radial ±209.7151 m 0.1 mm int22

Radial orbit correction for broadcast ephemeris. The reference time t0 is Epoch Time (DF385, DF386) plus ½ SSR Update Interval. The reference time t0 for SSR Update Interval “0” is Epoch Time.

DF366 Delta Along-Track ±209.7148 m 0.4 mm int20 Along-Track orbit correction for broadcast ephemeris. See note on reference time t0 of DF365.

DF367 Delta Cross-Track ±209.7148 m 0.4 mm int20 Cross-Track orbit correction for broadcast ephemeris. See note on reference time t0 of DF365.


RT

CM

10403.2

78



Data Field Notes

DF368 Dot Delta Radial ±1.048575 m/s 0.001 mm/s int21 Velocity of Radial orbit correction for broadcast ephemeris. See note on reference time t0 of DF365.

DF369 Dot Delta Along-Track

±1.048572 m/s 0.004 mm/s int19 Velocity of Along-Track orbit correction for broadcast ephemeris. See note on reference time t0 of DF365.

DF370 Dot Delta Cross-Track

±1.048572 m/s 0.004 mm/s int19 Velocity of Cross-Track orbit correction for broadcast ephemeris. See note on reference time t0 of DF365.

DF371 RESERVED for Dot Dot Delta Radial

±1.34217726 m/s20.00002 mm/s2

int27 Acceleration of Radial orbit correction for broadcast ephemeris. See note on reference time t0 of DF365.

DF372 RESERVED for Dot Dot Delta Along-Track

±1.3421772 m/s2 0.00008 mm/s2

int25 Acceleration of Along-Track orbit correction for broadcast ephemeris. See note on reference time t0 of DF365.

DF373 RESERVED for Dot Dot Delta Cross-Track

±1.3421772 m/s2 0.00008 mm/s2

int25 Acceleration of Cross-Track orbit correction for broadcast ephemeris. See note on reference time t0 of DF365.

DF374 Satellite Reference Point

0-1 N/A bit(1)

Orbit corrections refer to Satellite Reference Point:

0 - Satellite Reference Point (SRP) currently L1/L2 phase center of the ionospheric free signal

1 - Reserved for future extension to Center Of Mass (COM) representation

DF375 Satellite Reference Datum

0-1 N/A bit(1) Orbit corrections refer to Satellite Reference Datum:

0 - ITRF 1 -Regional

DF376 Delta Clock C0 ±209.7151 m 0.1 mm int22

C0 polynomial coefficient for correction of broadcast satellite clock. The reference time t0 is Epoch Time (DF385, DF386) plus ½ SSR Update Interval. The reference time t0 for SSR Update Interval “0” is Epoch Time.


RT

CM

10403.2

79



Data Field Notes

DF377 Delta Clock C1 ±1.048575 m/s 0.001 mm/s int21 C1 polynomial coefficient for correction of broadcast satellite clock. See note on reference time t0 of DF376.

DF378 Delta Clock C2 ±1.34217726 m/s20.00002 mm/s2

int27 C2 polynomial coefficient for correction of broadcast satellite clock. See note on reference time t0 of DF376.

DF379 No. of Code Biases Processed

0-31 1 uint5 Number of Code Biases for one individual satellite

DF380 GPS Signal and Tracking Mode Identifier

0-31 1 uint5

Indicator to specify the GPS signal and tracking mode:

0 - L1 C/A 1- L1 P 2- L1 Z-tracking and similar (AS on) 3 - Reserved 4 - Reserved 5 - L2 C/A 6 - L2 L1(C/A)+(P2-P1) (semi-codeless) 7 - L2 L2C (M) 8 - L2 L2C (L) 9 - L2 L2C (M+L) 10 - L2 P 11 - L2 Z-tracking and similar (AS on) 12 - Reserved 13 - Reserved 14 - L5 I 15 - L5 Q >15 - Reserved.

DF381 GLONASS Signal and Tracking Mode Identifier

0-31 1 uint5

Indicator to specify the GLONASS signal and tracking mode:

0 - G1 C/A 1 - G1 P 2 - G2 C/A (GLONASS M) 3 - G2 P >3 -Reserved


RT

CM

10403.2

80



Data Field Notes

DF382

RESERVED for Galileo Signal and Tracking Mode Identifier

0-31 1 uint5

Indicator to specify the Galileo signal and tracking mode:

0 - E1 A PRS 1 - E1 B I/NAV OS/CS/SoL 2 - E1 C no data 3 - Reserved 4 - Reserved 5 - E5a I F/NAV OS 6 - E5a Q no data 7 - Reserved 8 - E5b I I/NAV OS/CS/SoL 9 - E5b Q no data 10 - Reserved 11 - E5 I 12 - E5 Q 13 - Reserved 14 - E6 A PRS 15 - E6 B C/NAV CS 16 - E6 C no data >16 - Reserved.

DF383 Code Bias ±81.91 m 0.01 m int14 Code Bias for specified Signal

DF384 GLONASS Satellite ID

1 – 24 1 uint5 GLONASS Satellite ID’s only

DF385 GPS Epoch Time 1s 0 – 604799 s 1 s uint20 Full seconds since the beginning of the GPS week

DF386 GLONASS Epoch Time 1s

0 – 86400 s 1 s uint17 Full seconds since the beginning of GLONASS day

DF387 No. of Satellites 0 – 63 1 uint6 Number of satellites

DF388 Multiple Message Indicator

0 – 1 1 bit(1)

Indicator for transmitting messages with the same Message Number and Epoch Time:

0 - last message of a sequence

1 - multiple message transmitted


RT

CM

10403.2

81



Data Field Notes

DF389 SSR URA bits 5 – 3: 0 – 7 bits 2 – 0: 0 – 7

bit(6)

SSR User Range Accuracy (URA) (1 sigma) for a range correction computed from complete SSR set as disseminated by RTCM SSR messages. The URA is represented by a combination of URA_CLASS and URA_VALUE. The 3 MSB define the URA_CLASS with a range of 0-7 and the 3 LSB define the URA_VALUE with a range of 0-7.

The URA is computed by:

URA mm 3 _ 1 _ 1 mm

Special cases are:

000 000 - URA undefined/unknown, SSR corrections for the corresponding satellite may not be reliable

111 111 - URA > 5466.5 mm

DF390 High Rate Clock Correction

±209.7151 m 0.1 mm int22 High Rate Clock correction to be added to the polynomial clock correction (see DF376, DF377, DF378)


RT

CM

10403.2

82



Data Field Notes

DF391 SSR Update Interval 0-15 1 bit(4)

SSR Update Interval. The SSR Update Intervals for all SSR parameters start at time 00:00:00 of the GPS time scale. A change of the SSR Update Interval during the transmission of a SSR data stream should ensure consistent data for a rover. The supported SSR Update Intervals are:

0 - 1 s 1 - 2 s 2 - 5 s 3 - 10 s 4 - 15 s 5 - 30 s 6 - 60 s 7 - 120 s 8 - 240 s 9 - 300 s 10 - 600 s 11 - 900 s 12 - 1800 s 13 - 3600 s 14 - 7200 s 15 - 10800 s

Note that the update intervals are aligned to the GPS time scale for all GNSS in order to allow synchronous operation for multiple GNSS services. This means that the update intervals may not be aligned to the beginning of the day for another GNSS. Due to the leap seconds this is generally the case for GLONASS.

DF392 GLONASS Issue Of Data (IOD) 0-255 bit(8)

Issue Of Data of GLONASS broadcast ephemeris

If bit 7 is 0 (bit 7 is MSB):

Bits 0-6 represent the 7 bits of the GLONASS tb field in the current ephemeris (see DF110)

If bit 7 is 1:

Reserved for future use. Data should not be used. This can be the case for pre-GLONASS-M satellite if ephemeris changed within tb interval.


RT

CM

10403.2

83



Data Field Notes

DF393 MSM Multiple message bit

bit(1)

1 indicates that more MSMs follow for given physical time and reference station ID

0 indicates that it is the last MSM for given physical time and reference station ID

DF394 GNSS Satellite mask

bit(64)

The sequence of bits, which specifies those GNSS satellites for which there is available data in this message. The Most Significant Bit (msb), or the first encoded bit corresponds to GNSS satellite with ID=1, the second bit corresponds to GNSS satellite with ID=2, etc. And the Least Significant Bit (lsb), or the last encoded bit corresponds to GNSS satellite with ID=64.

Exact mapping of actual GNSS satellites (PRNs for GPS, “slot numbers” for GLONASS, etc.) to satellite mask IDs is specific for each GNSS (see corresponding tables in MSM description for each GNSS).

Some ID values may refer to specific satellites, while some ID values may be indicated as “Reserved” in this standard. These IDs may be used in the future for other satellites and thus decoding software shall ensure that it does not skip these bits, but decodes complete GNSS Satellite mask, decodes corresponding observables as if they refer to known satellites, but should refrain from using them, unless new satellite mapping table becomes available to map corresponding ID to a specific satellite.

If any data for satellite with ID=n follows, then the corresponding bit (bit number n) is set to 1. If data for satellite with ID=m does not follow, then corresponding bit (bit number m) is set to 0.


RT

CM

10403.2

84



Data Field Notes

DF395 GNSS Signal mask bit(32)

The sequence of bits, which specifies those GNSS signals, for which there is available data in this message. Each bit corresponds to a particular signal (observable) type for a given GNSS. The Most Significant Bit (msb), or the first encoded bit corresponds to a signal with ID=1, the second bit corresponds to a signal with ID=2, etc. And Least Significant Bit (lsb), or the last encoded bit corresponds to signal with ID=32.

Exact mapping of actual signal identifier (in correspondence with RINEX 3.01 signal naming convention) to signal mask IDs is specific for each GNSS (see corresponding tables in MSM description for each GNSS).

Some ID values may refer to specific signals, while some ID values may be indicated as “Reserved” in this standard. These IDs may be used in the future for other signals and thus decoding software shall ensure, that it does not skip these bits, but decodes complete GNSS Signal mask, decodes corresponding observables as if they refer to known signals, but should refrain from using them, unless new signal mapping table becomes available to map corresponding ID to a specific signal.

If a signal (observable) with ID=n is available for at least one transmitted satellite, then the corresponding bit (number n) is set to 1, otherwise the corresponding bit is set to 0.


RT

CM

10403.2

85



Data Field Notes

DF396 GNSS Cell mask bit(X)

A two-dimensional table, which determines signal availability for each transmitted satellite.

This field is of variable size: X=Nsig*Nsat, where Nsat is the number of satellites (the number of those bits set to 1 in Satellite Mask, DF394) and Nsig is the number of available signals (the number of those bits set to 1 in Signal Mask, DF395).

The first row of this rectangular table corresponds to the signal with the smallest ID for which the corresponding bit in the Signal Mask is set to 1. The second row corresponds to the signal with the second smallest ID for which the corresponding bit in Signal Mask is set to 1. The last row corresponds to the signal with the highest ID for which the corresponding bit in the Signal Mask is set to 1.

The first column of this rectangular table corresponds to the satellite with the smallest ID for which corresponding bit in the Satellite Mask is set to 1. The second column corresponds to the satellite with the second smallest ID for which the corresponding bit in the Satellite Mask is set to 1. The last column corresponds to the satellite with the highest ID, for which the corresponding bit in the Satellite Mask is set to 1.

If observable data for a given satellite and a given signal follows then the corresponding cell in this table is set to 1, otherwise it is set to 0.

This bit table is packed by columns, starting from the column corresponding to smallest satellite ID.

The size of each column is Nsig bits, and it is packed starting from the cell corresponding to the smallest signal ID.

Each cell of the table is represented by one bit, which is set to 1 or 0, according to the value in the cell.


RT

CM

10403.2

86



Data Field Notes

DF397

The number of integer milliseconds in GNSS Satellite rough range

0–254 ms 1 ms uint8

Rough range can be used to restore complete observables for a given satellite. Rough range takes 18 bits which are split between two fields (DF397 and DF398). This field contains the integer number of milliseconds in the satellite rough range. If this field is not transmitted (MSM1, MSM2, MSM3) then it is the responsibility of decoding equipment to restore it using rough reference station position and ephemeris data.

A bit pattern equivalent to FFh (255 ms) indicates invalid value.

DF398 GNSS Satellite rough range modulo 1 millisecond

0 to (1 – 2–10) ms

2–10 ms uint10 See the note above. Allows restoring full rough range with accuracy 1/1024 ms (about 300 m).

DF399 GNSS Satellite rough Phase Range Rate

± 8191 m/s 1 m/s int14

Phase Range Rate has the same sign as the mathematical derivative of the PhaseRange.

Similar to ranges, the full Phase Range Rate observable for a particular signal can be constructed by the sum of the rough Phase Range Rate (unique for given satellite) and the fine Phase Range Rate (unique for each particular signal corresponding to given satellite).

A bit pattern equivalent to 2000h (-8192 m/s) indicates invalid value.

DF400 GNSS signal fine Pseudorange

± (2–10–2–24) ms (Approx: ±292 m)

2–24 ms (Approx: 0.018 m)

int15

Specific for each signal of given Satellite. Being added to fields DF397 and DF398 allows getting the full Pseudorange observable corresponding to given signal.

A bit pattern equivalent to 4000h (–2–10 ms) indicates invalid value.


RT

CM

10403.2

87



Data Field Notes

DF401 GNSS signal fine PhaseRange data

± (2–8–2–29) ms (Approx: ±1171 m)

2–29 ms (Approx: 0.0006 m)

int22

Similar to DF400, but refers to the PhaseRange. The proper integer number of cycles have been removed from the original full carrier to match it to the corresponding Pseudorange at the start of PhaseRange generation.

This integer number is kept constant for the epochs that follow until a cycle slip is detected, after which a new integer number of cycles must be determined. In this case the associated GNSS PhaseRange Lock Time Indicator (DF402) must be reset to zero.

Note that the PhaseRange defined here has the same sign as the Pseudoranges.

Certain ionospheric conditions (or incorrect initialization) may cause the difference between the PhaseRange and the Pseudorange (PhaseRange – Pseudorange) to diverge over time, which may cause the value to exceed the range limit defined. Under these circumstances the above mentioned “integer number of cycles” shall be reinitialized. In this case the associated GNSS PhaseRange Lock Time Indicator (DF402) shall be reset to zero.

A bit pattern equivalent to 200000 h (–2–8 m) indicates invalid value.

DF402 GNSS PhaseRange Lock Time Indicator


The Lock Time Indicator provides a measure of the amount of time during which the receiver has maintained continuous lock on that satellite signal. If a cycle slip occurs during the previous measurement cycle, the lock indicator will be reset to zero.

DF403 GNSS signal CNR 1–63 dBHz 1 dB-Hz uint6

The GNSS CNR measurement provides an estimate of the carrier-to-noise ratio of the satellite's signal in dB-Hz.

A value of “0” means that the CNR measurement is not computed, or not available.

Availability or unavailability of CNR does not affect validity of corresponding observables.

DF404 GNSS signal fine Phase Range Rate

±1.6384 m/s 0.0001 m/s int15 Fine Phase Range Rate for a given signal. Full Phase Range Rate is the sum of this field and the Satellite Rough Phase Range Rate (DF399).

A bit pattern equivalent to 4000h (–1.6384 m/s) indicates invalid value.


RT

CM

10403.2

88



Data Field Notes

DF405 GNSS signal fine Pseudorange with extended resolution

± (2–10–2–29) ms (Approx: ±292 m)

2–29 ms (Approx: 0.0006 m)

int20 Same as DF400, but with extended resolution except the bit pattern equivalent to 80000h (-2-10 ms) indicates an invalid value instead of the invalid pattern defined for DF400.

DF406

GNSS signal fine PhaseRange data with extended resolution

± (2–8–2–31) ms (Approx: ±1171 m)

2–31 ms (Approx: 0.00014 m)

int24

Same as DF401, but with extended resolution except the bit pattern equivalent to 800000h (-2-8 ms) indicates an invalid value instead of the invalid pattern defined for DF401.

DF407

GNSS PhaseRange Lock Time Indicator with extended range and resolution.

See Tables 3.4-1E and 3.4-1F

uint10 Same as DF402, but with extended range and higher resolution

DF408 GNSS signal CNR with extended resolution

0.0625–63.9375 dBHz

2–4 dB-Hz uint10

Same as DF403, but with extended resolution.

A value “0” indicates that the CNR measurement has not been computed, or is not available.

Availability or unavailability of the CNR does not affect validity of other observables.

DF409 IODS – Issue Of Data Station

0–7 1 uint3 This field is reserved to be used to link MSM with future site-description (receiver, antenna description, etc.) messages.

A value of “0” indicates that this field is not utilized.

DF410 Reserved


RT

CM

10403.2

89



Data Field Notes

DF411 Clock Steering Indicator

uint2

0 – clock steering is not applied

In this case receiver clock must be kept in the range of ± 1 ms (approximately ± 300 km)

1 – clock steering has been applied

In this case receiver clock must be kept in the range of ± 1 microsecond (approximately ± 300 meters).

2 – unknown clock steering status

3 – reserved

DF412 External Clock Indicator

uint2

0 – internal clock is used

1 – external clock is used, clock status is “locked”

2 – external clock is used, clock status is “not locked”, which may indicate external clock failure and that the transmitted data may not be reliable.

3 – unknown clock is used

DF413 IOD SSR 0 – 15 1 uint4 A change of Issue Of Data SSR is used to indicate a change in the SSR generating configuration, which may be relevant for rover operation.

DF414 SSR Provider ID 0 – 65535 1 uint16

SSR Provider ID is provided by RTCM on request to identify a SSR service. The Provider ID shall be globally unique. Providers should contact “rtcm.org”.

0 to 255 - reserved for experimental services

256 to 65535 - unique SSR Provider ID

DF415 SSR Solution ID 0 – 15 1 uint4 SSR Solution ID indicates different SSR services of one SSR provider


RT

CM

10403.2

90



Data Field Notes

DF416 GLONASS Day Of Week

0-7 1 uint3

0 – Sunday

1 – Monday

2 – Tuesday

3 – Wednesday

4 – Thursday

5 – Friday

6 – Saturday

7 – The day of week is not known

DF417 GNSS Smoothing Type Indicator

bit(1) 1 – Divergence-free smoothing is used

0 – Other type of smoothing is used

DF418 GNSS Smoothing Interval


The GNSS Smoothing Interval is the integration period over which the pseudorange code phase measurements are averaged using carrier phase information.

Divergence-free smoothing may be continuous over the entire period for which the satellite is visible.

Notice: A value of zero indicates no smoothing is used.

DF419 GLONASS Satellite Frequency Channel Number

See Table 3.4-6 1 uint(4) The GLONASS Satellite Frequency Channel Number identifies the frequency of the GLONASS satellite.

DF420 Half-cycle ambiguity indicator

bit(1)

0 – No half-cycle ambiguity.

1 – Half-cycle ambiguity

When transmitting PhaseRange with unresolved polarity encoding software shall set this bit to 1. Receiving software that is not capable of handling half-cycle ambiguities shall skip such PhaseRange observables. If polarity resolution forced PhaseRange to be corrected by half-a-cycle, then the associated GNSS PhaseRange Lock Time Indicator (DF402, DF407) must be reset to zero, indicating that despite continuous tracking the final PhaseRange experienced non-continuity.


RT

CM

10403.2

91



Data Field Notes

DF421 GLONASS Code-Phase Bias Indicator

bit(1)

0 = The GLONASS Pseudorange and PhaseRange observations in the data stream are not aligned to the same measurement epoch.

1 = The GLONASS Pseudorange and PhaseRange observations in the data stream are aligned to the same measurement epoch.

DF422 GLONASS FDMA Signals Mask bit(4)

Bitmask, where the MSB corresponds to the presence or absence of DF423, continuing to the LSB or last bit corresponding to the absence or presence of DF426. If the bit is set to zero then the corresponding field is absent from the message. If the bit is set to one then the corresponding field is present in the message.

DF423 GLONASS L1 C/A Code-Phase Bias ±655.34 m 0.02 m int16

The GLONASS L1 C/A Code-Phase Bias represents the offset between the L1 C/A Pseudorange and L1 PhaseRange measurement epochs in meters. If DF421 is set to 0, the measurement epoch of the GLONASS L1 PhaseRange measurements may be aligned using: Aligned GLONASS L1 PhaseRange = Full GLONASS L1 PhaseRange (see DF042) + GLONASS L1 C/A Code-Phase Bias. If DF421 is set to 1, the measurement epoch of the GLONASS L1 PhaseRange measurements may be unaligned using: Unaligned GLONASS L1 PhaseRange = Full GLONASS L1 PhaseRange (see DF042) GLONASS L1 C/A Code-Phase Bias. A bit pattern equivalent to 8000h (-655.36 m) in this field indicates invalid value (unknown or falling outside DF-range)


RT

CM

10403.2

92



Data Field Notes

DF424 GLONASS L1 P Code-Phase Bias ±655.34 m 0.02 m int16

The GLONASS L1 P Code-Phase Bias represents the offset between the L1 P Pseudorange and L1 PhaseRange measurement epochs in meters. If DF421 is set to 0, the measurement epoch of the GLONASS L1 PhaseRange measurements may be aligned using: Aligned GLONASS L1 PhaseRange = Full GLONASS L1 PhaseRange (see DF042) + GLONASS L1 P Code-Phase Bias. If DF421 is set to 1, the measurement epoch of the GLONASS L1 PhaseRange measurements may be unaligned using: Unaligned GLONASS L1 PhaseRange = Full GLONASS L1 PhaseRange (see DF042) GLONASS L1 P Code-Phase Bias.

A bit pattern equivalent to 8000h (-655.36 m) in this field indicates invalid value (unknown or falling outside DF-range)

DF425 GLONASS L2 C/A Code-Phase Bias ±655.34 m 0.02 m int16

The GLONASS L2 C/A Code-Phase Bias represents the offset between the L2 C/A Pseudorange and L2 PhaseRange measurement epochs in meters. If DF421 is set to 0, the measurement epoch of the GLONASS L2 PhaseRange measurements may be aligned to the Pseudorange measurements using: Aligned GLONASS L2 PhaseRange = Full GLONASS L2 PhaseRange (see DF048) + GLONASS L2 C/A Code-Phase Bias. If DF421 is set to 1, the measurement epoch of the GLONASS L2 PhaseRange measurements may be unaligned using: Unaligned GLONASS L2 PhaseRange = Full GLONASS L2 PhaseRange (see DF048) GLONASS L2 C/A Code-Phase Bias.



RT

CM

10403.2

93



Data Field Notes

DF426 GLONASS L2 P Code-Phase Bias ±655.34 m 0.02 m int16

The GLONASS L2 P Code-Phase Bias represents the offset between the L2 P Pseudorange and L2 PhaseRange measurement epochs in meters. If DF421 is set to 0, the measurement epoch of the GLONASS L2 PhaseRange measurements may be aligned to the Pseudorange measurements using: Aligned GLONASS L2 PhaseRange = Full GLONASS L2 PhaseRange (see DF048) + GLONASS L2 P Code-Phase Bias. If DF421 is set to 1, the measurement epoch of the GLONASS L2 PhaseRange measurements may be unaligned using: Unaligned GLONASS L2 PhaseRange = Full GLONASS L2 PhaseRange (see DF048) GLONASS L2 P Code-Phase Bias.


Note 1: Effective range is the maximum range attainable with the indicated bit allocation and scale factor.


RT

CM

10403.2

94

Table 3.4-2 Lock Time Indicator, Data Fields DF013, DF019, DF043, DF049 (Note 1)

Indicator (i) Minimum Lock Time (s) Range of Indicated Lock Times

0-23 i 0 < lock time < 24

24-47 242 i 24 ≤ lock time < 72

48-71 1204 i 72 ≤ lock time < 168

72-95 4088i 168 ≤ lock time < 360

96-119 117616 i 360 ≤ lock time < 744

120-126 309632 i 744 ≤ lock time < 937

127 --- lock time 937

Note 1 - Determining Loss of Lock: In normal operation, a cycle slip will be evident when the Minimum Lock Time (MLT) has decreased in value. For long time gaps between messages, such as from a radio outage, extra steps should be taken on the rover to safeguard against missed cycle slips.

Table 3.4-3 SBAS PRN Codes, Data Fields DF009, DF038

SBAS Code

GPS/GLONASSSatellite ID

SBAS Code


SBAS Code


120 40 127 47 134 54 121 41 128 48 135 55 122 42 129 49 136 56 123 43 130 50 137 57 124 44 131 51 138 58 125 45 132 52 126 46 133 53


RT

CM

10403.2

95

Table 3.4-4 Carrier Smoothing Interval of Code Phase, DF008 and DF037

Indicator Smoothing Interval

000 (0) No smoothing

001 (1) < 30 s

010 (2) 30-60 s

011 (3) 1-2 min

100 (4) 2-4 min

101 (5) 4-8 min

110 (6) >8 min

111 (7) Unlimited smoothing interval


RT

CM

10403.2

96

Table 3.4-5 GLONASS Carrier Frequencies in L1 and L2 Bands

Satellite Frequency Channel Indicator

No. of channel Nominal value of frequency in L1 Band, MHz

Nominal value of frequency in L2 Band, MHz

0 -07 1598.0625 1242.9375

1 -06 1598.6250 1243.3750

2 -05 1599.1875 1243.8125

3 -04 1599.7500 1244.2500

4 -03 1600.3125 1244.6875

5 -02 1600.8750 1245.1250

6 -01 1601.4375 1245.5625

7 00 1602.0 1246.0

8 01 1602.5625 1246.4375

9 02 1603.125 1246.875

10 03 1603.6875 1247.3125

11 04 1604.25 1247.75

12 05 1604.8125 1248.1875

13 06 1605.375 1248.625

14 07 1605.9375 1249.0625

15 08 1606.5 1249.5

16 09 1607.0625 1249.9375

17 10 1607.625 1250.375

18 11 1608.1875 1250.8125

19 12 1608.75 1251.25

20 13 1609.3125 1251.6875


RT

CM

10403.2

97

Table 3.4-6 GLONASS Satellite Frequency Channel Number (DF419)

DF value No of

channel Nominal value of frequency in

L1 Band, MHz Nominal value of frequency in

L2 Band, MHz

0 -7 1598.0625 1242.9375

1 -6 1598.6250 1243.3750

2 -5 1599.1875 1243.8125

3 -4 1599.7500 1244.2500

4 -3 1600.3125 1244.6875

5 -2 1600.8750 1245.1250

6 -1 1601.4375 1245.5625

7 0 1602.0 1246.0

8 1 1602.5625 1246.4375

9 2 1603.125 1246.875

10 3 1603.6875 1247.3125

11 4 1604.25 1247.75

12 5 1604.8125 1248.1875

13 6 1605.375 1248.625


RT

CM

10403.2

98

DF value No of

channel Nominal value of frequency in

L1 Band, MHz Nominal value of frequency in

L2 Band, MHz

14 Reserved

15 if the Frequency Channel Number is not known, not available or not applicable (e.g. CDMA-only capable Satellite)

3.5 Messages

This section describes the messages. Each message contains a specific set of data fields, sometimes repeated, as in the case where information on several satellites is provided. The data fields are broadcast in the order listed. Multi-byte values are expressed with the most significant byte transmitted first and the least significant byte transmitted last. Unlike Version 2 (RTCM 10402.x), there is no reversal of bits within a byte. 3.5.1 GPS RTK Observable Messages

Tables 3.5-1 through 3.5-5 provide the contents of the GPS real-time kinematic (RTK) messages, which are based on raw data. From these data, valid RINEX files can be obtained, although when the Pseudorange Modulus Ambiguity (DF014, DF044) is not provided, ephemeris and clock information will be required to make the conversion. As a consequence, this set of messages offers a high level of interoperability and compatibility with standard surveying practices. If GPS RTK Messages (1001-1004) are used in a Network RTK application, their content representing L1 and L2 PhaseRanges might be altered by correcting for antenna phase center variations (see also 3.1.6). However the properties of the PhaseRanges have to be indicated properly with an Antenna Description message. Note: observations corrected for antenna phase center variations are no longer compatible with RINEX standard definition.


RT

CM

10403.2

99

Table 3.5-1 Contents of the Message Header, Types 1001, 1002, 1003, 1004: GPS RTK Messages

DATA FIELD DF NUMBER

DATA TYPE

NO. OF BITS

Message Number (e.g.,“1001”= 0011 1110 1001) DF002 uint12 12

Reference Station ID DF003 uint12 12

GPS Epoch Time (TOW) DF004 uint30 30

Synchronous GNSS Flag DF005 bit(1) 1

No. of GPS Satellite Signals Processed DF006 uint5 5

GPS Divergence-free Smoothing Indicator DF007 bit(1) 1

GPS Smoothing Interval DF008 bit(3) 3

TOTAL 64

The Type 1001 Message supports single-frequency RTK operation. It does not include an indication of the satellite carrier-to-noise ratio as measured by the reference station.

Table 3.5-2 Contents of the Satellite-Specific Portion of a Type 1001 Message, Each Satellite – GPS Basic RTK, L1 Only


DATA TYPE

NO. OF BITS

GPS Satellite ID DF009 uint6 6

GPS L1 Code Indicator DF010 bit(1) 1

GPS L1 Pseudorange DF011 uint24 24

GPS L1 PhaseRange – L1 Pseudorange DF012 int20 20

GPS L1 Lock time Indicator DF013 uint7 7

TOTAL 58


RT

CM

10403.2

100

The Type 1002 Message supports single-frequency RTK operation, and includes an indication of the satellite carrier-to-noise ratio (CNR) as measured by the reference station. Since the CNR does not usually change from measurement to measurement, this message type can be mixed with the Type 1001, and used primarily when a satellite CNR changes, thus saving broadcast link throughput.

Table 3.5-3 Contents of the Satellite-Specific Portion of a Type 1002 Message, Each Satellite – GPS Extended RTK, L1 Only


DATA TYPE

NO. OF BITS







DF014 uint8 8

GPS L1 CNR DF015 uint8 8

TOTAL 74


RT

CM

10403.2

101

The Type 1003 Message supports dual-frequency RTK operation, but does not include an indication of the satellite carrier-to-noise (CNR) as measured by the reference station.

Table 3.5-4 Contents of the Satellite-Specific Portion of a Type 1003 Message, Each Satellite – GPS Basic RTK, L1 & L2


DATA TYPE

NO. OF BITS







GPS L2-L1 Pseudorange Difference DF017 int14 14



TOTAL 101


RT

CM

10403.2

102

The Type 1004 Message supports dual-frequency RTK operation, and includes an indication of the satellite carrier-to-noise (CNR) as measured by the reference station. Since the CNR does not usually change from measurement to measurement, this message type can be mixed with the Type 1003, and used only when a satellite CNR changes, thus saving broadcast link throughput.

Table 3.5-5 Contents of the Satellite-Specific Portion of a Type 1004 Message, Each Satellite – GPS Extended RTK, L1 & L2


DATA TYPE

NO. OF BITS







DF014 uint8 8



GPS L2-L1 Pseudorange Difference DF017 int14 14




TOTAL 125


RT

CM

10403.2

103

3.5.2 Stationary Antenna Reference Point Messages

Message Type 1005 (see Table 3.5-6) provides the earth-centered, earth-fixed (ECEF) coordinates of the antenna reference point (ARP) for a stationary reference station. No height above a monument is provided. Message Type 1006 (see Table 3.5-7) provides all the same information as Message Type 1005, but additionally provides the height of the ARP above a survey monument. These messages are designed for GPS operation, but are equally applicable to GLONASS and the future Galileo, and system identification bits are reserved for them. The phase center is not a point in space that can be used as a standard reference. For one thing, it varies with frequency. In addition, the location of L1 phase center is strongly dependent on the antenna calibration method used during the calibration process. Therefore, the location of the L1 phase center may vary between different calibration tables for the same antenna model. Message Types 1005 and 1006 avoid the phase center problem by utilizing the Antenna Reference Point, which is used throughout the International GNSS Service (IGS). Message Types 1005 and 1006 contain the coordinates of the installed antenna’s ARP in Earth-Center-Earth-Fixed (ECEF) coordinates -- datum definitions are not yet supported. The coordinates always refer to a physical point on the antenna, typically the bottom of the antenna mounting surface. The Quarter Cycle Indicator was introduced to avoid inconsistencies between different approaches by different receiver hardware manufacturers to handle quarter cycle shifts between carrier phase observations on the same frequency (see Section 3.1.8).


RT

CM

10403.2

104

Table 3.5-6 Contents of the Type 1005 Message – Stationary Antenna Reference Point, No Height Information


DATA TYPE

NO. OF BITS

Message Number (“1005”= 0011 1110 1101) DF002 uint12 12


Reserved for ITRF Realization Year DF021 uint6 6

GPS Indicator DF022 bit(1) 1

GLONASS Indicator DF023 bit(1) 1

Reserved for Galileo Indicator DF024 bit(1) 1

Reference-Station Indicator DF141 bit(1) 1

Antenna Reference Point ECEF-X DF025 int38 38

Single Receiver Oscillator Indicator DF142 bit(1) 1

Reserved DF001 bit(1) 1

Antenna Reference Point ECEF-Y DF026 int38 38

Quarter Cycle Indicator DF364 bit(2) 2

Antenna Reference Point ECEF-Z DF027 int38 38

TOTAL 152


RT

CM

10403.2

105

Table 3.5-7 Contents of the Type 1006 Message – Stationary Antenna Reference Point, with Height Information


DATA TYPE

NO. OF BITS

Message Number (“1006”= 0011 1110 1110) DF002 uint12 12


Reserved for ITRF Realization Year DF021 uint6 6

GPS Indicator DF022 bit(1) 1

GLONASS Indicator DF023 bit(1) 1

Reserved for Galileo Indicator DF024 bit(1) 1

Reference-Station Indicator DF141 bit(1) 1

Antenna Reference Point ECEF-X DF025 int38 38

Single Receiver Oscillator Indicator DF142 bit(1) 1

Reserved DF001 bit(1) 1

Antenna Reference Point ECEF-Y DF026 int38 38

Quarter Cycle Indicator DF364 bit(2) 2

Antenna Reference Point ECEF-Z DF027 int38 38

Antenna Height DF028 uint16 16

TOTAL 168


RT

CM

10403.2

106

3.5.3 Antenna Description Messages

Table 3.5-8 provides an ASCII descriptor of the reference station antenna. As noted for DF031 in Table 3.4-1, the International GPS Service (IGS) Central Bureau convention will be used most of the time, since it is universally accessible. Table 3.5-9 provides the same information, plus the antenna serial number, which removes any ambiguity about the model number or production run. The Committee adopted the naming convention from the IGS equipment-naming table as supplied by the International GPS Service Central Bureau (IGS CB). This table provides a unique antenna descriptor for antennas used for high-precision surveying type applications, which is utilized in the Antenna Descriptor (DF030). IGS limits the number of characters to 20 at this time, but the standard allows more characters for future extension. The Antenna Setup ID (DF031) is a parameter for use by the service provider to indicate the particular reference station-antenna combination. "0" for this value means that the values of a standard model type calibration should be used. The Antenna Serial Number (DF033) is the individual antenna serial number as issued by the manufacturer of the antenna

Table 3.5-8 Contents of the Type 1007 Message – Antenna Descriptor


DATA TYPE

NO. OF BITS

NOTES

Message Number (“1007”=0011 1110 1111) DF002 uint12 12


Descriptor Counter N DF029 uint8 8 N 31

Antenna Descriptor DF030 char8(N) 8*N

Antenna Setup ID DF031 uint8 8

TOTAL 40+8*N


RT

CM

10403.2

107

Table 3.5-9 Contents of the Type 1008 Message – Antenna Descriptor & Serial Number


DATA TYPE

NO. OF BITS

NOTES



Descriptor Counter N DF029 uint8 8

Antenna Descriptor DF030 char8(N) 8*N N 31


Serial Number Counter M DF032 uint8 8

Antenna Serial Number DF033 char8(M) 8*M M 31

TOTAL 48+ 8*(M+N)


RT

CM

10403.2

108

3.5.4 GLONASS RTK Observable Messages

Tables 3.5-10 through 3.5-14 provide the contents of the GLONASS real-time kinematic (RTK) messages, which are based on raw data. From these data, complete RINEX files can be obtained. As a consequence, this set of messages offers a high level of interoperability and compatibility with standard surveying practices. The service provider using these messages should also transmit an Antenna Reference Point message (Type 1005 or 1006) and an Antenna Descriptor message (Type 1007 or 1008). A provider of combined GPS-GLONASS service should provide completely independent sets of observables. In addition, if the time tags of the GPS and GLONASS RTK data are synchronized, the Synchronous GNSS Flag should be used to connect the entire RTK data block.

Table 3.5-10 Contents of the Message Header, Types 1009 through 1012: GLONASS RTK Messages


DATA TYPE

NO. OF BITS



GLONASS Epoch Time (tk) DF034 uint27 27

Synchronous GNSS Flag DF005 bit(1) 1

No. of GLONASS Satellite Signals Processed DF035 uint5 5

GLONASS Divergence-free Smoothing Indicator DF036 bit(1) 1

GLONASS Smoothing Interval DF037 bit(3) 3

TOTAL 61


RT

CM

10403.2

109

The Type 1009 Message supports single-frequency RTK operation, but does not include an indication of the satellite carrier-to-noise (CNR) as measured by the reference station.

Table 3.5-11 Contents of the Satellite-Specific Portion of a Type 1009 Message, Each Satellite – GLONASS Basic RTK, L1 Only


DATA TYPE

NO. OF BITS

GLONASS Satellite ID (Satellite Slot Number) DF038 uint6 6

GLONASS Code Indicator DF039 bit(1) 1

GLONASS Satellite Frequency Channel Number DF040 uint5 5

GLONASS L1 Pseudorange DF041 uint25 25

GLONASS L1 PhaseRange – L1 Pseudorange DF042 int20 20

GLONASS L1 Lock time Indicator DF043 uint7 7

TOTAL 64


RT

CM

10403.2

110

The Type 1010 Message supports single-frequency RTK operation, and includes an indication of the satellite carrier-to-noise (CNR) as measured by the reference station. Since the CNR does not usually change from measurement to measurement, this message type can be mixed with the Type 1009, and used only when a satellite CNR changes, thus saving broadcast link throughput.

Table 3.5-12

Contents of the Satellite-Specific Portion of a Type 1010 Message, Each Satellite – GLONASS Extended RTK, L1 Only


DATA TYPE

NO. OF BITS


GLONASS L1 Code Indicator DF039 bit(1) 1






DF044 uint7 7

GLONASS L1 CNR DF045 uint8 8

TOTAL 79


RT

CM

10403.2

111

The Type 1011 Message supports dual-frequency RTK operation, but does not include an indication of the satellite carrier-to-noise (CNR) as measured by the reference station.

Table 3.5-13

Contents of the Satellite-Specific Portion of a Type 1011 Message, Each Satellite – GLONASS Basic RTK, L1 & L2


DATA TYPE

NO. OF BITS








GLONASS L2-L1 Pseudorange Difference DF047 uint14 14



TOTAL 107


RT

CM

10403.2

112

The Type 1012 Message supports dual-frequency RTK operation, and includes an indication of the satellite carrier-to-noise (CNR) as measured by the reference station. Since the CNR does not usually change from measurement to measurement, this message type can be mixed with the Type 1011, and used only when a satellite CNR changes, thus saving broadcast link throughput.

Table 3.5-14

Contents of the Satellite-Specific Portion of a Type 1012 Message, Each Satellite – GLONASS Extended RTK, L1 & L2


DATA TYPE

NO. OF BITS








DF044 uint7 7



GLONASS L2-L1 Pseudorange Difference DF047 uint14 14




TOTAL 130


RT

CM

10403.2

113

3.5.5 System Parameter Messages

The complete list of record announcements summarizes all messages transmitted by the particular reference station.

3.5-15 Contents of the Type 1013 Message, System Parameters


DATA TYPE

NO. OF BITS

Message Number DF002 uint12 12


Modified Julian Day (MJD) Number DF051 uint16 16

Seconds of Day (UTC) DF052 uint17 17

No. of Message ID Announcements to Follow (Nm) DF053 uint5 5

Leap Seconds, GPS-UTC DF054 uint8 8

Message ID #1 DF055 uint12 12

Message #1 Sync Flag DF056 bit(1) 1

Message #1 Transmission Interval DF057 uint16 16

Message ID #2 DF055 uint12 12

Message #2 Sync Flag DF056 bit(1) 1

Message #2 Transmission Interval DF057 uint16 16

(Repeat until Nm sets)

TOTAL 70+29* Nm


RT

CM

10403.2

114

3.5.6 GPS Network RTK Correction Messages

The use of single reference stations to transmit RTK data is limited by the fact that the accuracy and reliability of integer ambiguity resolution deteriorates with increasing distance from the reference station. A powerful solution to this problem is offered by a synchronized network of RTK stations. Networks of reference stations mitigate the distance-dependency of RTK solutions. With such networks, a provider can generate measurement corrections for receivers operating within a large defined region, and this information can be supplied to the user in a standard format. As the current kinematic and high-accuracy message types 1001-1012 do not support an efficient use of data from multiple reference stations, new approaches must be developed to facilitate the valuable information afforded by networks of reference stations. The standardization of network information and processing models is also necessary to reduce the size of the network RTK corrections, as well as the satellite-independent error information. A simplified approach of transmitting data from reference station networks to roving users is utilized below in the form of a new message set capable of supporting reference network operations. Individual reference stations often support more than one network in a large region. A detailed description of how the message set below supports these networks is given below. The approach used here provides considerable flexibility for the service provider to support a wide variety of services within range of a large network of reference stations. The principle of determining L1 and L2 corrections is defined in Version 2.3 (RTCM Paper 136-2001/SC104-STD – now designated as RTCM 10402.3) and in subsequent revisions of Version 2, as 4.3.18 section B. However version 2.3 is defined for any type of geodetic carrier phase observation, while version 3 assumes clock adjusted carrier phase observations (see RTCM Paper 30-2004/SC104-STD or RTCM 10402.3 section 3.1.4). The correction difference components have been split into a dispersive and a non-dispersive part. The dispersive correction difference is also called ionospheric correction difference, after its contributor. The opposite, the non-dispersive, is also called ionosphere-free correction difference or geometric correction difference, recognizing that it is not purely due to geometry because of the tropospheric contribution.


RT

CM

10403.2

115

The L1 Correction (L1C) and the L2 Correction (L2C) can be determined in general by:

1,1,1,1

1, )(1 SSSSSS AtNf

ctsCL , and

2,2,2,2

2, )(2 SSSSSS AtNf

ctsCL , with

Ss = Computed Geometric Range in meters between the ARP of station S and satellite

)(1, tS = Phase Range Measurement in meters for station S, L1 (similarly for L2)

1,1

SNf

c = Integer Ambiguity part scaled to meters, L1 (similarly for L2). The integer can be arbitrarily chosen for

an initial measurement in order to bring the resulting Phase Correction within range of the field definition. For Network RTK the all-integer ambiguities have to be brought onto a common integer level. Therefore all values per-satellite and per-frequency have to be synchronized between reference stations.

2,1, , SS tt = Receiver clock term for the respective frequency of Phase Range Measurement

2,1, , SS AA

= Antenna Offset and Phase Center Variation Correction for the respective frequency; the service provider

has to ensure that the antenna phase center corrections does not introduce biases. (See also Section 3.1.6, ”Proper Handling of Antenna Phase Center Variation Corrections”)

1f = L1 carrier frequency

2f = L2 carrier frequency

Satellite and relativistic clock term have been neglected in the given formula. These terms cancel sufficiently in the inter-station single difference. A difference of the clock between both station receivers remains in the correction differences. However, the value common to all correction differences for every master-auxiliary reference station pair can be estimated and removed from the correction differences. These inter-station clock biases are also minimized for typical Network RTK applications. The clock difference term between reference stations in the L1 and L2 correction difference may be treated independently. Therefore clock effects may influence Ionospheric and geometric correction differences. Nevertheless, this approach chosen is sufficient for general positioning approaches, since residual clock effects are removed in double differences. Proper treatment of antenna phase center corrections is crucial to avoid unrecoverable biases in correction differences (See also section 3.1.6, “Proper handling of antenna phase center variation corrections”).


RT

CM

10403.2

116

The L1 Correction Difference (L1CD) is calculated as the single-difference of the “Auxiliary Reference Station Carrier Phase Correction” minus “Master Reference Station Carrier Phase Correction”.

MA CLCLCDL 111

An alternate way of calculation is to carry out:

1,1,1,1

1, )()(1 AMAMAMAMAM AtNf

cttsCDL

)(1, tAM = Single-differenced Phase Ranges of Auxiliary Reference Station A minus Master Reference Station M

)(ts AM = Single-differenced slope distances between Satellite and reference station antenna of Auxiliary Reference Station A minus Master Reference Station M

1,1

AMNf

c = Single-differenced Integer Ambiguity values of Auxiliary Reference Station A minus Master Reference

Station M scaled to meters. In practice only double-differenced integer ambiguities can be fixed due to insufficient modeling of various error sources. The single-differenced integer ambiguities for a particular auxiliary reference station minus master reference station might incorporate an arbitrary integer number. The number is arbitrary but common for all satellites and therefore is observed as a common clock error.

1,AMt = Estimated single differenced receiver clock term on L1.

1,AMA = Single-differenced antenna offset and PCV on L1

Similarly, the L2 Correction Difference (L2CD) is computed as follows:

2,2,2,2

2, )()(2 AMAMAMAMAM AtNf

cttsCDL

Correct integer ambiguity resolution between reference stations is only possible on a double-difference basis. The correct set of double-differenced integer ambiguities is unique for a given data set. A common integer ambiguity level indicates that correction differences are derived from a homogenous solution satisfying the double-difference requirement between all involved reference stations.


RT

CM

10403.2

117

Correction differences are typically based on integer-adjusted raw observation data. Certain rules must be observed to preserve the correctness of the double-difference requirement. In particular, introducing a cycle for one specific satellite-station combination must be compensated for by adjusting other satellite-station combinations in order to maintain a homogenous solution. However, the correction differences are defined as single-differenced values between two reference stations. Therefore the introduction of a fixed number of cycles for the observations of one satellite for all reference stations throughout the whole network will not show up in the correction differences. Changing all observations for a specific reference station by a fixed number of cycles will change all correction differences. The number of introduced cycles will be absorbed by the clock bias estimation in the rover. Two subsets of a network might satisfy the requirement of correct double-differenced integer ambiguities, without necessarily being on the same integer ambiguity level since the choices of integers are arbitrary. As soon as a reference station has common integer ambiguity levels with two subsets of a network these two subsets can be joined and brought to the same integer ambiguity level. These two subsets will then form one subnetwork with the same integer ambiguity level. If circumstances are such that not enough satellites with correct fixed integer ambiguities are available for one reference station or a number of reference stations connecting two subsets of a network, it is advisable to treat the subsets separately. Both subsets will be considered to form different subnetworks with different integer ambiguity levels indicated by assigning different subnetwork ID’s. The correct integer ambiguity level L1-L2 widelane indicates that only the L1-L2 widelane is correctly fixed. The individual L1 and L2 integer ambiguities may contain integer offsets. The L1 and the L2 offsets will be the same. Changing the ambiguity status flag from 3 to 2, 3 to 1, or 2 to 1 without increasing the non sync count indicates that the previous good guess of the integer ambiguity turned out to be the correct integer and the correctness of the integer has been approved by the networking software. Unrecoverable cycle slips might occur for permanent reference station applications as well. If the integer ambiguity for the satellite with the cycle slip is on the integer ambiguity level (see also the discussion above on integer ambiguity level), the unrecoverable cycle will cause the loss of the integer ambiguity level for the specific satellite, reference station, and frequency. Correction difference information for this specific combination needs proper flagging in the ambiguity status flag and increasing the non sync count. The non sync count must be increased if there is an unrecoverable cycle slip in a correction difference that is not on the integer ambiguity level. Frequent cycle slips may cause problems with the counter’s range. The non sync count should not be increased more than once per minute in order to reduce counter roll-overs. Satellites with cycle slips more frequent than once per minute should not be transmitted.


RT

CM

10403.2

118

Arbitrarily fixed, and therefore possibly non-correct integers, provide only sufficient information when the identical integers are used for a certain amount of time. An increase of the non sync count will be associated with ambiguity status flag of 3. In the continuation of the operation the networking software might prove that the arbitrarily chosen integers are actually on the correct integer ambiguity level. Under these circumstances the ambiguity status flag might be changed to the appropriate status of 1 or 2. This is discussed further in Appendix A.1

Table 3.5-16 Contents of the Network Auxiliary Station Data Message 1014


DATA TYPE

NO. OF BITS

NOTES

Message Number DF002 uint12 12 1014

Network ID DF059 uint8 8

Subnetwork ID DF072 uint4 4

Number of Auxiliary Stations Transmitted DF058 uint5 5 0 - 31

Master Reference Station ID DF060 unit12 12

Auxiliary Reference Station ID DF061 uint12 12

Aux-Master Delta Latitude DF062 int20 20

Aux-Master Delta Longitude DF063 int21 21

Aux-Master Delta Height DF064 int23 23

TOTAL 117


RT

CM

10403.2

119

Table 3.5-17 Contents of Header Network RTK -- Messages 1015, 1016 or 1017


DATA TYPE

NO. OF BITS

NOTES

Message Number DF002 uint12 12 1015, 1016 or 1017



GPS Epoch Time (GPS TOW) DF065 uint23 23

GPS Multiple Message Indicator DF066 bit(1) 1

Master Reference Station ID DF060 uint12 12


# of GPS Sats DF067 uint4 4

TOTAL 76


RT

CM

10403.2

120

Table 3.5-18 Contents of Data Block for GPS Ionospheric Correction Differences 1015


DATA TYPE

NO. OF BITS

NOTES


GPS Ambiguity Status Flag DF074 bit(2) 2

GPS Non Sync Count DF075 uint3 3


DF069 int17 17

TOTAL 28

Table 3.5-19 Contents of Data Block for GPS Geometric Correction Differences 1016


DATA TYPE

NO. OF BITS

NOTES





DF070 int17 17

GPS IODE DF071 uint8 8

TOTAL 36


RT

CM

10403.2

121

Table 3.5-20 Contents of Data Block for GPS Combined Geometric and Ionospheric Correction Differences 1017


DATA TYPE

NO. OF BITS

NOTES





DF070 int17 17



DF069 int17 17

TOTAL 53

3.5.7 GPS Ephemerides

The GPS ephemeris message contains GPS satellite ephemeris information. This message could be broadcast in the event that the IODC does not match the IODE, which would require the differential reference station to base corrections on the previous good satellite ephemeris. This would allow the user equipment just entering the differential system to utilize the corrections being broadcast for that ephemeris, and would support the use of the satellite for differential navigation despite the fact that the satellite ephemeris was in error. It is anticipated that this message type would be broadcast every 2 minutes or so while this condition persisted. The schedule would be maintained until the satellite broadcast was corrected, or until the satellite dropped below the coverage area of the reference station. Another use of the message is to assist user receivers to quickly acquire satellites. For example, if the user receiver has access to a wireless service with this message, rather than waiting until one satellite has been acquired and its almanac data processed, it can utilize the ephemeris information immediately.


RT

CM

10403.2

122

All data fields have the same number of bits, the same scale factor and units defined in GPS SPS Signal Specification, Sections 2.4.3 and 2.4.4. The name of the data fields are also kept as close as possible to those defined in GPS SPS Signal Specification document for cross-reference.

Table 3.5-21 Contents of GPS Satellite Ephemeris Data, Message Type 1019


DATA TYPE

NO. OF BITS

NOTES



GPS Week Number DF076 uint10 10 0 - 1023

GPS SV ACCURACY DF077 uint4 4 See GPS SPS Signal Specification, 2.4.3

GPS CODE ON L2 DF078 bit(2) 2 00 - Reserved 01 - P code on 10 - C/A code on 11 - L2C on

GPS IDOT DF079 int14 14 See GPS SPS Signal Specification, 2.4.3

GPS IODE DF071 uint8 8 See GPS SPS Signal Specification, 2.4.3

GPS toc DF081 uint16 16 See GPS SPS Signal Specification, 2.4.3

GPS af2 DF082 int8 8 See GPS SPS Signal Specification, 2.4.3



GPS IODC DF085 uint10 10 See GPS SPS Signal Specification, 2.4.3

GPS Crs DF086 int16 16 See GPS SPS Signal Specification, 2.4.3

GPS n (DELTA n) DF087 int16 16 See GPS SPS Signal Specification, 2.4.3


RT

CM

10403.2

123


DATA TYPE

NO. OF BITS

NOTES

GPS M0 DF088 int32 32 See GPS SPS Signal Specification, 2.4.3

GPS Cuc DF089 int16 16 See GPS SPS Signal Specification, 2.4.3

GPS Eccentricity (e) DF090 uint32 32 See GPS SPS Signal Specification, 2.4.3

GPS Cus DF091 int16 16 See GPS SPS Signal Specification, 2.4.3

GPS (A)1/2 DF092 uint32 32 See GPS SPS Signal Specification, 2.4.3

GPS toe DF093 uint16 16 See GPS SPS Signal Specification, 2.4.3

GPS Cic DF094 int16 16 See GPS SPS Signal Specification, 2.4.3

GPS 0 (OMEGA)0 DF095 int32 32 See GPS SPS Signal Specification, 2.4.3

GPS Cis DF096 int16 16 See GPS SPS Signal Specification, 2.4.3

GPS i0 DF097 int32 32 See GPS SPS Signal Specification, 2.4.3

GPS Crc DF098 int16 16 See GPS SPS Signal Specification, 2.4.3

GPS (Argument of Perigee) DF099 int32 32 See GPS SPS Signal Specification, 2.4.3

GPS OMEGADOT (Rate of Right Ascension) DF100 int24 24 See GPS SPS Signal Specification, 2.4.3

GPS tGD DF101 int8 8 See GPS SPS Signal Specification, 2.4.3

GPS SV HEALTH DF102 uint6 6 See GPS SPS Signal Specification, 2.4.3

GPS L2 P data flag DF103 bit(1) 1 0 - L2 P-Code NAV data ON 1 - L2 P-Code NAV data OFF

GPS Fit Interval DF137 bit(1) 1 See GPS SPS Signal Specification, 2.4.3

TOTAL 488


RT

CM

10403.2

124

3.5.8 GLONASS Ephemerides

The GLONASS ephemeris message contains GLONASS satellite ephemeris information. One use of the message is to assist user receivers to quickly acquire satellites. For example, if the user receiver has access to a wireless service that distributes this message, it can utilize the ephemeris information immediately, rather than waiting until one satellite has been acquired and its almanac data processed. This message could also be broadcast in the event that an anomaly in new ephemeris data set is detected, which would require the differential reference station to base corrections on the previous good satellite ephemeris. This would allow the user equipment just entering the differential system to utilize the corrections being broadcast for that ephemeris, and would support the use of the satellite for differential navigation despite the fact that the satellite ephemeris was in error. It is anticipated that this message type would be broadcast every 2 minutes or so while this condition persisted. The schedule would be maintained until the satellite broadcast was corrected, or until the satellite dropped below the coverage area of the reference station. All data fields have the same number of bits, the same scale factor and units defined in the 5th edition of GLONASS ICD, which contains the most recent information about GLONASS-M navigation data. This document can be downloaded from the official source of information about GLONASS at the website http://www.glonass-center.ru, under the heading “ICD 2002”. The names of the data fields are also kept as close as possible to those defined in the GLONASS ICD for cross-referencing.

Table 3.5-22 Contents of GLONASS Satellite Ephemeris Data, Message Type 1020


DATA TYPE

NO. OF BITS

NOTES




GLONASS almanac health (Cn word) DF104 bit(1) 1 See GLONASS ICD Version 5.0

GLONASS almanac health availability indicator DF105 bit(1) 1 See GLONASS ICD Version 5.0

GLONASS P1 DF106 bit(2) 2 See GLONASS ICD Version 5.0

GLONASS tk DF107 bit(12) 12 See GLONASS ICD Version 5.0

GLONASS MSB of Bn word DF108 bit(1) 1 See GLONASS ICD Version 5.0


RT

CM

10403.2

125


DATA TYPE

NO. OF BITS

NOTES


GLONASS tb DF110 uint7 7 See GLONASS ICD Version 5.0

GLONASS xn(tb), first derivative DF111 intS24 24 See GLONASS ICD Version 5.0

GLONASS xn(tb) DF112 intS27 27 See GLONASS ICD Version 5.0

GLONASS xn(tb), second derivative DF113 intS5 5 See GLONASS ICD Version 5.0

GLONASS yn(tb), first derivative DF114 intS24 24 See GLONASS ICD Version 5.0

GLONASS yn(tb) DF115 intS27 27 See GLONASS ICD Version 5.0

GLONASS yn(tb), second derivative DF116 intS5 5 See GLONASS ICD Version 5.0

GLONASS zn(tb), first derivative DF117 intS24 24 See GLONASS ICD Version 5.0

GLONASS zn(tb) DF118 intS27 27 See GLONASS ICD Version 5.0

GLONASS zn(tb), second derivative DF119 intS5 5 See GLONASS ICD Version 5.0


GLONASS n(tb) DF121 intS11 11 See GLONASS ICD Version 5.0

GLONASS-M P DF122 bit(2) 2 See GLONASS ICD Version 5.0

GLONASS-M ln (third string) DF123 bit(1) 1 See GLONASS ICD Version 5.0

GLONASS n(tb) DF124 intS22 22 See GLONASS ICD Version 5.0

GLONASS-M Δn DF125 intS5 5 See GLONASS ICD Version 5.0

GLONASS En DF126 uint5 5 See GLONASS ICD Version 5.0

GLONASS-M P4 DF127 bit(1) 1 See GLONASS ICD Version 5.0


RT

CM

10403.2

126


DATA TYPE

NO. OF BITS

NOTES

GLONASS-M FT DF128 uint4 4 See GLONASS ICD Version 5.0

GLONASS-M NT DF129 uint11 11 See GLONASS ICD Version 5.0

GLONASS-M M DF130 bit(2) 2 See GLONASS ICD Version 5.0

GLONASS The Availability of Additional Data DF131 bit(1) 1 See GLONASS ICD Version 5.0

GLONASS NA DF132 uint11 11 See GLONASS ICD Version 5.0

GLONASS c DF133 intS32 32 See GLONASS ICD Version 5.0

GLONASS-M N4 DF134 uint5 5 See GLONASS ICD Version 5.0

GLONASS-M GPS DF135 intS22 22 See GLONASS ICD Version 5.0

GLONASS-M ln (fifth string) DF136 bit(1) 1 See GLONASS ICD Version 5.0

Reserved bit(7) 7

TOTAL 360

Note: GLONASS-M data are valid for GLONASS-M satellites only: refer to the description of data field DF130. 3.5.9 Unicode Text String Message

Message type 1029 contains a variable length text string for any displayable information the service provider may want to transmit to the user. For maximum flexibility, the characters in this message are in the Unicode encoding scheme. Unicode is a system for providing a unique numeric code for each character in every language, while allowing for support of any subset of the complete code space. See http://www.unicode.org for the Unicode specification and conformance information. The characters in this message are in the UTF-8 encoding form to provide transparency for ASCII code points (00h-7Fh). That is, the 128 ASCII characters are encoded in the identical 8-bit form in UTF-8. All other characters are multi-byte and each byte in that sequence will be in the range 80h-FFh. Therefore, each byte does not necessarily constitute a full character, but is instead referred to


RT

CM

10403.2

127

as a “code unit” of a character. The Unicode specification defines how to identify the number of 8-bit code units constituting a received character and how to handle unknown or ill-formed characters. Because the length of the string is known, a terminating NULL must not be included.

Table 3.5-23 Contents of the Unicode Text String, Message Type 1029

DATA FIELD DF NUMBER DATA TYPE NO. OF BITS

NOTES



Modified Julian Day (MJD) Number DF051 uint16 16 (Note 1)

Seconds of Day (UTC) DF052 uint17 17 (Note 1)

Number of Characters to Follow DF138 uint7 7 This represents the number of fully formed Unicode characters in the message text. It is not necessarily the number of bytes that are needed to represent the characters as UTF-8. Note that for some messages it may not be possible to utilize the full range of this field, e.g. where many characters require 3 or 4 byte representations and together will exceed 255 code units.

Number of UTF-8 Code Units (N) DF139 uint8 8 The length of the message is limited by this field, or possibly by DF+1 (see previous note).

UTF-8 Character Code Units DF140 utf8(N) 8*N

TOTAL 72+8*N

Note 1 – The time tag used in this message refers to the approximate time of message transmission (the actual time of transmission may be delayed by buffering). If a different time of applicability is required, the service provider may include that time within the Unicode message text.


RT

CM

10403.2

128

Example Unicode Text String Message The following is an example of the Unicode Text String Message represented in hexadecimal with the UTF-8 code units in bold:

D3 00 27 40 50 17 00 84 73 6E 15 1E 55 54 46 2D 38 20 D0 BF D1 80 D0 BE D0 B2 D0 B5 D1 80 D0 BA D0 B0 20 77 C3 B6 72 74 65 72 ED A3 3B

The parameters of the message are

Message Number = 1029 Reference Station ID = 23 Modified Julian Day (MJD) Number = 132 Seconds of Day (UTC) = 59100 Number of Characters to Follow = 21 Number of UTF-8 Code Units = 30

The message text used in the example is “UTF-8 проверка wörter” (UTF-8 check words) without quotes. The Unicode code points and character names for this message are: 0055 LATIN CAPITAL LETTER U 0440 CYRILLIC SMALL LETTER ER 0054 LATIN CAPITAL LETTER T 043A CYRILLIC SMALL LETTER KA 0046 LATIN CAPITAL LETTER F 0430 CYRILLIC SMALL LETTER A 002D HYPHEN-MINUS 0020 SPACE 0038 DIGIT EIGHT 0077 LATIN SMALL LETTER W 0020 SPACE 00F6 LATIN SMALL LETTER O WITH DIAERESIS 043F CYRILLIC SMALL LETTER PE 0072 LATIN SMALL LETTER R 0440 CYRILLIC SMALL LETTER ER 0074 LATIN SMALL LETTER T 043E CYRILLIC SMALL LETTER O 0065 LATIN SMALL LETTER E 0432 CYRILLIC SMALL LETTER VE 0072 LATIN SMALL LETTER R 0435 CYRILLIC SMALL LETTER IE


RT

CM

10403.2

129

3.5.10 Coordinate Transformation Messages

Further information about coordinate transformations can be found at “OGP Surveying and Positioning Guidance Note Number 7, part 2 - Coordinate Conversions and Transformations including Formulas” (Further on referred to as OGP) and EPSG database Version 6.11_2 (Further on referred to as EPSG) at http://www.epsg.org/ or at the European Coordinate Reference System (CRS) website at http://crs.bkg.bund.de/.

3.5.10.1 Transformation Information

For RTCM data supporting a RTK service, coordinates are measured within the ITRF or a regional realization. Surveyors and other users of RTK services must normally present their results in the coordinates of local datums. Therefore, coordinate transformations are necessary. Currently, transformation parameters are calculated and manually transferred to GPS receivers, a process which can be a source of confusion. Another method is to store models on the GPS receivers and to use these for the transformation. However, it often happens that revised models are not available in the GPS receiver, so that users end up utilizing obsolete information. Users have often expressed their desire to be able to utilize a simpler and more convenient method. By having RTCM messages that contain transformation data and information about the Coordinate Reference Systems, the users of the RTK service can obtain their results in the desired datum without any manual operations. The RTK service providers can then ensure that current information for the computation of the transformations is always used. The convenience of this method will promote the acceptance of RTK services.

3.5.10.2 Concatenated Coordinate Operation (ISO 19111)

The change of coordinates from one coordinate reference system to another coordinate reference system follows from a series of coordinate operations consisting of one or more coordinate transformations and/or one or more coordinate conversions. This is called a concatenated coordinate operation.


RT

CM

10403.2

130

Figure 3.5-1. Steps in the Coordinate Transformation Process

The transformation of coordinates from an ECEF coordinate system to a local coordinate system generally requires several steps, as described in the next few paragraphs. Datum transformation

The transformation from the global ECEF (ITRF, ETRF, ...) to the local geodetic datum is generally accomplished by means of a 7-parameter transformation. The ISO19111 specifies the linearized, or approximate, transformation formula. The parameters found in many publications as well as databases like the EPSG or European initiatives, and all the IGS and IERS parameters correspond to this formula. The use of the linearized formula and a respective 7-parameter set is specified by the computation-indicator “0”. The strict formula of a 7-parameter transformation is also often used in practice and is related to finite rotations’ parameterization. The application of the strict formula and a respective set of 7 parameters is specified by the computation-indicator “1” in data field DF150. The 7 parameters belonging to the indicator “0” and “1”, respectively are self-consistent also with respect to the given and different inversion formulas, while the different transformation parameterizations and related parameters themselves can not to be interchanged without a loss of transformation correctness and accuracy. Coordinate conversion from geocentric Cartesian representation to ellipsoidal latitude, longitude and height

This conversion requires the knowledge of the ellipsoidal parameters (a,b). Coordinate conversion to plane coordinates

This coordinate conversion uses projection formulas like the Transverse Mercator projection (Gauss-Krüger, UTM,..) or other (mostly) conformal projections to obtain 2-D Cartesian plane coordinates (Northing, Easting) and 3.5-D height. The projection step

Coordinatesrelated to

source CRS

Coordinateoperation I

Coordinates related toIntermediate CRS

Coordinatesrelated totarget CRSof coordinateoperation I

Coordinatesrelated tosource CRSof coordinateoperation II

Coordinateoperation II

Coordinatesrelated to

target CRS


RT

CM

10403.2

131

requires the knowledge of the ellipsoidal parameters as well as the parameters for the projection (prime meridian, scale, false northing and easting etc.).

Height transformation

From ellipsoidal heights to the local, leveling-related height system requires the knowledge of the difference between the ellipsoid and the reference surface for the local height system. This reference surface may be the geoid, quasi-geoid or a similar surface. The representation of such a reference surface includes the vertical datum as well as systematic and stochastic effects in the realization of the local height systems. The height surface can be related either to the global datum and ellipsoid, or to the local datum and ellipsoid. The height transition from ellipsoidal to physical heights can also be accomplished within the 7-parameter transformation, if the area is very small (see DF152, DF153). Transformation from global ECEF to plate-fixed ECEF coordinates

The dynamic earth causes movements of the tectonic plates on the order of centimeters per year. This means that the transformation parameters are not constant. To account for this, different organizations have established quasi-global coordinate reference systems, which are tied to the tectonic plates (ETRS in Europe). If the starting point for step no. 1 is such a plate-fixed coordinate system, then the transformation parameters may be considered constant for a longer period of time, since only local movements within the plates would be responsible for changes. Since global GNSS (satellite coordinates) are described in a global ECEF coordinate system, an additional transformation step is necessary: An additional message will be defined for this function in the future. It will be omitted in this document.

3.5.10.3 3-D Coordinate Transformation Formulas


RT

CM

10403.2

132

There are four sets of transformations that will be supported in this Standard: (1) the linear form of the Helmert Transformation, (2) the strict form of the Helmert Transformation, (3) the abridged Molodenski Transformation, and (4) the Molodenski-Badekas Transformation. They are described in EPSG Guidance Note 7, which is on the website of the “Surveying and Positioning Committee of the International Association of Oil and Gas Producers (OGP)”, the former “European Petroleum Survey Group” (EPSG, http://www.epsg.org ). Figure 3.5-2 shows the geometry of the transformation and the senses of rotation used herein.

Figure 3.5-2. Definition of Translation and Rotations


RT

CM

10403.2

133

3.5.10.3.1 Helmert Transformation, linear expression

(OGP 2.4.3.2.2 Coordinate Frame Rotation, EPSG dataset coordinate operation method code 9607) Transformation of coordinates from one geographic coordinate reference system into another (also known as a “datum transformation”) is usually carried out as an implicit concatenation of three transformations: [geographical to geocentric >> geocentric to geocentric >> geocentric to geographic] The middle part of the concatenated transformation, from geocentric to geocentric, is usually described as a simplified 7-parameter Helmert transformation. The formula is:

dZ

dY

dX

Z

Y

X

RR

RR

RR

M

Z

Y

X

S

S

S

XY

XZ

YZ

T

T

T

*

1

1

1

* (3.5-1)

and the parameters are defined as: (R1, R2, R3): Rotations to be applied to the coordinate reference frame. The sign convention is such that a positive rotation of the frame about an axis is defined as a clockwise rotation of the coordinate reference frame when viewed from the origin of the Cartesian coordinate system in the positive direction of that axis, that is a positive rotation about the Z-axis only from source coordinate reference system to target coordinate reference system will result in a smaller longitude value for the point in the target coordinate reference system. Although rotation angles may be quoted in any angular unit of measure, the formula as given here requires the angles to be provided in radians. The formula as given here requires the angles to be provided in radians - conversion from arc seconds (R1, R2, R3) to radians (RX, RY, RZ ):


RT

CM

10403.2

134

180*3600*1

RRX (3.5-2)

180*3600*2

RRY (3.5-3)

180*3600*3

RRZ (3.5-4)

M : The scale factor to be applied to the position vector in the source coordinate reference system in order to obtain the correct scale of the target coordinate reference system.

M = (1+dS*10-6) (3.5-5)

3.5.10.3.2 Helmert Transformation, Strict formula

S

S

S

T

T

T

Z

Y

X

M

dZ

dY

dX

Z

Y

X

** R (3.5-6)

where R is the rotation matrix defined by

11

11

22

22

33

33

xz

cossin0

sincos0

001

cos0sin

010

sin0cos

100

0cossin

0sincos

RR

RR

RR

RR

RR

RR

y RRRR (3.5-7)


M = (1+dS*10-6) (3.5-8) Inverse formula


RT

CM

10403.2

135

To transform in the opposite direction using the same numerical values as for the forward formula use the following strict inverse formula:

dZ

dY

dX

Z

Y

X

MZ

Y

X

T

T

T

S

S

S

1-R

(3.5-9)

where R-1 is the mathematical inverse of the rotation matrix = the transposed matrix RT.


RT

CM

10403.2

136

3.5.10.3.3 Molodenski Transformation, abridged

S

T S

T S

T

d

d

h h dh

(3.5-10)

2

2

sin cos sin sin cos ( / / ) ( ) / sin 2 / 2[ ]

sin cos[ ]

( ) cos

cos cos cos sin sin / sin

S S S S S s s s s s s S

S

S S

S S

S S S S S s s S s

dX dY dZ M a b N b a df N e a dad rad

M h

dX dYd rad

N h

dh dX dY dZ df N b a da a

/ N

(3.5-11)

where M and N are the meridian and prime vertical radii of curvature at the given latitude φs,

2

S s3/ 22 2

s

a (1-e )

1 e sin( )S

M

(3.5-12)

S

2 2

a

1 sin( )s S

Ne

(3.5-13)

2 2 2 2( ) /S s s se a b a (3.5-14)

da is the difference in the semi-major axes of the target and source ellipsoids [da = aT – aS] and df is the difference in the flattening of the two ellipsoids [df = ft – fs = 1/(1/ft) – 1/(1/fs] where 1/f = a/(a - b). The formulas for dφ and dλ indicate changes in φS and λS in radians. Finally it holds for the translations of the origins: dX=XT – XS , dY=YT – YS and dZ=ZT – ZS


RT

CM

10403.2

137

3.5.10.3.4 Molodenski-Badekas Transformation

(OGP 2.4.3.3 Molodensky-Badekas 10-parameter transformation, EPSG dataset coordinate operation method code 9636) To eliminate high correlation between the translations and rotations in the derivation of parameter values for these Helmert transformation methods, instead of the rotations being derived about the geocentric coordinate reference system origin they may be derived at a location within the points used in the determination. Three additional parameters, the coordinates of the rotation point, are then required. The formula is:

dZ

dY

dX

Z

Y

X

ZZ

YY

XX

RR

RR

RR

M

Z

Y

X

P

P

P

PS

PS

PS

XY

XZ

YZ

T

T

T

*

1

1

1

* (3.5-15)

and the parameters are defined as: (R1, R2, R3): Rotations to be applied to the coordinate reference frame. The sign convention is such that a positive rotation of the frame about an axis is defined as a clockwise rotation of the coordinate reference frame when viewed from the origin of the Cartesian coordinate system in the positive direction of that axis, that is a positive rotation about the Z-axis only from source coordinate reference system to target coordinate reference system will result in a smaller longitude value for the point in the target coordinate reference system. Although rotation angles may be quoted in any angular unit of measure, the formula as given here requires the angles to be provided in radians. ( PX , PY , PZ ): Coordinates of the point about which the coordinate reference frame is rotated, given in the source Cartesian coordinate reference system. The formula as given here requires the angles to be provided in radians - conversion from arc seconds (R1, R2, R3) to radians (RX, RY, RZ ):

180*3600*1

RRX (3.5-16)

180*3600*2

RRY (3.5-17)


RT

CM

10403.2

138

180*3600*3

RRZ (3.5-18)


M = (1+dS*10-6) (3.5-19) Reversibility

The Molodensky-Badekas transformation in a strict mathematical sense is not reversible, i.e. in principle the same parameter values cannot be used to execute the reverse transformation. This is because the evaluation point coordinates are in the forward direction source coordinate reference system and the rotations have been derived about this point. They should not be applied about the point having the same coordinate values in the target coordinate reference system, as is required for the reverse transformation. However, in practical application there are exceptions when applied to the approximation of small differences between the geometry of a set of points in two different coordinate reference systems. The typical vector difference in coordinate values is in the order of 6*101 to 6*102 meters, whereas the evaluation point on or near the surface of the earth is 6.3*106 meters from the origin of the coordinate systems at the Earth’s centre. This difference of four or five orders of magnitude allows the transformation in practice to be considered reversible. Note that in the reverse transformation, only the signs of the translations and rotation parameter values are reversed; the coordinates of the evaluation point remain unchanged.

3.5.10.4 Procedures for Utilizing the Messages

Seven message types are defined here in support of the application of coordinate transformations, namely Message Types 1021 through 1027. Message Type 1021 provides the basic transformation parameters for the first three sets, while Message Type 1022 provides the information for the fourth set, the Molodenski-Badekas transformation. Message Types 1023 and 1024 define the residuals for ellipsoidal and plane grid representations, respectively. Message Types 1025, 1026 and 1027 define the parameters that support the Lambert Conic Conformal (LCC2SP) projection, the Oblique Mercator (OM) projection, and others. At a minimum, the Service Provider should send out either Message Type 1021 or 1022, each of which contains transformation parameters. The other messages provide useful information for many applications. Either Message Type 1023 or 1024 should be utilized, but not both; similarly for Message Types, 1025-1027, only one type should be utilized.


RT

CM

10403.2

139

The interval between successive Coordinate Transformation Messages is arbitrary, but the following guidelines are provided here. If the communications link is bi-directional,

1021 or 1022: Initially send out after 3, 8 and 13 GNSS epochs, each 60 epochs thereafter 1023 or 1024: Initially send out after 4, 9 and 14 GNSS epochs, each 60 epochs thereafter 1025 or 1026 or 1027: Initially send out after 5, 10 and 15 GNSS epochs, each 60 epochs thereafter.

For a one-way broadcast link,

1021 or 1022: Each 60 epochs 1023 or 1024: 10 epochs after 1021 or 1022 1025 or 1026 or 1027: 20 epochs after 1021 or 1022.

If it is necessary to cover larger areas with a one-way broadcast link, neighbouring grids - for the ‘Area of validity of the Helmert/Molodenski transformation’ - can be transmitted with Message Type 1023 or 1024.

The Mobile Receiver must perform the following procedures:

First, the Mobile Receiver should check which Transformation messages are utilized by inspecting the data field DF148, “Utilized Transformation Message Indicator”, which is included in Message Types 1021 and 1022.

All identified messages should be processed before performing the transformation.

The Mobile Receiver should process the residual messages using the interpolation technique identified by the Service Provider.

An estimate of the complete positioning error should be determined using proper error propagation. The contributions of the coordinate transformation are determined by the terms of Helmert/Molodenski error and grid error, respectively.

The Service Provider should observe the following guidelines:

The Service Provider should utilize a fixed set of Areas of Validity rather than attempt to define the Area of Validity in terms of the location of a particular User.

If service is provided to a User in the outer 10% of the Area of Validity, as described in Figure 3.5-2, the corresponding messages for the adjacent Area should be sent out (see Figure 3.5-3).

If the communications link is bi-directional and a User moves into the outer 10% of the Area of Validity, a residual message (1023 or 1024) should be sent out immediately.

o A new residual message (1023 or 1024) for the neighbouring meshes should be sent out immediately, and repeated 5


RT

CM

10403.2

140

and 10 epochs later.

o Type 1021 (or 1022) and 1025 (or 1026 or 1027) messages should be postponed, if they would normally be sent at the same time.

The grid extensions should be the same within the area of a Service Provider

The raster points of the grid should not change and should be independent of the rover position. The Service Provider should determine the origin of the raster according to the rover position and then send the appropriate raster.

Figure 3.5-3. Area of Validity

Figure 3.5-3 shows the area of validity for the Helmert/Molodenski transformation, with the latitude and longitude coordinates of the origin, and the extent of the area in latitude and longitude. If the extent of the area of validity in latitude and longitude is undefined (see DF154, DF155), then the area of validity is global.


RT

CM

10403.2

141

Figure 3.5-4 shows the grid definition for the residual messages, i.e., Message Types 1023 and 1024. The Area of Validity is shown in the center, with the eight adjacent Areas surrounding it. The parameters of Message Type 1023 are defined with respect to longitude and latitude, while the parameters of Message Type 1024 are defined with respect to East and North, respectively. The residual messages define the 3-dimensional shifts for each point number. If the area of validity is undefined (see DF194, DF195 and DF204, DF205), then messages 1023 and 1024 are invalid. The squares are identified in Roman numerals as follows:

I II III IV V VI VII VIII IX

Figure 3.5-4. Grid Definition for Residual Messages

1 2 3 4

5 6 7 8

9 10

(φ0, λ0 or N0, E0)

11 12

∆φ

∆φ

∆λ ∆λ ∆λ

∆φ

13 14 15 16


RT

CM

10403.2

142

Figures 3.5-5 through 3.5-7 show the raster points used for each interpolation method identified in Message Types 1023 and 1024, namely bi-linear, bi-quadratic, and bi-spline, respectively. The mesh points as provided by messages 1023 and 1024 do not have to overlap with neighboring meshes transmitted. For example 4 messages might cover overall 8 by 8 mesh points.

In the bi-linear method, the rover can be located anywhere in the shaded area – not just the location shown in Figure 3.5-5; however, it uses only the four surrounding grid points in the interpolation.

Figure 3.5-5. Raster Points Used for Bi-Linear Interpolation


RT

CM

10403.2

143

While it is similar to the bi-linear interpolation, only a section of grid points will be used for the bi-quadratic interpolation. The squares West, North-West and North of the interpolation square are always used for quadratic interpolations. For instance, the grid points in the upper left (1, 2, 3, 5, 6, 7, 9, 10, and 11, squares I, II, IV, and V) are used for interpolation when the rover is within one square, namely the shaded square shown in Figure 3.5-6. For one particular message 1023 or 1024 interpolations can be performed for squares V, VI, VIII, and IX. Note that the squares shown in this example do not necessarily correlate with the content of messages 1023 and 1024.

Figure 3.5-6. Raster Points Used for the Bi-quadratic Interpolation.


RT

CM

10403.2

144

In the bi-spline method, the rover can be located only in the shaded central square, as indicated in Figure 3.5-7. It uses all 16 grid points in the interpolation.

Figure 3.5-7. Raster Points Used for the Bi-Spline Interpolation.


RT

CM

10403.2

145

3.5.10.5 Contents of the Coordinate Transformation Messages

Table 3.5-24 Contents of the Helmert / Abridged Molodenski Message Type 1021


DATA TYPE NO. OF BITS NOTES


Source-Name Counter DF143 uint5 5

Source-Name DF144 char8(N) 8*N

Target-Name Counter DF145 uint5 5

Target-Name DF146 char8(M) 8*M

System Identification Number DF147 uint8 8

Utilized Transformation Message Indicator DF148 bit(10) 10

Plate Number DF149 uint5 5

Computation Indicator DF150 uint4 4

Height Indicator DF151 uint2 2

ΦV - Latitude of Origin, Area of Validity DF152 int19 19 See Figure 3.5-3

ΛV – Longitude of Origin, Area of Validity DF153 int20 20 See Figure 3.5-3

∆φV – N/S Extension, Area of Validity DF154 uint14 14 See Figure 3.5-3

∆λV – E/W Extension, Area of Validity DF155 uint14 14 See Figure 3.5-3

dX – Translation in X-direction DF156 int23 23

See Equations 3.5-1, 3.5-6, 3.5-9 & 3.5-15

dY – Translation in Y-direction DF157 int23 23 See notes for dX

dZ – Translation in Z-direction DF158 int23 23 See notes for dX


RT

CM

10403.2

146



R1 – Rotation Around the X-axis DF159 int32

32

See Section 3.5.10.3.1, para. 3 and Section 3.5.10.3.4, para. 2, and equations 3.5-2, 3.5-3, 3.5-4, 3.5-7, 3.5-15, 3.5-16, 3.5-17, & 3.5-18

R2 – Rotation Around the Y-axis DF160 int32 32 See notes for R1

R3 – Rotation Around the Z-axis DF161 int32 32 See notes for R1

dS – Scale Correction DF162 int25 25

See equations 3.5-5, 3.5-8 & 3.5-19

add aS – Semi-major Axis of Source System Ellipsoid

DF166 uint24 24 See Section 3.5.10.2 and final two para's in Section 3.5.10.3.3, and equations 3.5-11 through 3.5-14.

add bS – Semi-minor Axis of Source System Ellipsoid

DF167 uint25 25 See notes for add aS

add aT – Semi-major Axis of Target System Ellipsoid


add bT – Semi-minor Axis of Target System Ellipsoid


Horizontal Helmert/Molodenski Quality Indicator

DF214 uint3 3

Vertical Helmert/Molodenski Quality Indicator

DF215 uint3 3

TOTAL 412 + 8*N + 8*M


RT

CM

10403.2

147

Table 3.5-25 Contents of the Molodenski-Badekas Transformation Message Type 1022


DATA TYPE

NO. OF BITS NOTES

Message Number DF002 uint12 12Source-Name Counter DF143 uint5 5

Source-Name DF144 char8(N) 8*N

Target-Name Counter DF145 uint5 5

Target-Name DF146 char8(M) 8*M


Utilized Transformation Message Indicator DF148 bit(10) 10

Plate Number DF149 uint5 5

Computation Indicator DF150 uint4 4

Height Indicator DF151 uint2 2

ΦV - Latitude of Origin, Area of Validity DF152 int19 19 See Figure 3.5-3

ΛV - Longitude of Origin, Area of Validity DF153 int20 20 See Figure 3.5-3

∆φV – N/S Extension, Area of Validity DF154 uint14 14 See Figure 3.5-3

∆λV – E/W Extension, Area of Validity DF155 uint14 14 See Figure 3.5-3

dX – Translation in X-direction DF156 int23 23

See Equations 3.5-1, 3.5-6, 3.5-9 & 3.5-15

dY – Translation in Y-direction DF157 int23 23 See notes for dX

dZ – Translation in Z-direction DF158 int23 23 See notes for dX


RT

CM

10403.2

148


DATA TYPE

NO. OF BITS NOTES

R1 – Rotation Around the X-axis DF159 int32

32

See Section 3.5.10.3.1, para. 3 and Section 3.5.10.3.4, para. 2, and equations 3.5-2, 3.5-3, 3.5-4, 3.5-7, 3.5-15, 3.5-16, 3.5-17, & 3.5-18

R2 – Rotation Around the Y-axis DF160 int32 32 See notes for R1

R3 – Rotation Around the Z-axis DF161 int32 32 See notes for R1

dS – Scale Correction DF162 int25 25

See equations 3.5-5, 3.5-8 & 3.5-19

XP – X Coordinate for M-B Rotation Point DF163 int35 35 See equation 3.5-15

YP – Y Coordinate for M-B Rotation Point DF164 int35 35 See notes for XP

ZP – Z Coordinate for M-B Rotation Point DF165 int35 35 See notes for XP

add aS – Semi-major Axis of Source System Ellipsoid

DF166 uint24 24 See Section 3.5.10.2 and finaltwo para's in Section 3.5.10.3.3, and equations 3.5-11 through 3.5-14.

add bS – Semi-minor Axis of Source System Ellipsoid


add aT – Semi-major Axis of Target System Ellipsoid


add bT – Semi-minor Axis of Target System Ellipsoid


Horizontal Helmert/Molodenski Quality Indicator

DF214 uint3 3


RT

CM

10403.2

149


DATA TYPE

NO. OF BITS NOTES

Vertical Helmert/Molodenski Quality Indicator

DF215 uint3 3

TOTAL 517 + 8*N + 8*M


RT

CM

10403.2

150

Table 3.5-26 Contents of the Residual Message, Ellipsoidal Grid Representation, Message Type 1023





Horizontal Shift Indicator DF190 bit(1) 1

Vertical Shift Indicator DF191 bit(1) 1

φ0 – Latitude of Origin of Grids DF192 int21 21 See Figure 3.5-4

λ0 – Longitude of Origin of Grids DF193 int22 22 See Figure 3.5-4

∆φ – N/S Grid Area Extension DF194 uint12 12 See Figure 3.5-4

∆λ – E/W Grid Area Extension DF195 uint12 12 See Figure 3.5-4

Mean ∆φ – Mean Latitude Offset DF196 int8 8

Mean ∆λ – Mean Longitude Offset DF197 int8 8

Mean ∆H – Mean Height Offset DF198 int15 15

Three shifts for 16 grid points (i=1,16) 16*(9+9+9)

φi – Latitude Residual DF199 int9 See Figure 3.5-4

λi – Longitude Residual DF200 int9 See Figure 3.5-4

hi – Height Residual DF201 int9 See Figure 3.5-4

Horizontal Interpolation Method Indicator DF212 uint2 2 See Figures 3.5-5 through 3.5-7

Vertical Interpolation Method Indicator DF213 uint2 2 See Figures 3.5-5 through 3.5-7

Horizontal Grid Quality Indicator DF216 uint3 3

Vertical Grid Quality Indicator DF217 uint3 3


TOTAL 578


RT

CM

10403.2

151

Table 3.5-27 Contents of the Residual Message, Plane Grid Representation, Message Type 1024





Horizontal Shift Indicator DF190 bit(1) 1

Vertical Shift Indicator DF191 bit(1) 1

N0 – Northing of Origin DF202 int25 25 See Figure 3.5-4

E0 – Easting of Origin DF203 uint26 26 See Figure 3.5-4

∆N – N/S Grid Area Extension DF204 uint12 12 See Figure 3.5-4

∆E – E/W Grid Area Extension DF205 uint12 12 See Figure 3.5-4

Mean ∆N – Mean Local Northing Offset DF206 int10 10

Mean ∆E – Mean Local Easting Offset DF207 int10 10

Mean ∆h – Mean Local Height Offset DF208 int15 15

Three shifts for 16 grid points (i=1,16) 16*(9+9+9)

Ni – Residual in Local Northing DF209 int9 See Figure 3.5-4

Ei – Residual in Local Easting DF210 int9 See Figure 3.5-4

hi – Residual in Local Height DF211 int9 See Figure 3.5-4

Horizontal Interpolation Method Indicator DF212 uint2 2 See Figures 3.5-5 through 3.5-7

Vertical Interpolation Method Indicator DF213 uint2 2 See Figures 3.5-5 through 3.5-7

Horizontal Grid Quality Indicator DF216 uint3 3

Vertical Grid Quality Indicator DF217 uint3 3



RT

CM

10403.2

152



TOTAL 590

Table 3.5-28 Contents of the Projection Message Type 1025 (Projection Types except LCC2SP, OM)





Projection Type DF170 uint6 6

LaNO – Latitude of Natural Origin DF171 int34 34 See EPSG dataset coordinate operation

LoNO – Longitude of Natural Origin DF172 int35 35 See EPSG dataset coordinate operation

add SNO – Scale Factor at Natural Origin DF173 uint30 30 See EPSG dataset coordinate operation

Ignore if projection = CS

FE – False Easting DF174 uint36 36 See EPSG dataset coordinate operation

FN – False Northing DF175 int35 35 See EPSG dataset coordinate operation

TOTAL 196


RT

CM

10403.2

153

Table 3.5-29 Contents of the Projection Message 1026 (Projection Type LCC2SP - Lambert Conic Conformal (2 SP))






LaFO – Latitude of False Origin DF176 int34 34 See EPSG dataset coordinate operation

LoFO – Longitude of False Origin DF177 int35 35 See EPSG dataset coordinate operation

LaSP1 – Latitude of Standard Parallel No. 1 DF178 int34 34 See EPSG dataset coordinate operation

LaSP2 – Latitude of Standard Parallel No. 2 DF179 int34 34 See EPSG dataset coordinate operation

EFO – Easting of False Origin DF180 uint36 36 See EPSG dataset coordinate operation

NFO – Northing of False Origin DF181 int35 35 See EPSG dataset coordinate operation

TOTAL 234


RT

CM

10403.2

154

Table 3.5-30 Contents of the Projection Message 1027 (Projection Type OM - Oblique Mercator)






Rectification Flag DF182 bit(1) 1

LaPC – Latitude of Projection Center DF183 int34 34 See EPSG dataset coordinate operation

LoPC – Longitude of Projection Center DF184 int35 35 See EPSG dataset coordinate operation

AzIL – Azimuth of Initial Line DF185 uint35 35 See EPSG dataset coordinate operation

Diff ARSG – Difference, Angle from Rectified to Skew Grid

DF186 int26 26 See EPSG dataset coordinate operation

Add SIL – Scale factor on Initial Line DF187 uint30 30 See EPSG dataset coordinate operation

EPC – Easting at Projection Center DF188 uint36 36 See EPSG dataset coordinate operation

NPC – Northing at Projection Center DF189 int35 35 See EPSG dataset coordinate operation

TOTAL 258


RT

CM

10403.2

155

3.5.11 Network RTK Residual Error Messages

3.5.11.1 Background

The Network RTK concept is based on having a plurality of GNSS reference stations continuously connected via data links to a control center. One or more computers at the control center continuously gather the information from all receivers and create network error models such as ionospheric, geometric (including troposphere and orbit) models and site-specific multipath error models in real time. One approach providing Network RTK services is described in Section 3.5.6, and utilizes Message Types 1014 through 1017. Another approach is to have the rover working in the network area send its approximate position to the control center via a bi-direction data link. The control center can then generate an “optimal” data stream derived from the physical reference station data and the network error models at the approximate rover position, and then sends the data stream to the rover via the same data link. This technique creates reference station data for a new invisible, unoccupied station. Hereafter this will be referred to as a “non-physical reference station”. Note: A Non-Physical or Computed Reference Station is typically calculated based on information from a network of reference stations. Different approaches have been established over the years. The Non-Physical or Computed Reference Stations are sometimes trademarked and may not be compatible. Examples of these names are “Virtual Reference Stations”, “Pseudo-Reference Stations”, and “Individualized Reference Stations”.

3.5.11.2 Network RTK Residual Error Information

The Network RTK correction information provided to the rover can be considered as interpolated corrections between the reference stations in the RTK network. Depending on the actual conditions of the atmosphere, this interpolation is not perfect. A residual interpolation error has to be expected. With sufficient redundancy in the RTK network, the network server process can provide an estimate for residual interpolation errors. Such quality estimates may be used by the rover to optimize the performance of RTK solutions. The values may be considered by the rover as a priori estimates only, with sufficient tracking data available the rover might be able to judge residual geometric and ionospheric errors itself. The method of interpolating corrections and quality information for the rover position is proprietary and different solutions may be expected from different network service providers. It is the responsibility of the network server software provider to ensure that the residual information is representative of the actual situation. Network RTK residual error information should be transmitted every 10-60 seconds.


RT

CM

10403.2

156

The standard deviation for the residuals in the messages below may refer to the physical or the non-physical reference station position (indicated by the physical reference station flag in the messages 1005 or 1006) allowing maximum flexibility for the network system. Different scenarios are:

The interpolation of the corrections for the rover location is performed by the network processing software resulting in a non-physical reference station. This approach requires the rover to transmit via NMEA GGA its position to the network processing control center and, hence, bidirectional communication is required. In this scenario the information in the Network RTK Residual Error Messages can be estimated together with the corrections transmitted to the rover. The Network RTK Residual Error Messages will be referenced to the non-physical reference station.

The interpolation of the correction is performed by the rover using data from RTCM 3.1 Network RTK Messages. The rover then has the option to use the Network RTK Residual Error Messages instead of self-computed values. In this the Network RTK Residual Error Messages are referenced to the closest master or auxiliary station to the rover. This approach requires bidirectional communication as the rover’s position is needed to determine the closest reference station.

3.5.11.3 New Physical Reference Station Position Messages

Message Type 1032 (see Table 3.5-35) is similar to the Message Type 1005, but provides the earth-centered, earth-fixed (ECEF) coordinates of the antenna reference point (ARP) for the real (or “physical”) reference station used. No height above a monument is provided. Message Type 1032 contains the coordinates of the ARP in the GNSS coordinate system Earth-Center-Earth-Fixed (ECEF) coordinates -- local datums are not supported. The coordinates always refer to a physical point at the bottom of the antenna. Message Type 1032 is used in case of the non-physical reference station approach to allow the rover to refer baseline vectors to a physical reference rather than to a non-physical reference without any connection to a physical point. This feature is mainly desired for post-processing in office software applications.


RT

CM

10403.2

157

3.5.11.4 Contents of the Network RTK Residual Error Messages

Table 3.5-31 Header Part of the GPS Network RTK Residual Message Type 1030

DATA FIELD DF NUMBER DATA TYPE NO. OF BITS NOTES


GPS Residuals Epoch Time (TOW) DF224 uint20 20


May be the ID of a physical or non-physical station

N-Refs DF223 uint7 7

GPS Number of Satellite Signals Processed DF006 uint5 5

TOTAL 56

Table 3.5-32 Satellite Specific Part of the GPS Network RTK Residual Message Type 1030



ocs DF218 uint8 8

ods DF219 uint9 9

ohs DF220 uint6 6

Ics DF221 uint10 10

Ids DF222 uint10 10

TOTAL 49


RT

CM

10403.2

158

Table 3.5-33 Header Part of the GLONASS Network RTK Residual Message Type 1031



GLONASS Residuals Epoch Time (tk) DF225 uint17 17


May be the ID of a physical or non-physical station

N-Refs DF223 uint7 7

GLONASS Number of Satellite Signals Processed

DF035 uint5 5

TOTAL 53

Table 3.5-34 Satellite Specific Part of the GLONASS Network RTK Residual Message Type 1031


GLONASS Satellite ID DF038 uint6 6

ocs DF218 uint8 8

ods DF219 uint9 9

ohs DF220 uint6 6

Ics DF221 uint10 10

Ids DF222 uint10 10

TOTAL 49


RT

CM

10403.2

159

Table 3.5-35 Physical Reference Station Position Information Message Type 1032


DATA TYPE

NO. OF BITS


Non-Physical Reference Station ID DF003 uint12 12

Physical Reference Station ID DF226 uint12 12

ITRF Epoch Year DF021 uint6 6

Physical reference station ARP ECEF-X DF025 int38 38

Physical reference station ARP ECEF-Y DF026 int38 38

Physical reference station ARP ECEF-Z DF027 int38 38

TOTAL 156

3.5.11.4 Receiver and Antenna Descriptors Message

This message is an elaboration of Message Type 1008, and can be transmitted instead of 1008. It contains not only the antenna information on the reference station but information about receiver type and the firmware version of the receiver type. This message serves several purposes:

1. It allows recipients of RTCM data messages to directly generate RINEX files from the data stream. By utilizing the proper IGS syntax for receiver and names, this data as well as serial numbers and firmware versions can be place in the header of the RINEX observation files.

2. It enables proper identification of the reference station receiver type via the RTCM data stream.

The serial number and firmware version strings are not standardized. They will correspond to the manufacturer’s naming convention.


RT

CM

10403.2

160

The receiver type descriptor should conform to the IGS 20 character definition used by the IGS as defined in the IGS file “rcvr_ant.tab”. If the receiver type, antenna, type, serial numbers, etc., are unknown, the length of the counters should be set to zero, in which case the succeeding descriptor field is not utilized.

Table 3.5-36 Contents of the Type 1033 Message – Receiver and Antenna Descriptors


DATA TYPE

NO. OF BITS

NOTES



Antenna Descriptor Counter N DF029 uint8 8

Antenna Descriptor DF030 char(N) 8*N N 31


Antenna Serial Number Counter M DF032 uint8 8

Antenna Serial Number DF033 char(M) 8*M M 31

Receiver Type Descriptor Counter I DF227 uint8 8

Receiver Type Descriptor DF228 char(I) 8*I I 31

Receiver Firmware Version Counter J DF229 uint8 8

Receiver Firmware Version DF230 char(J) 8*J J 31

Receiver Serial Number Counter K DF231 uint8 8

Receiver Serial Number DF232 char(K) 8*K K 31

TOTAL 72+ 8*(M+N+

I+J+K)


RT

CM

10403.2

161

3.5.12 State Space Messages

3.5.12.1 Background

The principle of the state space concept is to provide information on the status of individual GNSS error sources. Therefore the term State Space Representation (SSR) is used. Differential GNSS and RTK operation using corrections and/or raw measurements from single or multiple reference stations must be distinguished from SSR. Differential positioning using “observation space” to transport information is called Observation Space Representation (OSR). The GNSS state vector of SSR consists of the following basic parameters:

satellite orbit errors satellite clock errors satellite signal biases (delays of codes and carrier phases within satellite hard- and software) ionospheric delay parameters tropospheric delay parameters

and quality indicators for state parameters

RTCM SSR messages are used to disseminate the state space information, which is combined with individual tracked GNSS data of a user (rover) to improve its positioning. Already a sub-set of state space parameters can be sufficient for meaningful applications. Different levels of accuracy are supported depending on the provided SSR messages and the corresponding properties. The actual application scenario for a GNSS rover is flexible and varies. The state space information can be converted into observation space for a rover position and can thus be used to correct the rover observables for more accurate positioning. Then, the application is a conventional OSR process for the rover. Alternatively the state information can directly be used in the rover's processing or adjustment model. The state space approach is a commonly applied concept. The PPP (Precise Point Positioning) concept uses mainly precise satellite orbit and clock parameters derived consistently from global networks of reference stations as well as global atmospheric models to perform single station positioning. Accuracies in the sub-meter or even sub-decimeter level can be achieved with dual frequency receivers on a global scale.


RT

CM

10403.2

162

For RTK applications, the SSR concept has been demonstrated in an indirect mode. Some network RTK software is based on state space models and the network RTK services are derived from the state vector(s). Without RTCM SSR messages, the state space information is transformed to observation space and represented by observation based RTCM messages.

3.5.12.2 State Space – SSR Messages

The SSR Messages are developed in three major steps:

1. The development of messages for precise orbits, satellite clocks and satellite code biases. This is compatible to the basic PPP mode using IGS products. Such messages will enable real-time PPP for dual frequency receivers: DF-RT-PPP.

2. The development of vertical TEC (VTEC) messages. This will enable RT-PPP for single frequency receivers: SF-RT-PPP.

3. The development of slant TEC (STEC) messages, tropospheric messages and satellite phase biases messages. This will enable RTK-PPP.

The current SSR Message Types cover the first stage of DF-RT-PPP.

3.5.12.3 GPS SSR Orbit Correction, Clock Correction and Code Bias Messages

Tables 3.5-37 to 3.5-49 describe the GPS SSR messages including a SSR URA quality message.


RT

CM

10403.2

163

Table 3.5-37 Header Part of the SSR GPS Orbit Correction Message 1057



GPS Epoch Time 1s DF385 uint20 20

SSR Update Interval DF391 bit(4) 4

Multiple Message Indicator DF388 bit(1) 1

Satellite Reference Datum DF375 bit(1) 1

IOD SSR DF413 uint4 4

SSR Provider ID DF414 uint16 16

SSR Solution ID DF415 uint4 4

No. of Satellites DF387 uint6 6

TOTAL 68


RT

CM

10403.2

164

Table 3.5-38 Satellite Specific Part of the SSR GPS Orbit Correction Message 1057




Delta Radial DF365 int22 22

Delta Along-Track DF366 int20 20

Delta Cross-Track DF367 int20 20

Dot Delta Radial DF368 int21 21

Dot Delta Along-Track DF369 int19 19

Dot Delta Cross-Track DF370 int19 19

TOTAL 135

Table 3.5-39 Header Part of the SSR GPS Clock Correction Message 1058










TOTAL 67


RT

CM

10403.2

165

Table 3.5-40 Satellite Specific Part of the of the SSR GPS Clock Correction Message 1058



Delta Clock C0 DF376 int22 22



TOTAL 76

Table 3.5-41 Header Part of the SSR GPS Satellite Code Bias Message 1059









No. of Satellites DF387 uint6 6 (No. of Satellites) * (SV Block) will immediately follow this DF.

TOTAL 67

* SV Block consists of Satellite Specific Part immediately followed by Code specific part for the corresponding satellite.


RT

CM

10403.2

166

Table 3.5-42 Satellite Specific Part of the of the SSR GPS Satellite Code Bias Message 1059



No. of Code Biases Processed DF379 uint5

5

The Code Specific Parts for all processed Code Biases are directly following the Satellite Specific Part of the corresponding satellite. (No. of Code Biases Processed) * (Code Specific Part) will immediately follow this DF.

TOTAL 11

Table 3.5-43 Code Specific Part of the of the SSR GPS Satellite Code Bias Message 1059


GPS Signal and Tracking Mode Indicator DF380 uint5 5

Code Bias DF383 int14 14

TOTAL 19


RT

CM

10403.2

167

Table 3.5-44 Header Part of the SSR GPS Combined Orbit and Clock Correction Message 1060











TOTAL 68


RT

CM

10403.2

168

Table 3.5-45 Satellite Specific Part of the SSR GPS Combined Orbit and Clock Correction Message 1060













TOTAL 205


RT

CM

10403.2

169

Table 3.5-46 Header Part of the SSR GPS URA Message 1061










TOTAL 67

Table 3.5-47 Satellite Specific Part of the SSR GPS URA Message 1061



SSR URA DF389 bit(6) 6

TOTAL 12


RT

CM

10403.2

170

Table 3.5-48 Header Part of the SSR GPS High Rate Clock Correction Message 1062










TOTAL 67

Table 3.5-49 Satellite Specific Part of the SSR GPS High Rate Clock Message 1062



High Rate Clock Correction DF390 int22 22

TOTAL 28


RT

CM

10403.2

171

3.5.12.4 GLONASS SSR Orbit Correction, Clock Correction and Code Bias Messages

Tables 3.5-50 to 3.5-62 describe the GLONASS SSR messages including a SSR URA quality message.

Table 3.5-50 Header Part of the SSR GLONASS Orbit Correction Message 1063



GLONASS Epoch Time 1s DF386 uint17 17








TOTAL 65


RT

CM

10403.2

172

Table 3.5-51 Satellite Specific Part of the SSR GLONASS Orbit Correction Message 1063



GLONASS IOD DF392 bit(8) 8







TOTAL 134

Table 3.5-52 Header Part of the SSR GLONASS Clock Correction Message 1064










TOTAL 64


RT

CM

10403.2

173

Table 3.5-53 Satellite Specific Part of the of the SSR GLONASS Clock Correction Message 1064






TOTAL 75

Table 3.5-54 Header Part of the SSR GLONASS Satellite Code Bias Message 1065









No. of Satellites DF387 uint6 6 (No. of Satellites) * (SV Block) will immediately follow this DF.

TOTAL 64

* SV Block consists of Satellite Specific Part immediately followed by Code specific part for the corresponding satellite.


RT

CM

10403.2

174

Table 3.5-55 Satellite Specific Part of the of the SSR GLONASS Satellite Code Bias Message 1065



No. of Code Biases Processed DF379 uint5

5

The Code Specific Parts for all processed Code Biases are directly following the Satellite Specific Part of the corresponding satellite. (No. of Code Biases Processed) * (Code Specific Part) will immediately follow this DF.

TOTAL 10

Table 3.5-56 Code Specific Part of the of the SSR GLONASS Satellite Code Bias Message 1065


GLONASS Signal and Tracking Mode Indicator DF381 uint5 5

Code Bias DF383 int14 14

TOTAL 19


RT

CM

10403.2

175

Table 3.5-57 Header Part of the SSR GLONASS Combined Orbit and Clock Correction Message 1066











TOTAL 65


RT

CM

10403.2

176

Table 3.5-58 Satellite Specific Part of the SSR GLONASS Combined Orbit and Clock Correction Message 1066













TOTAL 204


RT

CM

10403.2

177

Table 3.5-59 Header Part of the SSR GLONASS URA Message 1067










TOTAL 64

Table 3.5-60 Satellite Specific Part of the SSR GLONASS URA Message 1067



SSR URA DF389 bit(6) 6

TOTAL 11


RT

CM

10403.2

178

Table 3.5-61 Header Part of the SSR GLONASS High Rate Clock Correction Message 1068










TOTAL 64

Table 3.5-62 Satellite Specific Part of the SSR GLONASS High Rate Clock Correction Message 1068



High Rate Clock Correction DF390 int22 22

TOTAL 27

Tables 3.5-37 through 3.5-45 and 3.5-50 through 3.5-57 provide the contents of the basic GPS and GLONASS SSR orbit, clock and code bias messages, which support GNSS Precise Point Positioning (PPP) for dual frequency receiver applications. The orbit and clock messages contain data to be combined with the corresponding values obtained from the satellites broadcast message. The supported broadcast messages are currently the GPS navigation message (NAV data, D(t), IS-GPS-200D) and GLONASS-M navigation message (GLONASS ICD Version 5.1).


RT

CM

10403.2

179

All messages may be split over several messages using the Multiple Message Indicator. It increases the number of e.g. satellites to be transmitted, but it also enables the receiver to begin immediately processing of data after decoding the first message of a multiple message type.

3.5.12.5 SSR Orbit Correction Message

Figure 3.12-1. Radial, along-track and cross-track orbit components

The Orbit Correction Message contains the parameters for orbit corrections in radial, along-track and cross-track component. These orbit corrections are used to compute a satellite position correction , to be combined with satellite position

calculated from broadcast ephemeris. The sign definition of the correction is

(3.12-1) with satellite position corrected by SSR Orbit Correction message satellite position computed according to corresponding GNSS ICD from broadcast ephemeris parameter set identified by IOD/IODE in SSR Orbit Correction message satellite position correction


RT

CM

10403.2

180

The satellite position correction is computed according to

| | (3.12-2)

| | (3.12-3)

(3.12-4)

(3.12-5)

with satellite broadcast position vector satellite broadcast velocity vector direction unit vector, i = {radial, along, cross} orbit correction vector Note: The radial vector according to formula (3.12-4) has to be used for the computation and should not be confused with a radial vector of a circular orbit. The complete orbit correction vector is computed from the individual correction terms and their velocities:

(3.12-6)

with time reference time obtained from SSR Orbit Correction message , , , orbit correction terms from SSR Orbit message, i = {radial, along, cross}


RT

CM

10403.2

181

The reference time for the velocity term is computed from the GNSS epoch time (GPS: DF385, GLONASS: DF386) plus half the SSR Update Interval (DF391). Exception is SSR Update Interval “0”, which uses the GNSS Epoch time as reference time. Orbit representation requires the definition of a coordinate reference system. For global services the coordinate system should be related to the ITRS. For regional services a reference system related to the tectonic plate of the region is often used. The messages (1057, 1060, 1063, 1066) allow orbits transformed from ITRF to a global coordinate system close to ITRF (e.g. ETRF, NAD, JGD2000). Then, it is not necessary for the rover to perform the corresponding transformation. A regional datum is indicated by the Satellite Reference Datum flag, while the actual coordinate reference system will be identified by the configured stream of the service provider.

3.5.12.6 SSR Clock Correction Message

The Clock Message contains the parameters to compute the clock correction applied to the broadcast satellite clock. The polynomial representation describes the clock differences for a certain time period. The sign definition of the corrections is

(3.12-7)

with satellite time computed according to corresponding GNSS ICD from broadcast clock parameters, identified by IOD/IODE of corresponding SSR Orbit Correction message satellite time corrected by SSR Clock Correction message clock correction obtained from SSR Clock Correction message The polynomial is computed according to

(3.12-8) with time reference time obtained from SSR Clock Correction message polynomial coefficients from SSR Clock Correction message, i = {0, 1, 2}


RT

CM

10403.2

182

The reference time for the polynomial terms is computed from the GNSS epoch time (GPS: DF385, GLONASS: DF386) plus half the SSR Update Interval (DF391). Exception is SSR Update Interval “0”, which uses the Epoch time as reference time. Note: The relativity correction has to be applied for GPS according to IS-GPS-200D to compute . Referring to paragraph 20.3.3.3.3.1 the relativistic correction term ∆ is

∆ ∙

with vectors and computed from broadcast ephemeris. The relativistic effects are already taken into account in the broadcast clock parameters for GLONASS. Satellite clocks are determined from ionospheric free signals derived from observations used by the service provider. Such observations are affected by delays introduced in the satellite hardware (code biases). For example, GPS broadcast clocks are referenced to the ionospheric free linear combination of the P codes on L1 and L2, ignoring any code biases of these signals. For SSR, the selection of signals used to generate the satellite clock corrections and the treatment of code biases are left to the service provider. The service provider shall ensure a consistent transmission of clock and code bias parameters. A rover must then consistently apply the code biases and clock corrections.

3.5.12.7 SSR Code Bias Message

The Code Bias Message uses a Signal and Tracking Mode Indicator to describe the actual signal properties. The Signal and Tracking Mode Indicator maps the RINEX 3.0 observation types into a more compact storage scheme of integer indices. The RINEX 3.0 observation types based on type (code, carrier, etc.), band (L1, L2, etc.) and attribute (tracking mode) are required to account for the future variety of signal tracking. The Code Biases reported in the SSR Code Bias Message must be added to the pseudo range measurements of the corresponding code signal to get corrected pseudo ranges. Any code biases transmitted in the broadcast messages (e.g. the GPS group delay differential, TGD, IS-GPS 200D) are not applied at all. The Code Bias Message contains absolute values, but also enables the alternative use of differential code biases by setting one of the biases to zero.


RT

CM

10403.2

183

The provider shall support as many signals as possible and must report code biases which are zero. A rover can consistently use signals for which a code bias is transmitted. It is not reliable for a rover to use a signal without retrieving a corresponding code bias from the data stream. Satellite code biases, especially for GLONASS, may depend on the receiver type used to track the signals. The SSR stream provider shall correct the bias level to be consistent with a certain receiver type and shall indicate this receiver type by sending a corresponding Message Type 1033 Receiver and Antenna Descriptors.

3.5.12.8 SSR High Rate Clock Message

To support higher resolution of the clock state and also higher update rates, a High Rate Clock SSR message is used. Both constituents, Clock Message and High Rate Clock Message, define the complete state of the satellite clock. The High Rate Clock correction is added to the corresponding clock correction.

3.5.12.9 SSR Combined Orbit and Clock Correction Message

A Combined Orbit and Clock Correction Message is provided, which reduces the bandwidth and can easily maintain the consistency of orbit and clock data. The Combined Orbit and Clock Message requires that orbit and clock have the same SSR Update Interval.

3.5.12.10 SSR URA Message

Clock and radial orbit state parameters are correlated. A SSR User Range Accuracy (URA) is used as one single statistical indicator to describe the quality of both parameters. The SSR User Range Accuracy is transmitted in a SSR URA message. A special formula is used to enable high resolution for small numbers and low resolution for large numbers.

3.5.12.11 Consistency of Data and Processing

A state space parameter may consist of different constituents disseminated in different SSR messages. The use of different SSR messages is intentional to support different applications, update rates and accuracy requirements. Additional SSR messages will consequently add additional resolution and positioning accuracy. This creates the need to know the consistency of the SSR parameters for an application. Only a consistent set of SSR parameters can build up a complete and accurate correction. The consistency of SSR data becomes more important with increasing resolution provided by additional messages. Generally the continuous chronology of messages can be used to check the consistency, but in real-time applications messages may be lost or delayed. A consistency parameter is also the IOD (IODE for GPS) for orbit in the correction messages, which is used to obtain consistency in the computation and applications of RTCM messages. A similar requirement exists for state space parameters distributed over several SSR messages.


RT

CM

10403.2

184

The combination of SSR data depends on the consistent update of the state parameters as correlations of the parameters exist. It is of advantage, if a SSR message contains all relevant information on the state parameter update without any dependency on other messages. The consistency of data is enabled through the SSR Update Interval. The meaning of SSR Update Interval is different from the transmission rate of SSR messages. The validity interval of SSR parameters can be longer than the SSR Update Interval. There are several SSR Update Intervals defined, which all start at the start of a day in the GPS time scale (time: 00:00:00). The SSR message contains the GNSS epoch time (DF385, DF386). From both information the consistency of the SSR parameters can be verified. A change of an SSR Update Interval is only allowed, if the consistency of SSR data is maintained, i.e. at the end of a SSR Update Interval. The rover is then capable to combine all relevant SSR parameters consistently and it secures the combination of state parameters from different messages. Note: To align GPS and GLONASS SSR Update Intervals, the leap second time difference must be considered for GLONASS. Figure 3.12-2 shows a sketch of the state parameter influence on the Range for a certain location. The updates of five different SSR Range errors are displayed over time. Code biases are state parameters with a static character or a very low update rate. Typically orbit and clock parameters do have different update rates. In the example, the same SSR Update Interval is used for the two different SSR parameters orbit and troposphere. The High Rate Clock will have the highest update rate.


RT

CM

10403.2

185

Figure 3.12-2. Sketch of Concept of SSR Update Interval to ensure the consistency of data for five different SSR parameters.

Please note, that the sketch is only meant to demonstrate the concept. The quantities shown do not represent real physical behavior. All influences are e.g. positive values, however, negative values will also occur in real application.

IOD information of broadcast clocks are redundant information and are not required in addition to the orbit IOD. I.e., the SSR Orbit and Clock corrections refer to the same IOD. The service provider should refer to the latest set of broadcast messages, which are


RT

CM

10403.2

186

generally also received in real-time by a GNSS rover. However, it is recommended to delay the use of the latest broadcast message for a period of 60 seconds, measured from the time of complete reception of ephemeris and clock parameters, in order to accommodate rover applications to obtain the same set of broadcast orbital and clock parameters. It is left to the service provider to send the RTCM Satellite Ephemeris Data (e.g. Message Types 1019 for GPS and 1020 for GLONASS) before switching to a new IOD. It is not allowed to send corrections for more than one IOD for the same orbit Update Interval. The consistency of SSR Orbit and Clock messages is maintained through the SSR Update Interval. The computation of satellite positions and satellite clock offsets from broadcast data must be consistent. The GLONASS ICD refers to two different algorithms. For SSR, the GLONASS broadcast ephemeris computation “Simplify of algorithm for re-calculation of ephemeris to current time” must be used (see GLONASS ICD Version 5.1, A.3.1.2). Note: Please consider two corrections in the GLONASS ICD Version 5.1. In appendix A.3.1.2 the sign of the 4th term in dV dt⁄

correctly reads 2ωV instead of 2ωV and for dV dt⁄ the term in parentheses correctly reads 3 instead of 1 .

Note: The numerical integration of satellite coordinates from broadcast ephemeris should be performed with sufficient accuracy. For instance, the Runge-Kutta method of 4th order with the step of numerical integration that does not exceed 30 seconds can be used to obtain a precision of 0.1 mm. The SSR Update Interval serves to uniquely identify all consistent parameters from different messages, which can be used to compute consistent corrections at one epoch. 3.5.13 GLONASS Network RTK Correction Messages

The principle of GPS Network RTK as described in Section 3.5.6 can also be adopted for GLONASS Network RTK. A simplified approach of transmitting GLONASS data from reference station networks to roving users is utilized below in the form of a new message set capable of supporting GLONASS reference network operations. The GLONASS carrier phase correction difference messages follow the same format defined for the GPS Network RTK messages and are intended to be utilized by the rover software using the same general processing algorithms.


RT

CM

10403.2

187

The GLONASS L1 carrier phase correction (L1CR) and L2 carrier phase correction (L2CR) can be determined by:

,1 ,1 ,1 ,11

1 ( )S S S S S Sc

L CR S t N t Af

, and

,2 ,2 ,2 ,22

2 ( )S S S S S Sc

L CR S t N t Af

, with

SS = Computed geometric range in meters between the ARP of station S and satellite

,1( )S t = GLONASS L1 phase range measurement in meters for station S, (similarly for L2)

,11

Sc

Nf

= GLONASS L1 integer ambiguity part scaled to meters, (similarly for L2).

,1St = L1 receiver clock term for the GLONASS phase range measurement, (similarly for L2)

,1SA = GLONASS L1 antenna offset and phase center variation correction (similarly for L2). The service

provider shall ensure that the antenna phase center corrections do not introduce biases. (See also Section 3.1.6 "Proper Handling of Antenna Phase Center Variation Corrections")

1f = L1 carrier frequency of the GLONASS satellite signal

2f = L2 carrier frequency of the GLONASS satellite signal

The GLONASS L1 Carrier Phase Correction Difference (L1CDR) is calculated as the single-difference of the "Auxiliary Reference Station Carrier Phase Correction" minus "Master Reference Station Carrier Phase Correction".

1 1 1A ML CDR L CR L CR


RT

CM

10403.2

188

An alternate way of calculation is to carry out:

,1 ,1 ,1 ,11

1 ( ) ( )AM AM AM AM AMc

L CDR S t t N t Af

,1( )AM t = Single-differenced GLONASS phase ranges of Auxiliary Reference Station A minus

Master Reference Station M

( )AMS t = Single-differenced slope distances between satellite and reference station antenna of Auxiliary Reference Station A minus Master Reference Station M

,11

AMc

Nf = GLONASS single-differenced integer ambiguity values of Auxiliary Reference Station A

minus Master Reference Station M scaled to meters. For network RTK, all GLONASS integer ambiguities shall be brought onto a common integer level. Therefore, the single-differenced integer ambiguities for a particular Auxiliary Reference Station minus Master Reference Station might incorporate an arbitrary integer number. Although this number is common for all satellites, it will not be observed as a common clock error or cancel in a double difference due to the GLONASS FDMA signal structure. The service provider shall adjust the absolute magnitude of the GLONASS ambiguity level to minimize inter-frequency biases in the GLONASS double-difference correction differences (see also the description of the GLONASS ambiguity level in this section).

,1AMt = Estimated single-differenced receiver clock term on L1

,1AMA = Single-differenced antenna offset and PCV on L1

Similarly, the L2 Carrier Phase Correction Difference (L2CD) is computed as follows:

,2 ,2 ,2 ,22

2 ( ) ( )AM AM AM AM AMc

L CDR S t t N t Af


RT

CM

10403.2

189

Like GPS correction differences, the L1 and L2 GLONASS correction differences are factored into ionospheric and geometric components (see also Section 3.5.6 "GPS Network RTK Correction Messages"). Satellite and relativistic clock term have been neglected in the given formula. These terms cancel sufficiently in the inter-station single difference. Proper treatment of antenna phase center corrections is crucial to avoid unrecoverable biases in correction differences (see also section 3.1.6 “Proper handling of antenna phase center variation corrections”). A difference of the clock between both station receivers remains in the L1 and L2 correction differences. However, the value is common to all correction differences for a given master-auxiliary reference station pair can be estimated and removed. The clock difference term between reference stations in the GLONASS L1 and L2 correction difference may be treated independently. Therefore residual clock effects may influence GLONASS ionospheric and geometric correction differences. Nevertheless, this approach is sufficient for general positioning schemes, since residual clock effects cancel in double differences. The GPS correction differences for a given master-auxiliary pair may contain an arbitrary integer bias that cancels in double differences (see also Section 3.5.6 "GPS Network RTK Correction Messages"). However, an arbitrary integer bias influencing GLONASS correction differences may manifest as so-called inter-frequency biases in double differences as a consequence of the GLONASS frequency division multiple access (FDMA) signal structure. For example, approximately 4.3 mm of error will be introduced for every 5 cycles of bias in the L1 ambiguity level if the difference between the frequency channel numbers of the two GLONASS satellite signals involved in the double-difference is a maximum (13 for the current GLONASS frequency plan). However, the error is only 0.3 mm for the same integer bias if the frequency channel number difference is a minimum. These apparent inter-frequency biases will not be absorbed by the clock estimation in the rover software or cancel in the double difference and may degrade ambiguity resolution and RTK positioning performance. The Network RTK service provider, through appropriate data processing strategies, shall adjust the absolute magnitude of the L1 and L2 integer ambiguity levels to minimize inter-frequency biases in the GLONASS double-differenced correction differences. In practice, the GLONASS ambiguity level is typically adjusted using algorithms that utilize unambiguous single differenced pseudorange measurements. The Network RTK service provider should be especially prudent if the network consists of heterogeneous GLONASS receiver makes and models. Interoperability testing has shown that between-station single difference pseudorange and carrier phase measurements involving mixed receiver types may be influenced by receiver-dependent biases that may introduce significant inter-frequency biases of several centimeters if not treated correctly by the network software. Tables 3.5-63 through 3.5-66 provide the contents of the GLONASS Network RTK correction messages.


RT

CM

10403.2

190

Table 3.5-63 Contents of Header for GLONASS Network RTK Messages 1037, 1038, or 1039





GLONASS Network Epoch Time DF233 uint20 20


Master Reference Station ID DF060 uint12 12


# of GLONASS Data Entries DF234 uint4 4

TOTAL 73

Table 3.5-64 Contents of Data Block for Ionospheric Correction Difference Message 1037



DF038 uint6 6

GLONASS Ambiguity Status Flag

DF235 bit(2) 2

GLONASS Non Sync Count DF236 uint3 3

GLONASS Ionospheric Carrier Phase Correction Difference

DF237 int17 17

TOTAL 28


RT

CM

10403.2

191

Table 3.5-65 Contents of Data Block for Geometric Correction Difference Message 1038



DF038 uint6 6


DF235 bit(2) 2



DF238 int17 17


TOTAL 36

Table 3.5-66 Contents of Data Block for Combined Geometric and Ionospheric Correction Differences Message 1039



DF038 uint6 6


DF235 bit(2) 2



DF238 int17 17


GLONASS Ionospheric Carrier DF237 int17 17


RT

CM

10403.2

192


Phase Correction Difference

TOTAL 53

3.5.14 FKP Network RTK Correction Messages

With the concept of FKP (from the German word: “Flächenkorrekturparameter” = Area Correction Parameters) horizontal gradients of distance-dependent errors like ionosphere, troposphere and orbits are derived from a network of GNSS reference stations and transmitted to a rover together with raw or correction data of a corresponding reference station. The rover may use the gradients to compute the influence of the distance dependent errors for its own position. It can be used as a stand-alone technique or in combination with a non-physical reference station. The gradient message thus can be used as follows:

In connection with a physical reference station the gradients are applicable in the neighborhood of the physical station. In connection with a non-physical reference station the gradient messages are defined with respect to the non-physical

reference station, so that the gradients are applicable in the neighborhood of the non-physical station. The horizontal gradients serve as a first order approximation of the geometric and ionospheric errors for rovers that are located apart or moving away from the non-physical or physical reference station position. Tables 3.5-67 and 3.5-69 define the headers for the GPS and GLONASS FKP Gradient messages, respectively, and Tables 3.5-68 and 3.5-70 define the satellite specific data. Network FKP gradient information should be typically transmitted every 10-60 seconds. The horizontal gradients (FKP) are a linear approximation of the geometric and ionospheric errors in the neighborhood of the physical or virtual reference station. The geometric gradient contains non-dispersive (orbit and troposphere residual) errors while the ionospheric gradient contains the dispersive errors. The horizontal gradients are defined on a surface parallel to the ellipsoid at the height of the physical or non-physical reference station. Hence, troposphere effects caused by differences in station heights and station location must be corrected before computation of the geometric gradient by using a standard troposphere model. The following relations shall be used to apply the gradient corrections. The geographical coordinates R and R are the ellipsoidal coordinates of the corresponding reference station and the rover has the coordinates , . The corrections are then:


RT

CM

10403.2

193

))cos()()((37.6 000 RRR EN=δρ

))cos()()((37.6 RRIRII ENH=δρ with:

N0 the gradient in north-south direction for the geometric (ionosphere free) signal in [ppm] E0 the gradient in east-west direction for the geometric (ionosphere free) signal in [ppm] NI the gradient in north-south direction for the ionospheric signal in [ppm] (influence on GPS L1 frequency) EI the gradient in east-west direction for the ionospheric signal in [ppm] (influence on GPS L1 frequency) φ, λ the ellipsoidal coordinates of the rover in radians φR, λR the ellipsoidal coordinates of the reference station in radians H H= 1 +16 (0.53 –E/π)3

E the elevation angle of the satellite at the rover position in radians δρ0 the distance dependent error for the geometric (ionosphere free) signal [m] δρI the distance dependent error for the ionospheric signal [m]

The distance dependent error

fδρ , for a carrier phase measurement Φ on a signal with frequency f can be computed in [m] by:

I0f δρf

f+δρ=δρ

2

1,

where f 1 is the GPS L1 frequency (1575.42 MHz).

The PhaseRange measurement fP of the rover is corrected by

f,ffcorr, δρP=P


RT

CM

10403.2

194

The distance dependent error fr,δρ for a Pseudorange measurement r on a signal with frequency f can be computed in [m] by

I0fr, δρf

fδρ=δρ

2

1

and the Pseudorange measurement

fPR of the rover is corrected by

fr,ffcorr, δρPR=PR

The gradient corrections are applied to the reference station data. Standard single base rover algorithm can then be utilized. No further modifications are necessary. The gradients can, for instance, be computed from three Non-Physical Reference Stations located at the reference station itself as well as at a position 1000 m north and 1000 m east on the same height. Assuming that the clocks of all three stations are identical and the carrier phase ambiguities have been resolved, the north-south respectively east-west gradients can be derived from the observation differences of the geometric and ionospheric observables between the physical or non-physical reference station and the non-physical station north respectively east. For the geometric gradient a standard troposphere model has to be applied before computing the difference. It is recommended to use the Niell mapping function and the Saastamoinen troposphere zenith delay model. However, it is noted, that the geometric gradients are not significantly affected by changes of the troposphere model, therefore it is not required to use the same model in the rover algorithm. The obtained geometric and ionospheric signal differences in millimeters can be treated as gradients in ppm. Refer to 3.5.6 GPS Network RTK Messages and 3.5.3 Antenna Description Messages for details on a Non-Physical or Computed Reference Station. Tables 3.5-67 through Table 3.5-70 describe the GPS and GLONASS FKP Network RTK message types.


RT

CM

10403.2

195

Table 3.5-67 Header Part of the GPS Network FKP Gradient Message 1034



Reference Station ID DF003 uint12 12 May be the ID of a physical or non-physical station

GPS FKP Epoch Time (TOW) DF240 uint20 20

No. of GPS Satellite Signals Processed

DF006 uint5 5

TOTAL 49

Table 3.5-68 Satellite Specific Part of the GPS Network FKP Gradient Message 1034



GPS Issue of data ephemeris (IODE)

DF071 bit(8) 8 Issue Of Data (GPS broadcast) Ephemeris to reference the geometric gradients

N0: Geometric gradient (North) DF242 int12 12

E0: Geometric gradient (East) DF243 int12 12

NI: Ionospheric gradient (North) DF244 int14 14

EI: Ionospheric gradient (East) DF245 int14 14

TOTAL 66


RT

CM

10403.2

196

Table 3.5-69 Header Part of the GLONASS Network FKP Gradient Message 1035



Reference Station ID DF003 uint12 12 May be the ID of a physical or non-physical station

GLONASS FKP Epoch Time DF241 uint17 17

No. of GLONASS Satellite Signals Processed

DF035 uint5 5

TOTAL 46

Table 3.5-70 Satellite Specific Part of the Network FKP GLONASS Gradient Message 1035



GLONASS Issue Of Data (IOD) DF392 bit(8) 8

Issue Of Data of GLONASS ephemeris to reference the geometric gradients

N0: Geometric gradient (North) DF242 int12 12

E0: Geometric gradient (East) DF243 int12 12

NI: Ionospheric gradient (North) DF244 int14 14

EI: Ionospheric gradient (East) DF245 int14 14

TOTAL 66


RT

CM

10403.2

197

3.5.15 Multiple Signal Messages

3.5.15.1 General

The Multiple Signal Message (MSM) is intended to generate GNSS receiver observables in a universal manner to meet the coming reality when more and more GNSS and their signals will be available. MSMs are designed to cover the following:

Maximum compatibility with RINEX-3 Replace legacy RTCM-3 messages (MT1001-1004 and MT1009-1012), transmitting the most essential information in a

generalized form, incorporating new signals and GNSS. Universality for all existing and future GNSS signals Compactness of presentation No ambiguity in interpretation Simplicity of generation/decoding Flexibility and scalability

The message organization is equally well suited for:

Fully deployed GNSS with each satellite transmitting the same set of signals. GNSS transition period when different satellites transmit different sets of signals.

The similar nature of the observables for each of the currently known GNSSs (both operational and planned) allows all observables for each GNSS to be presented in a universal format. The generic MSM structure is described first using generic field (MT) numbers. The definitions for each of the GNSS follows, which includes definitions for the GNSS specific fields. The MSMs are split into compact messages and full messages, similar to the current RTCM approach (e.g. 1003 and 1004, or 1011 and 1012). The proposed messages have the following intended applications:


RT

CM

10403.2

198

Message type Intended Application

MSM1 Conventional and advanced DGNSS MSM2 Conventional RTK modes MSM3 MSM4 MSM5 Storing data in a complete set of RINEX observables MSM6 RTK with extended resolution. Real time Network data streaming. MSM7 Transmission of a complete set of RINEX observations with extended

resolution

MSM2 contains only PhaseRange observables, which allows for more flexibility when working with low-bandwidth data links and/or high-rate transmissions. For example, the reference station can send MSM2 with a rate as high as possible, while from time to time inserting MSM3 or MSM4 messages to provide additionally pseudorange and carrier-to-noise ratio (CNR) data, which are usually not needed at a high rate. The key features of the messages are as follows:

Effective identification of satellites and their signals by introducing satellite and signal masks Effective bit consumption for ‘transition GNSS periods’ by introducing cell masks Effective decomposition of observables by introducing the rough/fine range concept Effective scalability of different observables by introducing observation blocks (with own internal looping) which can be

effectively inserted into or removed from message body Expressing primary observables (Pseudorange and PhaseRange) and all their components (Integer number of milliseconds,

RoughRange, FinePseudorange and FinePhaseRange) for all bands and all signals in the same units (milliseconds). In MSM it is assumed that the speed of light is c = 299,792,458 meters per second.

One of the most important data fields (DF) in MSM messages is the signal mask. It is a bitset indicating which signals from a given GNSS are available from at least one of the multitude of tracked satellites. Each bit in the signal mask is representative of a specific GNSS signal. The definition of the signal mask bits is different for each GNSS, and is provided for each GNSS separately. Some of the currently defined signals (in RINEX-3.01 definition) have been omitted to make the table clearer. There are a number of reserved bits in the signal mask, which could be used for these signals in future revisions.


RT

CM

10403.2

199

Messages MSM1 – MSM5 are standard precision messages and messages MSM6 and MSM7 are high precision messages. MSM6 and MSM7 contain the same fields as MSM4 and MSM5 respectively, but with a higher resolution.

3.5.15.2 Integration with other existing messages.

The MSMs are intended to replace the legacy RTCM-3 observation messages (MT1001-1004 and MT1009-1012). MSMs utilize a Multiple Message Bit (DF393), while legacy RTCM-3 messages utilize a Synchronous GNSS Message Flag (DF005) for similar purposes. These DFs allow epoch to be compiled independently using either MSM or legacy messages. The legacy and MSM messages are not intended to be mixed. Decoding software shall not attempt to mix data from legacy messages and MSMs. The standard does not restrict providers from sending legacy and MSM messages in the same stream, though such operation is not recommended. In the case where legacy messages and MSM are being transmitted over the same data stream, encoding software shall ensure that the intended services are achieved with either MSM or legacy messages without the need to mix observations from the different sets. The Multiple Message Bit (DF393) allows compiling a complete GNSS observation epoch when the data of the epoch is spread over sequential messages. Some of the legacy messages are intended to be used together with the MSM observation messages: Reference position MT 1005/1006, receiver/antenna identification information MT 1033, Network corrections MT 1014-1017, GNSS ephemeris data MT 1019,1020 etc. MSM is intended for the following applications:

Transmitting raw data for DGNSS/RTK applications, as well as for raw data logging for further archiving or post-processing. Transmitting raw data from both physical and non-physical reference stations; The Reference-Station Indicator (DF141), used

in MT1005 and MT1006 applies to MSM messages. Transmitting or recording of raw data from static or moving receivers. If a receiver is not static, it is suggested to first transmit

position messages for each epoch, followed by messages containing observables. Transmitting raw data for more than one GNSS at an epoch. In this case different GNSS may be controlled by the same clock,

or by independent clocks; The Single Receiver Oscillator Indicator (DF142), used in MT1005 and MT1006 is applied to MSMs as well.

Clock steering may (or may not) be applied. If for some reason clock steering is applied to each GNSS independently, then the above mentioned Receiver Oscillator Indicator (DF142) should be set to “0”, indicating different clocks, even if the original unsteered raw observables were controlled by the same clock.


RT

CM

10403.2

200

The Synchronous GNSS Message Flag (DF005) is NOT applied to MSMs. The Quarter Cycle Indicator (DF364), used in MT1005 and 1006 is NOT applied to MSMs.

3.5.15.3 Generic GNSS MSM description

3.5.15.3.1 Message Types Summary

Table 3.5-71. Message Types Table

MSM Type

Message Name No. of Bits (upper bound) Notes

MSM1 Compact GNSS Pseudoranges

169+Nsat*(10+16*Nsig) 1353 for Nsat=16, Nsig=4

Modulo 1 ms Pseudoranges for most GNSS signals. Recommended as DGNSS reference data. Only data with a steered clock should be transmitted in this message, which shall be indicated in DF411 (Clock Steering Indicator). If data from multiple GNSS are transmitted and the difference between the clocks for these GNSS systems exceeds 0.25 ms (modulo 1 second), then this message type shall not be used.

MSM2 Compact GNSS PhaseRanges


Modulo 1 ms phase-ranges for most GNSS signals. Only data with a steered clock should be transmitted in this message, which shall be indicated in DF411 (Clock Steering Indicator). If data for multiple GNSS are transmitted and the difference between the clocks for these GNSS exceeds 0.25 ms (modulo 1 second), then this message type shall not be used.


RT

CM

10403.2

201

MSM Type


MSM3 Compact GNSS Pseudoranges and PhaseRanges


Modulo 1 ms Pseudoranges and PhaseRanges for most GNSS signals. Only data with a steered clock should be transmitted in this message, which shall be indicated in DF411 (Clock Steering Indicator). If data for multiple GNSS are transmitted and the difference between the clocks for these GNSS exceeds 0.25 ms (modulo 1 second), then this message type shall not be used.

MSM4 Full GNSS Pseudoranges and PhaseRanges plus CNR


Full Pseudoranges, PhaseRanges and CNR (carrier-no-noise ratio) for most GNSS signals

MSM5

Full GNSS Pseudoranges, PhaseRanges, PhaseRangeRate and CNR


Full Pseudoranges, PhaseRanges, CNR and PhaseRangeRate for most GNSS signals. Recommended for RINEX data generation.

MSM6 Full GNSS Pseudoranges and PhaseRanges plus CNR (high resolution)


Twin of MSM4 but with higher observables resolution


RT

CM

10403.2

202

MSM Type


MSM7

Full GNSS Pseudoranges, PhaseRanges, PhaseRangeRate and CNR (high resolution)


Twin of MSM5 but with higher observables resolution

Notes:

In the table above, Nsat refers to the number of GNSS Satellites; Nsig refers to the number of different signals included in the transmitted message

The table provides an upper bound of bit consumption for what one could call a ‘complete’ GNSS constellation. Actual throughput would be lower, especially during the ‘transition period’ when not all GNSS satellites transmit all (Nsig) signals.

Specific numbers are also provided as a reference for the case of Nsat=16 and Nsig=4. Raw data without clock steering shall not be used for messages that do not transmit “The number of integer milliseconds”. MSM1, MSM2 and MSM3 shall not be used for each GNSS where the difference between the clocks for the GNSS exceeds

0.25 ms (modulo 1 second). MSM4, MSM5, MSM6 or MSM7 shall be used in these cases. The following table gives an overview of the difference between MSM message types in the sense of compactness of message

vs. availability of data


RT

CM

10403.2

203

Table 3.5.72. Contents of the MSM message types

DATA FIELD MSM1 MSM2 MSM3 MSM4 MSM5 MSM6 MSM7

The number of integer milliseconds in GNSS Satellite rough ranges

Extended Satellite Information GNSS Satellite rough ranges modulo 1 millisecond

GNSS Satellite rough Phase Range Rates GNSS signal fine Pseudoranges 1 1 GNSS signal fine PhaseRange data 1 1 GNSS signal polarity indicator Cumulative loss of continuity indicator of GNSS signal PhaseRange data

1 1

GNSS signal CNRs 1 1 GNSS signal fine Phase Range Rates

1 With extended resolution


RT

CM

10403.2

204

Notes:

Different MSMs are just different methods of packing the same data, providing that the clock-steering indicator is the same for these messages. This in particular does not require that the RoughRange be the same, but implies that the reconstructed Pseudorange and PhaseRange would be the same for a given satellite-signal on a given epoch, regardless of which specific MSM was used to encode these observables.

Data packed into MSM1-3 and MSM4-7 may differ only if clock-steering is not applied for MSM4-7. Having the same clock-steering status, the difference between the reconstructed Pseudorange, Phase Range and CNR from the

standard precision messages (MSM1-5) and the high precision messages (MSM6-7) shall differ only in resolution. GNSS PhaseRange Lock Time Indicator in high-precision messages (MSM6 and MSM7) has higher resolution and wider

range, compared to the same indicator in standard-precision messages (MSM2-5). The integer number of ambiguities applied to PhaseRange at initialization shall be the same across all MSM messages,

regardless of whether or not a steered clock is used. Complete Pseudorange, PhaseRange and PhaseRangeRate for each signal (i) of given satellite can be restored as follows:

For standard precision messages: Pseudorange(i) = c/1000 × (Nms + Rough_range/1024 + 2–24 × Fine_Pseudorange (i)), meter, PhaseRange(i) = c/1000 × (Nms + Rough_range/1024 + 2–29 × Fine_PhaseRange(i)), meter, PhaseRangeRate (i) = Rough_ PhaseRangeRate + 0.0001*Fine_ PhaseRangeRate (i), meter/sec, For high precision messages: Pseudorange(i) = c/1000 × (Nms + Rough_range/1024 + 2–29 × Fine_Pseudorange (i)), meter, PhaseRange(i) = c/1000 × (Nms + Rough_range/1024 + 2–31 × Fine_PhaseRange(i)), meter, PhaseRangeRate (i) = Rough_ PhaseRangeRate + 0.0001*Fine_ PhaseRangeRate (i), meter/sec, where c is speed of light (meter/sec).

3.5.15.3.2 Phase Alignment

Carrier phases tracked on different signal channels or modulation bands of the same frequency may differ in phase by 1/4 (e.g., GPS: P/Y-code-derived L2 phase vs. L2C-based phase) or, in some exceptional cases, by other fractional parts of a cycle. It is known that such cycle shifts may vary between different manufacturers as well as different hardware or firmware releases. In order to facilitate data processing, phases packed in MSMs have to be consistent across all satellites of a satellite system and a specific frequency within continuous MSM transmission with respect to such cycle shifts.


RT

CM

10403.2

205

The phase observations shall be shifted by the respective fraction of a cycle, either directly by the receiver or by a correction program or the MSM conversion program, prior to MSM stream generation, to align them to the reference signal. The reference signal shall be selected according to Table 3.4-73. The reference signal may or may not be tracked. Notes: 1) While aligning the GPS L2 PhaseRange encoding software shall ignore FlexPower status (when the phases of the L2S/L2L/L2X can be changed on the satellite).

Table 3.5-73 Reference Signal for Phase Alignment

System Frequency

Band Frequency

[MHz] Reference Signal (RINEX Observation

Code)

GPS

L1 1575.42 L1C L2 1227.60 L2P L5 1176.45 L5I

GLONASS

G1 1602+k*9/16 L1C G2 1246+k*7/16 L2C

GALILEO

E1 1575.42 L1B E5A 1176.45 L5I E5B 1207.140 L7I E5(A+B) 1191.795 L8I E6 1278.75 L6B

3.5.15.3.3 Lock Time Indicator

The GNSS PhaseRange Lock Time Indicator is used in MSM to indicate intervals of PhaseRange continuity and to indicate possible cycle slips, loss of lock or some other internal reinitializations. Each case of PhaseRange non-continuity shall be indicated by encoding software by resetting this Lock Time Indicator to zero.


RT

CM

10403.2

206

Table 3.5-74 GNSS PhaseRange Lock Time Indicator (DF402)

Indicator (i) Minimum Lock Time

(ms) Range of Indicated Lock Times

(t) (ms)

0 0 0 ≤ t < 32

1 32 32 ≤ t < 64

2 64 64 ≤ t < 128

3 128 128 ≤ t < 256

4 256 256 ≤ t < 512

5 512 512 ≤ t < 1024

6 1024 1024 ≤ t < 2048

7 2048 2048 ≤ t < 4096

8 4096 4096 ≤ t < 8192

9 8192 8192 ≤ t < 16384

10 16384 16384 ≤ t < 32768

11 32768 32768 ≤ t < 65536

12 65536 65536 ≤ t < 131072

13 131072 131072 ≤ t < 262144

14 262144 262144 ≤ t < 524288

15 524288 524288 ≤ t

Decoding software shall compare "Minimum Lock Time" reconstructed from "Lock Time Indicator" at the given epoch with

the one reconstructed on the previous epoch. If "Minimum Lock Time" at the given epoch is smaller than the one at the previous epoch, it is an indication that PhaseRange experienced some discontinuity, which caused Lock Time Indicator to be reset to zero. At the same time, if the reconstructed "Minimum Lock Time" at a given epoch is the same or larger than at the previous epoch, it does not necessarily guarantee continuous tracking between two epochs. Some values may clearly indicate Loss Of Continuity (LOC), some values may indicate "potential LOC", some values may indicate "Continuous Tracking",


RT

CM

10403.2

207

while some values may indicate defect in encoding software. The following algorithm for detecting LOC is suggested (though it neglects the possibility of an error in encoding software).

Loss of lock detection: p = Minimum Lock Time in milliseconds, as reconstructed at previous epoch n = Minimum Lock Time in milliseconds, as reconstructed at current epoch dt = Time Interval in milliseconds between current epoch and previous epoch

if (p > n) LOC if (p = n) and (dt ≥ p) LOC if (p = n) and (dt < p) ok, tracking was continuous if (p < n) and (dt ≥ (2n-p)) LOC if (p < n) and (n < dt < (2n-p)) LOC (possible) if (p < n) and (dt ≤ n) ok, tracking was continuous

For High precision messages (MSM6 and MSM7) the GNSS PhaseRange Lock Time Indicator with extended range and

resolution is used. It has the same meaning, but due to higher resolution and range ensures higher confidence with less uncertainty. When reliable LOC detection is not possible, the decoding software has to assume a discontinuity in PhaseRange even when potentially tracking could have been continuous).

Table 3.5-75 GNSS PhaseRange Lock Time Indicator with extended range and resolution (DF407)

Indicator (i) Supplementary coefficient (k)

Minimum Lock Time (ms) Range of Indicated Lock

Times (t) (ms)

0 – 63 1 i 0 ≤ t < 64

64 – 95 2 2 • i – 64 64 ≤ t < 128

96 – 127 4 4 • i – 256 128 ≤ t < 256

128 – 159 8 8 • i – 768 256 ≤ t < 512

160 – 191 16 16 • i – 2048 512 ≤ t < 1024


RT

CM

10403.2

208

Indicator (i) Supplementary coefficient (k)

Minimum Lock Time (ms) Range of Indicated Lock

Times (t) (ms)

192 – 223 32 32 • i – 5120 1024 ≤ t < 2048

224 – 255 64 64 • i – 12288 2048 ≤ t < 4096

256 – 287 128 128 • i – 28672 4096 ≤ t < 8192

288 – 319 256 256 • i – 65536 8192 ≤ t < 16384

320 – 351 512 512 • i – 147456 16384 ≤ t < 32768

352 – 383 1024 1024 • i – 327680 32768 ≤ t < 65536

384 – 415 2048 2048 • i – 720896 65536 ≤ t < 131072

416 – 447 4096 4096 • i – 1572864 131072 ≤ t < 262144

448 – 479 8192 8192 • i – 3407872 262144 ≤ t < 524288

480 – 511 16384 16384 • i – 7340032 524288 ≤ t < 1048576

512 – 543 32768 32768 • i – 15728640 1048576 ≤ t < 2097152

544 – 575 65536 65536 • i – 33554432 2097152 ≤ t < 4194304

576 – 607 131072 131072 • i – 71303168 4194304 ≤ t < 8388608

608 – 639 262144 262144 • i – 150994944 8388608 ≤ t < 16777216

640 – 671 524288 524288 • i – 318767104 16777216 ≤ t < 33554432

672 – 703 1048576 1048576 • i – 671088640 33554432 ≤ t < 67108864

704 2097152 2097152 • i – 1409286144 67108864 ≤ t

705 – 1023 Reserved

For "Lock Time Indicator with extended range and resolution" the following algorithm for detecting Loss of Lock is

suggested:

Loss of lock detection: p = Minimum Lock Time in milliseconds, as reconstructed at previous epoch n = Minimum Lock Time in milliseconds, as reconstructed at current epoch


RT

CM

10403.2

209

a = Supplementary Coefficient, as reconstructed at previous epoch b = Supplementary Coefficient, as reconstructed at current epoch dt = Time Interval in milliseconds between current epoch and previous epoch (Some combinations of (p,n,dt) are not possible. The algorithms provided below do not explicitly check for such inconsistencies.)

if (p > n) LOC if (p = n) and (dt ≥ a) LOC if (p = n) and (dt < a) ok, tracking was continuous if (p < n) and (b > p) and (dt ≥ (n+b-p)) LOC if (p < n) and (b > p) and (n < dt < (n+b-p)) LOC (possible) if (p < n) and (b > p) and (dt ≤ n) ok, tracking was continuous if (p < n) and (b ≤ p) and (dt > n) LOC if (p < n) and (b ≤ p) and (dt ≤ n) ok, tracking was continuous

Table 3.5-76 Computing GNSS PhaseRange Lock Time Indicator from actual Lock Time (DF407)

Range of Indicated Lock Times (t) (ms)

Indicator (i) computation from Lock Time (t)

0 ≤ t < 64 t

64 ≤ t < 128 64 + (t – 64) / 2

128 ≤ t < 256 96 + (t – 128) / 4

256 ≤ t < 512 128 + (t – 256) / 8

512 ≤ t < 1024 160 + (t – 512) / 16

1024 ≤ t < 2048 192 + (t – 1024) / 32

2048 ≤ t < 4096 224 + (t – 2048) / 64


RT

CM

10403.2

210

Range of Indicated Lock Times (t) (ms)

Indicator (i) computation from Lock Time (t)

4096 ≤ t < 8192 256 + (t – 4096) / 128

8192 ≤ t < 16384 288 + (t – 8192) / 256

16384 ≤ t < 32768 320 + (t – 16384) / 512

32768 ≤ t < 65536 352 + (t – 32768) / 1024

65536 ≤ t < 131072 384 + (t – 65536) / 2048

131072 ≤ t < 262144 416 + (t – 131072) / 4096

262144 ≤ t < 524288 448 + (t – 262144) / 8192

524288 ≤ t < 1048576 480 + (t – 524288) / 16384

1048576 ≤ t < 2097152 512 + (t – 1048576) / 32768

2097152 ≤ t < 4194304 544 + (t – 2097152) / 65536

4194304 ≤ t < 8388608 576 + (t – 4194304) / 131072

8388608 ≤ t < 16777216 608 + (t – 8388608) / 262144

16777216 ≤ t < 33554432 640 + (t – 16777216) / 524288

33554432 ≤ t < 67108864 672 + (t – 33554432) / 1048576

67108864 ≤ t 704

For Lock Time Indicator with extended range and resolution (DF407) one may use the following algorithms to compute this indicator based on actual tracking time: // Input : t - Tracking Time in [ms] // Output: i - Lock Time Indicator DF407 uint32 GetIndex( uint32 t )


RT

CM

10403.2

211

{ if( 0 <= t && t < 64 ) return ( t ); if( 64 <= t && t < 128 ) return ( 64 + (t-64 )/2 ); if( 128 <= t && t < 256 ) return ( 96 + (t-128 )/4 ); if( 256 <= t && t < 512 ) return (128 + (t-256 )/8 ); if( 512 <= t && t < 1024 ) return (160 + (t-512 )/16 ); if( 1024 <= t && t < 2048 ) return (192 + (t-1024 )/32 ); if( 2048 <= t && t < 4096 ) return (224 + (t-2048 )/64 ); if( 4096 <= t && t < 8192 ) return (256 + (t-4096 )/128 ); if( 8192 <= t && t < 16384 ) return (288 + (t-8192 )/256 ); if( 16384 <= t && t < 32768 ) return (320 + (t-16384 )/512 ); if( 32768 <= t && t < 65536 ) return (352 + (t-32768 )/1024 ); if( 65536 <= t && t < 131072 ) return (384 + (t-65536 )/2048 ); if( 131072 <= t && t < 262144 ) return (416 + (t-131072 )/4096 ); if( 262144 <= t && t < 524288 ) return (448 + (t-262144 )/8192 ); if( 524288 <= t && t < 1048576 ) return (480 + (t-524288 )/16384 ); if( 1048576 <= t && t < 2097152 ) return (512 + (t-1048576 )/32768 ); if( 2097152 <= t && t < 4194304 ) return (544 + (t-2097152 )/65536 ); if( 4194304 <= t && t < 8388608 ) return (576 + (t-4194304 )/131072 ); if( 8388608 <= t && t < 16777216 ) return (608 + (t-8388608 )/262144 ); if( 16777216 <= t && t < 33554432 ) return (640 + (t-16777216)/524288 ); if( 33554432 <= t && t < 67108864 ) return (672 + (t-33554432)/1048576); if( 67108864 <= t ) return (704 ); return 1023; // will never happen }

3.5.15.3.4 General Message Structure

Each MSM consists of 3 blocks:


RT

CM

10403.2

212

Table 3.5-77 Content of an MSM message, and sequence of blocks

Block type Comment

Message Header Contains all information about satellites and signals that are transmitted in this message

Satellite Data Contains all satellite data that is common for all signals of a given satellite (e.g. Rough Range)

Signal Data Contains all signal data that is specific for each signal (e.g. Fine PhaseRange)

All data fields are grouped by data type, rather than by satellite or signal. That is, if more than one data field is transmitted in a Satellite Data block then the first data field for all available satellites is packed, followed by the second data field for all available satellites, etc. Similarly, if more than one Signal Data field is to be transmitted then the first data field for each available satellite/signal combination is packed, followed by the second data field, again for each available satellite and signal. This packing order is called “internal looping”. The standard reserves a possibility for potential future MSM extensions. These extensions may be introduced by adding data to the end of a message. This flexibility leads to the following considerations:

Actual message length (as decoded from message header) may not match (may be greater than) the minimal required message length (as computed based upon the message contents).

Decoding software shall skip (ignore) any unexpected data at the end of the message. The presence of such extra data shall be considered as normal and shall not result in raising warning flag.

Encoding software shall NOT use this expansion feature for proprietary data. Nor shall an encoder add any extra information to the end of an MSM.


RT

CM

10403.2

213

3.5.15.3.5 Message Header Description

Table 3.5-78 Content of message header for MSM1, MSM2, MSM3, MSM4, MSM5, MSM6 and MSM7

DATA FIELD DF NUMBER DATA TYPE

NO. OF BITS NOTES

Message number DF002 uint12 12

Reference station ID DF003 uint12 12

GNSS Epoch Time Specific for each GNSS uint30 30 Specific for each GNSS

Multiple Message Bit DF393 bit(1) 1

IODS – Issue of Data Station DF409 uint3 3

Reserved DF001 bit(7) 7 Reserved (may be GNSS specific)

Clock Steering Indicator DF411 uint2 2

External Clock Indicator DF412 uint2 2

GNSS Divergence-free Smoothing Indicator

DF417 bit(1) 1

GNSS Smoothing Interval DF418 bit(3) 3

GNSS Satellite Mask DF394 bit(64) 64 Specific for each GNSS

GNSS Signal Mask DF395 bit(32) 32 Specific for each GNSS

GNSS Cell Mask DF396 bit(X) X (X≤64)

TOTAL 169+X

Notes:

The size of the cell mask is not fixed, but is determined after decoding the satellite and signal masks. The size of cell mask is X=Nsat*Nsig, where Nsat is the number of satellites (the number of bits, which are set to 1 in satellite mask), and Nsig is the


RT

CM

10403.2

214

number of Signals (the number of bits, which are set to 1 in signal mask). The limit X≤64 is selected to guarantee the full size of MSM7 (the largest MSM) fits into a single RTCM-3 transport frame.

Preliminary estimates of the full size of MSM7 under an X≤64 condition do not exceed 5865 bits, which is about half of the maximum permissible size for any RTCM-3 message.

In most real time applications, data to be transmitted will fit the limit of X≤64 (e.g. Nsat≤16, Nsig≤4), therefore all data for a given GNSS should be able to be generated within a single RTCM-3 transmission most of the time.

In case where there are many satellites and signals for a given GNSS, it is the responsibility of the encoding software to ensure that the “X≤64” rule by dividing the complete observation set among several messages. For example, if Nsat=14 and Nsig=6 (i.e. up to 14*6=84 observables), then the encoding software must use 2 separate transmissions, e.g.:

The first for 7 Satellites and 6 signals The second for the remaining 7 Satellites and 6 signals

In this case, the multiple message bit must be set accordingly. For more details, see section “Multiple MSM output” below. The example of construction and interpretation of satellite, signal and cell masks is given in section ‘Message Examples’

3.5.15.3.6 Satellite Data Description

Satellite Data is transmitted only for those satellites for which the corresponding bit is set to 1 in Satellite Mask (DF394). Thus, in the tables below, Nsat refers to the number of satellites, i.e. the number of bits set to 1 in the Satellite Mask. Each data field is repeated Nsat times (internal looping is used). The order of looped data corresponds to the order of bits in the Satellite Mask.

Table 3.5-79 Content of Satellite data for MSM1, MSM2, MSM3


GNSS Satellite rough ranges modulo 1 millisecond

DF398 uint10 (Nsat times)

10*Nsat

TOTAL 10*Nsat


RT

CM

10403.2

215

Table 3.5-80 Content of Satellite data for MSM4 and MSM6




8*Nsat



10*Nsat

TOTAL 18*Nsat

Table 3.5-81 Content of Satellite data for MSM5 and MSM7




8*Nsat

Extended Satellite Information

Specific for each GNSS

uint4 4*Nsat Specific for each GNSS



10*Nsat

GNSS Satellite rough PhaseRangeRates

DF399 int14 (Nsat times)

14*Nsat

TOTAL 36*Nsat


RT

CM

10403.2

216

3.5.15.3.7 Message Types Signal data description

Signal data is transmitted only for those signal-satellite combinations, for which the corresponding bit is set to 1 in Cell Mask (DF396). Thus, in the tables below, Ncell refers to the number of signal data blocks, i.e. the number of bits set to 1 in the Cell Mask. Each data field is repeated Ncell times (internal looping is used). The order of the looped data corresponds to the order of bits in the Cell Mask.

Table 3.5-82 Content of Signal data for MSM1


GNSS signal fine Pseudoranges

DF400 int15 (Ncell times)

15*Ncell

TOTAL 15*Ncell



GNSS signal fine PhaseRange data


22*Ncell

GNSS PhaseRange Lock Time Indicator

DF402 uint4 (Ncell times)

4*Ncell

Half-cycle ambiguity indicator

DF420 bit(1) 1*Ncell

TOTAL 27*Ncell


RT

CM

10403.2

217





15*Ncell



22*Ncell



4*Ncell



TOTAL 42*Ncell





15*Ncell



22*Ncell



4*Ncell



GNSS signal CNRs DF403 uint6 (Ncell times)

6*Ncell

TOTAL 48*Ncell


RT

CM

10403.2

218





15*Ncell



22*Ncell



4*Ncell



GNSS signal CNRs DF403 uint6 (Ncell times)

6*Ncell

GNSS signal fine PhaseRangeRates


15*Ncell

TOTAL 63*Ncell


RT

CM

10403.2

219



GNSS signal fine Pseudoranges with extended resolution


20*Ncell



24*Ncell



10*Ncell



GNSS signal CNRs with extended resolution


10*Ncell

TOTAL 65*Ncell


RT

CM

10403.2

220



GNSS signal fine Pseudoranges with extended resolution


20*Ncell



24*Ncell



10*Ncell



GNSS signal CNRs with extended resolution


10*Ncell

GNSS signal fine PhaseRangeRates


15*Ncell

TOTAL 80*Ncell

3.5.15.3.8 Multiple MSM output

Multiple MSM messages may be transmitted for a given physical epoch. In order to indicate the “End of Epoch” DF393 (MSM Multiple Message Bit) has been introduced. This DF is the same for all GNSS and should be set to 1 if more MSM for same or another GNSS follows for given physical epoch and given Reference Station ID.


RT

CM

10403.2

221

In order to effectively utilize this bit, the decoding software should be aware of all possible GNSS transmitted in the stream. Since new MSM messages for more GNSS are expected to be designed in the future, the following message range is reserved exclusively for MSM

MT1070 – MT1229 It is guaranteed that 55-th bit (counting from one) represents MSM Multiple Message Bit in messages MTxxx1, MTxxx2, MTxxx3, MTxxx4, MTxxx5, MTxxx6 and MTxxx7 from the above mentioned range of messages. This enables the decoding software to detect the end of epoch without knowledge of the content or format of any new MSM for new GNSS.

DATA FIELD DF NUMBER DATA TYPE

NO. OF BITS NOTES

Message number DF002 12

12

30

Multiple Message Bit DF393 Bit(1) 1

The rest of the message…

Each MSM has two size limitations:

The size of Cell Mask is limited to 64 bits The size of entire message is limited to 1023 bytes

Both of these limitations may be potentially reached. If at least one of the limitations is reached then a provider shall split the MSM message for the given GNSS into a set of two or more sequential, complementary messages, with proper care of the Multiple Message Bit.


RT

CM

10403.2

222

The standard does not put any restrictions on message splitting. Generally, splitting on satellite-by-satellite basis is the most effective way of splitting, because it does not require duplication of RoughRange (i.e. DF397, DF398). At the same time, in case of severe divergence of Pseudorange observables for the same satellite (due to receiver or satellite hardware bias or due to any other cause), DF-range for Fine Pseudorange may be insufficient to pack all Pseudorange observables. In this case encoding software should choose either not to output Pseudorange for some signals on a given epoch, or transmit them in a separate MSM message. Having a priory information about large bias between Pseudorange on different signals for given GNSS, encoding software may choose to consider the less efficient (in terms of bandwidth) signal-by-signal MSM splitting.

3.5.15.4 GPS Messages Description

For GPS all seven MSM are introduced.


Table 3.5-89 GPS Message Types

Message Type

Message Name MSM type

1071 Compact GPS Pseudoranges MSM1

1072 Compact GPS PhaseRanges MSM2

1073 Compact GPS Pseudoranges and PhaseRanges MSM3

1074 Full GPS Pseudoranges and PhaseRanges plus CNR MSM4

1075 Full GPS Pseudoranges, PhaseRanges, PhaseRangeRate and CNR MSM5

1076 Full GPS Pseudoranges and PhaseRanges plus CNR (high resolution) MSM6


RT

CM

10403.2

223

Message Type


1077 Full GPS Pseudoranges, PhaseRanges, PhaseRangeRate and CNR (high resolution) MSM7

3.5.15.4.2 GPS Specific Data Fields

For GPS satellites the following clarifications apply:

GPS Epoch Time (TOW) DF004 is used for GNSS Epoch Time. Actual PRNs are mapped to satellite mask IDs according to Table 3.5-90 Actual GPS signals are mapped to signal mask IDs according to Table 3.5-91 Extended satellite information is reserved for future use.

Table 3.5-90 GPS Satellite ID mapping

Satellite ID in Satellite Mask (DF394)

GPS Satellite PRN

1 1

2 2

… …

63 63

64 Reserved


RT

CM

10403.2

224

Table 3.5-91 GPS Signal ID mapping

Signal ID in Signal Mask

(DF395)

Frequency Band

Signal GPS signal

RINEX code Comments/Notes

1 Reserved 2 L1 C/A 1C 3 L1 P 1P 4 L1 Z-tracking or

similar 1W

5-7 Reserved 8 L2 C/A 2C 9 L2 P 2P 10 L2 Z-tracking or

similar 2W

11-14 Reserved 15 L2 L2C(M) 2S 16 L2 L2C(L) 2L 17 L2 L2C(M+L) 2X 18-21 Reserved 22 L5 I 5I 23 L5 Q 5Q 24 L5 I+Q 5X 25-29 Reserved 30 L1 L1C-D

31 L1 L1C-P

32 L1 L1C-(D+P)

Notes:

For legacy messages DF016 provided information about signal type. The following table determines matching between DF016 and GPS signal mask for MSM


RT

CM

10403.2

225

Table 3.5-92 Matching between DF016 and GPS MSM Signal ID

DF016 GPS MSM signal ID

0 8 (L2C) or 15 (L2S) or 16 (L2L) or 17 (L2X) 1 9 (L2P) 2 10 (L2W) 3 10 (L2W)

3.5.15.5 GLONASS Messages Description

For GLONASS all seven MSM messages and a GLONASS L1 and L2 Code-Phase Bias Message are introduced.


Table 3.5-93 GLONASS Message Types

Message Type


1081 Compact GLONASS Pseudoranges MSM1

1082 Compact GLONASS PhaseRanges MSM2

1083 Compact GLONASS Pseudoranges and PhaseRanges MSM3

1084 Full GLONASS Pseudoranges and PhaseRanges plus CNR MSM4

1085 Full GLONASS Pseudoranges, PhaseRanges, PhaseRangeRate and CNR MSM5


RT

CM

10403.2

226

Message Type


1086 Full GLONASS Pseudoranges and PhaseRanges plus CNR (high resolution) MSM6

1087 Full GLONASS Pseudoranges, PhaseRanges, PhaseRangeRate and CNR (high resolution)

MSM7

3.5.15.5.2 GLONAS Specific Data Fields

For GLONASS satellites the following clarifications apply:

GNSS Epoch Time for GLONASS MSMs is a composite field as presented in the table below.

Table 3.5-95 GNSS Time for GLONASS MSMs


GLONASS Day Of Week DF416 int3 3

GLONASS Epoch Time DF034 uint27 27

Actual GLONASS slot numbers are mapped to Satellite Mask IDs according to Table 3.5-96 Actual GLONASS signals are mapped to Signal Mask IDs according to Table 3.5-97 GLONASS Satellite Frequency Channel Number (DF419) is used as extended satellite information in the header of MSM5

and MSM7


RT

CM

10403.2

227

Table 3.5-96 GLONASS Satellite ID mapping


GLONASS Satellite slot number

1 1

2 2

… …

24 24

25–64 Reserved

Table 3.5-97 GLONASS Signal ID mapping


(DF395)

Frequency Band

Signal GLONASS

signal RINEX code

Comment/Notes

1 Reserved 2 G1 C/A 1C

3 G1 P 1P

4-7 Reserved 8 G2 C/A 2C

9 G2 P 2P

10-32 Reserved

Notes:

In MSM1, MSM2 and MSM3 the number of integer milliseconds in the GNSS Satellite Rough Range (DF379) is not transmitted. For odd frequency channel numbers, 1 millisecond does not contain integer number of GLONASS wavelengths. The decoding software shall not utilize GLONASS PhaseRange without restoring the number of integer milliseconds in GNSS Satellite rough range, as it may introduce half cycle error.


RT

CM

10403.2

228

3.5.15.6 GALILEO Messages Description

For GALILEO all seven MSM messages are introduced.


Table 3.5-98 GALILEO Message Types

Message Type


1091 Compact GALILEO Pseudoranges MSM1

1092 Compact GALILEO PhaseRanges MSM2

1093 Compact GALILEO Pseudoranges and PhaseRanges MSM3

1094 Full GALILEO Pseudoranges and PhaseRanges plus CNR MSM4

1095 Full GALILEO Pseudoranges, PhaseRanges, PhaseRangeRate and CNR MSM5

1096 Full GALILEO Pseudoranges and PhaseRanges plus CNR (high resolution) MSM6

1097 Full GALILEO Pseudoranges, PhaseRanges, PhaseRangeRate and CNR (high resolution)

MSM7


RT

CM

10403.2

229

3.5.15.6.2 GALILEO Specific Data Fields

For GALILEO satellites the following clarifications apply:

GALILEO Epoch Time (TOW) DF248 is used for GNSS epoch time. Actual PRNs are mapped to satellite mask IDs according to Table 3.5-99 Actual GALILEO signals are mapped to signal mask IDs according to Table 3.5-100 Extended satellite information is reserved for future use

Table 3.5-99 GALILEO Satellite ID mapping


GALILEO Satellite PRN

1 1

2 2

… …

50 50

51 GIOVE-A

52 GIOVE-B

53–64 Reserved


RT

CM

10403.2

230

Table 3.5-100 GALILEO Signal ID mapping


(DF395)

Frequency Band

Signal GALILEO

signal RINEX code

Comments/Notes

1 Reserved 2 E1 C no data 1C 3 E1 A 1A 4 E1 B I/NAV

OS/CS/SoL1B

5 E1 B+C 1X 6 E1 A+B+C 1Z 7 Reserved 8 E6 C 6C 9 E6 A 6A 10 E6 B 6B 11 E6 B+C 6X 12 E6 A+B+C 6Z 13 Reserved 14 E5B I 7I 15 E5B Q 7Q 16 E5B I+Q 7X 17 Reserved 18 E5(A+B) I 8I 19 E5(A+B) Q 8Q 20 E5(A+B) I+Q 8X 21 Reserved 22 E5A I 5I 23 E5A Q 5Q 24 E5A I+Q 5X 25–32 Reserved


RT

CM

10403.2

231

3.5.16 GLONASS Bias Information Messages

In general, GLONASS Pseudorange and PhaseRange measurements can be affected by different receiver-dependent biases. An offset of this so-called code-phase bias (CPB) between the reference and rover receivers will manifest as frequency-dependent biases in the corresponding GLONASS double-difference PhaseRange measurements. The magnitude of these inter-frequency biases may adversely affect ambiguity resolution, especially when 3rd party reference receivers are involved. This message provides information which is intended to compensate for the first-order inter-frequency PhaseRange biases introduced by the reference receiver CPB. Higher order frequency-dependent biases may still be present in the reference PhaseRange data; however, the magnitude of this class of bias is typically insignificant for ambiguity resolution.

Table 3.5-101 Contents of GLONASS L1 and L2 Code-Phase Biases Message 1230

DATA FIELD DF

NUMBER DATA TYPE

NO. OF BITS NOTES

Message Number DF002 uint12 12 Reference Station ID DF003 uint12 12 GLONASS Code-Phase bias indicator

DF421 bit(1) 1

Reserved DF001 bit(3) 3 ReservedGLONASS FDMA signals mask DF422 bit(4) 4 GLONASS L1 C/A Code-Phase Bias

DF423 int16 16

GLONASS L1 P Code-Phase Bias

DF424 int16 16

GLONASS L2 C/A Code-Phase Bias

DF425 int16 16

GLONASS L2 P Code-Phase Bias

DF426 int16 16

TOTAL 32+16*N N corresponds to the number of bits set to 1 in DF422.


RT

CM

10403.2

232

Notes:

MT1230 with valid CPB values for all GLONASS FDMA signals available in the data stream (MT1009-1012 and MT1081-1088) is mandatory for full GLONASS and combined GPS/GLONASS RTK interoperability, including GLONASS and combined GPS/GLONASS network RTK services. For example, if reference station broadcasts GLONASS observables related to GLONASS L1 C/A and GLONASS L2 C/A signals, MT1230 shall include DF423 and DF425. MT1230 may include information about greater number of GLONASS FDMA signals than those available in the data stream that includes GLONASS observables.

To provide a full GLONASS RTK service that is also backwards compatible with GLONASS observable messages 1009-1012 and proprietary methods of processing the content of those messages, the encoder shall not apply the contents of MT1230 to GLONASS observation data a priori, if MT1230 is broadcast in the data stream that includes MT 1009-1012.

Transmitted Configuration

Any of 1081-1087 Any of 1009-1012 DF421

MSM only Transmitted Not transmitted Can be 0 or 1 Legacy only Not transmitted Transmitted Shall always be 0 MSM + Legacy Transmitted Transmitted Shall always be 0

The content of message 1033 is commonly used in practice by the decoder to first identify and then compensate for the

expected GLONASS receiver-dependent biases present in observation messages 1009-1012. Although this method has proven relatively reliable, 1033 was not developed specifically for this purpose and has several limitations. Message 1230 has been developed to improve GLONASS interoperability. Therefore, if a data stream contains both messages 1230 and 1033 then the content of 1230 takes precedence over the expected GLONASS receiver biases indicated by the receiver description in 1033.

For MAC Network RTK services, MT 1230 defines Code-Phase Biases related to the Master Reference Station. Therefore, the

content of DF003 (Reference Station ID) in MT 1230 shall correspond to the content of DF060 (Master Reference Station ID).

GLONASS Code-Phase Biases are transmitted only for those GLONASS FDMA signals, for which the corresponding bit is set to 1 in GLONASS FDMA Signals Mask (DF422).


RT

CM

10403.2

233

The standard reserves a possibility for potential future MT1230 extensions. These extensions may be introduced by adding data to the end of the message.

3.6 Proprietary Messages

The 95 message types from 4001 through 4095 are reserved for proprietary use. Each company or organizationmay beassigned by RTCM one message type for proprietary use. The format is similar to the other messages, in that thetransportlayerisdefinedinthesameway,andthefirstdatafieldisa12‐bitmessagenumber.Eachcompanyisfreetodefineseveralsub‐typesofmessages,buttheymustallutilizetheassignedmessagetype. At the time of printing, the following Proprietary Message types have been assigned. Contact RTCM to acquire a new message type.

Table 3.6-1 Assigned Proprietary Message Types

Message Type Organization Contact

4095 Ashtech http://www.ashtech.com

4094 Trimble Navigation Ltd. http://www.trimble.com

4093 NovAtel Inc. http://www.novatel.ca

4092 Leica Geosystems http://www.leica-geosystems.com

4091 Topcon Positioning Systems http://www.topconpositioning.com

4090 Geo++ http://www.geopp.de/

4089 Septentrio Satellite Navigation http://www.septentrio.com

4088 IfEN GmbH http://www.ifen.com

4087 Fugro http://www.fugro.com

4086 inPosition GmbH http://www.inposition.ch


RT

CM

10403.2

234

Message Type Organization Contact

4085 European GNSS Supervisory Authority http://www.gsa.europa.eu

4084 Geodetics, Inc. http://www.geodetics.com

4083 German Aerospace Center, Institute of Communications and Navigation (DLR)

http://www.dlr.de/kn/en/desktopdefault.aspx/tabid-2204/3257_read-19445/

4082 Cooperative Research Centre for Spatial Information

http://www.crcsi.com.au

4081 Seoul National University GNSS Lab http://gnss.snu.ac.kr/nav/

4080 NavCom Technology, Inc. http://navcomtech.com

4079-4001 RESERVED


RTCM 10403.2

235

4 TRANSPORT LAYER 4.1 Description

The transport layer defines the frame architecture for sending or receiving Version 3 messages. The purpose of defining this layer is to ensure that Version 3 data can be properly decoded by applications. The frame is mandatory from this respect but it is not required throughout the transmission of the data. Providers may package the messages into a separate frame structure that best suits the transmission medium. The data set would need to have this frame structure re-established before transfer to the application. For high-integrity applications, it would be up to the provider to demonstrate that adequate integrity is maintained in the process of disassembling and reassembling the transport layer frame structure. The basic frame structure consists of a fixed preamble, a message length definition, a message, and a 24-bit Cyclic Redundancy Check (CRC) for high data transfer integrity. The structure of the frame format is shown in Table 4-1.

Table 4-1 Version 3 Frame Structure

Preamble Reserved Message Length Variable Length Data Message

CRC

8 bits 6 bits 10 bits Variable length, integer number of bytes

24 bits

11010011 Not defined – set to 000000

Message length in bytes 0-1023 bytes QualComm definition CRC-24Q

The Preamble is a fixed 8-bit sequence. The next six bits are reserved and should be set to zero by the Transport Layer Control for all messages. The mobile user receiver should ignore these bits and not assume they will always be set to zero. In future versions these bits may contain the version number of the standard. The Variable Length Messages are those defined in Chapter 3. If the data link requires short messages in order to maintain a continuous stream of data, the message length may be set to "0", providing a "filler" message of 48 bits in length, because the data message length will be zero. This standard uses the QualComm CRC algorithm. Twenty-four bits of CRC parity will provide protection against burst as well as random errors with a probability of undetected error

2-24 = 5.9610-8 for all channel bit error probabilities 0.5. The CRC operates on the sequence of bits beginning with the preamble, through to the end of the Variable Length Message Field, using a seed of 0. The sequence of 24 bits (p1,p2,...,p24) is generated from the sequence of information bits (m1,m2,...,m8N), where N is the total number of bytes in the sequence consisting of the message plus

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

236

preamble and Message Length Definition Parameter. This is accomplished by means of a code that is generated by the polynomial

where = 1 for i = 0, 1, 3, 4, 5, 6, 7, 10, 11, 14, 17, 18, 23, 24

= 0 otherwise

This code is called CRC-24Q (Q for Qualcomm Corporation). The generator polynomial of this code is in the following form (using binary polynomial algebra):

X 1 X p X

where p(X) is the primitive and irreducible polynomial

1

When, by the application of binary polynomial algebra, the above g(X) is divided into m(X)X24, where the information sequence m(X) is expressed as

m(X) = mk + mk-1X + mk-2X2 + . . . + m1X

k-1

the result is a quotient and a remainder R(X) of degree < 24. The bit sequence formed by this remainder represents the parity check sequence. Parity bit pi, for any i from 1 to 24, is the coefficient of X24-i in R(X).

This code has the following characteristics:

1) It detects all single bit errors per code word.

2) It detects all double bit error combinations in a codeword because the generator polynomial g(X) has a factor of at least three terms.

3) It detects any odd number of errors because g(X) contains a factor 1+X.

4) It detects any burst error for which the length of the burst is 24 bits.

5) It detects most large error bursts with length greater than the parity length r = 24 bits. The fraction of error bursts of length b > 24 that are undetected is:

a) 2-24 = 5.96 10-8, if b > 25 bits. b) 2-23 = 1.19 10-7, if b = 25 bits.

As noted earlier, the reference station should insert zero’s in all reserved fields, and for messages whose lengths that don’t line up with byte boundaries, zero’s should be used for undefined bits to fill out the last unfilled byte.

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

237

4.2 Example

The following is a Hex-ASCII example of a message type 1005 (Stationary Antenna Reference Point, No Height Information). D3 00 13 3E D7 D3 02 02 98 0E DE EF 34 B4 BD 62 AC 09 41 98 6F 33 36 0B 98 The parameters for this message are:

Reference Station Id = 2003 GPS Service supported, but not GLONASS or Galileo ARP ECEF-X = 1114104.5999 meters ARP ECEF-Y = -4850729.7108 meters ARP ECEF-Z = 3975521.4643 meters

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

239

5 DATA LINK LAYER The Data Link Layer defines how the RTCM 10403 message data stream is encoded on the Physical Layer. This may also include flow control, packetization, encryption, or additional error checking. It is up to the service provider to determine how to define this layer as appropriate to the application.

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

241

6 PHYSICAL LAYER The Physical Layer defines how the RTCM 10403 message data is conveyed at the electrical and mechanical level – e.g.: beacons, MSK; UHF, VHF Modems; DARC FM Subcarrier, Satellite links, fixed cable. It is up to the service provider to determine how to define this layer as appropriate to the application.

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

A-1

APPENDIX A. SUGGESTIONS AND EXAMPLES FOR NETWORK OPERATION

The following two sections provide additional guidance and information for Vendors, Service Providers and Mobile Users. Appendix A.1 provides guidance to Service Providers on the selection of master and auxiliary stations, and to Users on how to best use the information in the messages. Appendix A.2 provides a scheduling example that demonstrates one method of utilizing the Synchronous Message Flags and Multiple Message Indicators to support operation with multiple GNSS’s. A.1 How to Use Network ID’s and Subnetwork ID’s Figure A.1-1 gives an example of a network containing 23 reference stations identified by Network ID. In general the network will consist of only one subnetwork identified by Subnetwork ID. Every one of these 23 reference stations can be used as a Master Reference Station and all reference stations within a certain range around the Master Reference Station might be used as Auxiliary Reference Stations. The figure shows 3 different Master Reference Stations (11 <red>, 14 <blue>, and 17 <purple>) and associated radii. The radii are defining in the example the range holding all associated Auxiliary Reference Stations for the designated Master Reference Station. However other ways of selecting Auxiliary Reference Stations for a designated Master Reference Station are possible and the selection process might have to be adapted to the specific environment of the permanent networking application. Master Reference Station M11 has the Auxiliary Reference Stations A1, A2, A5, A6, A7, A8, A12, A13, A14, A16, A17, A19, A21, and A22. Master Reference Station M14 has the Auxiliary Reference Stations A2, A3, A7, A8, A9, A11, A13, A15, A16, A17, A18, A22, and A23. Master Reference Station M17 has the Auxiliary Reference Stations A7, A8, A11, A13, A14, A15, A16, A18, A19, A21, A22, and A23. All three Master Reference Stations (M11, M14, and M17) are also Auxiliary Reference Stations (A11, A14, and A17) for each other. Under the assumption that all Master Reference Stations are on a common Integer Ambiguity Level, a handover to the next Master Reference Station data stream would be possible without reinitialization of the integer ambiguities as used in the rover application. However, Integer Ambiguity Leveling is not mandatory for Master Reference Stations. Normally, all stations would be available to a network processing facility and a networking provider could combine all stations in one network (e.g. 122). When all Reference Stations could be brought to a joint Ambiguity Level, a common Subnetwork ID 0 would be assigned. An example of individual data streams may be for Master Reference Stations M11, M14, and M17 respectively as a sequence of information of Network ID (122), Subnetwork ID (0), Master Reference Station ID, Auxiliary Reference Station ID,…:

11

1 2

3 4

5

6

7 8

9

10

12

13

14

15 16 17

18 19 20

21 22

23

Figure A.1-1. Network Example

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

A-2

122, 0, M11, A1, … 122, 0, M11, A2, … 122, 0, M11, A5, … 122, 0, M11, A6, … 122, 0, M11, A7, … 122, 0, M11, A8, … 122, 0, M11, A12, … 122, 0, M11, A13, … 122, 0, M11, A14, … 122, 0, M11, A16, … 122, 0, M11, A17, … 122, 0, M11, A19, … 122, 0, M11, A21, … 122, 0, M11, A22, …

122, 0, M14, A2, … 122, 0, M14, A3, … 122, 0, M14, A7, … 122, 0, M14, A8, … 122, 0, M14, A9, … 122, 0, M14, A11, … 122, 0, M14, A13, … 122, 0, M14, A15, … 122, 0, M14, A16, … 122, 0, M14, A17, … 122, 0, M14, A18, … 122, 0, M14, A22, … 122, 0, M14, A23, …

122, 0, M17, A7, … 122, 0, M17, A8, … 122, 0, M17, A11, … 122, 0, M17, A13, … 122, 0, M17, A14, … 122, 0, M17, A15, … 122, 0, M17, A16, … 122, 0, M17, A18, … 122, 0, M17, A19, … 122, 0, M17, A21, … 122, 0, M17, A22, … 122, 0, M17, A23, …

Message streams such as those in the example above might be transmitted on separate data links or jointly in one data link. Note that the current standard document recommends disseminating only one Master Reference Station per data link (See section 3.1.5). As long as all reference stations are on the same integer ambiguity level, a hand-over to another Master Reference Station is possible as long as the new Master Reference Station was already an Auxiliary Reference Station for the previous Master Reference Station. In the example user equipment could operate using the red Master Reference Station with fixed integer ambiguities on the rover. When roving it might be desirable to switch to the pink or blue Master Reference Station and its associated Auxiliary Reference Stations. Note that with the current recommendation of only one Master Reference Station per data link, switching Master Reference Stations requires that different data links be used. There are situations where a homogeneous integer ambiguity solution might fall apart. For instance, some stations in the center could have communication problems with the central computation facility, or their observations might become unavailable for some other reason. The example given in Figure A.1-2 shows 2 independent homogenous solutions with separated integer ambiguity levels (gray shaded areas). The circles marking the initial area with all the associated Auxiliary Reference Stations for particular Master Reference Stations span both shaded areas. Since the correction differences (with Ambiguity Status Flag = 1, i.e., correct Integer Ambiguity Level for L1 and L2) may be generated only between Master Reference Station and its Auxiliary Reference Stations on the same integer ambiguity level, the example data streams will be different:

11

1 2

3 4

5

6

7 8

9

10

12

13

14

15 16 17

18 19 20

21 22

23

Figure A.1-2. Example of Multiple Solutions

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

A-3

122, 1, M11, A1, … 122, 2, M14, A3, … 122, 2, M17, A8, … 122, 1, M11, A2, … 122, 2, M14, A8, … 122, 2, M17, A14, … 122, 1, M11, A5, … 122, 2, M14, A9, … 122, 2, M17, A15, … 122, 1, M11, A6, … 122, 2, M14, A15, … 122, 2, M17, A18, … 122, 1, M11, A7, … 122, 2, M14, A17, … 122, 2, M17, A23, … 122, 1, M11, A12, … 122, 2, M14, A18, … 122, 1, M11, A16, … 122, 2, M14, A23, … 122, 1, M11, A19, … 122, 1, M11, A21, … Note: It is possible to form other Correction Differences as well, but their Ambiguity Status Flag will be different from “1”. The reaction of the user system may be manifold and is strongly dependent on the processing strategy implemented in the system itself. The simplest strategy is to use only homogenous information of Master Reference Station-Auxiliary Reference Stations combinations referring to the identical epoch. In this case the implementation and handling within the user system is quite straightforward. The user system will first receive the homogenous ones of any of the Master Reference Station-Auxiliary Reference Station combinations and may correct its observations. When a second data stream, with a different Master Reference Station, becomes more suitable the user system may switch to the new data stream, and probably needs only to ensure that no jump occurs in its results due to the switch of the Master Reference Station. However this again is dependent on designated strategy of the user system’s processing strategy. When a homogenous solution with a common integer ambiguity level as given in Figure A.1-1 breaks apart, resulting in a setup as given in Figure A.1-2, the reaction of the user system might depend on the area of actual operation. Within the white area, the zone where the reference stations are no longer part of any solution, the user system’s only chance is to use the remaining information and try an extrapolation. The resulting positioning will probably be degraded under this circumstance. If the user system is operating in one of the gray areas and is using a Master Reference Station-Auxiliary Reference Station combination outside his gray area, the user system may continue without major interruption, but eventually with less flexibility in modeling the information for proper mitigation of biases. If the user system is operating in one of the gray areas, but is utilizing a Master Reference Station-Auxiliary Reference Station combination of the opposite gray area, the user system probably will have to change to a Master Reference Station-Auxiliary Reference Station combination in its area of operation. Ultimately this will probably result in a reset of the user system’s integer ambiguities and the user has to reinitialize again. As stated above, a processing strategy using only information of the latest available epoch is probably the simplest strategy possible. More sophisticated processing strategies may involve the usage of the information of Master Reference Station-Auxiliary Reference Station combinations of different Master Reference Stations and/or different observation epochs. The information of the Network RTK messages have the potential to be used within another centralized networking solution. In the future a further application might be a complete network solution on a user

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

A-4

receiver. The status information of the network calculation transmitted in form of the data fields Network ID and Subnetwork ID provide sufficient proof to indicate to the user system that it is secure or non-secure to continue operation with the new set of information. At the time the complete description of all these potential applications is not possible, due to the number of variations. The experienced developer in the field of network RTK will understand the meaning of the Network ID and Subnetwork ID for his envisioned applications. Therefore further details are left open and will need further description in case the given description is considered ambiguous. A.2 A Scheduling Example for RTK Networks Demonstrating the Proper Use of

Synchronous Message Flags and Multiple Message Indicators It is anticipated that RTK services in the future will transmit data for more than one satellite system concurrently. Such facilities already exist for non-network RTK service, using GPS and GLONASS data, all referenced to the same time epoch. Such operation supports the mixing of measurements from different GNSS’s. As Galileo comes on line, it will initially be used in conjunction with GPS and GLONASS, so RTK services utilizing multiple GNSS’s will be common. The Synchronous Message Flags and Multiple Message Indicator in the RTK messages are designed to support multiple GNSS operation. However, not all rover receivers will be designed to receive and process information from more than one GNSS, and the RTCM standard should enable rovers to know when relevant information has been completely transmitted for a particular epoch. Otherwise such user receivers would have to wait until data for the next epoch has been received before they could begin processing. Such delays are neither desirable nor necessary. The Synchronous Message Flag supports the use of two or more GNSS’s. It is set to “1” if data from another GNSS will follow, and it is set to “0” if there are no other services, or if this data set is for the last GNSS for that epoch. With networks, it might be necessary to transmit data for different Auxiliary Reference Stations at different times, but referenced to a single epoch. For example, if there are 5 Auxiliary Reference Stations and one particular message is sent for one auxiliary station every epoch, it will take 5 epochs to provide a complete set of information. The Multiple Message Indicator is set to “0” for the last Auxiliary Reference Station in the specific message set (e.g. 1015 or 1016), and the others are set to “1”. With more than one GNSS, the data stream will contain the Auxiliary Reference Station data first for one satellite system, then the other. How these rules are applied is demonstrated in Table A.2-1 below for a combined GPS and GLONASS service. The Epoch is the reference time in seconds. GPS 1004 refers to the GPS Master Reference Station reference epoch, and 1004 SMF refers to the value of the Synchronous Message Flag in the 1004 message. GLONASS 1012 refers to the GLONASS Master Reference Station reference epoch, and 1012 SMF refers to the corresponding GLONASS flag. For ease of explanation at each epoch Network RTK data for one Auxiliary Reference Station and one GNSS is transmitted. Actual service implementations may send several messages per epoch, but the explained principle is readily apparent. GPS 1015 refers to the reference epoch for the GPS Auxiliary Reference Station Iono message, and the corresponding MMI refers to the value of the

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

RTCM 10403.2

A-5

Multiple Message Indicator in the 1015 message; similarly for the 1016 Geometric message. The corresponding GLONASS values are then given, where 1015* refers to the not-yet-defined GLONASS Iono message, and similarly for 1016*.

Table A.2-1 Example Showing the Use of SMF’s and MMI’s GPS GLONASS GPS Network RTK GLONASS Network RTK Epoch 1004 SMF 1012 SMF 1015 MMI 1016 MMI 1015* MMI 1016* MMI

1 1 1 1 0 1 1 1 1 2 2 1 2 0 1 1 1 1 3 3 1 3 0 1 1 1 1 4 4 1 4 0 1 1 1 1 5 5 1 5 0 1 1 1 1 6 6 1 6 0 1 1 1 1 7 7 1 7 0 1 1 1 1 8 8 1 8 0 1 1 1 1 9 9 1 9 0 1 0 1 0

10 10 1 10 0 1 1 1 1 11 11 1 11 0 1 1 1 1 12 12 1 12 0 1 1 1 1 13 13 1 13 0 1 1 1 1

15 15 1 15 0 15 1 15 1 16 16 1 16 0 15 1 15 1 17 17 1 17 0 15 1 15 1 18 18 1 18 0 15 1 15 1 19 19 1 19 0 15 1 15 1 20 20 1 20 0 15 1 15 1 21 21 1 21 0 15 1 15 1 22 22 1 22 0 15 1 15 1 23 23 1 23 0 15 0 15 0 24 24 1 24 0 15 1 15 1 25 25 1 25 0 15 1 15 1 26 26 1 26 0 15 1 15 1 27 27 1 27 0 15 1 15 1 28 28 1 28 0 15 0 15 0

29 29 1 29 0

It can be seen that all the GPS and GLONASS Auxiliary Reference Station messages are referenced to Epoch 1, until the entire set of data has been broadcast, after which the data is referenced to Epoch 15. Note that the GPS SMF’s are all “1”, indicating that the GLONASS message is to follow, while the GLONASS SMF’s are all “0”, indicating that there is not a third GNSS represented in the data stream. The final MMI for each GNSS and message type is set to “0”, indicating that the complete set of network corrections have been transmitted, and the rover can proceed immediately to apply them. The extension of this technique to three or more GNSS’s is readily apparent.

© R

TCM

– N

ot fo

r rep

rodu

ctio

n or

redi

strib

utio

n

© RTCM Not for reproduction or redistribution

Documents

Transcript of © RTCM Not for reproduction or redistribution