From clark@aleph.gsfc.nasa.gov Thu Feb 8 16:33:38 EST 2001 Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4.email.verio.net [129.250.36.44]) by leo.gsfc.nasa.gov (8.9.3/8.9.3) with ESMTP id QAA04176 for ; Thu, 8 Feb 2001 16:33:37 -0500 (EST) Received: from [129.250.38.61] (helo=dfw-mmp1.email.verio.net) by dfw-smtpout4.email.verio.net with esmtp id 14Qyh5-0005Ut-00; Thu, 08 Feb 2001 21:33:35 +0000 Received: from [128.183.106.247] (helo=tomcat.gsfc.nasa.gov) by dfw-mmp1.email.verio.net with asmtp (011318477) id 14Qyh4-0002qA-00; Thu, 08 Feb 2001 21:33:34 +0000 Message-ID: <3A8310AB.C2E5C543@tomcat.gsfc.nasa.gov> Date: Thu, 08 Feb 2001 21:33:31 +0000 From: Dr Thomas A Clark Organization: NASA/GSFC X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Brian Corey , Leonid Petrov CC: aen@dopey.haystack.edu, alan.whitney@ivscc.gsfc.nasa.gov, cjl@haystack.mit.edu, clark@aleph.gsfc.nasa.gov, cwalker@aoc.nrao.edu, hase@wettzell.ifag.de, rjc@haystack.mit.edu Subject: Re: Time and VLBI References: <200102081800.NAA23104@planck.haystack.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: R Brian Corey wrote: > [snip] > Conceptually it's probably reasonable to describe the situation this way > (although I'd feel more comfortable saying it's OK if I knew where this > conversation was going to end up!), but literally? No, that's not how > it's done. The time tag is not memorized and there is no sample counter > that gets reset. In the Mk4 formatter, for instance, the sample clock, > which always runs at 32 MHz (lower sample rates are supported by > decimating the data), does not get reset when the formatter is synced > to the maser 1 pps. So the sample epoch may deviate from perfect > synchronization with the maser 1pps by +-1/64 us (or something like > that -- I may be off by a factor of 2). The sample clock *is* > synchronized to the maser 5 MHz, and all the other formatter signals > (e.g., beginning of frame, internal 1pps, time code) are in turn synced > to the sample clock. > > But does any of this matter??!! No matter how the formatter signals are > generated, what ultimately matters is the GPS-FMT time interval > measurement. If the maser 1pps is off by 1 ms, the synchronization may > work perfectly, but the time code on tape will be wrong by 1 ms. These ambiguities are why I prescribe that the timing be defined in two steps -- Maser-to-GPS and Maser-to-formatter. GPS (with some corrections that I can call it UTC(GPS) but some purists become angry when I do!) can be though of an approximation to UTC(USNO), which in turn is an approximate realization of UTC(BIPM). UTC(USNO) really only exists on paper and represent an analytic average, smoothed in the time domain, of many different clocks. Time transfer measurements link the clocks in many countries (heavily weighted towards USNO) to form UTC(BIPM). The USNO supplies daily corrections to the GPS satellite controllers indicating the actual performance of each satellite's clock and this data is included in the data message sent by each GPS satellite. Even when these corrections are applied, the GPS constellation still has a small error of +/- 15 nsec. This error is posted (one day later) on the USNO web site with a 2 day averaging window (I have collected all this data since 2000.0) and it is furnished as a prediction (only past, but no future data included) to the GPS controllers who broadcast this number also. Over year 2000, the range of differences between UTC(GPS with ex post fact corrections) and UTC(GPS with real-time corrections applied) was +/- 4 nsec. The daily ionosphere corrupts the single frequency timing receivers by ~+/- 10 nsec. So depending on how we define the measurements, we achieve a precision after ~1 day in the 10-20 nsec range. But to measure this with a precision (and I hope that the accuracy is close to this), the timing must be averaged. Therefore in each station we form another "paper" clock that represents the difference between the maser, running as a very smooth flywheel, and GPS transferring time from USNO. This is important in the current discussion because a single 1PPS pulse (which could come from either GPS or the a counter/clock driven by the maser) is used to set the formatter clock. From that time forward, unless there is a glitch (noise, power failure or whatever), the formatter clock is locked to the the 200 nsec transitions of the maser. Therefore, my view of how the stations should maintain their clocks is that long-term observations between the best local clock (the maser) and the best external clock (USNO via GPS) be made with a dedicated instrument. With this approach, the offset and rate of UTC(USNO) minus UTC(maser, locally in the station) is well defined. This is what I have tried to provide with the TAC, the dedicated time-interval counter (TIC) and full-time PC for logging. When a VLBI experiment is running, this time knowledge is transferred to the formatter and the MASER-FMT data is logged by the field system. In all these discussions we must also realize that the formatter only provides the timing within the single bandwidth of each video converter. Since the widest channel bandwidth we use now is 16 MHz (a period of ~60 nsec), the single channel delays are only defined at the ~10 nsec level. And thermal gradients within the MkIV rack can cause the group delays associated with the single channels to drift at levels of tens of nsec. Of course the way we solve this problem over a wide synthesized bandwidth is to inject phase cal pulses at a rate of 1/usec (1 MHz rate). It is this "clock" that time-tags the incoming photons over the full receiver bandwidth. It is derived from every 5th zero-crossing of the 5 MHz maser signal in the receiver feed (which is hundreds of meters from the maser). In our current systems, we don't know which of the 5 MHz zero-crossings made the pulse, so we have a 200 nsec ambiguity built into the system. Since the 1/usec pulse generator is in the receiver, the phase cal system measures the CHANGE in the length of the cables (but not their actual length). The photons, mized with the phase cal pulses, come down to the MkIV and Maser thru another few hundred meters of cable, so the time tag that gets applied by the formatter is late by several usec. We solve for a clock offset/rate but we then throw this away as a nuisance parameter. I recall that it took me about 5 years to convince Jim Ryan that these "DC" offsets in the definition of UTC at each station actually had an effect on our determinations of UT1. We have always relied on hope and faith that the cable calibrator removes changes in the phase cal pulse, and we have trusted that the other delays are constant. We attempt to fit the data to ~10 psec when we don't really know the constant biases to at the usec level! A few years ago I proposed a system that would help to tie the single-band delays to the wide-band delays which would also allow us to remove the "DC Bias" errors. Alas, there has never been enough NASA $$$ to try out the ideas. ;<{ You had also asked about Sagnac effect on the GPS timing. I am certainly not an expert in the subtile effects of GenRel! But it appears that the DoD, when they defined the GPS system, took this into account. The GPS satellite orbits are defined in an Earth-centered coordinate frame by conventional Keplerian elements. When the user gets a GPS pseudo-range he has to apply a "retarded baseline" velocity correction to account for the rotation of the earth in this reference frame. In the formalism that describes the equations to be used for this transformation DoD specified all the needed terms. The ground-based tracking stations that the DoD operates apply these equations to generate the Keplerian elements that are delivered to the user (on the GPS signals). The firmware in the user's receiver is then supposed to re-apply all the corrections in a consistent manner for navigation. We know that even the simplest of these receivers delivers positions consistent at the few meter level (since SA was turned off). Since the satellites in the east vs. satellites in the west sagnac difference is ~100 nsec, a few meter-level performance from a $100 receiver would not be possible unless the vendor was applying the correction properly. Pardon my rambling -- Tom