Your behavior appears to be a little unusual. Please verify that you are not a bot.


Survey Perspectives – Late July 2008

July 16, 2008  - By

Software Receivers May Hold the Key to Multi GNSS

It’s not often that I read a technical paper that really catches my attention to the point that I read and reread it, then write the authors to probe further. That happened to me last week.

I’m on the IGS (International GNSS Service, formerly International GPS Service) email distribution list. IGS is a consortium of 200 world-wide agencies that combine resources and share GPS/GLONASS data in order to generate precise GPS and GLONASS products. According to the IGS website, you can think of the organization as the highest precision international civilian GPS community.


The IGS GNSS Tracking Network

If you’re signed up, IGS will occasionally send out informative emails about current GNSS events. To subscribe to IGSMAIL send an email to majordomo@igscb.jpl.nasa.gov with a line in the body following this format (substituting your own email address):
subscribe igsmail you@your.email.address.

Last week, I received IGSMAIL-5791. It was a notice that a paper was posted from the IGS 2008 Workshop held in Miami, Florida last month. The paper was entitled Considerations for Future IGS Receivers. It was authored by Todd Humphreys of Cornell University, Larry Young at NASA’s Jet Propulsion Lab (JPL), and Thomas Pany with University FAF Munich, Germany.

It’s a great paper to read if you are interested in the future of high-precision GNSS receivers. It touches on a lot of the subjects (GPS modernization, Galileo, GLONASS, etc.) that I’ve been writing about for awhile and also an interesting subject that I haven’t written about: GNSS software receivers.

IGS is interested in being the gold standard of GNSS data: orbits, clocks, reference frame positions, and ionosphere/troposphere maps. A noble goal for sure, but most of the commercial GNSS applications don’t require the sort of accuracy the IGS is chasing after. Nonetheless, the paper discusses many of the issues that face the commercial GNSS industry, and even takes into account the very recent proposal by the Department of Defense to cease support of L1/L2 P(Y) semicodeless. Also, IGS isn’t heavily involved in real-time kinematic (RTK) applications, which have become very prevalent in the commercial GNSS industry.

After reading the paper, I formulated a few questions and sent them to the authors. They promptly answered and I thought it would be insightful to include them in this column.

Eric Gakstatter (EG): You touch on GLONASS and Galileo a bit, but don’t delve into current constellations, launch schedules, etc. This leads the reader to believe that you value GPS modernization over an increased number of observables from other GNSS (GLONASS, Galileo). Is that a correct assumption? The “more signals from the same number of space vehicles (SVs) vs. today’s signals on more SVs” debate is a hot one right now. Which do you value more?

Larry Young: (LY) More satellites with at least two-frequency signals definitely trumps more signals per satellite. For ground uses I believe the limited number of satellites currently reduces our ability to estimate, for example, a spacially and temporally varying tropospheric delay.

We concentrated on GPS because:

  1. We have excluded the current FDMA GLONASS signals as less accurate for high-accuracy science applications, but look forward to including possible future CDMA signals from GLONASS.
  2. We expect the Galileo signals will be very useful, but there are as of yet only two prototype Galileo satellites in orbit. Actually, we went to some length to describe benefits from the Galileo signal structure. I think any launch schedule for Galileo is even less certain than the schedule for GPS replenishment.

 

(Editor’s Note: Larry’s reference to FDMA GLONASS accuracy (the current GLONASS architecture) doesn’t mean that GPS/GLONASS receivers sold today are less accurate than GPS-only receivers sold today for real-time kindematic RTK/machine control applications. Companies that design GPS/GLONASS receivers have developed methods to mitigate the internal biases that exist in the GLONASS broadcast signals.)

EG: How did you determine 16 as the minimum requirement for the number of L2C SVs in orbit?

Todd Humphreys (TH): We tried to temper the pressure to modernize the IGS network with an understanding that the IGS is a volunteer federation with enormous inertia, and so can’t be expected to respond to drastic requirements upheavals. The presence of 16 L2C-capable SVs (which implies 8 L5-capable SVs) on orbit is what triggers Event 2 in the minimum requirements schedule. The primary changes brought on by Event 2 are:

  1. newly incorporated IGS receivers must be L5-capable
  2. newly incorporated receivers are no longer required to track L2 P(Y).

Change 1. keeps the IGS current by beginning to measure and characterize the L5 signal. Change 2. is meant to begin the inevitable conversion to a network that does not use P(Y)-code tracking. Change 2. also reduces the barrier to entry into the IGS network. By not requiring L2 P(Y) tracking, we open the IGS network to receivers without semicodeless tracking capability, such as some software receivers. It’s also a recognition that commercial receivers capable of P(Y) tracking will likely be more rare and more expensive after Event 2, given that semicodeless P(Y) tracking is slated for obsolescence.

EG: Given the intention of the U.S. Department of Defense (DoD) regarding semicodeless access, do you think it will halt all development of GNSS software receivers in that area, and that they will focus purely on L1 C/A, L2C and L5 (and L1C)?

TH: The paper mentions that software receiver developers are not as keen on codeless/semicodeless techniques as they are on standard coded tracking for two reasons:

  1. Software receiver designers want to get the most performance they can from their limited computational resources and so it makes sense to concentrate on coded tracking.
  2. The restrictions on use of proprietary codeless/semicodeless tracking techniques makes these techniques less attractive than standard coded tracking.

Add to this that the DoD plans to discontinue semicodeless access by around 2020, and you can see why semicodeless tracking hasn’t been on the forefront of most software receiver developers’ minds.

On the other hand, the IGS minimum receiver requirements schedule proposed in the paper would require semicodeless-capable receivers until 8 IIF SVs are in orbit (making a total of 16 L2C-capable SVs on orbit). Hence, if software receiver developers want to see their products used as stand-alone receivers in the IGS before then, they’ll have to provide semicodeless tracking.

Thomas Pany (TP): Semicodeless access is an interesting topic on its own and software receiver research will continue on it (at UniFAF we got funding for it).

LY: JPL needs to track P-codes in its software receiver in order to get the best accuracy for surface-reflection experiments. When this is done with post-processing, we are able – and others should be able – to obtain the actual Y-code chip sequences that had been used. We also implement semi-codeless processing into software receivers. Sometimes it’s just handy to have both the L2C and P2 signals, for example, to investigate effects of long-delay multipath.

What is a GNSS software receiver?

I think a real interesting part of this paper, and one I haven’t touched on yet, is the discussion of software GNSS receivers. A friend of mine has been putting the software receiver bug in my ear for some time. I’ve been dismissing it for the most part because he and I have been speaking in terms of the consumer GPS market. I hadn’t really thought of it with respect to the market for high precision commercial GNSS receivers, especially those that are in fixed installations like CORS.

First of all, one of the reasons today’s complex GNSS receivers are so small is because there is a high level of electronics integration. What that means is that engineers design many different processing functions into one or two custom integrated chips. These chips are called application specific integrated circuits (ASICs). Using ASICs help reduce the size, cost and power consumption of complex electronic products such as GNSS receivers.


The Cornell University GRID GNSS software receiver based on DSP technology.

But an ASIC is not required to build a GNSS receiver. Granted, without an ASIC or two it might be larger and more power hungry, but you can build one nonetheless. A GNSS software receiver doesn’t mean you get a GNSS receiver delivered on a $2 DVD either. No sir, there are still plenty of electronic components involved. The core difference is that instead of one or two ASICs, there would be a series of off-the-shelf discrete components. There are essentially two different approaches in designing a GNSS software receiver; one uses a digital signal processor (DSP) and the other uses a field programmable gate array (FPGA). Sometimes both a DSP and FPGA are used in a design. The GNSS software is loaded in the DSP and/or FPGA and this is how the GNSS software receiver gets its name.

Essentially, a GNSS software receiver is a design where all signal processing that comes after the analog radio frequency front-end is completely software re-configurable.

Why use a GNSS software receiver?

Higher power consumption, larger size and higher chip count doesn’t seem like a good argument in favor of GNSS software receivers. So what is? I posed that question to the paper’s authors.

EG: What is the major attraction of GNSS software receivers? Cost? Flexibility?

TH: From the point of view of the IGS, the major attractions are flexibility and transparency. The IGS’s goal is to deliver gold standard GNSS orbits, clocks, reference frame positions (and thereby contribute to gold standard Earth orientation parameters), and iono/tropo maps. For this, we need transparency into receiver operation so that we can better model the statistics of the receiver products that we use. Better yet, we’d like to implement our own specialized tracking loops and other specialized receiver features. Software receivers offer us this transparency and flexibility.

Although it probably takes a back seat to transparency and flexibility, price is certainly an attraction. For example, the ASTRA software receiver mentioned in the paper is planned to be offered for around $1,200 (hardware) plus $200 or so per receiver for a software maintenance contract. This is about 10 times less expensive than the traditional receivers that the IGS buys. If ASTRA and others can really deliver at such reduced prices, you may see an exciting densification of IGS sub-networks for tropospheric and ionospheric study.

EG: Do you think there is a strong possibility that GNSS software receivers are technically able to replace traditional GNSS receivers in fixed GNSS infrastructure environments (eg. CORS, IGS, JPL, SoPAC, etc.)?

TH: Absolutely. The JPL BlackJack receiver is arguably the best-performing GPS receiver on the planet today, and it’s essentially a software receiver with an FPGA-based correlation engine (see the Montenbruck reference in the paper for a comparison of the BlackJack against other receivers). I suspect that the reference-frame receivers sold by some traditional vendors are, in fact, software receivers in the mold of the BlackJack. I predict a market-wide convergence toward FPGA/DSP-based software GNSS receivers over the next decade as the FPGS/DSP price per transistor count continues to fall.

The real question is what kind of access the IGS will have to the software of these receivers. The traditional model is that the IGS has no control over their receiver’s software aside from setting a few parameters and downloading the occasional vendor-provided firmware update. Suppose vendors instead license their source code to the IGS, or provide “plug-ins” for IGS-specific routines. Such transparency and flexibility is just what the IGS needs to carry out its demanding mission.

EG (following-up on Humphreys’ comment on a market-wide convergence toward GNSS software receivers over the next decade): If a vendor can sustain its business by licensing their source code, then it will happen. The alternative is a Linux-type approach where the development is a shared effort. The commercial demand will be great enough that I think one of these models will materialize.

TP: If an open-source software receiver emerges in the near future, it has to overcome the following difficulties, which are not easy to solve (at least this is our experience at the University FAF Munich).

  1. The front-end development has to be done and drivers have to be developed.
  2. The software requires assembler programming skills including multi-threading.
  3. The software needs to have a high stability to run 24 hours per day with basically no failure. This all applies for FPGA, DSP or general-purpose based receivers, and are eventually most easily solved on the general-purpose processor.
  4. Last but not least, you have to implement competitive signal processing algorithms to achieve results similar to commercial receivers. So if one succeeds with all this stuff, it’s questionable, if the software will be free of charge.

EG: I guess network RTK users would see some upside (to a densified reference station infrastructure)? How about static post-processing users? Maybe longer baselines?

TH: Accurate estimates of SV clocks and orbits don’t depend strongly on dense networks. By extension, network RTK users or static post-processing users won’t see marked improvement just because the surrounding network is denser. What improvements come from denser networks will be due to a better characterization of the troposphere and its gradients. Such improvements will indeed allow longer baseline carrier-phase-differential techniques. One could imagine a dense regional network making possible carrier-phase-differential techniques with millimeter-level accuracy on baselines of up to 100 km. Whether this will be of great commercial interest, I can’t say. As a researcher, I’m interested!

If the user has a single-frequency receiver, then dense networks help to mitigate both ionospheric and tropospheric errors in his RTK or static-post-processing solution.  If the user has a dual-frequency receiver, then he won’t see much reduction in his ionospheric errors, but will still benefit from reduced tropospheric errors.

EG: Can you tell me a little bit about the computing platform required for a GNSS L1/L2/L5 receiver?

TP: I strongly believe that a modern standard PC (four cores) has all the required processing power to do all-in-view L2P(Y) tracking at least with cross-correlation in addition to track the civil signals on L1/L2, but to which extent the computational resources can be exploited strongly depends on the developers’ capabilities. It’s my experience that PhD candidates who typically have a background in geodesy or communications are normally not experts in assembler language. For this type of work an experienced game programmer would eventually be more qualified.

TH: Right now, a full L1/L2/L5 receiver requires either a multiple-core approach (see the description of the University FAF Munich receiver in the paper) or an FPGA. The wide bandwidth L5 signal drives this requirement. Tracking L5 requires 10 times more computational power than narrow-band tracking of L1 and L2C.

EG: Do you have a schedule in place to perform the testing described in item 6. A. (from the paper)? Compare the performance of a software GNSS receiver with a traditional ASIC-based receiver?

TP: A University FAF Munich software receiver will be installed at a EUREF site in Germany in September or October this year. I expect that the data will be available to IGS.

TH: A dual-frequency version of the Cornell GRID receiver will be tested against traditional dual-frequency receivers in November of this year. It will be deployed to Brazil for ionospheric scintillation study in December of this year.

Imagine All the Signals, Living in Harmony

Imagine if you had a GNSS software receiver and a new signal such as L5 comes online. You wouldn’t need to change your receiver hardware (except the antenna), no boxes to unpack, no new hardware to figure out, only load new GNSS processing software into the DSP/FPGA.

But I think low cost, rather than flexibility; might drive the GNSS software receiver into the commercial markets eventually. Not necessarily on the user equipment side of things such as machine control or portable applications, but rather on the infrastructure side of the business, such as CORS and other regional as well as world-wide networks where power and size can be traded for cost. Like Humphreys said, being 1/10th the cost of traditional GNSS receivers makes it feasible to create very dense networks of reference stations.

This article is tagged with and posted in Opinions, Survey