# NavList:

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

**Re: Lat/Lon by "Noon Sun" & The Noon Fix PROVE IT**

**From:**George Huxtable

**Date:**2009 Apr 16, 13:55 +0100

Jim Wilson wrote | George: | | Thanks, and I'm sorry to be a bother, but if I plan to use my method, I | need simulated data in the same form that I took it for my example. | Specifically, I need at least five altitudes at about one minute | intervals starting 30 minutes before LAN. Then I need a few around | maximum altitude. I could live with what you offered for that. Finally, I | need another five altitudes at about one minute intervals starting at the | last altitude of the first run. Anything else is wasted on me. Figure 2 | shows what I took, and I don't really need that much, but the format is | natural. I'll attach it. | | I hope that this is not too much to ask. And added later, off-list- I think there may be a method that doesn't inundate everyone with superfluous data. You could use your program to generate the tons of data on one minute intervals, and then throw away what isn't needed. Is it that easy? ======================== Response from George- I'm keen to meet Jim's requirements. It's no problem to create a lot more columns in the spreadsheet, and thus simulate 61 altitudes at 1-minute intervals. From those I could select three groups of six, each spanning five minutes. The most useful observations for determining longitude are near the limits of the period, as far from Local Apparent Noon as possible, and Jim wishes, quite properly, to take advantage of that. The important observations for latitude, however, are those close to LAN. Frank Reed stated his requirements to be observations spanning 40 to 60 minutes at 5 or 10 minute intervals, therefore 5 to 13 in all, and I've bent over backwards, in this demanding test, by choosing that maximum number of 13. Jim's extended series would be 18 observations rather than 13, but if that will do the trick, we should try it. Can a skilled observer take timed altitude readings as close as 1 minute intervals, though? Can he do so without an assistant for noting times and recording results? If not, we should be told, because it becomes a disadvantage in the procedure. I have no problem in providing data for the first part of Jim's procedure, covering the first five minutes, from the start of the chosen hour. Not so easy to choose "a few around maximum altitude", because each scan is unpredictably different, in the time of maximum altitude, and the height, and the scatter of its points around it.. I am reluctant to allow hindsight, in examining the data-set after it's been captured, to determine when the peak was, for the purpose of deciding which observations should have been used, as a real observer couldn't do that. So I would prefer Jim to preselect a fixed time-bracket, if he can, which will meet his requirements around the peak.Those observations around the peak don't need to be spaced so closely in time as 1 minute, and we don't have to take equal intervals all through. If Jim can find a way to restrict his total number of observations to 13, that would allow a fairer comparison with Frank's procedure, though I certainly wouldn't insist on it. My problems comes with the final set, of falling altitudes, taken toward the end of the measurement-hour. Jim wants these to start "at the last altitude of the first run". That's all very well with hindsight, but how does a real observer do that, unless he has been observing at regular intervals, or coninuously, to discover when that moment has arrived, to start noting results? And then, there's another problem. I can see that Jim would wish to make his set of falling amplitudes symmetrical with his set of rising ones. But what happens it the peak hapens to be delayed after LAN? Then the falling part of the altitude curve can't be accommodated within the allotted hour for observation. Indeed, that will normally be the case, because the effect of Northerly vessel-speed alone will normally act to delay the moment of the peak. [That effect has been somewhat tempered by my failure to allow for equation of time, in choosing the appropriate time-span around LAN, which should really have run from 12:08:16 to 13:08:16, rather than from 12:10 to 13:10 (though all the numbers have, I hope, been properly calculated according to the GMT times that were given)]. This is a problem that will also face an observer in real-life, and to ensure that he will be able to complete a symmetrical observation within the specified hour, perhaps he should delay, somewhat, the start of his data-collecting, to be a bit after12:10. Or else, accept that a longer interval than an hour will have to be accpted, on many, perhaps most, occasions. The longer the duration of the observation-scan, the more precise the answer will be, and the more it will depart from an "observation around noon". If Jim can provide a simple recipe for choosing fixed timing of his three blocks of altitudes, I'll try to meet his needs. If he can suggest an algorithm, which doesn't presume knowledge of any data before it's actually arrived, I will try to implement it. What we're discovering, here, are real difficulties in interpreting the procedure that would be faced by a real observer, and are not just artefacts of the simulation process, so we can learn from them George. contact George Huxtable, at george{at}hux.me.uk or at +44 1865 820222 (from UK, 01865 820222) or at 1 Sandy Lane, Southmoor, Abingdon, Oxon OX13 5HX, UK. --~--~---------~--~----~------------~-------~--~----~ Navigation List archive: www.fer3.com/arc To post, email NavList@fer3.com To unsubscribe, email NavList-unsubscribe@fer3.com -~----------~----~----~----~------~----~------~--~---