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: Fw: Letcher page 103
    From: Henry Halboth
    Date: 2010 Feb 12, 19:18 -0800
    Paul Hirose in 8786 using his "sight reduction simulator" provided a most interesting analysis regarding the Altitude accuracy of HO 211 (Ageton). Would he favor us with a similar analysis of HO 208 (Dreisenstok}.

    I used 208 at sea for many years as a favored method of sight reduction and, except for an occasional "outrider", found it to be most satisfactory, especially where working space did not favor the use of more cumbersome pubs. It would be interesting to view an analysis of its accuracy

    Frank and George are otherwise most correct in inviting attention to the affect of accumulated errors in sights taken above opposing sea horizons. Such methodology has often been advocated as providing the most accurate fix, in that the box-like configuration resulting tends to average out the errors of both instrument and observation - but that's another tale.

    Regards,

    Henry

    --- On Thu, 2/11/10, Frank Reed <FrankReed@HistoricalAtlas.com> wrote:

    From: Frank Reed <FrankReed@HistoricalAtlas.com>
    Subject: [NavList] Re: Fw: Letcher page 103
    To: NavList@fer3.com
    Date: Thursday, February 11, 2010, 10:13 PM

    Greg wondered:
    "At what point would you use Letcher's opposing Sun Moon method to reset a stopped chronometer?"

    As George has pointed out, when you use altitudes observed in opposite azimuths, any systematic errors are magnified. We're looking for a separation between the LOP of the Moon and the LOP of the other object as evidence of a an error in GMT. The trouble is that an error in the calculation of dip, or an error in the estimation of refraction, or an error in the measurement of the index error when the objects are on opposite azimuths would all lead to a separation of the LOPs, unrelated to the error in GMT that we're looking for.

    So how can we fix that? If the goal is to preserve as much as possible of the simplicity and familiarity in the clearing process that comes from this longitude by lunar altitudes system, and I think we all agree that this is appealing to navigators raised on standard late-20th-century LOP navigation, then the easiest way is to look for a second body (which would almost always be a star in twilight) that is on the SAME azimuth as the Moon. Then those same systematic errors that are amplified above are in fact almost entirely cancelled out. This applies to all the things that normally make altitudes somewhat uncertain except the residual random variation which can be quite small. By taking four or more observations of each altitude and graphing them, we can immediately assess the scale of those residual errors and also average them out to a significant extent. So the results can really be quite good. And just a reminder, this method is only effective when the Moon's motion relative to the celestial sphere (the stars) is nearly perpendicular to the horizon. This can be judged fairly well "by eyeball" when the sights are taken. If the Moon is rising/setting with its "horns" nearly horizontal (within 45 degrees of horizontal is good, within 30 is excellent), then the Moon's orbit is nearly perpendicular to the horizon.

    On the other hand, what would be the best way to use the Sun and the Moon to get GMT when they're on more or less opposite azimuths? In that case, we might take advantage of the "geometric miracle" discovered by the proprietor of the "Frank Reed School of Navigation" (Heh-heh) and posted to NavList in July, 2008 (see http://fer3.com/x.aspx/05622, also see messages 5638 and 5686 which has a diagram). It turns out that there is a surprisingly broad range of azimuth differences where lunar distances can be cleared without using any spherical trigonometry at all. We can take the scenario described by Letcher and entirely ignore the altitude of the Moon. We measure the altitude of the Sun, and the angle between the Moon and Sun --a traditional lunar distance. Then, if they're on roughly opposite azimuths, no exactness required, we calculate the altitude of the Moon "as if" the two bodies were in fact on exactly opposite azimuths. Then using extremely simple corrections, really just the normal altitude corrections that you would use on these altitudes, we calculate the cleared lunar distance. After that, we either need tables of pre-calculated lunar distances (not at all hard to get these days) or we have to deal with the pain of working out the geocentric lunar distances long-hand from Nautical Almanac data. Either way, from there it's a simple interpolation to get GMT.

    Of these two approaches, the latter has all the advantages of a true lunar distance observation, and it works regardless of the orientation of the Moon. On the other hand, it requires an exact measurement of the sextant's index correction. If that's uncertain then the method by altitudes is better.

    -FER

    ----------------------------------------------------------------
    NavList message boards and member settings: www.fer3.com/NavList
    Members may optionally receive posts by email.
    To cancel email delivery, send a message to NoMail[at]fer3.com
    ----------------------------------------------------------------


       
    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