Up: Home Page

Megacam Pixel Data Description
Revision 1.5

Contact: megacam@cfht.hawaii.edu, Canada-France-Hawaii Telescope

Created: 1999 November 5
Revised: 2002 April 2

Tip: For printing, download the PostScript version of this document.

Abstract:

This is a description of Megacam's pixel data, including chip numbering, readout amplifier configuration, prescan/overscan regions, and packaging of the pixel data for the Unix host receiving the image.

Changes:

1.6 Apr 2002 The 'A' and 'B' amplifiers were swapped compared to the convention EEV/Site uses (and compared to the convention detector engineers at CFHT would be accustomed to.) They have now been swapped to match the usual convention though some lower level documentation for the controller may still have them the original way.

1.5 Jul 2001 Proposed alternate numbering, viewing camera as 80 readouts rather than 40 chips (more convenient for astronomer?)

1.4a Sep 2000 It's NPPRE that will be zero. Added some EEV specifics.

1.4 Sep 2000 Removed ``probably'' from ``NSPRE will probably be zero.''

1.3 Mar 2000 Rasters will be a range of full rows from each readout instead of arbitrary rectangular region.

1.2 Feb 2000 Changed name of document and added abstract.

1.1 Jan 2000 Corrected chip numbering view as seen from dewar (Jan 28).

1.0 Jan 2000 Initial version.

1. Chip numbering

The following numbering scheme should be used where-ever possible, to remain consistent. This scheme is designed to be the most straightforward for the end user of the instrument. If another numbering scheme is required internally, that's fine of course, but a mapping should be provided where necessary.

Chips in the main, square imaging region of the camera will be numbered consecutively from 0 to 35 in left-to-right, top-to-bottom order. See figure 1 (a) for details.
Numbers 36 through 39 will be assigned to the extra four chips on the side, if they are present. They will not affect the numbering of the central chips. See figure 1 (b).
In the event that an entire chip in the mosaic should be bad, or not selected, the numbering will remain the same, with fixed numbers assigned to physical positions in the focal plane.
When data is displayed, North should always be on top and East to the left.
The orientation seen looking in through the window of the dewar will be the same, except the image is rotated 180 degrees since the camera is mounted at prime. This means the part of the mosaic that images North on the sky (row with chips 0-8) will end up physically closest to the south pier of the telescope. The column of chips that images East on the sky (chips 0, 9, 18, and 27) will be closest to telescope West. See figure 1 (c).

**Figure 1:** Megacam Chip Numbering
$\begin{figure} \begin{center} \epsfig {file=megacam-chipno.eps}\end{center}\end{figure}$

2. CCD Amplifiers

In an ideal case, with 2 readouts per CCD, a closer view of the mosaic data would look like figure 2.

**Figure 2:** Megacam Readout Configuration
$\begin{figure} \begin{center} \epsfig {file=megacam-chipid.eps}\end{center}\end{figure}$

In the event that an amplifier is bad, we have two options:

Disable that chip entirely and continue to read all remaining chips from both ``A'' and ``B'' amplifiers.
Read out all of the CCDs from only one of the amplifiers, at the cost of another 20 seconds of readout time.

In the figure 3, we favor reading the top rows from the ``B'' amplifier and the bottom rows from the ``A'' amplifier, except for chip 14 which has a dead ``B''. This is only an example. The choice of ``A'' or ``B'' will be configurable for each chip.

**Figure 3:** Megacam Alternate Readout Configuration
$\begin{figure} \begin{center} \epsfig {file=megacam-chipid-alt.eps}\end{center}\end{figure}$

The software will not be required to support a mix of these two cases. In other words, we will either read all CCDs from a single amplifier (where each chip can be either ``A'' or ``B'') or read all CCDs from both amplifiers. This simplifies things like packet sizes and DSP programming.

2.1 CCD Amplifiers, amplifier-based numbering

Proposed alternative to chip numbering above: At some level, the chip numbering described above is needed for engineering, and housekeeping while building the camera. Knowledge of which amplifier is on which physical CCD device will also be needed if we have to select a single output per CCD. Even the latter, however, would be done by engineers and the astronomers or anyone looking at the data really only cares about knowing that there are N amplifiers, where each region is, and where the first pixel read is. When saving ``split'' FITS files, some kind of identifier must appear in the filename. This same identifier would appear in the EXTNAME keyword of an extension. While this EXTNAME or filename can contain letters/numbers, it may be easier to number them with consecutive, unique numbers, rather than the chip number plus the letter ``a'' or ``b''. With this numbering scheme, instead of figure 2, someone reducing the data would simply look at MegaCam as 80 readouts when reducing their data, with numbering shown in figure 4.

**Figure 4:** Megacam Readout Configuration
$\begin{figure} \begin{center} \epsfig {file=megacam-ampid.eps}\end{center}\end{figure}$

And with half the readouts active, the configuration of figure 3 would instead be represented as shown in figure 5.

**Figure 5:** Megacam Readout Configuration
$\begin{figure} \begin{center} \epsfig {file=megacam-ampid-alt.eps}\end{center}\end{figure}$

The proposal originates from the idea that the astronomer really only sees the camera in terms of its readouts. The fact that a pair of readouts share the same piece of silicon is only of significance to engineers, who can use the alternate diagrams to translate a numeric amplifier ID to a chip number (well, they only have to divide by two!) So a summary of the pros and cons that come to my mind:

Pros

SAOImage DS9 would not need to be modified to display MegaCam data from separate (split) files. (Currently, if you load foo00.fits with ``Open multiple...'', it automatically looks for foo01.fits, foo02.fits, ... and builds a mosaic. I does not look for foo00a.fits, foo00b.fits, foo01a.fits ...) We are going to standardize on using MEF, but in any case keeping support for split (without having to do extra hacking on DS9) seems like a good idea.
Purely numeric identifiers (no `ab' characters) are easier to handle in software.
Using unique numeric amplifier IDs allows us to be more compatible with NOAO's recommended conventions for EXTNAME and IMAGEID. (Please see the NOAO FITS dictionary.) Right now, we use 'chipNNa/b' instead of 'imNN' to make it clear that our numbers are currently chip numbers, not amp numbers.
The diagrams for the observer (figure 4 and figure 5) are cleaner/simpler. Numbers 0..71 fill the square region in top-to-bottom, left-to-right order.

Cons

We should be careful to always speak of the ``80 amps/readouts'' and not the ``40 chips'' of MegaCam or things could get confusing. (Hey, 80 sounds more impressive than 40 anyway, right!? Same trick as the ``12K''... we don't make a big deal about the minor dimension ;-)
Engineers need to make a translation when the actual chip number is required. (This information is obvious by looking at the two diagrams side-by-side, and also the A-or-B-ness and chip number can be stored in an extra FITS card withing the extension.)

Please give your feedback on this matter, as we should decide very soon what to use to avoid a lot of confusion.

3. Bias Sections

The following rules will apply to bias regions:

All dimensions will be given in readout pixels counts.
Prescan and overscan will automatically be included in the data whenever possible. It will be passed in the same order as seen by the amplifier. (Prescan, image pixels, overscan, repeat.)
A range of full rows (including the overscan) will be selectable by giving one start row and one end row. The same square region will them be read from each readout. This region will be the same distance from the normal start pixel of each readout. No other subrastering schemes will be required with MegaCam.
When binning is selected all values will reflect the binning factor, and overscan regions will be binned in the same fashion as the imaging region.

In the example in figure 6, the left side shows the arrangement of data if one of the lower chips was being read out from only its ``A'' amplifier. The right side shows a CCD from the top row in the case of two amplifiers per CCD.

**Figure 6:** Example Bias Section Dimensions
$\begin{figure} \begin{center} \epsfig {file=megacam-bias.eps}\end{center}\end{figure}$

In both cases, the total number of pixels per readout will be given by:

$\begin{displaymath} NPIX = ( NSPRE + NSR + NSOVR ) \times ( NPPRE + NPR + NPOVR ) \end{displaymath}$

And in the case of one readout per chip, $NSR \times NPR$ is $2K \times 4.5K$ while it is only $1K \times 4.5K$ when both amplifiers are being used.

For megacam specifically, we know the following values will apply to the EEV devices:

will be 0 (no pre-scan in the parallel register)
is fixed at 50 by the hardware in the serial register. The prescan exists only in the serial register, not in the image area.
for a full chip is 4612 (4.5K plus 4 additional rows between the serial register and the iamge area. These four rows see light as any other row, and not .)

4. Data Arrangement in Memory

NOTE: The following was written before the decision to use a Real-Time Linux acquisition system. Options for block-descrambling, DMA, and endian-issues are supported by the combination of the AMCC and the Linux driver which was developed to specifically support the needs of MegaCam image transfer. Sections 4 and 5 of this document will be updated soon to illustrate some of the options that are now available. The first working version of the driver is described at http://software.cfht.hawaii.edu/sspci/. Note that the most current version of this software is already installed on the development machine.

In the end, we would like to have image data arrive in system RAM (or something comparably fast) on our Unix data acquisition computer. This memory buffer should mimic the arrangement of the final FITS data file as closely as possible. The structure of a multi-extension FITS file for mosaic data is described by NOAO (See ``Mosaic Data Structures'' at http://iraf.noao.edu/projects/mosaic/) This leads to the following constraints:

Descramling. Data from each amplifier should be stored separately, in a contiguous block of memory.
No flipping. Neither the DSP nor the software collecting the data should make any attempt to flip or correct the orientation of the data. The first pixel in the buffer should be the first one read by the amplifier on the device.
Byte-swap option. Depending on the architecture of the Unix computer, it may be desirable to store the pixel data byte-swapped (over a 16-bit word size) in the memory buffer. This would allow direct memory-mapping to a FITS file on Intel, DEC, and other processors. If it is possible for the DSP to send the pixel data over the fiber already byte-swapped, this would be ideal. (Or if the S-Link interface can do it on the fly without any overhead, that works too.)

5. Pixel Stream Packaging

Since the hardware solution for getting the data into the Unix memory has not been chosen, it may also be useful to specify a possible format for the pixel stream that would allow a direct connection between the DSPs and a Unix host. This form of a protocol will be irrelevant if a solution like the memory mirror cards is chosen, but one will still be needed at some level. It cannot hurt to propose a scheme that lends itself to easily building the final desired memory buffer.