Data Analysis

With the serial crashing problem fixed (apparently) by the end of the day Friday - big sigh of relief from Mike - I spent a few hours this weekend analyzing (in Excel) the Copy(11)First60K data file that Gordon prepared last week. I obtained some interesting results. Some notes:

• After PPM counter value 3183, there was a glitch where the PPM counter value rolled straight over to 3185 (skipping 3184) even though only 1 second had passed according to the OCXO counter as well as the PC clock. I decided there must have been a spurious PPM event, so I just adjusted all the subsequent PPM counter values down by 1 second. However, we should look back at the raw data file to see if we can piece together what happened in more detail.
  
  
• There are still occasional temporary glitches in the counter value. Some of these are correlated with TRAIM alarms, so may represent temporary phase shifts in the GPS unit's internal clock, as opposed to say timing problems in our counter register latching. But not all of the glitches are obviously ascribable to this.
  
  
• After initial warm-up of the OCXO, during the 1st 8 hours, there were a number of points at which the relative frequencies shifted slightly. It is not yet certain whether this was due to adjustments of the OCXO frequency (e.g., due to environmental temperature variations), or due to adjustments of the frequency of the clock internal to the GPS unit to track changes in the idea of the current time inferred from the satellite data. However, the magnitude of the frequency variations seen after warm-up (based on average frequencies measured over 10-minute windows) is within only about +/- 0.01 Hz of the long-term mean (see plot below). Given the 10 MHz base OCXO clock frequency, this amounts to 1 ppb variation - even less than the OCXO's specified frequency stability figure. The timescale of these variations is about 8 minutes (500 secs) or so. Or, another way to look at it is this: Between two different 600-second windows, the number of 100-ns OCXO pulses seen can vary by about +/- 5 or 1/2 microseconds' worth. Or, with the 1 ppb variation, we can lose or gain about 1 ns per sec by just using the OCXO clock when the GPS is unavailable. In a minute, we could gain or lose 60 ns. In an hour, we could gain or lose 3.6 microseconds, or 3,600 feet of positional accuracy. Thus, we should probably not rely on the OCXO clock for periods of more than about an hour or so when the GPS is not available. But shorter outages we can interpolate over effectively.
  
  
  
  
  
• Between about 45,780 and 58,300 seconds, there was a period where the relative clock frequencies suddenly shifted, the phases drifted apart for a while, then the relative frequencies suddenly went back to normal, but with the phases off by about 450 cycles or so (45 microseconds) then the relative phase suddenly snapped back to about where it would have been if the anomaly had not occurred (see plot below). Looking at the data, the period when the phases were off coincided with a period in which time lock had presumably been lost, because the self-reported TRAIM accuracy was zero. The phase snapped back when the GPS lock was re-acquired. This indicates that this phase drift was due to phase drift of the GPS unit's internal clock, rather than to OCXO frequency drift. In other words, during this approximately 3.5-hour long interval, more accurate times could have been obtained by extrapolating based on the calibrated OCXO frequency, than by using the PPS pulses from the GPS. If the OCXO alone was used during this period, accuracies would have been within a few microseconds, certainly less than 10. Whereas, during this period, the PPS times were off around 500 cycles (50 microseconds).