Introduction

The Cube Mode is a variant of the of the burst mode already offered with VISIR and ISAAC.
In this mode, a data-cube with each single DIT frame is saved. This mode is particularly interesting for lucky-imaging type of observations, where one wants to select the best frames out of a set before co-adding them. The mode can be suited for time resolved applications for those setups that do not lose frames. However, the timing accuracy that can be obtained has not yet been thoroughly tested. More details are given in the User's Manual.

There are stringent limitations to the use of this mode, in particular it will only be offered in p82 in combination with basic imaging, SDI+, coronagraphy and SAM in NGS (i.e. no LGS observations).

Users will be allowed to specify different window formats (e.g. 64x64 up to full frame - 1024x1024) with increasing minimum DIT, once the window size gets bigger. The maximum number of DIT frames that can be saved in a cube is limited by the need to have file sizes smaller than 512 Mb.

Cube mode can be very efficient, but there is an overhead penalty for some setups.For instance, FowlerNSampling (FNS) is not a good choice in cube mode, despite the lower noise, because the readout techniques introduces high overheads: in full frame option for a total exposure time of 03:45 the total execution time is around 8 minutes. This is true for all FNS setups using the minimum DIT.

However, with most DCR setups the overall observing efficiency is highly improved, as reported by Seifahrt (see the contributed library): narrow band images taken with the S13 camera are read-noise limited up to several minutes of exposure time. Hence, there is no need to jitter the telescope to compute the sky and stare mode observations are sufficient. Also, the readout overheads are strongly limited (there is one readout per cube, i.e. one readout overhead for hundreds or thousands of frames) and several thousand frames can be taken per hour, much more than when using simple AutoJitter observations, no cube mode.

In most cases the system is able to deliver 100% of the DIT frames, even when one selects the minimum DIT. The table below shows some of the setups which have been succesfully tested. In some cases(e.g. DCR/HD full frame. See the detector characteristics for a description of the various readout and detector setps) the minimum DIT that guarantees no frame loss is higher than the possible minimum DIT.

Cube mode does not have to be used with the minimum DIT.

The following table will be modified after the intervention in October and November 2015.

Note that the window size is not perfectly squared. In cube mode NY = NX +2 and all the windowsare centred around pixel 512,512 (i.e.the parameter STARTX and STARTY cannot be set).

The recommended detector setup for use with cube mode is DCR/HD. Only in the full frame with minimum DIT options it loses frames. Setting DIT=0.5 guarantees that all frames are stored.

Users are also encouraged to check the user's manual for information on the cube data format. Itis important to remember that each cube contains one extra frame (i.e. NDIT+1). The last frame of the cube is the combined average frame.

Preliminary tests on the cube mode showed that:

• The noise level is the same as seen on normal frames. A preliminary test on noise performance in Double_RdRstRd (DCR) shows that the temporal noise, i.e. the variation of the noise across the cube, is similar to the spatial noise already quoted for theCONICA detector (from 3.8 to 4.2 ADUs RMS).
• Very small windows (64x66, 128x130) show larger noise than bigger windows, mostly due to the presence of fixed pattern noise (such as 8-pixel fixed pattern noise). The cosmetic of the detector is also different, with more blemishes in with smaller windows.These patterns can be eliminated during post-processing of the data.
• The overall signal-to-noise in the complete dataset is usually as predicted by the ETC, since the cube mode does not add extra noise, except of course that the readout noise is much more important given the many reads. One can see some additional horizontal additivepattern on the images, not stable between cubes or frames: this pattern can be removed by subtracting the median of each row (M. Durant, private communication)
• Random drifts (jitter) in x and y can be seen across thecube. For example a star can move from one frame to the other as muchas 1-2 pixels,when data are taken with good AO correction.
  The causes of this jitter are not yet well understood. They represent one more reason why cube mode observations and shift and addpost-processing of the images can result in a significant increase ofstrehl and image quality.

The number of parameters involved in this mode is large and more tests have to be performed. These pages will be updated as soon as results become available.

Given the great interest shown for this mode by the community, we will offer it despite it not being fully characterized.

Interested users should check these webpages for the latest news on cube mode characterization,or contact the NaCo Team at naco@eso.org.