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: Luni-Solar Distance
    From: George Huxtable
    Date: 2010 Oct 18, 00:28 +0100

    A few belated comments on Douglas Denny's posting of a couple of weeks 
    back, on 11 Oct, about his Sun lunar.
    He wrote-
    "It must not be forgotten though, this experiment of mine is nevertheless 
    an attempt to get as good as possible accuracy on land under the 'best' 
    conditions, with a steadied 'standard' sextant with telescope, and 
    calculated altitudes used, so it should be the 'best' possible or close to 
    it. I am interested mainly in the original time accuracy problem from using 
    Lunar Distances to obtain longitude as per nineteenth century."
    To simulate some of the difficulties, Douglas might try shooting his next 
    lunar from the local kids' playground, standing astride a see-saw, with a 
    friend or two waggling it about. He might also persuade them to chuck 
    buckets of cold water at him from time to time. And then, there's the 
    blockage of much of the sky, by sails, to allow for somehow. Taking lunars 
    at sea wasn't easy.
    He added-
    "I still expect it is a different matter altogether at sea however, and 
    having to measure the altitudes too will reduce accuracy, unless they are 
    calculated - but that presupposes a known time is available which in the 
    19th C. was not the case without chronometers."
    If the time was known, there would be no point in taking a lunar. That's 
    the purpose of measuring a lunar-distance; to determine the time. So 
    there's a bit of a paradox, in calculating altitudes with which to clear a 
    lunar, for which time and position are both needed. To get round it, you 
    have to assume a trial longitude first, and then use the lunar observation 
    to refine that assumption.
    The method of calculating altitudes also requires a prior knowledge of 
    latitude, and assumes that any navigator always knows his latitude well. 
    Which is generally the case, except after a period of overcast skies.
    In contrast, measuring the altitudes of Moon and other-body requires no 
    such prior knowledge. You can be anywhere in the World, and a lunar will 
    give your longitude, though not your latitude.
    Frank Reed has produced a useful and precise lunar calculator, at-
    http://www.historicalatlas.com/lunars/lunars_v4.html .
    If required, this can work on the basis of calculated altitudes. And that 
    works well, for the purpose for which it was intended; checking an observed 
    lunar distance against a predicted value based on a known position and a 
    known time. The difficulties arise when it's used to solve the converse 
    question, determining longitude and time when only lunar distance and 
    latitude are known, based on calculated altitudes. In some combinations of 
    positions of Moon and other-body in the sky, the altitudes have little 
    effect on the answer. In other geometries, the result is very sensitive to 
    those altitudes, the accuracy depending greatly on the initial value chosen 
    for assumed longitude, and calling for multiple iterations..
    Let me demonstrate such a difficult case, that you can check for yourself, 
    using that lunar calculator. A navigator is somewhere on the Equator, at 
    lat = 0º, and knows it from his previous observations. We know (though he 
    doesn't) that at midnight, 00:00 hrs at the start of 26 March 2005, he is 
    exactly on the Greenwich meridian, at long = 0º, at which moment he takes a 
    precise lunar distance between the Moon's near limb (it's full Moon, so 
    either limb will do) and Regulus, of 36º 48.9'.
    However, not knowing his exact longitude, he guesses it to be 01º 00' East. 
    On that basis, the program clears the lunar, and finds that the measured 
    lunar distance, cleared on that basis, is 1.0' greater than the calculated 
    value assuming that he really was at that longitude. Based on that, the 
    program indicates that the assumed longitude should be shifted Westward, 
    from the initial assumed position of 1ºE,  by approx 28.6', so to 31.4'E. 
    (Actually, just the magnitude of the suggested shift is givem; not its 
    direction, which has to be deduced separately). The amount of that proposed 
    shift is based on a rough average value for the Moon's speed across the 
    star background of 0.5º per hour.
    So next step is to change the assumed longitude to that new value, starting 
    a process of iteration. Then the resulting cleared lunar distance is only 
    0.5º greater than the calculated value for that longitude, which should be 
    shifted further by 15.5', to 15.9'E. You can see that the iteration is 
    converging, but painfully slowly, improving by approximately a factor of 
    two at each step. At this point, once we can see how it's converging, we 
    can make a short-cut by predicting on that basis what the end-result is 
    going to be. It will end up at 0º, as we knew it would all along (but he 
    What I've pointed out is not a weakness in Frank's lunar calculater, but a 
    weakness in the procedure of calculating altitudes for clearing lunars to 
    determine an unknown longitude. It's a matter that Maskelyne skated over, 
    when introducing the procedure in his first edition of British Mariner's 
    Guide, in 1763.
    contact George Huxtable, at  george@hux.me.uk
    or at +44 1865 820222 (from UK, 01865 820222)
    or at 1 Sandy Lane, Southmoor, Abingdon, Oxon OX13 5HX, UK. 

    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