Contact: email@example.com, Canada-France-Hawaii Telescope
Created: 1999 November 5
Revised: 2002 April 2
|Tip: For printing, download the PostScript version of this document.|
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.
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.
In an ideal case, with 2 readouts per CCD, a closer view of the mosaic data would look like figure 2.
In the event that an amplifier is bad, we have two options:
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.
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.
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.
And with half the readouts active, the configuration of figure 3 would instead be represented as shown in figure 5.
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:
Please give your feedback on this matter, as we should decide very soon what to use to avoid a lot of confusion.
The following rules will apply to bias regions:
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.
In both cases, the total number of pixels per readout will be given by:
And in the case of one readout per chip, is while it is only when both amplifiers are being used.
For megacam specifically, we know the following values will apply to the EEV devices:
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:
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.