About Chandra Archive Proposer Instruments & Calibration Newsletters Data Analysis HelpDesk Calibration Database NASA Archives & Centers Chandra Science Links

Skip the navigation links
Last modified: 1 February 2008

URL: http://cxc.harvard.edu/ciao3.4/why/ccmode.html
Hardcopy (PDF): A4 | Letter

Continuous Clocking Mode


The ACIS continuous clocking (CC) mode is provided to allow 2.85 msec timing at the expense of one dimension of spatial resolution. This mode creates 1 pixel x 1024 pixel images, each with an integration time of 2.85 msec. Details of the spatial distribution in the columns are lost, other than the fact that the event originated in the sky along the line determined by the length of the column. For more details, see the Continuous Clocking Mode section of the POG.

Calibration

The computation of PHA, ENERGY and PI for CC mode observations is performed in the same way as these computations for TE mode observations and using the TE mode gain, CTI and time-dependent gain calibration products. The pulse-height information may be somewhat inaccurate because

However, it is still recommended that you apply the CTI and time-dependent gain adjustments to the data. There was a fix to the CTI correction for CC-mode data in standard data processing version DS 7.6.3 (12 August 2005).

Data Caveats

Mask files: There is a known problem with CC-mode mask files that were produced with a software version lower than DS 7.3.0 (before about 24 June 2004). Be sure to read the Caveats about ACIS Pipeline-Processed Mask Files to see if this issue affects your data.

TIMEDEL keyword: The value of the keyword TIMEDEL in some ACIS continuous-clocking mode event-data files is incorrectly set to 1.4592 s instead of 0.00285 s. While this does not represent a problem if the pipeline-produced files are used for timing analyses, it is a problem if an affected event-data file is reprocessed using acis_process_events with the parameter calc_cc_times=yes because the values of the TIMEs in the output file will be corrupted. The problem, which affects data processed with DS7.6.0 (June 2005) or higher, is being corrected.

To see if your data file is affected, check the ASCDSVER (software version) and/or TIMEDEL header keywords in the evt1.fits file:

unix% dmkeypar acis_evt1.fits ASCDSVER echo+
7.6.2

unix% dmkeypar acis_evt1.fits TIMEDEL echo+
1.4592

This file was processed after DS 7.6.0 and has the incorrect TIMEDEL value, so we use dmhedit to update it:

unix% dmhedit infile=acis_evt1.fits filelist="" op=add key=TIMEDEL value=0.00285 unit=s

unix% dmkeypar acis_evt1.fits TIMEDEL echo+
0.00285

Correcting Event Times

Since 15 June 2005 (standard data processing version DS 7.6), the TIMEs in ACIS CC mode event data files are the times of arrival at the detector. For observations processed using an earlier version of the software, the event TIMEs are the read-out times, which include the effects of (1) dither, (2) motion of the SIM and (3) a 3-6 s offset (the nominal read-out time). Data processed with an older version of the software should be reprocessed before performing timing analyses; the Calculate CC-mode Times of Arrival thread illustrates how to do so.

Reprocessing the Data

The first "good" version of the processing software for CC-mode observations is DS 7.6.3 (12 August 2005). To see which version of the software was used to process your data:

unix% dmkeypar acis_evt2.fits ASCDSVER echo+
R4CU5UPD11.1

Note that the version naming convention changed after version R4CU5UPD14 to the "DS" system, starting with DS 6.0.0. Therefore, this data was processed with a version of the software older than DS 7.6.3 and should be reprocessed in CIAO before being analyzed.

If your file was processed with DS 7.6.0 or higher, be sure to read the data caveat about the TIMEDEL keyword.

Because CC mode is a special case, there are some data analysis caveats to keep in mind during the reprocessing.

acis_process_events
  • The eventdef parameter, which specifies the names and data types of the columns in the output event data file, needs to be set to one of the predefined strings for CC mode: cclev1 (faint CC mode) or ccgrdlev1 (graded CC mode).

    If you are unsure of the event mode of your observation, the information can be found in the READMODE and DATAMODE values stored in the file header:

    unix% dmkeypar acis_evt1.fits READMODE echo+
    CONTINUOUS
    
    unix% dmkeypar acis_evt1.fits DATAMODE echo+
    CC33_FAINT
    

    This is a faint CC mode observation, so the proper eventdef parameter is "cclev1".

  • Apply the time-dependent gain and CTI corrections:

    unix% pset acis_process_events apply_tgain=yes
    unix% pset acis_process_events apply_cti=yes    
    

    The ACIS calibration team has advised that it is useful to apply these corrections, even though the calibration is derived from TE-mode observations.

  • Set calc_cc_times=yes so the the event times are corrected to the time of arrival:

    unix% pset acis_process_events calc_cc_times=yes
    

    The Correcting Event Times section of this why topic has more information.

tg_create_mask

The output of tg_create_mask is a FITS region file which enumerates the grating parts and specifies the region shape, size, and orientation in sky pixel-plane coordinates. ACIS/HETG CC-mode data is processed with the grating_obs parameter set to MEG, but a rotation angle of zero. Since there is no spatial resolution across the dispersion, the HEG and MEG arms are merged together; they are resolved later by tg_resolve_events, if possible.

tg_resolve_events

There are two options in tg_resolve_events for determining the order sorting: osipfile=CALDB (the default) or osipfile=none along with osort_lo and osort_hi instead.

  1. Due to poor gain correction, orders may be shifted so that they fall outside the osip regions for some chips at some wavelengths. Using the osipfile parameter then results in clipped efficiency which is not accounted for by the ARF.
  2. Using the osort_lo and osort_hi parameters can compensate for clipped orders, but it allows much background from zero order at short wavelengths. This is often a region of much interest for Fe K analysis.

Which option you take depends upon the analysis. The general recommendation is to use the osip file (i.e. osipfile=CALDB), but then to compare the plus and minus HEG and MEG spectra and ignore regions which are low during analysis.

Order resolution uses the CCD ENERGY to make an educated guess as to whether the photon is MEG or HEG and iterates the resolution by assigning a nominal CHIPY. Some ambiguity in coordinates may make this less accurate than TE mode.

Hardcopy (PDF): A4 | Letter
Last modified: 1 February 2008


The Chandra X-Ray Center (CXC) is operated for NASA by the Smithsonian Astrophysical Observatory.
60 Garden Street, Cambridge, MA 02138 USA.    Email: cxcweb@head.cfa.harvard.edu
Smithsonian Institution, Copyright © 1998-2004. All rights reserved.