Occasionally there are features in the data which are not regularly seen and are likely not of astrophysical origin. These include rare events on the spacecraft or detectors. In this section, we discuss known data features and our understanding of their causes.
D.1.1 Header Keywords
There are a couple of header keywords that should be consulted for issues before performing high precision photometry. These include MISS_DATA and MISS_LCT. These have been found in the 55 Cnc dataset AORKEY 48070144, EXPIDs 353 and 6399. The symptom is a position problem in the frames. If MISS_DATA = T and/or MISS_LCT is greater than 0, there is likely a problem with missing data. Images with these header issues should not be included in the data analysis.
Another header keyword that may indicate a problem is BADTRIG. Such a problem can be found in the 55 Cnc dataset AORKEY 48072960, EXPIDs 7950, 5259, and 9256 among others. This problem manifests itself as centroids of whole images being off in x-direction (in BCD coordinates). In the headers of these images BADTRIG=T, and ZEROPIX is greater than 1 (often ≈ 4800). An occasional problem was observed during the warm mission wherein an extra byte appeared in the science packet (image data). As a result, all pixels after this byte are shifted by one pixel. Such images are identified by having the ABADDATA header keyword set in the raw data (BADTRIG in the BCD images); the images themselves usually become stripy as a result of the mismatch between the science and calibration data. The SSC pipeline corrects this by locating the first pixel in the image with a value of exactly 0, and then shifts all later pixels.
In the case of these images, there is more than one ZEROPIX, so the pipeline cannot correct the images for the shift in pixels. Images with these header issues should not be included in the data analysis.
Figure D.1: A BADTRIG problem in staring mode data. Left side vertical axis is for the grey lines and wheel speed RPM. The right-side vertical axis corresponds to x (blue) and y (green) centroids of the AOR as a function of sclk time. BADTRIG is set for the x-positions which have centroids of 14.5 after sclk time of 1.058017x109.
D.1.2 Skydark Change in the Middle of an Observation
Observers that use long staring mode observations, including exoplanet observations and brown dwarf monitoring observations, should be aware that the applied skydark may have changed in the middle of the observation. This change is possible due to the dynamic nature of the skydark determination, which chooses the best dark that is nearest in time to a given BCD (single image). For observations that do not require high relative precision, the current calibration assures the best absolute photometric calibration.
The change in skydark will cause a small jump in the stellar flux and background levels, when inspected as a function of time. To check whether this happened, one can check the FITS header of a BCD file taken near the beginning of the continuous observation, and look for a header keyword SDRKEPID, which is found under the “DATA FLOW KEYWORDS” section of the header. Compare the value of this keyword to the same keyword value in a BCD taken near the end of the continuous observation. If the SDRKEPID is different, the applied skydark has changed during the observation. The pipeline has been configured so as to prevent this from happening in high relative precision observations, but it is possible that this problem could have slipped through for some datasets.
D.1.3 Background modulation
This has been seen in a number of AORs, although it is not very common. The modulation is of order one electron for roughly two hours, although the duration varies (see Figure D.2). We do see that the signal is correlated. Over the same period that the background levels modulate, we see a similarly shaped decrease in the background uncertainty values.
Despite intensive checks, nothing in the telemetry appears to change during the time of the modulation nor are there changes in the telemetry that correlate with frequencies seen in the modulation. The signal does appear to be correlated, in that if one connects the dots (Figure D.3) there is coherent structure in the background modulated by an expanding and contracting envelope. There is similar coherent structure in the background sigma. The noise in the background only goes down during that time. There are what look like gaps in the waveform, corresponding to regions where the background is extremely correlated over timescales of about five minutes. These gaps seem to be synchronized with extrema in the position sawtooth. This is somewhat similar to frequency modulation (FM) and amplitude modulation (AM) signals.
There is no evidence of the background modulation affecting photometry.
Figure D.2: Background measured in electrons as a function of time for 0.02 second subarray data.
Figure D.3: Same as Figure D.2, only now with each data point connected by a line, and zoomed in on the background modulation portion of the light curve.
D.1.4 Noise Pixel Spikes
A few times over the course of the mission the number of noise pixels has been seen to sharply increase in value for a short duration (≈ 30 min) before returning to normal (see Figure 8.12, at 16 and 30 hours). These noise pixel spikes are alarming because as the number of noise pixels goes up, the measured aperture flux will decrease, which mimics the signal of a transit. During the spikes, positions do not show out of the ordinary trends. There is also no apparent correlation with any particular spot on the pixel, so these are not related to a single position.
Using the IRAC data simulator we have successfully replicated the noise pixel spikes seen in these datasets using a high frequency position oscillation. At frequencies higher than the observation rate, oscillations of the instrument will have the effect of smearing out the image, and thereby increasing the number of noise pixels, without changing the object centroids. Although we have looked for correlations with telemetry values, there is no known cause for the suggested oscillations onboard Spitzer.
Table D.1: Examples of datasets with known noise pixel spikes.
Planet host star name
AORKEY
start_sclk
stop_sclk
HD 7924
46981888
1041429073.301
1041455525.016
HD 7924
44605184
1004594183.339
1004622735.006
XO-3
46482944
1050530251.708
1050573212.475
HD 20003
48408064
1062587169.546
1062628187.337
D.1.5 Timing
Both UTCS_OBS and ET_OBS use the standard convention of offset from J2000 which is defined as 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 that 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 leap seconds 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 the 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, two of those seconds are for leap seconds, 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 2000 January 1 12:00:00 TT or 2000 January 1 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.
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 milliseconds worst case, 20 milliseconds is probably a decent estimate of the uncertainty). It is approximately 8.221 milliseconds before the first pedestal read of an integration.
The midpoint time of an individual subframe j (where j runs from 1 to 64) of a subarray DCE is given by
where the 3.231 milliseconds is the result of the difference of the initial reset times and one half of an IRAC clock tick (clock ticks are 10 milliseconds in subarray mode). The above quantity is the exact midpoint time for the central pixel of the subarray (pixel 16,16 when counting from 1,1 to 32,32).
As each subarray row is read out in ten microseconds, to find the time of the midpoint for an integration for a particular pixel, in row r, column c:
The equation takes into account the fact that the actual readout size of the subarray is 40 pixels × 40 pixels and it takes 8 microseconds 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 one second for commanding overhead. As a result, a 0.4 second subarray frame which takes approx (64*0.4 seconds = 25.6 seconds) actually takes 27 seconds. In addition, you need to factor in the amount of time it may take for the next command to be issued by the spacecraft and received by IRAC. This is of order 0.4 seconds, but can vary. Therefore, in this case a total latency of about 1.8 seconds is expected.
Finally, AINTBEG is unfortunately not a good indicator of exactly when an integration starts due to the design of the IRAC firmware. However, ATIMEEND is the correct time of the end of an integration.
D.1.6 58th Frame in Subarray Datasets
The 58th subarray frame in both IRAC channels 1 and 2 exhibits a general variation in the background level of the subframe compared to other frames. This background variation does not appear to have a significant effect on the results of aperture photometry performed using annular background subtraction. While the exact cause of the background variation in this frame is unknown, it has been traced to a problem in the pipeline applying the skydark, being due to some periodic variation (or a slight timing difference) when subtracting the detector bias level. It does not appear to have a gain component. To be sure that there is no detrimental effect on the reduced data due to this feature many researchers omit this subframe in their analysis.
D.1.7 Corrupted Header
In AORKEY 42615040, WASP-434.5 micron, 2 second subarray observations at time 2011-07-29T23:08:34.966 all 64 frames in one BCD, about 2.7 hours into the observation, have elevated flux across the whole frame (multiplied by ≈ 105). It looks like a normal image when displaying with DS9, only the photometry indicates something is wrong. The flux levels in the BCDs before and after are fine. The imask implies the whole image is non-linear. The uncertainties (*_bunc.fits) image is all NaN's.
The source of this problem is a corrupted header. The barrel shift and some other header keywords were corrupted in transmission, causing the pipeline to not be able to correctly process the image.
D.1.8 Position Jumps Due to Reaction Wheel Speed Change
In the 55 Cnc datasets AORKEYs 48072704 and 48072960, there are several times when one can see jumps in position within AORs which do return to their original positions. Such times include 2013-07-08T12:55:21.630, 2013-07-11T13:26:19.537 and sclk times 1062887000.00, 1062602000.00, 1062610000.00, 1041435000.00, 1043545000.00, 1047548000.00, 1058016500.00, and 1057755000.00. During the summer 2013 anomaly, these jumps in position did not return to their original position. This behavior of not returning to its original position is confined to that anomaly.
The jumps in position correspond to wheel speed shifts. Wheel speed shifts are expected due to momentum rebalancing events in the wheel speed controller. The goal of this system is to avoid zero crossing disturbances (which would also induce position disturbances in the data) as long as possible. Autonomous momentum rebalancing only occurs when the system momentum grows above a certain threshold. Once this level is breached, the goal changes to balancing the wheels so that it can stretch out the time until the next desat. If the momentum falls back below that threshold, autonomous momentum rebalancing will once again be disabled.
We see different behavior during the PCS anomaly during the summer of 2013 because that anomaly was not allowing the momentum error integrator to compensate for the bearing drag in the wheels. A shift in wheel speed would introduce a different bearing drag torque, and without the integrator to compensate for this, the shift would not be removed.
These images can be used in analysis as long as the gain associated with the different centroids can be appropriately corrected for.
Figure D.4: Same as Figure 4.13, except this AOR was during the 2013 anomaly. A wheel speed shift occurs at time 1.057755, but the centroids never return to their pre-wheel-shift positions.
D.1.9 Pointing History File Change
In dataset AORKEY 48014336 (target HD 209458) centroids of the target change unpredictably near the end of a staring mode AOR. When examining the images by eye, the star is not actually moving around the detector. However, FITS header values CRVAL 1 and 2 change at the boundary from normal centroids to random centroids.
Often a photometry code takes R.A. and Dec. as input and converts those to x- and y-positions using the FITS header astrometric information, and then uses those initial values of x and y to refine an actual centroid. Pointing history files are what the SSC used to generate the astrometry in the header given the telemetry from the telescope. In this particular AOR, the pointing history file which was used to reconstruct the astrometry changed at an sclk time of ≈ 1.06246x109. This caused a change in the value of the CRVAL keywords in the FITS headers. When the value of the CRVAL keyword changes, then it appears as though the image shifted, when in fact it did not. In this case it shifted by enough distance that the centroiding routine lost the star and is attempting to centroid on noise, which explains the large scatter in positions after the shift (see Figure D.5).
We have since re-run the pipeline on this AOR, and it now has correct astrometry in the headers. We have seen this problem only once in the warm mission.
Figure D.5: x- and y-centroids as a function of time. The pointing history file changes just beyond sclk time 1.06246x109, which changes the expected position of the star in the image, and therefore makes the centroiding algorithm essentially fail to find the target. This AOR has been re-processed and now no longer shows this problem.
D.1.10 Effects of Cosmic Rays on Centroiding Algorithm
We concentrate on the effects of cosmic rays on the supplied box_centroider.pro centroiding algorithm. In all datasets, a few measured positions are just slightly different from the mean levels (usually less than one pixel).
For completeness, we looked at five of these for a WASP-15b AOR, and all five are caused by cosmic rays (CR). The CRs will change the center of light calculation in the centroiding routine. Not surprisingly, although we have not quantified it, the brightness of the CR seems to be correlated with the difference in position from the mean. The rate at which we see the centroid deviations is consistent with the known CR rate.
Figure D.6: x- and y-positions as a function of time for a WASP-15 AOR. The position points which do not follow the sawtooth pattern are caused by CRs.
D.1.11 Pattern noise (horizontal striping)
Pattern noise or horizontal striping (see example in Figure D.7) appears to randomly affect an indeterminate number of successive frames in an AOR. It was first noticed to affect the data more continuously on July 25, 2014. The pattern noise disappeared around 2014 December 9 but it reappeared briefly in some of the skydarks taken on 2015 March 13.
After 2014 July 25, short frame time (less than 12 seconds) images began to indiscriminately contain a low-level interference modulation of the signal across the array, or horizontal striping. A more careful investigation of images from all the AORs in one full campaign revealed that horizontal striping affected all frame times, but it is most prominent in the shortest frame times because of their lower backgrounds and fewer Fowler samples. The horizontal striping is stronger in channel 2 than in channel 1 (again presumably due to the lower background in channel 2). Its intensity can vary from barely detectable to easily seen, when looked at with the histogram equalization scaling. Subarray frames were found to be affected as well, although the noise is much higher in them and the effect is harder to see.
There is no detailed understanding of the origin of this effect, although it is thought to be related to electronic interference, probably from current running in some nearby part of the spacecraft, such as the battery charging currents. Tests were made to perform aperture photometry on data with pattern noise. No statistically significant difference in the derived flux densities were found when comparing point source photometry of the same source in observations with and without the pattern noise.
Figure D.7: Strong horizontal dark stripes in a 6-second frame time raw image in channel 2.
D.2 Time Series Photometry Tools
There are several tools available in the Contributed Software page
that can be used when analyzing high precision photometry. These include
box_centroider.pro that calculates centroids for a source using a simple first moment box centroider.
pmap_correct.pro that corrects for intrapixel gain variations in warm IRAC photometry. It performs a kernel regression on measured centroids and aperture photometry using a pixel mapping dataset taken on a calibration star. Because of the nearest neighbor calculation, it can be slow for large datasets, but it is much more accurate than iracpc_pmap_corr.pro (see below).
iracpc_pmap_corr.pro that corrects IRAC aperture photometry-derived fluxes from the post-cryogenic, or warm mission (IRACPC) for the intrapixel response, using the (pre-gridded) pixel maps of the 3.6 µm and 4.5 µm subarray sweet spots. Note that this uses a pre-gridded pmap. It is faster, but less accurate than, pmap_correct.pro (above).
irac_aphot_corr.pro that corrects IRAC aperture photometry-derived fluxes for the pixel phase and array location-dependent response functions. Built-in corrections are available for data from both the cryogenic (S18.24 processing; keyword /CRYO) and warm (S19.2 processing; keyword /WARM) missions. Note that this parametrized function for the intra-pixel response is a rough approximation and does not replicate the structure of the gain on less than 0.1-pixel scales. It may be useful as a first pass in correcting photometry.
