NavList:

http://fer3.com/arc/m2.aspx/Key-West-nearLAN-sights-PeterHakel-may-2013-g24081

Comments on Peter Hakel's SUN LAN in Key West on May 17th, 2013

May 29st, 2013

Hello to all,

The following lines summarize an earlier and private discussion with Peter Hakel.

Thank you Peter for having very kindly suggested that I might publish them to the attention of all our NavList Community.

*******

Peter published his recent SUN LAN sights in Key West on May 17th 2013 as follows:

Lat: N 24° 33' Lon: W 81° 46' T = 26 C HE = 7 ft P = 1016 mb

From these results Peter computed the following LAN position
Lat: N 24° 38' and Lon: W 83° 16' (approximately 80 NM from True position) with the following comments in:
" http://fer3.com/arc/m2.aspx/Key-West-nearLAN-sights-PeterHakel-may-2013-g24081 " and among which:

“It looks like I just missed the LAN, so the resulting noon curve extrapolates a little, which is always a concern.” And,

“I never read such high altitudes (over 84 degrees) but it did not seem to be difficult. The instability of the index error was kind of expected based on what I have seen before with my sextant. I suspect missing the moment of LAN is the main source of error here, since I didn't get a nice "symmetric" data set around LAN this time.”

After further thoughts Peter added some private comments about the possibility of having “mispointed [his] sextant toward the wrong azimuth”.

And finally Peter gave me the following Observational Data further corrected here for only instrument errors:

- UT1=17h34m27.0s Hs1=84°20’8
- UT2=17h35m38.0s Hs2=84°31’4
- UT3=17h37m39.0s Hs3=84°08’8
- UT4=17h40m20.0s Hs4=83°52’8
- UT5=17h42m10.0s Hs5=83°25’0
- UT6=17h44m09.0s Hs6=83°15’2

*******

First of all, the SUN Transit time is UT tr.=17h23m27.18s, at which time the SUN apparent center is exactly at the South of the Observer, while its Declination is N19°28’32”4, i.e. with the Sun Center Geocentric height being is quite close from 84°55’. This is an important preliminary result which will be discussed in the second part related to the LAN itself.

*******

I first computed Intercepts and Azimuths as individual LOP’s through using the “true” position (Lat: N 24° 33' Lon: W 81° 46') as a DR position. A total of 2 iterations is required here since the actual LOP’s are low radius circles and cannot really be considered as “straight lines”. Here are the results:
i1/Az1 = +14.5’/207°2 , i2/Az2 = +32.8’/209°7 , i3/Az3 = +24.6’/213°7
i4/Az4 = +30.2’/218°5 , i5/Az5 = +18.4’/221°4 , i6/Az6 = +27.1’/224°4

Our “straight lines LOP’s” yield a first position at
N24°18’5/W082°10’4, then
N24°17’8/W082°09’6, then
N24°17’8/W082°09’7, which is our final result since it no longer changes to our 0.1’ representation. From this position the heights dispersion is 6.3 NM, which indicates that “something definitely unusual” happened during this observations round.

These results show that:

- The intercepts are all positive, which would indicate that – as Peter felt – finding the actual Sun azimuths in order to rock the heights into “minimum heights” was definitely a hard task. Observing above 80° requires good training and the best sextant rocking technique has been described in NavList: let the rocking axis be the one from the Observer’s eye to the body center and not just a horizontal axis. For heights above 75°, it makes a hell of a difference on accuracy!
- Although the recorded heights were certainly perfectible, the final position as derived through the standard Marcq Saint Hilaire Method is approximately 25 NM from the true one. Could be better, but sometimes – at least in the open sea – one might be quite happy to bag such a result after a full week of forced DR navigation.
- And most importantly, the Marcq Saint Hilaire Method can always be implemented, anytime and anywhere, albeit at the expense (here) of iterations, just to be sure … in case iterations would be required.

*******

Back to dealing this set of observations with a LAN Software.

As correctly noticed, yes! LAN happened earlier than the first observation. It is a bit of a concern, but the most important FACTOR here lies with the culmination height itself since it reaches here almost 85°. As LOW ALTITUDES are to be respected for refraction concerns, similarly HIGH ALTITUDES are equally to be respected given the difficulty to observe them accurately and given additional concern also when processing them as LAN observations.

With “T” meaning here: “UT of Observation – UT of Culmination”, if one uses a times power approximation for the heights around culmination, i.e. fitting the recorded heights to a curve such as:

Observed Height at T = C0 + C1*T + C2 * T**2 + C3 * T**3 + C4 * T**4 + C5 * T**5 + C6 * T**6 + …

… then the higher the Culmination Height, the shorter the “valid time” around culmination time. Also, the lower the representation order, the shorter again the valid time-span for an accurate Heights representation.

As an example, if one attempts least-square fitting observations to better than 0’1 through a quadratic (i.e. square powers of time) approximation – which is the algorithm used here – for a Culmination Height of 85° the maximum valid observation time-span is +/- 2 minutes of time around culmination time. For the same 85° Culmination height, if one attempts fitting observations to better than 1’ (instead of 0.1’) through the same quadratic approximation, the maximum valid observation time-span then becomes +/- 4 minutes of time around culmination time.

Should one wish to significantly increase such “valid time-span around culmination time” it is possible to go for a higher approximation fit. For a 7th order approximation fit and with the same 85° Culmination height, the validity range becomes only marginally increased : 8 minutes around Culmination Time for accuracies equal or better than 0’1, and barely 10 minutes around Culmination Time for accuracies equal or better than 1’. In other words, and when dealing with a given limited number of terms, sticking to Time as the computing variable is NOT a good choice in order to concisely represent heights for high culminating heights. There are other (much) better variables to this effect but this is a totally different and (most) difficult story.

Very important caveat also: when processing noisy data through a LAN Software, the Longitude determination will always be greatly degraded when compared to the noise magnitude. For 1’ RMS degrading the Heights data, with a Culmination height of 85°, the Latitude SDEV will be roughly 1’, but the Longitude SDEV will be close to 7’. If the Culmination Height is lower, things further worsen. With a 45° Culmination Height, for the same 1’ RMS affecting the Heights data, the Latitude SDEV will be almost unchanged to the same 1’ SDEV value, but the Longitude SDEV now becomes close to 15’. And this holds true whatever the chosen computation variable, whether a simple Time variable, or a (much) more performing variable permitting much more concise representing series. This specific point was earlier – and possibly/probably for the first time - mentioned in Mortimer Rogoff’s excellent book “Calculator Navigation” (NORTON Editions).

To get back to our example and given the high noise level in the observations, we should not expect to get any good LAN result when compared to the Marcq Saint Hilaire Method. And in fact, while processing these results through Marcq Saint Hilaire yields a position some 25 NM away from true position, processing them through a LAN software gives a position some 82 NM off.

As a summary, the main reasons why processing the given data through a LAN Software does not give results so good as the Marcq Saint Hilaire Method are:
- Since (UT Culm – UT Observation) is used here a computation variable the actual observations time-span [17h34m27.0s-17h44m09.0s] is well outside the useful time-span permitted by this 2nd order Software (approximately [17h20m-17h27m]. And above all,
- Since this phenomenon occurs whatever the chosen computational variable, the main reason for inaccuracy here comes from the very significant RMS (6.3’) affecting the observations. And, to some lesser extent,
- The observations time-span did not cover Culmination, and finally
- There is a limited number of Observations (6). Own experience has shown that a very minimum should be 12 to 15 observations, especially in case of noise. And by the way, it is always important to have at the (very) least 1° of difference between the highest and lowest recorded heights, a “must” which is totally fulfilled in this example.

Finally I chose to reprocess all these data while assuming that such observations have been corrected into “noise free” observations. If so, this is what they would look like:

- UT1=17h34m27.0s Hs1=84°06’3
- UT2=17h35m38.0s Hs2=83°58’6
- UT3=17h37m39.0s Hs3=83°44’2
- UT4=17h40m20.0s Hs4=83°22’6
- UT5=17h42m10.0s Hs5=83°06’6
- UT6=17h44m09.0s Hs6=82°48’2, which is easy to crosscheck since each of them should yield a 0.0’ intercept this time when using your known true position as a DR position. (Remember: apply only dip, then refraction, Semi-Diameter and Parallax, but NOT Index correction which is zero here.)

Peter’s “noise free” results have now become:

Newly determined Culmination Time UT1 = 17h15m15.0s , while newly determined Position at Culmination has become N24°07’0 W079°42’9

This is - quite surprisingly here - not an improvement to the earlier “noisy” LAN position, most probably explained by the highly “out of useful range” values of the time variable.

*******

I personally have extremely little experience with quadratic (second order) LAN approximations. However and from comparison with higher order approximations, I would trust that its valid time period around culmination time would look like:

Maximum (UT Culm – UT Observations) in minutes = 1/3 * (90° - Culmination Height in degrees),

In other words: for a 84° Culmination Height in our example the permitted observation time span would cover +/ 3 minutes of time around the culmination time.
If the Culmination height becomes 60°, then the usable Observations time span then would cover +/- 15 to 20 minutes around Culmination time.

NOTE: The (only) way to reliably assess such maximum allowable time span is to compute the value of the time variable for which the 3rd order AND the 4th order terms exceed some given threshold (ranging from 0.1’ to 1.0’ for example). There is little practical interest to “tolerate” a threshold higher than 1.0’ since any “noise” in the data yields a “much noisier” Longitude determination. And any value outside the useful time-span becomes a noisy value.

*******

As a final conclusion, I would suggest a recommendation to indicate to the LAN Users the limitations addressed here-above on the LAN computations, both concerning noisy data and concerning the usable time-span as permitted by the operating LAN Software.

Best Friendly Regards to all

Antoine M. “Kermit” Couëtte

PS: From NAS Key-West, when in the US NAVY, I happened to observe the Regulus occultation by the Moon on Jun 18th, 1980 in UT Time, while it was still Jun 17th in local time and date.

----------------------------------------------------------------
NavList message boards and member settings: www.fer3.com/NavList
Members may optionally receive posts by email.
To cancel email delivery, send a message to NoMail[at]fer3.com
----------------------------------------------------------------