Upload
eric
View
213
Download
0
Embed Size (px)
Citation preview
ORIGINAL ARTICLE
Monitoring of UTC(k)’s using PPP and IGS real-time products
Pascale Defraigne • Wim Aerts • Eric Pottiaux
Received: 17 January 2014 / Accepted: 12 April 2014
� Springer-Verlag Berlin Heidelberg 2014
Abstract The time transfer technique based on Precise Point
Positioning (PPP) has proved to be a very effective technique
allowing the comparison of atomic clocks with a precision of a
hundred picoseconds, and with latency of 2 days. Using
satellite orbit and clock information from the IGS real-time
products, it is now possible to compute very precise time
transfer solutions based on PPP in near real-time, i.e., with a
latency down to some minutes. We present PPP-based time
transfer results obtained in near real time with the new version
of the GNSS data processing software Atomium, and the
satellite products mentioned above. We additionally analyze
the results that can be obtained with low latency using the
NRCan Ultra-Rapid products (EMU) available with a delay of
90–150 min. From the statistics of the results, it is concluded
that the real-time IGS products allow detection of a clock jump
larger than 1.5 ns after some minutes; the detection threshold
falls down to 0.8 ns when using the EMU products about 2 h
later. It is also shown that in near real time, a frequency change
larger than 2e-14 can be detected when looking at the last 24 h
data or larger than 2e-13 when looking at the last 2 h. As
demonstrated, the quality of the monitoring depends on the
distance between the two stations, so that distances shorter than
about 3,000 km should be preferably used for a near real-time
comparison of atomic clocks based on PPP.
Keywords UTC(k) � PPP � Time transfer
Introduction
The International Atomic Time (TAI) is computed by the
International Bureau of Weights and Measurements
(BIPM) from an ensemble time scale algorithm combining
about 400 atomic clocks distributed in about 60 laborato-
ries worldwide. The Universal Time Coordinated (UTC) is
then obtained after correcting TAI by the number of leap
seconds introduced since its origin in 1972. Since UTC is
being computed a posteriori, it is not available in real time.
Each time laboratory, therefore, maintains one realization
of UTC, named UTC(k) where k is the acronym of the
laboratory. UTC(k) is a clock, or a time scale, adjusted to
produce the best possible extrapolation of UTC and serves
then as an accurate time source available in real time. The
monitoring of these realizations of UTC is classically done
through the comparison with the true UTC, when this one
is available. Presently, a rapid version of UTC is provided
by the BIPM on a weekly period (Arias et al. 2012), giving
a maximum latency of 10 days to get the comparison
UTC(k)-UTCr. The official UTC is, however, computed on
a monthly basis which imposes up to 45 days for the val-
idation of UTC(k) via its comparison with the true UTC.
While UTC(k) is continuously compared with the lab-
oratory clocks, an external monitoring with parallel real-
izations of UTC is a powerful tool for the time laboratories
to increase the reliability of their time scale. The time
transfer technique based on Precise Point Positioning (PPP)
has proved to be a very effective technique allowing the
comparison of atomic clocks with a precision at the level of
a hundred picoseconds, and with latency of 2 days (Orgi-
azzi et al. 2005; Defraigne et al. 2008). PPP time transfer is
presently operationally used for many time links included
in the computation of the TAI (Petit et al. 2011). PPP
(Zumberge et al. 1997; Kouba and Heroux 2001) is based
P. Defraigne (&) � W. Aerts � E. Pottiaux
Royal Observatory of Belgium, Avenue Circulaire, 3,
1180 Brussels, Belgium
e-mail: [email protected]
W. Aerts
e-mail: [email protected]
E. Pottiaux
e-mail: [email protected]
123
GPS Solut
DOI 10.1007/s10291-014-0377-5
on a consistent modeling and analysis of GPS, and possibly
GLONASS (Defraigne and Baire 2011), dual-frequency
code and carrier phase measurements, using external pro-
ducts for the satellite orbits and clocks, in order to deter-
mine the station position, its clock synchronization error
and the troposphere zenith delay at each observation epoch.
The differences between the clock solutions obtained for
two remote stations provide, therefore, the synchronization
offset between the two station clocks and its evolution over
time. This technique is widely recognized for its high
resolution, with a classical sampling of one point each 30 s,
its low statistical uncertainty of 0.1 ns, when ignoring the
uncertainty of the instrumental hardware delays calibration,
and its ability to reach a stability of 10-15 or better at an
averaging time of 1 day, thanks to the very low noise level
of the carrier phases (Larson et al. 2000). The systematic
uncertainty for PPP time transfer is equivalent to that of the
code-only time transfer, as the code data are the only
observables providing access to the timing information, the
carrier phases being ambiguous. Clock solution accuracy
is, therefore, limited to some nanoseconds, due to the
colored nature of the code measurements (Defraigne and
Bruyninx 2007) and the performances of instrumental
calibrations, i.e., 1 ns on each frequency for absolute cal-
ibration (Proia et al. 2011) and 1.5 ns for carefully done
individual long-distance relative calibration (Esteban et al.
2010). Usually, IGS Rapid or Final products are used to
remove the satellite clock errors from the measurements
and to model the satellite positions. These products are,
however, available after a minimum of 17 h. IGS is also
providing Ultra-Rapid products but the clock products
available in real time are in that case based on predictions
over several hours, producing satellite clock uncertainties
of 3 ns, which is too large for a comparison of ground
clocks at the nanosecond level. We, therefore, propose here
to use two sets of estimated satellite products available
with a low latency to provide PPP solutions with the same
low latency. The first one is the IGS real-time products
(Caissy and Agrotis 2011), available with a latency of 30 s,
allowing a clock monitoring in near real-time, i.e., down to
some minutes after the last observation. The second one is
the NRCan Ultra-Rapid products (EMU) generated hourly
with a delay of 90 min after the last observation (Mireault
et al. 2008), and already proposed by Cerretto et al. (2012)
for clock monitoring with a latency from 2 to 3 h. This
capability can be considered useful for the National
Metrology Institutes, being provided with an additional tool
for comparisons of their local realization of UTC or for any
time scale for which the real-time monitoring is crucial.
We start with a presentation of the satellite orbit and
clock products used, followed by a description of our
analysis scheme based on the PPP software tool Atomium
(Defraigne et al. 2008). In particular, the modifications
introduced in the GNSS data processing to be real-time
product compliant, are detailed. The next two sections
present a quantification of the quality of the results
obtained from the analysis conducted using the EMU or
IGS real-time products for the satellite clocks and orbits, in
order to determine at which level it can serve as near real
time or low latency monitoring of atomic clocks connected
to a GNSS receiver.
Near real-time satellite orbit and clock products
As mentioned in previous section, two sets of satellite
clocks and orbits available with a very short latency have
been considered: the first one is the IGS real-time clocks
and orbits which can be obtained from the RTCM streams
delivered in real time by the NTRIP Broadcaster http://
www.igs-ip.net. These products are the output of an IGS
Real-time Working Group established in 2001 with the
goal to design and implement real-time IGS infrastructure
and processes (Caissy and Agrotis 2011). The second set of
products is the EMU Ultra-Rapid products delivered by the
NRCan Analysis Center of the IGS (Mireault et al. 2008),
in the same format as the IGS products, i.e., SP3 and
RINEX clock format.
Real-time IGS products
The IGS presently manages a global real-time GNSS
tracking network and generates combined real-time ana-
lysis products. These products are available with a sam-
pling rate of 5 s and a latency of about 30 s. As for the
classical post-processed IGS products, the different IGS
real-time Analysis Centers (ACs) provide real-time clocks
and orbits. A combination is then operated by ESOC who
assumes the role of IGS real-time Analysis Center Coor-
dinator, producing the combined products IGC01 we used
here. These products are provided as corrections to the
broadcast orbits and clocks, which we converted in a first
step into classical IGS standard files of post-processed
orbits and clocks (sp3 and clk formats). Note that the orbits
streamed in the message IGC01 are very close to the Ultra-
Rapid combined orbits IGU. We tested the use of either the
IGC01 or the IGU orbits and found that the impact on the
results, few picosecond only, was negligible.
The quality of the real-time satellite clocks was esti-
mated to have a 2-sigma uncertainty of 200–400 ps (Hadas
and Bosy 2014) with an rms two times larger. The refer-
ence for the IGS real-time satellite clocks is not a contin-
uous clock or time scale, so that the clock solution of one
particular station is not continuous. For this reason, only a
difference between the clock solutions of two stations can
be used for clock monitoring. This is illustrated in Fig. 1
GPS Solut
123
where the clock solutions of two IGS stations equipped
with a H-maser (BRUX and PTBB) have been depicted.
We retrieve indeed the same jumps at the same epochs,
which are jumps in the reference of the IGS real-time
clocks. When looking at the differences between the two
stations (Fig. 1, bottom part), these jumps cancel and the
solution directly represents the clock offset evolution
between the two clocks that are compared.
Ultra-rapid NRCan products
The second set of products is the EMU Ultra-Rapid pro-
ducts delivered by the NRCan Analysis Center of the IGS
(Mireault et al. 2008) in the same format as the IGS pro-
ducts, i.e., SP3 and RINEX clock format. A new set of two
files (sp3 and clk) is delivered each hour. Each clk file
contains satellite clocks for the last 24 h, and each sp3 file
contains the satellite positions estimated in the last 24 h,
and predicted for the following 24 h. The EMU products
are available around 90 min after the last epoch of the clk
file, so that the latency for the products of any epoch is
between 90 and 150 min. As post-processed products, they
are based on a higher degree of internal consistency
checking like, e.g., outlier rejection, than the real-time IGS
products described in previous section. The 2-sigma
uncertainties on these clock products are estimated to
170 ps (Cerretto et al. 2012). The advantage of using the
EMU products rather than the combined IGU products is
that they are available more rapidly, i.e., 90 min instead of
3 h, they are updated, each hour rather than every 6 h for
the IGU, and with a higher sampling rate, 30 s instead of
900 s.
There is, therefore, a major difference between the IGS
real-time products for which a given epoch is only
computed and provided once, in real time, and the EMU
products which are computed for a moving window of
24 h. For each new hourly computation performed with the
EMU, a new set of orbits and clocks is, therefore, used. The
reference for the satellite clocks is continuous inside one
24 h EMU data set, but is changing from one set to the next
one. Figure 2 illustrates the impact of these changes on the
station clock solutions obtained with PPP. Consequently, as
for the real-time IGS products, the clock solution obtained
for one particular station with the EMU cannot be used
alone for the monitoring of the clock stability. Only the
differences between two station clocks will, therefore, be
presented in the following.
PPP software modifications
All the PPP results presented have been obtained using the
PPP software Atomium, developed at the Royal Observa-
tory of Belgium (Defraigne et al. 2008). Only GPS data are
used in this study; the addition of GLONASS observations
does not significantly improve the PPP-based time transfer
solutions as shown in Defraigne and Baire (2011). Ato-
mium is based on a least-squares analysis over a given data
batch, providing one station position for the data batch, one
clock solution at each observation epoch and tropospheric
zenithal delays with a chosen sampling rate. In the present
case, the troposphere was determined as one estimation
each 20 min, with a relative constraint of 1.5 mm between
two successive values. A linear interpolation of the tro-
pospheric zenith delay is used between the epochs where a
value is estimated.
Some preliminary results of near real-time monitoring of
atomic clocks using Atomium and real-time IGS products
Fig. 1 PPP clock solutions for BRUX and PTBB obtained using
Atomium and the IGS real-time products for one 24 h data batch.
Bottom time transfer solution obtained as the differences of the two
PPP solutions
Fig. 2 PPP clock solutions for BRUX and PTBB obtained using
Atomium and the EMU products for five successive 24 h data batch
(top), and time transfer solution obtained as the differences of the two
PPP solutions (bottom)
GPS Solut
123
have been presented in Defraigne et al. (2012). These
results contained an important number of outliers, which is
not acceptable for a real-time monitoring. For this reason, a
new cleaning procedure has been implemented in Atomi-
um. In its original version, a pre-inversion cleaning based
on the Hatch-Melbourne-Wubbena (Hatch 1982) combi-
nation was applied on the raw data in order to detect out-
liers and cycle slips, and a second cleaning was then
operated for the rejection of smaller outliers based on the
residuals after a first inversion. However, due to some
erroneous satellite clock products in the real-time data
introduced after the first cleaning, the first inversion was
contaminated, affecting all the residuals and making the
whole procedure unsuccessful. In order to overcome that
problem, an additional cleaning was introduced after cor-
recting the code measurements for the satellite distance, the
satellite clock, and the dry atmosphere, just before the first
inversion. This allows removing new outliers caused by
problems in the real time or EMU satellite orbits and
clocks. It must be noted that the IGS real-time products
have no accuracy codes and no information concerning the
quality of the individual values, so that a software-based
cleaning is really necessary to reject observations of sat-
ellites with erroneous clock products. Furthermore, as real-
time products have epochs without any satellite clock,
mainly due to short interruptions of the streaming, an
additional software modification was introduced to keep
the same ambiguities rather than to determine new ones
when a data gap is due to the absence of satellite clock for
one epoch; this avoids the presence of frequent jumps
associated with new ambiguity determinations in the
solutions.
A validation of this new version of Atomium is pre-
sented in Fig. 3 which illustrates the differences between
the PPP clock solution computed with Atomium, and the
IGS Final combined solution for five IGS stations over the
6 month period from October 1, 2012 to March 31, 2013.
The figure confirms the announced precision of PPP-based
time transfer: the standard deviations of these differences
extend from 62 to 88 ps. Some specific multi-day corre-
lations can be seen in the differences shown in Fig. 3.
These can be explained by differences in the data pre-
processing which, associated with some multipath or near-
field effects can induce some diurnal effect as the data are
analyzed in daily data batches.
PPP using real-time and EMU products
A set of IGS stations equipped with a Hydrogen Maser was
selected in order to investigate the quality of the clock
comparisons based on a PPP computation using the IGS
real-time products and EMU products. Most of these sta-
tions are co-located with a time laboratory providing a
local realization of UTC. They are illustrated in Fig. 4.
We then used BRUX (time laboratory ORB, Brussels,
Belgium), PTBB (time laboratory PTB, Braunschweig,
Germany) and USN3 (time laboratory USNO, Washington
Fig. 3 Differences between the PPP clock solution, computed with
Atomium using the IGS final products, and the IGS final combined
clock solution
Fig. 4 Distribution of stations
used in the present study
GPS Solut
123
DC) as core stations, from which we formed all the base-
lines of different lengths. A period of 6 months has been
chosen for the analysis, covering October 1, 2012 to March
31, 2013.
Figure 5 presents the PPP time transfer solutions
obtained using Atomium and IGS real-time products, the
EMU and IGS final products for the 6 month period cited
above, applied to one long baseline (TWTF-USN3,
10,700 km) and one continental baseline (BRUX-PTBB,
450 km). Figure 6 presents the differences between the
PPP time transfer solutions obtained in short latency and
those obtained with the final IGS products, the standard
deviations of these differences are also indicated on the
Figure.
A first observation of Fig. 6 is that the magnitude of the
differences is clearly dependent on the baseline length.
This can be easily explained by the spatial correlation
between satellite position and clock errors: these errors
have a similar impact on the PPP clock solutions for nearby
stations and hence cancel when taking the difference of the
solutions for time transfer. For remote stations, the impact
on the clock solution is different since the satellite visi-
bility is different, and this impact does not cancel when
taking the difference between the two PPP solutions. It
must, therefore, be recommended to use short baselines for
making real-time monitoring of time scale using real-time
products. This thesis was confirmed by the study of all
baselines formed from the three reference stations USN3,
BRUX and PTBB. A second observation of Fig. 6 is that as
expected, the solutions obtained with the IGS real-time
products are characterized by a noise level significantly
larger than those obtained with the EMU. The precision of
the solutions is indeed increasing with the latency of the
satellite products used. In the following, we quantify the
possible clock problem detection that can be obtained
either after some seconds to minutes using the IGS real-
time problem or after about 2 h using the EMU products.
Figures 7, 8 and 9 present the average difference, the
standard deviation and the maximum of the differences
between the PPP time transfer solutions, obtained using
Atomium and either the IGS real-time products or the
EMU, and the IGS final products for the same 6 month
period and for all the time links presented in Fig. 4. In
Fig. 7, we observe that some bias can exist between solu-
tions obtained using the real-time products and those
obtained with the final IGS products; however, this bias is
not systematic but depends on the link, and its magnitude is
increasing with the distance between the stations. The
estimated bias for all the time links investigated is lower
than 150 ps, and it is always significantly smaller than the
standard deviation of the differences shown in Fig. 8. We
Fig. 5 PPP time transfer solutions obtained using Atomium and the
IGS real-time products (red), the EMU (green) and the IGS final
products (black); the curves have been vertically shifted by 2 ns in
order to improve the visibility
Fig. 6 Differences between the time transfer solutions obtained with
the IGS real-time products (red) or the EMU (green) with respect to
the solution obtained with the IGS final products for the same time
links as in Fig. 5
Fig. 7 Average of the differences, i.e., bias between the Atomium
solution obtained with final IGS products and the Atomium solution
based on IGS real-time products (red), or EMU (green)
GPS Solut
123
can, therefore, conclude that no systematic bias exists in
the solution obtained with real-time or EMU products.
Figure 8 clearly confirms the increase in the magnitude of
the differences with increasing distance between the sta-
tions. Figure 8 furthermore reproduces the standard devi-
ations of the differences between the Atomium and the IGS
final solution. It can be observed that with the EMU pro-
ducts, although producing differences increasing with the
distance, the standard deviations of these differences are
always smaller than the standard deviations of the differ-
ences between the Atomium solution based on the IGS
final products, and the IGS solution itself. The impact of
the choice of products in this case is therefore smaller than
the impact of the computation procedure. On the contrary,
the use of IGS real-time products has an impact larger than
the computation procedure for all time links larger than
3,000 km, as seen from the comparison of the standard
deviation of the differences with respect to the Atomium
solutions computed with the IGS final products. Finally,
looking at Fig. 9, we can determine the level at which a
clock jump can be detected and attributed unambiguously
to the clock and not to an artifact of the satellite clock
products used. For baselines shorter than 1,000 km, this
level is 0.5 ns when the EMU are used, i.e., with a latency
of 90–150 min, and 1 ns when the IGS real-time products
are used, i.e., with a latency of 5 min. While this level is
still valid for long baselines with the EMU products, it is
raised to 1.5 ns for baselines larger than 3,000 km with the
IGS real-time products.
In order to determine which level of frequency change
can be detected by the near real-time monitoring based on
IGS real-time/EMU products, we plotted in Fig. 10 the
frequency differences over 24 h and over 2 h between the
PPP solution computed with the IGS real-time/EMU pro-
ducts and the IGS Final combined solution. These fre-
quency differences are computed as the linear regression
coefficient over the 24 h solution differences (real-time/
EMU—Final) in the first case, and over each 2 h window
starting at an integer hour of the same differences in the
second case. We can observe that for a clock frequency
monitoring, looking at a 24 h solution, allows detection of
any frequency change larger than 1.8e-14; when using only
the last 2 h for the monitoring, only frequency changes
larger than 1.8e-13 can be detected. For smaller frequency
changes observed in the solution, no distinction can be
done between a clock frequency change and an artifact due
to the satellite orbit/clock errors.
Considering the results presented here above, two rec-
ommendations can be made for near real-time comparison
Fig. 8 Standard deviation of the differences between the Atomium
solution obtained with final IGS products and the Atomium solution
based on IGS real-time products (red), EMU (green) and the IGS final
combined solution (black)
Fig. 9 Maximum differences between the Atomium solution
obtained with final IGS products and the Atomium solution based
on IGS real-time products (red), EMU (green) and the IGS final
combined solution (black)
Fig. 10 Maximum frequency differences as a function of the baseline
length
GPS Solut
123
of atomic clocks based on PPP: the first one is to use
preferably intra-continental links, since long-distance links
are affected by a larger noise, especially when the IGS real-
time products are used. Furthermore, there is an advantage
of using the EMU products when they are available, i.e.,
with a latency of 90–150 min, as these refine the solution
obtained in near real-time with the IGS real-time products.
Note that the results obtained in this study concerning the
use of the EMU are in good agreement with a similar
experiment based on the NRCan PPP analysis software
(Cerretto et al. 2012).
Conclusions
Using real-time or Ultra-Rapid products for satellite orbits and
clocks, it is now possible to compute near real-time or low
latency PPP solutions and hence provide a near real-time or
low latency clock monitoring. We proposed an analysis of the
results obtained from the PPP analysis conducted using the IGS
real-time products for the satellite clocks and orbits, in order to
determine the level at which these PPP solutions can serve as
near real-time monitoring of the UTC(k)’s or any other clock
connected to a GNSS receiver. A comparison was, moreover,
made with the results obtained with the EMU products pro-
vided hourly by the NRCAN analysis center of the IGS.
A new version of Atomium was used for this study,
including a new data cleaning able to remove from the data
the satellites having bad orbits or clocks, avoiding the
presence of outliers in the clock solutions computed with
the IGS real-time products or any clock/orbit products of
lower quality than the IGS combined Final or Rapid pro-
ducts. Such outliers would indeed impede the method to be
used for near real-time monitoring of clocks.
Using the IGS real-time products available with a
latency of about 30 s, it was observed that the magnitude of
the differences with respect to the time transfer solutions
obtained with the IGS Final products are significantly
correlated with the distance between the stations. From
about 100 ps for a 500 km baseline, it grows up to about
300 ps for the inter-continental baselines. This results from
satellite position and clock errors which have a similar
impact on the PPP clock solutions for nearby stations and
hence cancel when making the difference between the
solutions for time transfer, while they do not cancel for
more remote stations. Detection of clock problems using
IGS real-time products is, therefore, preferable using short
baselines. However, the results presented show that near
real-time PPP based on these real-time products allows
detection in a few minutes of any clock jump larger than
1.5 ns, and any frequency change larger than 2e-14 when
looking at the last 24 h data, or larger than 2e-13 when
looking at the last 2 h.
These results were compared with those obtained using
the EMU products available with a 90–150 min latency. It
was observed that these products provide a solution of
better quality than the IGS real-time products. The mag-
nitude of the differences with respect to the time transfer
solution obtained with the IGS Final products is always
lower than the differences between the Atomium and the
IGS final solutions, which means that the impact of the
products (EMU or IGS Final) is lower than the impact of
the analysis strategy (Atomium PPP or IGS combined). It
was also shown that using the EMU products, it is possible
to detect any clock jump larger than 0.8 ns slightly more
than 90–150 min after the event, and a frequency change
larger than 1.2e-14 when looking at the last 24 h data, or
larger than 1.6e-13 when looking at the last 2 h available,
i.e., ending 90 min before the current epoch. This capa-
bility is the same as the IGS Rapid of Final products, but
with longer latency.
A low latency clock comparison for a given set of time
links is presently running at the Royal Observatory of
Belgium; the results are stored in a database, and a web
page (http://clock.oma.be) displays the associated plots
updated for each new computation. The clock comparisons
are provided with a latency of 12 min after the end of the
hour using IGS real-time products. After 90 min, the
solutions in the database and the associated plots on the
web pages are replaced by new solutions computed with
the EMU products produced by the NRCan IGS analysis
center. One day later, the solutions in the database are
replaced by those computed with the IGS Rapid products,
and 2 weeks later they are replaced by the solutions com-
puted with the Final IGS orbits.
From the statistics obtained from this analysis, it is
concluded that the solutions proposed on the webpage
allows, within an hour, detection of a clock jump larger
than 1.5 ns after 12 min, or 0.8 ns after 90 min, and a
frequency change larger than 2e-14 when looking at the
last 24 h data, or larger than 2e-13 when looking at the last
2 h.
Acknowledgments The authors thank the IGS community, and
especially the IGS Real-Time Working Group members for the real-
time clocks and orbits and the NRCan analysis centers for the hourly
EMU products which allow us to process these near real-time clock
comparisons.
References
Arias F, Harmegnies A, Jiang Z, Konate H, Lewandowski W, Panfilo
G, Petit G, Tisserand L (2012) UTCr: a rapid realization of UTC.
In: Proceedings of European Frequency and Time Forum,
Gothenburg, Sweden, 2012, pp 24–27
Caissy M, Agrotis L (2011) Real-time working group and real-time
pilot project. Int GNSS Serv Tech Rep 2011:183–190
GPS Solut
123
Cerretto G, Tavella P, Lahaye F, Mireault Y, Rovera D (2012) Near
real-time comparison and monitoring of time scales with Precise
Point Positioning using NRCan Ultra-Rapid Products. IEEE
Trans Ultrason Ferroelectr Freq Control 59(3):545–551. doi:10.
1109/TUFFC.2012.2226
Defraigne P, Baire Q (2011) Combining GPS and GLONASS for time
and frequency transfer. J Adv Space Res 47(2):265–275. doi:10.
1016/j.asr.2010.07.003
Defraigne P, Bruyninx C (2007) On the link between GPS pseudor-
ange noise and day-boundary discontinuities in geodetic time
transfer solutions. GPS Solut 11(4):239–249. doi:10.1007/
s10291-007-0054-z
Defraigne P, Guyennon N, Bruyninx C (2008) GPS Time and
frequency transfer: PPP and phase-only analysis. Int J Navig Obs
2008, Article ID 175468. doi:10.1155/2008/175468
Defraigne P, Baire Q, Lahaye F, Cerretto G, Rovera D (2012) Near
real-time comparison of UTC(k)’s through a Precise Point
Positioning approach. In: Proceedings of European Frequency
and Time Forum, Gothenburg, Sweden, 2012, pp 349–353
Esteban H, Palacio J, Galindo FJ, Feldmann T, Bauch A, Piester D
(2010) Improved GPS-based time link calibration involving
ROA and PTB. IEEE Trans Ultrason Ferroelectr Freq Control
57(3):714–720. doi:10.1109/TUFFC.2010.1469
Hadas T, Bosy J (2014) IGS RTS precise orbits and clocks
verification and quality degradation over time. GPS Solut.
doi:10.1007/s10291-014-0369-5
Hatch R (1982) The Synergism of GPS Code and Carrier Measure-
ments. In: Proceedings of the Third International Symposium on
Satellite Doppler Positioning at Physical Sciences Laboratory of
New Mexico State University, Feb. 8–12, vol. 2, pp 1213–1231
Also available as Magnavox Technical Paper MX-TM-3353-82,
No. 11024/D
Kouba J, Heroux P (2001) Precise Point Positioning using IGS orbits
and clock products. GPS Solut 5(2):12–28. doi:10.1007/
PL00012883
Larson K, Levine J, Nelson L (2000) Parker T (2000) Assessment of
GPS carrier-phase stability for time-transfer applications. IEEE
Trans Ultrason Ferroelect Freq Contr 47:484–494
Mireault Y, Tetreault P, Lahaye F, Heroux P, Kouba J (2008) Online
precise point positioning: a new, timely service from Natural
Resources Canada. GPS World 19(7):59–64
Orgiazzi D, Tavella P, Lahaye F (2005) Experimental assessment of
the time transfer capability of Precise Point Positioning. In:
Proceedings IEEE International Frequency Control Symposium,
Vancouver, Canada, 2005, pp 337–345
Petit G, Harmegnies A, Mercier F, Perosanz F, Loyer S (2011) The
time stability of PPP links for TAI. In: Proceedings of Joint
Meeting European Frequency and Time Forum and IEEE
International Frequency Control Symposium, 2011,
pp 1041–1045. doi: 10.1109/FCS.2011.5977299
Proia A, Cibiel G, White J, Wilson D, Senior K (2011) Absolute
calibration of GNSS time transfer systems: NRL and CNES
techniques comparison. In: Proceedings of Joint Meeting Euro-
pean Frequency and Time Forum and IEEE International
Frequency Control Symposium, 2011, pp 1–6. doi: 10.1109/
FCS.2011.5977799
Zumberge JF, Heflin HB, Jefferson DC, Watkinsand MM, Webb FH
(1997) Precise Point Positioning for the efficient and robust
analysis of GPS data from large networks. J Geophys Res
102(B3):5005–5017. doi:10.1029/96JB03860
Dr. Pascale Defraigne received
her doctoral degree in 1995
from the Universite Catholique
de Louvain. She is presently
responsible for the time and
frequency laboratory at the
Royal Observatory of Belgium.
She chairs the Working Group
of the Consultative Committee
for Time and Frequency on
GNSS time transfer.
Dr. ir. Wim Aerts (GNSS
research group, Royal Observatory
of Belgium since 2009) obtained a
PhD degree in electrical engineer-
ing from the KatholiekeUniversi-
teit Leuven (KULeuven), Belgium
in 2009. His research interests
include improving accuracy of
timing and positioning with GNSS.
From 2009 onwards he is guest
professor at the Katholieke Uni-
versiteitLeuven (FIIWKU Leuven
@ KHLim) with an engineering
course on analog and digital
telecommunications.
Dr. Eric Pottiaux (GNSS
research group, Royal Observa-
tory of Belgium since 1998)
received his Ph.D. degree from
the Universite Catholique de
Louvain (UCL), Belgium, in
2010. He is member of the
geodetic expert team within the
EUMETNET EIG GNSS water
VApour Program (E-GVAP),
member of the IGS troposphere
working group and co-chairs
working group 2 of the COST
Action ES1206 GNSS4SWEC.
GPS Solut
123