I just noticed that http://spaceflight.nasa.gov/realdata/sightings/SSapplications/Post/JavaSSOP/orbit/ISS/SVPOST.html gives deltaT (as "Ephemeris Time" or Universal Time - UTC = 64.18) as well as UT1 - UTC, which it gives as 0.00 sec. ISS TRAJECTORY DATA Lift off time (UTC) : N/A Area (sq ft) : 3000.0 Drag Coefficient (Cd) : 2.35 Monthly MSFC 50% solar flux (F10.7-jansky) : 111.5 Monthly MSFC 50% earth geomagnetic index (Kp) : 3.53 ET - UTC (sec) : 64.18 UT1 - UTC (sec) : 0.00 The actual current value for UT1 - UTC is about -0.47: http://maia.usno.navy.mil/eo/ http://hpiers.obspm.fr/eop-pc/index.html If the TLEs are generated based upon an assumption of UT1 - UTC = 0, then it may be a mistake to attempt to "correct" for the difference, when computing a ground or sky track. Contrary to an earlier post, I in fact do apply deltaT in my computation of the positions of the planets, etc. Also, last night I switched from the WGS72 constants in my Java translation of the ancient SGP4 FORTRAN (URGENT ASSISTANCE NEEDED...) code to WGS84 constants. Although I didn't do a character by character comparison, the transit reports I generated for myself appeared identical. I give latitude & longitude to 4 decimal places, which works out to a resolution of about 10 meters. The WGS84 ellipsoid increases the Earth's radius by 2 meters, relative to the WGS72 ellipsoid, and increases the polar radius by about 1.8 meters, so in fact there's very little difference between the two. I can't find any Geoid height code written in a MODERN (i.e., readable) language, so in order to adjust GTOPO30/SRTM30 MSL elevations to elevations above the WGS84 ellipsoid, I'm probably going to have to translate some more FORTRAN code: http://earth-info.nga.mil/GandG/wgsegm/egm96.html ------------------------------------------------------------------------- Subscribe/Unsubscribe info, Frequently Asked Questions, SeeSat-L archive: http://www.satobs.org/seesat/seesatindex.html
This archive was generated by hypermail 2b29 : Thu Jul 01 2004 - 11:18:18 EDT