ICD 1.9f/3.2

SPE-C-G0037, "Software Design Description" , Gemini 8m Telescopes Project

1. dhs_pdr_icd1c, "ICD 1c -- Baseline DHS interface" , Norman Hill, Severin Gaudet and Dale Kotturi, DAO
2. dhs_pdr_icd3, " ICD 3 -- Bulk Data Transfer" , Norman Hill & Severin Gaudet, DAO.
3. dhs_pdr_icd4, " ICD 4 -- Logging Interface" , Norman Hill & Severin Gaudet, DAO.
4. cics_smb_017, "ICD 6 -- ICS/TCS Direct Control Interface" , Steven Beard, Royal Observatory Edinburgh.
5. gscg.grp.???, "ICD 13 -- Standard Controller ", Bret Goodrich & Andrew Johnson, Gemini 8m Telescopes Project.
6. gscg.grp.???, "ICD 18 -- World Coordinate System Information" , Steve Wampler and Steven Beard, Gemini 8m Telescopes Project.
7. " ICD 1.9f/3.1 -- Near-infrared Integral-Field Spectrograph (NIFS) to Observatory Control System interface" , Mark Jarnyk, Peter Young, RSAA.
8. cics_smb_002, "Core Instrument Control System -- Introduction & Specification" , Steven Beard, ROE.
9. cics_smb_016, "The OCS/ICS/DHS Observing Sequence and Data Flow" , Steven Beard, Royal Observatory Edinburgh.
10. cics_smb_022, "CICS -- Architectural Design Document" , Steven Beard, Royal Observatory Edinburgh.
11. cics_smb_042, "The flow of WCS information through a Gemini ICS" , Steven Beard, Royal Observatory Edinburgh.
12. "EPICS Channel Access Reference Manual" , J. O. Hill, Los Alamos National Laboratory
13. tcs_ptw_008, "World Coordinates" , Pat Wallace, Rutherford Appleton Laboratory.
14. "Representation of Celestial Coordinates in FITS" , E.W. Griesen and M.Calabretta, NRAO and ATNF.
15. AAO/SDS_07, Self-defining Data System (SDS) , Jeremy Bailey, Anglo-Australian Observatory.
16. AAO/IMP_MANUAL_8, Interprocess Message Passing (IMP) System , Keith Shortridge, Anglo-Australian Observatory.
17. "NIFS Conceptual Design Review Vol 1", Research School of Astronomy and Astrophysics, Australian National University
18. "NIFS Critical Design Review Vol 1", Research School of Astronomy and Astrophysics, Australian National University

Acquisition and Guidance

Those operations associated with acquiring a science object and maintaining the correct pointing of the telescope and adjustment of the telescope's optics by means of guide stars.

Bad pixel mask

Calibration data containing a map of the pixels on a detector array, with defective pixels flagged in some way. The mask can be used to ensure that defective pixels are not included in the data processing. A bad pixel mask can also be used to mask off unwanted areas of the detector array which cannot be removed using a See Region of interest .

Bulk data

Header and pixel data which is to be transferred to the DHS for display or storage. Bulk data is transmitted using the protocol of ICD/3, See dhs_pdr_icd3, "ICD 3 -- Bulk Data Transfer", Norman Hill & Severin Gaudet, DAO., rather than by EPICS channel access, See "EPICS Channel Access Reference Manual", J. O. Hill, Los Alamos National Laboratory. Compare with See Status information .

Calibration data

Any data used for some sort of calibration purpose. It might be a flat field observation, or an observation of a standard star, for example. It is possible for a set of data to be both See Calibration data and See Science Data .

Components Controller (CC)

An instrument subsystem responsible for the various mechanisms (e.g. motors and heaters) contained in an instrument.

Data array

That part of a See Frame containing the actual data detected. A data array may contain signal, variance or See Data quality .

Data label

A unique label for a See Data set assigned by the DHS or OCS which is used to identify data being sent to or requested from the DHS. When an instrument obeys an OBSERVE command, the See Data label for the See Data set generated is provided by the OCS. The See Data label for data generated spontaneously by a non-instrument data source, such as a wavefront sensor, is provided by the DHS.

Data LAN

The Local Area Network in the Gemini system devoted to the transfer of bulk data.

Data quality

Information describing the useability of each of the elements of the main signal See Data array , for example a bad pixel mask.

Data set

A self-contained collection of data generated as a result of an instrument obeying an OBSERVE command. Each OBSERVE command results in one and only one See Data set . All the data relating to one See Data set will be maintained by the DHS in a single container. A data set consists of some See Header data describing the See Data set plus one or more See Frame s.

Data set observation

This term is used in the CICS documentation to refer to the act of accumulating light on the detector in order to create a See Data set . It is what an instrument does in response to an OBSERVE command. Compare with the definition of See Observation .

Destructive read

A clocking out of the integrated signal recorded by a detector which results in that signal being discarded. A detector can only be read out once in such a mode.

Detector Controller (DC)

An instrument subsystem responsible for controlling a detector array and reading data from it. Note that this term has been used in Gemini documentation to refer both to the detector control electronics and the detector control software system . In the context of this software document the term refers to the detector control software system unless otherwise stated.

Dynamic Header

That part of the See Header data containing information about the See Data set which needs to be collected at a very precise time (such as the time at which the data collection started and finished). This part of the See Header data is typically provided by an instrument.

Engineering log

A record containing information of interest to an engineer who is testing a system or diagnosing a problem with a system. The "engineering log" might contain a record of debug messages generated by the system, plus a history of changes made to certain critical engineering parameters, plus anything else an engineer decides the system needs to record. The "engineering log" is more detailed and more configurable than the " See History log ", and refers only to a single system. The main purpose of the "engineering log" is to provide an engineer with detailed diagnostic information.

Exposure

The array of data resulting from reading the detector during or after a single exposure of the detector array to light. An exposure is made by resetting the detector, exposing it to light, and reading it one or more times (e.g. once in a See Destructive read mode or several times in a See Non-destructive read mode).

Frame

An image or spectrum capable of being displayed or processed as a discrete entity (for example an image of all the coadded exposures in one beam of a See Data set observation made in chop mode). A See Data set can be made of one or more frames (for example a See Data set in chop mode might consist of frames of coadded exposures in beams A and B). Each frame can consist of one or more combined See Exposure s.

Header data

A collection of attribute/value pairs which describe a See Data set or a See Frame within a See Data set .

History log

A record of the commands executed by a system and any significant changes to the system operation. The "history log" for an instrument might contain a record of the OCS sequence commands executed plus a record of the times when the instrument configuration was changed, and it is generally less detailed than an " See Engineering log ". History log events may be combined together to form a global history of all the events happening in the observatory. The main purpose of the history log is to record what happened during a night's observing, regardless of how many science programmes were involved.

Instrument Sequencer (IS)

That part of an Instrument Control System responsible for coordinating the actions of a Detector Controller and one or more Components Controllers. The A&G subsystem has a "Guidance and Beam Direction Sequencer" for coordinating its components.

Mandated Header

That part of the See Header data containing information describing a data array which must be present for the DHS to make sense of that data array. Such information includes the size and shape of the data array and the World Coordinate System (WCS) information .

Non-destructive read

A clocking out of the integrated signal recorded by a detector in a way which maintains that signal intact. The signal recorded by a detector can be sampled more than once in such a mode. This mode is often used to minimise the contribution from detector read noise.

Observation

An observation is a procedure, specified by the observer, designed to obtain scientific information from the light acquired from an object. To complete an observation, the OCS may need to issue several OBSERVE commands, which could result in several See Data set s. See also See Data set observation .

Observing log

This is a record of all the observations made as part of a particular observer's science programme, plus a summary of the observing conditions and a collection of all the comments made by the observer during those observations. The main purpose of the observing log is to provide the observer with a record of their particular science programme. (See also See Engineering log and See History log ).

Principal Systems

The Gemini Control System is made up of the OCS, TCS, DHS and one ICS for each instrument. These systems constitute the principal systems of the Gemini Control System.

Read

When used in the context of a detector controller, this refers to the read of a single pixel on the detector array.

Readout

When used as a noun to describe instrument data, this refers to the array resulting from a See Read of all the pixels on the detector inside a given region of interest (which may be the whole detector array). An See Exposure can be made from one or more readouts.

Region of interest

This is an area on the surface of a detector whose data are of interest. There may be one or more regions of interest on a detector array.

Science Data

Any data obtained as a result of a scientific observation. An image or spectrum of an astronomical object is an example of See Science Data . Compare with See Bad pixel mask and See Calibration data .

Static header

That part of the data header containing information which changes little with time during the collection of a See Data set (such as the telescope target coordinates and name of the observer). This part of the header is typically provided by the OCS, but some wavefront sensors may need to provide the information themselves.

Status information

Small quantities of information describing the configuration or status of a system. This information is usually stored in an EPICS database and communicated by channel access, See "EPICS Channel Access Reference Manual", J. O. Hill, Los Alamos National Laboratory. Compare with See Bulk data .

Status/Alarm Database (SAD)

This is an EPICS database containing the public status information for a Gemini principal system. For an Instrument Control System, the SAD would contain information about the configuration of the instrument's mechanisms, its current state and health, and information obtained from sensors.

VME

A real-time system obeying the ANSI/IEEE 1014-1987 Versatile Backplane Bus standard.

VxWorks

The Real Time Operating system from Wind River

World Coordinate System (WCS) information

Information describing the transformation between pixel coordinates in the data array and (RA,Dec) coordinates on the sky (see See cics_smb_042, "The flow of WCS information through a Gemini ICS", Steven Beard, Royal Observatory Edinburgh. and See tcs_ptw_008, "World Coordinates", Pat Wallace, Rutherford Appleton Laboratory.).

Conforming instrument ICDs

• ICD 1.9a/3.2 -- Near IR Imager (NIRI) to Data Handling System.
• ICD 1.9b/3.2 -- Gemini Near IR Spectrograph (GNIRS) to Data Handling System.
• ICD 1.9c/3.2 -- High Resolution Optical Spectrograph (HROS) to Data Handling System.
• ICD 1.9d/3.2 -- Gemini Multi Object Spectrograph (GMOS) to Data Handling System.
• ICD 1.9e/3.2 -- Mid IR Imager (MIRI) to Data Handling System.
• ICD 1.9f/3.2 -- Near-infrared Integral Field Spectrograph (NIFS) to Data Handling System

Guest instrument ICDs

• ICD 1.9q/3.2 -- Michelle to Data Handling System.
• ICD 1.9r/3.2 -- Cryogenic Optical Bench (COB) to Data Handling System.
• ICD 1.9s/3.2 -- Phoenix to Data Handling System.

Quasi instrument ICDs

• ICD 1.6/3.2 -- A&G Control System to Data Handling System.

 

The DHS and Instrument Control System Hardware Architecture

Communications infrastructure

The logging infrastructure uses the facilities of EPICS and in particular uses the services provided by Channel Access (CA). The full list of facilities provided by CA are described in reference See "EPICS Channel Access Reference Manual", J. O. Hill, Los Alamos National Laboratory. Logging information is transmitted over the Data LAN. For details of the protocol see ICD/4, See dhs_pdr_icd4, "ICD 4 -- Logging Interface", Norman Hill & Severin Gaudet, DAO..

Software architecture

A context diagram for the NIFS (science instrument) to DHS logging interface may be found in ICD/4, See dhs_pdr_icd4, "ICD 4 -- Logging Interface", Norman Hill & Severin Gaudet, DAO., and a data flow diagram of an instrument control system, showing the relation between it, its subsystems and the DHS, may be found in the CICS introduction See cics_smb_002, "Core Instrument Control System -- Introduction & Specification", Steven Beard, ROE.. The NIFS logging interface follows these rules and guidelines:

1. All items to be logged by the DHS are contained in SIR records in the Status/Alarm Database of the NIFS ICS.
2. According to Gemini policy NIFS has four status items called "historyLog" in its Status/Alarm databases, for conveying textual log messages to the DHS. In particular these are:
3. nifs:historyLog - Instrument Sequencer;
4. nifs:cc:historyLog - Components Controller;
5. nifs:dc:historyLog - Detector Controller;
6. nifs:wfs:historyLog - On-instrument wavefront sensor controller;

 

The software architecture is fully described in See "NIFS Critical Design Review Vol 1", Research School of Astronomy and Astrophysics, Australian National University.

Communication infrastructure

The data are communicated over the Gemini Data LAN as SDS data structures transmitted using the IMP message passing system over the TCP/IP protocol. The method for transferring data between Gemini systems is described in ICD/3, See dhs_pdr_icd3, "ICD 3 -- Bulk Data Transfer", Norman Hill & Severin Gaudet, DAO.. SDS is described in reference See AAO/SDS_07, Self-defining Data System (SDS), Jeremy Bailey, Anglo-Australian Observatory. and IMP in reference See AAO/IMP_MANUAL_8, Interprocess Message Passing (IMP) System, Keith Shortridge, Anglo-Australian Observatory..

Software architecture

A context diagram for the ICS (NIFS) to DHS bulk data interface may be found in ICD/3, See dhs_pdr_icd3, "ICD 3 -- Bulk Data Transfer", Norman Hill & Severin Gaudet, DAO., and a data flow diagram of an Instrument Control System, showing the relation between it, its subsystems and the DHS, may be found in the CICS introduction See cics_smb_002, "Core Instrument Control System -- Introduction & Specification", Steven Beard, ROE.. The NIFS to DHS bulk data interface follows the following rules and guidelines:

1. It is good practise for the names of header items to be the same as their FITS keywords, but this is not a hard and fast rule. In general, the only systems which have to know anything about FITS keywords are the DHS and OCS.
2. Each OBSERVE command results in one "data set". The command can result in more than one frame of data being produced, but the DHS always keeps all the data belonging to a particular data set in the same container. The contents of a data frame can be transmitted to the DHS in small chunks if desired.

Terminology

It is assumed that one OBSERVE command results in one See Data set . Each See Data set can contain one or more See Frames . Each See Frame is made by combining one or more See Exposures , and each See Exposure can be recorded from one or more See Readouts of the detector. See the definitions in See Definitions.

As an example, the data resulting from a See Data set collected in chop mode could be transmitted by an instrument in one of two ways: as a single coadded and sky-subtracted frame; or as two separate coadded frames for beams A and B. Each frame might consist of one exposure or a whole series of exposures coadded together.

Events and responses

The events and responses over this interface are exactly the same as the ones described in the "Events and Responses" section of ICD/3, See dhs_pdr_icd3, "ICD 3 -- Bulk Data Transfer", Norman Hill & Severin Gaudet, DAO., except for "ICD 3 client" read "ICS".

Science data transmission scenario

See The flow of science data and headers through the Gemini Control System and NIFS shows the flow of science data through the Gemini Control System. Note that only the relevant subset of data flows are shown. For a complete data flow diagram see references See SPE-C-G0037, "Software Design Description", Gemini 8m Telescopes Project, See cics_smb_002, "Core Instrument Control System -- Introduction & Specification", Steven Beard, ROE. and See cics_smb_022, "CICS -- Architectural Design Document", Steven Beard, Royal Observatory Edinburgh.. See also the discussion in reference See cics_smb_016, "The OCS/ICS/DHS Observing Sequence and Data Flow", Steven Beard, Royal Observatory Edinburgh..

Mandated and dynamic header information

NIFS is mandated to deliver at least the following items of header information (see ICD 3, See dhs_pdr_icd3, "ICD 3 -- Bulk Data Transfer", Norman Hill & Severin Gaudet, DAO., for a description of the recommended types and data structures for these items). These are simply examples of header data that NIFS will supply, a full list is included in the PDF tables in ICD (1.9f/3.1, See "ICD 1.9f/3.1 -- Near-infrared Integral-Field Spectrograph (NIFS) to Observatory Control System interface", Mark Jarnyk, Peter Young, RSAA.):

• For each data set:
• Data label;
• Lifetime of the data set;
• Name of the quick look streams associated with the data set2. For NIFS there will be one quick look stream for the raw data and, optionally, a second quick look stream for the compressed spatial image.
• Readout mode used;
• Number of non-destructive reads;
• Period between non-destructive reads;
• Universal Time at the start and end of the data set observation (UTSTART, UTEND);
• The total elapsed time (ELAPSED) and the total exposure time (EXPTIME);
• Then for each frame within that data set:
• Size and shape of the data array;
• Data type of the data array;
• Data units;
• Plus the following items, which are relevant for science data only:
• World Coordinate System information (e.g. sufficient information to be able to determine the [RA,Dec] of the centre of each pixel of the compressed spatial image of the object-- see See tcs_ptw_008, "World Coordinates", Pat Wallace, Rutherford Appleton Laboratory.).

Data structures for NIFS science data

1. Spectral Data

Each NIFS data set observation will be contained in a standard DATASET structure, as described in the "Data Structure Specifics" section of ICD/3, See dhs_pdr_icd3, "ICD 3 -- Bulk Data Transfer", Norman Hill & Severin Gaudet, DAO.. The DATASET structure will include necessary dynamic header information described in See Mandated and dynamic header information above and will have separate frames for each of the four readout amplifiers of the detector. Each of these frames will have a set of reference pixels that can be used for data calibration. The data and reference pixels will be stored in separate sub-frames but related through their frame identifiers. The number of reference pixels per quadrant will be controlled through a NIFS CAD parameter but will typically be 32. In addition to these data, variance and quality frames will also be stored.

In summary, each NIFS image file will contain sixteen separate frames, four per quadrant, i.e. intensity, variance, quality and reference data. The SDS data structure description is as follows:

 

dataset DHS_BD_DATASET {structure}

instrument DHS_DT_STRING "nifs"

telescope DHS_DT_STRING "Gemini North"

.

.

frame(1) DHS_BD_FRAME {structure}

frameId DHS_DT_STRING "1"

frameTitle DHS_DT_STRING "Quadrant 1 data array"

dataType DHS_DT_STRING "Intensity"

axisSize(1..2) DHS_DT_UNIT32 1024, 1024

origin(1..2) DHS_DT_UNIT32 1024, 0

.

frame(1) DHS_BD_FRAME {structure}

frameId DHS_DT_STRING "1.1"

frameTitle DHS_DT_STRING "Variance array"

dataType DHS_DT_STRING "Variance"

axisSize(1..2) DHS_DT_UNIT32 1024, 1024

origin(1..2) DHS_DT_UNIT32 1024, 0

.

frame(2) DHS_BD_FRAME {structure}

frameId DHS_DT_STRING "1.2"

frameTitle DHS_DT_STRING "Data quality array"

dataType DHS_DT_STRING "Quality"

axisSize(1..2) DHS_DT_UNIT32 1024, 1024

origin(1..2) DHS_DT_UNIT32 1024, 0

.

frame(3) DHS_BD_FRAME {structure}

frameId DHS_DT_STRING "1.3"

frameTitle DHS_DT_STRING "Reference pixel array"

dataType DHS_DT_STRING "Reference"

axisSize(1..2) DHS_DT_UNIT32 1024, 32

origin(1..2) DHS_DT_UNIT32 1024, 1024

.

frame(2) DHS_BD_FRAME {structure}

frameId DHS_DT_STRING "2"

frameTitle DHS_DT_STRING "Quadrant 2 data array"

dataType DHS_DT_STRING "Intensity"

axisSize(1..2) DHS_DT_UNIT32 1024, 1024

origin(1..2) DHS_DT_UNIT32 0, 0

.

frame(1) DHS_BD_FRAME {structure}

frameId DHS_DT_STRING "2.1"

frameTitle DHS_DT_STRING "Variance array"

dataType DHS_DT_STRING "Variance"

axisSize(1..2) DHS_DT_UNIT32 1024, 1024

origin(1..2) DHS_DT_UNIT32 0, 0

.

frame(2) DHS_BD_FRAME {structure}

frameId DHS_DT_STRING "2.2"

frameTitle DHS_DT_STRING "Data quality array"

dataType DHS_DT_STRING "Quality"

axisSize(1..2) DHS_DT_UNIT32 1024, 1024

origin(1..2) DHS_DT_UNIT32 0, 0

.

frame(3) DHS_BD_FRAME {structure}

frameId DHS_DT_STRING "2.3"

frameTitle DHS_DT_STRING "Reference pixel array"

dataType DHS_DT_STRING "Reference"

axisSize(1..2) DHS_DT_UNIT32 32, 1024

origin(1..2) DHS_DT_UNIT32 1024, 0

.

frame(3) DHS_BD_FRAME {structure}

frameId DHS_DT_STRING "3"

frameTitle DHS_DT_STRING "Quadrant 3 data array"

dataType DHS_DT_STRING "Intensity"

axisSize(1..2) DHS_DT_UNIT32 1024, 1024

origin(1..2) DHS_DT_UNIT32 0, 1024

.

frame(1) DHS_BD_FRAME {structure}

frameId DHS_DT_STRING "3.1"

frameTitle DHS_DT_STRING "Variance array"

dataType DHS_DT_STRING "Variance"

axisSize(1..2) DHS_DT_UNIT32 1024, 1024

origin(1..2) DHS_DT_UNIT32 0, 1024

.

frame(2) DHS_BD_FRAME {structure}

frameId DHS_DT_STRING "3.2"

frameTitle DHS_DT_STRING "Data quality array"

dataType DHS_DT_STRING "Quality"

axisSize(1..2) DHS_DT_UNIT32 1024, 1024

origin(1..2) DHS_DT_UNIT32 0, 1024

.

frame(3) DHS_BD_FRAME {structure}

frameId DHS_DT_STRING "3.3"

frameTitle DHS_DT_STRING "Reference pixel array"

dataType DHS_DT_STRING "Reference"

axisSize(1..2) DHS_DT_UNIT32 1024, 32

origin(1..2) DHS_DT_UNIT32 0, 1024

.

frame(4) DHS_BD_FRAME {structure}

frameId DHS_DT_STRING "4"

frameTitle DHS_DT_STRING "Quadrant 4 data array"

dataType DHS_DT_STRING "Intensity"

axisSize(1..2) DHS_DT_UNIT32 1024, 1024

origin(1..2) DHS_DT_UNIT32 1024, 1024

.

frame(1) DHS_BD_FRAME {structure}

frameId DHS_DT_STRING "4.1"

frameTitle DHS_DT_STRING "Variance array"

dataType DHS_DT_STRING "Variance"

axisSize(1..2) DHS_DT_UNIT32 1024, 1024

origin(1..2) DHS_DT_UNIT32 1024, 1024

.

frame(2) DHS_BD_FRAME {structure}

frameId DHS_DT_STRING "4.2"

frameTitle DHS_DT_STRING "Data quality array"

dataType DHS_DT_STRING "Quality"

axisSize(1..2) DHS_DT_UNIT32 1024, 1024

origin(1..2) DHS_DT_UNIT32 1024, 1024

.

frame(3) DHS_BD_FRAME {structure}

frameId DHS_DT_STRING "4.3"

frameTitle DHS_DT_STRING "Reference pixel array"

dataType DHS_DT_STRING "Reference"

axisSize(1..2) DHS_DT_UNIT32 32, 1024

origin(1..2) DHS_DT_UNIT32 1024, 1024

.

 

The intensity data arrays will be 1024 x 1024 pixels in size and are from separate quadrants of the detector. They are kept separately so that reference pixels from each quadrant can be used for image calibration.

The variance arrays will, for linear-fitted data, contain the variance of the least-squares linear fit.

The quality arrays will contain a single byte for each pixel with the following interpretation:

0 Normal pixel
1-254 Pixel saturated after this number of NDRs
255 Bad pixel

The reference pixel arrays contain calibration data for each quadrant of the detector and vary in axes size because of the detector amplifier readout orientation.

 

1. Processed Image Data

NIFS will, optionally, send a compressed spatial image of the object to the DHS for transient display (see See Science data transmission scenario). These data will be in the following format:

 

dataset DHS_BD_DATASET {structure}

instrument DHS_DT_STRING "nifs"

telescope DHS_DT_STRING "Gemini North"

.

.

frame DHS_BD_FRAME {structure}

frameId DHS_DT_STRING "1"

frameTitle DHS_DT_STRING "Spatial image"

dataType DHS_DT_STRING "Intensity"

axisSize(1..2) DHS_DT_UNIT32 145, 140

 

The intensity data array will be 145 x 140 pixels in size and represents the 29 NIFS slitlets duplicated five times with 70 pixels in the spatial direction duplicated twice so that an approximately square image on the sky is displayed. (The 29 slitlets are 0.103" wide while the 70 spatial pixels are 0.0425" high, therefore the interpolated square pixels will be 0.0206" x 0.0213").

Command description

All the commands recognised by the DHS across a data link are described in ICD/3, See dhs_pdr_icd3, "ICD 3 -- Bulk Data Transfer", Norman Hill & Severin Gaudet, DAO..

Status information

All status information is transmitted to the DHS in a header attached to the data.

Alarm conditions

None known.

Communication infrastructure

Same as that described in See Communication infrastructure.

Software architecture

Same as that described in See Software architecture.

Events and responses

The events and responses over this interface are exactly the same as the ones described in the "Events and Responses" section of ICD/3, See dhs_pdr_icd3, "ICD 3 -- Bulk Data Transfer", Norman Hill & Severin Gaudet, DAO., except for "ICD 3 client" read "Detector Controller of the ICS".

Calibration data transmission scenario

See The flow of science data and headers through the Gemini Control System and NIFS shows the flow of science data through the Gemini Control System. Note that calibration data may flow from the DHS back to an Instrument Control System. This would happen only if an instrument needs to calibrate its data internally in real time before transmitting it to the DHS. This is true for NIFS, where compressed spatial images are required for real-time display. The basic scenario is as follows:

1. The OCS instructs NIFS to take a calibration frame (giving NIFS a data label, as described in the scenario in See Science data transmission scenario).
2. The Instrument Sequencer part of the NIFS ICS forwards the OCS commands to the DC part of the NIFS ICS.
3. The DC takes the calibration frame and stores it internally.
4. The calibration frame is sent by the DC to the DHS using the method described in See Science Data from NIFS to the Data Handling System.
5. The DHS stores each calibration frame for future use.
6. Whenever the NIFS DC requires a new calibration frame (e.g., after a change in configuration or at the beginning of a new session) it sends a request to the DHS for a particular data label.
7. If the calibration data request is successful, the DHS transmits the contents of the file to the DC. If the calibration data request fails, the DHS will return an error.
8. The DC stores the calibration frame internally and keeps it for future data preprocessing.

Command description

All the commands recognised by the DHS across a data link are described in ICD/3, See dhs_pdr_icd3, "ICD 3 -- Bulk Data Transfer", Norman Hill & Severin Gaudet, DAO..

Status information

All status information is transmitted to the DHS in a header attached to the data.

Alarm conditions

None known.