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
    Name or NavList Code:
    Email:
       
    Reply
    It works - within limits.
    From: Herbert Prinz
    Date: 2002 Apr 12, 01:18 +0000

    To find GMT and our position simultaneously we need the observation of the
    altitude of any two celestial bodies, the distance of the Moon from any suitable
    body, and the time intervals between these three observations.
    
    The simplest case from a mathematical point of view is to measure the altitudes
    of the Moon and second body themselves (because they are needed anyway for
    clearing the distance), and to measure all three quantities at exactly the same
    moment. One can cheat a little on the latter by bracketing the distance
    observation with the altitude observations and subsequent averaging.
    
    While it's true that the required altitudes can be computed, we also know that
    there is no free lunch. To use computed altitudes merely means that we have
    already observed some (other) altitudes at an earlier stage (for the purpose of
    finding time and latitude). The solution by this method is, therefore, a running
    fix.
    
    Consider the case where double altitudes of the Sun, or some such method is used
    during the day to establish local time and latitude. If a vessel sailing from New
    York towards the Azores in and out of the meanders of the Gulf Stream observes
    Sun altitudes around 10:00 and 14:00 to establish local time and then takes a
    lunar around 20:00, the dead reckoning of longitude made good between the former
    and the later observations can easily be off by 10 nm, and hence its local time
    be off  by 40s. So the error in computed Moon altitude could be up to 10' of arc,
    hence the error of computed parallax up to 10" of arc, which in turn could
    translate to an error of as much as 20s in GMT or 5nm in longitude for the final
    fix. This is not much in the scheme of things. Most navigators were and will be
    happy to get GMT within a minute.  I am only emphasizing that this is an
    additional error that does not appear if altitudes for clearing the distance are
    measured directly and that cannot possibly be detected or eliminated by any
    mathematical tricks.
    
    Bruce Stark soft-pedals the impact of DR error on the accuracy of the final fix
    in his message "It works", of April, 2. The reason why it works for Bruce even
    "when both GMT and longitude are wildly uncertain" is that in his example, he
    does not depend on measuring local time at all; he computes it from accurate data
    and only THEN shifts assumed GMT and assumed longitude in sync with each other,
    so as to not upset their relation (defining local time). Naturally, after 2
    iterations, one gets the correct GMT and longitude from the lunar distance. But
    this is tautological. In the real world, however, local time is only as good as
    your dead reckoning since the time you established it. The "wildly uncertain" DR
    does, indeed, not matter up to the moment where we start with the first
    observation for time. But any subsequent error in dead reckoning will have its
    inevitable effect on the resulting fix for GMT from the final lunar observation.
    
    Of course, there is nothing special about lunars here. This is a general problem
    with the running fix. Take the standard timed altitude observation of two stars
    as an example. When starting from a wildly wrong DR position, St. Hilaire will
    get you the right fix, albeit only after 2 or 3 iterations. That's not
    surprising, because direct methods will not even need a DR. The same is true for
    a running fix, if and only if you are absolutely sure about your dead reckoning
    between observations. But if you screw up on the DR (e.g. by getting into a
    current) no method will tell you. All of them will result in the same wrong fix.
    
    There is another, minor problem with computed altitudes. I am not sure whether
    this has been mentioned already.  They rely on an unverified assumption about
    there being ideal atmospheric conditions in the direction of the Moon and second
    object. But if there are unusual circumstances, the effect can result in up to
    12s error in GMT for every 0.1' deviation from standard refraction. If one
    measures the altitudes, this error is automatically eliminated, at the cost of
    only the corresponding negligible positional error. Using computed altitudes is
    thus inherently less safe than measuring them.
    
    All numbers I gave are worst case scenarios that I could THINK of. I never lost
    time at sea and never had to depend on a lunar distance. So, I really don't know
    what I am talking about. All I have ever done were isolated experiments of
    various kinds.
    
    Herbert Prinz
    
    
    

       
    Reply
    Browse Files

    Drop Files

    NavList

    What is NavList?

    Get a NavList ID Code

    Name:
    (please, no nicknames or handles)
    Email:
    Do you want to receive all group messages by email?
    Yes No

    A NavList ID Code guarantees your identity in NavList posts and allows faster posting of messages.

    Retrieve a NavList ID Code

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

    Email Settings

    NavList ID 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