# NavList:

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

### Compose Your Message

Message:αβγ
Message:abc
 Add Images & Files Posting Code: Name: Email:
Re: Captain Cook's Sep 07th, 1773 Lunar revisited
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.

```
Browse Files

Drop Files

### Join NavList

 Name: (please, no nicknames or handles) Email:
 Do you want to receive all group messages by email? Yes No
You can also join by posting. Your first on-topic post automatically makes you a member.

### Posting Code

Enter the email address associated with your NavList messages. Your posting code will be emailed to you immediately.
 Email:

### Email Settings

 Posting Code:

### Custom Index

 Subject: Author: Start date: (yyyymm dd) End date: (yyyymm dd)