IRAC High Precision Photometry
Definition of Timing Keywords in Headers
Both UTCS_OBS and ET_OBS use the standard convention of offset from J2000 which is definedas 2451545.0 TT (Terrestrial Time) and January 1, 2000, 11:58:55.816 UTC. ET_OBS and UTCS_OBS are both ephemeris times in the sense that they refer to a clock in the Spitzer reference frame and differs from Earth based clocks by the light travel time difference of the observed event and GR effects. UTCS_OBS uses the UTC time system and includes leapseconds and the offset from the International Atomic TIme (TAI). ET_OBS is in the TDB (Barycentric Dynamical Time) system as defined by the JPL CSPICE routines used to calculate ET_OBS from the internal spacecraft time and standard timing kernels.
The difference between UTSC_OBS and ET_OBS is in the time system used. UTCS_OBS differs from ET_OBS by addition of leap seconds, the offset in the definition of TAI to UTC and GR effects (accounted for in ET_OBS) which are lost in the precision that the time is reported. ET_OBS is counted from Julian date 2451545.0 which is 64.186 seconds earlier than the epoch UTCS_OBS is counted from. As of 2009, ET_OBS - UTCS_OBS = 66.186 seconds, 2 of those seconds are for leapseconds, the remaining offset is the difference between the zero point of the clocks, 64.186 seconds. That is the reference time for ET_OBS is 64.186 seconds earlier than for UTCS_OBS. The reference point for ET_OBS is J2000 or Jan 1, 2000 12:00:00 TT or Jan 1, 2000 11:58:55.816 UTC.
MJD_OBS is the modified Julian date using the UTC time system in the Spitzer reference frame. That is, it is UTCS_OBS converted directly to Julian day. HJD_OBS is the heliocentric Julian date as calculated using the observed position. It correctly accounts for the difference in light travel time between a heliocentric observer and Spitzer for the specified observation.
Timing Offsets Between Frames
UTCS_OBS is the start of IRAC data taking sequence, that is the initial reset modulo timing uncertainties between the spacecraft and the IRAC instrument (less than 70 ms worst case, 20 ms is probably a decent estimate of the uncertainty). It is approximately 8.221 ms before the first pedestal read of an integration.
The mid time of an individual subframe, j (where j runs from 1 to 64), of a subarray DCE is given by
tmid(j) = UTCS_OBS + (j - 0.5) * FRAMTIME + 3.231 ms
where the 3.231 ms is the result of the difference of the initial reset times and one half of an IRAC clock tick (clock ticks are 10 ms in subarray mode). The above quantity is the exact mid point time for the central pixel of the subarray (pixel 16,16 when counting from 1,1 to 32,32).
Each subarray row is read out in 10 micro-s, to find the time of the midpoint for an integration for a particular pixel, in row r, column c:
tmid(c,r,j) = tmid(j) + int((c-1)/4 - 3) * 10 micro-s + (r-16) * 108 micro-s.
The formula takes into account the fact that actual readout size of the subarray is 40x40 pixels and it takes 8 micro-s for each row reset.
Each successive DCE in a subarray AOR is the result of a new commanded integration. There is an inherent latency in the sequencing of commands. The rule is that a data taking command will take the integration time rounded to the next nearest second plus 1 second for commanding overhead. As a result, a 0.4s subarray frame which takes approx (64*0.4s = 25.6s) actually takes 27s. In addition, you need to factor in the amount of time it may take for the next command to be issued by the spacecraft andreceived by IRAC. This is of order 0.4s, but can vary. The latency of 1.82s is around what is expected for normal operations.
Finally, AINTBEG is unfortunately not a good indicator of exactly when an integration occurs due to the design of the IRAC firmware. However,ATIMEEND is the correct time of an integration end.