Introduction

GNSS receivers must apply corrections to compensate for deterministic errors, such as satellite orbit and clock, to reach decimeter-level positioning accuracy. This is typically performed in real time by connecting to a third-party receiver or a real-time kinematic (RTK) network, allowing relative positioning with differential GNSS (DGNSS) techniques. Those techniques require a separate data link (e.g., cellular connectivity) and often a service subscription. For instance, the international GNSS service (IGS) provides real-time access to precise orbit and clock corrections via the Internet (Elsobeiey and Al-Harbi 2016). To eliminate the need for a separate data link, classic broadcasted ephemeris and satellite-based augmentation system (SBAS) messages are viable real-time correction options. However, the performance guarantees of SBAS and classical broadcast messages exceed one meter, as demonstrated by Ali et al. (2012), Montenbruck et al. (2015), Pan et al. (2017), and Park et al. (2020). As an alternative to broadcast and SBAS messages, GNSS corrections are also delivered by commercial services through geostationary (GEO) satellites, requiring a service subscription.

In recent years, the Galileo High Accuracy Service (HAS) has been introduced as a free-of-charge service. It is designed to enable stand-alone GNSS receivers with no separate data links to achieve 20 cm and 40 cm accuracy in horizontal and vertical positions (95%), respectively (European Union 2023). To achieve this goal, Galileo HAS broadcasts real-time correction data for Galileo and Global Positioning System (GPS) on the E6 signal. The signal is not encrypted, implying that any E6-capable receiver can benefit from the HAS free-of-charge. Alternatively, if the user terminal has internet connectivity, Galileo HAS also provides an internet-based service. Early Galileo HAS tests have shown that the service can already offer the expected service accuracy when Galileo is combined with GPS. Fernández-Hernández et al. (2022) conducted the first assessment of the performance of Galileo HAS. Their findings demonstrated that the system provides extensive coverage while achieving a few-centimeter broadcast correction accuracy. Later, Naciri et al. (2023) obtained a positioning accuracy better than 20 cm (95% confidence level interval) in kinematic mode. Martini et al. (2023) also carried out a positioning performance assessment, assuming a static case and a road environment with obstructions. Results of the static case showed an accuracy better than 3 cm and 8 cm (1-sigma) in horizontal and vertical components, respectively. The dynamic test revealed a horizontal positioning error of 26.7 cm (1-sigma) in environments with degraded visibility, which was four times superior to that of a code-based solution. The benefits of Galileo HAS are also extended to precise orbit determination (POD) of satellites in low earth orbit (LEO). Hauschild et al. (2022) made significant improvements in 3D orbit determination of Sentinel-6A by incorporating HAS corrections into their near-real-time processing. They achieved an orbit determination error of approximately 7–9 cm, which is an advancement compared to the method relying solely on broadcast ephemerides corrections, which yielded a less accurate accuracy of 17–20 cm.

The Galileo HAS corrections are designed to have global validity for precise point positioning (PPP) assisted by state space representation (SSR) corrections. Despite Galileo HAS is centered on PPP, the corrections can be implemented in single-point positioning (Angrisano et al. 2023) or incorporated into differential techniques. However, as opposed to DGNSS, where Radio Technical Commission for Maritime Services (RTCM) standards are widely supported, PPP does not have a globally adopted standard for the provision of HAS correction data. The standardization of the RTCM SSR format has been pending for several years. Alternatives have been proposed in the meantime; however, many of them are very similar to RTCM SSR. Galileo HAS corrections are provided in their own format, reminiscent of the compact SSR format (Hirokawa et al. 2016). Furthermore, they are encoded into so-called high-parity vertical Reed Solomon (HPVRS) codes for optimizing the HAS message reception from multiple satellites (Fernández-Hernández et al. 2020). As a result, legacy GNSS receivers and PPP processing software that solely depend on GNSS data links are unlikely to be able to benefit from the HAS without a software upgrade.

To facilitate the use of Galileo HAS with legacy receivers and software, the HASlib package was developed by Horst (2021), as a contribution to the European Commission’s Precise and Authentic User Location Analysis (PAULA) project (Horst et al. 2022). While some HAS decoders have been developed to analyze HAS results, for example, in Hauschild et al. (2022), open-source alternatives to HASlib have appeared only recently (Borio et al. 2023). HASlib is an open-source application that decodes the HAS HPVRS-encoded navigation data frames and converts the corrections to either RTCM-SSR or IGS-SSR. The HAS corrections generated from HASlib can be input to any GNSS receiver or PPP processing software that supports RTCM-SSR or IGS-SSR correction data streams, even if they do not natively support HAS. We validate the implemented package by showing a proof-of-concept result of processing Galileo HAS corrections with the open-source RTKLIB package. RTKLIB (Takasu 2013) was selected as it can provide real-time PPP solutions when aided by RTCM 3 messages. We aim to show the potential of Galileo HAS, HASlib, and RTKLIB to provide free-of-charge real-time solutions with high accuracy. In this regard, the next section describes the context of the open-source services. The proof-of-concept test is shown in Results section. The final conclusions are then outlined.

Open-source HAS decoder and PPP engine

Sub-meter GNSS positioning requires the availability of a service to provide correction data. Such data can be expressed in various formats, requiring a processing engine supporting the provided correction data. The adopted positioning services, data formats and used open-source library are presented in this section. Figure 1 shows the workflow to obtain the PPP solutions. GNSS receivers gathered data in the Septentrio binary (SBF) file format. Subsequently, the collected data were processed through HASLib, which transforms the input file into SSR corrections. These SSR corrections are transmitted with a recognized standard by RTKLIB and serve as the foundation for computing PPP solutions to various forthcoming user applications. We utilized SBF files to construct a post-processing dataset, simplifying our investigation and facilitating the creation of a supplementary document. However, in real-time applications, HASlib must be applied with GNSS data streams through transmission control protocol (TCP) or serial ports. When applied in real time, our setup demonstrated the capability to generate an end-to-end result in around 2 s per epoch.

Fig. 1
figure 1

End-to-end architecture to access PPP solutions based on Galileo HAS and open-source software

Full size image

Open-source HAS decoder package

Three main principles drove the design of HASlib. First, the implementation must not consume too many computational resources to allow real-time operation on various platforms. Second, it should be portable, not dependent on commercial software or libraries, as well as easy to use and integrate into existing projects and workflows. Third, the library should be straightforward to configure or modify. To achieve this, the library was designed for easy adoption by emphasizing modularity, code readability and easy extension through a clear interface. The modular structure enables a straightforward reuse of the whole library or its parts in the future. Different interfacing methods were developed for input and output data: streams, files, and TCP connection. The input data can be read from streams and files in SBF and binary exchange format (BINEX) (UNAVCO 2020). The output modes support two of the most meaningful representations, RTCM-SSR (RTCM 2013) or IGS-SSR (IGS 2020). To accommodate future needs, adding new input and output formats is also designed to be as straightforward as possible.

The top-level architecture of the decoder library is illustrated in Fig. 2, followed by Table 1, which describes the most important HASlib classes and their functionalities. The HASlib decoder is publicly available on the GitHub platform (National Land Survey of Finland 2022) and released under the European Union Public License (EUPL) with a copyright owned by the European Union.

Fig. 2
figure 2

HASlib high-level architecture and data flow

Full size image
Table 1 Description of the most important HASlib classes and their functionalities
Full size table

As part of the HAS Message Collector class, an important step of HASlib is the optimization of the time needed to download data. To this end, HASlib exploits the availability of several satellites by decoding the messages in a Reed–Solomon scheme. The HAS corrections are received from several Galileo satellites simultaneously at a rate of 448 bits per second and per satellite (European Union 2023). The Reed–Solomon encoding distributes the information content of 32 data pages over a total of 255 redundant encoded pages. The original message length, k, is dependent on the amount of information transmitted in the HAS message. Each page consists of 424 bits of information. In order to decode a single message consisting of k ≤ 32 pages, the receiver needs to receive any k different encoded pages to recover the information. In other words, the amount of information to be downloaded remains constant. Note that in practice, HAS messages can be shorter than 32 pages, in which the remaining pages are filled with zeros. If the messages are transmitted in the optimal way, this scheme enables an efficient dissemination of data (Senni et al. 2022).

Reed–Solomon encoding (Reed and Solomon 1960) is a linear operation in a Galois field. Consequently, both encoding and decoding operations can be expressed as matrix multiplication inside this field. Let \(c\) represent the 32-element message vector. Then, it can be encoded with the generator matrix \({\mathbf{G}}\) to the code vector \({{\varvec{\Gamma}}}\) of length 255 as (European Union 2023):

$${{\varvec{\Gamma}}} = \left[ {\begin{array}{*{20}c} {c_{0} } \\ {c_{1} } \\ \vdots \\ {c_{31} } \\ {\gamma_{0} } \\ {\gamma_{1} } \\ \vdots \\ {\gamma_{222} } \\ \end{array} } \right] = \left[ {\begin{array}{*{20}c} {\varvec{c}} \\ {\varvec{\gamma}} \\ \end{array} } \right] = \left[ {\begin{array}{*{20}c} {\mathbf{I}} \\ {\mathbf{P}} \\ \end{array} } \right]{\varvec{c}} = \user2{G c}$$
(1)

where the generator matrix \({\mathbf{G}}\) is composed of blocks \({\mathbf{I}}\) and \({\mathbf{P}}\). The top block \({\mathbf{I}}\) is an identity matrix of size 32 × 32, implying that the first 32 elements of the 255-page sequence are the original HAS message pages in clear text. The bottom block \({\mathbf{P}}\) is a dense matrix with size 223 × 32, and it corresponds to the remaining 223 parity pages.

This formulation makes the decoder straightforward to implement without the need for specialized algorithms. First, the received encoded pages are collected according to the page identifier which can be found in the clear-text page header. Then, once the necessary number \(k\) of different pages has been received, the message bytes are vertically grouped into words, and the decoding matrix \({\mathbf{G}}^{ - }\) is formed as a \(k \times k\) matrix with the corresponding rows of \({\mathbf{G}}\) in the same order. The obtained matrix \({\mathbf{G}}^{ - }\) is invertible, and it is applicable to each vertical word; consequently, one matrix inversion is sufficient to decode the entire message. Reed–Solomon encoding and decoding, including the definition of the generator matrix \({\mathbf{G}}\), is explained in more detail in the interface control document (European Union 2023).

Open-source PPP software package

There are diverse options for PPP processing, ranging from receiver built-in features to commercial and open-source software. One of the most popular open-source packages for precise GNSS processing is RTKLIB. Its first release took place in 2006 and it is still being developed, allowing PPP processing with a cm-level accuracy (Prol et al. 2018). The current stable RTKLIB version (v. 2.4.3 b34) only supports the finalized RTCM SSR messages, implying that there is no support for PPP with the Galileo HAS without internet access. HASlib is used to cover this gap, enabling the conversion of Galileo HAS messages to RTCM 3. In this scheme, the satellite orbit and clock corrections provided by Galileo HAS messages are employed by RTKLIB. However, RTKLIB currently lacks the capability to incorporate the transmitted code biases. Therefore, we are not utilizing the HAS code biases in the RTKLIB PPP results. Instead, we let the code biases be absorbed mainly by the carrier phase ambiguity term and receiver clock. Details of how to employ the absolute code biases are shown in Villiger et al. (2019). As for the phase biases, Galileo HAS is not providing them yet, so they cannot be used in our PPP solution, and therefore no integer ambiguity resolution can be performed. For more details, Schaer et al. (2021) illustrate the potential advantages of incorporating phase bias in PPP implementations.

To exemplify the magnitude of the corrections not employed by RTKLIB, Fig. 3 shows the differential code bias (DCB) values computed based on Galileo HAS messages, which requires the code bias corrections by default. Note that these unapplied code biases, while up to some decimeters, do not introduce a similar error in the PPP solution as they are compensated by the filter as part of the float carrier phase ambiguity term and the receiver clock. Therefore, they do not lead to a commensurate error in the position solution. To substantiate this point, we refer to Villiger et al. (2019), who emphasize the impracticality of distinguishing between clock corrections and the associated bias terms. Moreover, the IGS real-time working group (IGS 2020) acknowledges that biases may be excluded in PPP with SSR messages because they cannot be differentiated from phase ambiguities in certain situations. This limitation is applicable only to cases where ambiguity resolution is not intended and for short durations, as the inter-signal biases (ISB) might not remain constant over time. Additionally, from our perspective, code biases are necessary for positioning if the user processes measurements different from those of the network. For example, code biases are necessary if the user processes 1C/2P while the network uses 1W/2W. However, if both the network and the user use the same measurements, code biases are not needed for positioning, although they may be necessary for timing. Given these considerations, appropriate configurations are necessary in RTKLIB to overcome the absence of code bias corrections. This includes the estimation of float ambiguities and utilizing identical measurements used in satellite clock and signal bias estimation.

Fig. 3
figure 3

DCB values related to the signal biases of the ionosphere-free combination determined from the Galileo HAS messages on February 8, 2023, from 13:00 to 16:00 UT

Full size image

Table 2 presents the configurations employed in RTKLIB. As these options are specifically tailored for real-time applications, they effectively reflect the potential of PPP in field campaigns. Users can rely on these configurations to obtain accurate and reliable results during their operations with Galileo HAS, HASlib, and RTKLIB. However, it is essential to note that the authors have not applied any specific tuning to enhance the PPP algorithm. Consequently, this study showcases the inherent accuracy of RTKLIB, which may not fully reflect the accuracy of HAS corrections and expected convergence time, given that the RTKLIB software is not specifically developed to use Galileo HAS. RTKLIB utilizes the extended Kalman filter (EKF) with undifferenced observations to compute the solutions in PPP modes. Despite utilizing a static station, a kinematic mode is selected to evaluate the convergence time with a dynamic PPP solution. In the static mode, only three unknowns are defined for the coordinates, whereas the kinematic mode incorporates three unknowns with each epoch. This approach enables a more precise assessment of the time required to achieve a stable solution for most user applications.

Table 2 RTKLIB configuration settings for real-time PPP aided by Galileo HAS corrections
Full size table

The L1/L2 frequencies are used for GPS, while for Galileo, the E1/E5b frequencies are employed. The two frequencies enable the ionospheric-free (IF) linear combination (LC). The estimation of zenith tropospheric delay (ZTD) is performed during the PPP process aided by the Saastamoinen model (1973) and Niell mapping function (Niell 1996). Considering that the visibility is reduced at the high latitudes in Finland, a low cut-off angle of 7° is defined. The used antenna phase center (APC) models are based on the IGS corrections released in the antenna exchange format (ANTEX) files. To account for the Galileo HAS corrections, the satellite orbit and clock are estimated using the broadcast ephemeris and corrected by the HAS-based SSR messages referring to the APC location. No strategies are selected for ambiguity solutions as code bias corrections are not applied.

Results

The PPP assessment is conducted based on Galileo HAS data collected by raw GNSS measurements and HAS navigation data frames on five representative days between February 8 and 13, 2023. The data collection was conducted by a commercial off-the-shelf Septentrio PolaRx 5 receiver in Finland. The collected data in SBF format were processed by HASlib and converted to RTCM 3 messages. The functionality of the open-source services is validated by parsing the output of HASlib to the RTKLIB package. The interfaces are then applicable to generate accurate PPP results in real time.

Four configurations in RTKLIB are evaluated and compared. Table 3 summarizes all the configurations. These configurations were defined to represent the positioning modes and constellations that users will most likely apply in real-case experiments. They were applied to two stations, named rooftop and MPAS (Fig. 4). The rooftop station is in the premises of the Finnish Geospatial Research Institute (FGI) in Espoo, Finland (60.2° N, 24.8° E). The MPAS station is a monitoring station situated 6.2 km from the rooftop station. The station is positioned on top of a building near Helsinki city center within an urban environment characterized by numerous surrounding buildings and structures. The reference location of both stations was determined by the AUSPOS online GPS processing service v.2.3 (Geoscience Australia 2021) with final IGS corrections and daily GNSS data.

Table 3 Positioning modes employed for comparison against PPP with Galileo HAS messages
Full size table
Fig. 4
figure 4

Environment surrounding the rooftop and MPAS stations

Full size image

Figure 5 illustrates the results in the rooftop station with an arc of three hours on February 8, 2023 (13:09–16:10 UTC). We did not include the PPP-IGS results in this analysis, as they exhibit comparable accuracy to PPP-HAS at the scale of Fig. 5. A dedicated comparison between the two methods is provided subsequentially for enhanced visualization. By visual inspection in Fig. 5, we have identified that enabling HAS corrections allows to overcome other exclusively GNSS-based solutions by an order of magnitude. SPP-BRDC and SPP-SBS provided a meter-level accuracy, while PPP-HAS allowed centimetric accuracy. The PPP-HAS, therefore, demonstrates a clear advantage over typical positioning strategies that lack external data links beyond the GNSS-provided information. It must be noticed that the first minutes of PPP-HAS are related to the convergence time required for a stable solution. Furthermore, we have made the dataset and a comprehensive guideline for replicating this experiment available in the Supplementary document.

Fig. 5
figure 5

Comparison of positioning solutions using real-time GNSS corrections broadcasted by the GNSS satellites. BRDC denotes the classic broadcast messages provided by GPS, Galileo, GLONASS, and Beidou, while SBS represents SBAS messages for GPS. PPP solutions were exclusively enabled by HAS corrections

Full size image

To further explore the capabilities of Galileo HAS in the rooftop station, Fig. 6 shows a comparison of the real-time PPP HAS solution (PPP-HAS-GPS/GAL) against a post-processed PPP solution, which includes final and accurate PPP corrections processed by IGS in a multi-GNSS environment (PPP-IGS-GPS/GAL/GLO/BDS). Again, these results are related to arcs of three hours on February 8, 2023. We have adopted the horizontal and vertical convergence times as the duration needed to achieve and stabilize the solution below 20 cm and 40 cm for horizontal and vertical accuracy, respectively. These threshold values align with the study conducted by Naciri et al. (2023) and the Galileo target performance metrics established by EUSPA (2020). A convergence time of around 11 min was obtained using Galileo HAS corrections, while IGS final products allowed a 3.8-min convergence time. We assume the convergence criterion is met when the horizontal and vertical components cross the predefined threshold values.

Fig. 6
figure 6

Vertical errors (top panel) and horizontal errors (bottom panels) of the rooftop station. PPP was carried out with two different correction sources: HAS corrections (shown in red) and final IGS corrections (shown in black). HAS corrections have been derived directly from the GNSS receivers in real time and processed with GPS and Galileo systems. IGS corrections, which include final SP3 products from GPS, Galileo, GLONASS, and Beidou, have been obtained days after data collection. The PPP processing strategies utilized both open-source codes from HASlib and RTKlib

Full size image

The top panel in Fig. 6 shows the vertical error, while the bottom panels show the horizontal error. The RMS was computed considering all values after the convergence time. In the vertical component, the Galileo HAS corrections allowed an RMS error (1-sigma) of 8.6 cm after convergence time, while the post-processed PPP enabled 4 cm accuracy. In this particular case, the predominant factor influencing convergence time was the vertical component. In the horizontal component, both solutions have shown a 1-sigma Circular Error Probable (CEP) of 9 cm after the convergence time, with an overall bias to the north direction. A bias in the horizontal component is expected within the post-processed PPP as the GNSS receiver is located at a high latitude (over 60°N in geographical latitude) and the GNSS coverage does not fully cover the Northern region, as shown in the sky plot example of Fig. 7. Although the largest errors in the HAS corrections are affecting the vertical component, we observe a comparable and biased level of accuracy in the horizontal component.

Fig. 7
figure 7

GPS and Galileo polar coordinates observed by the rooftop station collected during a three-hour data arc on February 8, 2023

Full size image

Figure 8 illustrates the PPP results obtained at the MPAS station. This example serves to reinforce the notion that the performance achieved at the rooftop station extends to other test cases. As demonstrated, the accuracy of PPP HAS remains around 10 cm, which is similar, but slightly inferior, to post-processed PPP. Additionally, this example requires a longer convergence time. The solution consistently hovers around the convergence time threshold (below 40 cm) for several minutes, nearly reaching 40 cm within the first 10 min. However, only after 20 min did the accuracy surpass the threshold. Similarly, the rooftop station also experiences resistance, with the vertical error remaining close to 40 cm for a brief period. However, the rooftop station accuracy reaches below 40 cm two times faster. The primary factor contributing to the lower accuracy in MPAS is the challenging urban environment, which is highly susceptible to signal multipath and obstruction. Both solutions (HAS PPP and post-processed PPP) present worse accuracy in MPAS when compared to the rooftop.

Fig. 8
figure 8

Same as Fig. 6, with the exception that it represents the MPAS station, located 6.2 km away from the rooftop station

Full size image

Figure 9 shows the rooftop results when 32 arcs of three hours are formed on February 9–12, 2023. Again, we show results based on PPP with HAS corrections and PPP with final IGS corrections. Both methods are capable of providing positioning accuracy within the expected thresholds below 20 cm and 40 cm for horizontal and vertical components, respectively. However, in this case, the convergence time was considerably larger. Although the vertical component could converge to below 40 cm within an average time span of 5 min, the horizontal component took an average of 01:30 h to converge to below 20 cm with Galileo HAS and 15 min with IGS corrections.

Fig. 9
figure 9

PPP error of RTKLIB aided by HASlib at the rooftop station. The PPP solution is computed using several three-hour arcs spanning the period from February 9–12, 2023. The shadowed colored areas in the figure represent the standard deviation

Full size image

Figure 10 (bottom panels) illustrates the accuracy of HAS corrections in the cases analyzed in Fig. 9. The top panels of Fig. 10 display the accuracy of HAS corrections used to generate Fig. 6, surpassing the precision of Fig. 9. In Fig. 10 (bottom panel), HAS corrections exhibit an accuracy level of approximately ± 0.25 m, with an average error centered at − 0.5 cm and a standard deviation of ± 0.22 m (2 sigma). In contrast, the top panel shows an average error centered at zero and a standard deviation of ± 0.19 m (2 sigma). This suggests that more accurate HAS corrections improve PPP accuracy and reduce convergence time. The performance of the HAS corrections around ± 0.25 m compares well against prior research (Fernández-Hernández et al. 2022; Naciri et al. 2023). However, the convergence time in Fig. 9 is longer than reported in literature. Martini et al. (2024) achieved a 15-min overall convergence time in static mode using GPS and Galileo data, while Naciri et al. (2023) reported a 7.5-min convergence time in PPP-HAS with kinematic mode at 33 IGS stations using GPS and Galileo observations. To justify the prolonged convergence time, we attribute it to the fact that the PPP engine was designed to use HAS corrections specifically in these previous studies, whereas RTKLIB was initially developed for broader and more generic applications. Additionally, our solution faced challenges in maintaining accuracy below the 20 cm horizontal threshold in Finland due to geometric deficiencies. Positioning components with the lowest observational redundancy absorbed a significant portion of the orbital errors, contributing to the prolonged convergence time in the horizontal component.

Fig. 10
figure 10

Accuracy of orbital and clock data from the HAS corrections in relation to IGS final orbit files in the 3-h period of February 8, 2023 (top panels) and from February 9–12, 2023 (bottom panels). Each color represents a different satellite. The histogram is obtained merging both orbit and clock errors in bins of 1 cm

Full size image

Table 4 summarizes the average accuracy achieved in all days analyzed. The evaluation performance is presented in terms of absolute bias, standard deviation, and RMS. In each processing mode, the statistics were calculated based on results obtained after the PPP-HAS solution reached convergence. Like the analysis in Fig. 5, the SPP processing strategy with broadcast ephemeris presents the worst solution, with an absolute error of 3 m and a standard deviation of about 0.7 m in both horizontal and vertical components. It is interesting to observe that SPP with SBAS corrections exhibits a similar standard deviation but achieves a better average error, around 0.7 m. This outcome highlights the effectiveness of SBAS solution in mitigating systematic errors and maintaining the solution accuracy within the level of the code measurement noise. As for the PPP results, centimeter-level accuracy is achieved when utilizing both HAS and post-processed corrections after the convergence time. An important aspect accentuated by these findings is the relatively higher standard deviation observed in the PPP with HAS corrections, especially in the vertical component, as compared to post-processed PPP.

Table 4 Absolute mean (\(\mu\)), standard deviation (\(\sigma\)), and RMS of the horizontal and vertical errors obtained using each positioning mode in the rooftop station
Full size table

Summary and conclusions

We presented an integration of HASlib and RTKLIB to provide open-source access to Galileo HAS. The HASlib has been written in Python and it decodes the HPVRS-encoded HAS correction messages and outputs them in either the RTCM 3 or the IGS SSR format. In this first release, the supported input formats are SBF and BINEX. The library architecture was designed to be easily extensible to other input and output formats, with particular interest in RTCM 3, which is adopted by RTKLIB.

The experimental results validate that the HASlib interfaces are compatible with the open-source RTKLIB package, enabling the HAS corrections to improve the positioning precision by one order of magnitude over classical real-time solutions with broadcasted and satellite-based augmentation data. In comparison to post-processed multi-GNSS PPP, a comparable level of accuracy was achieved in the horizontal component, with longer convergence time and worse accuracy in the vertical component, but still under 20 cm (1-sigma). In total, HASlib makes it possible to use Galileo HAS with receivers and software that do not support HAS outside of the box. Nevertheless, our investigation has identified a longer convergence time in RTKLIB for enabling PPP solutions, primarily attributed to the software's filtering together with geometry-related issues in high latitudes. More extensive testing and verification of the library is foreseen, especially considering future developments of RTKLIB and Galileo HAS.