[IGSMAIL-6511] final report on IGS station clocks

[Jim.Ray]

Author:  Jim Ray

Since the start of the former IGS/BIPM time transfer pilot project in
the late 1990s, I have informally monitored the performance of station
and satellite clocks in the IGS products and notified station operators
of problems and other issues.  With this final summary report, that
personal effort now ends.

Clock Products website
----------------------
Station operators, esp those with external atomic clocks, should get into
the habit of periodically checking the plots posted by Ken Senior at:

   Final clocks = https://goby.nrl.navy.mil/IGStime/igst_plots_monthly.php
   Rapid clocks = https://goby.nrl.navy.mil/IGStime/igrt_plots_monthly.php

Both are organized into monthly bins.  The Rapids are updated daily (by
17:00 UTC) while the Finals are updated weekly (usually Thursdays).  Ken
recently added new plots of the form [YYMMM]_ssss_data_vs_timescale.ps
where "ssss" is the station name, YY is the year, and MMM is the month.
These plots are now available for all stations, including those without
external atomic clocks, and show the time domain clock variations (as
viewed from the GPS data).  These are obviously useful to monitor the
performance of external clocks, but they can sometimes also be diagnositic
even for receivers using internal clocks.

Plots of the form [YYMMM]_ssss_states_and_sigmas.ps give more detailed
information for those clocks used in the IGS timescale algorithm, but are
probably too technical for most users.  Note that the new Hadamard
deviation plots are insensitive to quadratic variations (normal for clock
comparisons) whereas the previous Allan deviations are insensitive only to
linear differences.  Note also that Ken no longer removes the day-boundary
jumps in computing Hadamard deviations, while they were removed in the old
Allan deviations.  This leads to visible stability differences at about 1 d
intervals and longer, but the stability of the IGS timescales remains near
1e-15 at 1 d; it is improved over longer intervals thanks mostly to a
better steering algorithm.

Another valuable source of monitor information are plots of the clock
discontinuities between successive days, which are only sensible for
H-maser stations.  Those are posted at:

   https://goby.nrl.navy.mil/IGStime/daybdy/

For background information, please see the review at:

   http://acc.igs.org/clocks/clock-pilot-proj_metro03.pdf

and references therein.

While there are ~72 IGS stations equipped with H-masers according to site
logs, only about 20-25 of these contribute significantly to the IGS Rapid
and Final ensemble timescales, and less than 15 dominate.  Many of the
best-performing clocks are at timing labs, which is understandable given
their natural concern.  Reasons for the shortfall in availability include:

   * lack of RINEX data or slow delivery
   * use by less than 2 ACs, the minimum required for a combined IGS clock
     product
   * observed stabilities much worse than H-maser performance

The 2nd factor is aggravated when multiple IGS stations are located near
one other, each with competing utilities.  This dilutes AC usage and really
should be avoided by consolidating such multiple occupations into a single
super-station.  (Data from ancillary stations is very useful and highly
recommended but it should be reserved for local studies rather than
distributed externally.)

Sources of clock instability
----------------------------
There are many factors that can degrade the stability of H-maser signals
before they reach the GNSS receiver, most often downstream from the maser
itself.  Here are some common sources of problems:

   * frequency multipliers -- Even when they operate normally, they can add
     diurnal variations due to temperature sensitivity.
   * frequency distribution systems -- These often cause problems but are
     needed at facilities like VLBI sites in order to make multiple copies
     of the H-maser reference signal.
   * poor environmental control -- Diurnal variations are common due to
     exposure of the H-maser (least likely), frequency signal distribution
     system, any multipliers, antenna cables, any signal splitters, or GPS
     receiver to temperature variations if the thermal sensitivity of any
     component is significant.

In addition to these degradations in the timing systems, other GNSS general
problems are also relevant:

   * poor cable connections -- Single cable runs are always preferable, of
     minimal length and number of connectors.  Connectors should not be
     reset or disturbed unnecessarily, and should not be opened when there
     is any chance of invasion by water.  Cables should not be bent or
     unnecessarily exposed to outside conditions.
   * poor RF environment near antenna -- Opportunities for multipath
     reflections should be minimized, esp from surfaces close to the
     antenna.  Any reflections from behind and near the antenna (unless
     blocked by Eccosorb, for instance) will leak into the observations and
     introduce biases into the clock estimates as well as position and other
     parameters.  These can vary as the electrical properties change due to
     rain and ice, for example.  Consequently, the best antenna mounts have
     the least reflecting material near the antenna.  This fact is seen in
     the repeability of time domain clocks and position time series among
     different stations.
   * faulty antenna or receiver -- Good antennas tend to operate for long
     periods without attention, apart from the clearing of snow or other
     accumulates or lightning strikes.  Receiver failures are more common
     and often go unnoticed for long periods.  Strong indicators of problems
     include unexplained loss of SNR, increased phase cycle slips (which
     should not exceed about 1 per 1000 obs), or changes in observed clock
     behavior (even for non-atomic clocks).

Current status of H-maser stations
----------------------------------
Final comments on individual H-maser stations are included here.  Cesium and
rubidium stations are listed further below, but without comments.  "High
weight" refers to weight in the IGS timescale ensembles and is typically
about 5%.  "(lab)" marks to stations at timing labs.

Due to length, the rest of this report is only available in the complete
version, available at:

   http://acc.igs.orb/clocks/final-report.txt