The OM can operate in the two modes listed in Table 15. These allow either imaging or fast photometry or both simultaneously.
Mode![]() |
Special feature |
Imaging | Mosaic of 2-D imaging windows with long exposure
times (![]() |
Fast | High time resolution, providing 2-D time-sliced images over small areas. |
The Image Mode emphasises spatial coverage at the expense of
timing information.
Images can be taken at the full sampling of the instrument or binned by a
factor of 2 to yield a resolution element on the sky of approximately
0.5 or 1.0 seconds of arc. The maximum total size of the science
windows is determined by the memory available in the Data Processing Unit
DPU. A single Image Mode window binned by a factor 22 can be
up to 976
960 detector pixels, which results in a 488
480
binned pixel image being stored in the DPU. At full sampling (with
no binning) the window can be up to 652
652 pixels. The trade off is that
the images with unbinned pixels take more memory and therefore more
telemetry when downloading the data.
The maximum allowed integration time for an OM imaging mode exposure is 5 ks. Since the OM in its imaging mode produces accumulated images, there is no timing information attached to individual incoming photons.
Any drift in the pointing direction of the spacecraft is corrected in the image by tracking guide stars.
There are three different Imaging Modes: - "EPIC/RGS Image Mode" default combination of 5 exposures in predefined windows. - "Full Frame Low/High resolution Mode" single image covering the OM field of view with or without rebinning. - "Science User Defined Mode" flexible combination of imaging and fast windows of variable sizes and resolutions.
The Fast Mode emphasises timing information at the expense
of spatial coverage.
In its Fast Mode, the OM does not produce accumulated two-dimensional
images, but instead produces event lists like the X-ray instruments. This
mode is useful for monitoring rapidly variable sources, for example Blazars
or accreting binaries. Two small windows can be assigned, each of a maximum
of 512 pixels only.
Thus the maximum size of an approximately square window would be 2223
pixels (= 506 total). There is no binning within a Fast Mode
window. The pixel locations of individual photons within the window
are recorded and assigned a time tag, which has a user-specified
integration time of between 500 ms and the tracking frame
duration (10-20 s). No tracking correction is applied to Fast Mode
data. This can be applied on the ground, from the drift history
supplied by the OM. The data are obtained by default in 0.5 s time
slices, each preserving the pixel information.
Shorter times are in principle possible, but at the risk
of overloading the DPU (e.g. when two Fast Mode windows are
operated), and are therefore discouraged.
The maximum allowed integration time for an exposure with one Fast mode window is 4.4 ks, and 2.2 ks if two Fast mode windows are used simultaneously.
For critical time coverage, it has to be taken into account that during ground station handovers OM exposures are interrupted for 1800 sec.
Fast mode data can be acquired at the same time as image mode data. The default configuration for fast mode includes a large image window, in which the fast mode one is embedded. In case of User Defined windows, it is recommended to include an image mode window of bigger size than the fast mode one that includes the later.
Each mode has a specific overhead, i.e., time needed for
the instrument set-up, before the actual science exposure can
start. For both the above OM modes this overhead includes also the
reference frame exposure. In addition, about 1000 s are needed before
starting the OM exposures for the field acquisition of the satellite
star tracker.
The reader is referred to § 4.5.2
for a general discussion of the impact of instrumental overheads
on the planning of an XMM-Newton observation, and to the
XRPS User's Manual
for a detailed description of the OM overheads.
An interactive web tool is available at the MSSL web page:
http://www.mssl.ucl.ac.uk/www_astro/xmm/om/om_tool_current.html,
which may help the user to better handle and understand OM windows
and operational overheads.