Software requirements for LCFI CCD test system


                                                                  C Damerell
                                                                  8/3/99

Our aim will be to develop one suite of software to be used with the test
systems at Liverpool, at RAL and maybe elsewhere in future. This is very
much a first version of the specs for this system. All interested are
invited to suggest additions, subtractions and modifications to these
notes.

Nomenclature : R = readout register, or R-address ('horizontal' coordinate,
or 'column address')
              I = imaging register, or I-address ('vertical' coordinate, or
'row address')


a)	The real-time run control should allow a number of options,
including the following examples:

continuous clocking (R register only)
continuous clocking (I register only)
continuous clocking (I and R registers synchronously) ['fast clear']
continuous clocking (frame readout sequence)
	(options of Node Reset ON, pulsed per row, or pulsed per pixel)
	(these largely for scope work)

During these operations, the VME system should be available for
parameter-setting and tuning operations. For example, while observing clock
drive pulses probed at the CCD motherboard, it should be possible (for
example, by using the 'up' and 'down' keys of the keyboard) for the user to
trim selected clock edges, in order to set crossover points precisely, etc.

data readout, consisting of
	a preset fast-clear period
	a preset integration period (no clocking)
	single frame readout (Node Reset once per row)
Cycle through this sequence for a preset number of frames (events) or till
user interrupt. When used with laser illumination, laser would be triggered
at start of the (brief) integration period.


b)	The data readout can be operated in a number of modes. We need a
set of hardware readout modes, and a set of 'software modes', which means
the simplest hardware readout (mode 0), but the data pre-processed in the
software to mimic a more complex hardware mode. Thus:

Hardware modes:

0	read out ADC info for every pixel

1	read out ADC-differences ('pixel signals') for every pixel. Due to
limitations in the memory on the DSS module (motherboard), this will be
restricted to 256 Kbytes per channel. This will certainly suffice to
cross-check against mode 11, which can be run for full-frame DAQ.

2	read out ADC differences subject to a pixel threshold [so now we
are in sparse data format, storing the node ID, (R,I) address and pixel
signal]

3	read out ADC differences subject to a cluster threshold. For each
accepted cluster, read out a 2x2 or 3x3 AOI [again, sparse data format]

Software modes: [hardware is in mode 0 in all cases]

11	compute ADC-differences (like mode 1, but differences can now be
negative, and should be stored with sign, for evaluating noise performance)

12	equivalent of mode 2

13	equivalent of mode 3


c)	The first requirement of the software is to generate data in modes
11, 12, 13, ... The second requirement is to display the pixel data (ADC
counts) from any of the hardware or software modes in a graphics window.
Most convenient, and least confusing, is to employ a standard colour map,
say

black/red/orange/yellow/green/blue/white

with user-defined lower and upper limits for black and white. The displayed
area (AOI) to be user-selected from the full CCD active area, down to 3x3
or whatever. Area selected by entering (R,I) coordinates from the keyboard,
or by cursor-selection of part of the displayed area, etc.

For multi-port CCDs, care needs to be taken to correctly orient and
juxtapose the different sections of the active area read through different
output nodes (with I and/or R readout directions reversed, etc) so as to
reconstruct the correct image on screen.


d)	The third software requirement is to generate histograms of
single-event data for a selected AOI, for the current readout mode.
Histogram pixel signals (ADC counts) in:

up to say 6 R-slices for I = I_min, I = I_min + 1, ... I = I_min + 5
up to say 6 I-slices for R = R_min, R = R_min + 1, ... R = R_min + 5

These histograms to cover user-selected ADC range Y_min to Y_max, where
Y_min may be negative for mode 11 data.

Evaluate statistical quantities associated with the histogram contents
(usual HBOOK).


e)	The fourth requirement is to generate multi-event histograms based
on quantities derived from the data, again with user-specified AOI. These
would typically be

	pixel signals,
	cluster signals,
	cluster centroid position (in R and I)
	spread on cluster centroid position (for laser illumination)
	cluster signal, for single-pixel clusters (X-ray hits in depl region)
	cluster signal, for clusters with > 90% signal in central pixel
	mean cluster signal vs I for selected column or group of columns
	mean cluster signal vs R for selected row or group of rows

At this level, one should think about the options between storing
multi-event data in the form of NTUPLES for each event, and processing the
stored data, or of processing data frame by frame, discarding the data
after each frame is processed. The former approach is desirable if one has
laboriously accumulated a long run of low-occupancy X-ray data, while the
second requires far less memory, and is preferable for looking at many
frames of easily-collected laser-flash data. In the second case, one may
change some cuts and re-run the data accumulation.

We should permit both options. I assume with the current availability of
large-volume storage devices, we can be quite relaxed about the first
option. One could envisage maybe 30 bytes per cluster, 10**3 clusters per
event, 10**4 events, so a run could imply almost 1 Gbyte of data (mode 2 or
3; I can't imagine needing a lot of frames of mode 0 or 1 data!)

Again, one would want to be able to process the data with user-developed
code, and to determine statistical quantities associated with the above
histograms. PAW/HBOOK environment seems appropriate.