Errata/update for the ATBD "Theoretical Basis of the SDP Toolkit Geolocation Package for the ECS Project" by Peter D. Noerdlinger - version 445-TP-002-002 May, 1995.

NEW CORRECTION as of March 10, 1998 (previous errata follow)

In Eq. (6.4-5), p. 6-20, the exponent (3/2) on the Greek xi should be just a power 3 (cube). There is already a square root taken in  Eq.(6.4-3). I am indebted to Dr. Ming Luo of the TES project for this correction.

Furthermore, note that "predicted leap seconds" are no longer supported at all. Furthermore, the leap seconds and UT1/polar motion files now expire in 83 days after the last update, except that the leap seconds file can be used up to 83 days past the last leap second in it as well.  This change is because the U. S. Naval Observatory has advised us that a new leap second could be announced by the IERS with as little as 90 days notice, and USNO could take up to a week to post it.  Toolkit scripts are available to update both files.

Previous Errata:

IMPORTANT CORRECTION TO THE ATBD / WARNING and REQUEST:

Table A-1 on p. A-1 shows "ACTUAL" and "PREDICTED" leap seconds.

 Only the ACTUAL ones are from the U.S. Naval Observatory (USNO). The PREDICTED ones are my sole responsibility and I apologize for implying otherwise. The same pertains to "PREDICTED" leap seconds in later releases of the file "leapsec.dat."

 The "PREDICTED" leap seconds are very crude predictions useful only for simulations, debugging, etc. , as explained in the User Guide. Please do not use them for data production, in permanent software, or in any files that will not be updated as new leap seconds are announced. "Simulations" do not include usage for serious planning.

 We provided with Toolkit 5 a new Leap Seconds File which has the same cautions with it - the PREDICTED leap seconds are not good for anything but testing software. They will surely change. We provided a script and an updating function that must be run on a regular schedule to check for new IERS bulletins to update this file.

 ACTUAL leap seconds are normally announced about 6 months in advance, so it is not difficult to keep actual data processing up-to-date, provided that the script is run.

 Because of our internal use of TAI, a continuous time scale based on atomic time, errors of a second or more could in principle occur by using PREDICTED leap seconds and ignoring the resulting warning message:

"PGSTD_W_PRED_LEAPS"

 in the logfile in $PGSRUN/LogStatus

 I also retract and apologize for the statement in the User Guide that the PREDICTED leap seconds were "originally" from USNO data.

 In fact, in order to permit users to test software with plausible, after-launch dates, I reverse-engineered the "predictions" out of USNO tables of other predicted time differences. Apparently, these tables omit leap second predictions precisely because the estimates, confounded by the variability of the Earth's rotation, are NOT reliable over long periods. It will be a sorry state of affairs if the "PREDICTED" leap seconds propagate outside the environs of testing SDP software, and I earnestly request everyone to prevent that.

 REQUEST:

 Please do not transmit "PREDICTED" leap seconds outside the SDP processing environment and please trap the return value:

 "PGSTD_W_PRED_LEAPS"

 in your software - inhibiting any data production when you encounter it.

GENERAL UPDATES:

- TRMM Attitude

 In general, while the section on the TRMM attitude is correct, the roll and pitch have to be found from horizon sensor readings in early processing. The Toolkit staff are working with TSDIS on this problem. We believe that we can adopt the TSDIS analysis and probably their software for converting the reported "x and y sensor errors" into pitch and roll.

 - Earth Motions/Earth Aspect

 It appears that both the GTDS and TONS systems developed by the Flight Dynamics Division at GSFC, use polynomial approximations to the Earth motion parameters which we carry, using actual Earth rotation measurements, in the data file "utcpole.dat." Thus, GTDS and TONS can use less frequent updates and can carry predictions more simply. Our more frequent updates with actual data will result in more accurate Earth orientation (UT1 - UTC, which gives the Greenwich hour angle, and the smaller correction for polar motion) but this will only be useful in relating celestial bodies to the Earth, given that the spacecraft position will be determined with the polynomial method. In other words, the error in the GTDS and TONS polynomial approximation (which is small) will propagate to the spacecraft ephemeris, so that we would obtain better registration of Earth and spacecraft position if we used the same approximation (in which case there would be a small deterioration of the Earth orientation in J2000 celestial coordinates.) The errors are expected to be well within the spacecraft positional accuracy requirements.

 The nutation algorithm in the Software uses TDB as the time argument, but, after much ado about a small point, it turns out that it should use TDT. The difference in the nutation angle is extremely small (<< 0.001 arc second) so when this is corrected nothing much will happen except the calculation will be slightly faster.


CORRECTIONS:

Page 3-2, equation 3.2-2 should read

a1 = dT*V1

 (error first noticed by Fred Patt of MODIS - also by Bill Boeck of Niagara University/LIS team)

 The actual Toolkit code is correct on this point - the equation was copied wrong into the ATBD.

 p. 4-12, last paragraph: for "UTC - UTC has a sawtooth" read "UT1 - UTC has a sawtooth"

 p. 4-19, the statement at the very end of Section 4-7 that GPS = TAI -19 s was for Toolkit 4; in Toolkit 5 GPS was rebased to its starting epoch; see section 4.4.4.2

 p. 4-21, The equation for GMST near the beginning of Sect. 4.8.2.6 actually defines UT1 from GMST, not vice versa. The equation is correct and this is a difference in principle only.

 p. 6-6, paragraph above Fig. 6-1: the primed Greek phi always denotes geocentric latitude and the unprimed geodetic latitude. The figure is correct but the text just above it has the prime on the wrong one.

 p. 6-22, near the bottom, for "via that arc tangent function" read "via the arc tangent function".

 p. 6-26, Sect. 6.4.4.4. The material is correct, but was written when Toolkit 4 was in effect. Thus the words "current Toolkit" refer to TK 4.

 Unfortunately, in both TK4 and TK5, in the User Guide and in the prolog to the Zenith Azimuth tool, the change in Zenith angle due to refraction is incorrectly called an "increase". The ATBD and the actual calculation in the code are correct - it is, of course, a decrease; refraction makes the zenith angle at the Earth's surface less than in space. The positive number returned is this decrease.

 p. 6-39, Table 6-4. The geocentric latitude phi', not the geodetic latitude, phi should be used in this calculation of the displacement of the look point in longitude. These equations are anyway not in the Toolkit code - they are included just for the reader's convenience. The error in using phi would be inconsequential anyway, because the overall correction is small and approximate. (It is approximate because of variations in the atmosphere and because of the sensitivity of the correction to wavelength, which has been ignored.)


  • No labels