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: Use of Sun Sights for Local time, and Lunars for Longitude
    From: Herbert Prinz
    Date: 2002 Oct 21, 21:44 +0000

    Arthur Pearson described the olden style navigator's routine from times before
    the chronometer. After a detailed recapitulation, Bruce Stark concludes:
    
    > You've found latitude and longitude, and the lack of accurate GMT was no
    > hindrance whatever in working the observations.
    
    and further down
    
    >
    > Modern navigators find this hard to swallow. In the system they've been
    > taught, everything is founded on, and must begin with, accurate GMT. They've
    > come to accept, as a bedrock truth, that to work observations successfully
    > you have to have accurate GMT. If you don't have it the only hope, in their
    > view, is to FLOUNDER [my emphasis] toward it by iteration.
    
    If you are able to observe the altitude of the Moon at the time of taking the
    distance, you do not need GMT. If, however, the altitude of the Moon at the time
    of observation must be computed, one must know the celestial position of the
    Moon, and consequently the time at the place on which the almanac is based.
    Whether this is expressed in terms of ET, UT, GAT, GAST, LAT in Paris, LAST in
    Paris, ... does not matter. If you don't know how late it is at a particular
    longitude, one way or another, i.e. if you don't know the phase angle between the
    Earth and the sky, no magic is going to help you finding RA, hence LHA, and Dec
    of the Moon, both of which which you need to compute its altitude. Local time at
    unknown longitude is insufficient.
    
    It is true that the altitude of the Moon is not particularly critical as it only
    contributes a second order effect to the final result (a correction to a
    correction, as it were). So, it is conceivable that a well chosen estimate of LHA
    and Dec of Moon at the moment of  observation (i.e. an implicit guess at time in
    Greenwich, as well as your longitude) immediately leads to a sufficiently close
    approximation of actual UT, obviating further iteration. The only way to find out
    whether the guess was appropriate is to check whether Ra and Dec of the Moon for
    the newly found improved UT are reasonably close to the values that have been
    used. Only then will the improved UT be close to actual UT. The deliberate choice
    to stop iteration after the first round does NOT make the method inherently
    non-iterative.
    
    The fact of the matter is that a lunar distance reduction can be worked as a
    direct method when observed altitudes of Moon (and/or Sun) are available, whereas
    when a computed altitude of the Moon or Sun is involved, there is no such option.
    Then, it must always be handled as an indirect method, hence in an iterative way.
    There is simply no way to solve the system of non linear equations representing
    the lunar distance problem with unknown phase angle between Earth and sky in any
    direct way.
    
    In a previous post named "It works - within limits", I pointed to a further
    complication of lunar distances involving computed altitudes: They are to be
    qualified as running fixes. Like any other running fix, they suffer from bad dead
    reckoning between the individual observations. In this particular case, it
    concerns the estimated change in latitude and longitude of the observer between
    the moments where apparent time is established and the lunar is taken. This is an
    entirely different problem; I mention it here only to make it perfectly clear
    that this shortcome cannot be alleviated by means of iteration. Iteration helps
    bridging a gap when input parameters are only given implicitly. It does not help
    when input data is faulty.
    
    Bruce Stark's wording makes it seem as if he considers iteration and indirect
    methods a newfangled invention of modern navigators, if not an unsound method
    altogether. This would give the wrong picture. To be sure, the sight reduction
    method most widely practised in our time, namely the intercept method, IS
    indirect and iterative. But is this new? Let's have a closer look at the olden
    style navigation. Bruce Stark writes:
    
    > Besides the noon latitude and
    > lunar, which took no more work than if you'd had accurate GMT, you've worked
    > a time sight twice, using different latitudes. That's exactly what was
    > required in order to plot one Sumner line, using an accurate chronometer.
    
    In order to get one Sumner line, one requires one altitude observation plus its
    reduction; to get two lines, one needs two altitudes; etc. A noon observation
    provides just one other Sumner line and counts for one observation (although it
    is actually a series of observations). So, if I count correctly, our 18th century
    navigator worked 3 sights where the modern navigator would have needed 2. That's
    because the olden style navigator had to work his time sight from the morning
    again when latitude became available, as Bruce Stark correctly tells us in his
    posting. One may call it "re-working", I call it "iteration".
    
    The idea of iteration is by no means new. Iterative methods are now often
    preferred to direct methods for their simplicity. In olden times when
    mathematical tools were lacking, they were often the only way to go. For example,
    it is preferable to have a method to find apparent time and latitude
    simultaneously from any two altitudes. This is more convenient (and safer!) than
    a method where a navigator is bound to make an observation at a specific time.
    There exists a direct method, called "combined altitude" or "double altitude"
    method and the principle was already known to Joh. Regiomontanus. But in
    practice, the direct method is by far more labour intensive than the "time sight
    - noon sight - iterated time sight"  cycle described above. Therefore, iterative
    methods for this more general problem, too, have been proposed as early as in the
    18th century: Assume a latitude and find elapsed time between the two altitude
    observations. If the time (hour angle) turns out too short, compared with the
    chronometer, your latitude was too low, if it's too long, latitude too high. Make
    an adjustment and try again. The method must have been in use. Even a practical
    man like Lecky offers an improvement to it in "Wrinkles".
    
    Having focused on the task of computing the individual fix, let's zoom out to
    look at the ongoing process of navigation as a whole. We find that a passage is,
    and always was, one big iteration of taking measurements, making estimates and
    basing actions thereon. These actions lead to new situation, new observables. As
    new measurements become available, estimates are being corrected and actions
    modified. This was even more true in the olden days before modern electronics
    took out some (not all!) of the guesswork. Nowadays we call such an iterative
    process a feed-back controlled loop. When Nobert Wiener needed a name for an
    abstract mathematical discipline to deal with this technique, he chose
    "cybernetics" not without a reason: It's the Greek word for "navigation".
    
    Herbert Prinz
    
    
    

       
    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