NavList:

   

Reply

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.

-- 

   

Reply