Almanac & Sight Reduction app

[jdc]

Yet another one. Rather late for this season, but if anyone finds it useful then I'll tidy it and re-issue for 2013.

Screen shot here:

and URL here www.awelina.co.uk/sextant/JavaScript_Sextant_calcs.html

Also included is a great circle route calculator. Screen shot here:

and URL here www.awelina.co.uk/sextant/GreatCircle_latest.html

Nothing very new in either, but you can download the source files and run them on a lap top or on a smart-phone. I use them anyway. Constructive criticism or suggestions welcome as always.

 

[davidaprice]

I think smart phones are very good for running this kind of app, as they can use the GPS signal to provide a very accurate (atomic!) clock, making your calculated fixes much more precise.

 

[oldvarnish]

I think smart phones are very good for running this kind of app, as they can use the GPS signal to provide a very accurate (atomic!) clock, making your calculated fixes much more precise.

I think there is a difference between satellite time and celestial time.

About 20 seconds according to this:

http://leapsecond.com/java/gpsclock.htm

 

[Skylark]

It looks like a commendable piece of work........but.....it's not for me, thanks.

I'm not a professional mariner and learned a little celestial navigation for "the fun of it". I derive a certain enjoyment out of using the almanac, tables and the long-hand sight reduction process. It's time consuming, prone to making mistakes and requires bulky reference material but is very satisfying.

By the time I've taken a series of half a dozen fornoon sun sights, plotted their results, chosen a "best fit" altitude and time, corrected to Ho, reduced the sight, plotted the PL, it's time to take the afternoon series!

What else is there to do

 

[oldvarnish]

What else is there to do

Quite right! On a very easy recent ocean crossing I did a couple of sights a day and reduced them by the longest method possible. You need something to pass the time and you can't read novels all day.

In fact, if brain activity prevents degenerative brain diseases, as they say, then daily sight reduction ought to be compulsory over the age of 55!

 

[nigel1]

I think there is a difference between satellite time and celestial time.

About 20 seconds according to this:

http://leapsecond.com/java/gpsclock.htm

Sort of true, but the GPS satellites get a correction uploaded, and this is transmitted to GPS receivers every 12 minutes The only time this could be an issue if is your GPS receiver has been off, and lost internal memory, and then when you switch on, for a period for up to 12 minutes, your GPS could be displaying GPS time. As soon as the correction is received, it will update and show UTC

 

[nigel1]

It looks like a commendable piece of work........but.....it's not for me, thanks.

I'm not a professional mariner and learned a little celestial navigation for "the fun of it". I derive a certain enjoyment out of using the almanac, tables and the long-hand sight reduction process. It's time consuming, prone to making mistakes and requires bulky reference material but is very satisfying.

By the time I've taken a series of half a dozen fornoon sun sights, plotted their results, chosen a "best fit" altitude and time, corrected to Ho, reduced the sight, plotted the PL, it's time to take the afternoon series!

What else is there to do

I'm having fun teaching a deck cadet celestial nav at the moment. Pretty shocked at how little the nautical colleges now teach about celestial, but still, they could do better.Seems the college give them a hand out with a formula for reducing a sight by calculator, and consider thats enough.
Today, I reduced a sight using Nories tables in about 5 minutes, the cadet still trying to work out which way to apply longitude to GHA

 

[AntarcticPilot]

Sort of true, but the GPS satellites get a correction uploaded, and this is transmitted to GPS receivers every 12 minutes The only time this could be an issue if is your GPS receiver has been off, and lost internal memory, and then when you switch on, for a period for up to 12 minutes, your GPS could be displaying GPS time. As soon as the correction is received, it will update and show UTC

However, a navigational GPS not optimized for time reception (i.e. most GPS units!) will be a second or two off. Making use of the precise time signal requires different hardware/software. Basically you can get a precise location or a precise time, but not both. I think the latter presumes you know where you are, so it can make the appropriate time of flight corrections.

 

[nigel1]

However, a navigational GPS not optimized for time reception (i.e. most GPS units!) will be a second or two off. Making use of the precise time signal requires different hardware/software. Basically you can get a precise location or a precise time, but not both. I think the latter presumes you know where you are, so it can make the appropriate time of flight corrections.

Be nice to know what GPS units do or dont. I had read about this, and checked our 4 GPS units (2 x Furuno 150 and 2 x Kongsberg) and all were spot on time wise when compared to the WWV time signal.

I guess for practical purposes, using GPS time a couple of seconds in error, as the time argument when reducing a sight on a yacht is not going to make that much difference.
Hopefully, someone crossing the ocean will have a SSB receiver and be able to get a time signal.

 

[BobPrell]

Basically you can get a precise location or a precise time, but not both.

Is your name Heisenberg?

 

[John Barry]

Do you use the standard spherical (acos(sin(lat1)sin(lat2)+cos(lat1)cos(lat2)cos(dlong)) formula, or do you use the Vincenty / Andoyer formulae in your great circle calculations?

As a suggestion, allow the entry of almanac ephemeris data for the hour before and after (or the two hour gap that Reeds uses) and interpolate for the sight time.

Do you want more accurate formulae for your ephemerides? or formulae for additional bodies? Depends on how you calculate them of course, and increasing accuracy increases the size of the application. I calculate ephemerides for Sun, Moon, visible planets and navigational stars in a spreadsheet that's about ½Mb.

 

[AntarcticPilot]

Do you use the standard spherical (acos(sin(lat1)sin(lat2)+cos(lat1)cos(lat2)cos(dlong)) formula, or do you use the Vincenty / Andoyer formulae in your great circle calculations?

As a suggestion, allow the entry of almanac ephemeris data for the hour before and after (or the two hour gap that Reeds uses) and interpolate for the sight time.

Do you want more accurate formulae for your ephemerides? or formulae for additional bodies? Depends on how you calculate them of course, and increasing accuracy increases the size of the application. I calculate ephemerides for Sun, Moon, visible planets and navigational stars in a spreadsheet that's about ½Mb.

There is an excellent (free) ellipsoidal great circle calculator called "geod"; it is bundled with the equally excellent free projection software "proj4". Command line only, and a bit unforgiving! But extremely precise; millimeter accuracy is claimed. Not really relevant to yachting, but of value to surveyors and map-makers. The nice thing is that is handles all the nasty cases where using the simple cosine formula is likely to break down.

However, for practical purposes, the cosine formula is amply accurate enough for us, providing you don't hit a pathological case where you're differencing two large numbers to get a small one. I once did some comparisons between it and more accurate methods, and the difference in ocean crossing distances was less than a kilometre.

 

[John Barry]

The cosine formula doesn't breakdown if you're using a computer or modern calculator, so long as you're limiting it to 100th of a minute figures. It breaks down is you're using four figure tables though.

To get mm accuracy the application must be using the Vincenty formula, which is supposed to be accurate to 0.5mm. The trouble is that it's an iterative formula, and sometimes needs many thousands of iterations to deliver a result.

 

[AntarcticPilot]

The cosine formula doesn't breakdown if you're using a computer or modern calculator, so long as you're limiting it to 100th of a minute figures. It breaks down is you're using four figure tables though.

To get mm accuracy the application must be using the Vincenty formula, which is supposed to be accurate to 0.5mm. The trouble is that it's an iterative formula, and sometimes needs many thousands of iterations to deliver a result.

I'm afraid there are (unlikely) situations where it can go beserk, even using double precision floating point. But these are very unlikely to be encountered in practice. However, there will be reduced precision when approaching these singularities; the nominal 15+ significant figures of a double precision floating point will be reduced, possibly to 3 or 4. The real problem is that this can happen silently without the user being aware of the reduction in precision. And, of course, if computations are chained together, you can end up with a complete loss of precision even though each step has some significance. Even successive additions can do that - I know of a case of this in (now fixed) commercial software, where vast errors arose after a few thousand successive additions of a small number to a large one.

I agree that it is unlikely to be a problem in practise, but a programmer implementing the formula for use as a black box would be negligent if these pathological situations were not allowed for. That's where most of the cleverness in "geod" and "proj4" lies - detecting potential problems and coding round them. I can (for example) write projection code for the Polar Stereographic projection in about 10-15 lines of code; "proj4" uses much more because it is avoiding situations that I choose not to worry about!

 

[2nd_apprentice]

I think smart phones are very good for running this kind of app, as they can use the GPS signal to provide a very accurate (atomic!) clock, making your calculated fixes much more precise.

Get's even better: the GPS will give you a position which you can use to calculate the hour angle via almanach. That way you won't have to measure it, resulting in a precise fix. Cool, eh?

 

[jdc]

Do you use the standard spherical (acos(sin(lat1)sin(lat2)+cos(lat1)cos(lat2)cos(dlong)) formula, or do you use the Vincenty / Andoyer formulae in your great circle calculations?

I don't imagine that I've done anything that isn't a standard result, but I used no 'formulae' anywhere except for refraction where I used an empirical formula attributed to Garfinkel. Everywhere else I worked out from first principles. So for great circle I start with a plane through the origin, ax + by = z, and solve for the surface of a sphere of unit radius, x = sin(long).cos(lat), y = cos(long).cos(lat), z = sin(lat).

Do you want more accurate formulae for your ephemerides? or formulae for additional bodies? Depends on how you calculate them of course, and increasing accuracy increases the size of the application. I calculate ephemerides for Sun, Moon, visible planets and navigational stars in a spreadsheet that's about ½Mb.

I would like data for the moon. As you may have observed I didn't yet get around to including the moon simply as I don't have the data.

The aim of the whole exercise was initially to see how accurately I could predict emphemerides with a simple model of the earth-sun system. So I did not use polynomials from the naval observatory for instance.

The only facts I had to just look up or assume were:
- the period of rotation (ie length of year)
- the eccentricity of the earth's orbit
- the 'incline' of the earth's orbit around the sun , aka the obliquity of the ecliptic
- the time and date of the perihelion
- the time and date of the winter solstice in 2011

With only these, and some geometry (made a tad harder by one of the orbital equations being transcendental), I found I could predict GHA and DEC to about 1'. Adding a perturbation due to the earth-moon system rotating about its common centre of mass ('barycentre') allowed me to improve this by another factor of 5 or so. To do this I had to add two more 'facts':

- the distance from the centre of the earth to the barycentre, and
- the time and date of the first full moon of 2012.



What I have found this very good for is teaching. Learning to use astro can be daunting because there are several things to get right simultaneously:

- using the sextant to observe altitude;
- looking up the GHA and DEC and interpolating for the exact time;
- correcting for parallax and height of eye etc; and
- plotting the position line.

What this program has allowed me to do is start with the sextant sight without any of the angst of looking up things or doing algebra. In a few seconds a complete beginner can get results, and I've heard them say 'wow, that was only 1.3 miles out...' which they have found immensely encouraging.

Then as a next step they can work out GHA and DEC from tables, and check immediately that they have got it right or enter these values into the sight reduction part. The idea is gradually to replace the program with manual methods.

 

[John Barry]

If you PM me your e-mail address, or e-mail me at gedanchoku at yahoo dot com I'll send you my Moon spreadsheet (309Kb). It's based on the orbital elements from partial ELP200 data (partial VSOP87 data for the Earth's position) and produces a position that's about as accurate as that given in the almanac (the Earth's position is much more accurate than that - about 1").
To get a significant improvement in accuracy on this you'll need to use a LOT more than the 60 coefficients from ELP200 that I use - the full list contains many hundreds of elements.
The spreadsheet has a lot of information on it that you may not want (phase data, eclipse data, % illuminated, etc) but the calculations are all visible (there's one hidden column on the first worksheet) and you can extract the bits that you want.

 

[Talbot]

If you PM me your e-mail address, or e-mail me at gedanchoku at yahoo dot com I'll send you my Moon spreadsheet (309Kb). It's based on the orbital elements from partial ELP200 data (partial VSOP87 data for the Earth's position) and produces a position that's about as accurate as that given in the almanac (the Earth's position is much more accurate than that - about 1").
To get a significant improvement in accuracy on this you'll need to use a LOT more than the 60 coefficients from ELP200 that I use - the full list contains many hundreds of elements.
The spreadsheet has a lot of information on it that you may not want (phase data, eclipse data, % illuminated, etc) but the calculations are all visible (there's one hidden column on the first worksheet) and you can extract the bits that you want.

Use of the moon for an astronomical position calculation should be the very last choice. The (relatively) shor distance to the moon means that any minor errors of time or angle will have a much greater impact on fix accuracy.

Normally if you can see the moon, there is a good chance that at least a planet or two, and hopefully sufficient stars to get a much better fix.