DRAFT<BR>
<BR>
<BR>
<CENTER>
<h1> Time Transfer Issues at Arecibo Observatory - 2000</h1><BR>
<BR>
<h2>D. C. Backer (UC Berkeley), B. Genter, M. Davis, A. Vazquez, 
A. Venkataraman, M. Nolan,
K. Xilouri (UVa), D. Nice (Princeton), Trudi Peppler (NIST) ...<BR>
2000 March 15</h2><BR>
</CENTER>
<BR>
<h2>Outline</h2><BR>
<LI> Introduction<BR>
<LI> Schematic<BR>
<LI> Unix Time<BR>
<LI> Maser Status<BR>
<LI> AO Clock Comparator System (CCS)<BR>
<LI> Princeton Time Monitoring System<BR>
<LI> NIST Monitoring<BR>
<LI>Miscellaneous Notes, ToDo's<BR>
<LI>Propagation in Earth's Atmosphere<BR>
<BR>
<h2>Introduction</h2>
Precision pulsar timing, multi-observatory single pulse
measurements, radar astronomy and other programs demand
accurate transfer of Atomic Time from standards laboratories
to the observatory via GPS. The greatest demand on this
time transfer is for precision pulsar timing owing to the
current precision which can reach down to 25-50 ns on 
several objects in 30-60 minutes of observing. Stability
of time transfer over a decade of time is particularly
demanding owing to changing equipment and cables. This
memo provides an assessment of where we stand at the
Arecibo Observatory, and makes suggestions for the future
maintenance of this level of precision. <BR>
<BR>
<h2>Schematic</h2>
The atomic standards, GPS receivers, time transfer systems
and time/frequency distribution at the Observatory are
summarized in the official <A HREF="timing.gif"> schematic </A>.
Need larger version for clarity xxx?
See Bill Genter for a hard copy or print one from
/share/timing/timing.eps. <BR>
<BR>
There are three atomic standards: Maser, Rubidium 1 & Rubidium 2.
There are two GPS receivers: NIST (National Institute of Standards
and Technology) which is also known as GPS1 & 
TAC (Totally Accurate Clock=Thomas A. Clark) which
is also known as GPS2.
There are two clocks which create 1 PPS signals from the Maser
5 MHz: TRAK & EECO; EECO is about to be retired and replaced
by True Time 1 PPS generator.
There are three time interval measurement systems: Clock Comparator
System/CCS (E. Castro) which uses an HP 5334A counter, NIST unit which
is part of their GPS rig,
& Princeton Unit (J. Taylor) which use a home brew counter.
There is one WWV receiver which is a PC radio system.
Operation of these many units was exhaustively documented
by <A HREF="http://www.naic.edu/%7Edonna/timing.htm"> Donna Kubik 
</A> in her too brief tenure at the observatory; linking to this
pdf file will allow you to copy it/read via acrobat. A hard
copy will be kept in the control room? <BR>
<BR>
<h2>Unix Time</h2>
(from Arun) Mike Nolan is the prime architect of the current NTP-based
synchronisation scheme for the Sun network.  NTP uses a
tree hierarchy to distribute time.  "Peers" in this hierarchy
can synchronize with each other - each one dynamically picks
a synchronization source out of several available (various
sanity checks are built into the algorithm).  The stratum-1
server (currently "cuca" an Ultra-30) receives IRIG code from
the TRAK clock driven from the Maser and broadcasts The Time
to our local network.  A 1PPS signal from the Equipment Room
buffer is input to a few other machines (SPARC IPC, LX, 20)
which also independently broadcast The Time.  Other machines
can pick one of the above to synchronize their clocks.  A few
external servers are also available.  Synchronization accuracy
is typically within 1ms.  Mike has also been thinking about
using GPS input to further stabilize the system.<BR>
<BR>
Useful utilities on the unix system would be "lst" and "mjd"
which, respectively, give current LST and MJD. In addition,
it is often useful to compute lst and mjd for chosen date
so such routines with -? option would be very useful system
wide utilities. I have installed the Berkeley versions of "mjd"
and "rolex" (fancier version by Tony Wong)
in /share/abpp/bin directory and am working on the version
of lst (which we exported from NRAO Green Bank).
<BR>
<h2>Maser Status</h2>
The current state of the maser is that it is drifting seriously
following a failure of the thermal servo on maser cavity on 
about 2000 January 20. The
drift is 100 ns/day - see below.  Time steps will need to be inserted
to maintain proximity of the house 1 PPS to UTC. These steps
need to avoid critical observations and observers need to 
be informed of status quo. <BR>
<BR>
<h2>AO Clock Comparator System (CCS)</h2>
The CCS samples time intervals of the following pairs of 1 PPS
signals: MASER-MASER, MASER-GPS2, MASER-EECO, MASER-TRAK, MASER-RUB1, 
MASER-RUB2, and MASER-TTIME. The CCS sits on each pair of signals
for 1 minute every 10 minutes and takes 30 time interval samples
spaced by
2 s. The average data are stored in daily files every 10 m. 
The file nomenclature
is {mm-dd-yy}.txt. Following a recent request Bill Genter copies
the CCS PC files (<A HREF="03-07-00.txt"> e.g., file for 2000
March 7</A>).
to /share/timing on the unix system. A sample
<A HREF="aotime.f"> program </A> to
read these files, which annoyingly separate columns with tabs,
is available. <BR>
<BR>
<h2>Princeton Time Monitoring System</h2>
The Princeton TAC monitoring halted with a Y2K problem in
the PC bios. During the pulsar Y2K Workshop visit David Nice 
reset the PC clock back 20 y to allow
continued operation of its critical function of recording
the time interval between the TAC/GPS2 and the TRAK clock
1 PPS derived from the maser 5 MHz and distributed to pulsar
backends and elsewhere as the house 1 PPS. There is some
confusion here about the active cumulative file of MASER-GPS
time differences in ~joe/tac: aoclk.1.bak is complete to
end of 1999 when Y2K bug hit; aoclk.1 has recent results after
David restarted the PC monitoring system.<BR>
<BR>
The Princeton system samples the MASER-TAC/GPS2 time interval
every second and stores an average over 10 min along with a
histogram of different readings about the mean in {mjd}.clk
files; ~joe/tac/*.clk; <A HREF="51610.clk"> e.g. for MJD 51610, 2000 March
07</A>). A daily value and current frequency
are determined in a chron job, probably by  ~joe/autofit/tacday.f;
<A HREF="aoclk.example"> e.g., first lines of aoclk.1</A>).
I have compared recent values of these two time interval measurements
of the *same* GPS signals. One might think that the agreement
would be perfect, in the ns's range. But remember that the two
systems don't sample at the same instant, nor do they cover
the same range of the 10 min cycle, and the GPS signals have considerable
jitter owing to averaging over satellites as well as intrinsic
snr. I don't then really know what to expect. Longer term real features
should track and the maser drift certainly is seen equally be both.
A plot of 
<A HREF="ao.tac.2000mar.gif"> AO CCS vs Princeton </A> measurement
of TAC (GPS 2) 1 PPS vs that of maser during 7-12 March
2000 shows a short example of the equivalence of the two systems
(although CCS has a couple noise spikes).  This plot has the two
measures and their difference via a spline interpolation.<BR>
<BR>
<h2> NIST Monitoring</h2>
The NIST time interval measurement is done in "common view" mode.
The same satellites are viewed at the same time from Arecibo and
from NIST. This removes the DoD installed dither in the otherwise
more accurate GPS time codes. (The TAC system suppresses this
by looking simultaneously at *all* satellites above the horizon.)
"Soon" we are told that the dither (SA, selective availability)
will be turned off and this technique will be moot, at least as
far as SA is concerned. Time files each day are generated. Recent
versions have been placed in /share/timing: {mjd}.dat. These
are of limited use. What is important is the results of the 
common view analysis which are provided to the observatory
in hard copy form
by Trudi Peppler (303-497-3276; tpeppler@boulder.nist.gov).
Annual costs for this service is $5000 according to M. Davis.
Trudi has provided the recent results (Table 1 entries from
monthly reports as cumulative files of:<BR>
<A HREF="nist.dt">daily time error MASER-GPS</A><BR>
<A HREF="nist.dtf">daily time error with Kalman filter MASER-GPS</A><BR>
<A HREF="nist.df">daily freq error with Kalman filter MASER-GPS</A><BR>
See also<BR>
<A HREF="nist.readme">README file</A><BR>
<BR>
Kiriaki has entered the daily data from monthly NIST reports in 
files that we are attempting to recover. Trudi also may be able
to extend her contribution backwards in time. I need to check
that files received compare accurately to monthly reports (even
though I am sure they will).<BR>
<BR>
I have started to compare the NIST results with other time interval tables.
The first effort is with the Princeton table in aoclk.1.bak which covers
through to end of 1999. The <A HREF="nist.tac.gif"> plot</A> shows 
a frequency step around MJD 51330 and the large jump in frequency
discussed above around MJD 51560 (2000 Jan 20). What I don't
understand are the two jumps in aoclk.1.bak around MJD 51340
and 51370. These may be 5-MHz cycle jumps in the TRAK clock
which won't be in the NIST reports which sample a 1 PPS direct
from the MASER (see master diagram above). I need to recover
the CCS data to see the independent sampling of the TRAK xxx.<BR>
<BR>
<h2>Miscellaneous Notes, ToDo's</h2>
I note for tutorial purposes that the definition of a time
interval is accurately stated in English as "the algebraic
difference of two clocks read at the same instant". And I
therefore need to update Donna's quote on her Salvador Dali illustrated
cover page of her manual, "A man with a watch knows what time it
is. A man with two watches is never sure." The update is that while
"time epoch" may not be known (or have only arbitrary meaning), 
time interval is a matter of measurement which  is to say good
engineering.
<BR>
<BR>
The job is not done with this discussion of the
clock and time transfer systems. We would like to measure the
time interval between a well defined fiducial point in the
measurement system and the time interval measurement system
in a pulsar backend where PULSAR-TRAK(MASER) is determined.
This can be done by bringing a cable of known (measured)
propagation length directly to the backend. Further specificity
can be obtained by defining rise times of actual 1 PPS pulses
and the point on the rising slope to which time interval
is referred -- both in the clock and time transfer system
and in the pulsar backend.<BR>
<BR>
I leave to another forum the discussion of time transfer
from the pulsar backend to a fiducial point in the telescope
receiving optics. Current understanding is that this is
~7 microseconds which Phil et al. measured by looking
at delay of pulsed calibration signal. Eddy Castro plans
to loop a fiber up and back as soon as splicer arrives
so that a monitoring of the round trip on this path
can be done to see diurnal and cable twist changes.<BR>
<BR>
<h2>Propagation in Earth's Atmosphere</h2>
The zenith delay through the dry part of troposphere is ~7 ns. This
term will increase approximately as sec(ZA); reference:
Sovers, Fanselow & Jacobs (1998 RMP 70 1393) as quoted by
Walker (1999 ASP CS 180 461). To keep known effects under
10 ns it would be appropriate for full sky tracking
telescopes to include a correction for nominal dry troposphere.

The zenith propagation delay through the ionosphere is
~few to ~75 ns at 1 GHz for low Earth longitude; reference
as above and also GPS data for 1998 July 16 at 01:00 from
<A HREF="http://nng.esoc.esa.de/gps/ionplots.html#AN"> GPS TEC0 movie</A>. 
This delay also scales roughly with secant(ZA), has strong diurnal
and solar cycle terms and can be corrected with seemingly
sufficient accuracy via GPS data bases. If a dual frequency
GPS receiver system is installed at Arecibo for stabilization
of absolute linear polarization angle studies, as recommended
during Pulsar Y2K workshop, then this data will be available
locally. The ionospheric scientists (Sixto Gonzalez, Mike Kelly)
are also interested in this dual frequency data.