[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GJD to HJD
We _can_ know the shutter open/close times to a few milliseconds
Tom's data may not be that good but it is very easy to make it
that good. Microseconds are hard but anyone with a modem
connection to the Internet can get milliseconds. If you record the
time of the STAMP's confirmation message for the open and close
commands and subtract the transmit time (at 9600 baud) you can get
to milliseconds not that you really need it.
I'm one of those nuts who thinks that if I can gain 0.02 seconds
by only the cost of typing in a dozen lines of code, I'll type it
in. You only do it once.
So a one second error in HJD conversion _could be_ the largest error
source in in the time.
--- email@example.com wrote:
> I am probably misunderstanding Chris. He states:
> >It would appear that
> >the JD -> HJD conversion is the largest source of timing
> >Our computer clocks are very easy to keep to <<1 second.
> >I'd say that unless we can get the error introduced by the
> >to HJD two orders of magnitude below other sources of timing error
> >we keep UTC for the archive. I know we can live with a few seconds
> >of error but it is just plain embarrassing that our data reduction
> >process should be the largest source of error in a measurement.
> The largest sources of experimental error remain the computer
> clock setting, the knowledge of the shutter open/close times, and
> the time smearing due to the finite exposure length.
> Using SLALIB, you should be able to get the GJD->HJD conversion
> to under a second. This conversion is important, as you will get
> +/- 8minutes timing error due to the size of the earth's orbit.
> Again, for long-period variables, an 8-minute error might not be
> important, but for a 2hr eclipser, it can mean the difference between
> seeing an eclipse and missing it.
> The difference between assuming the observer is at the center of
> the earth or somewhere on the surface is +/- 0.02sec, below the
> sources of other error in the calculation. Ignore it.
> Using UTC in the database is fine by me, but just remember that
> you *have* to apply a heliocentric correction to the data before
> using it for analysis.
Home: 310-376-1029 firstname.lastname@example.org
Office: 310-336-5189 Christopher.J.Albertson@aero.org
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup