Since August 2018, the CSRS-PPP service is supporting RINEX version 3. While this feature was necessary to keep up with modernization efforts within the GNSS community, it led to further challenges that were not an issue with RINEX 2. This blog post explains some of the issues encountered and describes how CSRS-PPP v2.31, released this week, helps in mitigating them.
Issue #1: differential code bias availability
RINEX 2 was limiting the number of code observables to two per frequency (the C and P codes) and the number of carrier-phase observables to one per frequency. RINEX 3 introduced a three-character code to better characterize the signals. For instance, code measurements on the L2 carrier can now be labelled as C2C, C2L, C2S, C2W or C2X depending on the modulation tracked and/or the technique used to track the signal.
The first issue encountered was the lack of satellite differential code bias (DCB) corrections needed to properly account for satellite hardware delays. CSRS-PPP relies on monthly averages of DCBs provided by the Center for Orbit Determination in Europe (CODE), but only the P1C1, P2C2 and P1P2 DCB file are available. For this reason, only the C1C, C1W, C2C, C2W signals were initially supported. As a result, several clients submitting files to the NRCan service did not receive a position report back, or only received a single-frequency solution, since their RINEX 3 files contained L2 code modulations that were not being supported. The quick hack to get a solution was to convert the RINEX 3 file back to RINEX 2…
CSRS-PPP v2.31 (partially) solves this problems. Since C2 observations from RINEX 2 are already supported (regardless of which modulation is actually tracked), and because it is not clear to which signals CODE’s P2C2 DCBs exactly refer to, it was decided to support all L2/C2 code modulations listed above. While this is not a rigorous solution, it will allow several additional users to obtain a solution for their data. Meanwhile, we are investigating and validating means of obtaining proper DCB corrections for all signals.
Issue #2: signal mixture
A second issue emphasized by RINEX 3 is the mixture of signals provided by users. It seems like some receiver manufacturers track different signals for different blocks of GPS satellites. For example, a RINEX 3 file can contain L2C/C2C signals for (roughly) half of the satellites and L2W/C2W for the other half. Over the past months, we have seen so many subtle variations of this issue that it was getting extremely confusing to select which signals to process.
A simple solution was to start processing all signals. Hence, if a user provided carrier-phase measurements for both L2C and L2W, both signals would be added to the PPP filter. Same thing with code observations. This strategy obviously significantly increased the size of the filter, consumed more memory and slowed down processing. Things would only be getting worse in the future with Galileo tracking several modulations on L1, L5, L6, L7 and L8…
The solution that we came up with consists of selecting one modulation per frequency, but on a satellite-per-satellite basis and on an epoch-by-epoch basis. For example, if a satellite reports L2C and L2W at an epoch, we will pick one (say, L2C). Then, if at the next epoch, L2C is not available but L2W is, L2W will be used. Same thing with code observables. This strategy implies that receiver observation-specific bias parameters must be properly set up within the PPP filter, which was implemented.
As a result of this strategy, satellites are often included earlier in the solution. If tracking of one modulation is more robust (say, L2C), it will be prioritized over other modulations that would have been selected as the default signals originally (say, L2W). Furthermore, all weird signal combinations should now be processed seamlessly.
If you have been experiencing difficulty getting your RINEX 3 files processed through CSRS-PPP, give it a second try. And if you notice further problems, please contact the Canadian Geodetic Survey helpdesk!