Galileo: First Insights

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.


Several analysis centers are already providing satellite orbit and clock products for Galileo as a part of the MGEX initiative. Selecting the right products was however not that obvious: TUM only offers satellite positions (no clocks), and CODE and Wuhan have clock corrections at a 5-min sampling interval which is not ideal for kinematic processing. The CNES product seemed like the preferred choice since they contain 30-sec clocks as well as integer phase clocks for GPS allowing for PPP-AR. However, processing data with the CNES products led to a rejection of all GLONASS code observations... this seems to indicate that the time variation of the GLONASS clocks is correct but that each satellite contains an arbitrary large offset. The last option, which I finally opted for, is the GFZ products (with prefix gbm), also containing 30-sec clocks for all GNSS.


Another thing that I noticed with the MGEX products is that several analysis centers are providing non-standard SP3 products. For example, the CODE daily orbit files also contain the first epoch of the next day. This is actually a very good idea when users only want to process a single day since only one SP3 file is required. However, when processing data that spans more than a single day, simply concatenating two SP3 files leads to issues since one time tag is repeated and the orbits from the two days do not perfectly overlap at the day boundary. Furthermore, in the GFZ SP3 files, satellite positions are provided at 5-min intervals. This turned out not to be an issue for my software, and is perhaps even preferable to a 15-min interval if one is worried about mm-level interpolation errors.


Recently, the MGEX satellite antenna phase center offsets (PCO) were added to the IGS ANTEX files. I noticed that, for the two GIOVE satellites, different values of PCO were specified for some frequencies. Even though the two GIOVE satellites were decommissioned in 2012, it is a good reminder that some software may need updating to account for such specificity. In my software for example, the PCO were simply added to the satellite position (after accounting for the satellite orientation of course), regardless of frequency. This is a valid way of proceeding for a dual-frequency solution but should be modified for a multi-frequency solution. The current ANTEX file also does not contain L5 calibrations for ground antennas, which is an issue for Galileo since the satellite clocks are based on the L1/L5 signals. For the moment, I simply applied the L2 values to the L5 signal...


The last input required for Galileo processing is the DCB file. This product is especially useful (I should say mandatory) when processing the C7 or C8 code observations to align those signals to the satellite clocks. An agency from Wuhan is now providing DCBs on a daily basis in the new (and still not officially approved) IGS bias format. Unfortunately, on 02 Jan 2016, DCBs were provided for only 4 Galileo satellites (E12, E19, E22 and E26), while the orbit/clock files contained data for 8 satellites (E11, E12, E14, E19, E22, E24, E26 and E30). Still, I tried processing the C7X and C8X signals for the 4 above-mentioned Galileo satellites by applying DCB corrections, but I obtained incompatible code residuals among satellites... While I can't entirely discard an implementation issue on my side, it would be nice to have another source of DCB corrections for comparison purposes. I believe that DLR stopped uploading their DCB products to the MGEX directory on the CDDIS servers in the second half on 2015. Hence, I couldn't successfully process all uncombined signals at this point.


Another element to consider is the eclipsing behavior of the Galileo satellites. Since the eccentricity of the satellite transmitting antenna in the X- and Y-axis in the satellite reference frame is not null, satellites in eclipse could lead to larger residuals if their actual orientation differs from their nominal orientation (even if the eccentricity was null, wind-up effects would still be observed). Since there is not a general consensus on how yawing satellites should be handled among analysis centers (this issue deserves a blog post in itself), I still need to look for papers on this topic to ensure compatibility with the satellite clock product used.


To test my initial implementation, I processed 24 hours of data from station UNB3 collected on 02 Jan 2016 following the PPP methodology in kinematic mode. Since one orbital plane of the GLONASS constellation was in eclipse on that day, yawing satellites were downweighted. I assigned the same weight to all GNSS, and obtained the following RMS errors for different GNSS configurations:

Solution Latitude (mm) Longitude (mm) Height (mm)
G 7.5 6.7  13.6
G + E 6.9 6.7 12.7
G + R 5.4 5.3 12.2
G + R + E 5.2 5.2 11.3

Since there were only between 1 and 4 Galileo satellites tracked at any given epoch, I was quite surprised to see an “improvement” when including Galileo in the solution (but it can't really be seen on a plot). Whether this improvement is significant or not does not matter much to me at this point: the fact that the solution is not worse means that we're on the right path to proper processing of Galileo data!

Write a comment

Comments: 0