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
    Name or NavList Code:
    Re: alternative to running fix
    From: Barry Hudson
    Date: 2000 Aug 06, 8:55 PM

    A very interesting discussion with some points on prudent navigation. From
    my experience the sun run sun is a traditional
    method of getting noon position. An a.m P/L say at 0930 is run up to the
    Latitude ZT the position then is run forward or
    run back the few minutes to establish the noon pos. If you wish you can run
    your Latitude up to a PM P/L. One thing
    I always noticed is that the AM star sight never agreed with the Noon
    position and over the voyage it was proved invariably
    that landfalls fell in with star sight positions. In a long passage this
    reliance solely on the sun run sun running fix and scrapping
    the star position means days of accumulated error and big surprise at
    Barrie Hudson
    Paul Hirose wrote:
    > Instead of advancing a line of position by several hours for a running
    > fix, why not use it to improve your estimated position immediately?
    > Bowditch shows how in the chapter on celestial LOPs. First plot the
    > LOP and your estimated (or DR) position at the time of the LOP. Then
    > your new EP is the point on the LOP that's closest to the old EP.
    > Plotting is easier this way because only the EP needs to be advanced
    > to the time of the next LOP. As long as you have a good mix of LOP
    > angles, I bet you could navigate forever, never take a fix, yet keep
    > your DR real close. Just take a few sun sights each day and update
    > position after each one. I don't see anything but advantages compared
    > to a running fix. Nobody else has suggested this, though, so I guess
    > there's a flaw in my reasoning somewhere.
    > I do think a computerized nav system (something way more costly than a
    > Celesticomp) would immediately integrate a LOP into the present
    > position solution, and not save it for a running fix later. But I have
    > to admit I've never worked on a system that dealt with discrete LOPs.
    > In my experience, the sensor, such as doppler, puts out continuous
    > data. A closer analogy would be ground mapping radar, which does yield
    > discrete data points, but they are fixes, not LOPs.
    > One airplane I used to maintain had buttons marked QUAL 1 and QUAL 2
    > so the navigator could tell the computer how much confidence he had in
    > his radar crosshair placement. Interestingly, even when you hit QUAL 1
    > the system wouldn't simply slave its present position to the crosshair.
    > It would weigh its own dead reckoning ability against your likely
    > accuracy, and accept some of your input. If the correction was
    > unreasonably large, the computer figured you had the crosshairs on the
    > wrong point, and would reject the update. There was a button to
    > override that, but even then the computer got the last word. It would
    > update its position but not its velocities. That way a botched fix
    > would introduce a fixed error but one that wouldn't grow with time.

    Browse Files

    Drop Files


    What is NavList?

    Get a NavList ID Code

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

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