The Soft Approach
A Recipe for a Multi-System, Multi-Frequency GNSS Receiver
PC-based software GNSS receivers, which have served as powerful research tools for many years, are beginning to find applications outside the laboratory — in such areas as atmospheric modeling and synthetic aperture radar. The article describes the design of a multi-channel software receiver developed by the University of Calgary — challenges, trade-offs, results, and plans for further capabilities. A sidebar describes how the PLAN software receiver worked as a signal-monitoring tool to analyze the L5 signal broadcast by GPS satellite SVN 49.
(Downloadable PDF is 4.2 MB)
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
By May 2008 it was clear that a re-design was necessary in order to expand the receiver in a number of key ways:
A design process involving many months of discussion, testing, and re-testing led to the current receiver architecture.
. . .
A Multitude of Multiplicities
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.
. . .
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.
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.
ManufacturersThe software receiver developed by the University of Calgary PLAN is the GNSS Software Navigation Receiver (GSNRx), which has been licensed to a number of third parties. The L1-only front-end used for real-time development of the GSNRx is the SiGe GN3S Sampler available from Sparkfun <www.sparkfun.com>, Boulder, Colorado, USA. (The GN3S Sampler was co-developed by the University of Colorado Aerospace Department and SiGe Semiconductor, Ottawa, Canada, to make the software for SiGe’s SE4110L GPS front-end ASIC work with GNU/Linux. The Sampler incorporates the ANT-555 L1 patch antenna from Onshine Enterprise Company Ltd., Chung Ho City, Taipei, Taiwan. However, most of PLAN’s post-mission testing uses the NovAtel 702 GG antenna from NovAtel, Inc., Calgary, Alberta, Canada, and, for the L1/L2/L5 work, the NovAtel 704-X.) The vector signal analyzer (VSA) is the NI PXI-5661 2.7 GHz RF Vector Signal Analyzer from National Instruments, Austin, Texas, USA. The hardware simulator used to test the GSNRx is the GSS7700 from Spirent Communications, Paignton, England. The GSNRx runs on a PC computer with an Intel Core 2 Duo processor from the Intel Corporation, Santa Clara, California, USA.
Copyright © 2017 Gibbons Media & Research LLC, all rights reserved.