GPS Solutions

, 23:106 | Cite as

GNSS metadata and data validation in the EUREF Permanent Network

  • Carine BruyninxEmail author
  • Juliette Legrand
  • András Fabian
  • Eric Pottiaux
Original Article


The EUREF Permanent Network (EPN) is a network of continuously operating GNSS stations installed throughout the European continent. The EPN Central Bureau (CB) performs the day-to-day EPN coordination, acts as liaison between station operators, data centers, and analysis centers, and maintains the EPN Information System. Over the last years, the EPN CB has accommodated the enhancements required by the new EU General Data Protection Regulation, new multi-GNSS signals, new RINEX formats, increased usage of real-time GNSS data, and the new GeodesyML metadata exchange format. We will discuss how the EPN CB validates and provides access to EPN station metadata and monitors EPN data sets in terms of availability, latency, and quality to ensure they meet the user requirements. The analysis of 23 years of EPN GNSS data quality checks demonstrates some of the most frequently encountered tracking problems affecting EPN stations, and specific GNSS receiver types, throughout the years.


EPN EUREF GNSS Metadata Data quality 


The EUREF Permanent Network (EPN) is a network of permanently operating GNSS stations that have been created in 1995 with the primary goal to support and improve the maintenance of the European Terrestrial Reference System (ETRS89) and its successive realizations (Adam et al. 2002). The EPN is operated under the umbrella of EUREF, the IAG (International Association of Geodesy) sub-commission for Europe, integrated in IAG sub-commission 1.3, Regional Reference Frames. Counterparts of EUREF in other parts of the world are, e.g., SIRGAS, the sub-commission for South and Central America or NAREF, the sub-commission for North America (Drewes et al. 2016). Similar to the International GNSS Service (IGS; Johnston et al. 2017), the EPN is based on voluntary contributions. More than 130 agencies all over Europe contribute to the EPN. EPN stations upload Receiver Independent Exchange Format (RINEX) data to EPN data centers (DC), which permanently archive the data and make them freely available to all users. Real-time EPN data are distributed through three regional EPN broadcasters. As described in Bruyninx et al. (2012), EPN analysis centers acquire the EPN data for the generation of precise station positions and velocities in the ETRS89 and tropospheric zenith path delays. Even if primarily designed to serve reference frame maintenance, the EPN has become valuable for multi-disciplinary applications, e.g., numerical weather prediction and climate research (Guerova et al. 2016; Pacione et al. 2017), ionospheric monitoring (Bergeot et al. 2014), or monitoring of ground deformations (Nocquet et al. 2005; Nguyen et al. 2016).

The EPN Central Bureau (CB), managed by the Royal Observatory of Belgium (ROB), performs the day-to-day EPN network coordination and acts as the liaison between station operators, data centers, analysis centers, and users. As described in Bruyninx et al. (2009), it maintains the EPN Information System (Web site and ftp site and provides access to EPN station metadata, data, and products. Although guidelines, based on IGS guidelines, exist within the EPN for data quality and data flow, and maintenance of metadata, the various institutes use different practices and there is no formal guarantee that EPN stations are operated following the EPN guidelines. Therefore, the EPN CB also monitors the data sets in terms of metadata, availability, latency, and quality to ensure they meet the requirements of the users.

A part of the daily activities of the Central Bureau consists of analyzing the results of its automated processes to scan data centers, retrieve data, and perform checks on the station metadata and GNSS data. The robustness of the services in operation is a continuous challenge that requires constant development and improvement of background monitoring modules. During the last years, the availability of new multi-GNSS signals imposed revisiting the full monitoring chain and led to a complete redesign of the data quality checks. In addition, new applications are developed, such as the “Metadata Management and distribution system for Multiple GNSS networks” (M3G). Finally, the CB sends and answers many emails every day to notify station managers about abnormal station conditions, help users find what they are looking for, provide information about data, or help users use the EUREF data and products.

First, we discuss the EPN CB metadata management and data quality monitoring. Following, we present the analysis of 23 years of EPN GNSS data quality checks.

Tracking network

The EPN tracking network grew from 35 continuously operating stations delivering daily RINEX data in 1996 to more than 330 multi-GNSS reference stations today (Fig. 1), which minimally observe dual-frequency GPS data according to the EPN station guidelines available from Bruyninx (2017). All stations submit daily data, but 97% of the stations submit in addition hourly data, and 55% also submit real-time data. Thirty percent of the EPN stations also belong to the IGS network and hence the homogenization of IGS and EPN operation standards.
Fig. 1

EPN tracking stations (status June 2019). Gray filled circle: tracking only GPS, black filled circle: tracking GPS + GLONASS, open triangle: tracking GPS + GLONASS + Galileo, and gray filled triangle: tracking GPS + GLONASS + Galileo + BeiDou

Eighty-three European agencies are presently operating the EPN tracking network. They are universities (33%), research/space agencies (28%), mapping agencies (36%), and a few private companies. The mapping agencies are operating two-thirds of the EPN stations.

EUREF aims at playing a pioneering role in the modernization of permanent GNSS networks and stimulates, therefore, the installation of receivers capable of observing GLONASS, Galileo, and BeiDou satellites. The first GLONASS and Galileo observations showed up in the EPN resp. in end 1999 and 2013. Today, 95% of the EPN stations observe GLONASS, 65% Galileo, and 53% BeiDou in addition to GPS.

Station metadata

The installations at EPN sites must be documented by a ‘site log file,’ which is a text-based file in a standardized format maintained and published by the IGS. It contains station metadata such as information on the equipment installed at the station, its monumentation and environment, and eventually co-located instruments. The site log content requires updates as soon as a change occurs at the station, for example, an equipment change. In 2001, the EPN CB enabled automated site log updates by allowing station managers to send site log updates by email to the EPN CB. Consequently, updated site logs were distributed without any delays. In 2008, the email system was replaced by a Web-based site log validation and submission tool, which provided additional functionalities such as enhanced error messages and password protected uploads. Each of the agencies operating EPN stations received a login/password and was only allowed to update site logs of its own stations. In 2015, the Web-based system was extended also to collect and validate the site logs of the EPN densification stations (Bruyninx et al. 2018). The extension consisted of setting up a separate, less strict, set of rules for validating the site logs of the densification stations.

With about 2000 logins/year, the system proved to be very useful for EPN station managers, but also for external station managers who, through a guest account, could also validate their site logs. About 30% of the validations were done by guests. Still, also this system became outdated because of
  1. 1.

    GeodesyML The present version of the site log format is in use since June 2001 and does not respond anymore to the requirements of modern metadata, which should be in line with the international standards of the International Organization for Standardization and Open Geospatial Consortium, e.g., Geography Markup Language (GML) and Web service standards. While GML already provides primitive objects such as geometry, coordinate reference system, and time, it had no specific application schema that met the needs of the geodetic community. Brown et al. (2016) and Boler et al. (2017) describe that Australian and New Zealand government geodetic agencies proposed in 2016, with the support of the IGS, a new GML application schema, called the Geodesy Markup Language (GeodesyML). This XML-based standard includes objects like antenna, receiver, cable, adjustments, etc. Those object types in turn reference the primitive object types defined in the GML standard. Typical for GeodesyML is the fact that no information is ever deleted. It stays in GeodesyML but is marked as deleted. This is an essential difference with the classic IGS site logs.

  2. 2.

    European Union’s General Data Protection Regulation (EU GDPR) The EU GDPR is the most important change in data privacy regulation in 20 years and applies to all companies processing personal data (name, email, telephone numbers) of data subjects residing in the Union, regardless of the company’s location. The EU Parliament approved GDPR on April 14, 2016, and it was enforced on May 25, 2018 (EU 2016). GNSS metadata contain personal data such as the names of (European) station operators, and therefore GDPR is applicable to these metadata. In short: all individuals whose personal data are stored in a structured way must be informed about what is done with their personal data. They must also be provided with tools to delete and edit their data. Finally, they must now also formally agree that their personal data are made publicly available in the site logs.

  3. 3.

    European Plate Observing System (EPOS, Jeffery and Bailo 2014) EPOS combines the data and services of European solid earth science infrastructures into one integrated system. It is presently under construction, but first operational services are expected by 2020. The GNSS component of EPOS aims at providing access to metadata, data, and products from more than 3000 GNSS sites in Europe. EPOS also uses the IGS site logs and GeodesyML to exchange GNSS station metadata but has its own GNSS station metadata validation rules. As several of the EPN and EPN densification stations contribute to the EPOS, it is imperative that throughout the EPN and EPOS identical station metadata are used. In addition to the classic GNSS station metadata, EPOS also requires that information of data licenses, DOI (Digital Object Identifiers), and others is collected.


Therefore, in 2017, the EPN CB started the development of a new “Management and distribution system of Metadata for Multiple GNSS networks (M3G)”. The M3G database is GeodesyML-compliant and has the possibility to export GNSS station metadata in both the GeodesyML and classic site log format. M3G is primarily designed to allow station managers to pass the information on, e.g., the update of a receiver firmware version in a specific station to M3G using command-line instructions. For that purpose, each agency operating GNSS stations will receive a specific token permitting them to make changes to their metadata in M3G.

M3G uses three-level validation rules, which are applied in a stepwise manner:
  • General rules they are identical for all networks (EPN, EPN densification, EPOS), such as using IGS-standard names for GNSS receiver and antenna types;

  • Network-dependent rules, such as the usage of an IERS (International Earth Rotation and Reference Systems Service) DOMES number which is mandatory within the EPN and optional within EPOS;

  • Station-dependent rules, which are set up to allow non-standard metadata for historical GNSS data, such as a GNSS receiving antenna, which has no calibrations.

In order to comply with GDPR, M3G maintains a centralized database with all personal contact information. Once a person is added to this database, e.g., through the migration of an EPN site log, he will receive a GDPR-compliant email asking if he accepts (or declines) the publication of his/her personal data by ROB. If the person refuses, then his/her contact information is removed from all exported GNSS station metadata and replaced by the general contact info provided by the agency of the station manager.

Early 2018, all 1904 EPN and EPN densification site log files and associated Operational Center forms were migrated to M3G and imported into the new database to extensively test the new system. The Operational Center forms contain the basic information of each agency as well as the list of stations for which the agency maintains the site logs. Once imported, the station metadata were exported in both the site log and GeodesyML format. This was done without changing the content of the site logs. As a rule, a site log is only changed if the station manager has explicitly agreed with the changes.

In the summer of 2018, M3G, available from, reached the level of maturity required for operational use in EUREF and EPOS. As a result, today M3G manages operationally GNSS station metadata in a consistent way within both EPOS and EUREF networks. 113 European agencies have an account on M3G, which stores validated GNSS site metadata of 2016 GNSS stations (status: April 2019). 95% of these GNSS stations contribute to the EPN or EPN densification network. Only 37% of the people with personal data in M3G have actively informed us how they wish their personal data to be handled. The very large majority agrees that ROB makes their personal data publicly available without restrictions. Without any reply to the GDPR email, the exported GNSS metadata remain unchanged.

For the sake of completeness, we also mention that the EPN CB station documentation is complemented with pictures of the GNSS equipment, monument and its surroundings. These pictures are available for 99.99% of the EPN stations.

Antenna calibrations

In 2005, the IGS decided to replace the relative calibrations for the modeling of the phase center offset and variations of the GNSS receiver and satellite antennas by absolute calibrations (Gendt 2005). To maintain consistency with the IGS orbits, which are used in the EPN analysis centers, it was imperative that the EPN followed this new standard. However, at that time, the GEO++ company (Wübbena et al. 2006) producing the absolute type mean receiver antenna robot calibrations used by the IGS agreed to only make publicly available these calibrations for antenna/radome pairs in use within the IGS. Consequently, the EPN ended up with several antenna/radome pairs for which absolute calibrations were available but could not be publicly made available to the users because they were not installed in IGS stations. To accommodate for that problem, the EUREF Governing Board decided early November 2005 to start also using individual antenna calibrations from mid-November 2006 (GPS week 1400) on. For antenna without individual calibrations, EUREF used the absolute IGS type mean calibrations, and if necessary, complemented them with relative antenna calibrations converted to absolute. At the start, individual antenna calibrations were collected for 13 antennas/radomes installed in the EPN and made available by ftp at the EPN CB. To allow the correct application of these individual antenna calibrations during the data analysis, the EPN CB crosschecks the antenna serial number indicated in the station site log with the antenna serial number provided in the individual calibration and the RINEX file. The EPN individual antenna calibration is available from file, with xx = 05, 08, and 14 referring to the successive releases of the IGS antenna calibration file. At each new release of the IGS antenna calibration file, also a new epnc_xx.atx individual antenna calibration file is released. In addition, in between releases, the epnc_xx.atx is updated when new antennas are included in the EPN.

In May 2019, the epnc_14.atx file contained 213 individual antenna calibrations (Fig. 2) from the 251 collected individual antenna calibrations. This difference is caused by the fact that individual antenna calibrations submitted to the EPN CB for antennas/radomes that are already in use in the EPN are not added straight away to the epnc_14.atx file in order to avoid jumps in the coordinate time series. These calibrations are stored in a separate directory ( at the EPN CB and are considered for inclusion in the merged individual antenna calibration file upon a future release of the IGS antenna calibration file. In addition, if both chamber and robot calibrations are made available, then priority is given to the chamber calibrations, which includes more frequencies. For 30 antennas/radomes combinations, both robot and chamber calibrations are available.
Fig. 2

EPN stations classified according to antenna/radome calibrations in use. Black dots indicate EPN stations with an antenna/radome pairs with absolute individual calibrations (43.1%), green dots have antenna/radome pairs with absolute type calibrations (54.3%), orange dots have antenna/radome pairs with absolute calibrations converted from relative values (0.3%), and red dots have antenna/radome pairs without absolute calibrations (2.3%). In this case, the radome is neglected and the calibration values of the antenna with radome ‘NONE’ are used

The major advantage of using individual antenna calibration is the fact that some of the calibrations done in an anechoic chamber include more frequencies than the type mean calibrations provided by the IGS, which presently only include calibrations for GPS and GLONASS frequencies. Yet, the number of calibrations for, e.g., Galileo signals remains limited as can be seen in Table 1. For example, only 48 of the 218 EPN stations providing Galileo data have individual antenna calibrations for Galileo signals.
Table 1

For each constellation and frequency, number of antennas/radomes for which individual antenna calibrations have been submitted to the EPN CB. Status May 2019













































Data flow and data access

In this section, we describe the EPN data flow, followed by an overview of how the EPN CB monitors EPN data availability and latency, and some results.

Daily and hourly data

The RINEX data from the EPN stations are freely available through FTP from two regional data centers located at Bundesamt für Kartographie und Geodäsie (BKG, Germany) and Bundesamt für Eich- und Vermessungswesen (BEV, Austria), and one historical data center, managed by the EPN Central Bureau at ROB. As indicated in Bruyninx (2017), the submission of RINEX 2 (version 2.11, Gurtner and Estey 2012) observation data is, in May 2019, still mandatory. However, stations equipped with a receiver submitting more signals than dual-frequency GPS and GLONASS data must additionally submit RINEX 3 data (versions 3.02, 3.03 or 3.04, IGS RINEX WG and RTCM-SC104 2013, 2015, 2018).

Both regional data centers store hourly and daily data in the RINEX 2 and RINEX 3 formats. The historical data center only stores daily RINEX files and homogenizes the header of these files to be in agreement with the station metadata as provided in the station site logs. The EPN CB continuously scans the two regional EPN data centers, and the results of the scans are made available on the EPN CB Web site through interactive plots. An example is shown in Fig. 3, which displays the availability and latency of the hourly and daily data of the EPN station ARJ600SWE at BKG and BEV. They allow station operators to easily check the data upload of their stations. Additionally, the CB notifies station operators when successive daily or hourly data are missing or have significant delays.
Fig. 3

Example (station ARJ600SWE) of the daily (top) and hourly (bottom) availability plots provided by the EPN Central Bureau for each of the EPN stations

Figure 4 indicates that, since the start of the EPN in 1996, the availability of the daily RINEX 2 data has been excellent, with a mean availability of 95% ± 2% over the whole period and 97% in 2018. However, the amount of complete RINEX 2 files was dramatically low in the early years with just 37% in 1996. Today, it is 85%, but this also means that still about 15% of the EPN daily RINEX 2 data have missing epochs. For files with more than 1 h of missing data, this number is reduced to 2%.
Fig. 4

Availability and completeness of daily EPN data

The first RINEX 3 data appeared in the EPN in 2011 and the number of stations submitting RINEX 3 data significantly increased every year thanks to the increasing number of multi-GNSS receivers in the EPN. In 2018, 57% of the expected daily data were provided in the RINEX 3. The number of files with missing epochs is just 4% (compared to 12% for RINEX 2), and only 1% has more than 1 h of missing data.

Concerning the hourly data, the data flow monitoring demonstrated that in 2018:
  • At the BKG data center, resp. 93% ± 1% and 88% ± 3% of the hourly RINEX 2 and 3 data arrived within 10 min (threshold to be useful for, e.g., numerical weather predictions).

  • At the BEV data center, resp. 89% ± 4% and 88% ± 2% of the hourly RINEX 2 and 3 data arrived within 10 min.

It also demonstrates that especially concerning the RINEX 2 data, the BKG data center is performing better than the BEV data center. This can be explained by the fact that BEV data center was set up in 2017 and could still be struggling start-up problems.

Real-time data

Real-time EPN data are distributed through three regional NTRIP (Networked Transport of RTCM via Internet Protocol; Weber et al. 2005) broadcasters located at ASI (Italian Space Agency, Matera), BKG, and ROB. The data are exchanged in the vendor-independent RTCM format maintained by the Radio Technical Commission for Maritime Services (RTCM 2013). 55% of the EPN stations provide real-time data, and all sites stream data at a 1 Hz rate.

All EPN broadcasters should, in theory, provide the same streams to the users to guarantee the redundancy of the EPN real-time data flow. However, a snapshot of the comparison of the number of streams set up at each broadcaster with the number of EPN streams actually running (Table 2) directly demonstrates that the broadcasters do not exactly stream the same information. The reason is that new or stopped streams are not added/removed simultaneously by all broadcaster administrators, since this has to be done manually. In addition, EPN station managers change real-time streams without notifying EPN broadcaster operators, or by just notifying one of them.
Table 2

Number of EPN real-time streams available from three regional EPN broadcasters, operated by ASI, BKG and ROB (status: January 21, 2019)


Streams set up

Streams actually broadcasting










The EPN CB listens to the real-time EPN data streams transmitted by each of the EPN broadcasters and provides information about the availability of each stream. In addition, the streams are decoded to check stream latency, stream content (message types), station metadata (receiver type, antenna type, and antenna height), and a reference position. Beginning of 2019, 54% of the streams provided the “legacy” messages 1004 (GPS) and 1012 (GLONASS). One-third of the data streams providing RTCM 3.3 Multi Signal Messages (MSM) messages delivering MSM4 (message type 1074 etc.…) or MSM5 (message type 1075 etc.). The other two-thirds provide MSM7 (message type 1077, etc.).

Only 52% of the real-time EPN streams contained Galileo observables, which is surprisingly low because 76% of the stations that provide real-time data are actually providing RINEX 3 data, including Galileo observations. The main reason for not (yet) including Galileo in the data streams is motivated by the fact that almost ¾ of the real-time streams are operated by mapping agencies who are also providing national positioning services. We suspect that the users of some of these national positioning services might not be ready to get Galileo-capable real-time positioning services.

In a network like the EPN, which is primarily set up to provide access to the ETRS89, one expects that the streams provide the correct metadata to ensure that a user can use the station as an ETRS89 reference station during, for example, Real-time Kinematic (RTK) measurement. This implies that the reference position inserted in the real-time data stream (messages types 1005 or 1006) corresponds to the ETRS89 position of the station as released by EUREF or the national Authority/Mapping Agency. The EPN CB monitoring shows that about 56% of the streams have a reference position that is within 5 cm from the expected ETRS89 reference position. Surprisingly, almost half of the streams operated by mapping agencies had a station position that differed by more than 5 cm from the official ETRS89 position released by EUREF.

The antenna type and antenna height extracted from real-time message types 1008/1033 and 1005/1006 should also correspond to the information provided by the station manager in the site log. Around 20 streams are providing incorrect or incomplete information.

To inform the users of streams with problematic metadata, the EPN CB displays a warning message on the EPN CB Web site when a stream has errors like the ones mentioned above. In addition, when a NULLANTENNA is found as an antenna type, the station manager is contacted immediately to change the configuration of the stream. The reason is that the NULLANTENNA antenna type means that observations are corrected to refer to the antenna reference point and not to the antenna phase center. This is not allowed within the EPN because real-time EPN data are also converted to high-rate RINEX data, which are supposed to have observables referring to the antenna reference point.

The median stream latencies vary between 0.3 and 3.5 s, depending on the stream and the broadcaster from which they are retrieved. When a stream is consistently exceeding a 5-s latency, the Central Bureau informs the station manager. The 5 s corresponds to the waiting time used within real-time processing software such as the BKG Ntrip Client (BNC; Weber et al. 2016) run at BKG.

Data quality

This section first provides an overall picture of all the different GNSS data quality checks performed by the EPN CB on the daily RINEX data. In the second part, we analyze 23 years of EPN data quality checks.

Quality checks available from the EPN CB

The EPN CB started in 2001 to assess the quality of the GPS observations in the daily EPN observation files (Bruyninx et al. 2002; Kenyeres and Bruyninx 2004) using the TEQC toolkit (Estey and Meertens 1999). In 2011–2012, GLONASS observations were added to the monitoring. In 2015, to handle multi-GNSS observation files and RINEX 3 data, a complete redesign of the quality check monitoring at EPN CB was performed. Today, the data quality checks run on the daily RINEX 2 and RINEX 3 data of the EPN and verify GPS, GLONASS, Galileo and BeiDou observations. They are based on the G-Nut/Anubis software developed by Václavovic and Dousa (2016) and complemented with in-house developed software. They run daily on all new RINEX 2 and RINEX 3 data files, and in addition, all EPN data (more than 2100 k daily RINEX data files) since 1996 have been reanalyzed. In order to compute the expected observations for each constellation at each station location, the quality checks require a priori information on the satellite positions. For that purpose, the combined multi-GNSS broadcast ephemeris files available from the MGEX BRDM archives of the Crustal Dynamics Data Information System (CDDIS 2019) are used. Before the availability of MGEX orbits prior to 2013, the combined multi-GNSS broadcast ephemeris files available from the Geodetic observatory Pecný (Dousa 2019) were used. Only healthy satellites have been considered.

The EPN quality check results are updated daily, and corresponding data quality graphics are available from the EPN Central Bureau Web site (Fig. 5). For each system, they provide information on:
Fig. 5

Examples of the GNSS data quality plots extracted from the daily RINEX 3 data files and available from the EPN CB Web site. Top: evolution of the data completeness of the station BBYS00SVK. Second from top: evolution of the number of missing epochs for the station BOR100POL. Second from bottom: evolution of the number of tracked healthy satellites for the station AJAC00FRA. Bottom: evolution of the number of cycle slips × 1000 divided by the number of observations for the station REDU00BEL. Each satellite constellation is indicated by a different color (see legends)

  1. (a)

    the data completeness, represented by the percentage of actual phase observations with respect to the number of expected observations at the station location (at each epoch, at least one phase observable is expected from a visible satellite). “2+ freq” and “1 freq” indicate, respectively, the percentage with simultaneous phase frequencies on at least two frequencies and on at least one frequency.

  2. (b)

    The number of tracked healthy satellites.

  3. (c)

    The number of missing epochs.

  4. (d)

    The ratio of the number of cycle slips × 1000 with the number of observations.

  5. (e)

    the average RMS (root mean square) of code multipath for each frequency.

To allow comparing the performance of EPN stations mutually, we average the constellation-specific results of the daily G-nut/Anubis runs over the last 28 days for each station. These daily averages are displayed on the EPN CB Web site per constellation and, as shown in Fig. 6, they are very useful to detect clusters of stations whose tracking is worse than at other EPN stations. Figure 6 clearly shows a cluster of EPN stations with degraded dual-frequency Galileo tracking. We will provide more details about this issue later in this paper.
Fig. 6

Galileo dual-frequency tracking performance of all EPN stations as provided at the EPN CB Web site. For each station, the values are the 28-day averaged percentages and their stand deviation of dual-frequency phase observations with respect to the number of expected observations at the station location. IBIZ00ESP is indicated in green, while the other EPN stations are indicated in red

Finally, once a month, a daily RINEX 2 (and RINEX 3, if available) data file of each station is used to generate plots of the number of tracked satellites versus time, the azimuths and elevations of the tracked satellites, and the elevations of tracked satellites versus time (Fig. 7).
Fig. 7

Top: For DOY 002, 2019, and station VIL00ESP, the expected number of tracked satellites (gray background), the actual number of tracked satellites (red), and the number of satellites with observed dual-frequency phase observables (black) as a function of time. Second from top: The elevation of the satellites tracked by the station as a function of time extracted from the RINEX 3 data for DOY 002, 2019, of the station VIL00ESP. Second from bottom: azimuth and elevations of the observations extracted from the RINEX 2 data for DOY 001, 2019, of the station VFCH00FRA. Bottom: The azimuth and elevations of the observations extracted from the RINEX 3 data for DOY 001, 2019, of station MAR700SWE. Each satellite constellation is indicated with a different color (see legends). For all constellations, observations only available on one frequency are indicated in red. The remaining observations are all available on at least two frequencies

Analysis of the results

To obtain a consistent set of data quality check results, all EPN data (more than 2100 k daily RINEX data files) since 1996 have been reanalyzed. For each day, each station, and each constellation, ‘2+ freq above 0°’ (considering all observations), ‘1 freq above 0°’, and ‘1 freq above 15°’ (considering only observations above an elevation of 15°) were computed. Then, for each parameter, its daily median value over all EPN stations was retained and smoothed over 3 months to obtain the general evolution in time of the performance of the tracking of each constellation at the EPN stations (Figs. 8, 9).
Fig. 8

Evolution of the RINEX 2 data completeness. Top plot: 3-month moving averages of the daily median over all stations of 2+ freq above 0°, 1 freq above 0°, 1 freq above 15° for GPS (blue) and GLONASS (red). Middle plot: daily standard deviation of each indicator taken over all stations. Bottom plot: number of EPN stations contributing to the values in the top and middle plots

Fig. 9

Evolution of the RINEX 3 data completeness for Galileo (green) and BeiDou (orange). Top plot: 3-month moving averages of the daily median over all stations of 2+ freq above 0° and 1 freq above 0° for Galileo and BeiDou. Middle plot: daily standard deviation of each indicator taken over all stations. Bottom plot: number of EPN stations contributing to the values in the top and middle plots


The evolution of the RINEX 2 data completeness in Fig. 8 illustrates that for GPS, ‘2+ freq above 0°’ steadily increases from 72% in 1996 to 90% in 2018. It is strongly correlated with ‘1 freq above 0°’, which is just about 2% lower. The increase of ‘1 freq above 15°’ is less pronounced as it has already been above 95% in 1996. In addition, the small standard deviations of the indicators pinpoint that the three indicators are representative for the general improvement of the GPS data quality over the whole network. This demonstrates the degraded tracking at low elevations in the early years and shows how the introduction of all-in-view receivers and more sophisticated receiver tracking algorithms improved low elevation tracking over time.

Also, for GLONASS, the data completeness improves over the years. Before 2009, the evolution of the three indicators and their standard deviation is far from being linear. This is caused by the fact that few stations where submitting GLONASS data at that time. Between 2012 and 2016, the behavior stabilizes; more than 200 stations are tracking GLONASS in this period. From 2016, the degradation of GLONASS ‘2+ freq above 0°’ is caused by several GLONASS satellites with impaired L2 observations (GLONASS constellation status 2019) and it is not due to a general tracking problem in the EPN stations. It clearly demonstrates that the main challenge for triggering reliable data alarms lies in the separation of station-specific from satellite-specific degradations.


The completeness of the Galileo and BeiDou observations in the RINEX 3 data is shown in Fig. 9. For Galileo, single- and dual-frequency results are almost equivalent, which at first sight might be attributed to a superior quality of the Galileo signals. A detailed analysis discovered nevertheless that many stations experience sudden drops in the completeness of the Galileo observations, in both single and dual frequency. Several of these drops happen simultaneously at several stations (Fig. 10) at, e.g., DOYs 155, 215, and 335 of 2018, and 043 of 2019, and they are correlated with an increase in the number of tracked healthy Galileo satellites at the station.
Fig. 10

Daily 2+ freq (0°) and daily number of healthy satellites tracked for Galileo at stations GELL0DEU (top) and DNMU00UKR (bottom)

Figure 11 demonstrates what is happening at one of the affected stations equipped with a LEICA GRX1200 + GNSS receiver: the receiver is not tracking any Galileo observations at low elevations (observations up to 30° of elevation can be affected). This Galileo tracking problem is typically seen at stations equipped with receivers having a limited number of channels and/or measurement engines not designed to track, e.g., more than 4–6 Galileo satellites simultaneously. In the EPN, the effect was seen for LEICA GRX1200 + GNSS, LEICA GR10, and LEICA GR25 receivers, which have 120 channels.
Fig. 11

Elevation versus time of the satellites tracked by the GNSS station TUBO00CZE. The Galileo dual-frequency signals are indicated in green

A second kind of drop in the completeness of the Galileo data occurs seemingly randomly but is correlated with the activation of BeiDou tracking in, again, receivers with a limited number of channels. Figure 12 illustrates how the activation of BeiDou tracking at a GNSS station equipped with a 120-channel receiver caused a drop in Galileo tracking of about 20%. When a 555-channel receiver was installed, the Galileo tracking restored back to normal. The lack of low elevation Galileo data in many of the EPN stations explains why the dual-frequency Galileo tracking performance is comparable to the single-frequency performance and does not reflect the superior performance of Galileo tracking compared to the other satellite systems. In May 2019, LEICA announced the release of a new firmware version for their affected receivers. Although the receiver hardware limitation cannot be changed, first results with this firmware indicate that the Galileo tracking considerably improved without degrading the tracking of other constellations.
Fig. 12

Daily completeness of dual-frequency Galileo (green) and BeiDou (orange) observations


Figure 9 shows a significant degradation of the dual-frequency tracking for BeiDou at the end of 2018. This degradation was triggered by the commissioning of 18 new BDS-3 satellites on December 26, 2018. Normally, the RINEX 3 data of EPN stations observing BeiDou include the L2x, L7x, and L6x (with x: I, Q, or X, see RINEX 3.04 format description, IGS RINEX WG and RTCM-SC 104 2018) carrier phase observation codes. As can be seen from Table 3, few EPN stations provide L6x as the tracking of its frequency is optional in many receivers. The signals of the BDS-3 satellites are, however, slightly different. While L2x and L6x are unchanged, a modernized signal in the B2 frequency band is emitted by the BDS-3 satellites. The L7x signal, which is available for the other BeiDou satellites, is replaced on the BDS-3 by new L7x, L5x, and L2x signals that, again, only very few EPN stations are able to track. As a consequence, to have dual-frequency BeiDou data on the new BDS-3 satellites, the receivers should have activated the L6x tracking option or track the new signals in the B2 frequency band. As can be seen in Table 3, in April 2019, only few EPN stations had this capability, leading to the strong drop of the completeness of dual-frequency BeiDou data as shown in Fig. 9.
Table 3

Number of GNSS receivers in use in the EPN (status: April 2019) tracking a specific BeiDou frequency

Receiver type

































































GPS in RINEX 2 versus RINEX 3

In theory, the completeness of the dual-frequency GPS data extracted from the RINEX 2 or RINEX 3 data should be the same, apart from occasional differences caused by incomplete uploads of one of the daily files to the EPN. Figure 13 illustrates that this completeness is not always identical and that the difference depends on the receiver firmware, which is indicated with different colors. This is not a standalone case as shown in Fig. 14, which demonstrates that the completeness of the dual-frequency GNSS data in the RINEX 2 is about 5% less compared to RINEX 3 for all EPN stations equipped with the JAVAD TRE-3 DELTA and using the 3.7.3 FEB022018 firmware, except one station BORJ00DEU. The station that was unaffected used the EuroNet software from Alberding GmbH to convert the raw station data to RINEX, while the affected stations used JPS2RIN v.2.0.144. In all cases, the problematic RINEX 2 files had a GPS L1 observable that corresponded to L1W in RINEX 3, while the unaffected stations used L1C to map the RINEX 2 L1 observable. This situation was only seen in EPN stations equipped with JAVAD TRE_3, JAVAD TRE_3 DELTA, JAVAD TRE-G3T DELTA, JAVAD TRE-G3TH DELTA, or TRIMBLE NETR9 receivers. Not all the stations were affected because the problem depended on firmware version and conversion software.
Fig. 13

Difference between the daily 2+ freq GPS (0°) extracted from RINEX 2 and 2+ freq GPS (0°) extracted from RINEX 3 of one of the EPN stations equipped with a JAVAD TRE_G3TH DELTA receiver. The colors indicate the successive receiver firmware in use

Fig. 14

Difference between the daily 2+ freq GPS (0°) extracted from RINEX 2 and 2+ freq GPS (0°) extracted from RINEX 3 for all EPN stations equipped with the JAVAD TRE-3 DELTA receiver and using the 3.7.3 FEB022018 firmware

Summary and conclusions

We outlined the activities of the EPN Central Bureau starting with the new GNSS metadata management system M3G, available from, which integrates EU GDPR, the GeodesyML format, and has adaptive metadata validation rules. The ROB runs it operationally to serve both EUREF and EPOS communities and provides already access to metadata from more than 2000 European GNSS stations.

The EPN Central Bureau monitors daily, hourly, and real-time GNSS data distributed within EUREF, as shown in Table 4. The results are displayed on the EPN CB Web site available from
Table 4

Overview of the EPN CB monitoring of the EPN stations


Daily data

Hourly data

Real-time data




Availability and latency




Data quality


To analyze 23 years of EPN data quality checks of daily RINEX data, we focused on the percentage of observed versus expected observations. The impressive improvement of the GPS tracking at low elevations throughout the years is thanks to the modernization of the GNSS receivers. In recent years, some specific receiver/software configurations caused up to 10% less dual-frequency data in the RINEX 2 data compared to RINEX 3 data (same day, same station).

For GLONASS, general degradation of dual-frequency tracking is seen since 2016. The degradation originated nevertheless in the GLONASS satellites and did not reflect tracking problems at the EPN stations. Today, stations equipped with receivers at the lower end of the number of channels are susceptible to suffer from a lack of low elevation (up to 30°) Galileo and/or BeiDou data. BeiDou is in addition confronted with a set of new BDS-3 satellites whose B2 band signal is only tracked by very few EPN stations.

As a conclusion, our experience has shown that multi-GNSS RINEX quality checks remain challenging, especially with respect to the separation of satellite-specific degradations from station/receiver/firmware-specific degradations.



  1. Adam J et al (2002) Status of the European reference frame—EUREF. IAG Symp Ser 125:42–46Google Scholar
  2. Bergeot N, Chevalier JM, Bruyninx C, Pottiaux E, Aerts W, Baire Q, Legrand J, Defraigne P, Huang W (2014) Near real-time ionospheric monitoring over Europe at the Royal Observatory of Belgium using GNSS data. J Space Weather Space Clim 4:A31. CrossRefGoogle Scholar
  3. Boler F, Brown N, Bruyninx C, Johnston G (2017) Progress toward a standard-based XML system for IGS network site log metadata management and dissemination using GeodesyML. Accessed 12 Dec 2018
  4. Brown N, Fraser R, Johnston G (2016) Maximising interoperability and discoverability of geodetic products and services. Accessed 12 Dec 2018
  5. Bruyninx C (2017) Guidelines for EPN stations and operational centers. Accessed 5 Feb 2019
  6. Bruyninx C, Kenyeres A, Takacs B (2002) EPN data and product analysis for improved velocity estimation: first results. IAG Symp Ser 125:47–53Google Scholar
  7. Bruyninx C, Carpentier G, Roosbeek F (2009) The EUREF permanent network: monitoring and on-line resources. IAG Symp Ser 134:137–142. CrossRefGoogle Scholar
  8. Bruyninx C, Habrich H, Söhne W, Kenyeres A, Stangl G, Völksen C (2012) Enhancement of the EUREF permanent network services and products. IAG Symp Ser 136:27–35. CrossRefGoogle Scholar
  9. Bruyninx C, Araszkiewicz A, Brockmann E, Kenyeres A, Legrand J, Liwosz T, Mitterschiffthaler P, Pacione R, Söhne W, Völksen C (2018) EUREF permanent network technical report 2017. In: Villiger A, Dach R (eds) International GNSS service 2017 technical report. IGS Central Bureau and University of Bern, Bern Open Publishing, pp 105–115.
  10. CDDIS (2019) Merged multi-GNSS broadcast navigation files. Accessed 27 May 2019
  11. Dousa J (2019) GOP’s consolidated multi-GNSS navigation data archive. Royal Observatory of Belgium.
  12. Drewes H, Kuglitsch F, Adám J, Szabolcs R (2016) The geodesist’s handbook 2016. J Geod 90(10):907–1205. CrossRefGoogle Scholar
  13. Estey LH, Meertens CM (1999) TEQC: the multi-purpose toolkit for GPS/GLONASS data. GPS Solut 3(1):42–49. CrossRefGoogle Scholar
  14. European Union (EU) (2016) Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation). Accessed 6 Feb 2019
  15. Gendt G (2005) Planned changes to IGS antenna calibrations. Accessed 5 Feb 2019
  16. GLONASS constellation status (2019). Accessed 27 May 2019
  17. Guerova G, Jones J, Douša J, Dick G, de Haan S, Pottiaux E, Bock O, Pacione R, Elgered G, Vedel H, Bender M (2016) Review of the state of the art and future prospects of the ground-based GNSS meteorology in Europe. Atmos Meas Tech 9:5385–5406. CrossRefGoogle Scholar
  18. Gurtner W, Estey L (2012) RINEX: RINEX—the Receiver Independent EXchange format 2.11. Accessed 26 June 2012
  19. IGS RINEX WG, RTCM-SC104 (2013) RINEX—the Receiver Independent EXchange format, Version 3.02. Accessed 7 Feb 2019
  20. IGS RINEX WG, RTCM-SC104 (2015) RINEX—the Receiver Independent EXchange format, Version 3.03. Accessed 14 July 2015
  21. IGS RINEX WG, RTCM-SC104 (2018) RINEX—the Receiver Independent EXchange format, Version 3.04. Accessed 7 Feb 2019
  22. Jeffery KG, Bailo D (2014) EPOS: using metadata in geoscience. In: Closs S, Studer R, Garoufallou E, Sicilia MA (eds) Metadata and semantics research. MTSR 2014. Communications in computer and information science, vol 478. Springer, Cham, pp 170–187. CrossRefGoogle Scholar
  23. Johnston G, Riddell A, Hausler G (2017) The international GNSS service. In: Teunissen P, Montenbruck O (eds) Springer handbook of global navigation satellite systems, 1st edn. Springer, Cham. CrossRefGoogle Scholar
  24. Kenyeres A, Bruyninx C (2004) Monitoring of the EPN coordinate time series for improved reference frame maintenance. GPS Solut 8(4):200–209. CrossRefGoogle Scholar
  25. Nguyen HN, Vernant P, Mazzotti S, Khazaradze G, Asensio E (2016) 3-D GPS velocity field and its implications on the present-day post-orogenic deformation of the Western Alps and Pyrenees. Solid Earth 7(5):1349–1363. CrossRefGoogle Scholar
  26. Nocquet J-M, Calais E, Parsons B (2005) Geodetic constraints on glacial isostatic adjustment in Europe. Geophys Res Lett 32:L06308. CrossRefGoogle Scholar
  27. Pacione R, Araszkiewicz A, Brockmann E, Dousa J (2017) EPN-Repro2: a reference GNSS tropospheric data set over Europe. Atmos Meas Tech 10:1689–1705. CrossRefGoogle Scholar
  28. RTCM (2013) Radio technical commission for maritime services (RTCM) standard 10403.2, differential GNSS (global navigation satellite systems) services, Version 3 with Amendment 2, 7 Nov 2013Google Scholar
  29. Václavovic P, Dousa J (2016) G-Nut/Anubis—open-source tool for multi-GNSS data monitoring. IAG Symp Ser 143:775–782. CrossRefGoogle Scholar
  30. Weber G, Dettmering D, Gebhard H (2005) Networked transport of RTCM via internet protocol (NTRIP). IAG Symp Ser 128:60–66. CrossRefGoogle Scholar
  31. Weber G, Mervart L, Stürze A, Rulke A, Stöcker D (2016) BKG Ntrip client (BNC) version 2.12. Vol. 49 of Mitteilungen des Bundesamtes für Kartographie und GeodäsieGoogle Scholar
  32. Wübbena G, Schmitz M, Boettcher G, Schumann C (2006) Absolute GNSS antenna calibration with a robot: repeatability of phase variations, calibration of GLONASS and determination of carrier-to-noise pattern. In: Proceedings of the IGS workshop 2006 perspectives and visions for 2010 and beyond, May 8–12, Darmstadt, GermanyGoogle Scholar

Copyright information

© Springer-Verlag GmbH Germany, part of Springer Nature 2019

Authors and Affiliations

  1. 1.Royal Observatory of BelgiumBrusselsBelgium

Personalised recommendations