Interfaces and Protocols

Receivers
Title	Interfaces and Protocols
Author(s)	GMV
Level	Basic
Year of Publication	2013

The final objective of a navigation receiver is to compute a navigation solution. However, in order to do so, several measurements, from one or more satellite constellations, are needed. All this intermediate data is used not only for the solution computation but also in a multitude of applications. As such, with the increasing interest on all data measured by receivers and stations, it was necessary to create standards to exchange data in a common way between all the interested entities (e.g. universities, manufacturers, software companies and end-users). Even though the most popular standards are ASCII because they are machine independent, there are also binary formats.

RINEX

Receiver Independent Exchange format (RINEX) is a data interchange format for raw satellite navigation system data. It was developed by the Astronomical Institute of the University of Berne for the exchange of GPS data to be collected during the first large European GPS campaign EUREF 89; this development was based on the fact that most geodetic processing software used a well-defined set of observables:

• The carrier-phase measurement at one or both carriers
• The pseudorange (code) measurement, equivalent to the difference of the time of reception and the time of transmission of the signal.
• The observation time being the reading of the receiver clock at the instant of validity of the carrier-phase and/or the code measurements.

At the present time four major format versions have been developed:

• The original RINEX Version 1 presented at and accepted by the 5th International Geodetic Symposium on Satellite Positioning in Las Cruces, 1989.;
• RINEX Version 2 presented at and accepted by the Second International Symposium of Precise Positioning with the Global Positioning system in Ottawa, 1990, mainly adding the possibility to include tracking data from different satellite systems (GLONASS, SBAS);
• RINEX Version 3, released in 2009 added support for BeiDou, QZSS, IRNSS and SBAS and restructured the format document to make it clearer and easy to read.
• RINEX Version 4, published in 2021, is another major revision of the format for it to be able to accommodate the new navigation messages from all GNSS constellations, ionospheric corrections, earth orientation parameters and system time offsets.

RINEX Format

The RINEX format covers different ASCII files:

• Observation files
• Navigation files

Clocks (satellite and receiver clock offsets) Each file contains a header session and a data session. The header is placed at the beginning of the file and contains information about the station that collects the data and global information applicable to the entire file. Each observation file contains data from one site and one session, while the navigation RINEX file contains the navigation message broadcasted by the satellites. As such, receivers monitoring the same satellite will receive the same navigation messages. All RINEX standard specifications can be found in the following link:

• https://www.igs.org/wg/rinex/

RINEX Related Links

• Hatanaka compression/decompression

Since RINEX formats are based on ASCII files that can get quite large (for instance a mixed RINEX observation file, with records every second, can reach sizes in the order of 300MB), a dedicated compress/decompress algorithm was developed by Yuki Hatanaka to allow the user to compress/decompress RINEX observation files into a smaller ASCII format.

• Tools to handle RINEX Files

After the dissemination of RINEX format, some universities and receivers manufacturers made available several tools to handle RINEX files, for instance from UNAVCO.

• RINEX FTP Servers

Public raw satellite data are available in RINEX formats in different FTP servers, for example from UNAVCO. Or in NASA’s CDDIS archive listed here.

RINEX-Like Standards

After the presentation of RINEX format, several RINEX-like formats have been defined, mainly used by the International GNSS Service (IGS):

• IONEX: Exchange format for ionosphere models determined by processing data of a GNSS tracking network.
• ANTEX: Exchange format for phase center offsets (PCOs) and Phase Center variations (PCVs) of geodetic GNSS antennae
• Exchange format for satellite and receiver clock offsets determined by processing data of a GNSS tracking network.

IONEX

The IONosphere-map EXchange format was developed with the purpose of having a common format to exchange TEC maps obtained from the GNSS signals. IONEX format is based on RINEX: it consists of a ASCII file containing a header with global information, placed in the beginning of the file, and a data section, with the TEC map.

Detailed information on the format can be found here.

Also FTP servers have been maintained, since 1998 with IONEX data, for instance this one from NASA’s CDDIS that used anonymous ftp access but since October 2020 requires an Earthdata Login account.

ANTEX

ANTEX is based on RINEX and it was developed with the purpose of having a common standard to exchange Phase Center Offsets (PCOs) and Phase Center Variations (PCVs) of geodetic GNSS antennae. Details on the format can be found here.

RINEX Clocks

RINEX CLOCK format is based on RINEX format and it was developed with the purpose of having a common standard to exchange satellite and receiver clock offsets data.

Details on the format can be found here.

RINEX-type Exchange File for GEO SBAS Broadcast Data

This format contains the binary data broadcasted by some Space-Based Augmentation Systems (SBAS) like EGNOS and, WAAS collected in a specific time interval. Detailed information on the format can be found here.

SP3

SP3 Format

The first Standard Product 3 format (SP3-a) was proposed in 1989, with the main purpose of exchanging satellite related data (orbit and clock information). The basic format of an SP3 file is a header, following by a series of records containing the position and clock records for each satellite listed in the header. A second, optional, record contains the satellite velocity and clock correction rate-of-change.

Three major SP3 versions are defined:

• Original SP3-a proposed in 1989;
• SP3 version b, proposed in 1998, defined to allow the combination of GPS orbits and GLONASS orbits
• SP3 version c, proposed in 2000.
• And the current SP3 version d, proposed in 2016

SP3 Related Links

• All SP3 standard specifications can be found here;
• Public SP3 raw data are available in different FTP servers, for instance from here.

Almanac Related Formats

YUMA

The YUMA format defines an ASCII message containing the almanac elements of each GPS satellite, necessary to propagate the orbit of the satellite. GPS data started to be stored in YUMA format after 1990 and it has been used in orbit-analysis software to generate orbit plots of the GPS constellation. Definition of the format can be found [1] and stored data can be found here.

SEM

The SEM format is very similar to the YUMA format. It contains ASCII messages with the almanac elements of each GPS satellite that can be used to propagate satellite orbits. The major differences between YUMA and SEM are the following:

• The SEM files contain not only the SVN (Satellite Vehicular Number) but also the PRN of each satellite, this is important because although the SVN of each satellite is defined prior to its launch, the PRN is defined depending on the need, as such using SEM one can track the PRNs that are being transmitted by each SVN.
• Each element in the SEM file has higher precision than in the YUMA file.
• SEM almanac contains information regarding anti-spoofing and the block version of the satellite, unlike YUMA almanacs.

The complete definition can be found here and stored data can be found here.

TLE

TLE stands for Two Line Element, and it is a very small ASCII format suitable for internet transference. As YUMA and SEM it is used in orbit propagation software.

Detailed information on the TLE format can be found here and stored data in TLE format can be found here.

RTCM and NTRIP

RTCM

The standard for differential global navigation satellite system was defined in RTCM Special Committee 104 and its current version is Version 3. RTCM standard for differential global navigation satellite services are communication protocols between reference stations and mobile receivers which allow very high accurate positioning, when compared with positioning system without augmentation. RTCM Version 3, also known as RTCM 10403.1 is used on DGNSS services worldwide. It supports very high accuracy navigation and positioning applications, allowing the receivers to compensate from errors that exist in satellite positioning without augmentation. Details on the RTCM cannot be found for free but can be bought here.

NTRIP

The NTRIP was also defined in the RTCM Special Committee 104. NTRIP stands for “Networked Transport for RTCM via Internet Protocol”. It is based on Hypertext transfer Protocol version 1.1 and the intention is to disseminate differential correction data through the internet. As of 2020 this protocol is not available as a free open standard. An open source implementation is available and can be used to reverse-engineer the protocol.

NMEA

National Marine Electronics Association (NMEA) specified a set of data transmitted protocol named NMEAS 0180, NMEAS 0182, NMEAS 0183 and NMEAS 2000. Although, currently, the most used standard is NMEAS 0183, it has started to be migrated to NMEAS 2000 in several marine applications. NMEAS is a simple standard composed of a serial communication protocol and an ASCII messages, transmitted from a source to a series of destinies. This standard supports the interconnectivity between a series of marine electronic devices like wind instruments, auto pilots and GPS receivers, allowing, for instance, the correction of the auto pilot, based on GPS data. From the navigation point of view, different data transmission is foreseen in NMEAS standard, depending on the devices connected with the receiver, such as PVT data computed by the receiver, detailed information on satellites in view, or even the navigation messages itself.

Details on the standard can be found here.

EMS

This format contains the binary data broadcasted by EGNOS. The EMS files contain one data record per text line and each data record includes an EGNOS message in hexadecimal format. They are provided by the EGNOS Message Server and detailed information on the format can be found here.