It is only a matter of time before our smartphones can provide cm-level positioning accuracies. Thanks to the Centre National d’Études Spatiales (CNES, the French Space Agency) and its contractor CS, a giant step forward has been made towards the accomplishment of this goal with the release of two new Android apps on the Google Play store. This blog post features an invited contributor from CNES, Denis Laurichesse, who presents initial positioning results obtained using these apps.
Since my work is mainly focused on improving the accuracy of GNSS processing algorithms, I do not always spend the time required to optimize the code I am writing. Every now and then, I make a few adjustments to the code structure to avoid common pitfalls like excessive memory allocation which is particularly time consuming. I did such an exercise last week and thought I would share the process in case someone else wishes to shave a few seconds off their software processing time.
As promised, I took my new u-blox NEO-M8T outside. My first test simply consisted of evaluating the data quality of the carrier-phase and code measurements collected with a 20$ patch antenna. To achieve this, I have simply put the antenna on the roof of my car and parked on the street for 45 minutes. Results show that a cm-level precision is definitely achievable in a pseudo-kinematic mode using the PPP-RTK processing scheme, although code measurements contaminated with multipath significantly impacted the solution when no precise ionospheric information was provided to the filter.
Archives like CDDIS and SOPAC are great resources for accessing data from permanent GNSS stations using dual- or triple-frequency receivers. There is however a lack of publicly available single-frequency data sets to improve the development of processing algorithms aimed at low-cost receivers. For this reason, I decided to buy myself a little “toy” to collect my own data and, hopefully, get enough insights to benefit the precision, accuracy and integrity of these devices.
Processing of GLONASS data has always been more complex than GPS due to frequency division multiple access (FDMA). As a consequence of inter-frequency code biases, satellite clock corrections from different analysis centers are often offset by a few nanoseconds. Since accounting for such offsets is not really problematic, why has the IGS never produced a GLONASS clock combination? From personal experience, I think that I know the answer to this question and I agree with the IGS decision. However, authors of a paper published this week seem to think otherwise. Who’s right?
For almost two years now, I have been extracting precise slant ionospheric delays from over 200 permanent GNSS stations in Canada using PPP-AR. Since there is no official data format for storing GNSS-derived slant ionospheric delays, I have developed by trial and error a format that is at least suitable for my own purposes. Since precise ionospheric delays are key to fast PPP convergence, we can certainly foresee a need for exchanging this kind of information in the future. For this reason, I thought it could be useful to share this format and possibly get feedback from the GNSS community.
A couple of months ago, researchers from Wuhan University published a paper entitled “A review on the inter-frequency biases of GLONASS carrier-phase data,” aiming at clarifying distinctions between inter-frequency phase biases (IFPBs) and differential code-phase biases (DCPBs). While the paper offers good descriptions and a detailed analysis, I thought I might share a few additional insights.
As a kid, there were stories I liked to hear over and over again. I guess it's not all that different as an adult: the story of how GPS came together is always an entertaining read. In “Pinpoint: How GPS is changing technology, culture, and our minds”, author Greg Milner gives this story a new spin, with a novel-like narrative and an extended list of familiar characters. Overall, a very interesting read that every geodesist deserves under its Christmas tree!
Precise Point Positioning (PPP) uses precise satellite orbit and clock corrections from global navigation satellite systems (GNSS) to provide users with accurate positioning capabilities with respect to a global reference frame. In recent years, some International GNSS Service (IGS) analysis centers (ACs) also started providing satellite clock correction sets that preserve the integer nature of carrier-phase ambiguities. Even though these “integer clocks” allow for a more rapid convergence of PPP solutions and improved stability of the position estimates, their integer properties are currently neglected in the IGS clock combination. For this reason, recent efforts at NRCan have focused on generating a satellite clock combination product allowing for PPP with ambiguity resolution.
Hardware delays, or biases, affect GNSS carrier-phase and code measurements and must be properly accounted for in high-accuracy positioning. Several models were proposed to handle biases in precise point positioning with ambiguity resolution (PPP-AR), all of which can be cast in an uncombined representation. In this post, I explain the unified processing scheme that I am using in my software to deal with common PPP-AR products.
The Variometric Approach for Displacement Analysis Standalone Engine (VADASE) uses time-differenced carrier-phase measurements to estimate station velocity with mm-level accuracy using only broadcast satellite orbit and clock corrections. These velocity estimates are then integrated to derive station displacements at the centimeter level over short time intervals. These characteristics are well suited for earthquake monitoring since the method does not rely on external communication channels which are often among the first components to fail during an earthquake. But how does VADASE compare to a PPP solution?
During Google’s I/O 2016 conference held in May 2016, Google announced that raw GNSS measurements from smartphones running the Android N operating system would be made available to developers. Following this announcement, I registered to a tutorial held last week at the ION GNSS+ 2016 meeting entitled “Raw GNSS Measurements from Android Phones,” given by Frank van Diggelen and colleagues from Google. Since I am a precision junkie, there is a question I needed to answer: can we do cm-level positioning with a smartphone?
The ION GNSS+ 2016 meeting took place last week, from September 12-16, in Portland OR. Here are the highlights of this meeting from a PPP perspective.
It is common practice to constrain the tropospheric zenith delay (TZD) parameter in a PPP solution. Depending on the quality of the temperature, pressure and relative humidity input data, I typically apply a constraint on the initial TZD value with a standard deviation between 5 and 20 cm. I never gave this pseudo-observation much attention until a problematic data set made me revisit this concept.
Back in April, I discussed how applying L5 phase-bias corrections allowed for triple-frequency ambiguity resolution in PPP solutions. I demonstrated how the third frequency could potentially improve convergence times, but did not put too much focus on the estimated L5 biases. In this post, we examine the intra-day time variation of the L5 biases for the 12 block IIF satellites in orbit.
With the integration of GPS receivers in smartphones and in car navigation units, there are now millions of GPS users worldwide. Unfortunately, very few of them appreciate how GPS came together and how it provides user positions. With the aim of educating mass-market users, Dr. Pratap Misra wrote a new book entitled “GPS for Everyone: You are Here.”
It is well known that the 'leveling' process, in which carrier phases are fitting to code observations, is a source of error in the determination slant total electron content (STEC). These leveling errors can be greatly attenuated when using carrier-phase ambiguities obtained from PPP as leveling information. In this post, I show how leveling errors can also impact VTEC and, potentially, DCB estimates.
The extension of network RTK to larger networks is facilitated by a state-space representation of error sources, and is often associated with the term PPP-RTK. By adding atmospheric (troposphere and ionosphere) corrections to satellite orbit and clock corrections, it is possible to obtain fast convergence and seamless transition from a network RTK to a PPP solution. While this concept has been introduced nearly 15 years ago, there are still very few providers of PPP-RTK services at a global scale. Is this about to change?
It is now well-understood that a misalignment between carrier and code measurements within a GNSS receiver causes an apparent inter-frequency bias in GLONASS carrier-phase observations. Receiver-dependent calibration values are typically used to reduce this error source and a constrained parameter can be added to the filter to account for residual effects. A few years ago, I proposed an alternative which consists of using two reference satellites with adjacent frequency channel numbers to explicitly estimate inter-frequency phase biases. In this post, I share a few additional insights on this approach which were not included in the original paper.
I have had enough with the peer-review process, both as a reviewer and as an author. If you Google “alternatives to peer review,” you will see that I am not alone. There were many ideas proposed and even implemented to mitigate the pitfalls of this outdated approach. My goal here is not to analyze these methods, but only to rant about my experience with peer-review ineffectiveness in the world of GNSS.
The L5 signals transmitted by the block IIF GPS satellites caught the IGS by surprise. The time-varying inter-frequency phase bias that exists between L1/L2 and L5, also called “line bias”, is significant enough that it requires dissemination to users. Besides the lack of an adequate format, I believe that this initiative has been delayed because the benefits of a third frequency on float PPP are not substantial. To realize the benefits of L5, the IGS needs to embrace PPP with ambiguity resolution.
The term “PPP-RTK” usually involves positioning using state-space corrections generated from a network of GNSS receivers. This flexible representation of error sources allows for a scalable solution to be deployed: a global PPP solution can be obtained with precise satellite orbit and clock corrections, and instantaneous convergence can also be obtained by providing local atmospheric augmentation. In this post, I apply this concept to achieve single-frequency PPP with ambiguity resolution (AR).
After implementing Galileo processing capabilities in my PPP software, the next step towards GNSS modernization was the inclusion of BeiDou satellites. The active constellation of BeiDou-2 satellites currently consists of 6 geostationary (GEO), 5 inclined geosynchronous orbit (IGSO) and 4 medium earth orbit (MEO) satellites. Until 2020, when 27 MEO satellites should be in orbit, BeiDou will be more of a regional system covering mainly Asia and Australia. While the implementation of Galileo was rather straightforward, including BeiDou turned out to be more of a challenge.
GLONASS ambiguity resolution in PPP is a challenge, mainly due to the presence of inter-frequency code biases. Variations associated with antenna type, receiver type and receiver firmware have been observed, making calibration a difficult undertaking. The are thus two common ways of fixing GLONASS ambiguities in PPP: 1) have a dense network of reference stations to accurately measure between-station slant ionospheric delays; and 2) use a network of stations with homogeneous equipment (i.e., same antenna, receiver and firmware). However, when using IGS stations to estimate satellite clock corrections, none of these two methods can be successfully applied on a global level. Fortunately, there is another solution.
With 12 Galileo satellites in orbit, it is about time to jump on the bandwagon and check how those signals can be integrated in a PPP solution. In this post, I focus on the main inputs required for a proper Galileo implementation and show results of my first triple-GNSS processing.
Traditional surveying involved distance and angle measurements from a network of geodetic markers with known coordinates. Even single-baseline differential GNSS relied heavily on such a network of reference points. With recent advances in GNSS processing, ground markers are effectively being replaced by precise satellite orbits, enabling positioning methodologies such as precise point positioning (PPP). Therefore, investments made by geodetic agencies to maintain and densify classical geodetic networks have been considerably reduced, even though users still rely on such markers for their day-to-day operations. This post proposes to tap into existing infrastructures as an alternative to geodetic markers.
Processing of GNSS data collected on an airplane requires special handling of the troposphere. Due to large variations in altitude, the a priori hydrostatic and wet delays must be regularly updated since the tropospheric zenith delay (TZD) process noise would not allow proper tracking of those variations. However, the temperature and pressure reduction schemes employed in GPT2 do not seem well suited for this purpose, as demonstrated herein using data from the NGS kinematic challenge.
Processing of GNSS data requires proper handling of measurement biases originating from delays within the satellites and receivers. This is especially true for PPP with ambiguity resolution (PPP-AR) which relies heavily on code (pseudorange) observations. The objectives of the IGS Workshop on GNSS Biases 2015, held on November 5-6 in Bern, Switzerland, were therefore to better characterize GNSS biases, describe ways of handling such biases and define standard formats to exchange bias information.
In precise point positioning (PPP) solutions, the wet part of the tropospheric zenith delay (TZD) is usually estimated along with position and receiver clock parameters. The residual TZD effect varies over time, but the magnitude of its variation is predictable to some extent. For this reason, process noise is added to the TZD variance at each epoch. But how should the process noise value be selected?
The precision associated with position estimates obtained from GNSS processing software is often too optimistic. The culprit is an improper definition of the stochastic model, neglecting time-correlated errors such as multipath or satellite orbit and clock errors. In situations where single-epoch ambiguity resolution is not possible, such as PPP or long-baseline RTK, time correlation can become a serious concern for ambiguity validation.
Global navigation satellite systems (GNSS) play a significant role in geodynamic applications. Even though tectonic motions are in the order of a few millimeters to centimeters per year, the accuracy of high-end GNSS equipment is well suited to detect such displacements. The magnitude and direction of GNSS station displacements following an earthquake can also provide valuable information on the type of crustal movements encountered which can, in some instances, be used as a component of a tsunami-warning system. In this post, I take a look at data collected at a GNSS station affected by the magnitude 7.8 earthquake that occurred on 25 April 2015 in Nepal.
The main challenge with single-frequency PPP is to mitigate ionospheric effects. Global ionospheric maps (GIM) can reduce the contribution of this error source to some extent but residual errors often lead to meter-level positioning accuracies. A popular option is to use the GRAPHIC combination, an average of code and phase observations that “eliminates” ionospheric errors. This formulation is, however, not always your best option.
Ambiguity resolution and validation are perhaps the most popular GNSS-related research topics. A plethora of methods were developed for this purpose such as the popular ratio test, the difference test, the projector test, the W-test, etc. However, the techniques that worked for short-baseline RTK don’t perform as well for long-baseline RTK or PPP.
When computing post-processed PPP solutions, I typically had to pick one of the two following options: a GPS-only solution with ambiguity resolution (only available from CNES) or a GPS + GLONASS solution with float ambiguities (available from several other analysis centers). This dilemma ended last week, with CNES also offering satellite clock corrections at 30-sec intervals for GLONASS and Galileo. This product is provided as a part of the MGEX project, but the GPS/GLONASS part will soon become the standard GRG product.
The Least-squares AMBiguity Decorrelation Adjustment (LAMBDA) method [Teunissen, 1993] is an essential tool in my software. Prior to LAMBDA, finding the “best” integer ambiguity vector was a very computationally-intensive process. The decorrelation procedure of LAMBDA allows for an efficient search to be performed and has become widely accepted in the GNSS community. A faster search process does not however mean a shorter time to resolve ambiguities...
There are a lot of papers written about “optimal” linear combinations of observations, some of which are excellent, such as the work by Cocard et al. . The optimality of linear combinations can be defined based on several criteria such as noise reduction, ionospheric delay reduction, or wavelength amplification. This quest for optimality has however obscured what I believe is the true benefit of linear combinations: reducing the number of parameters to be estimated. It is unfortunately a widespread belief that the use of linear combinations can reduce errors in the observations and lead to better positioning results or faster ambiguity resolution than uncombined signals.