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: Working lunars from calculated altitudes.
    From: Arthur Pearson
    Date: 2002 Mar 29, 23:16 -0500

    George et. al.
    
    This is a very helpful example. As I followed it along, I wondered how
    important it would actually be to iteratively correct one's position
    along with the time to converge on a more accurate GMT. The first
    iteration of time improves the estimate of GMT about 25 minutes or
    roughly half an hour. In a sailing vessel underway at 6 or 7 knots,
    one's estimate of position would only change about 3 or 4 miles as a
    result of that improved estimate of time. I took my most recent set of
    distances and varied my position first by about 5 miles of latitude,
    then separately by about 5 miles of longitude. Each time, I recalculated
    the altitudes, re-cleared the distance, and re-estimated GMT. In both
    cases, the resulting change to the estimate of GMT was less than 10
    seconds.  It would seem that in practice on a sailing vessel,
    uncertainty in position would have a much less significant impact on the
    use of calculated altitudes than uncertainty in time. It makes the
    calculated altitude technique a bit more plausible from a distance. I am
    curious what history tells us about whether it was in fact employed by
    professional seamen in the age of sail.
    
    Thanks for this example and discussion,
    
    Regards,
    Arthur
    
    
    
    -----Original Message-----
    From: Navigation Mailing List
    [mailto:NAVIGATION-L{at}LISTSERV.WEBKAHUNA.COM] On Behalf Of George
    Huxtable
    Sent: Friday, March 29, 2002 7:11 PM
    To: NAVIGATION-L{at}LISTSERV.WEBKAHUNA.COM
    Subject: Working lunars from calculated altitudes.
    
    Working lunars from calculated altitudes.
    
    When working a measured lunar distance to obtain a value for GMT, an
    important factor to be taken into account is the altitude of the two
    bodies
    involved: particulaly that of the Moon, because the lunar distance is so
    greatly affected by the Moon's parallax.
    
    The traditional approach involves measuring the altitudes at
    (effectively)
    the same instant as the measure of lunar distance was made. That is a
    (relatively) straightforward matter that has been dealt with before, and
    will not be considered here.
    
    However, from the early days of lunars, it has been accepted that such a
    measurement of the altitudes may be difficult or even impossoble,
    because
    the horizon can not be clearly seen. It has been regarded as an
    acceptable
    substitute to calculate the altitudes at that instant instead of
    measuring
    them, based on the predicted positions in the nautical almanac. That
    procedure, and its complications, is what this posting is about.
    
    Two difficulties arise here. The navigator needs to know the GMT in
    order
    to look up the predicted positions of the bodies in the almanac, but he
    doesn't yet know the value of GMT, as that is what he is trying to
    obtain.
    And the altitude he calculates will be affected by his position on the
    Earth's surface, latitude and longitude. Though a navigator may well
    have a
    good idea of his latitude from a recent meridian altitude of the Sun,
    his
    longitude is in the end what he is trying to obtain from a knowledge of
    GMT, so at the start this is unknown.
    
    The reverse process is much simpler. If an observer happens to know
    exactly
    where he is on the Earth, and what is the GMT (perhaps from GPS) then he
    can work out exactly what the altitudes will be at the moment of
    measuring
    a lunar distance, without measuring them. He can then use these values
    to
    correct (clear) the lunar distances, and from that obtain a value for
    GMT
    which should correspond with what the GPS has told him. This is a
    circular
    process: it has its value in indicating how well the observer is making
    and
    correcting his measurements, but it is not a way of finding position.
    This
    is what Bruce Stark has done in his Pollux-lunar measurements made on
    March
    26 (local date).
    
    In general, a navigator using lunars will not have such a foreknowledge
    of
    the time and position for his lunar-distance observation (if he did, why
    would he be bothering with lunars?). Instead, he can only make an
    informed
    guess at these quantities at the moment of his lunar measurement. If he
    then works his lunar, calculating the altitudes on that basis, he should
    arrive at a more precise value for the time. Based on that time he can
    make
    a better estimate of his position. With those new values he can repeat
    the
    calculation. And so on.
    
    If the result of a lunar measurement depended only slightly on the
    altitudes, then an initial rough guess would suffice for the GMT and the
    position, which would then allow more accurate values to be obtained
    from
    the lunar. But because the correction to a lunar as a result of Moon
    parallax can be so great in certain circumstances, the convergence of
    such
    a process may be very slow, and many iterations may be needed before a
    precise result is obtained for GMT.
    
    I am grateful to Bruce for copying his observations to us, and will use
    them to illustrate this point: just his first set-of-five lunar
    distances.
    
    His GPS position is N44*00.9, W123*04.1
    
    Corrected for index error, lunar distances average 35*34.0 at a GMT of
    04:45:38 on 26 March 02.
    
    At that moment, from that position, if the altitude of the Moon had been
    observed it would have been 57*07.6, according to calculations from the
    almanac, and Pollux would have been 69* 46.9. (these values weren't
    given
    by Bruce, they are my workings)
    
    Cleared lunar distance is 35*24.4 or 35.4067*
    
    At 04:00 GMT the calculated lunar distance was 34*56.4 or 34.9400*
    At 05:00 GMT the calculated lunar distance was 35*33.5 or 35.5583*
    
    By linear interpolation, this gives a GMT for the lunar distance
    observations as 04:45:17, just 21 sec slow of GPS: a remarkably good
    result. My answers may diverge slightly from Bruce's as a result of a
    different calculation method, but effectively we agree.
    
    All I have done so far is to restate Bruce's first set of results.
    
    But now, take those same observations, and pretend that they were timed
    with a clock with an error, instead of by GPS. Let us presume that in
    fact
    that clock was 30 minutes fast on GPS, although this was not known to
    the
    observer.
    
    His observations of lunar distance would be exactly the same averaging
    39*34.0, but the indicated time would now be 30 min ahead, at 05:15:38
    by
    that clock.
    
    The navigator now has to use that time (he knows no other) to compute
    the
    altitudes of the Moon at 59*51.1 and of Pollux at 65*38.6. Note how much
    these differ from the altitudes calculated earlier, because of the
    half-hour time difference.
    
    Cleared lunar distance is now 35*29.3 or 35.488*
    
    The calculated lunar distances at 04:00 and 05:00 are just the same as
    before, unaffected by our clock error.
    
    Linear interpolation now gives a GMT for the lunar distance measurement
    at
    04:53:12., which is 7 min 34 sec ahead of GMT. What we can say is that
    an
    initial error in timimg of 30 minutes has resulted in a time error of 7
    min
    34 sec, which is about a quarter of the initial value. Other geometries
    of
    Moon and other-body in the sky will result in a different ratio, which
    is
    hard to predict, but even in the worst-case I don't think this factor
    can
    exceed one-half.
    
    We could use our result to correct the clock, which would reduce its
    error,
    but it would still be out by 7 min 34 sec, though the navigator would
    not
    be aware of that figure. With this new time, the altitudes can be
    recalculated, and the whole process can be reiterated, which would
    again,
    presumably, reduce the error by another factor of 4, to just less than
    two
    minutes. Next time, half a minute. The navigator will be aware of these
    steps getting smaller each time, which would advise him when to bring
    the
    proceedings to a halt.
    
    It's clear that this long-winded reiteration process does not lend
    itself
    to hand-calculation, though a computer would do it in a twinkle.
    
    If anyone (and here I am thinking particularly of Bruce Stark) can
    suggest
    a way around this problem, I would be pleased to hear about it.
    Otherwise,
    lunar navigators should avoid calculating their altitudes and stick to
    measuring them, unless they have the resources of a computer behind
    them.
    
    George Huxtable.
    
    
    
    
    ------------------------------
    
    george---.u-net.com
    George Huxtable, 1 Sandy Lane, Southmoor, Abingdon, Oxon OX13 5HX, UK.
    Tel. 01865 820222 or (int.) +44 1865 820222.
    ------------------------------
    
    
    

       
    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