(Downloadable PDF is 4.2 MB)
On the morning of April 9, 2009, researchers in the Position, Location And Navigation (PLAN) group at the University of Calgary received an e-mail from a collaborator in the United States asking for assistance in assessing the performance of the new L5 test signal.
(Downloadable PDF is 4.2 MB)
On the morning of April 9, 2009, researchers in the Position, Location And Navigation (PLAN) group at the University of Calgary received an e-mail from a collaborator in the United States asking for assistance in assessing the performance of the new L5 test signal.
The signal was due to begin transmission from GPS space vehicle number (SVN) 49 the following morning at 6 a.m. local time in Calgary. We were informed that the test signal would be transmitting the pilot component of pseudorandom noise (PRN) code 63, contrary to the L1 and L2C signals broadcast from the same satellite, which would broadcast PRN 1 signals.
At that time the finishing touches had recently been made to the latest generation of the PLAN group’s GNSS software Navigation receiver, a multi-system, multi-frequency software receiver. This receiver was already L5-capable, having been tested on signals from a hardware simulator; however, some modifications were still required to enable processing of the test signal. Within 15 minutes of receiving the SVN 49 signal specifications, the necessary modifications had been made and the receiver was ready to be tested.
Less than 24 hours later one of the authors (Dr. Borio) arrived in the PLAN laboratory, ready to begin recording the raw IF samples. Using a triple-frequency front-end and a RAID array, over one hour’s worth of synchronous, high-rate data was collected in the L1, L2, and L5 frequency bands, both before and after the 6 a.m. switch-on of the L5 signal. (See the sidebar, “A Signal Monitoring Tool,” for a discussion of the results from these observations of SVN 49, by downloading the PDF at the top of this article.)
The receiver modifications worked perfectly and all signals from SVN 49 were tracked successfully.
Although neither the L5 nor L2 signals contain any navigation message, we were still able to generate pseudorange measurements by sharing the navigation information from the L1 signal. Unfortunately, the ephemeris information provided by the satellite is unreliable and so these extra pseuodorange measurements are not used in the navigation solution.
Notably, SVN 49’s L2 carrier-to-noise (C/N0) levels are considerably lower than the L1 levels. The variation in this difference corresponding to changes in satellite elevation leads us to conclude that the variation results from three factors: 1) the difference in transmitted power (nominally 1.5 decibels), 2) the difference in receiver antenna gain pattern in the L1 and L2 frequency bands, and 3) the three-decibel loss from processing the L2CM and L2CL codes separately.
The key to the success of the L5 experiment is, in a word, design. Software receiver implementation in the PLAN group has gone through a number of design cycles since it began in 2004, with work on the latest incarnation, beginning in mid-2006.
This article will describe the objectives, design challenges, and engineering solutions that led to creation of PLAN’s GNSS software receiver. It will also discuss the features and applications of software receivers in general and the PLAN receiver in particular.
The Secret to This Success
The original version was a flexible single-frequency receiver, capable of processing GPS and Galileo signals in the L1 band using a variety of processing strategies, including standard, vector-based, and ultra-tight integration of GNSS with inertial navigation systems (INS).
By May 2008 it was clear that a re-design was necessary in order to expand the receiver in a number of key ways:
- to more easily introduce multi-frequency support
- to simplify the addition of new systems and signals
- to separate the high rate signal processing tasks to ease the integration of co-processors and thus improve efficiency.
A design process involving many months of discussion, testing, and re-testing led to the current receiver architecture.
. . .
A Multitude of Multiplicities
We are entering a golden age in GNSS research. With multiple GNSS systems, each transmitting multiple signals on multiple frequencies, the opportunities for research and development are manifold. As has been well documented elsewhere, software receivers provide an excellent platform for exploiting these opportunities. However, we believe that the structured approach undertaken by the PLAN group represents a distinct way forward in receiver development.
The L5 anecdote related at the start of this article reveals one advantage of the structured approach: adaptability. We have found this structure to be incredibly useful on numerous occasions. For example, in late March 2009 we decided to add GLONASS capability to the PLAN receiver. With only a few hours (about three) of design and programming, the ability to acquire and track GLONASS C/A signals on both L1 and L2 had been added to the receiver.
The addition of navigation message decoding and satellite trajectory calculations required some additional work (not least of which was deciphering the GLONASS interface control document, or ICD). Nonetheless, the generic structure of the receiver meant that no receiver level modifications were required.
. . .
Challenges
The software receiver structure described here yields many benefits. However, a number of challenges associated with the software receiver approach remain. Primary amongst these is the issue of data throughput.
As with any design process, many trade-offs have been made in developing the PLAN receiver. In particular, receiver designers commonly expect that flexibility comes at the cost of speed. Indeed, the use of an object-oriented approach is often advised against on the grounds that it is inherently less efficient than a purely procedural approach.
In the face of this expectation, one of our primary goals while designing the receiver was to enable more efficient computation of the high-rate processes in the receiver, while maintaining a high degree of flexibility and adaptability. The identification of the processing manager object referred to earlier was the key to achieving this goal.
In our experience, much greater computational efficiencies can be achieved by bringing all the high-rate computations together, such that all the information required to perform the Doppler removal and correlation operations for all signals is available in one object at the same time. This structure has the added advantage of enabling the integration of co-processors, such as field programmable gate arrays (FPGAs) and graphics processing units (GPUs) with relative ease.
A clear demonstration of the ability of the PLAN software receiver to handle large computational burdens in an efficient manner appeared in late March of this year, when the software was successfully interfaced to a commercially available, 12-channel portable (being in a USB flash drive form factor), L1-only front-end. This front-end has a sampling rate of slightly greater than 16 Msps and an IF bandwidth of approximately four megahertz.
Running on a laptop PC with two gigabytes of RAM and dual-processors, the PLAN receiver is capable of acquiring, tracking, and navigating in real time, using up to 12 channels simultaneously. Note that this includes both GPS and Galileo/GIOVE constellations. This real-time receiver uses only the CPU cores on the PC and does not take advantage of any GPU co-processors that may be present.
The remaining key challenge in GNSS software receiver design is the availability of hardware for down-converting and digitizing the variety of RF spectral bands that are now of interest to GNSS researchers. The commercially available L1 front-end is one of only a handful of complete designs available on the market at present that easily interface with PC hardware.
Very few currently offer more than single-frequency operation, and none that we are aware of currently offer the flexibility to acquire signals from all bands of interest.
At present, the PLAN group uses a high-fidelity vector signal analyzer (VSA) in conjunction with a RAID array to acquire high rate, synchronous multi-frequency data on up to three frequency bands at a time.
Summary
The modular design adapted for PLAN’s software receiver greatly facilitates research in many areas of GNSS signal and navigation processing. The ability to quickly add new signals, new systems, and new signal processing techniques was a fundamental goal of the design process, and the success of this approach has been demonstrated through a number of examples.
A common misconception suggests that a software receiver designed entirely in C++ would be too cumbersome and slow to operate in real time. On the contrary, the PLAN receiver can operate in real-time with up to 12 channels at sampling rates of over 16 Msps.
Much research and development work remains to be done, even within the constraints of the software receiver, and certainly a whole world of possibility exists beyond this specific definition. Signal quality monitoring, high-sensitivity operation, atmospheric modeling, and synthetic aperture radar applications are only a few of the potential further uses of the software receiver.
We also recently commenced development of a graphical user interface (GUI) to replace the current console interface. Although this development does not contribute directly to the research goals of the PLAN group, the ability to visualize receiver data at run-time can be very useful for quick identification of interesting phenomena, such as RF interference.
For the complete story, including figures, graphs, and images, please download the PDF of the article, above.
Additional Resources
[1] Capua, R. and M. Antonini (2008), “A Soft Touch: Sogei’s GPS/Galileo Software Receiver and Institutional GNSS Applications in Italy”, Inside GNSS, Fall 2008, pp. 33-39
[2] Petovello, M. G., and C. O’Driscoll, G. Lachapelle, D. Borio and H. Murtaza (2008), “Architecture and Benefits of an Advanced GNSS Software Receiver,” Journal of Global Positioning Systems, vol. 7, no. 2, pp. 156-168.
[3] Won, J.-H., and T. Pany and G. W. Hein, “GNSS Software Defined Radio: Real Receiver or Just a Tool for Experts?”, Inside GNSS, July/August 2006, pp. 48-56
