# NavList:

## A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding

**Re: Historical Lunars : take in account 'delta-T' or ignore it ?**

**From:**Paul Hirose

**Date:**2009 Dec 12, 21:34 -0800

antoine.m.couette{at}club-internet.fr wrote: > -*-*- Second, I am submitting here-after a fictitious example of an upcoming Lunar which shows that - if we were to ignore to-day the effects of delta-T on Lunars - we would significantly increase our error in UT determination, and therefore our Longitude uncertainty. > > 23 Dec 2009 Height of Eye = 17 ' T = 59�F , P = 29.92 ' Estimated UT / Position : 16h58m53.0s / N3707.1W01253.7 - All observations assumed to occur at the same time - Distance SUN-MOON = 77�53'7 , SUNL = 5�50'1 , MOONL = 50�05'0 . All sextant measures are corrected for Instrument error (and only instrument error), i.e. all other corrections (dip, refraction, SD, Parallax ... ) need to be performed from the "raw data" hereabove. Dip = .0667°, therefore lower limb apparent altitude = 5.7683° (Sun) and 50.0166° (Moon). Refraction (Nautical Almanac formula) = .1451° (Sun) and .0138° (Moon). Lower limb observed altitude = 5.6232° (Sun) and 50.0029 (Moon). > *** If we compute observer's position from the observed heights : > > o With delta-T = 66.7 seconds (close to current value for Dec 23, 2009) : That's different from the prediction in IERS Bulletin A (http://maia.usno.navy.mil/ser7/ser7.dat), which says UT1 will be 0.12 s ahead of UTC. Since UTC is 66.184 s behind TT (until the next leap second), predicted ∆T = 66.06 seconds. This is a problem because I want to compare your solution, my solution, and the data from the JPL HORIZONS online calculator. My software gets ∆T from the user, and doesn't know that the value is "wrong". But HORIZONS uses the correct ∆T. You can't simply input a value. Well, not directly. But you can adjust the observer's longitude. HORIZONS doesn't tell you its ∆T [note 1], but let's assume it uses the IERS prediction, 66.06 seconds. We want 66.70. I.e., HORIZONS thinks Earth's rotation is 66.06 slow compared to TT, and we want it to be an additional .64 s slow. Simulate this by moving the observer west by .64 * 15 * 1.002738 arc seconds (= .0027°). The 15 converts time to arc, and 1.002738 is the sidereal / solar time ratio. With the USNO MICA program, the method is even simpler. When you select TT as the input time scale to MICA, it assumes Earth rotates in step with TT, i.e., ∆T = 0. To apply ∆T, you simply move the observer's longitude west by ∆T * 15 * 1.002738 arc seconds. This adjusted value is the longitude with respect to the "ephemeris meridian", which is where the prime meridian would be if ∆T = 0. [note 1] JPL HORIZONS can output the "delta T" for any given time. But this value is *not* TT-UT1. It is TT-UTC, so is constant except that a 1-second jump occurs when there's a leap second. (Actually, this value uses "coordinate time" instead of TT, so there are fluctuations on the order of a millisecond due to relativistic effects.) [end note] To get compatible azimuths and elevations from HORIZONS, MICA, and other programs, control of ∆T is important. It took me a long time to figure out all the above. I hope that info helps someone reduce the size of those annoying little discrepancies when testing positional astronomy software! > Lunar Distance UT = 17h00m00.7s - i.e. TT = 17h01m07.4s - hence UT error = -1m07.7s, cleared distance = 78�34.00', and > We also get the following position at time of Lunar Distance : > N3659.9W01300.3 (result of 2 body fix), and Let's check this with HORIZONS, using the adjusted longitude as explained above. To get Sun apparent azimuth, apparent unrefracted elevation, and angular diameter, put !$$SOF (ssd) JPL/Horizons Execution Control VARLIST EMAIL_ADDR = ' ' COMMAND = 'sun' OBJ_DATA = 'NO' MAKE_EPHEM = 'YES' TABLE_TYPE = 'OBS' CENTER = 'coord' COORD_TYPE = 'GEODETIC' SITE_COORD = '-13.00767,36.99833,0.005' START_TIME = '2009-dec-23 17:01:07.4 tt' STOP_TIME = '2009-dec-23 17:01:08' STEP_SIZE = '1' QUANTITIES = '4,13' APPARENT = 'airless' TIME_DIGITS = 'FRACSEC' !$$EOF++++++++++++++++++++++++++++++++++++++++++++++++++++++ in an email, with the word "job" as the subject, and send to horizons{at}ssd.jpl.nasa.gov . Leave EMAIL_ADDR blank, unless you want to receive the reply in a different email address. The reply should come back in a minute or two. To get Moon data, change 'sun' to '301' (= 3rd planet, 1st satellite). If you use 'moon', you get an error message saying there are lots of moons in the solar system; which one do you want? HORIZONS says Sun azimuth = 234.6738, unrefracted altitude = 5.8953, semidiameter = .2710. Altitude - semidiameter = 5.6243 = unrefracted lower limb altitude. The observed altitude was .0010° (.06') less. HORIZONS says Moon azimuth = 155.5509, unrefracted altitude = 50.2549, semidiameter = .2517. Altitude - semidiameter = 50.0032 = unrefracted lower limb altitude. The observed altitude was .0004° (.02') less. When we apply refraction to the HORIZONS altitudes, we get 6.0350 (Sun center) and 50.2685 (Moon center). The refracted center to center separation angle = 78.4161. Subtract the sum of the semidiameters (.5227) to get the predicted limb to limb angle, 77.8934. The observed angle was 77.8950, .0016° (.10') greater. It would be a little more accurate to use the refracted semidiameters. According to my program, they are .2680 (Sun) and .2517 (Moon, no change ), so the predicted limb to limb angle is 77.8964. The observed angle was .0014 (.08') less. Your solution is an excellent match to the observed angles. Tomorrow I'll use the same method to check your computation with ∆T = 0. -- I filter out messages with attachments or HTML. -- NavList message boards: www.fer3.com/arc Or post by email to: NavList@fer3.com To unsubscribe, email NavList+unsubscribe@fer3.com