Message Decoding

The Radio Technical Commission for Maritime Services (RTCM) message decoding handles with every data type separately and afterwards begins with retrieving and synchronizing the necessary data fields, taking in to account the GPS and GLONASS time of the measurements the user receives. These measurements are the position observations of the user, and these are as standard position solutions in the NMEA format. The decoding process of the message comprises of three independent decoding tasks:

 The RTCM message decoding that deals with DGNSS RTCM SC-104 messages received from TopNET+ server.

 The RTCM 10410.1 message decoding, this handles GNSS data corrections from RTCM via Networked Transport of RTCM via Internet Protocol (Ntrip).

 User and navigation data decoding, which deal with satellite ephemeris information and user‟s measurements.

Several message types are considered while decoding the RTCM messages, containing pseudo-range corrections (PRC), along with the rate of change for the pseudo-range corrections (RRC) for visible healthy satellites observed at the corresponding DGNSS reference station. In addition, another message type is considered for obtaining ECEF coordinates of the corresponding DGNSS station.

RTCM messages are made of a number of blocks known as RTCM words, every word is 30-bit length (five RTCM bytes), containing 24 data bits and 6 parity bits (see Figure 4.2).

Figure 4.2: RTCM words format (RTCM, 1994).

Each RTCM message consists of a body and a header. While the body keeps data for each corresponding message type, the header is contained in the first and second RTCM words; it composed of message type, reference time, reference station identification, time, and length of message as shown in Figure 4.3.

Figure 4.3: RTCM header format (RTCM, 1994).

An RTCM message‟s length in toto rests upon the number of covered and correct satellites. Nevertheless, an integer value in the second RTCM word (Length of Frame) indicates, at all times, the total number of RTCM words that compiles the message. Several versions of RTCM SC-104 data format have been available;

these can be summarized as the following:

 RTCM 2.0: is only used for DGPS applications (without RTK).

 RTCM 2.1: is comparable to version 2.0 but it also contains new messages for carrier phase data and RTK corrections.

 RTCM 2.2: additionally to the above, it composes of GLONASS data and associated information which is carried by newly added messages 31-36.

 RTCM 2.3: consists of the antenna types in message 23 and ARP information in message 24 as well.

 RTCM 3.0: is the most recent version that holds network RTK messages and also accommodates message types for new GNSS systems that are under development, such as GLONASS and Galileo.

The types of messages described in RTCM 3.0 are employed in this work. There are four groups of RTCM 3.0 GNSS RTK messages (RTCM 2004), which are shown below in Table 4.1.

Figure 4.4: RTCM Types.

Group Name Message Type Message Description

Observations 1001 L1-only GPS RTK Observables

1002 Extended L1-Only GPS RTK Observables

1003 L1 & L2 GPS RTK Observables

1004 Extended L1 & L2 GPS RTK Observables

1005 L1 Only GLONASS RTK Observables

1006 Extended L1-Only GLONASS RTK

Observables

1007 L1 & L2 GLONASS RTK Observables

1008 Extended L1 & L2 GPS RTK Observables

Station Coordinates 1009 Stationary RTK Reference Station ARP

1010 Stationary RTK Reference ARP with

Antenna Height

Antenna Description 1011 Antenna Descriptor

1012 Antenna Descriptor & Serial Number

Auxiliary Operation Information 1013 System Parameters

User‟s measurements, as described earlier, obtained at the MNU are in the NMEA. The message decoder merely considers the messages of GGA, which include the GPS and GLONASS essential time and position fixing information.

This message contains the list of satellites being tracked and applied for computing the positioning coordinates at the MNU as well.

RTCM has upgraded to Version 2.0 for Networked Transport of RTCM via Internet Protocol (Ntrip), designated as RTCM Standards 10410.1.

The new standard defined by TRCM‟s Special Committee 104 (SC104), along with other things, supply a protocol for streaming differential correction data to stationary or mobile users though the Internet. Usually, differential correction have been broadcasted over the radio links from either a single or networked reference stations situated in familiar settings to improve the mobile receivers‟

(rovers) real-time accuracy. The majority of these services supply with GPS and GLONASS corrections. The design of Ntrip is to allocate the GNSS streaming data to mobile or stationary clients though the Internet, allowing simultaneous PC, PDA or receiver connections to a broadcasting host. Through the mobile IP networks, such as GSM, GPRS, EDGE, UMTS or HSDPA, Ntrip can support the wireless Internet access.

The navigation message includes a number of data pages, of which each holds five sub-frames. Each and every frame has two data words of 30 bits. In order to extract pertinent information about each observed satellites with respect to the user‟s measurement the following sub-frames are considered in the decoding process:

 Sub-frame 1, containing the Satellite Vehicles (SVs) clock parameters.

This information is utilised to correct the code phase time received from the SVs, with respect to the relativistic effects. This also permits the compensation of the SVs‟ group delay effects.

 Sub-frames 2 and 3 consist of ephemeris parameters which are used to determine the SVs orbits within two hours interval. This information is

used in order to calculate the satellites‟ locations vis-à-vis the time stamps of the user‟s measurements.

 Sub-frame 4 holds the ionospheric delay coefficients needed for computing the ionosphere delay at the time of measurements by using an embedded ionospheric model.

The information gained from the message decoding procedure is utilised to estimate the user‟s initial position. Then, before being used in the data Corrected Positioning Data Computed process as shown in Figure 5.9 though, the decoded correction information passes through the integrity monitoring and baseline estimation procedures for reliability and validity inspection.