Celestial Navigation Plugin Redux

[NAV]

Originally Posted by rgleason

... for a new sight after putting in my approx position at the top, I pick NEW, then select a star and hit FIND. The FIND popup shows a lat and long that never change, but the last one Longitude is never correct, so I change it to my approximate location and enter the altitude shown in the previous popup. Of course it is just approximate so the fix is wrong, but it is closer than what pops up initially.
Thanks

The FIND functionality can be used to obtain the approximate altitude and azimuth of a heavenly body (by entering your dead reckoning position), enabling to preset your sextant to the approximate altitude of the body you wish to use for a fix. This makes it easier to find the body when looking to it through the telescope. It's not used for COP or fix calculation.

[rgleason]

Yes I realize that the Find function is not normally used.!!!!
I was using the altitude to test the plugin since I do not have real sights!!! Yes that is not correct way to do it but it allows me to follow along..

Sent from my SCH-I545 using Cruisers Sailing Forum mobile app

[seandepagnier]

Originally Posted by NAV

From the code I understand that the Bennett formula is not used anymore for the calculation of refraction:

/* compensate for refraction */
double RefractionCorrection;
#if 0
/* old correction not used */ THIS IS BENNETT's FORMULA
double Ha = m_Measurement - m_EyeHeightCorrection;
double Ref = 1/tan(d_to_r(Ha + (7.31/(Ha + 4.4))));
double RefImp = Ref - .06 * sin(d_to_r(14.7*Ref + 13));

RefractionCorrection = RefImp * .00467 * m_Pressure / (273.15 + m_Temperature);



Refraction seems to be calculated only by the following code:

#else
double x = tan(M_PI/180 * ApparentAltitude + 4.848e-2*(M_PI/180) / (tan(M_PI/180 * ApparentAltitude) + .028)); m_CalcStr+=wxString::Format(_("\nRefraction Correction\n\
x = tan(Pi/180*ApparentAltitude + 4.848e-2*(Pi/180) / (tan(Pi/180*ApparentAltitude) + .028))\n\
x = tan(Pi/180*%.3f + 4.848e-2*(Pi/180) / (tan(Pi/180*%.3f) + .028))\n\
x = %.3f\n"), ApparentAltitude, ApparentAltitude, x);
RefractionCorrection = .267 * m_Pressure / (x*(m_Temperature + 273.15)) / 60.0;
m_CalcStr+=wxString::Format(_("\


I can't relate this to any formula I've found, although a small part of it seems to be similar. In the Admiralty Manual the following procedure is described:

"Calculate refraction (R) at a standard temperature of 10 degrees Celsius and pressure of 1010 mb:
R0 = 0.0167 degrees/TAN(Ha+7.31/(Ha=4.4))
If temperature T in Celsius and pressure P in mb are known, calculate the refraction from:
R = f*R0 where f = 0.28P/(T+273)
otherwise set R=R0 "

Sean, can you please advice me what formula you are using and why?

The problem is, I wrote the celestial navigation way back in 2010, before plugins even existed, and because it was considered not a core feature, it prompted dave to create the plugin system to allow for such things.

I basically then left it until last year, but unfortunately I cannot ask myself from 4 years ago since I forgot.

Originally Posted by NAV

"Calculate refraction (R) at a standard temperature of 10 degrees Celsius and pressure of 1010 mb:
R0 = 0.0167 degrees/TAN(Ha+7.31/(Ha=4.4))
If temperature T in Celsius and pressure P in mb are known, calculate the refraction from:
R = f*R0 where f = 0.28P/(T+273)
otherwise set R=R0 "

QUOTE]

In the Nautical Almanac of 2005 the bold formula above (read '+' for the equal sign after the second Ha) is slightly different:
R0 = 0.0167 degrees/TAN(Ha+7.32/(Ha+4.32))

Is the Nautical Almanac the authority on these figures? I will try to research this formula and the one before to determine the best formula to use.

Originally Posted by NAV

While checking the calculation of altitude corrections (for Sun LL, Sun UL, Moon LL, Moon UL, Venus and Polaris) I do find differences >0.1' for Semi Diameter, Refraction, Horizontal Parallax and Parallax in Altitude. This must be caused by the formulas used, which differ from those used in The Admiralty Manual (and in the Nautical Almanac) for the example data.

E.g. for the Moon LL example I find HP=0.9475 and PA=-0.7890, while the example data give HP=0.9100 and PA=-0.7598 (differences of 2'.25 and 1'.75).

I believe it is possible that my almanac especially moon data is potentially more accurate than what the nautical almanac is using, but need to verify this. I'm assuming the differences are less for the other bodies correct?

Can you verify that the calculations are at least being performed in the correct order?

Can I download the nautical almanac you are using so I can make some comparisons as well? I also have used stellarium which has it's own almanac for comparisons.

Originally Posted by NAV

The 'problem' is this:
1. For the calculation UT of altitude measurement must be used for the calculation (this UT must be entered in the time entry fields).
2. You read the time of altitude measurement from a clock (or from watch or from a computer). In almost all situations this time is not equal to UT, so it must be corrected before you can input the UT in de time fields.

I intended the user to click add exactly when they are reading the sight.. in any case, they can edit the UT after if this is not the case. Is this still a problem?

The quote you give from the Information page, refers to a change of position (distance, course) between your first observation and a second one. Usually this applies when taking a sun sight in the morning and a sun sight at noon. For both sights the correct UT of both measurement should be used for the calculation. The resulting LOP of the first sight can be moved to the second sight LOP by moving it over a distance equal to the time difference between the sights times the speed, to obtain a fix of two LOPs at the time of the second measurement. The plugin doesn't use LOP's though, but COPS, for which this cannot be done as I understand from the explanation. Of course the accuracy of a fix based on one shifted LOP and another one, is less than a fix of multiple star LOP's taken at about the same time (say within a period of about 10 minutes) in morning or evening twilight.

The plugin doesn't use LOP or COPS. More accurately it uses areas of position. These areas appear as circles if they are not shifted, but once shifted by a dead reckoning estimate (distance and bearing), they are no longer circles, this becomes obvious if shifted over a long distance on a bearing toward a pole for example, or if shifted based on magnetic bearing. The plugin cannot use least-squares to find the "fix" latitude and longitude once shifted in this manner because the math is insane. It might not even be possible for magnetic bearing shifts. So instead, the fix must be determined visually for running fixes. (possibly poor explanation in the doc)

Originally Posted by NAV

Yes, all users want to save sights, I expect. And if they don't, they should in my opinion. So, preferably this functionality should be build into the plugin. As long as this functionality is not available, use a notebook for sights only.

This has been requested before, so I will try to implement this using xml files.

Thanks again for your interest.

[rgleason]

Sean thanks for bearing with our questions.

[NAV]

Originally Posted by boat_alexandra

Is the Nautical Almanac the authority on these figures?

For nautical navigation: yes. Both Bowditch (US) and The Admiralty Manual of Navigation (UK) refer to it (and are each authorities too).

Originally Posted by boat_alexandra

I believe it is possible that my almanac especially moon data is potentially more accurate than what the nautical almanac is using, but need to verify this. I'm assuming the differences are less for the other bodies correct?

I don't expect that the almanac is the cause of larger differences. I only looked into the calculation for the bodies I mentioned (sun, moon, 1 star and 1 planet).

Originally Posted by boat_alexandra

Can you verify that the calculations are at least being performed in the correct order?

For the first part (Ha): yes. I've to look further into the second part (I had a first impression that something has to be altered too).

Originally Posted by boat_alexandra

Can I download the nautical almanac you are using so I can make some comparisons as well?

I'll send you some data. The official Nautical Almanac (UK and US) is not available as a digital document.

Originally Posted by boat_alexandra

I intended the user to click add exactly when they are reading the sight.. in any case, they can edit the UT after if this is not the case. Is this still a problem?

This procedure can only be used when two crew are available to do the measurements: one for the altitude measurement (shouting "stop" or "mark" at the time of measurement, and one to note down or input the time (from clock, watch or computer). This time should still be corrected to make it the correct UT.

[NAV]

An extract of the Nautical Almanac of 2005 can be found here:
The Nautical Almanac 2005 - Great Britain: H.M. Nautical Almanac Office - Google Boeken

See pages 277 up to 283 for the part that deals with the methods and formulae for sight reduction using a computer or programmable calculator.

[seandepagnier]

Originally Posted by NAV

This time should still be corrected to make it the correct UT.

This was a bug fixed now,


For a single person crew, you may have to use a stopwatch, or count seconds after taking the sight. What do you suggest?

[seandepagnier]

delete double post

[NAV]

Originally Posted by boat_alexandra

This was a bug fixed now

Do you mean that the plugin calculates UT from computer time when the numbers in the time entry field are entered? If so, I don't understand how that is possible. Can you explain this?

Originally Posted by boat_alexandra

For a single person crew, you may have to use a stopwatch, or count seconds after taking the sight. What do you suggest?

Both methods can be used. But you loose the original time entered in the plugin when a correction to obtain UT has to be applied. So it's safer to write it down first in this case.

[NAV]

For those interested:
Digital copies of Bowditch can be obtained from: http://www.fer3.com/arc/navbooks2.html

The last edition (2002) is a complete document. The previous edition (1995) per chapter. Chapter 20 deals with sight reduction.

[NAV]

When using the Find functionality and entering a position near IJmuiden, Netherlands (52 30 N, 004 30 E), the difference between the calculated true and magnetic azimuths of the body (Sun in this case) is 14 degrees. This is not correct: the local variation is only 0.4 degrees E.

[seandepagnier]

I have entered in 52.5 and 4.5 into the find dialog, and with check and uncheck magnetic box I get a difference of 0.4 degrees.

[NAV]

Originally Posted by boat_alexandra

I have entered in 52.5 and 4.5 into the find dialog, and with check and uncheck magnetic box I get a difference of 0.4 degrees.

Strange .. See attached picture(s):

I don't succeed in attaching the second picture to this mail. For this one I finally managed (trying it about 20 times in different ways), but the functionality seems not to work for me.

[NAV]

The second picture(but still no success):

[rgleason]

Nav I was told by the moderator Frank to try clearing my browser cache. It seemed to start working again. Sorry about the trouble.

Sent from my GT-N5110 using Cruisers Sailing Forum mobile app