NavList:

I will try this technique at sea next spring using both terrestrial and celestial LOP's with small crossing angles to check its practical use.

 

As far as tradition, we are taught to not rely on any LOP's with such small angles.  This technique may be of great use for running sunline fixes.

 

Jeremy

 

PS, part of your problem, IMHO is your presentation.  You are very aggressive using statements like "My question -- why would a navigator intentionally ignore useful position information??"  This isn't the way to win friends and influence people.

 

After two threads and 57 posts, including unrelated topics thrown in, 
here's a new thread narrowly dedicated (I hope) to the proposition 
that the estimated-position running fix (EPRF) is superior to the 
traditional running fix (TRF).  I'll try again:

First definitions:  We all know the TRF method of advancing (or 
retarding) a LOP.  And most know the estimated position concept:  
When, at a position whose uncertainty is relatively large, a new LOP 
is acquired whose uncertainty is significantly less, drop a 
perpendicular line to the new LOP from the current uncertain 
position.  These two concepts are applied to the running fix problem 
in the figure below (called Two Methods).  The result of the TRF is at 
RFIX; the result of  the EPRF is at EP2.

(1) The starting point EP1 was determined by using LOP1 plus the 
navigator's best guess about his position along LOP1.  The navigator 
ALWAYS knows something, no matter how little, about his position and 
thus places EP1 at his best estimate along LOP1.  This point is a 
major difference between the TRF and the EPRF.  The TRF pretends that 
the navigator knows nothing about his location along LOP1.  This 
notion is entirely false in practice.

(2) The location DR1 is the result of the navigator's estimate of his 
track from EP1 to DR1.  In our discussion it's irrelevant how complete 
a job the navigator did in determining this track.  Forget currents, 
drift, bird sightings, etc., or the definition of DR versus EP in our 
discussion.  The point is that the DR1 location and LOP1 is the only 
positional information we have immediately before LOP2 is acquired.  
So the running fix problem has three pieces of info, LOP1, DR1, and 
LOP2 as the "givens".  No need to debate where they came from (e.g., 
any kind of LOPs will do), or anything else about these "givens".

(3) The TRF and the EPRF employ completely different assumptions in 
using these three pieces of info.  As can been seen in the figure, the 
TRF uses only the perpendicular component (red line) of the estimated 
track, and completely ignores the parallel component (green line), in 
determining RFIX.  This is consistent with the assumption that the 
navigator knows absolutely nothing about the location of EP1 along 
LOP1.  Again, this assumption is always false in practice.

(4) The EPRF assumes the information in LOP1 has been completely 
exhausted in the determination EP1 and  DR1, so that we're left with 
only DR1 and LOP2 for fixing our location.  Therefore dropping the 
perpendicular to EP2 from DR1 completely honors LOP2 while retaining 
the current directional information in DR1 that is parallel to LOP2.  
In short, the EPRF honors all the new info acquired without 
contradicting or ignoring currently relevant information -- exactly 
what should be done in any estimation problem.

(5) The resulting characteristics of the two methods are quite 
different.  As can be seen in the figure with narrow LOP crossing 
angles, the TRF can give results absurdly far from our DR position.  
But any new LOP should increase the accuracy of DR1's location, not 
decrease it.  Even a new LOP parallel to LOP1 should improve our DR 
estimate.  And in contrast, as you can see, the EPRF does give 
perfectly reasonable and logical results for narrow crossing LOPs -- 
even for parallel LOPs.

(6) Note that as the orientation of LOP2 rotates from a narrow 
crossing angle to being perpendicular to LOP1, RFIX and EP2 uniformly 
come together, and are identical when the two LOPs are perpendicular.

In summary, the EPRF uses the position estimation along LOP1 as much 
as possible, while the TRF completely ignores it.  My question -- why 
would a navigator intentionally ignore useful position information??

JK

 
   

--
NavList message boards: www.fer3.com/arc
Or post by email to: NavList@fer3.com
To , email NavList+@fer3.com