This section describes the NOAA Polar Orbiter Level 1b Data Base that is archived by SSB, and from which users may request data.

Level 1b (following FGGE terminology) is raw data that have been quality controlled, assembled into discrete data sets, and to which Earth location and calibration information have been appended (but not applied).

The data are present on the data base as a collection of data sets. Each data set contains data of one type for a discrete time period. Thus, there are separate HRPT, LAC, GAC, HIRS, MSU, and SSU data sets. Time periods are arbitrary subsets of orbits, and may cross orbits (i.e., may contain data along a portion of an orbital track that includes the ascending node, the reference point for counting orbits). Generally, GAC, HIRS, MSU, and SSU data sets will be available for corresponding time periods and usually have a three to five minute overlap between consecutive data sets.

Prior to June 1981, the Earth location data in the AVHRR and TOVS Level 1b data may have been slightly inaccurate due to errors in the TIROS Information Processor (TIP) clock onboard the spacecraft. The 6-byte time code in the Level 1b data is taken from the TIP clock which routinely contained errors of 1.5 to 2.3 seconds.

Some problems have been encountered with NOAA-10 and NOAA-11 AVHRR Level 1b GAC data in regards to earth locations, distances between adjacent scan lines, data gaps, scan line numbers, and out of sequence scan times. It is not known at this time if these problems existed with the earlier spacecraft in the TIROS-N series. NESDIS/IPD is investigating these problems and will take corrective action. The following paragraphs summarize a memorandum from Karl W. Cox (SMSRC) to Pat Mulligan (NOAA/NESDIS/OSD) which details the problems. Copies of this memorandum are available from SSB.

As the spacecraft moves through its orbit, the expected angular distance between the nadir of adjacent GAC scans is approximately 0.0296 degrees of arc, or 3.2914 km, as measured from the center of the earth. This actual value of the average angular distance can vary by up to about 0.1712 km due to variations in satellite height, scan angle and other factors. Forty-eight randomly selected NOAA-10 and NOAA-11 GAC data sets were examined over a period of a few days at the beginning of July 1990. On the average, the distances between adjacent scan lines were outside the permitted window (0.2304 km) 45 times per dataset. The time difference between these adjacent scan lines was the expected 500 milliseconds, but the quality flags did not indicate a data gap.

When data gaps occur in GAC data, the scan line number is supposed to be incremented to reflect the number of scan lines corresponding to the length of the gap. However, the first scan line after a data gap was found to have the scan number next in sequence of those preceding the gap, while the second scan line following the gap had been incremented by the number of scan lines corresponding to the data gap. On an average, data gaps were found to occur two to three times per dataset with the gaps typically ranging from one to 40 scan lines.

In four out of the 48 GAC data sets examined, scan times were encountered which were not in proper sequence. Some of the time differences were very large. This problem introduces earth locations markedly different from those of adjacent scan lines. However, the scan line numbers were in ascending sequence as if there were no problems with the scan times or earth locations, and no scan quality flags had been set.

In the past, SSB has attempted to give the user only data with calibration information, but it was found that most users preferred to receive all the data (with or without calibration information) over their area and/or time span. The user can then use his own discretion in applying the calibration coefficients to any gaps of data without calibration information. It is SSB's policy that all Level 1b data (whether it includes calibration information or not) will be provided to the user for his specific area or time unless explicitly requested otherwise by the user.

In the event that the user receives data without calibration information, the data can be calibrated from the telemetry information contained in each scan. For a detailed explanation of this procedure, refer to NOAA Technical Memorandum NESS 107 entitled Data Extraction and Calibration of TIROS-N/NOAA Radiometers, available from SSB. In the case of a data set with some calibration present, the user can usually interpolate the calibration data between known points for the uncalibrated portion.

Clock Information

Users of Level 1b data should be aware that the satellite's on board clock experiences a small drift in time over a period of several months. Specifically, that time drift can be defined by Δt, where Δt is the spacecraft clock time (t) minus the actual UTC time. SOCC monitors this time error and maintains Δt to within ± one-half second. The Earth location data which is appended to the Level 1b data is based on the spacecraft clock time. Therefore, an error in Δt will be reflected as an error in Earth location. The error in Earth location due to this timing error could be as much as 4 kilometers at the satellite subpoint. SOCC normally applies the time correction around 2359 UTC on the scheduled date. The clock error, drift rate, last update and future update are announced in the APT Predict Bulletin (TBUS - TIROS Bulletin U.S.). The Level 1b process has been enhanced to incorporate a clock drift correction option. See Appendix L for details. Figure 2.0.1-1 shows a typical drift of Δt (note that points A and B are where SOCC applies the correction to Δt).

IBM Conventions

All the NOAA polar orbiter Level 1b data and products are produced on IBM mainframes. This section describes some of the characteristics of data written on an IBM mainframe. The bit and byte numbering conventions are described, in addition to the representations for signed binary integers and floating point numbers. These conventions are especially critical if the user does not use an IBM machine to read the data. This does not imply that these data cannot be read on non-IBM machines, but the user should exercise some caution when reading "IBM-generated" data on a non-IBM machine.

The bit and byte (one byte equals 8-bits) numbering convention for Level 1b data sets is as follows. The bits within each byte or word are numbered from the most significant bit (MSB) on the left to the least significant bit (LSB) on the right, with the MSB identified as bit 31, the next most significant as bit 30, and with the LSB as bit 0. Similarly, the byte containing the 8 MSBs of a 32-bit word is identified as byte 4; and the byte containing the 8 LSBs, as byte 1.

IBM's signed binary integers are usually represented as halfwords (16 bits) or words (32 bits). In both lengths, the leftmost bit (bit 31) is the sign of the number. The remaining bits (bits 1-15 for halfwords and 1-31 for words) are used to designate the magnitude of the number. Binary integers are also referred to as fixed-point numbers, because the radix point (binary point) is considered to be fixed at the right, and any scaling is done by the programmer.

Positive binary integers are in true binary notation with a zero sign bit. Negative binary integers are in two's-complement notation with a one bit in the sign position. In all cases, the bits between the sign bit and the leftmost significant bit of the integer are the same as the sign bit (that is, all zeros for positive numbers, all ones for negative numbers). Negative binary integers are formed in two's-complement notation by inverting each bit of the positive binary integer and adding one.

A floating point number is expressed as a hexadecimal fraction multiplied by a separate power of 16. The term floating point indicates that the placement, of the radix (hexadecimal) point, or scaling, is automatically maintained by the machine.

The part of a floating-point number which represents the significant digits of the number is called the fraction. A second part specifies the power (exponent) to which 16 is raised and indicates the location of the radix point of the number. The fraction and exponent may be represented by 32 bits.

A floating-point number has two signs: one for the fraction and one for the exponent. The fraction sign, which is also the sign of the entire number, is the leftmost bit of each format (0 for plus, 1 for minus). The numeric part of the fraction is in true notation regardless of the sign. The numeric part is contained in bits 8-31.

The exponent sign is obtained by expressing the exponent in excess-64 notation; that is, the exponent is added as a signed number to 64. The resulting number is called the characteristic. It is located in bits 1-7. The characteristic can vary from 0 to 127, permitting the exponent to vary from -64 through 0 to +63. This provides a scale multiplier in the range of 16-64 to 16+63. A nonzero fraction, if normalized, has a value less that one and greater than or equal to 1/16, so that the range covered by the magnitude of a normalized floating-point number is between 16-65 and 16+63.

Level 1b Data Set Names

This section describes the data set naming convention which is used for all Level 1b data sets. Each data set has a unique data set name which is generated when the data set is created. This 42-character name (which is coded in binary coded decimal [BCD]) will be used to reference the data sets. The data set name will be "NSS" followed by a set of alphanumeric qualifiers separated by periods (.). The complete data set name with all its qualifiers will be as follows:

NSS.Data-type.Spacecraft-Unique-ID.Year-day.Start-time.Stop-time.Processing-block-ID. Source

The qualifiers of the data set name are defined as shown in Table 2.0.3-1.

Data Set Header

This section describes the Data Set Header. All Level 1b data sets (with the exception of the SBUV/2) contain a Data Set Header record describing the data set. This header record is in binary and padded with trailing spare bytes to make it the same size as the full channel data set records. (Note: The Data Set Header for HRPT and LAC data sets is contained in two 7400-byte records. The first record contains the Data Set Header as described below and the second record will be meaningless to the user.) Currently, there are two slightly different Data Set Headers: one for the AVHRR and one for the TOVS data. The Data Set Header for TOVS has changed slightly from the original. It's format is given in Table 2.0.4-1.

SSB uses specialized software to extract parts of Level 1b datasets, based on user's selection criteria (channel, area and/or time selects). As of July 3, 1996, SSB modified the extraction software so that the Data Set Header record would reflect the actual number of output scan lines within the subsetted dataset and not the total number of scan lines found in the original dataset. This change does not affect users who order tape copies of entire datasets, just the users that order extracts.

The Data Set Header format was modified on two different occasions: September 8, 1992 and November 15, 1994. Appendix K contains the original format (before September 8, 1992) of the Data Set Header, while Appendix L contains the interim format (between September 8, 1992 and November 15, 1994) of the Data Set Header.

The current Data Set Header format for AVHRR data includes orbital parameters that were implemented with other enhancements on November 15, 1994. The format for the AVHRR Data Set Header is given in Table 2.0.4-2.

Valid spacecraft IDs are contained in Table 2.0.4-3. Note that the spacecraft ID is identical for NOAA-11 and TIROS-N. In this case, users should use the time code in conjunction with the spacecraft ID to verify that they have the correct satellite.

The data type of the data set is identified by the two integer codes contained in Table 2.0.4-4.

The start time is the spacecraft time code from the first frame of data processed for this data set and is contained in 6 bytes. The year is contained in the leftmost 7 bits of the first two bytes, the 9-bit Julian day is right-justified in the first two bytes, and the 27-bit millisecond UTC time of day is right-justified in the last four bytes. All other bits are zero. Figure 2.0.4-1 shows the format of the time code for both start and end times.

Complete scans that fall within data gaps are not included in the number of scans count. A gap in the data that covers one or more consecutive scans is counted as one data gap.

The end time is the spacecraft time code from the last frame of data processed for this data set. The content and format are the same as described for the start time (see Figure 2.0.4-1).

The Processing Block ID is a seven-byte field generated from start and end times. It contains the spacecraft revolution in which recording of the data set began and the revolution in which it terminated (same as the Processing Block ID described in beginning of Section 2.0.3).

The ramp/auto calibration field is contained in one byte. Bits 4-8 of this byte have meaning for GAC, LAC, and HRPT data sets only. These bits indicate ramp non-linearity. Bit 3 of this byte has meaning only for HIRS/2 and SSU data sets and contains the setting of the auto calibration override switch. Bit 4 is used for channel 1, bit 5 for channel 2, etc.

The DACS quality field consists of six types of DACS (Data Acquisition and Control Subsystem) quality information accumulated in the headers of all data sets derived from data input from DACS. The first two bytes contain a count of the input data frames that contained no frame sync word errors. The second two bytes contain a count of the DACS detected TIP parity errors. The last two bytes contain a sum of all auxiliary sync errors detected in the input data for the complete data set.

The calibration parameter ID identifies the calibration parameter input data set which is used to calibrate the data in this data set. The ID is encoded internally as a string of two 8-bit characters; not as an integer number.

DACS status information comprises one byte and is contained in the header of all data sets derived from data input from DACS. This byte is described in Table 2.0.4-5.

Source: http://www.ncdc.noaa.gov