NavList:

   

Reply

Hi Frank

Of course, the rapid fire fix (and the special noon fix) are not heresy.  With 
the proper regression, they will clearly provide a reasonable fix.  

I remain skeptical when the curve is shallow, the altitude error terms 
scattered, we have a velocity that is only improperly known AND the 
regression method is a faired line using a mark-1 eyeball.  As we have just 
seen with Jim's method, it is possible to obtain a "fix" that really isn't.  
I have been waiting patiently for the mark-1 eyeball fix using the method you 
espoused.  That appears to be a curve fit, so the first set of George's data, 
when it was every 5 minutes would probably be more suitable for your 
purposes. Please Frank, won't you try at least one? 

Just to be clear, I am not playing gotcha or going to argue mindlessly.  I try 
to be fair and evaluate data as presented.  I evaluate data for a living, so 
fairness is built in!

The cocked hat is nothing more than a regression fit using the 3 intersections 
(assuming 3 LOPs) as the input.  Could it be done using least squares?  Sure, 
and it would probably confirm what you did by the mark-1 eyeball regression.  
Throw in 25 LOPs and the mark-1 eyeball is confused. We agree! 

When first playing around, I said to myself, if 3 LOPs work well, then I 
should get a refined fix with 6 LOPs.  I certainly didn't get what I wanted 
and in fact provided myself with enough evidence to discount the method in 
practical use.  No, I didn't use a least squares fit.  It may have worked, it 
may not.

I have nothing against electronic solutions. By my comments, you can see that 
I have created quite a bit of my own electronic methods.  Fair is fair.  Take 
out the drudgery and everything becomes a bit more enjoyable.  However, being 
a very old hand at software (since the 1960's), I know how it can confuse 
even the author, let alone the user who is not privy to the source code.  I 
have an inherent distrust of it, in that programmers are NOT infallible, most 
especially myself!  There is a predeliction to assume that just because it is 
coded in software, it must be right.  

There is a prominent GPS manufacturer who has a very nasty conversion bug when 
going from MGRS to other position coding conventions, like lat lon or UTM.  I 
have pointed this out the manufacturer, to no avail.  I guess that they just 
don't care.   The conversion fails to match the goverment example.  That 
rates a total "duh".  If you never checked this example, you would trust the 
conversion and therefore the output of the GPS.  I checked it, and it is just 
WRONG.  The same type of thing can happen when doing celestial.  We are not 
immune to it.

In other words, let the user beware!  If you use software, and have not been 
provided (either by yourself or others) extensive proof of how it provides a 
good answer, then take everything it says with a gigantic grain of salt.  

Surely you have spent enough time with the guts of the NavList software (and 
the historical mapping software) to understand just how insidious software 
can be.

Best Regards
Brad


--~--~---------~--~----~------------~-------~--~----~
Navigation List archive: www.fer3.com/arc
To post, email NavList@fer3.com
To , email NavList-@fer3.com
-~----------~----~----~----~------~----~------~--~---

   

Reply