Abstract
The GNSS software receiver has evolved as a promising tool for researchers and developers because of its flexibility and reconfigurability. As modernized GNSS signals have been emerging day by day, the need to adapt the software receiver to address the upcoming challenges of GNSS navigation has become inevitable. The main aim of this work is to assess the existing Global Navigation Satellite System Software Defined Receiver (GNSS-SDR) tool for Indian Regional Navigation Satellite System (IRNSS) signals using a low-cost RTL-SDR front-end. The IRNSS software receiver chain is developed using GNSS-SDR code and framework. GNSS-SDR is an open-source tool developed by the Centre Tecnològic de Telecomunicacions de Catalunya (CTTC) of Spain. This work is useful for carrying out various GNSS-related applications using IRNSS signals in the future and paves the way for further research and development of the IRNSS system by using it as a research/academic tool.
1 INTRODUCTION
The Indian Regional Navigation Satellite System (IRNSS) was developed by the Indian Space Research Organization (ISRO) of India with an operational name of NavIC (Navigation with Indian Constellation). IRNSS/NavIC signals cover India and the region extending up to 1,500 km from its political boundary. It provides two levels of service: Standard Positioning Service (SPS) for civilian users and Restricted Service (RS) for military and strategic purposes. The space segment of IRNSS/NavIC consists of three geostationary Earth orbit satellites (GEOs) and four inclined geosynchronous orbit satellites (IGSOs) with an inclination of 5° and 29° with the equator, respectively. These seven IRNSS/NavIC satellites are transmitting signals continuously towards Earth.
At present, only five satellites out of seven are actively being used for finding the user position, velocity, and time (PVT). The complete details regarding control and ground segments of the IRNSS/NavIC system can be found at the ISRO (ISRO, March 6, 2023). Many constellations and signals are continuously emerging as part of the modernization of GNSS systems, and these signals are visible and readily available to Indian users. In this background, the GNSS software receiver is very useful and could play an important role in exploiting these new signals and systems to improve receiver performance. A GNSS software receiver is useful for monitoring signals in real time, rapid prototyping, and testing new signals and algorithms. Advantages such as flexibility and reconfigurability of a software receiver benefit the receiver designers and developers to exploit the multi-frequency and multi-constellation approaches, eventually providing better positional performance with lower cost and greater ease. It is also possible to integrate software receivers with the inertial navigation sensors (INSs) to enhance the navigation performance in signal-degraded environments such as indoors, heavy canopy, vegetation, tunnels, etc. This paper explains the development of the IRNSS/NavIC L5 SPS software receiver using the GNSS-SDR tool. The positional performance of GNSS-SDR for IRNSS/NavIC L5 SPS signals is presented for static and dynamic cases with real-world data. Further, the performance of the software receiver is validated using simulated data generated by a GNSS simulator.
GNSS software receivers have evolved over the decades with the software-defined radio approach. Some early advances with this approach were achieved by Akos (1997) and Borre (2003). Later with a similar approach, many software receivers were developed (Anghileri et al., 2007; Fernández-Prades et al., 2010, 2011; Ledvina et al., 2003; Molino et al., 2009; Petovello et al., 2008). A MATLAB-based open-source GNSS SDR receiver’s collection has been published recently, with a clear description of the code structure and test framework (Bernabeu et al., 2022). The present work is based on GNSS-SDR, a free and open source software tool developed by Centre Tecnològic de Telecomunicacions de Catalunya (CTTC) of Spain, written in C++ with the GNU’s Not Unix (GNU) radio framework. The source code is released under GNU General Public License (GPL) v3 (GNSS-SDR, n.d.). It can process most GNSS satellite signals up to the navigation solution (PVT). Currently, it does not have an IRNSS/NavIC receiver chain to process the signals of this system. However, the GNSS-SDR integration framework is flexible enough to add new signal processing algorithms and systems without difficulty.
So, in this work, we have developed IRNSS/NavIC algorithms for acquisition, tracking, navigation data decoding, and the complete receiver chain for L5 SPS signals. Only a few GPS L1 C/A signal implementation modules are modified to make them suitable for L5 SPS signals. Similarly, a few more navigation data decoding algorithms are modified or adapted from the Galileo E1 signal implemen-tation of GNSS-SDR. These modifications are carried out according to an IRNSS interface control document (ICD), released in August 2017 (Mruthyunjaya & Ramasubramanian, 2017). IRNSS/NavIC SPS signal characteristics are similar to GPS L1 C/A signal characteristics, which allows us to use the acquisition and track-ing blocks of GPS L1 C/A signals directly with minor modifications. IRNSS/NavIC SPS signals use techniques from both GPS L1 C/A and Galileo E1. Navigation data encoding of IRNSS/NavIC signals is similar to Galileo E1 signals, which also helps as we can use some of the telemetry decoder blocks of the Galileo implementation. Earlier with a similar approach, a postprocessing-based NavIC software receiver (NavICSR) in MATLAB was presented (Srinu & Parayitam, 2020). An extremely cheap digital video broadcasting-terrestrial (DVB-T) receiver dongle with a USB interface can receive digitized GNSS signals (Fernández-Prades et al., 2013). So, in this work, a low-cost RTL2832U (RTL-SDR) Blog V3 dongle is used as a front-end to receive NavIC L5 SPS signals.
The main contribution of this work is to assess the positional performance of GNSS-SDR for IRNSS/NavIC L5 SPS signals by developing an IRNSS/NavIC receiver chain using the GNSS-SDR code and framework. It can process IRNSS/ NavIC L5 SPS signals in real time and postprocessing modes and delivers PVT to its users.
The positional performance of IRNSS/NavIC signals using a software receiver with low-cost RTL-SDR hardware has not yet been presented. Therefore, an IRNSS/NavIC software receiver is proposed for development using GNSS-SDR code and framework so that it can be useful for navigation-related research and applications with IRNSS/ NavIC signals in the future. The validation and positional performance of the IRNSS/ NavIC receiver chain are demonstrated using real and simulated data.
This paper is organized into six sections. Section 2 briefly reviews the IRNSS/ NavIC SPS signal model. Section 3 explains the navigation data structure of IRNSS/ NavIC. The block diagram of GNSS-SDR architecture is briefly explained in Section 4. IRNSS/NavIC software receiver implementation using GNSS-SDR is discussed in Section 5 by emphasizing the signal processing blocks modified to develop the NavIC software receiver with the GNSS-SDR framework. Section 6 presents the experimental setup and preliminary performance results for simulated and real data. Finally, conclusions and future scope for further development are given.
2 IRNSS/NAVIC SPS SIGNAL MODEL
IRNSS/NavIC signals are transmitted in two modes of service. RS signals have limited accessibility for prescribed users, whereas SPS signals are available and accessible for all. So we are restricted to developing and assessing the performance of IRNSS/NavIC receivers for SPS signals only. The NavIC SPS signals are transmitted on the L5 band at 1164.45 to 1188.45 MHz and on the S band at 2483.5 to 2500 MHz, with 24 MHz and 16.5 MHz bandwidths, respectively. The center frequencies are derived from the common clock frequency of 10.23 MHz, as shown in Figure 1.
The signal in space is comprised of three components:
Carrier: frequency centered either at fL5 or fS
PRN code: Each IRNSS/NavIC satellite is assigned a unique pseudorandom number (PRN) spreading code. These codes are generated using gold codes with a 1.023 MHz chipping rate with a 1-ms repetition period. The PRN code is a 1023 chip sequence modulated onto both L5 and S carriers.
Data: It contains the information of satellite, clock, and other parameters and has a symbol rate of 50 sps (or bit rate of 25 bps). This information is continuously uploaded to all the satellites from the IRNSS/NavIC ground control network.
Navigation messages are broadcast using a direct sequence spread spectrum called the Code Division Multiple Access (CDMA) technique. Figure 1 shows the block diagram of IRNSS/NavIC SPS signal generation at the satellite payload for civilian users. The 50-sps symbol stream is spread by a unique PRN code using modulo-2 addition and further binary phase shift keying (BPSK [1]) encoded onto both the L5- and S-band frequencies. The IRNSS/NavIC SPS baseband navigation signal in mathematical form is represented by Equation (1).
1
where ⊕ represents Exclusive-OR (XOR) operation or modulo-2 addition, Dsps is a navigation data of standard positioning service, Csps is a PRN code unique for each satellite, means integer part of , it gives an i-th bit of navigation message, means i modulo 1023, and gives i-th chip of spreading code. Tc, sps is one chip period given by and represents the rectangular pulse of one chip period centered at t=0.
The minimum power received by the ideally matched right-hand circularly polarized (RHCP) antenna of the user receiver on the ground with 0 dBi for an elevation angle higher than 5° is measured as 159.0 dBW and −162.3 dBW for L5- and S-band SPS signals, respectively (Mruthyunjaya & Ramasubramanian, 2017).
3 IRNSS/NAVIC NAVIGATION DATA STRUCTURE
The IRNSS/NavIC navigation data structure is shown in Figure 2. Each master frame consists of four subframes, and each subframe is transmitted sequentially in time with 12-s duration. Each subframe consists of a 16-bit synch pattern (0xEB90), followed by 584 code symbols corresponding to 292 data bits, and every subframe ends with six tail bits. The tail bits are a sequence of 6 zero values indicating the successful decoding of subframe data.
Three levels of error coding schemes protect IRNSS/NavIC navigation message data. They are: a) cyclic redundancy check (CRC) that detects errors in the received navigation data and protects against bursts and random errors, b) half-rate Forward Error Correction (FEC) convolutional coding, and c) block interleaving. FEC-coded data is interleaved with 73 columns and eight rows. Data is written in columns and read in rows, protecting against bursts in the FEC decoded data.
Subframes 1 and 2 give satellite ephemeris, satellite clock correction parameters, satellite and signal health status, user range accuracy, total group delay, etc., as part of the primary navigation parameters. This data repeats once every 48 seconds. Subframes 3 and 4 give an almanac of all satellites, ionosphere grid delays and confidence, time offsets of IRNSS/NavIC with respect to UTC and GNSS, coefficients for the ionosphere delay correction, test messages, differential corrections, Earth orientation parameters, etc., in the form of messages as part of the secondary navigation parameters. Each message transmits 220 bits of the navigation message data through Subframes 3 and 4.
4 GNSS-SDR ARCHITECTURE
GNSS-SDR is an open-source C++ software receiver project that runs on a normal PC for processing GNSS signals in both postprocessing and real-time modes. The software architecture of GNSS-SDR is shown in Figure 3. In postprocessing mode, the input to the receiver is a raw signal file that contains digital intermediate-frequency (IF) data of GNSS signals. In real-time mode, the input data is taken from the output of an radio-frequency (RF) front-end connected to a suitable GNSS antenna. GNSS-SDR has a flexible framework where users can build their algorithms and signals of interest. It offers interfaces to all the intermediate signals and parameters. It supports interfacing with most commercially available or custom-made RF front-ends through USB or ethernet buses for taking IF data as input and delivering the navigation solution. It can adapt to different sampling frequencies, IF, and analog to digital converter (ADC) resolutions of many RF front-ends.
GNSS-SDR permits users to define their custom GNSS software receiver to target a specific signal with a user-defined number of bands and channels per band. It allows one to choose specific algorithms and parameters for each processing block through a single configuration file. Thus, each configuration file defines a different GNSS receiver.
The control plane of GNSS-SDR is responsible for creating a flow graph in accordance with the input configuration file. It consists of four main components: a) configuration mechanism, b) GNSS block factory, c) GNSS flow graph, and d) control thread. The configuration mechanism of GNSS-SDR is flexible to use any number of algorithms and implementations with the associated parameters. The addition of new signal processing blocks without changing the existing code of the GNSS-SDR is facilitated by the GNSS block factory. A GNSS flow graph creates and manages processing blocks according to the user configuration, connecting them in a process network for implementing a given software receiver. The control thread manages everything from start to end.
The blocks presented in blue in Figure 3 are GNSS processing blocks. The signal source block is responsible for continuously sending digital IF samples from the file (offline) or RF front-end (online). The signal conditioner block conditions the input data resolution to a suitable data resolution that a host computer can handle in running the software receiver. It can also provide baseband conversion from IF data, resampling, and filtering. Each channel consists of signal acquisition, tracking, and a telemetry decoder for a single satellite. The number of parallel channels to be assigned can be defined through the configuration file by the user. The GNU radio will automatically initiate the thread-per-block scheduler and manage the modern multi-core processor’s multitasking capabilities. The role of the acquisition block is to detect visible satellites with respect to the antenna and provide rough estimates of the code phase and the Doppler shift. The role of the tracking block is to refine these estimates to track the satellite continuously in time. The role of the telemetry decoder block is to get the navigation data bits from the navigation messages broadcast by the GNSS satellites. The role of the observables block is to find the pseudorange, carrier phase, and Doppler shift.
Finally, the PVT block computes the navigation solution and provides the solution in understandable formats for further analysis to the user. The outputs of the receiver can be stored in Receiver Independent Exchange format (RINEX), KML, GeoJSON formats, etc. The monitor block provides an interface for monitoring the internal status of the software receiver in real time by streaming the receiver’s internal data to local or remote clients over user datagram protocol (UDP). GNSS-SDR can read assistance data such as the satellite’s ephemeris and almanacs externally through the Internet for faster time to first fix (TTFF). The detailed GNSS-SDR architecture, framework and modules are described in Fernández-Prades et al. (2010, 2011, 2012).
5 IRNSS/NAVIC SOFTWARE RECEIVER IMPLEMENTATION USING GNSS-SDR
An existing open-source GNSS-SDR is used to develop an IRNSS/NavIC real-time software receiver. The blocks of the GNSS-SDR signal flow graph are abstract, meaning that users can replace them with different algorithms belonging to a particular GNSS signal implementation. The block diagram of the signal flow graph for the IRNSS/NavIC signals is shown in Figure 4. Since IRNSS/NavIC signal characteristics such as multiplexing, modulation, PRN code characteristics, and the coordinate system are similar to GPS L1 C/A signals, acquisition block, tracking block, and the entire framework are adapted from the existing GPS L1 C/A signal implementation of GNSS-SDR with minor modifications. The blocks labeled as observables and PVT are common to all signal implementations, so these blocks are adapted directly for the IRNSS/NavIC signals.
The main block that needs to be developed is the telemetry decoder block. The IRNSS/NavIC data frame structure and encoding of navigation data differ from GPS L1 C/A signals, but are similar to the Galileo E1 signals in terms of encoding the navigation data. Both use the FEC coding scheme, block interleaving, and CRC on the data message. So, these modules are adapted from the Galileo E1 telemetry decoder implementation. The IRNSS/NavIC telemetry decoder block is developed by modifying the code and framework of the existing GPS L1 C/A telemetry decoder implementation in accordance with the IRNSS ICD document by adapting the above-said modules from Galileo E1 signal implementation.
6 EXPERIMENTAL RESULTS AND VALIDATION
The developed IRNSS/NavIC software receiver chain and algorithms are validated and tested for simulated data and data collected using an RF front-end in static and dynamic conditions. The results are plotted, and the corresponding positional accuracy statistics are shown in tables for each case. IRNSS/NavIC static positioning performance is compared with the existing implementation of GPS L1 signals of GNSS-SDR for the comparable satellite geometry. The data is simulated using Orolia’s Skydel GNSS simulation software (Orolia, n.d.). Experimental results for the real-time case are obtained using a low-cost RTL-SDR dongle.
6.1 Positional Accuracy Measures
The standalone static positional accuracy measures are calculated with respect to a reference location defined by the geodetic survey or using a test receiver. Distance root-mean-square (DRMS) and circular error probability (CEP) are the common metrics for assessing the 2D positional accuracy (Fernández-Prades et al., 2016). Similarly, the confidence measures for 3D positioning are mean radial spherical error (MRSE) and spherical error probability (SEP). These measures are calculated using the formulae given in Table 1 and are expressed in meters, where , and are the error variances in east-north-up (ENU) local reference coordinate system. These are given by Equations (1), (2), and (3).
1
2
3
where EREF, NREF, and UREF are the east, north, and up coordinates of the reference location. Similarly, for calculating precision accuracy measures, the reference location coordinates are replaced with the mean values of the receiver ENU estimations as given in Equations (4), (5), and (6). The positional accuracy measures are also applicable to a dynamic receiver. The main difference in a dynamic receiver scenario is that the reference location coordinates change with time.
4
5
6
where EAVG, NAVG, and UAVG are the mean values of all the estimated positions of the east, north, and up coordinates of the user receiving antenna.
The positional accuracy of a GNSS receiver also depends on the geometry of tracked satellites and the volume of space formed by the trapezoid with the position of satellites as vertices. The metrics to represent the geometry in different positional domains are geometric dilution of precision (GDOP), horizontal dilution of precision (HDOP), vertical dilution of precision (VDOP), and position dilution of precision (PDOP). These metrics are dimensionless, and the lower the metric’s value, the better the navigation solution in the corresponding domain (Borre et al., 2007).
6.2 Experimental Results for Simulated Data
Digital simulated IF data is collected for static and dynamic vehicle cases for IRNSS/NavIC L5 and GPS L1 signals. For the simulation of static data, fixed antenna position coordinates (rooftop of the NERTU building, Hyderabad, India) with zero ionosphere and troposphere delays are chosen. For comparison of IRNSS/NavIC L5 signals with GPS L1 C/A signals, the same number of satellites (six) are considered while simulating the signals along with comparable satellite geometry or dilution of precision (DOP). GNSS-SDR ran individually for both GPS and IRNSS/NavIC signals with the same receiver configuration settings such as 1-ms coherent integration time, delay-locked-loop/phase-locked-loop (DLL-PLL) tracking implementation of second order, 25-Hz phase locked loop (PLL) bandwidth, 2-Hz delay looked loop (DLL) bandwidth, and 0.5-chip early-late correlator spacing. True antenna position in geodetic coordinates and simulated digital IF data specifications are given in Table 2. The sky plot of IRNSS/NavIC and GPS satellites are shown in Figures 5 and 6, respectively. Figure 7 shows the position error scatter with respect to the mean reference position. The mean reference position coordinates are obtained using the estimated position observations. Figure 8 gives the up coordinate error with respect to the mean reference. The corresponding velocity errors are shown in Figures 9 and 10. Tables 3 and 4 give static positional performance statistics for both constellations.
Similarly, IRNSS/NavIC L5 and GPS L1 signals are simulated for a receiver fixed on a vehicle moving at a speed of 50 kmph. The digital IF data specifications are identical to those specified for the static case. The same number of satellites (six) with similar geometry is chosen for both constellations in the dynamic case with the intent of comparing the software receiver’s performance for IRNSS/NavIC signals with GPS L1 signals. Figures 11 through 16 show the corresponding sky plot, simulated trajectory, position and velocity error plots, and latitude versus longitude plot for both GPS L1 C/A and IRNSS/NavIC L5 SPS signals for the dynamic simulated data. Table 5 gives dynamic positional performance statistics for both constellations.
The positional performance of GNSS-SDR for IRNSS/NavIC L5 and GPS L1 signals are compared for static and dynamic cases. However, the accuracies for both systems depend on various factors such as DOP, the orientation of satellites in space, etc. In practice, it is not easy to compare the positional performance of both systems due to these factors. However, they are compared by taking approximate comparable geometry with the same number of satellites in this work using a simulator. The estimated position error (3D-MRSE) for static and dynamic cases is within 3 m for both constellations considering six satellite channels, shown in Tables 4 and 5. The accuracy could be better if more satellites with good satellite geometry are considered for both systems. The experimental results for the simulated data validate the development of the IRNSS/NavIC receiver chain using GNSS-SDR.
Further, it is observed from Table 4 that there is a deviation or offset in the results of IRNSS/NavIC L5 and GPS L1. The IRNSS/NavIC L5 signals show more deviation than GPS L1 signals from the reference position. The possible reason could be either bias in the orbital or ephemerides generated by the simulator for IRNSS/ NavIC L5 satellites or biases introduced in the IRNSS/NavIC L5 receiver chain in GNSS-SDR or both. Further analysis is needed to improve the receiver’s accuracy for IRNSS/NavIC signals for both static and dynamic cases.
6.3 Experimental Results for Real-Data
To implement and test GNSS software receivers and signal processing modules, digitized ADC IF data for GNSS signals of interest is required. Several commercial RF front-ends are available in the market to receive GNSS signals. Since many of these devices are expensive, it is not easy to procure them as individual researchers and developers. Therefore, a low-cost RF front-end capable of receiving GNSS signals is very useful to the research community. Quite a few low-cost RTL-SDR front-end dongles have emerged in the market. These were originally designed for DVB-T TV tuning and reception. Since they can tune and acquire data from a wide range of frequencies, they have been used as general-purpose SDRs.
The frequency tuning range varies based on the tuner chip used inside these devices. The Realtek-based RTL-SDR Blog V3 dongle uses an R820T tuner chip and RTL2832U ADC chipset. It has a frequency tuning range from 500 kHz to 1766 MHz (500 kHz – 24 MHz in direct sampling mode). This band, fortunately, covers IRNSS/NavIC L5 SPS signals. It provides unsigned 8-bit I/Q (complex) baseband sample data and provides a maximum sampling frequency of 3.2 MSPS (mega samples per second) as per the specification given in the datasheet. The raw I/Q sample stream transmits to the PC through a USB 2.0 interface. It was stated that the maximum sampling frequency for continuous reception without losing samples is 2.4 MSPS (Fernández-Prades et al., 2013).
The accuracy and stability of the clock are crucial for GNSS applications. As the RTL-SDR Blog V3 front-end dongle is equipped with a temperature compensated crystal oscillator (TCXO) of ± 0.5 PPM (parts per million), it is a sufficient replacement for the preferable 1-PPM accuracy. Moreover, the PPM offset value is not equal for all devices. If RTL-SDR dongles are used in GNSS applications, it is required to compensate for the effect of frequency drift in the sampling clock using the PPM of the device. Otherwise, it severely affects the tracking loops and leads to the loss of lock of GNSS satellite signals. It also affects the acquisition of satellite signals if the drift exceeds the limits of the Doppler search in the acquisition module. So, the PPM must be calibrated for each dongle for PPM offset corrections.
GNSS-SDR is flexible enough to compensate for the effects of the PPM offset by selecting the proper front-end IF deviation, , and corrected sampling frequency, , values via a configuration file. So, the first step in running the software receiver with the RTL-SDR is to find and f using the calibrated PPM. These two estimates depend upon the PPM value of the dongle and can be derived using Equations (7) and (8).
7
8
Here fs is the actual sampling frequency and fcenter represents tuned RF center frequency of the front-end. Once these two values, and , are deduced, it is possible to configure the front-end parameters through the configuration file. Thereby GNSS-SDR accounts for the PPM offset corrections. In order to calibrate RTL-SDR frequency drift or PPM offset value, global system for mobile communication (GSM) signals can be used as a reference signal to compare and calibrate the frequency drift. Similarly, using assisted GNSS data, a calibration method was proposed with satellite reference signals to estimate the Doppler shifts via the Internet. It uses the Secure User Plane Location (SUPL) v1.0 client, and thereby and can be estimated directly (Fernández-Prades et al., 2013).
Since there is no GSM and assisted GNSS data available at our location, calibration is done by a trial-and-error method using an existing GNSS-SDR GPS L1 C/A receiver chain with known visible satellites and Doppler. In general, the PPM offset value is assumed to be within ±50 PPM, thereby and values are estimated using Equations (7) and (8), respectively, for all the PPM values, ranging from −50 to 50 with a step size of 0.5 for GPS center frequency, fcenter, at 1575.42 MHz. GNSS-SDR is run for each case and the correct PPM offset. It acquires and tracks satellites without loss of lock for the given visible GPS satellites and provides a navigation solution. Further, the estimated PPM value is refined by comparing the Doppler frequency of tracked satellites with the known Doppler frequency of the acquired IRNSS/NavIC satellites.
6.3.1 Experimental Setup
The two hardware components, RTL-SDR and GNSS antenna, are connected to the PC through a USB interface, as shown in Figure 17. The antenna is placed on the rooftop of the building and remains static during the experiment. The RTL-SDR Blog V3 dongle has inbuilt bias-T, which supplies the necessary DC power to the active antenna and RF front-end. The operating system is Linux Ubuntu 18.04 LTS with GNU radio version 3.7.11. The host PC device specifications are listed in Table 6.
All the necessary dependencies, signal processing blocks, and drivers are installed through the software packages given in the GNSS-SDR documentation.
6.3.2 Results for Static Real-Time Case
The real-time performance of the developed IRNSS/NavIC L5 receiver chain using GNSS-SDR is tested in static and dynamic cases using low-cost RTL-SDR. Table 7 gives the input receiver configuration settings for both static and dynamic receiver cases. The sky plot of IRNSS/NavIC satellites is shown in Figure 18. Tracking results of PRN 2 are shown in Figure 19. Figure 20 shows the position error scatter with respect to the true and mean reference position. Figure 21 gives the up coordinate errors with respect to the true and mean reference. The corresponding velocity errors are shown in Figures 22 and 23. Table 8 gives the positional performance statistics for static live data.
GNSS-SDR supports data logging of acquisition, tracking, PVT, and other intermediate blocks. The following plots are plotted using the MATLAB scripts provided in the book by Borre et al. (2007).
The position coordinates obtained after processing live IRNSS/NavIC L5 SPS signals using RTL-SDR in a static case are shown on Google Maps in Figure 24, along with true antenna coordinates. The antenna is located on the rooftop of the NERTU building, Osmania University. The blue color pin location is the true antenna position surrounded by the estimated position sample evaluation shown in white circles.
6.3.3 Experimental Setup and Results for Dynamic Real-Time Case
The receiver’s performance for dynamic environments is also evaluated using an antenna placed on top of the vehicle and connected to the PC through RTL-SDR. A reference trajectory was generated using a u-blox EVK-M8U hardware receiver. The experimental setup for the dynamic case is shown in Figure 25. The sky plot of IRNSS/NavIC satellites is shown in Figure 26. Figure 27 shows errors in local ENU coordinates. Velocity errors in the ECEF coordinate system are shown in Figure 28. Figure 29 shows the horizontal position and velocity errors. Figure 30 shows a two-dimensional latitude versus longitude coordinate plot and the reference trajectory. The position coordinates obtained after processing live IRNSS/NavIC L5 SPS signals using RTL-SDR in a dynamic case are shown on Google Maps in Figure 31, along with true antenna coordinates. Table 9 gives the positional performance statistics for dynamic live data of IRNSS/NavIC L5 signals.
The experimental setup with GNSS-SDR and a low-cost RTL-SDR front-end can track and decode the navigation data of all the visible IRNSS/NavIC satellite channels with respect to the antenna and delivers the navigation solution in real time. It is observed that with cheap RTL-SDR dongles, it is feasible to get precise and reasonable accuracies in the navigation solution. The estimated position error (3D-MRSE) for static and dynamic cases is on the order of 10 m and 30 m, respectively, with five satellites and for a low sampling frequency of 2.048 MHz digital I/Q data of RTL-SDR. The performance of the IRNSS/NavIC software receiver can be improved by incorporating ionospheric and tropospheric delay corrections. Further improvement in the accuracy can be expected with good GDOP, i.e., if all seven satellites, instead of five satellites, are available and used for computing the position.
6.4 Execution Time and TTFF
Initially, the GNSS-SDR was tested by measuring its execution time by running it offline for data of a fixed length of 200 s. Execution time is almost 0.2-times the length of data, i.e., the computational power of the PC supports real-time applications. Time to first fix (TTFF) is another indicator for assessing the performance of the real-time software receiver. The time the static receiver takes to provide a valid first position fix is called TTFF. The TTFF value is calculated for a static real-time receiver using RTL-SDR for IRNSS/NavIC L5 SPS signals with the assumption of no prior known information of the time, ephemeris, almanac, and position.
The maximum time required to get the navigation parameters in a worst-case scenario for getting the first navigation solution fix with IRNSS/NavIC SPS signals is 60 s. However, the GNSS-SDR framework initially validates the frame synchronization of successive incoming subframe data, which delays the TTFF. GNSS-SDR execution time and TTFF values are given in Table 10 for IRNSS/NavIC L5 signals.
It is observed from Table 10 that the real-time execution time is five times that of offline execution time. The execution time or runtime of the GNSS-SDR includes initialization, instantiation of objects, reading configuration file, and creating a flow graph according to the configuration file, etc. It also includes preprocessing of the data, such as data type adoption, filtering, etc. So it reports a total runtime that possibly crosses the actual data processing time. An execution time of 206.982 s is observed for processing 200 s of live data. In offline mode, there is no need to wait for the data to fill the buffers, as it is from the file. So the execution or runtime in offline mode is far less compared to online mode and indicates the possibility of supporting it for more channels.
7 CONCLUSIONS AND FUTURE SCOPE
This paper presents the implementation and positional performance of a real-time IRNSS/NavIC software receiver using GNSS-SDR code and framework. In this work, the performance of the initial version of the real-time IRNSS/NavIC software receiver without incorporating atmospheric corrections is evaluated for L5 SPS signals. A low-cost RTL-SDR Blog V3 front-end dongle is used to receive live IRNSS/NavIC L5 SPS signals. The receiver’s performance for positional accuracy, execution time, and TTFF, along with necessary plots, validate the development. This could be one of the low-cost real-time software receiver solutions for processing IRNSS/NavIC signals and can be used as a research and academic tool. It is observed from the preliminary experimental results that GNSS-SDR with the low-cost RTL-SDR Blog V3 USB front-end delivers good performance and could be employed in several GNSS applications, including real-time monitoring of ionosphere, troposphere, satellite clock, etc.
The IRNSS/NavIC software receiver is implemented using the GNSS-SDR, a highly customizable and flexible software receiver available freely and feasible for implementing new algorithms and signals. The IRNSS/NavIC receiver chain based on GNSS-SDR paves the way for researchers for further development centered on the regional IRNSS/NavIC system. It could also enable the exploitation of multi-band and multi-constellation signals for better performance.
The developed receiver needs to be tested thoroughly in signal-degraded conditions with other hardware front-ends and PC configurations for future research. Further performance of the developed IRNSS/NavIC software receiver can be enhanced using the complete information broadcast by the IRNSS/NavIC satellites, including atmospheric corrections. An IRNSS/NavIC S-band receiver chain could be implemented, and performance assessment could be carried out using dual-frequency corrections in static and dynamic conditions.
HOW TO CITE THIS ARTICLE
Srinu, C., & Parayitam, L. (2023). Performance of GNSS-SDR for IRNSS L5 signals using a low-cost RF front-end. NAVIGATION, 70(2). https://doi.org/10.33012/navi.573
ACKNOWLEDGMENTS
The authors would like to thank the GNSS-SDR tool developers. This work has been possible only because of this tool by CTTC and the contribution of the open-source community. We want to express our gratitude towards Orolia for providing Skydel GNSS simulation software to NERTU, Osmania University, as part of the Orolia Academic Partnership Program (OAPP). We thank the University Grants Commission (UGC) of India for sponsoring the work through the UGC-SRF scheme of the first author.
This is an open access article under the terms of the Creative Commons Attribution License, which permits use, distribution and reproduction in any medium, provided the original work is properly cited.