An Enhanced FGI-GSRx Software-Defined Receiver for the Execution of Long Datasets

1. Introduction

The availability of Global Navigation Satellite System (GNSS) software-defined receiver (SDR) platforms have fostered research and innovation in the field of satellite navigation by enabling researchers to experiment with new algorithms, signal processing techniques and applications. GNSS SDRs also offer greater flexibility and customization as compared to traditional GNSS receivers [2,5] by allowing developers to tailor GNSS solutions to specific requirements and integrate them into a wide range of devices and systems. GNSS SDRs also serve as a valuable tool for investigation, reproduction, validation and cross-verification of GNSS signals and by providing open platforms to explore and share raw recorded GNSS in-phase/quadrature (I/Q) datasets [3,4,7,8]. These features enable GNSS SDRs to offer flexibility, adaptability, customization and interoperability for innovation and research over hardware receivers. Advances in computing technology has also enabled a few GNSS SDRs to perform real-time signal processing [5], which is essential for applications such as transportation [9,10], aviation [11], surveying [12], and smart cities [13]. They can also adapt to different signal conditions and interference environments, leading to more robust and reliable GNSS performance. The rapid development capabilities offered by SDRs also support the proliferation of smarter hardware GNSS receivers in growing mass-consumer markets, such as smartphones, wearables, automotive navigation systems [14,15,16], where SDRs cannot themselves compete due to cost, power, or weight restrictions.

The concept of GNSS emerged in the 1970s with the development of the U.S. Global Positioning System (GPS) and the Russian Global Navigation Satellite System (GLONASS). These systems initially used dedicated hardware receivers to process satellite signals for navigation and positioning. The 1990s saw the development of SDRs through the seminal work on real-time GNSS SDR that was first introduced by Akos in [17,18,19], which inspired a lot of research on algorithm development. A GNSS SDR can be described as a software running on a general-purpose computer translating received GNSS signal samples into a position, velocity, and time (PVT) estimate [2]. Since then, the concept has been reused by many research teams who introduced their designs focusing on signal processing algorithms, receiver architectures and performance evaluation.

The data exchange between the various SDRs requires a certain level of standardization. This led up to the development of the ION SDR standard [28]. Broadly speaking, three main categories of GNSS-SDRs have emerged with all of them defined by the use of general purpose processors to process radio frequency (RF) data from an analog front-end in essentially raw form, allowing some configuration flexibility and supporting the ION SDR standard [2]:

• Real-time receivers based on low-level programming languages (C or C++) (such as GRID [20,21], GNSS-SDR [5], Namur [22], TUTGNSS [23] and MuSNAT [24]).
• Post-processing receivers written in a high-level programming language (Python/ MATLAB) for teaching and research purposes (such as FGI-GSRx [1], Borre-SDR [25,26], PyChips [27,28], softGNSS [29] and MATRIX [30,31,32]).
• Snapshot receivers (such as UAB Snapshot GNSS Receiver [33,34]) optimized for very short batches of signal samples.

The availability of open-source GNSS platforms such as RTKLIB [35,36] and SDRs such as GNSS-SDRs [5] and FGI-GSRx [1] has democratized access to GNSS receiver development and experimentation. These platforms have fostered collaboration, knowledge-sharing, and innovation within the GNSS community, leading to the development of new algorithms and applications. Current trends in GNSS SDRs include integration of multiple GNSS constellations (e.g., GPS, GLONASS, Galileo, BeiDou), multi-frequency GNSS processing, enhanced security and authentication mechanisms and the integration of GNSS with other sensor modalities for seamless navigation and localization. The ongoing development of GNSS SDRs often requires the processing of long and diverse datasets (such as datasets collected in urban areas or under adverse weather conditions), multipath mitigation and/or interference rejection. This aids in towards testing the performance of a set of receiver key parameter indicators (KPIs) and enables GNSS receivers to incorporate enough variations within the dataset so that it can be trusted for robust testing.

GNSS SDRs can also be used as an effective tool for detecting and mitigating malicious attacks aimed at disrupting or manipulating GNSS-based positioning and navigation systems commonly known as spoofing and jamming. This may include analyzing the received GNSS signals in detail, including their characteristics such as power levels, integrity metrics and detecting anomalies indicative of spoofing attacks, such as the presence of counterfeit signals or discrepancies in signal properties. Techniques such as signal cross-correlation, and cryptographic authentication such as Galileo’s Open Service Navigation Message Authentication (OSNMA) [37,38,39] can be employed to ensure that the received signal is genuine. OSNMA testing on a SDR also requires processing of longer datasets along with the need for faster processing. The Finnish Geospatial Research Institute (FGI) developed an open-source Python engine, FGI-OSNMA, for OSNMA based navigation message authentication [42] of Galileo E1B signal [40,41,43]. In a recent development, FGI-OSNMA is incorporated with the FGI-GSRx software receiver to enable OSNMA-based position authentication capability [44]. This integration will facilitate further research on the actual use of OSNMA in the context of obtaining an authentic position solution, especially in the absence of any signal or message level authentication mechanism with other existing GNSS systems.

To summarize, the constant evolution of GNSS, such as, inclusion of modernized signals and new services offered by the GNSS constellations, requires regular updates for GNSS SDRs. This will ensure continued functionality, security, and effectiveness in meeting users’ needs and expectations. Therefore, in this paper we are presenting an improved and updated version of FGI-GSRx henceforth named as FGI-GSRx-v2.0.0. The major improvement in v2.0.0 is carried out by incorporating key design strategies, while focusing on one vital aspect, i.e., faster execution. These features are specifically aimed to facilitate processing of long datasets. This paper also presents the assessment of old and new versions of FGI-GSRx by considering some of the design aspects and KPIs, specific to the assessment of performance of software-defined GNSS receivers [45].

The rest of the paper is structured as follows: Section 2 presents an insight into the receiver architecture of FGI-GSRx-v1.0.0 and its limitations. Section 3 presents the FGI-GSRx-v2.0.0 design and architecture and a proposed parallel tracking mode. Assessment and data processing methodology is explained in Section 4. This is followed by performance analysis of both versions of FGI-GSRx on a dataset in Section 5. Section 6 offers some concluding remarks on the current work while presenting some highlights on the future work.

2. FGI-GSRx Software-Define Receiver

FGI’s multi-GNSS software receiver was released as open-source in February 2022 [1] along with the book GNSS Software Receivers [47]. It is a MATLAB-based GNSS receiver that operates only as a post-processing receiver for raw I/Q GNSS data samples. The development of the FGI-GSRx was initiated from the work of Borre et al. [25] in 2012, in which a GNSS software-defined receiver was developed for tracking two IOV satellites (GIOVE A and GIOVE B) from the European Galileo. This was followed by the inclusion of Galileo in 2013 [48], the Chinese satellite navigation system BeiDou in early 2014 [49], the Indian regional satellite navigation system NavIC in late 2014 [50], and the Russian satellite navigation system GLONASS in 2015 [51]. The evolution of FGI-GSRx from a GPS-only receiver to a more extensive receiver supporting GNSS signals from multiple constellations (GPS, Galieo, BeiDou, GLONASS and NavIC) offers diversity and makes it an excellent resource for researchers. The software receiver is already being used in the ‘GNSS Technologies’ course offered in several Finnish Universities.

2.1. Existing Sequential Receiver Architecture

The processing chain of FGI-GSRx-v1.0.0 consists of GNSS signal acquisition, code and carrier tracking, decoding of the navigation message, pseudorange estimation, and PVT estimation as shown in Figure 1. The receiver’s salient features are listed in Table 1. As can be seen in Figure 1, the receiver allocates channels to all the acquired satellites, and then it continues to track each satellite sequentially one at a time for each time epoch until it finishes executing the last data sample. There is no dependency among the channels in this traditional tracking approach, and therefore, it would have been optimum to utilize some form of parallelism to run all the tracking channels in parallel. This parallel tracking execution strategy is considered as one of the key KPIs for faster execution of the receiver when implementing the next version of FGI-GSRx, i.e., v2.0.0. This will be further illustrated in Section 3.

2.2. Limitations of FGI-GSRx-v1.0.0

The current open-source version of FGI-GSRx-v1.0.0 is being used in GNSS receiver development research and in benchmarking SDR solutions in the GNSS industry. Its architecture provides a great opportunity to build and test new algorithms without the need to make extensive changes to the original code. The receiver was designed to facilitate a great deal of flexibility in terms of different key parameters at different stages of receiver signal processing chain from acquisition to navigation. For that reason, the receiver’s memory allocation and the computing resource management was not optimal. As an example, many of the signal tracking variables were saved for the whole data length, thus consuming memory and computing resources when the data sizes grow significantly. This is especially considered a bottleneck when processing long datasets are needed to analyze in some certain test cases, for example, to analyze the performance of OSNMA service of Galileo.

3. FGI-GSRx-v2.0.0: Design and Architecture

The limitations identified in Section 2.2, served as the motivation to suggest improvements and introduce new features in the latest release of FGI-GSRx. The latest release of FGI-GSRx, henceforth referred to as FGI-GSRx-v2.0.0, is developed to overcome some of the limitations of the previous version by focusing on using the following design strategies. It is important to mention here that the integrity of the initial receiver design is preserved in the new v2.0.0 while optimizing and improving the receiver architecture. In the following, the design strategies for a GNSS SDR are introduced first before the presentation of the v2.0.0 architecture.

3.1. Design Strategies for Software-Defined GNSS Receivers

The evaluation process of a GNSS SDR can be broadly classified into incorporating design strategies and formulating effective assessment methods. The following subsection provides an insight into the focus areas pertaining to design strategies that were considered in the development of FGI-GSRx-v2.0.0. Several strategies can be employed to optimize the processing speed without sacrificing accuracy, functionality, usability, etc. A brief review of some of these strategies that are considered in this work is mentioned below.

• Code Profiling: This refers to identifying performance bottlenecks through code profiling and optimizing critical sections of the code base. This may involve restructuring algorithms, minimizing function call overhead, and optimizing memory access patterns to improve overall processing speed. A significant effort was made in this regard for the development of v2.0.0 that included identifying the functions and processes contributing maximum processing time and removing redundant variables and computations. This effort lead to improved tracking time via v2.0.0 sequential mode as compared to v1.0.0. A more detailed insight is presented in Section 5.1 and Section 5.2.
• Memory Management and Parallelization: Parallel processing techniques and efficient memory management of the processing unit can lead to minimize memory access latency and improve overall processing speed. FGI-GSRx-v2.0.0 parallel processing mode is aimed at distributing computational tasks by invoking multiple MATLAB instances so as to utilize the maximum processing power of the processing units, such as CPU cores. This can significantly speed up signal processing algorithms, especially those that are inherently parallelizable, such as correlation and FFT (Fast Fourier Transform) operations. An analysis on performance of memory management using various versions of FGI-GSRx is shown in Section 5.3.

3.2. FGI-GSRx-v2.0.0 Receiver Architecture

FGI-GSRx-v2.0.0 is developed to overcome existing shortcomings in v1.0.0 by focusing on the design strategies presented in Section 3.1. Figure 2 presents the data flow of v2.0.0 architecture which is similar to v1.0.0. The three main blocks (Acquisition, Tracking and Navigation) offered by v2.0.0, inherently follow the same functional methodology as v1.0.0 with the exception of the tracking block. A brief description of these blocks is presented below.

• Acquisition: The acquisition block searches and acquires satellite signals one at a time. The signals are handed over to the tracking block once the search is complete. v2.0.0 also supports multiple GNSS constellations as v1.0.0. The acquisition data contains the information regarding each signal acquired (observations, duration, signal, channel) as well as statistics from the acquisition phase (e.g., peak Metric, peak value, variance, baseline, standard deviation, code phase, carrier frequency and satellite ID).
• Tracking: The tracking block utilizes the acquisition data and correlates the incoming signal with signal replicas to generate tracking measurements from all signals and satellites. In v1.0.0, the signal tracking of each satellite is processed sequentially which was not very effective especially for the processing of longer datasets leading to higher processing time. To overcome this limitation, in v2.0.0, the user can conveniently choose between two possible options to execute the tracking process. These include:

  -

  Sequential Tracking Mode: This mode is developed on the similar lines as v1.0.0. However, v2.0.0 offers an improved sequential tracking architecture, which is carried out by code profiling, efficient handling of data variables, identifying and optimizing high complexity and time consuming processes that ultimately contributed to faster data processing.

  -

  Parallel Tracking Mode: Parallel tracking mode is aimed at maximizing the CPU utilization to speed up the processing. The parallel processing is done at the signal tracking stage only, since this is the most computationally extensive part of the receiver. The idea is to initiate multiple parallel instances of MATLAB for processing each satellite individually to achieve maximum CPU utilization from the processing platform. In this particular case, the operating system takes care of running multiple instances by allocating enough resources for these demanding parallel instances. For example, if there are altogether 17 GPS and Galileo satellites available from the acquisition stage, the new receiver architecture will open 17 MATLAB instances where each instance will process one individual tracking channel. The work flow diagram of v2.0.0 parallel tracking block is divided into three main steps as shown in Figure 3.

• Multi-GNSS Navigation: This block offers data decoding of the output generated from the tracking block and converts the processed track data into receiver observables in terms of satellite-specific pseudoranges and ephemeris for each GNSS constellation. The navigation block has four main tasks: to convert the measurements into observations, calculate each satellite’s PVT, apply satellite and environmental corrections, and finally estimate the PVT solution of the user with the corrected pseudoranges.

3.2.1. FGI-GSRx-v2.0.0 Parallel Tracking Mode

The detail settings and procedure to execute each step is described in the user manual (for both Windows and LINUX platforms) which is available for download from FGI-GSRx-v2.0.0 online repository [57]. It is pertinent to mention here that while parallel tracking mode speeds up the processing, the user has to manually go through all steps of parallel processing listed above which adds complexity to the usability of the receiver.

3.3. Other Functional Enhancements

All the modifications in FGI-GSRx-v2.0.0 from v1.0.0 are highlighted in the v2.0.0 release note [57]. Most of these modifications are on the source codes that deal with optimization of memory and computing resources. Apart from that, the most significant functional update is in the signal acquisition where a two-stage acquisition is introduced. The two-stage acquisition algorithm is very effective in mitigating the correlation peak splitting effect caused by the presence of bit sign transitions in the signal segments, in particular with modern GNSS signals where bit transition may occur within the data blocks during the traditional Fast Fourier Transform (FFT) based acquisition [6].

In case of a successful first step acquisition of a particular satellite, the receiver proceeds with a second acquisition stage for the fine estimation of carrier doppler of the acquired satellite. The receiver obtains the code phase and the carrier doppler of the acquired satellite from the first stage as input to the second stage. At the second stage, the receiver advances the code phase of the satellite so it starts the correlation of the received signal with the local replica code from the beginning of the code epoch, thus avoiding any possibility for bit transition within the data block. In addition to that, the receiver also refines the carrier doppler from few hundreds of Hertz (Hz) to within $\pm 25$ Hz by appropriately tuning the frequency step in the FFT-based search space. A representative two-stage acquisition plot is shown in Figure 4. It can be seen that the two-stage acquisition correctly estimates the carrier Doppler for Galileo PRN 34 at 1725 Hz, whereas after the first stage acquisition, the estimated Doppler is 1625 Hz. This acquisition result was obtained with FGI-GSRx software receiver with 4 milliseconds (ms) of coherent integration and 2 blocks of non-coherent summation in order to show the advantage of two-stage acquisition to solve the problem of bit sign transitions within the acquisition signal segments. With this above acquisition configuration (i.e., 4 ms of coherent integration and 2 blocks of non-coherent summation), FGI-GSRx-v1.0.0 acquires Galileo PRN 34 with 1625 Hz, thus leading to bit error at the navigation stage due to not locking to the right carrier frequency. This phenomenon can be avoided with two-stage acquisition in FGI-GSRx-v2.0.0.

4. Assessment and Data Processing Strategy

This section provide the data processing and assessment strategy utilized to provide a common framework for unbiased and effective performance comparison of FGI-GSRx-v1.0.0 and FGI-GSRx-v2.0.0.

4.1. Assessment Strategies

To assess the performance and development of v2.0.0, some key performance indices (KPIs) are considered. These assessment methods are aimed at providing a platform for measuring the improvement and can be considered as a valuable tool for bench-marking [46]. In a bid to streamline this process, a generative list of 16 KPIs related to GNSS SDRs is presented in [45]. It is also impractical to expect an analysis against all potential measures and published methods. Therefore, for the development of v2.0.0, a subset of six points were selected as they are relevant to our scope and are explained in Table 2.

4.2. Data Processing Strategy

In order to ensure fairness in comparison, all the simulations were run on a dedicated processing unit whose details are given in Table 3.

The reference dataset used in this paper was recorded as open sky signal captured by Septentrio’s PolarNt Choke Ring antenna at FGI, Finland. The true receiver position is at 60.182°N, 24.828°E with an altitude of 47.248 meters (m). A dual-band RF front-end from Nottingham Scientific Limited (NLS) is used to down convert the captured GNSS signal into the raw I/Q format required for processing by FGI-GSRx. The details of the reference dataset are given in Table 4. The signal settings (or user requirements) used in this analysis are the same for all versions of FGI-GSRx and are presented in Table 5 where non-coherent normalized early minus late (NNEML) was used as the DLL discriminator function. A more detailed explanation of the receiver’s acquisition and tracking techniques can be found in [54] and [55]. Figure 5 illustrates the sky plot for both GPS and Galileo satellites recorded on October 30, 2023 at around 14:19:06 UTC. There are 11 GPS and 6 Galileo satellites acquired with both the versions of FGI-GSRx. The raw I/Q dataset is publicly available in [58].

5. Result Analysis

The development of FGI-GSRx-v2.0.0 was carried out by considering the design strategies (Section 3.1) while focusing on improving the design KPIs (Section 4.1) to overcome the limitations of v1.0.0. All the versions of FGI-GSRx are programmed in the MATLAB environment. The underlying design methodology is the same for both versions. However, some functions are optimized to cater for faster and accurate processing in the later release. The source code for both versions of FGI-GSRx is supported by the book GNSS Software receiver along with raw GNSS data files, default user settings and processed data files. That means that the user could also utilize v2.0.0 for processing the open data files utilized in GNSS Software receiver. The v2.0.0 is also supported by an additional user manual to incorporate the parallel processing mode (addressing both Windows and LINUX settings). This section presents a detailed insight and discussion into the performance comparison of both versions of FGI-GSRx through various aspects.

5.1. Code Profiling

In the bid to execute faster processing, code profiling was done to identify the functions and processes that were contributing to the maximum processing time. These functions were reviewed and optimized by reducing unnecessary computations, variables and memory access. An insight into some of the functions contributing to the maximum run time particularly from the tracking block is presented in Table 6. These functions were modified in the new version and the resultant improvement achieved by v2.0.0 with respect to v1.0.0 in terms of the time taken to run each function is also discussed in Table 6. v2.0.0 also offers some new functionalities with the addition of parallel tracking mode and multicorrelator processing. The detailed description of modifications and new additions are not in the scope of this paper however, they are available in the FGI-GSRx-v2.0.0 release note [57] and user manual for a more through insight for the interested readers.

5.2. Data Processing

The FGI-GSRx receiver architecture allows us to analyse the efficiency of the data processing blocks as a modular structure. It gives users the flexibility to evaluate three core blocks (Acquisition, Tracking and Navigation) individually as well as collectively. Taking advantage of this functionality, Table 7 presents an insight into the run time accumulated by each block in different versions of FGI-GSRx. The acquisition block of v2.0.0 offers an extra step to offer fine acquisition which is the reason for the higher acquisition time by v2.0.0 which was explained in Section 3.3. For the presented dataset, navigation processing time for v2.0.0 is slightly higher than v1.0.0 mostly due to the processing of higher number of satellites in the PVT computation, although the navigation block offers the same code functionalities for both versions. A more insight into this is presented in Section 5.4. The maximum run time is consumed by the tracking block in all the competing cases. This observation also served as the inspiration to introduce the parallel processing mode for v2.0.0. It can be observed that v2.0.0 reduces the total processing run time by approximately 40% as compared to the previous version. The added feature of a parallel processing block further improves the total simulation run time by approximately 59% for the given dataset.

5.3. Resource Management

FGI-GSRx-v2.0.0 specifically aims at improving the processing time, which is vital for processing of long datasets. The processing unit (or CPU) utilization for both versions of FGI-GSRx is presented in this section to analyse the resource management and utilization. It is important to mention here that to ensure a fair comparison, the processing unit was only processing FGI-GSRx during the recording of the CPU usage.

Figure 6 presents the CPU utilization for both versions using the sequential tracking mode using all satellites. On average, approx. 21% of CPU resources were utilized during the entire simulation interval for both versions. The v2.0.0 offered a more uniform distribution of resources as compared to v1.0.0. Therefore, it can be concluded that, in terms of Recourse Management, the optimization of core functions enabled the much improved usage of the processor by v2.0.0. It was previously highlighted in Table 7 that the maximum processing time is utilized by the tracking block of the receiver. This motivated us to develop the parallel processing block for processing only the tracking block via v2.0.0 by utilizing the CPU respurces more effectively. Figure 9 shows the CPU usage while processing v2.0.0 parallel processing mode. The average CPU usage can be seen to be approx. 85% which is significantly higher than the sequential processing mode. This is also the reason for the significant improvement in overall processing time by v2.0.0 as presented in Table 7.

5.3.1. Comparison with MATLAB Parallel Processing Toolbox

MATLAB also offers a similar parallel processing feature via parallel computing toolbox (PCT). Parallel computing toolbox takes advantage of the available computer resources by distributing tasks and executing them in parallel. It accelerates the code by creating a parallel pool of MATLAB workers using interactive parallel computing tools, such as parfor and parfeval to provide automatic parallel support. For the default local profile, the default number of workers is one per physical CPU core using a single computational thread. The processing unit used in this analysis is supported by 14 CPU cores.

Table 8 presents a comparison of performance for v2.0.0 parallel mode and with MATLAB PCT for variable number of satellites. For the processing of 6 Galileo satellites, the CPU usage by both receivers is shown in Figure 7. The processing time is almost same for both entities however, v2.0.0 parallel has a higher average value of 69% as compared to 38% by MATLAB PCT. However, when we processed GPS only constellation of 11 satellites, MATLAB PCT showed an improved performance of 30% while keeping the average CPU usage at a lower rate of 58% as compared to v2.0.0 parallel mode’s average CPU usage of 90% as presented in Figure 8.

A similar trend is also observed when we processed both GPS and Galileo satellites (a total of 17 satellites). As opposed to v2.0.0 where 17 MATLAB instances were initiated simultaneously for processing, PCT initially facilitates 14 channels and accommodate remaining channels accordingly. This can be seen in Figure 9 where the processing is done in a more distributed manner as compared to v2.0.0 parallel mode performance presented in Figure 9. This limitation is hardware driven and may result in faster or slower processing based on the number of available cores of the processing unit. Figure 9 presents the recorded CPU utilization while processing v2.0.0 with the MATLAB PCT for this scenario. FGI-GSRx with MATLAB PCT offers an average CPU usage of 60% which is lower than v2.0.0 parallel processing average but it resulted in faster processing time (43% improvement over v2.0.0 parallel tracking mode).

To summarize, MATLAB PCT offers improved performance as compared to v2.0.0 parallel mode especially when the number of satellites to be processed is higher. But MATLAB PCT’s performance is also dependent on the number of available cores of the processing unit. The superior performance of MATLAB PCT could be accounted to the optimized resource management offered by MATLAB inbuilt functions. It is also important to mention here that the PCT toolbox is a paid toolbox offered by MATLAB whereas v2.0.0 parallel mode does not depend on PCT toolbox.

5.4. Accuracy

To investigate the accuracy assessment criteria, an insight into the stand-alone static position accuracy is presented. For the presented datasets, 11 GPS and 6 Galileo satellites were acquired in the acquisition stage by both versions of FGI-GSRx. Figure 10 shows the obtained position solution by both versions of FGI-GSRx using the sequential processing mode. The positioning solutions obtained by both versions used the ionosphere final product from IGS (International GNSS Service), which is provided in IONEX (Ionosphere Exchange) format [56]. This is also followed by a detailed analysis presented in Table 9 that includes indices for position solution such as 3D root mean square (3DRMS) error, dilution of precision (DOP), horizontal and vertical position deviations, etc. It is pertinent to mention here that the code functionalities are the same at the navigation level for both versions. The reason for difference in the position accuracy values is the availability of higher number of satellites in case of v2.0.0 than v1.0.0.

6. Conclusions

This paper presents the latest update of the FGI’s open-source GNSS software-defined receiver ’FGI-GSRx’ while analyzing the performance of its new receiver tracking architecture. In particular, the FGI-GSRx-v2.0.0 release offers improvements in two main areas: i) functional optimization, and ii) faster processing at the signal tracking stage compared to the previous version by introducing parallel tracking architecture as an added tracking option. The improved performance of v2.0.0 was verified by assessing a few pertinent key performance indices and bench-marking its performance using the MATLAB parallel computing toolbox. Additionally, v2.0.0 offers two-stage acquisition and an optimized performance as compared to v1.0.0. The usability of the new architecture is slightly more complex for parallel processing than sequential processing, but it facilitates faster processing of the receiver’s tracking block, which is a significant advantage, especially for the processing of longer datasets which is a necessary requirement to facilitate cryptographic authentications such as Galileo’s Open Service Navigation Message Authentication. It is also important to mention that the source code for v2.0.0 and the dataset presented in this paper are shared as open-source by the National Land Survey of Finland.