# 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: GMT from Moon and Body Observed Altitudes...??
From: Sean C
Date: 2019 Feb 17, 23:32 -0800

Ron,

After reading your post (several times until what you were saying finally got through my thick head), I was thinking "No. This can't possibly work." But, the more I thought about it, the more I realized that I couldn't come up with any reason why it wouldn't. So, I decided to try and work an example.

I picked Aldebaran as the other body simply because it is currently a convenient body to use in the sky above my house. I used the USNO's MICA program to generate the data I needed. The data I got was as follows:

Date: 2019, Feb. 18  Time: 02:00:00 UT1

AP: 37°03.3' N, 76°28.6' W

Moon GHA: 48°26'28.098"

Moon Dec.: N19°29'51.17"

Moon "Ho": 59°54'03.53"

Moon Zn: 117°56'13.9"

Aldebaran GHA: 108°29'51.543"

Aldebaran Dec.: N16°32'39.80"

Aldebaran "Ho": 55°06'20.1"

Aldebaran Zn: 242°41'13.7"

The result of calculating the LD using GHA and Dec. was 56°54'04.11". The result of calculating the LD using "Ho" and Zn was 56°54'04.08" - a difference of just 0.03".

Of course, this is just one example - using perfect data. And, like you, I'm wondering if I am missing something here. But it does seem to work. The potential problems I can see when doing it this way are: 1) The altitude measurements must be very accurate. But then, so must the LD measurement when doing it the traditional way. 2) The refraction values must be accurate. This might be the biggest obstacle given the possibility of abnormal conditions. 3) The data I used was given to a precision of at least a tenth of a second. I'm not sure what the results would be when using N.A. data at a precision of a tenth of minute. 4) I'm also not sure how much an incorrect AP would affect the result, since this is probably how you would be determining Zn. I suspect that the error would have to be rather large to have a noticable effect, though. But I could be wrong.

Anyway, I'm kind of surprised that no one else has commented on this yet. I think it's a very interesting idea - at least as a possible alternative method requiring fewer [more familiar, less complicated] formulas. And if it does work in most (if not all) cases as well as my example, then I wonder why no one seems to have thought of or at least mentioned it before. If they did, I missed it. I hope the other members of NavList will chime in and give their insights about this soon. I'm keen to hear any reason this method shoudn't be used.

At any rate, thanks for the mental exercise. I might just go ahead and try a variety of other examples using different sources of data and different reduction methods while I'm waiting to see if anyone else has something to say.

Regards,

Sean C.

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)