|
|
|
|
|||||
|
||||||
Subject: Re: September Equinox computation
From: John Kabel (jjkabel@XXX.XXX)
Date: Tue Sep 24 2002 - 20:30:04 EDT
I have done the computations with my HP 48GX, using the Sparcom NAV48
Celestial Navigation pack authored by Tom Metcalfe. This system is
based on Meeus, with an internally calculated almanac based on the JPL
ephemeris. Now, the results are nowhere near precise enough to
numerically indicate where the shift from N to S declination occurs.
In fact, the results show a 0d00.0' declination over a span of some
five minutes. But the shift in the letter occurs from 4:55:24 to
4:55:25. And the crossing is at 104d16.8'.
Another "estimate" for the crew to consider. I suspect this program is
using a lot of decimal places internally, then rounding up for the user
only to the nearest 0.1 arc-min. This pac has always been very
accurate for me in previous work.
John Kabel
London, Ontario, Canada
> Hi guys,
>
> I was already wondering how Dan Allen could be off by more than 3 minutes
> using Meeus' algorithm, but no way did I believe that the JPL ephemeris plus
> Novas routines could be early by 3.5 minutes, whether its all written in
> Fortran, C or Cobol.
>
> So I plug the numbers into my carefully re-written Pascal version of the
> Novas routines using DE200 and obtain (by doing what I described in my
> earlier message) for the time of this year's autemnal equinox 4:55:24 UT1.
> This value has the advantage that it agrees with what Meeus publishes in
> "Tables of the Sun, Moon and Planets", as well as with what the USNO thinks
> it should be. (see Earth's Seasons, etc. 1992-2005 ). This is probably not
> a coincidence.
>
> Herbert Prinz
>
> >
> > Jay Borseth wrote:
> >
> > The results I'm getting put the equinox at:
> >
> > 4:51:54 AM GMT on 23 Sep 2002, crossing at E 105 degrees 9' 56".
> >
> >
> > Dan Allen wrote:
> >
> > PS - My computations for this year put the equinox at 4:52:04 AM GMT on
> > 23 Sep 2002.
|