NavList:
A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding
Re: Angular Distance Between Stars By Camera and Sextant
From: Paul Hirose
Date: 2012 Sep 19, 13:50 -0700
From: Paul Hirose
Date: 2012 Sep 19, 13:50 -0700
Marcel Tschudin wrote: > But how did you, Paul, obtain for the > Alioth-Alkaid refracted distance the 10.455432°? I was not able to > reproduce this value. Transferring e.g. the Dec, GHA and Hc values from > Andrés' program into Bill's Excel sheet I obtain Alioth-Alkaid refracted > distance of 10.457595°, or when using Frank's refraction approximation > 10.457409°. Marcel, here are the unrefracted and refracted coordinates from the program by Andrés. >>>Calculated altitudes: >>>Hc1 = 28.317414 >>>Z1 = 320.442970 >>>Hc2 = 34.115333 >>>Z2 = 310.248963 >> Refraction: >> >>>R1 = 0.028946 >>>R2 = 0.023032 >>>Apparent altitudes: >>>Ha1 = 28.347441 >>>Ha2 = 34.139225 Convert the refracted spherical coordinates to vectors. Although azimuth doesn't follow the normal convention for the "theta" angle in spherical coordinates - its zero point and direction of increase are different - both bodies are affected the same way. Thus, if we use azimuth as theta, the relative positions are still correct. Alioth = (.678537, -.560478, .474817) Alkaid = (.534770, -.631719, .561206) Let x = dot product of the vectors = .983396 Let y = magnitude of the vector cross product = .181471 Convert (x, y) from rectanglar to polar. Angle = 10.455432°. On my HP49G I wrote a program to do that. And this calculator (which is about 12 years old) can assemble a vector from spherical angles, so there's no need to convert to rectangular form. The advantage of the vector method is high accuracy, whether the angle is large, or microseconds of arc. With the cosine formula of spherical trig, you got poor accuracy near 0 or 180°. It's not necessary for the vectors to have the same magnitude. The only restriction is than both magnitudes must be nonzero. > Here I misinterpreted "Apparent" to relate to refracted whereas they > "possibly" relate to "true" or air-free coordinates. Their J2000 values > show some differences to the Simbad FK5 values: That's one reason I don't like CalSky. They don't precisely explain the basis of their data, unlike the JPL HORIZONS site. But HORIZONS does not do stars! > I do not know the capabilities of MICA. May be someone who is familiar > using it could explain up to which point it could help calculating > refracted star-star distances. MICA appears to have the advantage of being > available to Windows and Mac users. MICA can calculate azimuth and unrefracted zenith distance (= 90 - altitude). Although it's claimed to be suitable for celestial navigation, it does not have a refraction model, will not display altitude, and displays angles in DMS.s format only. It does have a large star catalog with HIPPARCOS data. The reduction to apparent place seems accurate, but the transformation from GCRS to true equatorial coordinates uses the old IAU 1976/80 precession nutation model, and fails to apply frame bias. This is not significant at navigation accuracy, but annoying to a user who expects the best. Time may be input in UT1 or TT. The delta T function is built in, and cannot be set manually. At present, the value is about 2.1 s high. The error be completely corrected by applying a bias to UT1 and the observer's longitude. Well, it could be, except that time can only be input to .1 s precision. A body can move up to 1.5" in .1 s, so the coarse time input prevents MICA from attaining its potential accuracy. The solar system ephemeris is the DE405, I think. I have no complaints about its accuracy, except for the remarks above. What I have said applies to version 2.0. It is not all true for later releases, according to the USNO site. http://aa.usno.navy.mil/software/mica/micainfo.php One interesting remark: "Lunar distance has been added to the "Phases of the Moon" output table." An alternative to MICA is my free Tinyac almanac program. In fact, my disappointment with MICA was the motivation for writing Tinyac. Its precession nutation model is IAU 2006/00A, the state of the art. The user has total control of delta T. (At the present time you MUST enter delta T manually, since the "auto delta T" feature has exhausted its internal table.) Time may be input, and is calculated, to nanosecond resolution. All angle formats - DMS.s, DM.m, and D.d - are available for input and output. Reductions to apparent place use the rigorous procedure in The Astronomical Almanac, including General Relativity. Tinyac duplicates the stellar and planetary reduction examples in the Almanac to full accuracy. It does have several defects. Unlike MICA, there's no internal star catalog. You must copy and paste the catalog coordinates into Tinyac's input screen. It cannot store a set of observer locations. At startup it doesn't even remember the last location you entered. And it only calculates coordinates for one time. You can't get a table at, say, every minute for a given time span, is in MICA. Tinyac calls the SofaJpl DLL, so it's affected by the minor refraction bug I mentioned in another message. And a 4" bump occurs at 15°, the transition between the high and low altitude refraction formulas. A few readers may find Tinyac useful for an occasional unusual job, or to get a second opinion on a body's coordinates. It's too elaborate and unfriendly for the ordinary navigator. You can't beat the price, though. http://home.earthlink.net/~s543t-24dst/tinyac/index.html --