Assessing the Quality of Products and Latest Performance of Galileo HAS (High Accuracy Service) Using Real-Time Data ^†

Abstract

The Galileo High Accuracy Service (HAS) offers free, real-time precise point positioning (PPP) corrections via Galileo (E6-B) and internet, supporting Galileo (E1, E5a, E5b, E6) and GPS (L1, L5) signals. As of Service Level 1, HAS provides SSR orbit, clock corrections, and biases, achieving decimeter-level accuracy (20 cm horizontal, 40 cm vertical) within 300 s (95th percntile), per the HAS ICD. This study compares HAS products with other analysis centers, verifying declared accuracy. Using a Septentrio Mosaic X5 GNSS receiver, real-time HAS data was collected over three weeks, verified against CODE products, and assessed for PPP performance under various scenarios to evaluate HAS reliability for high-accuracy positioning. The analysis has shown that HAS products provide superior accuracy for Galileo (9.6 cm URE) over GPS (14.0 cm URE) and enable decimeter-level positioning convergence within 3–5 min, although significant outliers were detected in the GPS clock corrections.

1. Introduction

The International GNSS Service (IGS) launched its Real-Time Service (RTS) in 2013 [1] to meet growing demands for real-time precise point positioning (RT PPP), which relies heavily on accurate satellite orbit and clock data. While SBAS systems like WAAS and EGNOS offer meter-level accuracy, newer space-based PPP augmentation services—such as BDS PPP-B2b [2], QZSS CLAS [3], and Galileo HAS—provide decimeter to centimeter accuracy with varying convergence times. The European Galileo HAS, still in its initial phase as of May 2025, broadcasts corrections via the E6 signal and NTRIP, achieving reported horizontal and vertical accuracies below 20 cm and 40 cm, respectively, with convergence times under 300 s [4]. Recent studies [5,6,7,8] confirm HAS offers high-quality SSR corrections and positioning performance comparable to CLAS and PPP-B2b. Ref. [7] reports 15 cm horizontal and 20 cm vertical accuracy with a 638 s convergence time, while [9] notes static repeatability at the centimeter level even for low-cost receivers. Software tools like HASlib [10], GHASP [11], and NavDecoder [12] are crucial for decoding and integrating HAS corrections, which are in a proprietary format similar to Compact SSR. However, integration into mainstream PPP engines remains challenging due to the lack of standardization. Finally, studies like [13,14] highlight the need for real-time anomaly detection, as even small unflagged HAS correction errors can degrade RT-PPP reliability in critical applications.

The main purpose of this paper is to experimentally compare the products provided by HAS with other analytical centers to verify the claimed accuracy and to assess the reliability and potential of HAS for high-precision positioning applications, especially in the context of aviation. The experiment consisted of several steps. Firstly, real-time HAS data was collected over a period of 3 weeks using a Septentrio Mosaic X5 GNSS receiver with a high-precision antenna mounted on the roof of a building. The second step was to verify the integrity of the dataset and compare it with finalized CODE (Centre for Orbit Determination in Europe) products. In the third step, the performance of the HAS-based PPP solution was evaluated under different circumstances (GNSS positioning with Galileo HAS corrections in static and UAV kinematic experiments) and using different data processing strategies. The paper ends with a conclusion section.

2. Corrections Generation Process

The generation of HAS corrections begins with the Galileo Sensor Stations (GSSs), a global network of 15 ground stations that collect raw data from Galileo and GPS satellites. This data is transmitted to the High Accuracy Data Generator (HADG), a key module responsible for computing precise corrections. The HADG processes the incoming data to generate corrections for satellite orbits, clocks, and biases.

Generated corrections are output in so-called Compact SSR format (CSSR). Unlike traditional correction methods that rely on observation-specific data, CSSR provides satellite-specific error corrections—such as orbit, clock, and bias adjustments—in a state-based format. This format is designed to be highly efficient, minimizing data size, in case of Galileo HAS, via high-parity vertical Reed–Solomon encoding [4].

Once generated, the corrections are relayed to users through two channels: the Galileo E6-B signal for direct satellite-based dissemination and an NTRIP (networked transport of RTCM via internet protocol) caster for internet-based distribution.

3. Product Analysis

3.1. Raw Product Quality Analysis from HAS

As a first step in assessing HAS products’ quality, a raw correction analysis was performed. Since the orbit corrections showed no outliers, no further analysis was required. The situation with clock corrections is somewhat different. While these corrections were stable for Galileo satellites throughout the entire duration of the experiment, the situation is worse for GPS. Numerous outliers were found in the on-board clock corrections for GPS. The outliers occurred on different days and at different times with no obvious systematic pattern and ranged from 2.6 m to 6.1 m depending on the day and satellite. As an example, Figure 1 shows the value of the clock corrections on day 342 of 2024 for GPS satellite G19.

Table 1. Outliers for GPS clock corrections during the experiment.

DOY	Time	Value [m]	Satellite
342.2024	19:36	6.13	G19
345.2024	20:00	2.61	G20
346.2024	12:34	3.21	G16
349.2024	8:46	4.41	G07
353.2024	16:18	3.82	G15
354.2024	12:41	3.76	G03
357.2024	3:55	4.05	G19

shows the date and time of the largest outlier for each day, their value relative to the daily average for all GPS satellites and the corresponding satellite, for which the largest outlier has occurred.

Such outliers can be attributed to the fact that Galileo HAS is still in test mode or possibly to the fact that the time of the survey coincided with the peak of solar activity. In the statistical analysis, such erroneous values were rejected. When performing positioning, corresponding epochs were excluded.

3.2. Comparison with CODE Final Products

CODE provides three different products, depending on the time required to form them—Ultra-Rapid (URAP), Rapid (RAP), and Finalized (FIN). The FIN products yield the highest accuracy, with orbits being precise up to 2–5 cm and clocks up to 10 cm (in range) [15], so they were chosen as a reference in this work. For an adequate comparison, several factors should be taken into account:

• The HAS orbital corrections, once applied, relate the satellite coordinates to the ionosphere-free antenna phase center (APC), while CODE provides the corrected satellite position, which is related to its center of mass (COM). To compensate for this effect, the ANTEX file igs20.atx was used to calculate the offset between APC and COM [16].
• Corrections to the on-board clocks from HAS and CODE refer to different signal combinations (HAS_GPS–C1C-C2P, HAS_GAL–C1C-C7Q, CODE_GPS–C1W-C2W, CODE_GAL–C1C-C5Q). To compensate for this shift, the DCB products from CAS were used [16].
• Another factor in comparing time corrections is the systematic bias inherent in different data centers. This offset does not affect the user, as it will be absorbed by the receiver’s clock. Therefore, in the comparison, the average value of the differences for GPS and Galileo was calculated and eliminated for each epoch [16].

To perform such analysis, corrections must be decoded and correctly applied. For that, a Python script was developed based on NavDecoder [12]. The NavDecoder contains several handy utilities, such as high-parity vertical Reed–Solomon (HPVRS) data decoding, downloading broadcast data, and transforming decoded data into several formats, which include SSR and SP3. The output data is well suited for performing positioning with it; however, it cannot be compared to CODE due to the reasons mentioned earlier. Having that in mind, a modified version of NavDecoder was developed. Apart from decoding corrections, it applies several transformations to make them comparable with CODE, performs epoch aligning, and differentiates them. URE analysis, which is performed in a latter section, is based on the output data from the developed script.

Table 2. RMS values for HAS products in RAC frame.

	dr [cm]	da [cm]	dc [cm]	dt [cm]
GPS	6.4	6.7	6.4	13.0
GAL	6.1	6.4	6.0	7.8

shows the RMS for radial, along-track, and cross-track components, as well as clock products.

The RMS values for the Galileo orbit components are consistently slightly better than those for GPS. The most significant difference is observed in the clock component, where the Galileo clock product RMS of 7.8 cm is substantially better than the GPS clock product RMS of 13.0 cm.

3.3. Long-Term URE Analysis

Since a direct comparison of products does not always reflect their impact on positioning, the user ranging error (URE) metric was calculated. The URE describes the error in the modeled pseudorange caused by errors in the broadcast orbit and clock information. This indicator can be calculated both locally, taking into account the specifics of the area, and globally. The global average URE value, according to [17], is calculated as follows:

$$URE=\sqrt{{\left(\delta R-{\delta }_{CLK}\right)}^2+0.0192\left(\delta A^2+\delta C^2\right)}$$

(1)

where $\delta R, \delta A, \mathrm{a}\mathrm{n}\mathrm{d} \delta C$ are the differences in radial, along-track, and cross-track components, respectively, and ${\delta }_{CLK}$ is the difference for clock products.

Figure 2 displays the URE value for each day of the static experiment for GPS and Galileo constellations.

For the GPS constellation, the average URE value for the entire study period was 14.0 cm. The Galileo value was significantly better, at 9.6 cm. This result indicates that the Galileo products exhibited notably superior quality compared to the GPS products during the experiment. The values were slightly higher than those obtained in similar studies, such as [16,18], especially for GPS constellation.

4. Processing with Independent Software

4.1. Software and the PPP Model

To evaluate the accuracy and stability of PPP positioning using Galileo HAS, we chose the raPPPid software product [19]. This open-source software, developed by the Technical University of Vienna (TU Wien), enables the processing of GNSS observations in highly adaptable PPP approaches and is suitable for high-quality to low-cost data. Its main advantage is the ability to customize the processing strategy in an extremely flexible way and the ability to use code biases provided by HAS.

The PPP models implemented in raPPPid mainly differentiate in the handling of the ionospheric delay. The two main options are the conventional PPP model based on two signal frequencies for building the ionospheric-free linear combination (IF LC) and the uncombined model managing any number of frequencies.

4.2. Description of Experimental Data

4.2.1. Static Experiment

The main goal of the static experiment was collecting HAS data for long-term analysis and comparison with CODE, as well as assessing positioning performance. For that, an antenna was mounted on the roof of the building in Ivano-Frankivsk, Ukraine, and connected to a Septentrio Mosaic X5 receiver (Septentrio, Leuven, Belgium). This receiver is well suited for this task, as it is capable of receiving the E6B signal from Galileo. The data were collected from DOY 338.2024 to DOY 006.2025 with a recording interval of 10 s. The reference coordinate for this static experiment was determined in PPP-AR mode, using all available constellations and signals.

4.2.2. Kinematic Experiment

This experiment aimed to assess PPP with HAS in kinematic mode on a moving object. A GNSS receiver was mounted on a DJI Matrice 350 drone (SZ DJI Technology Co., Ltd., Shenzhen, China), which executed a pre-programmed flight mission near the city of Sobieszyn, Poland. The chosen territory is well suited for such tests, as it is located close to a reference station RYKI, which is part of Polish RTK network ASG-EUPOS. The mission lasted 20 min, sufficient to evaluate both the convergence time and positioning accuracy of the PPP-HAS solution. Contrary to static data, kinematic processing was carried out in RTKLib [20]. This software is better suited for processing kinematic data, and as a good addition, has a wide range of plotting functions. A reference trajectory was derived in RTK mode using data from the RYKI base station. This setup allowed for a detailed analysis of the system’s performance in dynamic, real-world conditions.

The collected data was processed using the following settings, shown in

Table 3. Processing strategy for collected data.

Parameter	Strategy
GNSS used	GPS, Galileo
Frequencies	GPS: L1/L2; GAL: E1/E5A
Filter	Iterative Kalman filter, forward
Elevation cutoff	7°
Weighting	Elevation-dependent Standard deviation of raw observations: code—30 cm; phase—3 mm
Satellite antenna offset	has14_2345.atx
Interval	10 s/1 s for static/kinematic
Orbit/clock/code bias	Galileo HAS
Tropospheric delay	Saastamoinen + GPT3 mapping function
Ionospheric delay	Two-frequency ionosphere-free LC
Phase ambiguity fixing	No (float solution)

.

5. PPP Result Analysis

5.1. Positioning Productivity Analysis

In this section, detailed analysis of the positioning performance utilizing Galileo HAS products is provided. The RMS values of each coordinate, as well as convergence, are analyzed. The horizontal and vertical convergence times are defined as the durations required to achieve and maintain accuracy below 20 cm horizontally and 40 cm vertically, as per the Galileo target performance metrics [4]. The root mean square (RMS) of position errors is evaluated over the entire processing period excluding the convergence phase.

Three processing periods were chosen for assessing static positioning—20 min, 1 h, and 3 h. Figure 3 displays the results of PPP HAS positioning against a reference coordinate during DOY 345, with a 20 min interval.

Longer observation periods revealed slight coordinate drift, which affected positioning precision, with the 1 h test showing [13.7, 10.9, 13.1] cm RMS (N, E, H) and the 3 h test achieving [12.6, 12.1, 14.9] cm RMS. Such drift is possibly linked to changing satellite geometry, though coordinate differences remained within the 20/40 cm vertical requirement.

In case of kinematic processing, similar results were obtained. Figure 4 displays the coordinate difference, separately for each coordinate, against a reference trajectory for the whole duration of the flight mission.

Here, convergence for N and H occurs rapidly, within first 3 min of flight. As for the E component, it shows a constant displacement of ~20 cm and never falls below this value. This systematic bias, not seen in static tests, suggests potential unmodeled effects, such as receiver-specific biases or multipath from the drone’s airframe, requiring further investigation. RMS values were [7.3, 16.9, 19.7] cm for N, E, and H components, respectively.

5.2. Comparison of Galileo HAS with CNES SSR Correction Stream

The CNES SSR products, part of the PPP-Wizard project, provide precise real-time corrections for GPS, GLONASS, Galileo, and BeiDou satellites to enable real-time PPP. However, as opposed to Galileo HAS, CNES products also provide phase bias corrections, which allow for integer ambiguity resolution. Galileo plans to include those corrections into HAS during the next phase, but as of now, they are not present.

In order to analyze the possible impact of enabling phase bias corrections in HAS, the positioning with CNES products was analyzed. Figure 5 shows the 20 min positioning results with CNES products in float solution against a reference coordinate.

The float solution comparison has shown an important trade-off: while CNES products showed slightly better horizontal accuracy, the HAS solution provided significantly superior vertical accuracy (8.6 cm RMS vs. 20.0 cm for CNES). This highlights a different modeling performance, with HAS offering a more robust vertical solution before ambiguity resolution.

However, after enabling the phase biases and fixing ambiguities, the results change drastically. Figure 6 displays the positioning results with fixed ambiguities.

Fixing integer ambiguities caused a drastic improvement, shifting the solution from decimeter-level to centimeter-level precision. The post-convergence RMS values improved to 1.88 cm (north), 0.88 cm (east), and 3.96 cm (height), while the convergence time to reach such accuracy was 2.5 min. Those results emphasize the importance of phase bias products in PPP positioning, especially for navigation purposes where fast convergence is crucial for the safety of aviation operations.

5.3. Consolidating on PPP Results

The evaluation of Galileo HAS for PPP demonstrates its effectiveness for aviation navigation. This performance is well suited for aviation applications—such as precision approaches or drone navigation—where vertical accuracy and rapid initialization are critical. Compared to traditional PPP, where no external source of corrections is used, HAS reduces convergence time from 15–20 to 3–5 min. However, challenges were also identified, such as the persistent −20 cm offset in the kinematic East component and the reduced precision observed in longer static sessions. The comparison with CNES SSR correction streams, which include phase biases for integer ambiguity resolution, suggests that future HAS enhancements could halve convergence times to around 2.5 min and further improve accuracy. With its dual dissemination via satellite and internet, HAS also offers redundancy, enhancing availability for aviation use. Overall, Galileo HAS is a valuable asset for aviation navigation, with planned upgrades promising even greater precision and reliability.

6. Conclusions

This study provides a detailed analysis of the Galileo High Accuracy Service, focusing on its applicability to aviation navigation. The analysis encompasses the correction generation process, product quality, and PPP performance.

Product analysis against the CODE final products showed that HAS corrections display good accuracy, although outliers in GPS clock corrections were found; these ranged from 2.6 m to 6.1 m. These anomalies, likely due to HAS’s test mode or heightened ionospheric activity, posed challenges to real-time correction integrity.

PPP performance further underscored HAS’s potential. Static tests achieved convergence to below 20 cm horizontally and 40 cm vertically within 5 min, meeting aviation’s stringent requirements. Kinematic tests on a drone showed rapid convergence for north and height components within 3 min, though the east component exhibited a 20 cm offset, indicating areas for refinement. Comparison with CNES SSR corrections, which include phase biases, suggested that future HAS enhancements could halve convergence times to 2 min and boost accuracy further.