NavList:

   

Reply

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
landfall.
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.

   

Reply