Celestial Navigation Plugin Redux

[NAV]

Dutch language files for the celestial navigation plugin

[NAV]

I'm (very slowly) testing the plugin, using example data from my navigation textbooks.

My initial remarks are related to the explanatory html file. See the red text hereunder, which refers to the sentence parts in blue.

The plugin is designed to make celestial navigation possible and to provide a visual way to use and verify celestial measurements. The plugin expands the line of position to area of position to show all possible locations based on measurement error. The plugin also displays the true positions (generally a circle, not a line). Also added is the ability to take sights based onbearing instead of altitude. Initially I didn't understand what you mean by this. Using a sextant you can measure vertical angles (altitude of a body above the horizon) or horizontal angles between two points (this last method was mainly used in hydrographic surveying). Using a compass and a pelorus or azimuth mirror you can measure bearings. Usefull for calculation of compass errors, but certainly not for calculation of a celestial fix. I don't see any reason to offer this calculation in a plugin for celestial navigation.

Taking a Sight
A sight is an angular measurement taken of an astronomical body using (typically) a sextant.

• Type The type of sight (altitude or azimuth) determines if you are measuring the angle above the horizon (typical) or the angle to north. You can't measurean angle relative to north using a sextant. Azimuth sights are non-standard because it is typically difficult to measure more accurately than 1 degree which normally results in errors above 100 nautical miles. Accuracy of a vertical sextant measurement doesn't differ from accuracy of a horizontal sextant measurement. Taking bearings of heavenly bodies using a compass is definitely unsuitable to obtain a celestial fix.
• Celestial Body This is the body to sight. It is best to choose bodies that produce perpendicular positions at the fix point. For example, in the northern hemisphere, polaris gives excellent latitude, and either the sun or moon typically give good longitude results. These two bodies can complement each other to give a good fix. Two LOP's (or in this plugin actually Circles of Position) never give a good fix because you can't detect coarse errors in one of the measurements. For a good fix, the minimum number of measurements should be 4. In cases where the bodies move in the same plane (using only sun or planets for example) the error in latitude may be great especially near the equator. If two sights are taken which result in nearly parallel positions where they cross, the accuracy of the fix is much less. In other words: the azimuths of the observed bodies for a fix should differ sufficiently, i.e. at least 30 degrees.
• Measurement Taken as degrees (may be decimal, leave minutes 0) or entered as an integer and the minutes field used. The degrees of certainty determines how wide of an area the plotted line of position will cover. I assume this indicates an expected error in the altitude measurement.
• Date and Time for the sight must be the same as the exact moment the measurement is taken. Time of altitude measurement is normally read from a clock or a watch, or PC-time is used. But anyway, this time should be corrected for clock error (every clock is fast or slow compared to the "intended" time) and for the main difference (normally whole hours) to UTC. The plugin can't handle these calculations presently.
  
• Index error, dip and other corrections are normally expressed in minutes, not in degrees.

[rgleason]

Dear Nav
Nav, Sean and I appreciate very much your observations, thoughts and testing of this plugin. I know we both will be very interested in your suggestions for improvements!! If you have any questions or problems, please let us know.
Thanks
Rick

[seandepagnier]

Originally Posted by NAV

I'm (very slowly) testing the plugin, using example data from my navigation textbooks.
My initial remarks are related to the explanatory html file. See the red text hereunder, which refers to the sentence parts in blue.

The plugin is designed to make celestial navigation possible and to provide a visual way to use and verify celestial measurements. The plugin expands the line of position to area of position to show all possible locations based on measurement error. The plugin also displays the true positions (generally a circle, not a line). Also added is the ability to take sights based onbearing instead of altitude. Initially I didn't understand what you mean by this. Using a sextant you can measure vertical angles (altitude of a body above the horizon) or horizontal angles between two points (this last method was mainly used in hydrographic surveying). Using a compass and a pelorus or azimuth mirror you can measure bearings. Usefull for calculation of compass errors, but certainly not for calculation of a celestial fix. I don't see any reason to offer this calculation in a plugin for celestial navigation.

certainly not? why? I try to make it clear that most users are not interested in this mode, but it can still be used. You probably lack the proper instruments (digital tilt compensated magnetomter) required which is still only accurate to half a degree, but can then from only a single sight (altitude and azimuth) find a position fix. Until digital magnetometers, or for ground-based obervations there are many very accurate instruments, in the past, this method was unheard of. GPS has existed for longer than the digital instruments needed.

When I implement support for lunar sights to compute clock offset will you claim it is unsuitable as well (since the error is similar to azimuth sights.. up to 100 miles)

Taking a Sight
A sight is an angular measurement taken of an astronomical body using (typically) a sextant.

• Type The type of sight (altitude or azimuth) determines if you are measuring the angle above the horizon (typical) or the angle to north. You can't measurean angle relative to north using a sextant. Azimuth sights are non-standard because it is typically difficult to measure more accurately than 1 degree which normally results in errors above 100 nautical miles. Accuracy of a vertical sextant measurement doesn't differ from accuracy of a horizontal sextant measurement. Taking bearings of heavenly bodies using a compass is definitely unsuitable to obtain a celestial fix.
• Celestial Body This is the body to sight. It is best to choose bodies that produce perpendicular positions at the fix point. For example, in the northern hemisphere, polaris gives excellent latitude, and either the sun or moon typically give good longitude results. These two bodies can complement each other to give a good fix. Two LOP's (or in this plugin actually Circles of Position) never give a good fix because you can't detect coarse errors in one of the measurements. For a good fix, the minimum number of measurements should be 4.

Maybe the definition of a good fix should be revised. In any case, I do not know where you came up with the number 4. Keep in mind, in the plugin, the sights are no longer circles (and certainly not lines) of position if they are shifted by a dead reckoning distance and bearing.

Could you explain what you mean by detecting coarse errors in the measurements? I need to understand what you mean so the help file can explain it as well.

• In cases where the bodies move in the same plane (using only sun or planets for example) the error in latitude may be great especially near the equator. If two sights are taken which result in nearly parallel positions where they cross, the accuracy of the fix is much less. In other words: the azimuths of the observed bodies for a fix should differ sufficiently, i.e. at least 30 degrees.

Yes, good additional explanation.

• Measurement Taken as degrees (may be decimal, leave minutes 0) or entered as an integer and the minutes field used. The degrees of certainty determines how wide of an area the plotted line of position will cover. I assume this indicates an expected error in the altitude measurement.

• Date and Time for the sight must be the same as the exact moment the measurement is taken. Time of altitude measurement is normally read from a clock or a watch, or PC-time is used. But anyway, this time should be corrected for clock error (every clock is fast or slow compared to the "intended" time) and for the main difference (normally whole hours) to UTC. The plugin can't handle these calculations presently.

Why can't the user just set their clock correctly? Or do you think there should be a slider bar so the user can drag it back and forth to adjust clock skew and watch the plots change? (can align 4 fixes this way to correct clock skew) or?

• Index error, dip and other corrections are normally expressed in minutes, not in degrees.

I can make these in minutes.

Thank you for the feedback, we can continue to improve the plugin.

[NAV]

Celestial bearings
I didn't know about the existence of digital tilt compensated magnetometers. I'll try to get some info via the internet, although presently - maybe not rightly - I still doubt that those will be suitable for simultaneous measurements of altitude and bearing on a moving vessel. An instrument accuracy of 0.5 degree (I doubt you can obtain that as a measurement accuracy on a moving vessel) is insufficient for acceptable celestial fix results, in my opinion. I know I don't trust the digital compass in my smartphone ...

Good fix
2 non-parallel LOP's always intersect and you can't deduct any possible 'blunder' (called 'mistakes' in Bowditch) you've made in one or both of the measurements or in your calculations (random error).
3 non-parallel LOP's - in practice - give you tree intersections. If the triangle ('cocked hat') gets relatively large, you can conclude that there is likely an unexpected error in one of measurements or calculations, but you don't know in which one.
4 non-parallel LOP's - in practice - give you 6 intersections. If tree of these are close together and three are relatively way off, it's likely that there is an unexpected error in the measurement or calculation of the LOP that contains all three of these last intersections. This allows you to reject this LOP for the calculation of the fix.

More feed back later ....

[NAV]

Time
Of course the observer can set any clock to the correct time. But because all clocks are slow or fast running, the clock time will continuously deviate from the real ('intended') time. Where mechanical or electronic chronometers are used (normally indicating UTC), clocks are never set to the correct time (for not disturbing the daily rate of change of the clock). Instead, the clock time is compared daily to UTC (using radio time signals) and the difference (chronometer error) is recorded in a chronometer logbook to an accuracy of 0.5 second. Also the daily rate of change is recorded. Times of celestial observations are read from the clock and corrected for chronometer error.

If you use a precise electronic wristwatch to obtain the times of celestial observations, the same principle applies.

However, modern electronic (quartz) chronometers can be set to the right time without disturbing the clock rate.

[rgleason]

After a sighting, you can change the time, but perhaps we need a corrections area? Would that help?

[NAV]

Rick,
That's what I would do, because this ensures that the user interface is adapted to the way most observers carry out their observations in practice (as far as I'm aware).

[NAV]

Opening window of plugin
In the opening window of the plugin you can choose for 'Alg' (I don't know what this abbreviation indicates): plane, sphere, cone, cone2. It's not clear to me how this is used. Normally, for nautical astronomy, calculations are done on the sphere.

In the po-file I also see 'Combo!'. I don't see this text anywhere when running the plugin.

Window Sight Properties
The index error (IE) of the sextant can be entered. Perhaps it's more logical to enter the index correction (which is -IE).

When I press 'Set as defaults', the entered values are not saved (I don't see these after closing, and opening the plugin again).

[NAV]

Additional on Time
Modern, professional quarz chronometers can be automatically corrected from radio time signals, thus eliminating chronometer errors.

[rgleason]

NAV,

That's what I would do, because this ensures that the user interface is adapted to the way most observers carry out their observations in practice (as far as I'm aware).

What fields an order would you suggest for the corrections area? Short description too, please. I guess this means that data fields for storing a sighting will have to increase, and I don't know if that creates more trouble for Sean, but he'll advise I am sure.

[NAV]

Originally Posted by rgleason

What fields an order would you suggest for the corrections area? Short description too, please. I guess this means that data fields for storing a sighting will have to increase, and I don't know if that creates more trouble for Sean, but he'll advise I am sure.

Perhaps it is possible to use three additional fields in the Date and Time window, resulting in 3 fields (h,m,s) for chronometer time and three fields for chronometer correction (both chronometer error and difference between ship time and UTC).

[NAV]

The plugin uses the following two step procedure to obtain the fully corrected altitude from the altitude read from the sextant:
1. ObservedAltitude = Measurement - IndexCorrection - EyeHeightCorrection - RefractionCorrection - LimbCorrection
2. CorrectedAltitude = ObservedAltitude - ParallaxCorrection

This is confusing for me. Both Bowditch and the UK Admiralty describe this procedure in the following steps:
Apparent altitude (Admiralty abbr. is H; Bowditch abbr. is Ha)
Ha = sextant altitude corrected for index correction and dip
Observed altitude (Ho)
Ho = Apparent altitude corrected for refraction, parallax and semi-diameter [These corrections are a function of Ha, and are tabulated as Altitude Correction, Additional Correction and Horizontal Parallax Correction in the Nautical Almanac]

The plugin mentions: ObservedAltitude (Ho) = sextant altitude corrected for index correction, dip, refraction and semi diameter [No correction for parallax here].

So, what is called CorrectedAltitude in the plugin, is called Observed Altitude by Bowditch and Admiralty.

Plugin.............Bowditch...............Admiralt y..............Dutch
Measurement..sextant alt (Hs).......sextant alt (Hs).......instrumentshoogte (Hi)
-.......................-..............................-..............................gemeten hoogte (Hg) [=sextant alt corrected for index corr only]
-.......................apparent alt (Ha)....apparent alt (H).......'apparent alt' (Ha)
ObservedAlt.....-..............................-...............................-
CorrectedAlt.....observed alt (Ho)...observed alt (Ho).....ware hoogte (Hw)

[NAV]

In the plugin, the refraction correction is calculated as a function of sextant altitude, instead of apparent altitude (that's what I understand from the Calculations window).

[NAV]

Originally Posted by NAV

When I press 'Set as defaults', the entered values are not saved (I don't see these after closing, and opening the plugin again).

Correction:
Read: ..... after closing, and opening OpenCPN again.