Welcome to the NavList Message Boards.


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

Compose Your Message

Add Images & Files
    Re: My first Lunar
    From: George Huxtable
    Date: 2008 Sep 23, 09:48 +0100

    Using Frank's lunar calculator, I was puzzled about the discrepancies that 
    showed up, between the deliberate error, of a whole degree, that I had made 
    in the trial longitude, and the calculated longitude error that resulted, 
    stated to be 26' or 27', less than half of that error. Some discrepancy is 
    to be expected, because Frank's calculator simply assumes a nominal rate of 
    motion of the Moon, of 30' per hour, ignoring the vagaries of Moon motion, 
    direction offset, and parallactic retardation. However, what surprised me 
    was that the calculated error was less than half the initial error. Why? It 
    didn't accord with the assessment made by Paul Hirose, in [6293] of the 
    apparent motion of the Moon.
    I had written down the inputs for the analysis :
    "DR Lat 14�  31'  N
    DR Lon 61� 38.1' W
    Body - Jupiter
    January 26 1999
    22 19 30 GMT
    Distance 68� 19.4'  near."
    Frank then pointed out-
    "But you've dropped the measured altitudes. We can talk about the procedures
    and issues when no altitudes are measured, but that wasn't the case here.
    Enter the altitudes as measured. Those, combined with the observed apparent
    lunar distance, imply one and only one geocentric lunar distance and
    therefore one specific value of GMT. So you do that part first: adjust GMT
    until the error in the lunar is exactly zero. From then on, you assume GMT
    is FIXED. The calculator also gives you the "error" in the observed
    altitudes assuming you're at that DR position at the entered GMT. So next
    you just chase down that location (actually two) where the error in the
    altitudes goes to zero (this is an ordinary position fix from two altitudes
    at known GMT). And when you're done, you have GMT, longitude, and latitude,
    too. From there, you can do things like test for the sensitivity to error in
    the three observed angles."
    Frank's words explain the way he homed-in on his resulting position, which 
    was one of the questions I had asked.
    Yes, I was deliberately letting the program calculate those altitudes, 
    rather than taking Jeremy's observed values, and perhaps I could have said 
    so more explicitly. Isn't that a valid way to use the lunar calculator, 
    which invites the user to leave the altitude boxes clear if he wishes to 
    have those altitudes calculated instead? Shouldn't it still give the right 
    As Frank replied-
    "You could ignore the measured altitudes, and think about the issues when 
    altitudes are calculated. "
    Yes, that's exactly what I was doing. If no altitudes had been measured, 
    then surely, the way to home in on the result would be something like the 
    procedure I described in [6277]. Would Frank do that job differently?
    And the resulting iteration process is made unnecessarily lengthy by the 
    mismatch between the calculated longitude error and the actual error. 
    Because the error (in this example) is only halved in each iteration, many 
    such iterations are called for. If that calculation had been more precise, 
    the job could have been completed at the first reiteration.
    So we're left with one unresolved question; why is the calculated longitude 
    error so much smaller than expected? Does Frank agree, that that appears to 
    be the case? Or have I got something wrong?
    And two constructive suggestions for the next development of the lunar 
    calculator. That the actual longitude error be calculated in a way that fits 
    the facts of the case being considered. And that the direction, as well as 
    the magnitude, of that longitude error be provided for the user.
    Lunar distances, to many inland navigators without a sea-horizon, provide no 
    more than an exercise in testing their prowess with a sextant from a known 
    location at a known GMT, and Frank's lunar calculator is indeed a useful 
    tool for checking that precision. I have made the point before, that 
    actually NAVIGATING by lunar distances from an unknown longitude at an 
    unknown GMT, is a more complex matter. It's far from obvious how to use 
    Frank's program backwards, especially if the altitudes of the two bodies 
    concerned are to be calculated rather than measured, and especially if the 
    longitude can only be roughly guessed at beforehand. We have, here , an 
    example in which, in those circumstances, many reiterations would be called 
    contact George Huxtable, now at george@hux.me.uk
    (switched from george@huxtable.u-net.com)
    or at +44 1865 820222 (from UK, 01865 820222)
    or at 1 Sandy Lane, Southmoor, Abingdon, Oxon OX13 5HX, UK. 
    Navigation List archive: www.fer3.com/arc
    To post, email NavList@fer3.com
    To unsubscribe, email NavList-unsubscribe@fer3.com

    Browse Files

    Drop Files


    What is NavList?

    Join NavList

    (please, no nicknames or handles)
    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 Settings

    Posting Code:

    Custom Index

    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