Timing system design and tests for the Gravity Probe B relativity mission

Abstract

In this paper, we discuss the timing system design and tests for the NASA/Stanford Gravity Probe B (GP-B) relativity mission. The primary clock of GP-B, called the 16fo clock, was an oven-controlled crystal oscillator that produced a 16.368 MHz master frequency. The 16fo clock and the 10 Hz data strobe, which was divided down from the 16fo clock, provided clock signals to all GP-B components and synchronized the data collection, transmission, and processing. The sampled data of science signals were stamped with the vehicle time, a counter of the 10 Hz data strobe. The time latency between the time of data sampling and the stamped vehicle time was compensated in the ground data processing. Two redundant global positioning system receivers onboard the GP-B satellite supplied an external reference for time transfer between the vehicle time and coordinated universal time (UTC), and the time conversion was established in the ground preprocessing of the telemetry timing data. The space flight operation showed that the error of time conversion between the vehicle time and UTC was less than 2 μs. Considering that the constant timing offsets were compensated in the ground processing of the GP-B science data, the time latency between the effective sampling time of GP-B science signals and the stamped vehicle time was verified to within 1 ms in the ground tests.

Gravity Probe B data analysis: II. Science data and their handling prior to the final analysis

“…It takes a time sequence of L1 values for some specified monitor(s), processes them as described below, and outputs the corresponding set of L2 data to the L2 DB for permanent storage. This operation has a three-fold aim, namely: (1) preliminary data cleaning; (2) data compression (for signals with sampling rates above 0.5 Hz) or interpolation (for signals with sampling rates below 0.5 Hz); (3) time stamp correction and data synchronization (all L2 data points correspond to the same moments of vehicle time separated by 2 s intervals, namely, a data point at each twentieth 10 Hz strobe [7,15]). …”

“…The latter usually differed significantly due to time delays in the onboard circuitry. So first the time step of each L1 data point was corrected, and then a single L2 data point at a predetermined moment of vehicle time was derived from a number of neighboring L1 data points (see more on preprocessing below in 3.2.2-3.2.5; GP-B timing is thoroughly described in a special paper [15]). Additional issues with timing were fixed in the timing data preprocessing, see sections 3.2.3, 3.2.4.…”

“…The GP-B timing system is described in detail in a separate paper [15] included in this issue. Here we give only a pertinent brief survey of timing data handling with emphasis on preprocessing of timing signals.…”

“…The GP-B timing requirements given in [15] contained the top level requirement, namely, that the effective sampling time of all science signals should be known relative to UTC with the accuracy of better than 0.1 ms, after ground preprocessing. It is important to note that the known constant timing offsets were compensated for in the ground processing of GP-B science data.…”

“…As shown in figures 5 and 6, preprocessing the GP-B timing data was implemented in two programs: one determined the GPS time of 10 Hz data strobes, and the other determined the vehicle, or oscillator, time of GPS solutions. The oscillator time was derived from the 31 bit counter of the 16fo clock (see [15] for the definition), and it was equal to the vehicle time at the 10 Hz data strobes; therefore it was identical to the vehicle time to within 1/(16,368,000) part of a second.…”