# NavList:

## A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding

Message:αβγ
Message:abc
 Add Images & Files Posting Code: Name: Email:
Re: Exercise #14 Multi-Moon LOP's
Date: 2009 May 3, 12:06 -0700

```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

--~--~---------~--~----~------------~-------~--~----~
To post, email NavList@fer3.com
To unsubscribe, email NavList-unsubscribe@fer3.com
-~----------~----~----~----~------~----~------~--~---

```
Browse Files

Drop Files

### 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)