Äîêóìåíò âçÿò èç êýøà ïîèñêîâîé ìàøèíû. Àäðåñ îðèãèíàëüíîãî äîêóìåíòà : http://www.naic.edu/~phil/software/hdrs/idl.hdr
Äàòà èçìåíåíèÿ: Tue Jan 10 00:07:33 2006
Äàòà èíäåêñèðîâàíèÿ: Sat Dec 22 04:50:03 2007
Êîäèðîâêà:
Ïîèñêîâûå ñëîâà: crater

was hdr

idl spectral line hdr

01sep04 links:
data structure
header
standard header
correlator header.
doppler header

The interim correlator idl data structure is a hierarchy of structures holding headers and data for a record or scan. it is returned by the correlator i/o routines (corget, corinpscan,corgetm). Most of the documentation refers to this as a {corget} data structure and is typically called b. The number of elements in a given b structure depends on the number of correlator boards used in the observation. For a 4 board experiment it would look like:

IDL> help,b,/st
** Structure <8495b44>, 8 tags, length=271872, data length=271872, refs=1:
   B1              STRUCT    -> <Anonymous> Array[1]
   B2              STRUCT    -> <Anonymous> Array[1]
   B3              STRUCT    -> <Anonymous> Array[1]
   B4              STRUCT    -> <Anonymous> Array[1]

The b1 thru b4 are the information for boards 1 thru 4. Each of these b.bn hold a header and data set. Its format is listed below:

**b.b1** Idl data structure 1 pixel or board
field name	data type	description
H	STRUCT HDR	hdr used by interim correlator
HF	STRUCT WASHDR	new header info for was/wapps
P	INT ARRAY[2]	pol Number 1->polA,2->polb
ACCUM	DOUBLE	for coraccum usage
D	FLOAT ARRAY[NCHAN,NPOL]	The data

**b.b1.h** header used by interim correlator (top)
field name	data type	description
std	struct hdrstd	standard ao header used by all data taking programs (spectral line, aeronomy,sband)
cor	struct corv2	correlator configuration/status
pnt	struct hdrpnt	pointing information
iflo	struct hdriflo	IF and LO setup information
dop	struct hdrdop	doppler information
proc	struct hdrproc	procedure/pattern related information particular to a given experiment.

**b.b1.h.std** standard header (top)
field name	data type	description
hdrmarker	byte array[4]	marks start of a header in a datafile. Always holds the 4 letters "hdr_"
hdrlen	long	number of bytes in the entire header. Used to read raw data files from disc.
reclen	long	number of bytes in entire header/data sequence on disc. This is used to read the raw data from disc.
id	byte[8]	Holds an ascii id for the program that wrote the data set. Interim correlator data: "corProg"
version	byte[4]	ascii version of program that wrote this data. format: nn.n
date	long	year and day number for the current scan. Recorded at the start of the scan. The format is: yyyyddd where yyyy is the 4 digit year and ddd is the day number of the year. Eg. 2004201
time	long	AST seconds from midnight for the record end of integration time. This may be off by 1 second. It updates on every record.
expnumber	long	experiment number for this experiment. Not used since they switched the experiment numbers to an alphanumeric format.
scannumber	long	number that uniquely defines the scan. Format is ydddnnnnn where y is the last digit of the year, ddd is the day number of the year, and nnnnn is a number that increments sequentially during a day. Scan numbers are determined at the beginning of the scan.
recnumber	long	counts the integrations of a scan. It is 1 based. It increments each time a new integration starts. It is the same as grpnum
stscantime	long	The start time of the scan in AST seconds from midnight. Use this variable and the integration time to generate accurate record time stamps. eg If you do 1 second integrations, then the center of integration n (counting from 1 ) is stscantime + (n-.5)*integration time.
sec	HDRAO_SEC	this structure describes what other hdr sections are included in this header. Allows for generation of headers with different hdr section combinations.
free14 free13 free12 free11	long	locations that are not in use.
grpNum	long	The integration number. Same as recnumber. It is 1 based.
grptotRecs	long	The number of hdr/data records that are included in 1 integration. If you are observing with 8 pixels then there would be 8 hdr/data records for 1 integration or group.
grpCurRec	long	The hdr/data record count for this hdr/data record. It goes from 1 to grpTotRecs
datatype	byte[4]	the type of data in the data portion of the record. Not needed for correlator data.
azTTD	long	the azimuth encoder in 1/10000 of a degree units. It was sampled at the posTmMs timestamp. The az,gr,ch variables are duplicated in the pnt header. They are included here because the aeronomy programs do not use the pnt header but they do want the az,za locations.
grTTD	long	The gregorian encoder in 1/10000 of a degree units. It was sampled at the posTmMs time stamp.
chTTD	long	The carriage house encoder in 1/10000 of a degree units. It was sampled at the posTmMs time stamp.
posTmMs	long	The time stamp for the azttd,grttd, and chttd. This is AST milliseconds from midnight. The timestamp/data sample should be synchronized to better than a millisecond.
free2 free1	long	unused header locations.

**b.b1.h.cor** the correlator header (top)
field name	data type	description
id	byte[4]	header section id. contains "cor "
ver	byte[4]	version of this correlator header section. format is "xx.x"
masterclock	long	the correlator master clock period in nanoseconds. For interim correlator this is the number 20
dumpLen	long	the number of master clocks between correlator chip readouts. The integration time will be this value minus .34 microseconds. Typical dumplens are 5000000 giving exactly 1 second between chip readouts. the integration time will be 1 second minus .34 microseconds.
dumpsPerInteg	long	the number of "dumps" of dumplen master clocks that are included in a single integration that is written out to disc. The compute will integrate this many dumps before writing data out to disc. It is typically 1.
lagsSbcIn	long	The number of lags per sub correlator (sbc) that are read from the correlator. This number can be more that the number supplied to the user if 9 level or interleaved sampling is used.
lagsbcout	long	the number of lags/spectral channels in each spectra/acf written to disc. The user should use this value when computing channel widths.
numsbcin	long	the number of subcorrelators used for input on this correlator board. If 9 level or interleaved sampling is used, then this will be more than the number provided to the user.
numsbcout	long	The number of sbc's used for output to disc for this board. It can be 1,2 or 4 if stokes mode is used.
bwNum	long	The code used to specify the bandwidth. For the interim correlator the bandwidth is 100Mhz/(2^bwnum). eg 1=50Mhz,2=25Mhz,3=12.5Mhz etc..
lagConfig	long	The correlator configuration used for this board. The codes are: 0-9x9_A,1-9x9_B 1 pol for entire board 4-3x3_CMPLX 5-3x3_IQ 6-3x3_INTLV_A 7-3x3_INTLV_B interleaved 1 pol per board 8-3x3_INTLVIQ interleaved to pol per board 9-9x9_IQ 0 level 2 pol per board 10-3x3_POL 3 level stokes mode.
state	long	bit mask holding state information
frqBufThisRec	long	freq buf number for this record. 1,2 ,3 , or 4.
cycleLen	long	The cal or frequency cycle for this scan.
calcycl	byte[8]	Cal cycle used. coding is y,n
frqCycl	byte[8]	The frequency cycle order. Use 1,2.3,4 in ascii.
boardid	long	correlator board number. values are 6 thru 9.
numBrdsUsed	long	the number of correlator boards used in this scan.
attnDb	long[2]	correlator attenuator values for the spectra of this record. values are 0 thru 15.
pwrCnt	float[2]	The power counter values for the spectra of this record. The values are normalized to 1 second.
lag0pwrratio	float[2]	The power as seen by the 0 lags for the spectra of this record. The units are measured power / optimum power (for n level sampling).
caloff	float[2]	The lag0pwrratio if this record was a cal off record. If a cal cycle was used then this holds the cal off power for the sequence.
calOn	float[2]	The lag0pwrratio if this record was a cal on record. If a cal cycle of say yynn was used for this record, then calOn holds the total power part of the integration that came from the calOn.
state2	long	more state information in bitmap format.
		the rest is decoder information that is not used.

**b.b1.h.dop (the doppler header). (top)**
field name	data type	description
id	byte[4]	header section id. contains "dop"
ver	byte[4]	version of this doppler header section. format is " 1.0"
factor	double	doppler correction factor used. freqTopo=freqRest*factor . This cal be: velocity: 1/(1 + v/c) optical definition zoptical: 1/(1+z) zradio : 1/1-z)
velorz	double	The value of the objects velocity in the requested velocity coordinate system.It will be km/sec or z depending on the velocity type requested (see stat word below)
freqBcRest	double	The rest frequency of the RF band center (in Mhz).
freqOffsetts	double	The freqeuncy offsets of each subband from the RF band center (in Mhz). These offsets will be applied in the rest frame (if dopsetsball is requested). They will be applied in the topocentric frame (if dopsetrfonly is requested). See the stat word below.
velobsproj	double	The velocity of the observer in the requested velocity coordinate system projected onto the requested pointing direction. (in km/sec)
tmdop	long	When this doppler information was computed for. Units are AST seconds from midnite.
stat	long	this is a bitmap with 32 bits: the values are: (big endian ..) B31: 1 - doppler correct all bands (dopsetsball). 0 - just doppler correct the rf center freq (dopsetrfonly). B30-B27 velocity coordinate system: 0 - topocentric 1 - geocentric 2 - heliocentric 3 - lsr B26-B25 velocity type 0 - user specified optical velocity 1 - user specified z optical 2 - user specified z radio B24-B0 not used.
fill	long(2)	filler to make header a multiple of 8 bytes.

Notes:

The doppler timestamp tells when the doppler was computed. For most scans this is done at the start of the scan. Normally the doppler and frequencies are not updated during a scan.

home_~phil