[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GJD to HJD
Realistically a few seconds error in calculating HJD will make absolutely no
difference to any science done with the Mark IV. Exposures are typically
1-2 minutes in length, so there will be considerable smearing in that
dimension anyway.
I do a lot of eclipsing binary photometry, and typically can calculate the
time of minimum (ToM) for an eclipse to 0.0001 day = 9 seconds. A few
seconds of error in converting to HJD introduces a bias the calculation, but
it is significantly smaller than that due to other errors (e.g.:
uncertainties in the magnitude measurements).
Shawn
----- Original Message -----
From: "Chris Albertson" <chrisalbertson90278@yahoo.com>
To: "TASS" <tass@listserv.wwa.com>
Sent: Friday, June 14, 2002 12:57 PM
Subject: RE: GJD to HJD
> Mike,
>
> You are right about a two second error budget being reasonable.
> but we can do better. I think the real-time control
> program time tags the image in a kind of simplistic way.
>
> Inside the STAMP the command is decoded, a responce is
> sent back down the serial line and a jump made to the
> airplane servo routine. This is more deterministic then not.
> The STAMP does exactly one line of BASIC per clock tick.
> What is needed is to record the exact time of the STAMP's
> command comfirmation message for _both_ shutter's on
> _both_ open and close.
>
> Given your 2 second budget, half is taken by the HJD conversion
> so we must do better on the PC control side.
>
>
> --- "Gutzwiller, Michael" <mgutzwiller@lanvision.com> wrote:
> > Even if the computer clock is accurate to .001 seconds the accuracy
> > of the exposure time is not. The exposure time is subject to several
> > problems:
> >
> > 1) The shutters are a mechanical system controlled through the stamp.
> > 2) The shutters do not open and close simultaneously but in sequence
> > so the I exposure is actually 2 seconds ahead or behind the V.
> > 3) The exposures are an averaged image of 1 to 2 minutes long.
> >
> > For these reasons an error budget of 2 seconds is not out of line.
> >
> >
> > Thanks,
> >
> > Mike G.
> >
> > -----Original Message-----
> > From: Chris Albertson [mailto:chrisalbertson90278@yahoo.com]
> > Sent: Friday, June 14, 2002 12:10 PM
> > To: Michael Koppelman; TASS
> > Subject: Re: GJD to HJD
> >
> >
> > "Perfect" What a word! One centimeter of error and you are not
> > perfect. You would have to know the location
> > of the observer on the Earth's surface and not assume he was
> > at the center of the Earth. I think also you would need to take
> > into effect the pull of the moon on the path of the Earth's
> > orbit. The way I've seen these things done is first you pick
> > an allowable error. Let's say in our case, you picked
> > 0.1 seconds. How far does light travel in 0.1 sec? OK that is
> > your allowed error budget for error in the observers position
> > relative to the sun. Do you need to use a four body (Earth, moon,
> > Sun, Jupiter) model or can the simple two body (Earth Sun) model
> > work? No way to know without doing it both ways.
> >
> > The folks across the way from here run the GPS system. They worry
> > about things like the different speeds of light in air in
> > pressure gradient then in vacuum and special relitivy's
> > effect on a clock in orbit vs. on the ground and still they
> > don't get "perfect".
> >
> > It would appear that
> > the JD -> HJD conversion is the largest source of timing uncertainty.
> > Our computer clocks are very easy to keep to <<1 second.
> >
> > I'd say that unless we can get the error introduced by the conversion
> > 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.
> >
> > --- Michael Koppelman <lolife@bitstream.net> wrote:
> > > I'd appreciate if someone could double-check my calculation. As I
> > > stated,
> > > it is based on the same code as the SLA library, so it should be
> > spot
> > > on,
> > > but I did have to do a few date manipulation things and I'd
> > > appreciate a
> > > double-check. Here are two examples:
> > >
> > > digital [10:47pm] % ./jd2hjd 2452425.6907291 179.470833 6.375277
> > > correction is 0.001791
> > > digital [10:41pm] % ./jd2hjd 2452431.6260590 179.470833 6.375277
> > > correction is 0.001234
> > >
> > > The arguments above are jd, ra and dec.
> > >
> > > This matches within 4 seconds of Lew Cook's spread sheet. He claims
> >
> > > accuracy near 3 seconds. Can anyone check this with something known
> > > to be
> > > perfect?
> > >
> > > Thanks!
> > > Michael Koppelman
> > >
> > >
> >
> >
> > =====
> > Chris Albertson
> > Home: 310-376-1029 chrisalbertson90278@yahoo.com
> > Cell: 310-990-7550
> > Office: 310-336-5189 Christopher.J.Albertson@aero.org
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! - Official partner of 2002 FIFA World Cup
> > http://fifaworldcup.yahoo.com
> >
>
>
> =====
> Chris Albertson
> Home: 310-376-1029 chrisalbertson90278@yahoo.com
> Cell: 310-990-7550
> Office: 310-336-5189 Christopher.J.Albertson@aero.org
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>