NavList:
A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding
Re: Direct methods
From: Gary LaPook
Date: 2007 Nov 09, 01:43 -0800
From: Gary LaPook
Date: 2007 Nov 09, 01:43 -0800
Gary LaPook adds: The program I used for the almanac computations came from the "Almanac For Computers" from the U.S. Naval Observatory which provided factors to use for a power series form of computation. There were five constants (actually five each for the declination and for the GHA, a total of ten)) for each of the planets, five for Aires, three sets of five for the sun, (the third set for computation of S.D.) and the constants were usable for a calendar month. The moon had four sets of seven constants only good for a week, the fourth set for computation of H.P. This publication was discontinued after the 1991 edition. Did anybody else make use of this publication? gl On Nov 9, 1:30 am, glap...@PACBELL.NET wrote: > Gary LaPook writes: > > Your post reminded me that back in 1979 I wrote a similar program to > run on my Texas Instruments TI-59 which was programed off of small > magnetic cards and ran a machine language code. I found the coding for > the program but I apparently threw away the books that came with the > TI-59 so I can't decode the formula I used to do the computation and I > can't find a copy of the formula. I then adapted and expanded the > program to run on a Casio PB-1000 and I printed out that coding but > its been so long I am having a hard time figuring out just what the > program is doing. I am trying to figure out the formula I used but it > looks different than yours since it uses sines and cosines of the Zn > and these quantities squared plus the intercept but no usage of tans. > > The program worked very well. I would enter in the departure point and > destination, the heading since the last fix and airspeed, the fix time > and the names, times and altitudes of two or three star shots. The > program would compute the coordinates of the bodies, correct the > sextant altitudes (including coriolis), would adjust the sights for > movement of the plane and of the body to the common fix time and > display the fix location. Then it would display the track and ground > speed since the last fix and the actual wind encountered since the > last fix using the inputted airspeed and heading combined with the > track and ground speed it had calculated. It then displayed the > heading to hold to reach the destination to correct for the wind that > had been encountered, the predicted ground speed (also based on the > computed wind) and the estimated time of arrival. It then remembered > all of these values so at the next fix the only new information that > needed to be entered was fix time, names, times and altitudes of the > sights, airspeed and heading and it would do the computation all over > again. > > Since I am not a great mathematician I had to use an approximation to > calculate a three body fix. The program figured out the latitude and > longitude of the two body fix and then used that as the AP for > calculating the intercept and Zn for the third body. It then used the > bisector of the LOPs at the first fix in the direction of the third > LOP and moved the fix along that bisector two thirds the length of the > third intercept as an approximation of the center of the "cocked hat" > and then also displayed the length of the third intercept to provide > some sense of the accuracy of the fix. I was happy with the results > even though the programing was inelegant. > > gl > > On Nov 1, 3:53 pm, "George Huxtable"> wrote: > > > d walden's first posting with its attachment came over successfully to me. > > It may present problems to anyone that doesn't have Excel aboard as his > > spreadsheet. > > > He wrote- > > > | It is of course possible, as has been pointed out, to calculate the > > latitude and longitude of the points of intersection of two circles of > > position directly with neither an estimated nor an assumed position. Nor in > > fact are altitudes and intercepts or any plotting needed. The intersection > > of cones method, described by Frank in the discussion of latitude by lunars, > > and shown in a previously posted FORTRAN and Maxima example can be used. A > > few minor changes to the programs posted are needed. > > | > > | The problem is, in fact, slightly easier. It can be done with > > intersecting planes. The attached little spread sheet is an example of how. > > One enters with the altitude, declination, and GHA of two bodies. Out come > > the latitudes and longitudes of the two intersection points. If you have > > three bodies, pick a different pair, and two of the points should wind up > > quite close. There you are. > > | > > | Seems to be working for me, but no guarantees. > > > =================== > > > For completeness, if nothing else, I resend an attachment which originally > > went out to the old Nav-L list on 12 June 06, under the threadname > > "positions from crossing two circles". That provided a routine, written in > > Bastard-Basic for a Casio pocket-calculator, to determine the two possible > > positions that result from crossing two observations. It also explains how > > the thing works. > > > I remember that Andres followed it up with a posting in which he had > > converted it to a program written in C. > > > George. > > > contact George Huxtable at geo...@huxtable.u-net.com > > or at +44 1865 820222 (from UK, 01865 820222) > > or at 1 Sandy Lane, Southmoor, Abingdon, Oxon OX13 5HX, UK. > > > intersecting circles.rtf > > 41KDownload --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to NavList@fer3.com To , send email to NavList-@fer3.com -~----------~----~----~----~------~----~------~--~---