A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding
Re: Captain Cook's Sep 07th, 1773 Lunar revisited
From: Paul Hirose
Date: 2012 Jul 25, 23:25 -0700
From: Paul Hirose
Date: 2012 Jul 25, 23:25 -0700
Antoine Couëtte wrote: > As indicated earlier, I have reworked Cook's Lunar from a "reasonable" position both not too far from Ohamaneno harbor, and from which the Sun and Moon Azimuths are not land blocked. > > From (a just slightly revised) position S16°44'W151°35'0, and with all other elements as follows : > > HOE = 15.5 ft T = 77.5°F , on Sep 07th, 1773, with TT-UT = + 16.4s and > > a limb to limb sextant measure of 105°47'04" as a result of 10 measures, (whilst the recorded heights SUN LL = 12°38'24" , MOON UL = 43°29'00" are NOT being used to derive the following results because the position is forced into S16°44'W151°35'0) > > .. we can compute that this Lunar was observed at a time very close from UT = 17h06m58s1 on the 07th of September 1773, with such found date and time being reckoned in our modern acceptance. With that data my computed lunar distance is only .00008° greater than the observation. A +1.1 s correction to time makes them equal (at 17:06:59.2 UT1). However, a real navigator would use a "time sight" to determine time from a known position. It's more accurate because altitude changes faster than lunar distance (-.0044°/min) - in this case, 40 (Moon) and 53 (Sun) times faster! At the time I determined from the lunar distance (17:06:59.2), and at the position quoted above, the altitude intercepts (observed - computed) and altitude rates (°/min) are: +.5630° -.175 Moon -.5088° +.236 Sun From those figures we can estimate when the observed altitudes occurred. Then refine the times by trial and error to get the time sight results: 17:03:45.2 Moon altitude 17:04:49.7 Sun altitude 17:06:59.2 lunar distance But remember, a time sight was not possible for Cook because he didn't have an accurate position. He had to follow the classic lunar distance procedure, which brings us to my solution with time and position adjusted: 1773-09-07 17:05:54.8 UT1 -16.5108° -151.8963° new position -16.7333° -151.5833° old position ------------------- +.2225° +.3130 position difference At that time and place, the predicted altitudes equal the observations. Therefore, the parallax and refraction influences on lunar distance are accurately re-created. This is the equivalent "clearing" the lunar in a traditional solution. Then we adjust time so the predicted lunar distance equals the observation. Of course the predicted altitudes change as soon as you change the time, so the algorithm is iterative. It repeatedly solves a set of linear equations, under the assumption that the predicted altitudes and lunar distance respond linearly to a change in time, latitude, or longitude. This is true enough that the solution converged to better than .0001° after three iterations. A position calculated this way is merely a tool to compensate for parallax and refraction. It's not necessarily a strong fix. One reason is that the solution is relatively insensitive to the altitudes, so they are not always taken with great care. Also, the LOPs may not have a good crossing angle. Finally, the observations may not be virtually simultaneous, as they should be. That last may be a factor in this case, based on the time sights and the large position change in the solution. Let us assume the time sights I calculated above are the actual times of the observations. Then, with the data already given, adjust the altitudes to the time of the lunar distance observation (17:06:59.2): 43.4194° observed Moon altitude at 17:03:45.2 -.5658 corr. = 3.233m * -.175°/m ------- 42.8536 estimated Moon altitude at 17:06:59.2 12.5761° observed Sun altitude at 17:04:49.7 +.5094 corr. = 2.158m * +.236°/m ------- 13.0855 estimated Sun altitude at 17:06:59.2 With the new "observed" altitudes, and the same lunar distance, again allow the program to adjust time and position until the computed angles match the observations. Results: 17:06:59.7 new "cleared" solution (UT1) 17:05:54.8 old solution ---------- 1:04.9 difference -16.7342° -151.5818° new position -16.7333° -151.5833° assumed position -------------------- -.0009° +.0015° difference Now my program puts the observer only .1 NM from Kermit's "just slightly revised" position. I'm not sure that proves anything except that I did a good job adjusting the observed altitudes. The new altitudes affect the time solution by 65 s, equivalent to .29' error in lunar distance. That's the effect of shooting altitudes 2 and 3 minutes before the mid time of the 10 lunars. In an earlier post I said such a procedure would be "dumb". Perhaps that was a harsh word to apply to observers from my position 240 years and thousands of miles away. The evidence is circumstantial. But if they really did that, their methodology was at least sub-optimal. A simple modification would practically eliminate the systematic error. Just observe Sun altitude, Moon altitude, 10 lunars, Moon altitude, Sun altitude. Take the mean of the altitudes and lunars. For the deluxe procedure, record the chronometer time of each altitude, and the times of the first and last lunar. > Given the technical difficulty of correctly "catching/matching" both SUN and MOON Limbs since they had to hold their sextant more or less horizontal for this Lunar, we can certainly understand that - despite the fact that they did increase the number of their distances sightings to 10 measures (the biggest number recorded on that page) - their final Lunar distance could NOT be as accurate as their otherwise excellent Latitude determinations from Sun Heights with their best Octants. The position angle from Moon to Sun was 306° relative to the zenith, i.e., the Sun was at 2 o'clock relative to the Moon. That's not bad. A 90° PA would be worse. In that case I think you'd have to hold the sextant by the frame, not the handle. (The "sense" of position angle is the same as azimuth. It seems reversed because the point of view is on the inside of the celestial sphere.) I have been thinking of releasing my lunar program as a free app for Windows machines. Originally I never had that in mind. It was designed as an "in house" utility so I could make my own computations when lunars were discussed online. Over the years I added more features, so now it's probably unusable by anyone but me. But its algorithms are modern and rigorous, including the latest JPL ephemerides and IAU precession / nutation models. A lunar distance program is best written by a lunars enthusiast. That's not me. Nevertheless, I think my program would be useful if I gave it a decent user interface. If that happens, it will be after I release the next version of my astronomy DLL, now in work. Don't hold your breath. -- I filter out messages with attachments or HTML.