PDS_VERSION          = PDS3
RECORD_TYPE          = STREAM
OBJECT               = TEXT
PUBLICATION_DATE       = 1997-02-21
NOTE                   = "MGS RST Instrument Health Report HEA7052B.TXT"
END_OBJECT           = TEXT
END


Open Loop Data
==============

  Data Anomalies
  --------------

     We reported earlier today that our quick-look processing of the GWE
open-loop data failed for unknown reasons.  Joe and I have been working on
this.

     The ODS file is riddled with out-of-order POCA time tags and values.  We
processed approximately 4300 records before our parsing program went into an
infinite loop.  That represented about 10 percent (or 40 minutes) of the 6.5
hrs of data collected.  During those 40 minutes there were at least two
dozen instances in which pairs of POCA time tags were out of order.  That is,
if record N1 with time tag T1 contained POCA time tag P1 and record N2=N1+1
at T2>T1 had POCA time tag P2, then P1>P2.  This summary from 19 records
(441 through 459 inclusive) illustrates the problem (we have omitted redundant
entries from even-numbered records on the half-second):

441 POCA Rdbk Freq (Hz): 43416630.006980  POCA Rdbk Time Tag (msec): 74200000
443 POCA Rdbk Freq (Hz): 43416629.930050  POCA Rdbk Time Tag (msec): 74201000
445 POCA Rdbk Freq (Hz): 43416629.853120  POCA Rdbk Time Tag (msec): 74202000
447 POCA Rdbk Freq (Hz): 43416629.776190  POCA Rdbk Time Tag (msec): 74203000
449 POCA Rdbk Freq (Hz): 43416629.545400  POCA Rdbk Time Tag (msec): 74206000
451 POCA Rdbk Freq (Hz): 43416629.622330  POCA Rdbk Time Tag (msec): 74205000
453 POCA Rdbk Freq (Hz): 43416629.545400  POCA Rdbk Time Tag (msec): 74206000
455 POCA Rdbk Freq (Hz): 43416629.314610  POCA Rdbk Time Tag (msec): 74209000
457 POCA Rdbk Freq (Hz): 43416629.391540  POCA Rdbk Time Tag (msec): 74208000
459 POCA Rdbk Freq (Hz): 43416629.314610  POCA Rdbk Time Tag (msec): 74209000

Note that the POCA readings for 74204000 and 74207000 are missing entirely,
that the POCA readings at 74206000 and 74209000 are repeated, and that the
POCA readings for 74205000 and 74208000 follow later readings.

	Our software assumes that the condition P1>P2 means we have crossed
midnight, and the program adds 86400000 milliseconds to the time tag value.
Twenty-four such increments yield a number just shy of 2**31 - 1, at which
point a positive 32-bit signed integer wraps to negative values.  Once the
new POCA time appears to be a negative number, our program will loop
indefinitely trying to find a time tag larger than 2**31 - 1 by adding
86400000 forever.

	There are several solutions to this problem, including:

	    (1) We can develop a more sophisticated midnight-crossing
          correction -- perhaps by looking for precisely the jump from 86399
          seconds to 0 seconds.  But that assumes the POCA values will be
          well-behaved around midnight crossings.  Our GWE experience is
          that approximately one POCA time tag transition in 200 is
          negative (24 errors in 40 minutes with 2 records per second); and
          this ignores other possible errors which we have been seeing in
          both time tags and POCA values.  We have adopted this approach,
          but with a tolerance of SEVERAL seconds; we expect an occasional
          failure, but are hoping these will be rare.

	    (2) We can fix the ordering of POCA time tags and values at
          the source.

	We are puzzled that these errors are occuring at the LOWEST sampling
rate possible with the DSP.  If there were a synchronization problem, we would
expect that to be most apparent at high sampling rates.  The complete LOSS of
POCA information at some times is almost as puzzling as the randomization of
the ordering.