Welcome to the NavList Message Boards.

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
    or...
       
    Reply
    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.
    
    
    
    

       
    Reply
    Browse Files

    Drop Files

    NavList

    What is NavList?

    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)

    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site