KLM/ATN Timing Discrepancy - Along Track Anomaly

The Satellite Operations Control Center discovered a problem that
apparently resulted in the introduction of a 900 millisecond timing
error for both NOAA-15 and 16. This will account for the constant along
track error that is currently corrected at the user level. Exerts from
Peter Phillips message are provided below to fill you in on some of the
details. On August 7, SOCC plans to correct the error and perform a
clock update to remove the 900 milliseconds. At that time we will
update our clock drift file to remove the 1 second corrections that we
have been applying to the NOAA-15 and 16 data. Direct readout users
that are correcting their data should do the same. As soon as the
expected error parameters are received from SOCC, a new clock drift file
will be placed on our web site to reflect the change.
Thanks to SOCC and Pete.

Message dated July 26, 2001 from Peter Phillips:
"In preparation for ordering new frame synchs for the CDAs, yesterday we
started reviewing the present frame synch settings for all data types.
We came across a very interesting discrepancy when we compared the
blocking factor settings for real-time TIP data. For ATN satellites,
PACS sets up the frame synch to collect 5 frames of data before passing
the data over the HDLC interface to the Comm Controller. For KLM
satellites, PACS sets up the frame synch to collect 11 frames.

This difference in these settings is significant because Ground Receive
Time (GRT) is not stamped on the TIP frames until they arrive at the CDA
Comm Controller. GRT is used in the calculation of the spacecraft clock
error, which is the difference between TIP Time and GRT. ...
When calculating the clock error, PACS adds a correction factor to the
TIP Time (same as subtracting from GRT) to account for the delay. This
correction factor is a constant value of 400 milliseconds that does not
vary whether the data is KLM or ATN.

Based on the relatively good correlation between SOCC and CEMSCS
estimates of the spacecraft clock error for ATN satellites, this
correction factor appears reasonable for the ATN blocking factor setting
of 5 frames. However, this correction factor is not adequate for the
KLM setting of 11 frames. Based on frame synch tests performed at SOCC
in 1999, a delay of 150 milliseconds is introduced for every additional
frame of data that is collected in the frame synch. Therefore,
collecting an additional 6 frames will lead to an additional delay in
stamping GRT of approximately 900 milliseconds. This will cause the
SOCC reported spacecraft clock error to be 900 milliseconds less than
the true value for KLM spacecraft.
Because the spacecraft clock error is used as the basis for setting the
spacecraft clock, the net effect of this discrepancy will be that the
clock will be set 900 milliseconds AHEAD of the true value....
This, in turn, would cause the AVHRR imagery to appear to be lagging the
calculated spacecraft position by nearly 1 second, which is the problem
users have seen on KLM spacecraft.

SOCC engineers and operators confirmed this phenomenon today on a
NOAA-15 pass at Fairbanks. As expected, PACS set up the frame synch to
buffer 11 frames of data. The reported TIP clock error was -200
milliseconds. Midway through the pass, the operators changed the buffer
setting to 5. The reported TIP clock error changed to +700
milliseconds. The operators then returned the buffer setting to 11, and
the reported TIP clock error returned to -200 milliseconds. These
results indicate that the "true"
clock error on NOAA-15 is approximately +700 milliseconds, not -200
milliseconds as we have been reporting up to this point.

SOCC engineers will perform a similar test on NOAA-16 Friday morning to
ensure the results are consistent for all operational KLM spacecraft.
If they are consistent, PACS software can be corrected through a PIR to
change the frame synch blocking factor setting to 5 frames for KLM TIP
data, and the spacecraft clocks can be corrected by -900
milliseconds--or whatever amount is necessary to bring the "true" error
to zero--in a coordinated manner between the SOCC engineers and user