With my involvement in NRCan’s online PPP service, I get to see new trends in data submitted to our system. Until recently, dual-frequency GPS receivers could be categorized into two classes: the C1C/C2W and the C1W/C2W receivers. There is however another category of receivers that has attracted our attention lately: the ones tracking only the C1C/C2C signals.
Obtaining mm-level positioning accuracies with GNSS requires modeling of all error sources such as higher-order ionospheric effects. As a part of an IAG working group, I collaborated with European colleagues to investigate how this error source could be estimated as a part of the PPP filter. The results were published last week in GPS Solutions (Banville et al. 2017).
On June 19, Pierre Héroux officially retired from the Canadian Geodetic Survey of Natural Resources Canada (NRCan) after spending nearly 35 years with this organization. Over these years, Pierre has been a key player in the GNSS community, from testing the first commercial GPS receivers to being an early instigator of precise point positioning (PPP). Pierre kindly accepted my invitation to write a recollection of the early days of PPP and how this positioning methodology evolved within the IGS.
NRCan has been operating a zero-baseline GNSS calibration site on its premises for the past few months. The goal of this investigation is to better quantify the interoperability of different receiver/antenna types. Preliminary results obtained from this exercise were presented at the IGS workshop 2017 last week, and I thought that I would comment further on some of the Galileo results obtained.
I have recently got my hands on a copy of the Springer Handbook of Global Navigation Satellite Systems, edited by Peter Teunissen and Oliver Montenbruck. I am quite impressed with the list of contributing authors, with many experts on GNSS sharing their knowledge on a wide variety of topics contained in 41 chapters. While I encourage anyone interested in learning more about GNSS to order a copy of this book, I also want to point out an erratum related to GLONASS RTK processing.
The 2017 edition of the IGS Workshop was held in Paris from 3-7 July. I had the pleasure to attend this meeting for the first time and was quite pleased with the quality of the talks and the networking opportunities. Below is a summary of what I consider were important topics: these notes are based on my own understanding of the presentations and I encourage you to look for the original presentations for all the details once they are made available on the workshop website.
With ongoing work at NRCan aiming at offering an online PPP service supporting ambiguity resolution, we performed a validation exercise consisting of processing nearly 40 permanent GPS stations in eastern Canada over a 10-year period. As a by-product of this analysis, we computed station velocities and compared them with the values derived from the Bernese network solutions done at NRCan. The results were published last week in Survey Review and I am offering a short summary here.
It has been a few weeks since my last update on the u-blox data processing. The lack of stability of the position estimates in the single-frequency PPP (SF-PPP) solution without precise external ionospheric constraints bothered me and I spent some time thinking about possible means of improving the solution. In this blog post, I present the preliminary results of my investigation and I invite everybody with insights to share them so that we can all solve this issue.
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.