Chandra X-Ray Observatory
	(CXC)
Skip to the navigation links
Last modified: 1 December 2014

URL: http://cxc.harvard.edu/ciao/why/dither.html

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 parameters of the dither pattern:

Detector Peak-to-peak
Span (arcsec)
Nominal Period
in Y (s)
Nominal Period
in Z (s)
POG Reference
ACIS 16 1000 707 ACIS chapter
HRC 40 1087 768 HRC chapter

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

[dither pattern]

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

[RA, Dec as 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 - as discussed in the "ACIS-S3: a spurious period of exact 1000 seconds" thread from the Chandra Users' discussion group.

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.


Last modified: 1 December 2014
Smithsonian Institute Smithsonian Institute

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-2014. All rights reserved.