Dither

Introduction

The Chandra spacecraft has a built-in dither on its pointing position to average across calibration uncertainties. In ACIS, dithering keeps one bad pixel from ruining an entire observation and smooths over chip gaps; in HRC, it prevents too many photons entering a single microchannel plate pore (which will eventually lower the QE of the pore). For both instruments, dither smooths out small effects of QE variations to a scale on which the QE can be efficiently calibrated.

Visualizing the Dither Pattern

The following table summarizes the default parameters of the dither pattern:

These are the default values. Users may have chosen to use customized dither parameters. The scheduled/planned dither parameters are available from the Chaser observation search application on the Details page.

This motion is recorded in the aspect solution file. Plotting the (ra,dec) columns shows the dither pattern (a Lissajous figure) of the observation:

It is also possible to plot either coordinate as a function of time.

How Data Analysis is Affected

The spectral analysis of sources can be affected by the dither, since the spectral response of the ACIS chips depends upon on which node the source is detected. As discussed in the Aimpoints section of the POG, the ACIS-S aimpoint is shifted slightly to ensure that the dithered flux of an on-axis point source remains on one node of the chip in order to ease the analysis of such sources. The aimpoint shift is recorded in the event file header keyword "SIM_Z".

The dither period can introduce spurious periods into light curves - or any general timing analysis procedure. Users must be careful to rule out dither as the source of any periodicity at either of the two dither periods or their harmonics.

How can I tell if the source dithered over a node boundary?

The nodes are easy to visualize, since they have fixed coordinates: CHIPX = 255-256, 511-512 and 767-768.

Filter the event file on the CCD and sky(x,y) source region:

unix% dmcopy "evt2.fits[ccd_id=3,sky=region(source.reg)][bin chip=1]" chip_img.fits

Open the chip image in ds9 and it will be evident if the source is at one of the node boundaries. If the source is bright (many counts), you may also be able to make out any bad columns in the data.

You can also make an exposure map for the data. Load the exposure map and the original event file into ds9 and blink the frames. The nodes, especially the mid-chip boundary, are fairly obvious.

How can I tell if the source dithered onto a bad pixel?

To see if the source crossed a bad pixel, it is necessary to use the status bit information in the level=1 event file. Use dmlist to see if any events have status bit 4 set to "1" ("bad"):

unix% dmlist \
      "evt1.fits[ccd_id=3,sky=region(source.reg),status=xxxxxxxxxxxxxxxxxxxxxxxxxxx1xxxx]" \
      counts

If a non-zero value is returned, it means that there were badpixels removed from the source region.