Defects Index | Documentation Table of Contents
98/09/03 DEFECT in EDITDB
SYMPTOM: Good data was showing a large satellite a priori rms and causing
good data or good baselines to be eliminated.
PROBLEM: A rare cycle slip correction, rather than a break, was made to a
satellite before it became a reference satellite and the correction
was not applied correctly across the scenario boundary.
CORRECTION: The cycle slip correction is now applied to ensure continuity
for current and previous reference satellites across the scenario
boundary.
FOUND BY: Steve Hilla 98/09/01
FIXED BY: Gerry Mader 98/09/03
VERSION: 98/09/03
SOURCE: /g1/HPUX.09/Src/Editdb
/g1/HPUX.10/Src/Editdb
EXECUTABLE: /g1/HPUX.09/Bin
/g1/HPUX.10/Bin
NOTES: Uncorrected breaks in the data, whether they result from an
error in EDITDB or in how EDITDB is being used, are disastrous
for the operational orbit/cors processing. For about the past
year EDITDB has computed statistics on the amount of data being
deleted as well as a total a priori RMS and individual satellite
RMS's. The intention was to use these a priori RMS's to remove
either individual satellites or entire databases that passed
through the editor and still had faulty data. run_survey now
has the optional capability to check the total percentage of
data verses expectations, the percentage of data deletioned
verses the total, and the a priori RMS from EDITDB to eliminate
from databases from then combined solutions. The above
version of EDITDB now uses its information on individual
satellite RMS's to write an edit instruction to kill all the
remaining data for any satellite whose a priori RMS (after all the
editing is completed) exceeds a certain limit. This satellite(s)
is then removed from the computation of the total RMS. These
satellites may be found (if present) at the end of the xxxx00.edt
files and are identified by the comment "exceeds RMSmx". EDITDB
uses an a priori RMS limit of 100m internally to initiate this
kill command. The user may change this limit by entering a new
limit as the 9th number in the EDITDB.PAR file or in the first
line of the EDITDB.INP file. Currently the rightmost (8th) entry
in these lines is an integer 0. If you want to change this limit
based on familiarity with your particular data, enter your limit
to the right of this integer 0. If you make no change to these
lines, that's ok, the editor will use its internal value to detect
outlying satellites. Hopefully, the proper use of this feature
will cause offending satellites to be eliminated before combined,
network solutions.
980903.editdb
June 25, 1999
Steve Hilla