If you wish to contribute or participate in the discussions about articles you are invited to contact the Editor

Difference between revisions of "Interfaces and Protocols"

From Navipedia
Jump to navigation Jump to search
m (included author logo.)
(Fixed links and updated info in some of the formats.)
 
Line 17: Line 17:
 
*The observation time being the reading of the receiver clock at the instant of validity of the carrier-phase and/or the code measurements.
 
*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:
+
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.;
 
*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 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.
+
*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.
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===
 
===RINEX Format===
  
The RINEX format covers three different ASCII files:
+
The RINEX format covers different ASCII files:
 
*Observation files
 
*Observation files
 
*Navigation files
 
*Navigation files
*Meteorological file
 
  
 +
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 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.
+
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 links:
+
All RINEX standard specifications can be found in the following link:
*ftp://ftp.unibe.ch/aiub/rinex/
+
 
*http://igscb.jpl.nasa.gov/igscb/data/format/
+
*https://www.igs.org/wg/rinex/
  
  
Line 44: Line 43:
 
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 [http://terras.gsi.go.jp/ja/crx2rnx.html compress/decompress RINEX observation files into a smaller ASCII format].
 
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 [http://terras.gsi.go.jp/ja/crx2rnx.html compress/decompress RINEX observation files into a smaller ASCII format].
  
*Tools to handle RINEXT Files
+
*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 [http://facility.unavco.org/software/preprocessing/preprocessing.html from UNAVCO].
 
After the dissemination of RINEX format, some universities and receivers manufacturers made available several tools to handle RINEX files, for instance [http://facility.unavco.org/software/preprocessing/preprocessing.html from UNAVCO].
  
 
*RINEX FTP Servers
 
*RINEX FTP Servers
Public raw satellite data are available in RINEX formats in different FTP servers, for example from [ftp://cddis.gsfc.nasa.gov/pub/gps/data/daily NASA] and [ftp://data-out.unavco.org/pub/rinex/ UNAVCO].
+
Public raw satellite data are available in RINEX formats in different FTP servers, for example from [ftp://data-out.unavco.org/pub/rinex/ UNAVCO]. Or in NASA’s CDDIS archive listed [https://igs.org/data/ here].
  
 
==RINEX-Like Standards==
 
==RINEX-Like Standards==
Line 54: Line 53:
 
After the presentation of RINEX format, several RINEX-like formats have been defined, mainly used by the International GNSS Service (IGS):
 
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.
 
*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
+
*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.
 
*Exchange format for satellite and receiver clock offsets determined by processing data of a GNSS tracking network.
  
Line 60: Line 59:
 
===IONEX===
 
===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.
+
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.
 
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 [http://igscb.jpl.nasa.gov/igscb/data/format/ here].
+
Detailed information on the format can be found [https://igs.org/formats-and-standards/ here].
  
Also FTP servers have been maintained, since 1998 with IONEX data, for instance [ftp://cddis.gsfc.nasa.gov/pub/gps/products/ionex here].
+
Also FTP servers have been maintained, since 1998 with IONEX data, for instance [https://cddis.nasa.gov/Data_and_Derived_Products/CDDIS_Archive_Access.html  this one from NASA’s CDDIS] that used anonymous ftp access but since October 2020 requires an [https://urs.earthdata.nasa.gov/users/new Earthdata Login account].
  
 
===ANTEX===
 
===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.
 
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 [http://igscb.jpl.nasa.gov/igscb/data/format/ here].
+
Details on the format can be found [https://igs.org/formats-and-standards/ here].
  
  
Line 76: Line 75:
 
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.
 
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 [http://igscb.jpl.nasa.gov/igscb/data/format/ here].
+
Details on the format can be found [https://igs.org/formats-and-standards/ here].
  
  
Line 82: Line 81:
  
 
This format contains the binary data broadcasted by some Space-Based Augmentation Systems (SBAS) like EGNOS and, WAAS collected in a specific time interval.
 
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 [http://igscb.jpl.nasa.gov/igscb/data/format/geo_sbas.txt here].
+
Detailed information on the format can be found [https://igs.org/formats-and-standards/ here].
  
  
Line 93: Line 92:
 
*Original SP3-a proposed in 1989;
 
*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 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 version c, proposed in 2000.
 +
*And the current SP3 version d, proposed in 2016
  
  
 
===SP3 Related Links===
 
===SP3 Related Links===
*All SP3 standard specifications can be found [http://igscb.jpl.nasa.gov/igscb/data/format/ here];
+
*All SP3 standard specifications can be found [https://igs.org/formats-and-standards/ here];
*Public SP3 raw data are available in different FTP servers, for instance from the [http://igscb.jpl.nasa.gov/igscb/product/ IGS site].
+
*Public SP3 raw data are available in different FTP servers, for instance from [ftp://igs.ensg.ign.fr/pub/igs/products/ here].
  
 
==Almanac Related Formats==
 
==Almanac Related Formats==
Line 104: Line 104:
 
===YUMA===
 
===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.
 
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 [http://www.navcen.uscg.gov/?pageName=gpsYuma here] and stored data can be found [http://www.celestrak.com/GPS/almanac/Yuma/ here].
+
Definition of the format can be found [https://celestrak.com/GPS/almanac/Yuma/definition.phphere] and stored data can be found [http://www.celestrak.com/GPS/almanac/Yuma/ here].
  
  
Line 129: Line 129:
 
The standard for differential global navigation satellite system was defined in RTCM Special Committee 104 and its current version is Version 3.
 
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 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.
+
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 can be found [http://www.epncb.oma.be/_organisation/projects/euref_IP/RTCM.pdf here].
+
Details on the RTCM cannot be found for free but can be bought  [https://rtcm.myshopify.com/collections/differential-global-navigation-satellite-dgnss-standards here].
  
 
===NTRIP===
 
===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.
 
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 [http://igs.bkg.bund.de/ntrip/docu here].
+
As of 2020 this protocol is not available as a free open standard. An [http://software.rtcm-ntrip.org/ open source implementation] is available and can be used to reverse-engineer the protocol.
  
 
==NMEA==
 
==NMEA==
Line 144: Line 144:
 
Details on the standard can be found [http://en.wikipedia.org/wiki/NMEA_0183 here].
 
Details on the standard can be found [http://en.wikipedia.org/wiki/NMEA_0183 here].
  
==EMS==
+
==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.  
 
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 [http://www.egnos-pro.esa.int/ems/EMS_UID_2_0.pdf here].
+
They are provided by the EGNOS Message Server and detailed information on the format can be found [http://www.egnos-pro.esa.int/ems/uid.html here].

Latest revision as of 13:35, 7 April 2022


ReceiversReceivers
Title Interfaces and Protocols
Author(s) GMV
Level Basic
Year of Publication 2013
Logo GMV.png


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:


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.