GPS World

Tag: software receiver

  • Innovation: Better jamming mitigation

    Innovation: Better jamming mitigation

    Using Wavelets for a Robust Vector-Tracking-Based GPS Software Receiver

    Innovation Insights with Richard Langley
    Innovation Insights with Richard Langley

    ALFRÉD HAAR. Who is he, you might ask? Alfréd Haar was a Hungarian mathematician who introduced the concept of wavelets during his Ph.D. work on orthogonal functional systems under David Hilbert of Hilbert transform fame. And what is a wavelet? Generally speaking, a wavelet, as its name suggests, is a brief oscillation in time with an amplitude that begins at zero, goes through one or more variations, and returns to zero. It’s a bit like the cardiac cycle of each heartbeat shown on an electrocardiogram. But wavelets, unlike heartbeats, are mathematical functions with well-defined properties.

    Although Haar initiated the use of wavelets back in 1909, it was not until the 1970s and 1980s that the study of the use of wavelets — wavelet analysis — was undertaken to help solve a variety of problems in science and engineering with new application areas springing up all the time. We’ll get to one of these new areas — GNSS jamming mitigation — in just a bit, but let’s discuss a more mundane application first.

    Let’s say we have a digitized audio recording of Maynard Ferguson’s rendition of “MacArthur Park” in our computer. We could do a Fourier transform (related to the Hilbert transform mentioned earlier) of the entire recording, which would show us all of the specific audio frequencies making up the song. But what if we wanted to determine where in the song Ferguson played a particular high note, such as double high C (not his highest)? We could create a wavelet with that frequency and a short duration such as that of a 32nd note and use the mathematical operation of convolution (involving shifting, multiplication and integration) to find one or more spots in the recording with a similar frequency. We could extend the procedure and use a set or bank of wavelets to fully study the song in both frequency and time.

    Wavelet analysis will work on many kinds of data, not just audio signals. With an appropriate set of wavelets, we could decompose the data without gaps or overlap, store the resulting product for further analyses and, if necessary, reconstitute the original data with minimal distortion. The U.S. Federal Bureau of Investigation uses wavelet analysis to store compressed digital versions of fingerprint images. A heavily damaged recording of Brahms playing one of his own compositions on an Edison wax cylinder was partially restored using wavelet analysis despite the music being immersed in noise. And the small effect of El Niños on the Earth’s rotation has been studied using wavelet analysis.

    And, yes, wavelet analysis is helping to improve the use of GNSS. The tasks being undertaken include de-noising of pseudorange measurements, cycle-slip detection and elimination in carrier-phase measurements, and separating biases such as multipath from high-frequency receiver noise. In this month’s column (which, by the way, now appears four times per year), we learn about another GNSS application of wavelet analysis — specifically the use of the wavelet packet transform — to efficiently identify and separate a jamming signal from the combined signal in a GPS receiver. In a narrowband jamming test using a hardware simulator system, no positioning was possible with conventional receiver operation. But with the proposed approach, the jamming signal was readily suppressed, allowing the satellite signals to be acquired and a positioning solution to be computed. Thank you, Alfréd Haar.

    GPS technology has been integrated into many aspects of our daily lives. Hence, there is a growing demand for a robust GPS receiver that can operate efficiently without external aiding to provide continuous, reliable and accurate positioning, navigation and timing (PNT) solutions. However, this is not always possible due to frequent loss or attenuation of signals, multipath or interference. In such challenging conditions, a system malfunction can cause safety problems, especially in health-critical applications.

    Receiver architecture plays a major role in defining a receiver’s robustness against the challenges just mentioned. Scalar-tracking-based GPS receivers can achieve high navigation accuracy under line-of-sight (LOS) conditions. However, they always fail to provide adequate accuracy in signal-degraded environments such as urban, suburban and dense foliage environments. On the contrary, vector-tracking-based GPS receivers provide better performance in such challenging environments. In vector-tracking-based receivers, both the tracking loops and the navigation processor are combined to solve a single estimation problem. Hence, there are many advantages of this architecture over that of scalar-tracking-based receivers. First, information from strong signals from healthy satellites is used to track weak signals, when signals are highly attenuated or even totally blocked. Thus, vector-tracking-based receivers have better immunity to jamming and interference. Second, they can rapidly reacquire signals after a satellite outage. Third, they have an improved navigation solution accuracy compared to that of scalar-tracking-based receivers, even under normal LOS conditions. All of these advantages make vector-tracking-based receivers the best platform for our research on receiver robustness. However, vector-tracking-based receivers still suffer from degraded performance in the presence of strong jamming signals. Therefore, we are proposing a new anti-jamming technique to be employed for interference mitigation in vector-tracking-based GPS receivers.

    The spread-spectrum nature of GPS signals provides resistance to narrowband interference due to the spreading and despreading processes that take place at the transmitter and receiver respectively. However, a GPS signal reaches the receiver with very low power on the order of –158 dBW, which makes it vulnerable to jamming. A jammer with enough power and suitable time and frequency properties can degrade the positioning solution accuracy and may cause a total blockage of the GPS signals. Besides, the presence of a jamming signal increases the challenge of acquisition of the desired GPS signal.

    Therefore, many anti-jamming techniques have been employed for interference mitigation in GPS receivers. There are various anti-jamming methods for GPS receiving systems, which are mainly classified into four groups:

    1. Antenna-level techniques, which are based on the use of antenna arrays to generate a radiation (reception) pattern that attenuates the interference signal based on the direction of arrival.
    2. Automatic gain control (AGC), where interference can be detected by the saturation of the AGC.
    3. Post-correlation techniques, which process the signals after passing through the correlators.
    4. Pre-correlation techniques, which are based on processing the signals after passing through the analog-to-digital converter but before they get to the correlators.

    This article introduces a novel interference mitigation technique based on the wavelet packet transform (WPT), which belongs to the pre-correlation techniques category. The WPT enables the received interfered combined GPS signal to be represented in a transformed domain in which an interference signal can be better identified and separated, without significant degradation of the useful GPS signal. The WPT has been extensively discussed in the literature in the framework of GPS and other GNSS. For example, wavelet multi-resolution analysis has been used in one study to remove the multipath error and leave the useful signal untouched. In another study, multi-resolution analysis using wavelets was applied to pseudorange and carrier-phase GPS double differences to reduce multipath effects. And in another, researchers developed a technique to detect and remove cycle slips based on wavelet multiresolution analysis.

    The WPT has been widely used in the context of jamming to mitigate pulsed and narrowband interference. Although the WPT showed outstanding performance in jamming mitigation, the main drawback of this technique is the computational complexity. In this article, we introduce a novel wavelet packet-based technique for narrowband jamming mitigation with significantly reduced computational complexity.

    Signal and Interference Models

    The GPS signal employs a direct sequence spread spectrum communication technique, in which the signal is multiplied by a spreading or pseudorandom noise (PRN) code. As mentioned earlier, this spreading technique gives GPS some immunity to narrowband jamming. The received digitized spread spectrum signal at the output of the receiver’s analog to digital converter (ADC) can be represented by:

    Photo:

    (1)

    where, for signal s, ym(nTs) is the useful GPS signal received from mth LOS satellite, j(nTs) is the jamming signal, w(nTs) is additive white Gaussian noise (AWGN), M is the number of visible satellites, n is the sample number and Ts is the sampling rate.

    The useful received GPS signal can be described as follows:

    Photo:(2)
    where P is the signal power, d(nTs) is the navigation data, c(nTs) is the spreading pseudorandom noise code, fIF is the intermediate frequency, no is the code delay, fd is the Doppler shift, and θo is the carrier phase.

    Interference signals are classified based on their spectrum characteristics: narrowband or wideband depending on the signal’s bandwidth relative to the bandwidth of the desired GPS signal.

    Our focus in this article is on the mitigation of narrowband interference, specifically a linear chirp signal. A chirp signal can be expressed as:

    Photo:(3)

    where a is the chirp signal amplitude, fo is the starting frequency, k is the sweeping frequency, and Tsw is the sweeping frequency period. The chirp is continuously repeated.

    Wavelet Packet Transform

    The wavelet packet transform or WPT is a class of transformed domain techniques that has been widely used in the context of jamming mitigation in GPS signal reception. It allows for the study of a signal in both time and frequency domains simultaneously. In the WPT, the signal is decomposed into approximations (the low-pass component) and details (the high-pass component) with respect to a group of local basis functions. These functions can be obtained through dyadic scaling and shifting of the so-called mother wavelet. The discrete wavelet basis functions are given by:

    Photo:(4)

    where j and k are integers, so is the dilation step, and τo is the scaling coefficient. The decomposition of the signal with respect to a scaling function acts as low-pass filtering of the signal, while the decomposition with respect to a wavelet function acts as high-pass filtering of the signal. The signal is then down-sampled, and this procedure is further iterated on all the sub-bands using scaled and dilated versions of the wavelet and scaling functions. This filtering process allows the decomposition of the GPS signal with respect to a local basis function, in which each of these sub-bands identifies a limited frequency band of the received signal, and the frequency resolution is dependent on the level of decomposition. The wavelet packet decomposition can be realized as a filter-bank as depicted in FIGURE 1.

    FIGURE 1. Wavelet packet filter banks. (Image: Authors)
    FIGURE 1. Wavelet packet filter banks. (Image: Authors)

    Jamming Mitigation Algorithm

    As mentioned earlier, the main drawback of WPT is the time complexity. Due to the decomposition of both approximation and detail components, if the signal is decomposed into L levels, the resultant number of coefficients is 2L. For instance, if we used 10 decomposition levels, the resultant number of wavelet coefficients is 210 (1,024). However, as each wavelet coefficient component represents a limited portion of the frequency of the received signal, the jamming signal will only affect a few coefficients. Thus, the main idea of the proposed algorithm is to identify those coefficients that are affected by the jamming signal and reconstruct the jamming signal after denoising them. Then, the estimated jamming signal is subtracted from the received signal to obtain the jamming-free useful GPS signal.

    Identifying the wavelet coefficients affected by interference is achieved by computing the median absolute deviation (MAD). As those coefficients that are affected by interference have a higher MAD value than those that are not affected, the decision of whether the wavelet coefficients are affected by interference is based on comparing their MAD values with a certain predefined threshold. This threshold is determined based on the desired detection and false alarm probabilities according to the distribution of the received signal samples in an interference-free environment. Only the sub-bands whose MAD values exceed the threshold are considered to be affected by interference and are further decomposed.

    Therefore, only the sub-bands affected by interference are isolated and iterated. This technique allows for a considerable reduction in complexity, as both detection and mitigation can be applied in a limited number of sub-bands. FIGURES 2 and 3 show the tree decomposition of the received signal of two jamming scenarios based on the proposed algorithm. The frequency offset of the jamming signal from the GPS signal is 200 kHz in the first scenario and 600 kHz in the second one. The figures clearly illustrate the huge reduction in computational complexity as for 10 levels of decomposition; we ended up having only eight wavelet coefficients instead of 1,024.

    FIGURE 2. Tree decomposition for scenario I. (Image: Authors)
    FIGURE 2. Tree decomposition for scenario I. (Image: Authors)
    FIGURE 3. Tree decomposition for scenario II. (Image: Authors)
    FIGURE 3. Tree decomposition for scenario II. (Image: Authors)

    The proposed wavelet packet-based detection and mitigation algorithm is explained in three steps.

    Decomposition Step. The incoming GPS signal is decomposed through a uniform filter bank by only one level. Then, MAD is computed for all the decomposed sub-bands. Only sub-bands with a MAD value greater than the predefined threshold will be further decomposed. This step is repeated until the maximum predefined decomposition level is reached.

    Detection Step. The MAD value is computed for all sub-bands from the last decomposition level. Only sub-bands whose MAD value exceeds the predefined threshold are considered affected by interference and are used to reconstruct the jamming signal using the inverse wavelet transform.

    Reconstruction Step. In this step, the useful GPS signal is reconstructed free of interference by subtracting the estimated jamming signal from the received signal.

    Experimental Work

    In our investigation, a GNSS simulation system was used to create a fully controlled environment to examine and validate the performance of the proposed method using semi-real simulation scenarios. The simulator was controlled by simulation software that enables the simulation of multipath reflections through an advanced multipath model as well as atmospheric degradation to signals and the effects of antenna patterns and terrain obscuration. Moreover, it can generate simulated land, air, space and sea trajectories. Furthermore, the simulator when connected to an interference simulation system can provide various controlled jamming environments using an interference signal generator. The full setup is shown in FIGURE 4.

    FIGURE 4. Hardware experimental setup. (Image: Authors)
    FIGURE 4. Hardware experimental setup. (Image: Authors)

    The receiver used in this research is a prototype of a digital front end. The front end collects the output radio frequency (RF) signal from the simulator. Then, the RF signal is down-converted to baseband through several down-conversion stages, generating the in-phase (I) and quadrature-phase (Q) data. Then, the data is sampled and quantized through the ADC. The front end collects GPS L1 signals at different bandwidths ranging from 2.5 MHz to 20 MHz with quantization levels ranging from 1-bit to 8-bit. After that, the sampled digitized signal is sent to the computer via an Ethernet connection.

    The raw I/Q GPS samples are then processed by a GPS software receiver. Our proposed algorithms have been implemented using Matlab by modifying the open-source GPS software-defined radio (SDR) receiver composed by Borre and Akos, which is widely used in research.

    To verify the performance of the new proposed algorithm, a full GPS C/A-code signal was simulated using the previously mentioned simulation system. A static simulated scenario was generated for this purpose. This static scenario was run twice, once in an interference-free environment for reference, and one where the jamming signal was enabled. The simulation, front end and SDR receiver parameters are shown in TABLE 1.

    Table 1. Data collection and processing parameters. (Data: Authors)
    Table 1. Data collection and processing parameters. (Data: Authors)

    FIGURES 5 and 6 show the power spectral density (PSD)of the received signal before and after applying the proposed jamming mitigation technique. The figures demonstrate that the interference components have been highly attenuated. To confirm the benefits of the proposed technique, the reconstructed useful GPS signal has been acquired using the SDR receiver.

    FIGURE 5. PSD before jamming mitigation. (Image: Authors)
    FIGURE 5. PSD before jamming mitigation. (Image: Authors)
    FIGURE 6. PSD after jamming mitigation. (Image: Authors)
    FIGURE 6. PSD after jamming mitigation. (Image: Authors)

    FIGURE 7 shows that the receiver is in a total blockage as it failed to acquire any satellite before applying the jamming mitigation technique. However, FIGURE 8 shows that the proposed algorithm allowed the retrieval of seven satellites.

    FIGURE 7. Acquisition results before jamming mitigation. (Image: Authors)
    FIGURE 7. Acquisition results before jamming mitigation. (Image: Authors)
    FIGURE 8. Acquisition results after jamming mitigation. (Image: Authors)
    FIGURE 8. Acquisition results after jamming mitigation. (Image: Authors)

    FIGURE 9 shows the cross-ambiguity function (CAF) of PRN31 before jamming mitigation. It is obvious from the figure that the search space is quite noisy, and the receiver fails to acquire the GPS signal due to the difficulty of isolating the peak from the noise. However, FIGURE 10 shows that the peak clearly emerges from the noise floor and can be easily detected by the receiver after applying the jamming mitigation algorithm.

    FIGURE 9. CAF of PRN31 before jamming mitigation. (Image: Authors)
    FIGURE 9. CAF of PRN31 before jamming mitigation. (Image: Authors)
    FIGURE 10. CAF of PRN31 after jamming mitigation. (Image: Authors)
    FIGURE 10. CAF of PRN31 after jamming mitigation. (Image: Authors)

    These figures demonstrate the power of the proposed algorithm and confirms that the useful signal is not lost during the filtering process. Before applying the jamming mitigation algorithm, the receiver lost lock on all satellites and failed to provide a navigation solution. However, after applying the proposed algorithm, the navigation solution is available with an accuracy of about 10 meters in the east and north components and around 20 meters in the up component, as shown in FIGURE 11.

    FIGURE 11. Navigation solution. (Image: Authors)
    FIGURE 11. Navigation solution. (Image: Authors)

    Conclusion

    In this article, we have proposed a new method for mitigating a linear chirp narrowband jamming signal based on the WPT. Although the WPT has been widely used in the literature in the context of mitigating narrowband jamming, this technique is characterized by a significant computational complexity that is not only proportional to the length of the signal, but also proportional to the wavelet decomposition level.

    The results show that our proposed algorithm is able to maintain excellent performance in the suppression of the jamming signal with a significant reduction in complexity. In the proposed technique, the sub-bands affected by interference are identified and are further decomposed to be used to reconstruct the jamming signal. Then, the useful GPS signal is obtained by subtracting the estimated jamming signal from the received signal. The performance of the algorithm has been assessed with respect to acquisition and navigation performance. The results show that the proposed algorithm successfully suppressed narrowband jamming without significantly degrading the useful GPS signal.

    Acknowledgments

    This article is based on the paper “A Novel Wavelet Packet-based Jamming Mitigation Technique for Vector Tracking-based GPS Software Receiver” presented at ION GNSS+ 2018, the 31st International Technical Meeting of the Satellite Division of The Institute of Navigation, Miami, Florida, Sept. 24–28, 2018. The research was supported by the Natural Sciences and Engineering Research Council of Canada.

    Manufacturers

    The simulation system used a Spirent Communications Inc. GSS6700 Multi-GNSS Constellation Simulator, a Spirent GSS8366 Interference Combiner Unit and a Keysight Technologies N5172B-503 Interference Signal Generator. The receiver front end used was a NovAtel Inc. FireHose D17088 prototype digital GNSS front end.

    HAIDY Y. ELGHAMRAWY is a Ph.D. candidate in the Department of Electrical and Computer Engineering, Queen’s University, Kingston, Ontario, Canada. She received her M.Sc. degree in engineering physics and mathematics from the Faculty of Engineering, Cairo University, Egypt.

    MOHAMED YOUSSEF is leading GPS/GNSS product development activities for Sony North America. He holds an interdisciplinary Ph.D. degree from the Department of Geomatics Engineering and the Department of Electrical and Computer Engineering, University of Calgary, Canada.

    ABOELMAGD M. NOURELDIN is a cross-appointment associate professor in the Departments of Electrical and Computer Engineering at Queen’s University and the Royal Military College (RMC) of Canada in Kingston. He is the director of RMC’s Navigation and Instrumentation Research Laboratory.

     

    FURTHER READING

    (to come)

  • Simulation tool verifies GPS/INS integrated systems

    Simulation tool verifies GPS/INS integrated systems

    Image: metamorworks/Shutterstock.com
    Image: metamorworks/ Shutterstock.com

    In ultra-tight with new simulation tool

    A GPS/inertial trajectory data simulation podium can generate simulation data sets for all levels of GPS/INS integration. Here it verifies the operation and performance of a new ultra-tight GPS/INS integrated system, adaptable for both software and conventional hardware receivers.

    Navigation systems for land vehicles, embedded in passenger cars, ambulances, police cars, fire trucks and others, provide reasonable accuracy in open-sky environments, but under conditions such as underpasses and tunnels GPS satellite signals cannot be readily tracked since they are not consistently available or have low signal power. One major factor that directly impacts the effectiveness of receivers in terms of complexity and speed is receiver architecture.

    Scalar (conventional) signal tracking architectures process each satellite signal individually: pseudoranges and pseudorange rate measurements are produced separately and only combined in the navigation filter to generate the required solution. Hence, no information exchange happens between the different tracking channels.

    On the contrary, vector tracking systems combine all the channels in one system along with the navigation filter to produce pseudoranges, pseudorange rates and the navigation solution all at the same time. Figure 1 shows the general architecture of a vector tracking system. Vector-tracking architectures have proven themselves able to provide better performance over scalar tracking systems in challenging environments where most satellite signals are received at low signal-to-noise ratios (SNR).

    Figure 1. General view of the vector-based signal tracking system. (Image: Authors)
    Figure 1. General view of the vector-based signal tracking system. (Image: Authors)

    Any information available about the satellite constellation and user position and dynamics can be used to predict the received signals. Therefore, the best estimation we have for the receiver position and dynamics makes the vector tracking loops more robust. One approach to reduce or perhaps remove the receiver dynamic stress in the signal tracking loops is to provide external aiding information.

    Several sensor types have been augmented with GPS to improve navigation system accuracy and reliability. The most common systems that have been widely augmented with GPS are inertial sensor systems (INS). Because an INS system can provide a continuous solution at a high data rate, it is virtually a twin to the GPS with respect to its widespread use in navigation applications.

    Using the solution obtained from INS, one can estimate a line-of-sight acceleration that can be integrated to obtain a line-of-sight velocity. Car odometers also provide reasonably accurate measurements of the vehicle speed. Incorporating this velocity (from INS or other aiding sources) into tracking-loop computations helps the tracking loop to maintain tracking at a lower bandwidth even when high dynamics are experienced at the receiver. When the aiding source to the GPS signal tracking loops is an INS, the system is known as ultra-tight GPS/INS integration. Figure 2 shows a general block diagram of an ultra-tightly coupled GPS/INS integration system.

    Figure 2. Ultra-tightly coupled GPS/INS integrated system. (Image: Authors)
    Figure 2. Ultra-tightly coupled GPS/INS integrated system. (Image: Authors)

    The ultra-tight GPS/INS integrated system enhances a GPS receiver’s tracking ability in challenging environments and consequently improves navigation availability.

    Loose. The loosely coupled integration mode is easier to implement since the inertial and GPS navigation solutions are generated independently before being weighted together in a separate navigation filter. The advantages of this coupling strategy are that the INS errors are bounded by the GPS updates, the INS can be used to bridge GPS updates, and the GPS can be used to help calibrate the deterministic parts of the inertial errors instantly. The main drawback of this strategy, however, is that it requires at least four satellites in view which cannot always be guaranteed because of signal interruption due to many factors such as signal blockage by trees or tall buildings.

    Tight. The tightly coupled integration mode combines both systems into a single navigation filter. The major limitation of visibility of at least four satellites is removed since this integration mode can provide a GPS update even if fewer than four satellites are visible. The tightly coupled architecture also overcomes the problem of correlated measurements that arises due to cascaded Kalman filtering in the loosely coupled approach. However, these advantages come with the penalty of increased system complexity.

    Ultra-tight. In the ultra-tightly coupled integration approach, the raw measurements come from one step further towards the front end of a GPS receiver, in the form of I (in-phase) and Q ( quadrature ) signal samples. These I and Q measurements are integrated with the position, velocity and attitude of the INS in a complementary filter. The integration of INS-derived Doppler feedback to the carrier tracking loops provides a vital benefit to this system; the INS Doppler aiding removes the vehicle Doppler from the GPS signal. Hence, it results in a significant reduction in the carrier tracking loop bandwidth. In addition, due to lower bandwidths, the accuracy of the raw measurements is further increased.

    The proposed method uses a variant of the Kalman filter as the core of the navigation processor coupled with the inertial sensor’s input in a reduced inertial sensor system (RISS) configuration and car speed odometer; see Figure 3. Additionally, the data sets used in this work are generated using a newly composed GPS/INS trajectory data simulation platform.

    Figure 3. Reduced inertial sensor system (RISS). (Image: Authors)
    Figure 3. Reduced inertial sensor system (RISS). (Image: Authors)

    Secondly, it demonstrates a novel GPS/INS trajectory data simulation podium. This combined simulation system can produce simulation data sets for all levels of GPS/INS integration and is used to verify the operation and performance of the ultra-tight GPS/INS integrated system.

    SYSTEM ARCHITECTURE AND IMPLEMENTATION

    The goal of signal tracking loops is to monitor changes in the main signal parameters, namely, code phase and carrier frequency, to keep the locally generated signal aligned with the received signal. Successful tracking of these variables will provide good estimations of the parameters that are required for the navigation filter to function correctly. Errors in the code phase and carrier frequency are usually represented as:

       (1)

       (2)

    where  and  are the measured and estimated code phases, respectively.  and  are the measured and estimated carrier Doppler frequencies, respectively. These estimated errors at the signal tracking stage are directly linked to the errors in the states at the navigation filter.

    Each tracking channel provides its own measurements based on a discriminator’s output. All the measurements are then processed together in the navigation filter and feedback is provided to each channel based on the obtained navigation solution results. The filter will process the error signals received from the discriminators in the form of code phase error  and frequency error . Thus, the measurements of the filter will be pseudorange errors and pseudorange rate errors.

      (3)

      (4)

    Where fcode is the code frequency = 1.023 x 106 Hz, fcarrier is the nominal L1 frequency = 1575.42 MHz, and η represents the measurement noise vector.

    The computations of the navigation solution start with a mechanization process where we first calculate pitch, roll and azimuth angles. Knowing the Azimuth and pitch angles, vehicle forward velocity can be projected into East, North and Up velocities. The East and North velocities are transformed into geodetic coordinates and then integrated over the sample interval to obtain positions in latitude and longitude. The vertical component of velocity is integrated to obtain altitude. At this stage, we run the Kalman navigation filter through its two-step known cycle, prediction and update, incorporating any available measurements to estimate the receivers’ new position and velocity. Then, the estimated pseudoranges and pseudorange rates are calculated. Finally, the computed code and carrier frequencies are fed back to control the code and carrier oscillator inputs to align the locally generated signal with the incoming signal.

    COMBINED SIMULATION SYSTEM

    In our work, we combined two existing INS and GNSS simulators to build a comprehensive simulation tool that can produce a limitless number of data sets of repeated trajectories under entirely controlled circumstances. Moreover, these data sets can be used for any level of GPS/INS integration system validation. The system is also used to verify the performance of the above proposed ultra-tight GPS/INS integration system architecture.

    For the GPS data, a satellite navigation simulation signal generator was used to build and generate the desired trajectory. The selected model has the ability to provide dynamic capacity in Doppler and signal power levels as well as adequate channels to simulate line-of-sight and multipath satellite signals. The unit is driven by a software package that comes in different versions; the most powerful version is used in this research to drive the simulation hardware system to generate the output radio frequency (RF) signal.
    A receiver front-end then generates the discretized data stream in the form of in-phase (I) and quadrature-phase (Q) signals. The unit is a rugged dual-frequency L1/L2 front-end intended mainly for software receiver and interference detection systems. The unit is capable of logging L1/L2 data at bandwidths of 2.5 MHz, 5.0 MHz, 10 MHz and 20 MHz with data quantization varying from 1 bit to 8 bits.

    For the INS data sets, the INS simulator, developed by the Mobile Multi-sensor Group at the University of Calgary, is used for simulating inertial measurement unit (IMU) raw data. The INS simulator can virtually generate the raw data measurements of any grade of IMUs such as navigation, tactical and consumer-grade systems. A wide number of sensor errors can be simulated using this software such as bias instability, random walk, scale factor, errors due to thermal drift and g-sensitivity and so on. While the simulator can generate raw IMU measurements using user-defined vehicle motion and dynamics, such as static scenarios, straight line, constant velocities, accelerations, turns and bumpy roads, and it can also accept externally injected vehicle dynamics from real trajectory data.

    Figure 4 shows a high-level diagram of the trajectory data flow from the two arms of the synthesized simulator. Several conversion code scripts were written to convert raw data into the implementation platform workspace format. Both data sets were then merged through the implemented algorithm to provide the navigation solution.

    Figure 4. Data simulation tool flow diagram. (Image: Authors)
    Figure 4. Data simulation tool flow diagram. (Image: Authors)

    Step 1 of Simulation Process. The trajectory design, Figure 5, outlines the general aspects of the process. Among these are the type of platform to be simulated, for example. land vehicles, ships, aircraft and so on; the satellite constellation, typically GPS, Galileo or GLONASS; the environment, whether rural, suburban or urban; and error sources, including ionospheric and tropospheric effects. All of this is done using the simulator’s software.

    Figure 5. Trajectory data flow Step 1. (Image: Authors)
    Figure 5. Trajectory data flow Step 1. (Image: Authors)

    Step 2. This incorporates the implementation of the data stream that is fed into the signal generator hardware, which transforms this into an RF signal (Figure 6). Concurrently, the reference trajectory data is logged on the same computer that hosts the simulation software. The I and Q branches are recorded, simultaneously with the reference trajectory, on a GNSS receiver front-end.

    Figure 6. Trajectory data flow Step 2. (Image: Authors)
    Figure 6. Trajectory data flow Step 2. (Image: Authors)

    Step 3. Finally, the inertial data is simulated. First, the INS simulator is configured according to the desired simulation parameters. Among these are the sensor data rate, grade (or quality) of the selected sensor(s), and some initialization quantities that are obtained from the output of the GNSS signal simulator. Once the configuration process is complete, data extracted from the reference trajectory is converted into a format appropriate to the INS simulator, and the inertial data simulation is performed. At this stage, data from both the GNSS side and INS side can be converted into a format suitable for use by the integrated INS/GNSS system (see Figure 7).

    Figure 7. Data flow, Step 3. (Image: Authors)
    Figure 7. Data flow, Step 3. (Image: Authors)

    EXPERIMENTAL WORK

    Using the complete simulation system, several simulation data sets are used to verify the performance of the proposed algorithm in semi real-life scenarios. Each time a chosen scenario is run on the Spirent GNSS simulator, the software data is applied to the Spirent hardware to generate the RF signal, which is then applied to the input of the front-end unit to provide the corresponding I and Q signal streams. Meanwhile, the trajectory data is logged from the simulator to be used as a reference and then fed to the INS simulator to generate the corresponding raw IMU data. Finally, the I and Q and raw IMU data are combined (when the ultra-tight solution is used) in a software receiver code to extract the ultimate positioning solution. For scalar and vector-based signal tracking, only GPS data is used. One sample trajectory that simulates a land vehicle driving at low speed is selected to show results of the proposed method.

    Table 1 shows initialization of the key parameters during the simulation period. A GPS-only satellite constellation is used. We also limited the maximum number of simulated satellites to seven.

    RESULTS

    The reference solution used to evaluate the proposed method and combined simulation system is the pure data sets extracted from the Spirent GNSS simulator. The figures below show results of 80 seconds of data processing. At around seven seconds of the period, a 43-dB signal drop was applied for 8 seconds on channel number 1, which is assigned to track PRN number 06. A similar signal drop is partially overlapped with this, but was applied for only 5 seconds on channel number 3, which is dedicated to track PRN number 21. The following abbreviations are used in the figures: ST for scalar tracking, VT for vector tracking, and UT for ultra-tight GPS/INS integration system.

    Figure 8 and Figure 9 show the carrier frequency for PRN 06 and PRN 21. Large frequency errors (greater than 100 Hz) are noticeable in the scalar tracking system. The vector tracking system, however, was much less affected, showing more resistance to the drop in signal-to-noise ratio. The ultra-tight GPS/INS integration system was nearly unaffected and maintained a very accurate carrier frequency estimation throughout the simulated trajectory.

    Figure 8. Estimated carrier frequency for PRN #6. (Image: Authors)
    Figure 8. Estimated carrier frequency for PRN #6. (Image: Authors)
    Figure 9. Estimated carrier frequency for PRN #21. (Image: Authors)
    Figure 9. Estimated carrier frequency for PRN #21. (Image: Authors)

    The trend of the position errors is plotted in Figures 10, 11 and 12. The maximum position error was around 15 meters in the case of vector tracking, whereas the maximum position error from the ultra-tight system was below 4 meters in the worst case.

    Figure 10. Position X error. (Image: Authors)
    Figure 10. Position X error. (Image: Authors)
    Figure 11. Position Y error. (Image: Authors)
    Figure 11. Position Y error. (Image: Authors)
    Figure 12. Position Z error. (Image: Authors)
    Figure 12. Position Z error. (Image: Authors)

    Velocity errors are depicted in Figures 13, 14 and 15. Velocity errors for the vector tracking system reached about 2 meters per second during the low signal-to-noise ratio period. However, they were only small fractions of a meter per second for the ultra-tight GPS/INS integration system.

    Figure 13. Velocity X error. (Image: Authors)
    Figure 13. Velocity X error. (Image: Authors)
    Figure 14. Velocity Y error. (Image: Authors)
    Figure 14. Velocity Y error. (Image: Authors)
    Figure 15. Velocity Z error. (Image: Authors)
    Figure 15. Velocity Z error. (Image: Authors)

    CONCLUSIONS

    This article shows the performance of a newly proposed ultra-tight GPS/INS integrated system using an RISS that is intended to enhance GPS receivers’ tracking ability in challenging environments, thus improving navigation availability. Additionally, we present a freshly combined GPS/INS trajectory data simulator that can be used to generate simulation data sets for all levels of GPS/INS integration. The two components of the simulator are demonstrated to be perfectly linked. Performance of the algorithm was tested using several trajectories, and the algorithm demonstrated durability against harsh signal degradation. Acceptable position and velocity errors were achieved. Expected future improvements to the algorithm aim to employ longer integration time, and the performance of different grades of IMUs are to be simulated.

    ACKNOWLEDGMENT

    This work described in this article was first presented at the ION GNSS+ 2018 conference in Miami, Florida.

    MANUFACTURERS

    The Spirent GSS6700 Satellite Navigation Simulation Signal Generator was used in these tests, with SimGen software. The NovAtel FireHose front-end generated the discretized data stream.

    MALEK KARAIM is a Ph.D. candidate at the Department of Electrical and Computer Engineering, Queen’s University, Canada. He is working within the Navigation and Instrumentation Research (NavINST) Group at Queens’ University/Royal Military College of Canada.
    MOHAMED YOUSSEF received his Ph.D. degree from the Department of Geomatics Engineering and the Department of Electrical and Computer Engineering, University of Calgary, Alberta, Canada. He leads GNSS R&D activities at Sony North America.
    ABOELMAGD NOURELDIN is a cross-appointment associate professor at the departments of electrical and computer engineering in Queen’s University and the Royal Military College (RMC) of Canada. He is the director of the Navigation and Instrumentation Research Laboratory at RMC.

  • Software-based GNSS receiver available on Cadence digital signal processor

    A software-based GNSS receiver from Galileo Satellite Navigation (GSN) is now available for the Cadence Tensilica Fusion F1 digital signal processor (DSP).

    The software-based GNSS receiver allows customers to add full GPS functionality with design flexibility and long-term upgradeability at a minimal cost, low power and no physical size to today’s cost-sensitive internet of things (IoT) applications, according to Cadence Design Systems.

    To get the lowest possible power, GSN accelerated the performance of its GPS software receiver by creating several custom instructions to run on the Tensilica Fusion F1 DSP. As a result, the GPS software requires less than 110 MHz for full 12-satellite functionality.

    Additionally, with this software-based solution, customers can reduce the overall processor requirements to meet less-demanding location-based use cases such as asset tracking.

    “The Tensilica Fusion F1 DSP delivers outstanding performance for the implementation of our GNSS receivers, providing a low-power footprint required for IoT applications,” said Eli Ariel, CEO at GSN. “This enables customers to easily upgrade their Fusion F1 DSP-based designs to future satellite systems such as Beidou, GLONASS and Galileo via software. By leveraging several customized instructions in the Fusion F1 DSP, we were able to keep the required processor speed at the same frequency compared to DSPs with more than three times the processing power.”

    “GSN’s software-based approach for GNSS allows our Fusion F1 DSP customers to precisely scale their GNSS receiver requirements to meet their applications needs,” said Gerard Andrews, group director marketing, at Cadence. “The availability of GSN’s technology on this low-power DSP platform allows our customers to add location-based services at minimal cost and power.”

    The Tensilica Fusion F1 DSP offers low-energy, high-performance control and signal processing for a broad segment of IoT/wearable markets. This highly configurable architecture is specifically designed to excel at always-on processing that requires a merged controller plus DSP, ultra-low energy and a small footprint.

    The DSP is efficient in running the narrowband wireless communications standards typically associated with IoT device communications, including protocols such as Bluetooth Low Energy, Thread and Zigbee using IEEE 802.15.4, Wi-Fi 802.11n and 802.11ah and GNSS.

  • Trimble unveils software GNSS receiver for high-accuracy in mobile devices

    Trimble has introduced Catalyst, a software-defined GNSS receiver that works with select Android mobile handhelds, smartphones and tablets. When combined with a small, lightweight, plug-and-play digital antenna and subscription to the Catalyst service, the receiver provides on-demand GNSS, geo-location capabilities to transform consumer devices into high-accuracy mobile data collection systems.

    The announcement of the new product, designed for GIS professionals, was made at Trimble Dimensions.

    Through smartphone and tablet developments accelerated by the bring your own device (BYOD) to work movement, field workers and consumers increasingly have access to positioning technologies for geospatial data use and collection. The Catalyst software receiver collects data and inspects or manages assets using smart devices. The software-defined GNSS receiver is designed to be integrated into a wide range of applications—providing a dual-frequency, multi-constellation receiver. The mobile device receives dual-frequency signals from the plug-and-play Trimble DA1 digital antenna. The small size and light weight of the antenna makes it possible to store in a car glove box or backpack, available for use on demand. By adding a Trimble Catalyst subscription, users can choose the level of accuracy to suit their application needs from meter level to centimeters.

    Trimble calls its Catalyst service Positioning-as-a-Service. It is available on-demand. Users download applications to suit their business needs, purchase the low-cost DA1 digital antenna and subscribe to the level of service required for the application. For GNSS corrections, the solution automatically selects the best available correction service based on the user’s location and subscription level. Corrections powered by Trimble RTX technology and the Trimble VRS Now networks are supported. Trimble RTX corrections can be received either via IP/cellular connection or L-band satellite. The subscription cost is based on usage, allowing users to scale up/down for projects with minimal capital expense.

    “The addition of Trimble Catalyst expands our portfolio to address the needs of organizations that have adopted a workplace Bring Your Own Device (BYOD) strategy for their businesses and individuals who periodically need accurate positioning to support various work activities,” said Ron Bisio, vice president of Trimble’s Geospatial Division.

    TerraFlex Geospatial Data Collection. The first available application for the Trimble Catalyst service is the Trimble TerraFlex cloud-based mapping and GIS field software, enabling users to achieve up to centimeter-level accuracy. TerraFlex is a scalable cloud-based solution addressing a  variety of field requirements including attribute-rich GIS data collection on consumer devices. With an intuitive interface and streamlined toolset for creating custom digital form templates, TerraFlex keeps the data flow standardized and streamlined from the field to the office.

    TerraFlex provides a common interface for users across a range of common mobile and smart devices to provide robust, high-accuracy GNSS positioning and detailed asset attribution collection. The Catalyst service for TerraFlex provides a new option for a higher level of accuracy for users’ workflows without the upfront investment of traditional hardware GNSS receivers. It enables scaling up to meet specific project demands and allows a workforce to collect high-accuracy location in conjunction with other work tasks.

    Availability. Catalyst service subscriptions and Catalyst DA1 antenna are expected to be available in the first quarter of 2017. In addition, a Software Development Kit (SDK) is expected to be available in the fourth quarter of 2016 for developers who are interested in developing new applications that use the Trimble Catalyst positioning on-demand service. Information and updates.

    TerraFlex is available now.

  • Launchpad: Time and frequency server accurate in all conditions

    Launchpad: Time and frequency server accurate in all conditions

    The VersaSync is a new generation time and frequency server from Spectracom. The high-performance GNSS master clock and network time server delivers accurate, software-configurable time and frequency signals in all circumstances, including GNSS-denied environments.

    versasync-spectracom-wIt is based on a platform-approach to maximize versatility without restricting performance, which maintains or improves high-performance standards from larger form factors while reducing the footprint. The result is a rugged and compact design suitable for air, land or sea applications.

    Standard VersaSync configurations are designed in accordance to VITA 75, which was developed for easy integration of subsystems in mobile platforms. The overall volume is under 1 liter, the weight is less than 1 kilogram, and its power consumption is approximately 10 watts.

    The list of design features for harsh environmental conditions include mil-performance circular connectors, a sealed enclosure (IP65), and an efficient heat transfer via the conduction-cooled based plate. Spectracom is currently confirming its extensive reliability and compatibility modeling to military specifications.

    Versatility is also the theme for the VersaSync’s internal time-base, compatibility with external time and frequency reference sources, and time and frequency signal generation. It is available with a choice of a very low-phase noise ovenized crystal oscillator (OCXO) or chip-scale atomic clocks (CSAC), and can accommodate other high-precision internal time references. Similarly, it is available with various GNSS receivers including multi-constellation receivers and SAASM encrypted GPS with an upgrade path to M-code.

    Software-defined digital timing I/Os offer mission-to-mission configurability of virtually any timing signal. Network synchronization and management also offers a high degree of flexibility. Two gigabit Ethernet interfaces are available for network synchronization protocols (NTP and PTP) as well as for configuration, status, logging and upgradability.

    Applications

    • UAVs
    • flight test
    • telemetry
    • mobile communication systems
    • C4ISR (command, control, communications, computers, intelligence, surveillance and reconnaissance)

    Spectracom, spectracom.com

  • Israeli startup aims for flexibility with GNSS software receiver

    Galileo Satellite Navigation Ltd. (GSN), an Israeli startup, is demonstrating a navigation solution that can “pull the sword out of the stone,” said Uri Michon, sales and marketing manager for GSN.

    The company has developed its own GNSS software receiver, and is now in the final stage of integration to a Korean (long-term evolution) LTE integrated circuit (IC) manufacturer platform.

    As opposed to a standard hardware receiver convention of one size fits all, GSN offers a tailor-made flexible solution that accommodates each customer’s use cases, performance needs and system resource tradeoff.

     

    The receiver requires any regular RF front-end, simple glue logic and existing platform digital signal processor (DSP)/central processing unit (CPU). The receiver is hardware agnostic and has already been demonstrated working on CEVA, Cadence, ARM and Intel processors.

    While reducing the need for an external IC, the customer gains the ability to install only the GNSS constellation required, reducing inventory and solution costs. The customer can also introduce upgrades (new constellation features) and updates when available.

    GSN is targeting the cellular market, but the company said its flexibility and ability to create a low resource solution has its best fit for the rapdily evolving markets of machine-to-machine (M2M), the Internet of Things (IoT) and wearables.

  • IFEN’s v3.0 of SX3 GNSS Software Receiver Adds Functions

    IFEN has launched the latest software release, v3.0, for its SX3 GNSS Software Receiver Generation.

    The newly released software version 3.0 offers the following new features:

    • Real‐time P‐code generator and P‐code aiding for GPS L1/L2 cross‐correlation
    • Full dual‐antenna support for SX3 Black Edition
    • KML file output for Google Earth real‐time visualization
    • better performance through switch from 32-bit to 64-bit version
    • support of new SX3 RF front‐end with up to 12 IF streams

    IFEN’s SX3 multi‐GNSS software receiver now tracks all known and in future upcoming GNSS signals in view in real‐time on a standard laptop (up to 1,000 channels in parallel on a core i7 desktop PC). The included RF front‐end offers four RF frequency chains with 50 MHz bandwidth each, covering the entire GNSS L‐band spectrum.

    The USB 3.0 interface enables high‐speed data transfer with up to 8 bit quantization. Customers can fully concentrate on their applications instead of dealing with potentially obscure code when using open source. The professional support is specifically dedicated to sophisticated applications as well as SX3’s capability for additional customizations. This makes IFEN’s SX3 GNSS software receiver a powerful tool for research and development, IFEN said.

    In addition a dual‐antenna input RF front‐end (SX3 ‘Black Edition’) has been released in February 2015. This system can for example be used for heading determination, reflectometry and other applications requiring the synchronized input from two antennas.

  • Innovation: Python GNSS Receiver

    Innovation: Python GNSS Receiver

    An Object-Oriented Software Platform Suitable for Multiple Receivers

    By Eliot Wycoff, Yuting Ng, and Grace Xingxin Gao

    INNOVATION INSIGHTS by Richard Langley
    INNOVATION INSIGHTS by Richard Langley

    AND NOW FOR SOMETHING COMPLETELY DIFFERENT. My first introduction to computer programming was during a visit to the Faculty of Mathematics at the University of Waterloo when I was still a high school student. We got to keypunch a simple program onto cards using the FORTRAN programming language and submit the “job” to the university’s IBM 7040 mainframe computer. That visit helped seal the choice of Waterloo for my undergraduate education — but in applied physics, not math.

    Once I became an undergraduate, I learned how to properly program in FORTRAN (actually FORTRAN IV with the WATFOR compiler developed at Waterloo) and in assembly language on the SPECTRE virtual computer (written in FORTRAN), both on Waterloo’s new IBM 360 mainframe. Knowing how to program was instrumental in my graduate work on the geodetic application of very long baseline interferometry (VLBI) at York University. Being humble Canadians (and despite the fact that VLBI was invented in Canada), we called it just LBI. My LBI data analysis FORTRAN program was initially on a box full of punched cards that I would have to carry back and forth to the computer center being careful not to drop the box and get the cards out of order.     

    While I was a graduate student, I also got to use the Spiras-65 minicomputer that controlled the playback of the LBI recorded tapes at the National Research Council in Ottawa.  It was programmed using punched paper tape.

    I saw the progression from punched tape and cards to the use of terminals to enter programs and magnetic tapes for storing them and the data to be analyzed. The University of New Brunswick, where I came to work in 1981, was one of the first universities in Canada to introduce an interactive terminal- (or work-station-) based time-sharing system for programmers to develop and run their jobs on the central computer. The last card reader at UNB was retired in 1987.

    By the time I came to work at UNB, the era of the personal computer had already dawned. Although the Department of Surveying Engineering (as it was then called) acquired an HP 1000 minicomputer for various research tasks, personal computers began to show up on faculty members’ desks and in their labs. Some of us started out with Apple II computers (we used them, for example, for recording data from Transit–U.S. Navy Navigation Satellite System–receivers) and progressed through various Macintosh models.

    Once I became a professor, I did less and less programming myself–leaving it up to my graduate students to do the heavy lifting in that area. These days, my personal programming efforts are limited to short scripts mostly using the Python language. Python, which gets its name from the Monty Python’s Flying Circus television series, was first introduced back in 1991 but it is only relatively recently that its popularity has taken off. Python can be run on a wide variety of platforms under many operating systems.

    One of the key features of Python is that it supports multiple programming paradigms, including object-oriented programming (OOP).  OOP is a programming methodology based on the use of data structures, known as objects, rather than just functions and procedures. The objects, organized into classes, exchange information in a standardized way and their use helps ensures good code modularity.

    In this month’s column, we take a look at how Python has been used to develop a software-defined GNSS receiver — one well-suited to processing data from a network of receiver front ends.

    “Innovation” is a regular feature that discusses advances in GPS technology and its applications as well as the fundamentals of GPS positioning. The column is coordinated by Richard Langley of the Department of Geodesy and Geomatics Engineering, University of New Brunswick. He welcomes comments and topic ideas. Email him at lang @ unb.ca.

    With billions of GNSS-enabled devices in use today, the potential gains from harnessing data collected over a network of GNSS receivers has never been greater, yet the necessary architectures to handle and extract useful data collected over such networks are not well explored. Traditional uses of GNSS in cooperative positioning treat individual GNSS receivers as “black boxes” that merely output navigation solutions. As such, the wealth of information contained in each receiver’s raw signals is largely discarded.

    Of particular interest are ideas such as inter-receiver aiding, in which networked receivers might share acquisition, tracking, and navigation information (possibly in real time) to improve receiver performance. In addition, a network of receivers might also be used as a sensing tool: it is expected that atmospheric parameters, for instance, could be recovered by analyzing the raw signal data arriving at an appropriately sized network.

    In light of these interesting research areas, it would be expedient to develop a set of tools that can process and handle the raw data being produced at every receiver in a GNSS receiver network. Existing software-defined receivers (SDRs) have gone a long way towards making the fast prototyping of new receiver architectures possible. An SDR attempts to shift as many receiver functions, such as mixing and tracking, from being implemented in hardware to being implemented in software. This allows for fast prototyping as receiver components can be more quickly modified in software than in hardware. The hardware components that a GNSS SDR still requires are an antenna and a front end including an analog-to-digital converter (ADC). An analog GNSS signal is received at the antenna. It is then mixed to an intermediate frequency and digitized by the ADC. The digital stream is then processed by the SDR’s software component.

    But with regard to processing data from a receiver network, existing SDRs have a number of notable flaws. In brief, existing software receivers are designed to process the data arriving at one real-world receiver. Thus a procedural coding design is typically used. While procedural code is a good solution for the linear processes that occur in a single receiver (acquisition, tracking, demodulation of the navigation data, position calculations, and so on), this software design style does not adapt well to the task of performing all of these actions on multiple receivers with the additional goal that each receiver shares tracking data with every other one. In such scenarios, not only is there data being produced for every receiver in the network, but there is also data being produced about the relationships between the receivers in the network. Thus, an SDR that was originally designed to process data from only one receiver will prove difficult to adapt to the task of processing many.

    Luckily, object-oriented programming, a well-known and widely used software design philosophy, is well suited to the receiver network problem. Therefore, for this work, we designed and implemented an object-oriented software platform for many receivers. Python was chosen as the programming language because of its support for object-oriented programming, its portability, its free cost, its numerical abilities (using open-source libraries such as NumPy and SciPy), and its ease of use. And as a reference, an existing Matlab software receiver was used as a basis for developing many of the core algorithms in this work. We call our development simply the Python Receiver.

    Design

    Many of the core functions in the Python Receiver are modeled after those found in the Matlab development. Thus, this particular implementation is suited for the raw GPS L1 signal data mixed to an intermediate frequency by the SDR front end. In addition, the basic algorithms for acquisition, scalar tracking, and navigation are similar to the Matlab ones, with the exception that acquisition is made more robust by using multiple noncoherent integrations. The primary innovation of this software, however, is in the way in which the code is organized. For tracking multiple receivers, the Python Receiver was designed under an object-oriented approach.

    FIGURE 1 illustrates the main objects that a user would be expected to use in the Python Receiver. Each object is defined as a class, and as such each object is capable of storing object-specific data as well as performing certain object-specific functions. The hierarchy of Figure 1 roughly illustrates which objects are defined as members of other classes for typical usage. Thus, inside any instance of the network class may exist any number of receiver objects. Likewise, an instance of the constellation class may be home to any number of satellite objects.

    FIGURE 1. Typical object (class) hierarchy.
    FIGURE 1. Typical object (class) hierarchy.

    For data coming from a single real-world receiver, use of the Python Receiver would typically be as follows. First, a user would initialize an instance of the receiver class using a dictionary of predefined settings, such as the file location of the data source. Second, the user would initialize a constellation object of satellites by passing the pseudorandom noise (PRN) code values of each satellite to be included in the constellation. At this point, the user could then use built-in functionality in the receiver object to perform acquisition of all of the satellites in the constellation. Results of this acquisition attempt would be stored in the receiver object, where they could then be used to run the receiver’s built-in scalar tracking functionality. Likewise, scalar tracking data would be stored in the receiver object, and again the user could use the receiver’s built-in navigation functionality to decode the navigation bits produced during scalar tracking and perform navigation computations. Satellite-specific ephemerides would be stored in the relevant satellite objects.

    Navigation solutions are stored as a part of the receiver’s state object. The state object, which is also used in the satellite class, is a container for holding state information in the Earth-centered Earth-fixed (ECEF) coordinate system (such as position and velocity) and clock terms, and it also provides the ability to return position coordinates in other systems, such as the GPS geodetic system (frame) of WGS 84. While it is not a key feature of the Python Receiver, the state object is designed as an object so that it can be readily used elsewhere should an algorithm need to store state information and have coordinate transformations readily available.

    Tracking channels need not be restricted to the hierarchy shown in Figure 1. During operation for just one data source, the scalar tracking function defined at the receiver level will initialize a sufficient number of tracking channels to track all of its observed satellites. However, when operating on multiple sources of data and with the intent to share tracking outputs between channels, it is helpful to place tracking channels into groups, as shown in FIGURE 2. In the example that will be discussed in following sections, two real-world receivers observed a similar set of satellites. It was therefore helpful to define channel groups for each commonly observed satellite, with one channel in the group corresponding to the satellite as tracked by the first receiver, and the other channel corresponding to the satellite as tracked by the second. Tracking groups as a class, however, may be easily modified for other experimental purposes.

    FIGURE 2. Left: an independent tracking channel (corresponding to one tracking channel object). Right: a channel group. Note that in the channel group, updates to the code and carrier phase of each channel may be performed cooperatively.
    FIGURE 2. Left: an independent tracking channel (corresponding to one tracking channel object). Right: a channel group. Note that in the channel group, updates to the code and carrier phase of each channel may be performed cooperatively.

    Independent tracking channels have an update function that processes the next segment of raw data in three main steps: computing correlations (early, late, and prompt), producing discriminator outputs, and generating code and carrier-frequency updates. For a group of channels, this sequence of steps is interrupted after discriminator outputs have been computed. At this point, the channel group may instruct the tracking channels to update their code and carrier frequencies independently or through some other cooperative means that considers data across all of the channels.

    As for the last few classes: correlators and filters are defined as objects so that they can be easily changed depending on the experimental circumstances. And satellites, in addition to holding satellite-specific ephemerides, have built-in functionality to return their locations given a particular epoch of GPS Time.

    Naturally, core functions such as these would be found in traditional software receivers, but by repackaging them into the object-oriented framework, both code reusability and modifiability increase. And in addition, by defining classes for networks of receivers and groups of tracking channels, simulations and experiments involving cooperative positioning of receivers become easier to conduct.

    Experiment

    To help illustrate how the Python Receiver lends itself to the task of cooperatively tracking multiple receivers, concurrent data from two SDR front ends was collected on a boat in Lake Titicaca just offshore from Puno, Peru. The boat was a small motorized ferry capable of transporting approximately twenty passengers. One antenna and front end, hereafter referred to as “Receiver X” was placed on the port side of the boat, while the other, “Receiver Y” was placed on the starboard side. Maintaining a fixed baseline, both receivers captured raw GPS L1 signals from separate portions of the sky and mixed them to an intermediate frequency of 5.456 MHz. Raw data collection was performed concurrently at both receivers for 15 minutes as the boat returned from the floating islands of the Uros people to the dock at Puno. Finally, while Lake Titicaca is at a high elevation in the Altiplano (the Andean Plateau), the surrounding mountains do not rise far above the horizon, and thus visibility was quite good in most directions.

    Some challenges, however, present themselves in this data set. While Receiver X was able to acquire eight satellites, and Receiver Y was able to acquire 10, the signal quality at Receiver Y was generally poor. In Figure 3, in-phase prompt correlator outputs from traditional scalar tracking are shown for both Receivers X and Y and satellites with PRN codes 27 and 29. For satellite 27, Receiver Y loses lock of the signal between code periods 100,000 and 200,000, and for satellite 29, it completely loses track of the signal after only a few thousand code periods. (Recall that the C/A-code period is one millisecond.)

    FIGURE 3. The in-phase prompt correlator outputs for both receivers and satellites PRN 27 and 29. The cyan dots are correlator outputs, the red line is the locking metric, and the dashed green and blue lines are the thresholds set for determining good and poor lock, respectively. Locking metric values above the dashed green line represent a good lock, and values below the dashed blue line represent loss-of-lock. Note that y-axis values differ from graph to graph.
    FIGURE 3. The in-phase prompt correlator outputs for both receivers and satellites PRN 27 and 29. The cyan dots are correlator outputs, the red line is the locking metric, and the dashed green and blue lines are the thresholds set for determining good and poor lock, respectively. Locking metric values above the dashed green line represent a good lock, and values below the dashed blue line represent loss-of-lock. Note that y-axis values differ from graph to graph.

    To better characterize the tracking performance of each receiver-satellite pair, a locking metric was designed and implemented, the values of which are shown as the red lines in the graphs of Figure 3. Inspired by the earlier use of the square-law detector, we have expressed the metric as:

    Python-Eq1(1)

    where N is the number of most recent correlator samples, Ii and Qi are the ith in-phase and quadrature-phase prompt correlator outputs, and the square-root operator returns the negative square root of the absolute value of the expression under the radical if that expression is negative.

    After visually examining the relationship of this locking metric with the quality of the in-phase prompt correlator outputs, two thresholds were determined in order to better characterize the quality of the tracking loop lock. The first threshold, represented as the dashed green lines in the graphs of Figure 3, is the threshold above which the tracking loops were considered locked well. Its value was set to 250. The second threshold, whose value was set to 150 and is represented by the dashed blue lines, is the threshold below which the tracking loops were considered to be in a complete loss-of-lock situation. Locking metric values between 150 and 250 were considered as representing a situation in which the tracking loops were weakly locked to the incoming signals.

    Despite the poor performance of Receiver Y in tracking many of its signals, navigation functionality in the Python Receiver was still able to recover sufficient ephemerides from the tracking data to perform position calculations. FIGURE 4 shows the navigation solutions for Receiver Y over a 13-minute interval, roughly capturing the route that the ferry took westward back to Puno. Note that the moustache-shaped region in the right-hand side of the map is the collection of floating islands of the Uros. Just as the ferry left these islands, the navigation solutions for Receiver Y become much nosier. Possible reasons for this are the slight change in heading that the ferry made, or the thicket of reeds that surrounded the boat during this portion of the journey. Navigation results for Receiver X were much less noisy.

    FIGURE 4. The trip back to Puno on the left (west) from the floating islands of the Uros on the right (east) as determined by traditional scalar tracking and navigation at Receiver Y. Image courtesy of Google Earth and the GPS Visualizer.
    FIGURE 4. The trip back to Puno on the left (west) from the floating islands of the Uros on the right (east) as determined by traditional scalar tracking and navigation at Receiver Y. Image courtesy of Google Earth and the GPS Visualizer.

    Cooperative Scalar Tracking

    While all of these traditional results were obtained using the Python Receiver, they could have just as easily been obtained using procedurally coded receivers. Assuming, however, that one is interested in performing experiments that involve data sharing between multiple receivers, the Python Receiver lends itself handily to the task.

    An experiment was devised in which scalar tracking performed at both Receivers X and Y would be done cooperatively. In particular, it was observed that often when one of the two receivers momentarily lost track of its signal for a particular satellite, the other receiver would be tracking well. In addition, it was noted that because the two receivers maintained a fixed baseline during tracking, their tracking channels should have maintained a steady difference in code phases that changed slowly provided that the receiver-satellite geometry did not change quickly. As shown in FIGURE 5, the only violation of this scenario would occur when one of the two receivers lost lock and thus allowed for drift in its code-tracking loop. It should be noted that unlike the situation in Figure 5, the reported code difference between the two receivers suffered from a bias that grew linearly in time. This bias, which was likely due to clock errors in one or both of the receiver front ends, was eliminated through a linear regression before the plotting of the figure.

    FIGURE 5. The code-phase difference between Receivers X and Y for PRN 27 from 300,000 to 500,000 milliseconds. Note the large variance around 400,000 milliseconds corresponding to a loss-of-lock for Receiver Y.
    FIGURE 5. The code-phase difference between Receivers X and Y for PRN 27 from 300,000 to 500,000 milliseconds. Note the large variance around 400,000 milliseconds corresponding to a loss-of-lock for Receiver Y.

    All of these observations motivated the following cooperative scalar tracking design. First, any satellite that was observed by only one receiver would be independently tracked by that receiver in the traditional manner. A single tracking loop object would be allocated in Python for this particular receiver-satellite pair. Second, any satellite that was observed by both receivers would have a channel group object allocated in Python. This channel group would contain two tracking channel objects, one for each receiver.

    As shown in Figure 2, this channel group required specific code to be written to handle the cooperative updates of both receivers’ code and carrier frequencies. The algorithm was designed as follows. For each update epoch (generated by a call of the channel group’s update function), if both of the tracking channels were locked to their incoming signals, the channel group would save their code-phase difference for that code period. And since both channels were locked, both would update their code and carrier frequencies in the traditional manner, relying on discriminator outputs only.

    If, on the other hand, one of the tracking channels was in a loss-of-lock situation, the channel group would search the previous 5,000 milliseconds of data for code periods during which, presumably, both tracking channels were mutually locked. This data would contain information about the expected code-phase difference between the two tracking channels at the current code period. At this point, a linear regression on the data from the mutually locked code periods was used to determine this expected code-phase difference. Finally, we note again that this expected code-phase difference would only remain valid under the assumption that the receiver-satellite geometry was not changing rapidly, as was the case for this data. But acknowledging that some changes in the geometry might occur (such as a change in heading of the boat) is the reason why the search interval for mutually locked data was limited to five seconds.

    Assuming that one of the receivers was in a loss-of-lock situation and that sufficient data from the past five seconds existed to generate an estimate of the current expected code-phase difference, the channel group could then make a cooperative update of the lockless tracking channel. For this channel, the channel group would replace the traditional code-tracking discriminator outputs with the offset of the expected code-phase difference dexp from the currently observed code-phase difference dcur. In the following equation, the new discriminator output is denoted as c:

    Python-Eq2. (2)

    Expressing dcur=ycur−xcur and dexp=yexp−xexp, where xcur/exp and ycur/exp represent current and expected code phases at two receivers, we can rewrite Equation 2 as

    Python-Eq3  (3)

    or

    Python-Eq4  (4)

    since we expect the x receiver to be locked, and therefore Python-Eq4-a .

    Some finer points to mention include that the “loss-of-lock” and “tracking well” designations were determined by way of the locking metric defined in the previous section. In addition, if a receiver was “tracking weakly,” it would update its code and carrier frequencies by relying solely on its own discriminator outputs. Also, because in traditional scalar tracking loss-of-lock might occur for an extended interval greater than five seconds at one receiver (such as Receiver Y’s tracking of satellite 27 seen in Figure 3 between 300,000 and 400,000 milliseconds), whenever the channel group was called to cooperatively update a lockless tracking channel’s code frequency, it would record the current code-phase difference between both receivers. Under all scenarios, the carrier-frequency update would be done independently at each channel using discriminator outputs alone. And finally, in order for both receivers to share relevant data with each other during tracking, clock bias terms found after traditional scalar tracking were used to align in time the raw data files for each receiver appropriately.

    Results and Discussion

    Using cooperative scalar tracking, drifting of the code-phase difference during code periods when one of the receivers is experiencing loss-of-lock is expected to be suppressed. And indeed, results such as those shown in FIGURE 6 verify this expectation. Since cooperative scalar tracking does not attempt to modify the way either receiver tracks during periods of good lock, this type of modified scalar tracking is not expected to produce less noisy tracking results. It is expected, however, to help lockless tracking channels to regain track after short signal outages, similar to the benefits of vector tracking.

    FIGURE 6. The code-phase difference between Receivers X and Y for PRN 27 from 300,000 to 500,000 milliseconds, this time using cooperative scalar tracking. Presence of the red line indicates code periods during which cooperative code-phase updates were made for Receiver Y. Note that noisy drifting of the code-phase difference is suppressed.
    FIGURE 6. The code-phase difference between Receivers X and Y for PRN 27 from 300,000 to 500,000 milliseconds, this time using cooperative scalar tracking. Presence of the red line indicates code periods during which cooperative code-phase updates were made for Receiver Y. Note that noisy drifting of the code-phase difference is suppressed.

    Strikingly, this form of cooperative tracking allowed for Receiver Y to continually track the signal from satellite 29 (albeit with occasional outages) for the full thirteen minutes of data shown in FIGURE 7. Whereas in Figure 3, Receiver Y very quickly loses track of satellite 29, Figure 7 shows that Receiver Y, under cooperative scalar tracking, can maintain a good enough lock on the signal that by roughly 750,000 code periods, it is able to pick up the signal again quite strongly. This change in signal strength may have been due to a slight change in heading that the ferry made near Isla Taquile towards the end of this data set (see Figure 4 and FIGURE 8).

    FIGURE 7. The in-phase prompt outputs for Receiver Y and PRN 29 using cooperative scalar tracking. Compare this to the bottom-right graph in Figure 3. Inter-receiver aiding allowed Receiver Y to track this signal for a majority of the code periods.
    FIGURE 7. The in-phase prompt outputs for Receiver Y and PRN 29 using cooperative scalar tracking. Compare this to the bottom-right graph in Figure 3. Inter-receiver aiding allowed Receiver Y to track this signal for a majority of the code periods.
    FIGURE 8. The trip back to Puno as determined by Receiver Y after cooperative scalar tracking and navigation computations. Compared to Figure 4, the navigation solutions are less noisy. Image courtesy of Google Earth and the GPS Visualizer.
    FIGURE 8. The trip back to Puno as determined by Receiver Y after cooperative scalar tracking and navigation computations. Compared to Figure 4, the navigation solutions are less noisy. Image courtesy of Google Earth and the GPS Visualizer.

    Given the locking metric defined in the section “Experiment,” quantitative measures of how often each channel spent locked or in loss-of-lock can be made. In total, both receivers tracked six common satellites (with each receiver also tracking other satellites independently). TABLE 1 shows the locking frequencies for each commonly tracked satellite.

    TABLE 1. Percent of time each tracking channel spent locked. Lock was designated if the locking metric was above 150. The best values for Receiver Y are highlighted in green, with the most notable improvement occurring for satellite 29.
    TABLE 1. Percent of time each tracking channel spent locked. Lock was designated if the locking metric was above 150. The best values for Receiver Y are highlighted in green, with the most notable improvement occurring for satellite 29.

    Granted that the drift in the code phase for lockless tracking channels is curtailed in cooperative scalar tracking, an improvement in navigation solutions is also expected. This expectation is verified by comparing the qualitative level of noise in the solutions of Figure 8 to the solutions in Figure 4. Notably, the noise in the reed thicket (the section of the route immediately after leaving the moustache-shaped floating islands region) is suppressed. Not shown are the navigation solutions for the port side receiver, Receiver X, which by comparison to Receiver Y were relatively good in both forms of scalar tracking.

    Conclusion

    The experiment we carried out highlighted the abilities of the Python Receiver. Data from two SDR front ends and associated antennas placed on either side of a small transport ferry was used to track both receivers by using groups of tracking channels that could cooperatively modify their individual channels’ code and carrier frequencies. In this way, loss-of-lock in many of the tracking channels was avoided leading to improved navigation precision. More importantly, it is expected that future experiments like these can be easily implemented within the framework of the Python Receiver, and thus topics like cooperative vector tracking might be more easily investigated.

    Acknowledgments

    This article is based, in part, on the paper “A Python Software Platform for Cooperatively Tracking Multiple GPS Receivers” presented at ION GNSS+ 2014, the 27th International Technical Meeting of the Satellite Division of The Institute of Navigation, held in Tampa, Florida, September 8–12, 2014.

    Manufacturers

    The Python Receiver uses SiGe GN3S v3 Samplers, developed by the University of Colorado and SiGe Semiconductor (acquired by Skyworks Solutions Inc., Woburn, Massachusetts) and marketed by SparkFun Electronics, Niwot, Colorado.

    ELIOT WYCOFF received his B.S. in applied mathematics from Columbia University, New York, in 2011. While working on the Python Receiver, he was a graduate student in the Department of Aerospace Engineering at the University of Illinois at Urbana-Champaign (UIUC).

    YUTING NG obtained a B.S. in electrical and computer engineering from UIUC in 2014. She is currently a graduate student in the Department of Aerospace Engineering, UIUC.

    GRACE XINGXIN GAO is an assistant professor in the Department of Aerospace Engineering, UIUC. She received her B.S. in mechanical engineering in 2001 and her M.S. in electrical engineering in 2003, both from Tsinghua University, China. She obtained her Ph.D. in electrical engineering at Stanford University in 2008. Before joining UIUC in 2012, Gao was a research associate at Stanford University.

    FURTHER READING

    • Authors’ Conference Paper

    “A Python Software Platform for Cooperatively Tracking Multiple GPS Receivers” by E. Wycoff and G.X. Gao in Proceedings of ION GNSS+ 2014, the 27th International Technical Meeting of the Satellite Division of The Institute of Navigation, Tampa, Florida, September 8–12, 2014, pp. 1417–1425.

    • Software-Defined GNSS Receivers

    Digital Satellite Navigation and Geophysics: A Practical Guide with GNSS Signal Simulator and Receiver Laboratory by I.G. Petrovski and T. Tsujii with foreword by R.B. Langley, published by Cambridge University Press, Cambridge, U.K., 2012.

    “Software GNSS Receiver: An Answer for Precise Positioning Research” by T. Pany, N. Falk, B. Riedl, T. Hartmann, G. Stangl, and C. Stöber in GPS World, Vol. 23, No. 9, September 2012, pp. 60–66.

    A Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach by K. Borre, D.M. Akos, N. Bertelsen, P. Rinder, and S.H. Jensen, published by Birkhäuser Engineering, Springer-Verlag GmbH, Heidelberg, 2007.

    “GNSS Software Defined Radio: Real Receiver or Just a Tool for Experts?” by J.-H. Won, T. Pany, and G. Hein in Inside GNSS, Vol. 1, No. 5, July–August 2006, pp. 48–56.

    “Satellite Navigation Evolution: The Software GNSS Receiver” by G. MacCougan, P.L. Normark, and C. Ståhlberg in GPS World, Vol. 16, No. 1, January 2005, pp. 48–55.

    • Python

    Learn Python in One Hour by V.R. Volkman, published by Modern Software Press, L.H. Press Inc., Ann Arbor, Michigan, 2014.

    A Primer on Scientific Programming with Python by H.P. Langtangen, published by Springer-Verlag GmbH, Heidelberg, 2009.

    “Python for Scientific Computing” by T.E. Oliphant in Computing in Science & Engineering, Vol. 9, No. 3, May–June 2007, pp. 10–20, doi: 10.1109/MCSE.2007.58.

    • Noncoherent Integration

    “GNSS Radio: A System Analysis and Algorithm Development Research Tool for PCs” by J.K. Ray, S.M. Deshpande, R.A. Nayak, and M.E. Cannon in GPS World, Vol. 17, No. 5, May 2006, pp. 51–56.

    Fundamentals of Global Positioning System Receivers: A Software Approach, 2nd edition, by J. B.-Y. Tsui, published by Wiley-Interscience, John Wiley & Sons, Inc., Hoboken, New Jersey, 2005.

    “An Assisted GPS Acquisition Method Using L2 Civil Signal in Weak Signal Environment” by D.J. Cho, C. Park, and S.J. Lee in Journal of Global Positioning Systems, Vol. 3 No. 1-2, December 2004, pp. 25–31.

    • GPS Position Display

    “GPS Visualizer: Do-It-Yourself Mapping” website by A. Schneider.

    • Square Law Detector

    “Lock Detection in Costas Loops” by A. Mileant and S. Hinedi in IEEE Transactions on Communications, Vol. 40, No. 3, March 1992, pp. 480–483, doi: 10.1109/26.135716.

  • ION GNSS+ 2014: IFEN Inc.

    Mark Wilson, IFEN Inc., demonstrates the company’s new XS3 software receiver – which succeeds the scientific GNSS software-receiver SX-NSR – at the the 2014 ION GNSS+ Conference September 9-12 in Tampa, Florida.

  • IFEN Officially Launches SX3 Software Receiver

    IFEN Officially Launches SX3 Software Receiver

    IFEN-SX3_with_chart-W Photo: IFEN
    Photo: IFEN

    IFEN has launched the SX3 receiver. The company’s previous scientific software receiver, the SX‐NSR, was subject to major upgrades, while the respective hardware front-end was completely redesigned. Together, they build the new SX3 GNSS software receiver.

    IFEN’s most important innovation of the year was introduced at the ION GNSS+ Conference September 9-12 in Tampa, Florida.

    One of the SX3’s key features is four RF frequency bands, which can be split into a maximum of eight sub-bands per unit. This enhances the bandwidth to a full 55 MHz per RF band, offering additional signal power, especially in E5 band. The new USB 3.0 port empowers a unrivaled data transfer rate that makes a maximal bit-quantization of up to 8-bit possible — for every single stream.

    The additional power is compressed into a significantly smaller and lighter hardware chassis than before. Among other options, a dual antenna-input feature can be ordered as well as an OXCO clock. (Standard equipment of the SX3 GNSS software receiver is a precise temperature-controlled oscillator.)

    The proofed difference correlator notably ruggedizes acquisition and tracking of any navigation satellite signals. Polyfit tracking reduces measurement noise through averaging (such as code/carrier measurements). (See “Innovation: Software GNSS Receiver.”) Accordingly, vector tracking improves the tracking of weak signals in degraded environments and the reacquisition of “lost” satellites.

    Just like its predecessor, it is also able to act as a framework for a customer’s own signal processing algorithms. “Customers can fully concentrate on their applications instead of dealing with potentially obscure code when using open source,” said Product Manager Bernhard Riedl. “Our professional support is specifically dedicated to scientific work as well as SX3’s capability for additional customizations. SX3 is far more than just a COTS product. This makes IFEN’s new SX3 scientific software receiver a mighty powerful tool for research and development.”

  • Rockwell Tracks Galileo Signal with Secure Software Receiver

    Rockwell Collins has successfully received and tracked a Galileo satellite signal using a prototype GNSS receiver designed for secure military use.

    In 2013, Rockwell Collins received a $2 million contract from the Air Force Research Laboratory (AFRL) and the GPS Directorate to develop and demonstrate a Secure Software Defined Radio (S-SDR) GNSS receiver capability. By using multiple available satellite signals, improved and more robust signal availability can be obtained, enabling a compatible GNSS receiver to deliver superior position determination that can improve navigation performance and signal availability.

    Hosted in a software-defined radio, the S-SDR program will develop the security architecture required for receiver equipment approvals and certifications. The arrival of modernized GPS signals and other global constellations is changing the way the U.S. military and its allies accomplish secure GNSS-based positioning, navigation and timing. The European Galileo constellation coming on line during 2015, including its open signals and secure Public Regulated Service, is expected to provide an opportunity for improved robustness in satellite based navigation, in both commercial and government applications.

    “This milestone reinforces our belief that Rockwell Collins is uniquely positioned to produce a navigation receiver that will meet global needs,” said John Borghese, vice president of the Advanced Technology Center for Rockwell Collins. “With decades of experience developing GPS systems and leading edge security architectures, our company continues to be a top innovator in this field.”

    More than 35 years ago, Rockwell Collins assisted the U.S. Air Force in developing GPS technology. That legacy continued when the company created the world’s first all-digital miniature GPS receiver under contract with DARPA. Over the years, Rockwell Collins has produced more than 50 GPS products and delivered more than 1 million GPS receivers for commercial avionics and government applications. The GNSS receiver technology being provided for the S-SDR program will continue this legacy of providing leading edge GNSS solutions.

  • Galileo Position Fix with Open Source Software Receiver Achieved

    Galileo Position Fix with Open Source Software Receiver Achieved

    First GNSS-SDR Galileo standalone position fix using the four available satellites (Position obtained at the CTTC headquarters on 2013-Nov-10 15:52:14 UTC) GNSS-SDR.
    First GNSS-SDR Galileo standalone position fix using the four available satellites (Position obtained at the CTTC headquarters on 2013-Nov-10 15:52:14 UTC).

    For the first time, position fixes in real time using signals from Galileo have been achieved with an open source software receiver. The milestone was achieved by a research team from the Statistical Inference Department at the Centre Tecnològic de Telecomunicacions de Catalunya (CTTC), which manages the development of the open source project GNSS-SDR.

    Professional, full-featured receivers are expensive, and even in those cases the users have limited access (if any) to know exactly how position and time information were computed, CTTC said. In addition, these receivers exhibit very few upgrading capabilities. A software receiver allows all kind of modifications and inspections. “GNSS-SDR unleashes the full potential of the signals and, best of all, it is open and for free,” said Carles Fernández-Prades, GNSS-SDR project manager and Head of the Communications Systems Division at CTTC.

    GNSS-SDR 2D ENU coordinates precision for the Galileo position fix.
    GNSS-SDR 2D ENU coordinates precision for the Galileo position fix.

    A GNSS software receiver is a computer program that performs all the signal processing from raw satellite signals to the computation of position, velocity and time, just as is done by the GPS chips that are embedded in smartphones and other devices with satellite-based positioning capabilities. The key difference relies on the great flexibility in the design, upgradability and the experimentation possibilities that the software version allows, in opposition to integrated circuits, true black boxes with inputs and outputs but with no accessible information about what is going on inside of them.

    “With GNSS-SDR, researchers and technology enthusiasts can easily change the implementation of a certain functional block and assess the impact of that change on the whole receiver performance,” said Pau Closas, GNSS-SDR scientific advisor and Head of the Statistical Inference Department at CTTC. “This paves the way to innovative mass-market, industrial and scientific applications that could make use of Galileo signals but require non-standard features which are not present in mass-market receivers nor in costly professional equipment.”

    The first Galileo-based positioning fix, obtained by Javier Arribas using a general purpose GNSS antenna and a RF front-end connected to a commodity PC running GNSS-SDR represents an important milestone in the research on GNSS receiver design. “Next steps will be devoted to provide outputs in standard formats that will allow the application of geodesic-grade tools for extremely precise positioning (on the order of centimeters) and higher degrees of reliability,” Arribas said.

    GNSS-SDR is the first open source solution that offers this possibility, CTTC said. The source code released under the GNU General Public License (GPL) secures practical usability, inspection, and continuous improvement by the research community, allowing the discussion based on tangible code and the analysis of results obtained with real signals. The source code is complemented by a development ecosystem, consisting of a website, as well as a revision control system, instructions for users and developers, and communication tools.

    With GNSS-SDR, researchers from CTTC (with the aid of an open community created around the project, such as the students participating in the Google Summer of Code program in 2012 and 2013 Luis Esteve, Mara Branzanti, Daniel Fehr and Marc Molina) are offering a tool that fosters the use of GPS and Galileo signals in unexpected new ways, making possible applications with unforeseen benefits in a wide range of fields, such as geodesy, robotics, unmanned vehicles and safety-related systems.