# Improved Multi-GNSS PPP Software for Upgrading the DEMETRA Project Time Monitoring Service
## 1 Introduction
Because these steering parameters are computed based on the monitoring data, in this paper, we focus on the algorithms of the time monitoring part of the service. The core software in the DEMETRA timing monitoring service is called Atomium, which is developed by ORB [11]. Atomium is a GPS+GLONASS PPP software dedicated to GNSS time transfer and geodetic positioning. It uses the least-square method to estimate the following parameters: receiver clock error at each epoch; user antenna position for the whole daily data batch; tropospheric zenith wet delay at defined interval, and float phase ambiguities. The software uses satellite products made available from International GNSS service (IGS) and estimates the clock errors as \"IGS time-user clock\". On the DEMETRA side, the computation \"IGS time-DEMETRA reference\" is also carried out with PPP, for the same time period. Differentiating these two quantities, we obtain estimates of the user clock with respect to the DEMETRA reference. The user clock can be either the internal clock of the GNSS receiver or an external clock (e.g., hydrogen maser, cesium, rubidium atomic clock) used to drive the GNSS receiver at the user side. For convenience, all these clocks are called user clock or receiver clock, in general, in this paper. The DEMETRA reference time is chosen to be the UTC(IT) time scale that feeds the GNSS receiver at the INRIM side. UTC(IT) is the local realization of UTC made by the INRIM and is based on a hydrogen maser steered on UTC. Atomium PPP has been dedicated to precise time and frequency transfer for more than 10 years [15]. Currently, the PPP time transfer is mainly limited by the time discontinuity at the daily batch boundary, which is caused by the averaging of the noisy code measurements in the daily batches [16]. A common way to avoid the daily boundary discontinuities is to extend the estimation batch to multi-day (e.g., with PPP software developed by Natural Resources Canada (NRCAN) [17]). However, the boundaries still exist at the end of the multi-day batches. In addition, this method may cause the long-term artificial variation of the clock estimation, introducing additional random walk noise inside the batch [18]. Moreover, while being the state-of-the-art GNSS technique for modern high-quality clock comparison,short-term stability of the PPP is currently limited by the thermal noise in the carrier phase data. Further developments are, therefore, still needed to improve the stability of the PPP clock solution and mitigate the boundary issue. In this paper we present three updated versions of the Atomium PPP software that we have integrated into DEMETRA for improving the time monitoring part of the service: (i) Atomium Galileo PPP; (ii) Atomium constrained PPP; (iii) Atomium integer PPP. The basic ideas of the proposed new algorithms have been presented in [19], while they have not been included in any proceedings paper. In the current work, the mathematic principles of these improved PPP algorithms are described in detail, and results based on experimental data are presented enabling the evaluation of the improvements of the new methods and to define possible application scenarios. Atomium Galileo PPP includes Galileo measurements in the PPP computation, in addition to the GPS and GLONASS ones in the old version. Though the Galileo satellite system is still not fully operational for the moment, comparable performance to GPS in time transfer with code-only measurements has already been demonstrated in [20]. This paper presents the impact of using GPS+Galileo data in Atomium PPP for time and frequency transfer. Second, Atomium constrained PPP will be presented. This approach further constrains the receiver clock with the estimated frequency offset and drift, to retrieve the short-term stability of the measurements on the clocks with good quality (e.g., hydrogen maser), by restricting the impact of thermal noise on the receiver clock solutions [21].