# Investigation on Reference Frames and Time Systems in Multi-GNSS
## 1 Introduction  
As part of the contribution of the University of Padova to the MGEX program [1] and to the activities of the MultiGNSS Working Group within [2], 31 European GNSS sites have been monitored since 2014 with five different receivers (Javad, Leica, Septentrio, Topcon, Trimble). The location of the sites is shown in Figure 1 and the equipment at each site is described in Table 1. Three issues which are critical for the interoperability of the different GNSS constellations are considered from the user point of view:  
* Alignment of the spatial reference frame implied by the broadcast orbits to a common frame aligned to ITRF (International Terrestrial Reference Frame), such as the one implied by the preciseephemeris of CODE (Center for Orbit Determination in Europe) at the University of Bern. * Offset among the time scales of different GNSS constellations: are the reference time scale of the various GNSSs synchronized among each other? * Do different receivers measure different offsets? Does the receiver dependent offset change subject e.g., to a firmware update? GPS, GLONASS, Galileo and BeiDou are the systems taken into account. For some receivers at higher latitude (e.g., KIRU, Kiruna, Sweden; WROC, Wroclaw, Poland; NYA2, Ny Alesund, Svalbard; DLF1, Delft, The Netherlands; GANP, Ganovce, Slovak Republic) QZSS data are also available. A Septentrio receiver has also delivered data from the Indian NAVIC (formerly IRNSS) constellation. SBAS data are received from satellites S27 and S28, both belonging to the Indian overlay system GAGAN (GPS Aided Geo Augmented Navigation) in geostationary orbits. No data usable for positioning are available from other SBAS systems. This paper is organized in two parts. In the first part, the offset between broadcast reference frames and ITRF has been evaluated, together with a comparison between broadcast and precise orbits and clocks. This part is described in Section 2. The second part of the paper focuses on the misalignment of the time scales adopted by GNSSs, and is described in Sections 3 and 4. [PERSON] et al. [3] have carried out a similar analysis for the whole of 2013. In their study, they evaluate the signal-in-space ranging error (SISRE), which describes the error contributions due to broadcast orbits and clocks. They found that the GPS broadcast ephemerides show the best accuracy, with a RMS (Root Mean Square) orbit error of 0.18, 1.05 and 0.44 m in radial, along-track and cross-track directions respectively, and 2 ns as clock errors. For the other GNSS systems they found errors two to three times higher. The computed SISRE values confirm the better accuracy of GPS orbits compared to other GNSS's, since the global average SISRE values are 0.7 \(\pm\) 0.02 m (GPS), 1.5 \(\pm\) 0.1 m (BeiDou), 1.6 \(\pm\) 0.3 m (Galileo) and 1.9 \(\pm\) 0.1 m (GLONASS). These results apply to data available in 2013. Since then the quality of the signals and orbits have considerably improved, and a re-evaluation of the whole issue is justified. MATLAB-based _multiGNSS_ software (The MathWorks, Inc., Natick, MA, USA) is used for this purpose [4], which allows the estimation at each epoch of the three receiver coordinates, one Tropospheric Zenith Delay and nGNSS receiver time offsets, where nGNSS is the number of tracked GNSS constellations. The latter unknowns are the sums of the receiver clock offset and the offset of the GNSS time scale relative to a common, interGNSS time scale [5]. Differentiation of such an offset relative to the GPS data yields, epochwise and for each receiver, estimates of the GNSS time offset to GPS. Comparing across different receivers it can be seen that such offsets can be biased relative to each other by as much as several tens of nanoseconds. The average of six Septentrio receivers was arbitrarily selected as reference to estimate the receiver biases relative to the average Septentrio. For a given receiver brand, the bias relative to Septentrio for the various GNSS is very repeatable, with a few exceptions.