next up previous
Next: A proposed route to Up: gbtFits Previous: Introduction

Subsections


Standards for Device and Log FITS Files

General

1. All GBT FITS files shall conform to the FITS standard (i.e. SIMPLE=T).

2. The FITS file layout shall be as follows:

3. Wherever possible (i.e. where the concept being expressed is identical) existing FITS keywords shall be used. In order, the following keyword sets should be used:

Keywords from the above lists should not be used for anything other than their existing meanings.

If there is no existing keyword describing the required concept, a new one may be constructed. Underscores should be used for punctuation if required (see HEASARC recommendation R1).

4. Where appropriate, use should be made of existing GBT extension structure definitions. If this is not possible, a new structure may be defined, and the standard FITS keyword EXTNAME used to indicate the purpose of the extension. With the exception of the DATA binary table extension, extensions with different structures should not be given the same value of EXTNAME. See individual GBT device FITS file Project Notes for existing extension names.

The EXTVER keyword should be used to distinguish different extensions of the same type and with the same value of EXTNAME in a single FITS file. The use of the keyword EXTTYPE is not recommended. See the FITS User's Guide Section 3.3.2 for more details.

5. If a new FITS extension structure is defined, the following HEASARC FITS Working Group recommendations should be followed for the construction of keywords, values and column names:

6. In general, the comment field should be used to expand on the meaning of the value, rather than to restate the information implied by the FITS rules. Unfortunately this is not possible in the case of column keywords generated by the FITSIO library. In this case, additional COMMENT card images should be used immediately preceding the card image in question to provide additional explanations if necessary. e.g:

COMMENT   BLANKTIM is the amount of blanking at the start of each phase
TTYPE1  = 'BLANKTIM'           / label for field 1

Device FITS Files Standard

Primary Header Keywords

The Primary Header of all GBT Device FITS file shall start with a number of required keywords as shown in the example below:

SIMPLE  =                    T / file does conform to FITS standard
BITPIX  =                    8 / number of bits per data pixel
NAXIS   =                    0 / number of data axes
EXTEND  =                    T / FITS dataset may contain extensions
ORIGIN  = 'NRAO Green Bank'    /
INSTRUME= 'Spectrometer'       / device or program of origin
GBTMCVER= '3.3.0   '           / telescope control software release
FITSVER = '2.1     '           / FITS definition version for this device
DATEBLD = '2004-12-03T00:26:21' / time program was linked
SIMULATE=                    0 / Is the instrument in simulate mode?
DATE-OBS= '2001-11-17T15:54:13' / Manager parameter startTime
TIMESYS = 'UTC     '           / time scale specification for DATE-OBS
TELESCOP= 'NRAO_GBT'           / Green Bank Telescope (Robert C. Byrd 100m)
OBJECT  = '1950+34 '           / Manager parameter source
PROJID  = 'test    '           / Manager parameter projectId
OBSID   = 'map     '           / Manager parameter scanId
SCAN    =                  543 / Manager parameter scanNumber
 :
 :
(other application-specific keywords)
 :
 :
END

The first four items are mandatory FITS keywords.

ORIGIN is a reserved FITS standard keyword.

INSTRUME is the FITS standard keyword used to specify the ``instrument'' responsible for producing the data in the file. In the case of genuine instruments (e.g. the DCR) the appropriate name should be used. For other data sources (e.g. a Sampler value stored by the Archivist or the receiver calibration values stored by the Measurements Manager) the value of the INSTRUME keyword will be that of the program generating the FITS file.

GBTMCVER, FITSVER, DATEBLD, and SIMULATE are GBT-specific keywords.

GBTMCVER refers to the version of the M&C system in use at the time the file was created.

FITSVER refers to the version of the GBT FITS definition the file conforms to. The leading number refers to the global definition version (i.e. this document), while the trailing number refers to a revision specific to this specific type of FITS file. For example, a value of 2.5 in a Spectrometer FITS file would imply the fifth revision of the Spectrometer FITS file definition conforming to the second revision of the global GBT FITS standards.

DATEBLD is generated automatically via the Unix command ``date -u +whenever the program which actually writes the FITS file is linked.

SIMULATE specifies whether the program was running in simulation mode when the file was written.

DATE-OBS is the FITS standard keyword to specify the date and time of the start of an observation. As recommended in the standard, the UTC time scale is explicitly specified using the TIMESYS keyword. This time in GBT Device files represents the nominal scheduled time and is therefore represented only to the nearest second.

TELESCOP is a reserved FITS standard keyword.

OBJECT is the FITS standard, and PROJID, OBSID and SCAN pre-existing FITS keywords used to define these quantities, and so are used here. The corresponding GBT M&C (Scan Coordinator) parameters are indicated in the comments.

The one exception to the above set of standard keywords is the scan log FITS file which does not include all of the above keywords in its primary HDU. The scan log (always named ``ScanLog.fits'') is a listing of all of a project's device FITS files grouped by scan. The purpose is to identify and locate all the device FITS files associated with a given scan. Since it describes many scans and therefore many scan start times, descriptions and numbers, its header does not include the keywords DATE-OBS, TIMESYS, OBSID, OBJECT, and SCAN as shown the following example.

ScanLog Primary Header
-------------------------------------------------------------------------------
SIMPLE  =                    T / file does conform to FITS standard            
BITPIX  =                    8 / number of bits per data pixel                 
NAXIS   =                    0 / number of data axes                           
EXTEND  =                    T / FITS dataset may contain extensions           
ORIGIN  = 'NRAO Green Bank'    /
INSTRUME= 'ScanLog'            / device or program of origin
GBTMCVER= '3.3.0   '           / telescope control software release
FITSVER = '2.1     '           / FITS definition version for this device
DATEBLD = '2004-12-03T00:26:21' / time program was linked
SIMULATE=                    F / Is the instrument in simulate mode?
TELESCOP= 'NRAO_GBT'           / Green Bank Telescope (Robert C. Byrd 100m)
PROJID  = 'test    '           / Manager parameter projectId
END

PORT Binary Table Extension

The PORT binary table extension (EXTNAME=PORT) is used by GBT backends to describe their inputs. Each row is identified by BANK (character) and PORT (non-zero positive integer). Additional backend-specific columns may be included, e.g., level, speed, bandwidth, taper, threshold, attenuation, detected power, or any other port specific settings. This example header is from the Spectrometer.

XTENSION= 'BINTABLE'           / binary table extension
BITPIX  =                    8 / 8-bit bytes
NAXIS   =                    2 / 2-dimensional binary table
NAXIS1  =                  118 / width of table in bytes
NAXIS2  =                    2 / number of rows in table
PCOUNT  =                    0 / size of special data area
GCOUNT  =                    1 / one data group (required keyword)
TFIELDS =                    5 / number of fields in each row
TTYPE1  = 'BANK                / label for field   1
TFORM1  = '1A      '           / data format of field: 1-byte CHAR
TUNIT1  = 'INDEX   '           / physical unit of field
TTYPE2  = 'PORT                / label for field   2
TFORM2  = '1I      '           / data format of field: 2-byte INTEGER
TUNIT2  = 'INDEX   '           / physical unit of field
TTYPE3  = 'ATTENSET'           / label for field   3
TFORM3  = '1E      '           / data format of field: 1-byte CHAR
TUNIT3  = 'dBm     '           / physical unit of field
TTYPE4  = 'MEASPWR '           / label for field   4
TFORM4  = '1A      '           / data format of field: 1-byte CHAR
TUNIT4  = 'INDEX   '           / physical unit of field
TTYPE5  = 'LEVEL   '           / label for field   5
TFORM5  = '1I      '           / data format of field: 2-byte INTEGER
TUNIT5  = 'COUNT   '           / physical unit of field
TTYPE6  = 'SPEED   '           / label for field   6
TFORM6  = '1D      '           / data format of field: 8-byte DOUBLE
TUNIT6  = 'HZ      '           / physical unit of field
TTYPE7  = 'BANDWDTH'           / label for field   7
TFORM7  = '1D      '           / data format of field: 8-byte DOUBLE
TUNIT7  = 'HZ      '           / physical unit of field
TTYPE8  = 'FSTART  '           / label for field   8
TFORM8  = '1D      '           / data format of field: 8-byte DOUBLE
TUNIT8  = 'Hz      '           / physical unit of field
TTYPE9  = 'FEND    '           / label for field   9
TFORM9  = '1D      '           / data format of field: 8-byte DOUBLE
TUNIT9  = 'Hz      '           / physical unit of field
EXTNAME = 'PORT    '           / name of this binary table extension
END

STATE Binary Table Extension

The STATE table describes the setup of a device's switching signals. This table is used to record the commanded switching signal setup by all backends and the LO1. Note that the times specified in this table are nominal and may be modified due to implementation constraints inherent in the device generating (switching signals' master) the signals. An example STATE header, plus ASCII listing of typical table data, is given below:

STATE Binary Tables Extension: Header
-------------------------------------------------------------------------------
XTENSION= 'BINTABLE'           / binary table extension
BITPIX  =                    8 / 8-bit bytes
NAXIS   =                    2 / 2-dimensional binary table
NAXIS1  =                   20 / width of table in bytes
NAXIS2  =                    4 / number of rows in table
PCOUNT  =                    0 / size of special data area
GCOUNT  =                    1 / one data group (required keyword)
TFIELDS =                    4 / number of fields in each row
TTYPE1  = 'BLANKTIM'           / label for field   1
TFORM1  = '1D      '           / data format of field: 8-byte DOUBLE
TUNIT1  = 'SECONDS '           / physical unit of field
TTYPE2  = 'PHSESTRT'           / label for field   3
TFORM2  = '1D      '           / data format of field: 8-byte DOUBLE
TUNIT2  = 'NONE    '           / physical unit of field
TTYPE3  = 'SIGREF  '           / label for field   4
TFORM3  = '1J      '           / data format of field: 2-byte INTEGER
TUNIT3  = 'T/F     '           / physical unit of field
TTYPE4  = 'CAL     '           / label for field   5
TFORM4  = '1J      '           / data format of field: 2-byte INTEGER
TUNIT4  = 'T/F     '           / physical unit of field
NUMPHASE=                    2 / Number of Phases if only Internal Switch Sig
SWPERIOD=            5.466E+00 / Switching period
MASTER  = 'Spectrometer'       / Switching Signals Master
EXTNAME = 'STATE   '           / name of this binary table extension
END
-------------------------------------------------------------------------------

STATE Binary Tables Extension: Data (complete)
-------------------------------------------------------------------------------
ROW   BLANKTIM  PHSESTRT    SIGREF CAL
1   9.96147E-02 .0000E+00     0     0
2   9.96147E-02 .5000E+00     0     1
-------------------------------------------------------------------------------

The definitions of the STATE table specific keywords are given below:

NUMPHASE
The number of phases in each switching period.
SWPERIOD
The the length of the switching period for this scan in seconds.
MASTER
The name of the selected device for driving the switching signals.

The definitions of the columns in the binary table are as follows:

BLANKTIM
The number of seconds at the start of the phase before integration begins.
PHSESTRT
Phase edge in fractions of a switch period. First value is always zero and following values monotonically increase but must terminate less than one.
SIGREF
Value of the SIGREF switching signal where zero indicates signal.
CAL
Value of the CAL switching signal where zero indicates no noise.

Specific applications my include additional columns which are state dependent, e.g., the Spectral Processor has the columns FFTS and DELETED.

DATA Binary Table Extension

GBT backends (DCR, Spectral Processor, Spectrometer, and Holography) use a binary table extension with EXTNAME=DATA to contain the main data array. The general structure of these extensions is the same in each case, but the specific columns are backend dependent.

The number of columns varies among backends, but the first column is always the start time for the integration time which the row of data contains. It is a double representing the Fractional Julian Date. For pulsar data or other cases where more accuracy is needed, then two additional columns containing the MJD and seconds pass UT midnight are used. The final column is the DATA itself which may be multi-dimensional. The format and units varies among backends. The keyword TDIMn and TDESCn are used to describe the dimensions and names of the data's axes.

TTYPE1  = 'DMJD    '           / label for field   1
TFORM1  = '1D      '           / data format of field: 8-byte DOUBLE
TUNIT1  = 'd       '           / physical unit of field
TTYPE2  = 'UTDSTART'           / label for field   2
TFORM2  = '1J      '           / data format of field: 4-byte INTEGER
TUNIT2  = 'MJD     '           / physical unit of field
TTYPE3  = 'UTCSTART'           / label for field   3
TFORM3  = '1D      '           / data format of field: 8-byte DOUBLE
TUNIT3  = 's       '           / physical unit of field
TTYPE4  = 'DATA    '           / label for field   4
TFORM4  = '32768E  '           / data format of field: 4-byte REAL
TUNIT4  = 'correl  '           / physical unit of field
EXTNAME = 'DATA    '           / name of this binary table extension
TDIM4   = '(8192,2,2)'         / Structure of 3D item (LAG, SAMPLER, ACT_STATE)
CDESC1  = 'LAGS    '           / Axis 1 of DATA
CDESC2  = 'SAMPLER '           / Axis 2 of DATA
CDESC3  = 'ACT_STATE'          / Axis 3 of DATA

Log FITS Files Standard

Primary Header Keywords

The Primary Header of all GBT Log FITS file is shown in the example below:

SIMPLE  =                    T / file does conform to FITS standard
BITPIX  =                    8 / number of bits per data pixel
NAXIS   =                    0 / number of data axes
EXTEND  =                    T / FITS dataset may contain extensions
ORIGIN  = 'NRAO Green Bank'    /
INSTRUME= 'sampler2log'        / device or program of origin
GBTMCVER= '3.3.0   '           / telescope control software release
FITSVER = '2.1     '           / FITS definition version for this device
DATEBLD = '2004-12-03T00:26:21' / time program was linked
SIMULATE=                    F / Is the instrument in simulate mode?
DATE-OBS= '2001-11-17T15:54:13' / Manager parameter startTime
TIMESYS = 'UTC     '           / time scale specification for DATE-OBS
DEVICE  = 'Rcvr12_18'          / telescope's device
MANAGER = 'Rcvr12_18'          / device's manager
SAMPLER = 'gregorian'          / manager's sampler
COMMENT   Gregorian Receiver data:- monitor rate set by 'gregorianMonitorRate'
DELTA   =         6.000000E+01 / Minimum time between samples in seconds
UTSTART = 5.19454472192130E+04 / DMJD of first sample
END

The Log FITS file's Primary Header is similar to the Device's Primary Header. You will notice that the Log's Primary Header list contains keywords (DEVICE, MANAGER, SAMPLER, DELTA, and UTSTART) which are not in the Device's Primary Header. Conversely, the Device's Primary Header list contains keywords describing a scan (OBJECT, PROJID, OBSID, and SCAN) which the Log's keyword list does not contain since these files are not associated with telescope scans. Also not used in the Log FITS files is TELESCOPE since Log files are not necessarily tied to a specific telescope, e.g., weather stations or a central timing center.

Some of the the standard keywords have slightly difference meanings. DATE-OBS is the date and time of the first data sample in the file; as is UTSTART as Fractional Modified Julian date. The three keywords DEVICE, MANAGER, and SAMPLER unambiguously identify the source of the data in the file. In fact, the files are stored in a directory named for these keywords concatenated together with hyphens, e.g., ``Rcvr12_18-Rcvr12_18-gregorian.'' The keyword DELTA's value is the minimum time between samples in the file. Each possible data source or M&C Sampler has a description associated with it which is included in the header as a COMMENT.

Log Data Binary Table

Following the Primary Header is a BINTABLE header describing the layout of the log data. Each row contains data representing the values at a specific instance. The number of columns varies among files, but the first column is always the time that the sample was taken. It is a double representing the sample's Fractional Julian Date.

TTYPE1  = 'DMJD    '           / label for field   1
TFORM1  = '1D      '           / data format of field: 8-byte DOUBLE
TUNIT1  = 'd       '           / physical unit of field

Common GBT Keywords

The keywords described previously are used in tables found in more than one GBT FITS file and are listed in Appendix C. Each GBT FITS file may introduce other keywords specific to that file which are described in its own document. In addition, there are a number of GBT keywords used across GBT FITS files that have the same meaning, but are used in different parts of the file, e.g., sometimes as a header keyword and sometimes as a column identifier. Most of these deal with the IF. These are defined here and listed in Appendix C.

BACKEND
This keyword's value is the name of the device which produces a data file from the telescope astronomical signal. It is also the value of the Primary HDU keyword INSTRUME in a data FITS files. For Log and Dap FITS files it is the value of DEVICE. Examples are SpectralProcessor, Spectrometer, DCR, BCPM, and Holography.
PORT
This keyword's value is an integer (starting at 1) which, along with BANK, uniquely identifies a specific input to a BACKEND which terminates the signal path. PORT is used as a header keyword in backend FITS files and a column name in the IFManager FITS file.
BANK
This keyword's values is a character (A, B, C, ...) which describes a subset of a BACKEND's PORTs. For example, the SpectralProcessor divides its 8 PORTS into 2 BANKS (A and B) of 4 PORTs each, the Spectrometer dynamically partitions its 40 PORTs among 4 possible BANKS, and the DCR has 2 BANKs of 16 PORTs of which only one BANK may be active at a time. BACKENDs which do not partition their input PORTs are simply defaulted to BANK A. Like PORT, BANK is used as a header keyword in backend FITS files and a column name in the IFManager FITS file.
FEED
This keyword's value is an integer (starting at 1) which identifies a physical entry point on the RECEIVER for the RF signal. Each FEED has an offset from the antenna's beam. It is used in the Antenna FITS file to specify the offset and in the IFManager FITS file to identify the origin of a telescope signal's path.
RECEPTOR
This keyword's value is a name which identifies a distinct signal route, e.g., for separate polarizations, branching off from the FEED in the RECEIVER. It is used in the IFManager FITS file as part of each signal path and in the Calibration FITS file to characterize sets of calibrations.
RECEIVER
This keyword's value is a name which identifies a device for capturing the RF signal from a reflector and accepting a sinusoid from the LO1 to produce the Intermediate Frequency (IF) signal, It is used in the IFManager FITS file as the first device in a signal path and in Log and Dap FITS files as the value of DEVICE. Examples are Rcvr1_2, Rcvr40_52, and RcvrPF_1.

In other words, the signal in the GBT may travel along several paths from the RECEIVER to the BACKEND. Starting at one of possibly several FEEDs on a RECEIVER, the signal may be split into separate RECEPTORs. BACKEND inputs are labeled by PORT and BANK.


next up previous
Next: A proposed route to Up: gbtFits Previous: Introduction
Bob Garwood
2011-07-23