| my account | login-logout | resources | classroom help | support | catalog | home | get webcard |

 search | help desk | commons
 » Online Classroom   »   » Public Discussion of Cel Nav   » Lunar distance using Stark's tables (Page 2)

 This topic comprises 3 pages: 1  2  3
Author Topic: Lunar distance using Stark's tables
 Capt Steve Miller posted June 02, 2017 07:47 AM                   IN order for me to check what you have done I need further info.1. What Date did you do your Lunar sight?2. What was your Watch Time of the Lunar Sight?3. What was your measured Lunar Distance (sextant reading) between the Outer of the Moon and the outer of Jupiter?4. What Hc did you use for the Moon and Jupiter?With this info I should be able to check your work even though you left a lot of info out of your posting, just giving generalities with numbers that mean nothing to me.Do you have your forms that you can post? From: Starpath
 navi posted June 02, 2017 11:19 AM                   Form one clearing.Second form and answers to 1-4 to come. From: Chi
 navi posted June 02, 2017 11:20 AM                   From: Chi
 navi posted June 02, 2017 11:33 AM                   1 and 2.1 st of June WT= 09h55m47s CST which means2nd of June 02h55m47s UTC3. Ds= 24deg 53' (already put in my previous posting)4. Hc_Jupiter=44deg13.2' Hc_Moon= 48deg55.6'Furthermore I would not say that I posted "generalities with numbers meaning nothing" If you once again carefully read my posting you will see that at UTC 2 and UTC 3 True LD's of Reed coincide with D#1 and D#2 I founds by using Stark.However when using the Hc's from UTC2 for clearing a sighting close to UTC3 a great error is introduced in Stark's method. That same error is introduced if I put in the same Hc's from UTC2 in Reed's. (If I let Reed calculate the heights from the time I enter I get a better value, indicating that the error steems from Hc's used for the clearing is to far when using UTC2 for a sighting close to UTC3)Hence to use the method without having a true horizon seems difficult since one does NOT know the time of the sighting since that is the unknown to be found! That is what is my worry, as well as the how to handle tables 7 and 8 when D-D#1 gets negative as well as D#2-D#1 gets negative. From: Chi
 David Burch posted June 02, 2017 02:13 PM                   Hi Navi, I think we have enough info here to work this lunar with stark tables, using Hc in place of measured Hs. Back to you with this on Monday or Tuesday.--david From: Starpath, Seattle, WA
 David Burch posted June 02, 2017 02:34 PM                   Is this the right time, date, and location? Here are the calculated distances you should come up with. From: Starpath, Seattle, WA
 David Burch posted June 02, 2017 03:06 PM                   looks like uncorrected distance is 1466.11 nmi = 24º 26.1', then add 15.5' (I understand you used the far side), so the base lunar distance = 24º 41.6'Following through with a computed Lunar, it looks like this measurement would imply that your DR longitude was wrong by about 48', which is about 3 min error in time so not bad for a first round site... or more specifically, a lunar error of 1.6' too small, a rate of 0.405'/min , so a time error of 3m 57s, ie correct time about 2h 51m 50s. Since moon is moving east relative to jupiter, meaning separation is getting bigger with time, you observed a distance that would be seen some time later, so your watch is fast. From: Starpath, Seattle, WA
 Capt Steve Miller posted June 02, 2017 03:54 PM                   I have run the Lunar that you did on 1 June 21:55:47.I think that you can see the errors that you made on the Forms that you sent compared to the data on the sheets I have attached.First I noticed that the SA and MA differ due to the Hc values you used for the Moon and Jupiter. Those differences did ripple through the Forms.As can be see I calculated your UT Error as 53 seconds which is acceptable from your first Lunar Distance calculation. This 53 second translated to a Longitude error of 13.25' again not to bad for your first Lunar Distance calculation. You do get better with a lot more practice.Out of the 80 sets of Lunar Distance observations that I have done, I have had a 10 sec error, an 8 sec error, a 2 sec error, and a 1 sec error.I have averaged approx 75 sec error over the 11 years that I have done Lunars. From: Starpath
 David Burch posted June 02, 2017 04:26 PM                   Here is the form from Steve's note. From: Starpath, Seattle, WA
 David Burch posted June 03, 2017 01:58 PM                   The Stark solution agrees within expected differences from a more exact computed one, so this seems right.Please confirm that this answers your question about the Stark solution. It is one that takes practice and there is lots of room for errors. The only consolation might be that his method is easier and more accurate than was actually used in the days of lunars.The crucial part is clearing the lunars. The last step can be done by interpolation of computed distances at whole hour before and after the sight time, or with a hand held calculator. It is the same formula used for great circle sailing, covered in the back of our text book. From: Starpath, Seattle, WA
 navi posted June 05, 2017 02:40 PM                   Hello!Thanks for your answers. As you point out using UTC 2h0m0s for clearing means my Hc's are different from yours leading to another clearing result than you have leading to error. Since the point of making a lunar is the find the time, does it make sense to do an iterative process? Say as in my case I use the Hc's for UTC 2h0m0s and I get a time of UTC 2h36m47s, does it make sense to use that calculated time to find new Hc's and redo the clearing and get another time. My reasoning is that if I only know a DR position and that the time is between UTC 2 and 3 I must start with some Hc's to get going. The first iteration giving me 2h36m47s is much closer to the true value (2h55m47s) than 2h0m0s so the Hc's will be closer the true time so the clearing will be better. Then I get a new time and can redo this once again. Logically it should converge. What do you think, does it make sense? From: Chi
 David Burch posted June 05, 2017 03:21 PM                   I think we should go back to the basics here and review what is going on.in the lunar, we measure the distance between body and moon. then we clear the distance, which means account for all corrections to get the true observed distance, center to center of the two bodies. There are several factors that go into this, a large one being the limb used, i.e. in star to far edge of the moon, you have to take out the semi diameter to get to the center. on a close edge you have to add it. then there is refraction and a couple other small corrections, but you end up with cleared lunar distance. i think your result was 24 27.8’ This you found from a given DR and at a specific time. our job is to find either the correct time, i.e. error in what you used, or a corrected DR. These are equivalent.once you know time used and cleared distance, then we simply compute what the cleared distance is over some time interval that spans what you used. Generally this is easiest using a whole hour of UTC, so you do the computation for whole hour before and whole hour after. this gives you two lunar distances. You then just interpolate to find the right time. i.e. given T1 and LD1 and T2 and LD2, and your LDx, find the time TX that gives your Ldx. that is then the correct time, and the difference between that and the time you actually used is your error in time.this last step of finding two LDs at two times does not require stark tables, you can just compute it as i did in a note above. Stark just gives you an easy way to do this without other tables of computation.the time interval used for this last step interpolation does not matter. In the old days, the almanacs included precomputed distances for selected bodies every 3 hours. From: Starpath, Seattle, WA
 David Burch posted June 05, 2017 03:25 PM                   note we can think of this as finding Lon, as we can always know our true Lat without time. At sea any two stars will give your lat correct, or in a lunar if you measured Hs body and Hs moon, you could use those to find Lat. The Lon will be wrong by your time error, but the Lat will be right From: Starpath, Seattle, WA
 David Burch posted June 05, 2017 03:54 PM                   and to be a bit more specific about your comment: the Hc values do not enter in to the process at all. you do not need Hc to find the LDs being used for interpolation. it is just a great circle computation between the two GPs. In fact, as you have seen from the stark tables, you do not need the Hcs for finding the LD in the first place. These enter in arguments for the refraction and other moon corrections and do not have to be precise. If they did happen to be way off, then we could always iterate. ie, take known Lat (we can always assume we know that) then find watch error, then if large, we correct the watch time and do it again. From: Starpath, Seattle, WA
 navi posted June 05, 2017 06:28 PM                   Hi,I recalculated with Hc's of 2h55m47s and got about 3 min error just like you.In this case Hc moon is about 7 degree different between 2 and 2h55m47s that seems enough to throw of the clearing. Planet Hc is about 2 degrees different. Maybe in practice on either has a sea horizon or a watch with an error that is 5-10 min then the difference in Hc will be less dramatic.In a few weeks I will be on the sea and will try out real Hc's. Lat 62 Lon 17E. From: Chi

 All times are Pacific This topic comprises 3 pages: 1  2  3