NavList:
A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding
Re: Working lunars from calculated altitudes.
From: Arthur Pearson
Date: 2002 Mar 29, 23:16 -0500
From: Arthur Pearson
Date: 2002 Mar 29, 23:16 -0500
George et. al. This is a very helpful example. As I followed it along, I wondered how important it would actually be to iteratively correct one's position along with the time to converge on a more accurate GMT. The first iteration of time improves the estimate of GMT about 25 minutes or roughly half an hour. In a sailing vessel underway at 6 or 7 knots, one's estimate of position would only change about 3 or 4 miles as a result of that improved estimate of time. I took my most recent set of distances and varied my position first by about 5 miles of latitude, then separately by about 5 miles of longitude. Each time, I recalculated the altitudes, re-cleared the distance, and re-estimated GMT. In both cases, the resulting change to the estimate of GMT was less than 10 seconds. It would seem that in practice on a sailing vessel, uncertainty in position would have a much less significant impact on the use of calculated altitudes than uncertainty in time. It makes the calculated altitude technique a bit more plausible from a distance. I am curious what history tells us about whether it was in fact employed by professional seamen in the age of sail. Thanks for this example and discussion, Regards, Arthur -----Original Message----- From: Navigation Mailing List [mailto:NAVIGATION-L@LISTSERV.WEBKAHUNA.COM] On Behalf Of George Huxtable Sent: Friday, March 29, 2002 7:11 PM To: NAVIGATION-L@LISTSERV.WEBKAHUNA.COM Subject: Working lunars from calculated altitudes. Working lunars from calculated altitudes. When working a measured lunar distance to obtain a value for GMT, an important factor to be taken into account is the altitude of the two bodies involved: particulaly that of the Moon, because the lunar distance is so greatly affected by the Moon's parallax. The traditional approach involves measuring the altitudes at (effectively) the same instant as the measure of lunar distance was made. That is a (relatively) straightforward matter that has been dealt with before, and will not be considered here. However, from the early days of lunars, it has been accepted that such a measurement of the altitudes may be difficult or even impossoble, because the horizon can not be clearly seen. It has been regarded as an acceptable substitute to calculate the altitudes at that instant instead of measuring them, based on the predicted positions in the nautical almanac. That procedure, and its complications, is what this posting is about. Two difficulties arise here. The navigator needs to know the GMT in order to look up the predicted positions of the bodies in the almanac, but he doesn't yet know the value of GMT, as that is what he is trying to obtain. And the altitude he calculates will be affected by his position on the Earth's surface, latitude and longitude. Though a navigator may well have a good idea of his latitude from a recent meridian altitude of the Sun, his longitude is in the end what he is trying to obtain from a knowledge of GMT, so at the start this is unknown. The reverse process is much simpler. If an observer happens to know exactly where he is on the Earth, and what is the GMT (perhaps from GPS) then he can work out exactly what the altitudes will be at the moment of measuring a lunar distance, without measuring them. He can then use these values to correct (clear) the lunar distances, and from that obtain a value for GMT which should correspond with what the GPS has told him. This is a circular process: it has its value in indicating how well the observer is making and correcting his measurements, but it is not a way of finding position. This is what Bruce Stark has done in his Pollux-lunar measurements made on March 26 (local date). In general, a navigator using lunars will not have such a foreknowledge of the time and position for his lunar-distance observation (if he did, why would he be bothering with lunars?). Instead, he can only make an informed guess at these quantities at the moment of his lunar measurement. If he then works his lunar, calculating the altitudes on that basis, he should arrive at a more precise value for the time. Based on that time he can make a better estimate of his position. With those new values he can repeat the calculation. And so on. If the result of a lunar measurement depended only slightly on the altitudes, then an initial rough guess would suffice for the GMT and the position, which would then allow more accurate values to be obtained from the lunar. But because the correction to a lunar as a result of Moon parallax can be so great in certain circumstances, the convergence of such a process may be very slow, and many iterations may be needed before a precise result is obtained for GMT. I am grateful to Bruce for copying his observations to us, and will use them to illustrate this point: just his first set-of-five lunar distances. His GPS position is N44*00.9, W123*04.1 Corrected for index error, lunar distances average 35*34.0 at a GMT of 04:45:38 on 26 March 02. At that moment, from that position, if the altitude of the Moon had been observed it would have been 57*07.6, according to calculations from the almanac, and Pollux would have been 69* 46.9. (these values weren't given by Bruce, they are my workings) Cleared lunar distance is 35*24.4 or 35.4067* At 04:00 GMT the calculated lunar distance was 34*56.4 or 34.9400* At 05:00 GMT the calculated lunar distance was 35*33.5 or 35.5583* By linear interpolation, this gives a GMT for the lunar distance observations as 04:45:17, just 21 sec slow of GPS: a remarkably good result. My answers may diverge slightly from Bruce's as a result of a different calculation method, but effectively we agree. All I have done so far is to restate Bruce's first set of results. But now, take those same observations, and pretend that they were timed with a clock with an error, instead of by GPS. Let us presume that in fact that clock was 30 minutes fast on GPS, although this was not known to the observer. His observations of lunar distance would be exactly the same averaging 39*34.0, but the indicated time would now be 30 min ahead, at 05:15:38 by that clock. The navigator now has to use that time (he knows no other) to compute the altitudes of the Moon at 59*51.1 and of Pollux at 65*38.6. Note how much these differ from the altitudes calculated earlier, because of the half-hour time difference. Cleared lunar distance is now 35*29.3 or 35.488* The calculated lunar distances at 04:00 and 05:00 are just the same as before, unaffected by our clock error. Linear interpolation now gives a GMT for the lunar distance measurement at 04:53:12., which is 7 min 34 sec ahead of GMT. What we can say is that an initial error in timimg of 30 minutes has resulted in a time error of 7 min 34 sec, which is about a quarter of the initial value. Other geometries of Moon and other-body in the sky will result in a different ratio, which is hard to predict, but even in the worst-case I don't think this factor can exceed one-half. We could use our result to correct the clock, which would reduce its error, but it would still be out by 7 min 34 sec, though the navigator would not be aware of that figure. With this new time, the altitudes can be recalculated, and the whole process can be reiterated, which would again, presumably, reduce the error by another factor of 4, to just less than two minutes. Next time, half a minute. The navigator will be aware of these steps getting smaller each time, which would advise him when to bring the proceedings to a halt. It's clear that this long-winded reiteration process does not lend itself to hand-calculation, though a computer would do it in a twinkle. If anyone (and here I am thinking particularly of Bruce Stark) can suggest a way around this problem, I would be pleased to hear about it. Otherwise, lunar navigators should avoid calculating their altitudes and stick to measuring them, unless they have the resources of a computer behind them. George Huxtable. ------------------------------ george@huxtable.u-net.com George Huxtable, 1 Sandy Lane, Southmoor, Abingdon, Oxon OX13 5HX, UK. Tel. 01865 820222 or (int.) +44 1865 820222. ------------------------------