ISOCAM collected data on a continuous basis and passed it to the OBDH for insertion into the 8192-byte telemetry buffers that were downloaded every 2 s and assembled into one TDF per revolution. When ISOCAM was designated prime instrument, its data were downloaded through 24 of the 32 frames; otherwise, when parallel, through only 1 frame. Pointing data occupied 4 frames and housekeeping data the rest.
TDF_First_Scan scans an entire TDF to divide the revolution into individual observations and deliver their scheduling information via the Executed Observation History (EOH) files. Of relevance to ISOCAM are the EOHA and EOHC files from which data are extracted later in the pipeline and inserted into raw-data product header records so that the files themselves do not always need to be used. The EOHC file was a relatively late addition to the pipeline with the main purpose to ensure continuous data coverage. The EOHA observation schedule contains gaps between the nominal end of one observation and the start of the next. ISOCAM's continuous operation meant that potentially useful data sometimes fell in those gaps. Such data did not form part of an observer's TDT but were of help in reconstructing the history of the illumination of individual detector pixels when modelling instrument transients. The EOHC file, where the `C' stands for continuous, was devised to plug those gaps and make all ISOCAM data available and was used in later stages of the ISOCAM pipeline to define observation boundaries.
Derive_ERD is run once per observation using, in ISOCAM's case, the EOHC file to define the relevant parts of the TDF from which to extract, expand and record prime CIER or parallel CPER edited raw data and CDER diagnostic raw data. The on-board system interleaves two types of ISOCAM data into telemetry, namely housekeeping F1 blocks and imaging F2 blocks. Whenever the OBDH recognised that an F2 block was ready at the end or beginning of an integration time, it was inserted into telemetry which otherwise contains a continuous series of F1 blocks. Other instrument-independent parts of telemetry are processed simultaneously to transfer raw pointing data from the 4 relevant frames into the AOCS file and general housekeeping data into the GEHK file. At the end of the TDF, the AOCS file is used during derivation of pointing files.
For ISOCAM, it is the function of TDF_First_Scan to enumerate the instrument changes that took place over the course of a revolution in the CCSH file. As mentioned above, the CCSH primary header contains ISOCAM clock calibration keywords. The 20 or so parameters that define the operational status of ISOCAM are known collectively as the compact status and are given in chronological order in the CCSH file along with the start and end UTC, UTK and UTC time keys of the periods in which they apply. Individual observation's compact status values appear later in the CSTA file. For the CVF scans which are used for the spectrophotometric CAM04 AOT, only a single, nominal filter wheel position is stored in CCSH[1].CCSHFLTW(*) and CSTA[1].CSTAFLTW(*), instead of the full set employed.
The PRIMARY headers of CIER, CPER, CDER, CISP and CPSP files contain a common set of keywords derived from various sources to give important descriptive data, as in the following example:
OBJECT = 'CB195/L701' / Target ID as given by proposer OBSERVER= 'DCLEMENS' / Proposer ID in ISO Mission DB EQUINOX = 2000.0 / Equinox TMRATE = 32 / Telemetry rate in Kbps (Kbits/sec) EOHAUTCS= '96085090612' / Approx. UTC of start of observation EOHAUTCE= '96085092918' / Approx. UTC of end of observation EOHAAOTN= 'C01 ' / AOT name EOHAPLID= 'STARLESS' / Proposal ID EOHAOSN = '07 ' / Observation sequence number EOHAPSN = '00 ' / Pointing sequence number EOHAPCAT= '4 ' / Proposal category EOHACIND= ' ' / Calibration indicator EOHATTYP= '002 ' / Target type AOTVERS = '03.01 ' / AOT-to-OCT logic version ATTUTCSL= '96085090534' / UTC of start time of slew to intended target ATTUTCS = '96085090550' / UTC of time of first arrival at intended target ATTOTFTH= 10.0 / On-target flag threshold (arcsecs) ATTRA = 293.69733 / Intended Right Ascension of instrument viewing ATTDEC = 12.34669 / Intended DEClination (with ATTRA) ATTTYPE = 'R ' / Type of attitude operation (P/R/T) ATTRNPTS= 5 / Number of points per line of the raster ATTRNLNS= 5 / Number of lines in whole raster pointing ATTRDPTS= 32 / Distance (arcsecs) between adjacent points ATTRDLNS= 32 / Distance (arcsecs) between adjacent lines ATTRORIE= 1 / ORIENTation flag (0 or 1) ATTRROTA= 0.0 / ROTATE of raster pattern (degrees) ATTGUIDE= 109046 / Guide star reference number ATTSAANG= 71.0 / Solar aspect angle (degrees) ATTERROR= 2 / CONTINGEncy flag(0=success; 1=target not acq'd) TREFCOR1= 228128772 / UTC of 1st reference time TREFPHA1= 129.47567 / Orbital phase at TREFCOR1 TREFCOR2= 228129465 / UTC of 2nd reference time TREFPHA2= 129.48371 / Orbital phase at TREFCOR2 TREFCOR3= 228130158 / UTC of 3rd reference time TREFPHA3= 129.49175 / Orbital phase at TREFCOR3 TREFUTC1= 228128772 / UTC (whole seconds since 01-01-1989) TREFUTC2= 5112273 / UTC (remaining fraction of second) TREFUTK = 301458521 / ISO Uniform Time Key (UTK) TREFITK = 89720116 / ISO INSTRUMENT Time Key (ITK) TREFITKU= 0.13999950000000 / ITK unit length in secondsOf those keywords that are not obviously self-explanatory, the EOHA data are from the EOHA record that applies to the observation; the ATT data are pointing-related quantities from the first relevant APPH record; and the TREF data give the clock calibration or are calculated at times near the beginning, middle and end of the observation to show progress through the spacecraft's orbit.
Derive_ERD makes one CIER or CPER row for every F2 block found in telemetry,
expanding the compacted format into bytes, words or longwords and adding
supplementary housekeeping data from an adjacent F1 block. Similarly,
each of
the larger number of F1 blocks is used to make one CDER row, without
imaging data, thus providing a complete history of the instrument's
housekeeping. The F1 contents of the CDER record are identical to the F1
part
of CIER or CPER records and comprise data for 244 different housekeeping
parameters,
including those in vector columns related to a wide variety of quantities
such as settings of the internal calibrator source or the cryo motor;
temperature measurements at different detector locations;
on-board processor status and error codes; and voltage settings. Most of
these
data are of limited general interest. The rest of the CIER or CPER records
are occupied by raw imaging data in CIER[1].F2IMAG(1122,*),
for example, and 33 other associated F2 block items. The dimensions of
F2IMAG
are greater than
in order to accommodate extra data
required
by the SW readout scheme. Unless on-board integration was in operation,
records alternate between RESET and EOI data with identical CAM on-board
times CIER[1].F2TIME(*) and CIER[1].F2BOOTTI(*) that are used to calculate
the CAM ITK in CIER[1].GPSCTKEY(*).
Pointing data are obviously vital for data analysis and these are calculated at the end of Derive_ERD using the AOCS file derived earlier at the same time as other raw data. Two files are produced, namely a Reference Pointing History file and an Instantaneous Pointing History file. When ISOCAM was prime, the IRPH and IIPH files contained CAM pointing data. Otherwise, CAM parallel pointing data are found in the CRPH and CIPH files. The pointing system operated independently of any other instrument, so these files are of a general design described in the ISO Handbook Volume I, [40]. Because parallel pointing files were only made for CAM parallel's benefit, it is worth pointing out here, though, the extra CRPH[1].PRIME(*) and CIPH[1].PRIME(*) columns that show the aperture of the prime instrument in use. A change in the PRIME aperture implies a change in the spacecraft's and ISOCAM's pointing direction requiring a new data boundary. The other significant pointing event for both prime and parallel data is a change of RPID. The expected time of changes of IRPH[1].RPID(2,*) are given in IRPH[1].UTC(2,*) and IRPH[1].UTK(*), for example, which may be compared with the actual times by inspection of IIPH.RPID(2,*), IIPH.UTC(2,*) and IIPH.UTK(*).