Performance Evaluation of a Multi-frequency GPS/Galileo/SBAS Software Receiver

The real-time capable software GPS/Galileo receiver [1], developed at the Institute of Geodesy and Navigation at the University FAF Munich, has been completely redesigned. Figure 2: ipexSR: the software receiver can running on a notebook, connected via USB to the Front-end. Within this paper we would like to discuss the most innovative features, analyze its performance and present an overview of its possible applications. The receiver is intended to work on a conventional PC, processing IF samples coming from a USB Front-end or from previously stored data files. The provided GUI shows detailed internal data as well as comprehensive information about the tracked satellites. A very important feature is that numerous receiver parameters can be set during the runtime. Several tests have been performed connecting high bandwidth L1 and triple frequency (L1/L2/L5) Frontends, specially developed to guarantee the very big transfer rate required for real time processing of such a large amount of data. Acquisition is based on a FFT-IFFT scheme, optionally enhanced with an indoor specific algorithm that performs parallel interference cancellation. For signal tracking, the receiver can run two different filter modes: the first is a order-configurable PLL/FLL/DLL, while a second one is represented by a third order PLL and aided FLL and DLL. The sensitivity that can be reached is about 10 dB-Hz. Advanced code multipath mitigation techniques have been implemented by the optimization of the correlators reference functions. Big effort has been put on the development of various core elements that enable the receiver to acquire and track even highly attenuated signals, as they may occur in an indoor environment. Concerning acquisition, the Doppler search space has been reduced to allow longer integration times and a vector re-acquisition technique is used for tracking signals that show high variable power characteristics. The tracking loop design itself and the bit/symbol synchronization module have been also optimized in this sense. Code phase ambiguity can be resolved by exploiting the so-called single-shotpositioning, in case a very inaccurate PVT solution is available. At the present the receiver can track all-in-view civil GPS and EGNOS signals, as well as the Galileo In-Orbit Validation Element GIOVE-A. A navigation message decoder for the CNAV message that will be sent with the GPS L2C/L5 signals has already been integrated, together with the one for the Galileo I/NAV message. The navigation solution can be obtained by Single Point Positioning or by a Kalman Filter estimate. Current performance shows accuracy levels which are better than 30 cm for code measurements and 1 mm for carrier phase measurements respectively. Beside the ordinary navigation features, a series of support services has been added to increase the performance, offer new capabilities and extend the receiver application field. The possible applications of the receiver are as a GNSS reference/monitoring station and as a powerful development platform for new algorithm prototyping. A version of the software receiver is currently working twenty-four-seven as GPS/Galileo/SBAS reference station, providing measurements obtained from GPS C/A and L2C, EGNOS and GIOVE-A E1-E5a broadcast signals. A first evaluation of the reference station performance is shown in Figure 1. Figure 1: Code minus Carrier pseudorange measurements over a 15 hours interval for the tracked GPS C/A and L2C CM signals. INTRODUCTION The ipexSR is a High-end real-time capable GNSS software receiver, intended to be run on a conventional PC (Figure 2). It is currently in its third phase of development, coming after single-frequency predecessors and presenting significant innovations. It can receive and track signals coming from all-in-view satellites of different GNSS (GPS/Galileo) and SBAS, offering precise positioning as well as reference station/monitoring services. The receiver can process IF samples coming in real-time from a USB Front-end or from recorded data streams, read from conventional storage media. Table 1 describes the characteristics of the triple frequency Frontend which is currently in use. It has been developed by the Fraunhofer Institute of Integrated Circuits and exploits a special data transfer scheme that allows a transfer rate up to 312,5 Mbps, necessary for a continuous processing of the triple frequency samples stream. Frequency Bandwidth Sample Rate ADC Res. L1, E1 15/20 MHz 40.96 MHz 2/4 Bits L2 15/20 MHz 40.96 MHz 2/4 Bits L5, E5a 15/20 MHz 40.96 MHz 4 Bits Table 1: Some characteristics of the triple frequency Front-end connected to the software receiver. The receiver has been developed as a set of C++ classes, grouped into modules, with well defined input and output data. The implementation follows an accurate UML diagram design, where one of the main purposes is maximum re-usage of the source code. Algorithm and data structures which are common to two or more receiver classes are implemented as base class, while the particular features can be specified in the derived ones. The code is partly optimized with assembler instructions to ensure better real-time capabilities; the use of multi-threading helps reducing the processing time. Before presenting the most interesting features of the software receiver, a look over the entire architecture is given. ARCHITECTURE The block diagram depicted in Figure 3 illustrates the architecture of the ipexSR. Figure 3: Overall software receiver architecture. After receiving IF-samples from the extern, the whole signal processing is controlled by a so-called Master Receiver. It has several receiver units attached, each tracking a specific GNSS service. One single receiver unit comprises a number of different channels, each tracking one satellite signal. The receivers share most part of the C++ source code, employing a universal tracking scheme which however can be configured in a different way for each of them. One major difference between different receiver units is given by the navigation message decoder. Since signal acquisition turns out to be the most time consuming process, a specific unit has been dedicated to it also in order to have a more careful control. This is composed of an Acquisition Manager and level 1 and level 2 FFT acquisition sub-units: level 1 is responsible for high-power signals while level 2 for high-sensitivity acquisition. In contrast to level 1, the level 2 unit searches only a limit Doppler region. Going further, the navigation processor retrieves the pseudorange measurements from the master receiver and passes them to one or more navigation modules. These modules perform various actions going from single-pointpositioning to signal quality monitoring. A description of the receiver main tasks can be found here, while other services and features appearing in the block diagram are discussed in later sections. Signal Acquisition The task of the acquisition module is to perform a first estimate of the code phase and Doppler frequency of the incoming signals and is the most time consuming step in the software receiver. In our module, signal acquisition is performed in two ways: a first option consists in calculating the acquisition output parameters using a previously computed navigation solution, in case receiver position, satellite ephemerides and clock errors are available. Should such information be unavailable, then the receiver switches automatically to conventional FFT-based signal acquisition. The receiver performs it in one common step for all different GNSS signals successively. Signal acquisition has two levels according to the required sensitivity. To acquire strong signal components, the receiver uses the conventional coherent acquisition algorithm. For weak signal detection, a combination of coherent and noncoherent integrations can be used [2]. A parallel search within the code delay domain is implemented via FFT correlations. The acquisition algorithm is based on the maximum likelihood criteria where signal parameters are estimated from the likelihood cost function. Figure 4 shows the 3D acquisition window of the software receiver, the correlation peak of the acquired satellite is clearly visible. Figure 4: 3D Acquisition plot generated by the software receiver when acquiring a GPS satellite. For the high-sensitivity acquisition, more sophisticated routines are implemented which include non-coherent summation (squaring or differential); also strong signal interference cancellation is applied. Signal Tracking A schematic diagram of the used unified approach for the signal tracking module is depicted in Figure 5. Figure 5: Representation of the tracking scheme for a generic