If you wish to contribute or participate in the discussions about articles you are invited to contact the Editor
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 three 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, currently under revision.
Currently the most commonly used RINEX versions is RINEX 2.11 which allows to store pseudorange carrier-phase and Doppler measurements from GPS, GLONASS and also augmentation systems like EGNOS and WAAS in the same file. With the development of new global navigation satellite systems like Galileo and BEIDOU, it became clear that a new standard, which will full integrate all the satellite system, is needed. With this purpose RINEX Version 3 has been developed and it is under revision.
RINEX Format
The RINEX format covers three different ASCII files:
- Observation files
- Navigation files
- Meteorological file
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 and meteorological 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 links:
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 RINEXT 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 NASA and UNAVCO.
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 variations 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 GPS signal. 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 here.
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.
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
- And the current SP3 version c, proposed in 2000.
SP3 Related Links
- All SP3 standard specifications can be found here;
- Public SP3 raw data are available in different FTP servers, for instance from the IGS site.
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 here 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 supports the dissemination of Real-Time Kinematic network information. Details on the RTCM can be found 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. Detailed information on the standard can be found here.
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.