A Python Software Platform for Cooperatively Tracking Multiple GPS

Receivers Eliot Wycoff and Grace Xingxin Gao, University of Illinois at Urbana-Champaign

Biography

Eliot Wycoff received his B.S. in Applied Mathematics at Columbia University in the City of New York in 2011. From 2011 to 2013 he served as a software engineer at Singapore's Advanced Digital Sciences Center (ADSC) where he gained exposure to topics in computer vision. Currently he is a first year graduate student in Aerospace Engineering at the University of Illinois at Urbana-Champaign where his advisor is Professor Grace Xingxin Gao. His research focus is on Global Navigation Satellite Systems (GNSS) and cooperative positioning.

Grace Xingxin Gao is an assistant professor in the Aerospace Engineering Department at University of Illinois at Urbana-Champaign. She received her B.S. degree in Mechanical Engineering in 2001 and her M.S. degree in Electrical Engineering in 2003, both at Tsinghua University, China. She obtained her Ph.D. degree in Electrical Engineering at Stanford University in 2008. Before joining Illinois at Urbana-Champaign as an assistant professor in 2012, Prof. Gao was a research associate at Stanford University. Prof. Gao has won a number of awards, including RTCA William E. Jackson Award, Institute of Navigation Early Achievement Award, 50 GNSS Leaders to Watch by GPS World Magazine, and multiple best presentation awards at ION GNSS conferences.

Abstract

Existing software platforms are not well suited to the task of processing data from a network of GNSS receivers. Because data are expected to be shared amongst networked receivers, not only must new algorithms be designed, but new software platforms upon which these algorithms can be tested must also be built. In this work a software platform for simultaneously processing data from many GNSS receivers is designed and implemented. An object oriented design philosophy is used so that objects such as receivers, networks of receivers, and constellations of satellites are all defined as separate blocks of code with the capacity to store relevant data and perform object-specific functions. Under this coding design and with this software platform, experiments on cooperative positioning that leverage shared

data between receivers in a network can be quickly implemented. Therefore the fast prototyping of ideas in cooperative GNSS can be realized. As an example of this, a real-world experiment involving data from two SiGe Samplers was performed at Lake Titicaca in Peru in which both receivers shared tracking data to help prevent loss-of-lock during scalar tracking. Acquisition, cooperative scalar tracking, and navigation were all performed using the software platform developed in this work. For the example experiment of this project, two receivers on a moving boat maintained a fixed baseline and thus shared code phase information to prevent loss-of-lock situations due to signal loss at either receiver. Experimental results show that indeed loss-of-lock is prevented. In addition, example usages from this experiment highlight the benefits of using the Python Software Receiver over traditional software receivers.

Introduction

With billions of GPS enabled devices in use today, the potential gains from harnessing data collected over a network of GPS 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 GPS in cooperative positioning treat individual GPS receivers as “black boxes” that merely output navigation solutions [1]. As such, the wealth of information contained in each receiver's raw GPS signal 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 have gone a long way towards making the fast

prototyping of new receiver architectures possible [2]. But with regards to processing data from a receiver network, they 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, such as in [2]. 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 be sharing tracking data with every other. 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 a software defined receiver 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. And thus for this work an object oriented software platform for many receivers is designed and implemented. 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 [3]), and its ease of use. And as a reference, the Matlab software receiver in [2] was used as a basis for developing many of the core algorithms in this work.

The next section will discuss the design of the Python Software Receiver, and the following sections will provide example usages by means of a real-world experiment in which the raw signals from two SiGe GN3S v3 Samplers are tracked in unison with the purpose of improving the robustness of tracking at both receivers.

Design

Many of the core functions in the Python Software Receiver are modeled after those found in [2]. Thus, this particular implementation is suited for the raw GPS L1 signal data mixed to an intermediate frequency by the SiGe Sampler. In addition, the basic algorithms for acquisition, scalar tracking, and navigation are similar to those found in [2], with the exception that acquisition is made more robust by using multiple noncoherent integrations as done in [4]. The primary innovation of this software, however, is in the way the code is organized. For tracking multiple receivers, the

Python Software Receiver was designed under an object oriented approach.

Figure 1 to the right illustrates the main objects that a

user would be expected to use in the Python Software 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,

Figure 1 Typical Object (Class) Hierarchy

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.

For data coming from a single real-world receiver, use of the Python Software 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 PRN 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 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 geodetic system of WGS84. While it is not a key feature of the Python Software Receiver, it 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 show in Figure 1. During operation for just one

data source, the scalar tracking function defined at the receiver level will initialize enough 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.

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

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.

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 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.

Experimental

To help illustrate how the Python Software Receiver lends itself to the task of cooperatively tracking multiple receivers, concurrent data from two SiGe Samplers 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 SiGe Sampler, 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 SiGe Samplers 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 fifteen minutes as the boat returned from the floating islands of the Uros 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 ten, the signal quality at Receiver Y was generally poor. In Figure 3 below, in-phase prompt correlator outputs from traditional scalar tracking are shown for both Receivers X and Y and satellites 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.

To better characterize the tracking performance of each receiver-satellite pair, a locking metric was designed

Figure 3 The in-phase prompt correlator outputs for both receivers and satellites 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.

and implemented, the values of which are shown as the red lines in the graphs of Figure 3. Inspired by the square-law detector in [6], the metric can be expressed

𝐼!! − 𝑄!!!!!!

𝑁 (Eq. 1)

where 𝑁 is the number of most recent correlator samples, 𝐼! and 𝑄! are the 𝑖 th 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 Reciever Y in tracking many of its signals, navigation functionality in the Python Software Receiver was still able to recover enough 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 people. 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.

Cooperative Scalar Tracking

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

Figure 4 The trip back to Puno on the left (west) from the Floating Isalnds 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 [5].

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 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 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 on one or both of the SiGe samplers, was eliminated through a linear regression before plotting of the figure.

All of these observations motivated the following cooperative scalar tracking design. First, any satellite that was observed only by 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 oncoming 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 five-thousand 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 enough data in 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 𝑑!"# from the currently observed code phase difference 𝑑!"# . In the following equation, the new discriminator output is denoted as 𝑐.

𝑐 =  𝑑!"# − 𝑑!"# (Eq. 2) Expressing 𝑑!"# = 𝑦!"# − 𝑥!"# and 𝑑!"# = 𝑦!"# − 𝑥!"# where 𝑥!"#/!"# and 𝑦!"#/!"# represent code phases, current and expected, at two receivers, we can rewrite Equation 2 as

𝑐 = 𝑦!"# − 𝑥!"# − 𝑦!"# − 𝑥!"# (Eq. 3) or

𝑐 ≅ 𝑦!"# − 𝑦!"# (Eq. 4) since we expect the 𝑥 receiver to be locked, and therefore 𝑥!"# ≅ 𝑥!"#.

Some finer points to mention include that the “loss-of-lock” and “tracking well” designations were determined

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.

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 (e.g. Receiver Y for PRN 27, as 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 [7].

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 Figures 4 and 9).

Given the locking metric defined in the Experimental section, 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). The full table of locking frequencies for each commonly-tracked satellite is given below.

Receiver

Independent Scalar Tracking Lock Frequency

Cooperative Scalar Tracking Lock

Frequency X Y X Y

PRN 3 99.98% 88.76% 99.98% 88.60% PRN 6 99.83% 98.71% 99.82% 98.72% PRN 18 99.89% 91.31% 99.89% 91.61%

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 8 The in-phase prompt outputs for Receiver Y and satellite 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.

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

PRN 22 99.99% 99.96% 99.99% 99.96% PRN 27 99.73% 84.40% 99.73% 84.66% PRN 29 98.71% 02.53% 98.72% 71.62%

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 9 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

Existing software receivers are designed to mimic the processes of solitary receivers. Yet with the abundance of GPS devices in use today, interest in cooperative GNSS is growing, and the demand for research tools capable of performing experiments on networks of receivers is on the rise. Unfortunately, procedurally-coded software designed for solitary receivers is not well suited to the task of tracking

many receivers in a network. Thus for this work a Python software platform for tracking multiple receivers was designed and implemented, and it has been named the Python Software Receiver. Using an object oriented design philosophy, the code is flexible and easy to modify for

experiments involving many data sources.

To highlight these abilities, an experiment was performed on data collected on Lake Titicaca near Puno, Peru. Data from two SiGe Samplers 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 Software Receiver, and thus topics like cooperative vector tracking might be more easily investigated.

References

[1] Liu, Yunhao, and Zheng Yang. Location, localization, and localizability: location-awareness technology for wireless networks. Springer, 2011.

[2] Borre, Kai. A software-defined GPS and Galileo receiver: a single-frequency approach. Springer, 2007.

Figure 9 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 [5].

[3] Oliphant, Travis E. “Python for scientific computing.” Computing in Science & Engineering 9.3 (2007): 10-20.

[4] Cho, Deuk Jae, Chansik Park, and Sang Jeong Lee. “An assisted GPS acquisition method using L2 civil signal in weak signal environment.” Journal of Global Positioning Systems 3.1-2 (2004): 25-31.

[5] Schneider, Adam. “GPS Visualizer.” 2002. Web. 1 Feb. 2014.

[6] Mileant, Alexander, and Sami Hinedi. “Lock detection in Costas loops.” Communications, IEEE Transactions on 40.3 (1992): 480-483.

[7] Bhattacharyya, Susmita. Performance and Integrity Analysis of the Vector Tracking Architecture of GNSS Receivers, 2012.