rdsin [ parameter=value ... ] [ outputfile ... ] rdsin [ parameter=value ... ] [ directory ]
Parameters are: dmsp_types, on_pass_disk, tape_device, pass_number, files_per_pass, pass_date, pass_time, satellite, stored, temp_units, use_master, master_file, start_time, smth_lines, smth_samples, ss_calib, glob, t1_limb, override_form, debug_time, sync_time, sync_bits, time_diag, max_gap, archive_time, sat_time_test, dmdm_len, ts_dmdm.
rdsin creates TeraScan Optical Linescan System (OLS), Special Sensor Microwave Imager (SSM/I), Special Sensor Microwave Temperature Sounder (SSM/T1), Special Sensor Microwave Water Vapor Sounder (SSM/T2), SSJ4, Direct Mode Data Message (DMDM), and Equipment Status Telemetry (EST) datasets, from the Defense Meteorological Satellite Program (DMSP) real-time data smooth (RDS) and stored data smooth telemetries (SDS).
Input telemetry data can be read from the pass disk, tape, or standard UNIX disk files. Multiple passes on tape or the pass disk can be processed at once. In the case of UNIX disk files, additional "header" information needs to be provided by the user to process the pass.
The OLS sensor data is composed of two channels: a visible and a thermal channel. The image data from each of these channels has the same spatial resolution (~ 2.5km x 2.5km). The data are spatial averages of the higher resolution OLS data in the RTD telemetry stream. The RDS OLS images essentially resemble the data obtained from running rtdin on the RTD telemetry stream with ols_res=lo, except that averaging is done in both line and sample directions, as opposed to using subsampling in the line direction.
The visible and thermal data resolutions are 6 and 8 bits, respectively. Each is stored as byte data.
The overall spatial subset of the OLS data to be extracted can be specified in one of two ways:
1) the smallest rectangular area required to cover a region defined by a master dataset (see master).
2) a rectangular area of specific size, beginning at a user-specified time and scan sample.
The SSM/I is a passive microwave radiometer with the following seven channels: 19v, 19h, 22v, 37v, 37h, 85v and 85h GHz. The SSM/I uses a conical scan so all footprints of a given frequency along a scan have the same dimensions. There are 128 samples per scan for the two 85 Ghz channels and 64 samples per scan for the lower frequency channels. The spot size varies from about 50km for the 19 GHz channels to about 15 km for the 85 GHz channels. The SSM/I is primarily used to estimate various geophysical properties of the Earth and/or atmosphere. These include total columnar atmospheric precipitable water, ocean surface wind speed, sea ice concentration, etc. The TeraScan functions miedr and geoph convert SSM/I brightness temperatures into these, and other, geophysical quantities. The SSM/I sensor is only available on the f-8, f-10 and f-11 satellites (not on f-9).
The SSM/T1 is a passive microwave radiometer with the following seven channels: 50.5, 53.2, 54.35, 54.9, 58.4, 58.825 and 59.4 GHz. In the SSM/T1 output dataset these are named "mt1_1"..."mt1_7". Channel 1 is the window channel, and each higher channel "peaks" at, or has greatest sensitivity to, higher altitudes in the atmosphere, up to 22 km for channel 7. The SSM/T1 scans 7 samples cross-track, and has a spot size of approximately 175 km at nadir. The seven channels can be inverted using the TeraScan function t1edr to estimate the temperature and pressure height profiles of the atmosphere.
The SSM/T2 is a five channel passive microwave radiometer. It has three channels situated symmetrically about the 183.310 GHz water vapor resonance line, 180.310 +/-1, 183.310 +/-3, 183.310 +/-7, and two window channels, 91.655 and 150 Ghz. In the SSM/T2 output dataset these are named "mt2_1"..."mt2_5". The SSM/T2 scans 28 samples cross-track, has a spot size of approximately 45 km at nadir, and essentially has 4 times the spatial resolution of the (collocated) SSM/T1. These channels can be inverted using the TeraScan function t2edr to estimate the water vapor, specific humidity, and relative humidity profiles of the atmosphere. The SSM/T2 sensor is only available on the f-11 satellite.
Note: it is known that the OLS glare obstruction bracket on the DMSP spacecraft produces signal contamination at the edges of the SSM/T1 and SSM/T2 scan lines during terminator orbits. See parameter glob below.
The SSJ4 sensor is used to measure electron and ion counts in the atmosphere. It is a nadir viewing sensor with one sample per line per second. Data output variables are ion_counts and electron_counts. These are measured for twenty energy levels from 0.948 to 948 Kev. See level dimensions and energy_level variables in the SSJ4 output datasets. Additionally, because of the nadir sampling, latitude and longitude variables for each of the sample locations is computed and provided within the output datasets.
When ingesting special sensor data, rdsin extracts the entire pass of for the special sensors listed above. The extent that calibration is performed on the data can be specified. Special sensor data is often referred to as sensor data records (SDRs) when in the form of calibrated brightness temperatures, and envionmental data records (EDRs) when converted to geophysical parameters.
The DMDM is a text message containing the orbital elements for the sending satellite along with other "special messages." These special messages can take one of eight forms that include information on orbital elements for other DMSP or NOAA satellites, changes in the OLS thermal/light fine schedule, launch dates for new satellites, etc. The DMDM message is stored as six-bit ASCII characters in the DMSP real-time data telemetry, approximately one character per OLS scanline. The message is 184 characters and therefore repeats throughout the pass. The DMDM message is simply extracted and stored in a Terascan dataset. The information in this message can be displayed using getdmdm.
The EST is housekeeping data extracted from LS-mode frames between and including the RDS/SDS LS-mode subsync and LS-mode linesync frames. Actually, all of the appropriate LS-mode frames are stored in the output EST dataset. The getest function must be used to process these raw frames into EST data.
There are no (user-supplied) input TeraScan datasets. The sources for input telemetry data are described above. Output is either to a user supplied directory or a user-supplied list of dataset names. If a directory name is entered, output names will be automatically generated and the files will reside in the specified directory. Names will be generated that look like f#.yyddd.hhmm.type, where # is the DMSP satellite number, yyddd is the year and julian date, hhmm is the start hour and minute of the output dataset, and type is the type of data produced [ols, dmdm, est, mi_s (=ssmi), mt1_s (=ssm/t1), mt2_s (=ssm/t2); where the "_s" indicates sensor data record]. If a directory name is not entered, the output filename(s) given will be used with the type of dataset appended to the end of the file.
In processing the telemetry data, rdsin looks for a "good" time value to attribute to the start of the pass. A time is considered "good" when three consistent and consecutive times have been found. This "good" time helps ensure that rdsin begins processing after any "noise" at the beginning of the pass. More importantly, it allows the earth location of the data to be performed more accurately.
In establishing a "good" start time, rdsin first tries to use the satellite times embedded in the telemetry. If they cannot be extracted for some reason, rdsin will then try to use the computer/receiver clock times (hereafter archive times) that were stored during the real-time telemetry retrieval (applies only to RDS, not SDS telemetry). If these are also not available then rdsin uses the time in the pass header that was put in by the operator (see parameters sync_time, sync_bits, time_diag, max_gap, archive_time, debug_time, and sat_time_test below).
This specifies the type(s) of data to be extracted from the raw DMSP telemetry. Note, more than one type can be extracted during a single invocation.
Valid responses are [ols, ss, dmdm, est, all]. The default is all.
Answer yes if the input is from the pass disk, or no if the input is from tape or standard UNIX disk file.
Valid responses are [yes or no]. The default is yes.
If on_pass_disk=no, this is the name of the input tape device or UNIX disk file name. Tape device names are machine specific. For example, the following devices are commonly used on the Sun SPARC Station:
/dev/nwd0 - DAT, fixed blocking, APUNIX driver /dev/nrwd0 - DAT, variable blocking, APUNIX driver /dev/nsx0 - 8mm, fixed blocking, APUNIX driver /dev/nrsx0 - 8mm, variable blocking, APUNIX driver /dev/nrmt - 8mm or CCT, variable blocking, SUN driverAll of the above device names imply no rewind on close.
The default is extracted from the UNIX environment variable TAPE. Only tape devices listed in the file $PASSDIR/devtable, or simple UNIX disk file names, are accepted.
This specifies the number(s) of the pass(es) to process, when input is from tape or the pass disk. Passes are numbered starting with 1. Input tape is always assumed to be positioned at the first pass.
Valid responses for input from the pass disk are [1 to maximum number of passes that can be stored on your pass disk (see lspass)]. The default response is the number of the last acquired pass.
Valid responses for input from tape are [1 to 100]. The default response is 1.
If input is from tape, this is the number of tape files per pass. If files_per_pass=2, then each pass is assumed to consist of a header file, followed by a data file. If files_per_pass=1, then the tape is assumed not to have any header files. In this case, the user must supply the additional "header" info using the three parameters listed immediately below.
Valid responses are [1 or 2]. The default response is 2.
If files_per_pass=1 or the pass is from a UNIX disk file, this is the date of the pass to be processed. See formats for valid date formats.
If files_per_pass=1 or the pass is from a UNIX disk file, this is the start time of the pass to be processed. See formats for valid time formats.
If files_per_pass=1 or the pass is from a UNIX disk file, this is the DMSP satellite name of the pass to be processed.
Valid responses include [f-8, f-9, f-10, f-11, f-12, f-13].
If files_per_pass=1 or the pass is from a UNIX disk file, specifies whether the data is from stored or real-time telemetry. This affects what telemetry attribute is written to the output dataset (see NOTES).
Valid responses are [yes or no]. The default is yes.
Specifies the temperature scale of the OLS thermal calibration. The thermal calibration comes from a fixed scaling determined before launch.
Valid options are [kelvin celsius fahrenheit]. The default is celsius.
Answer yes if the OLS data is to be selected from the intersection of a master dataset (number 1 in the description above, also see master). Answer no if subsets are to be specified by start time and sample (number 2 in description above).
Valid responses are [yes or no]. The default is yes.
If use_master=yes, this is the name of the master dataset used to specify a region for OLS data extraction (see master).
Valid responses are any TeraScan dataset that contains a map projection-based earth transform. The default is Master.
If use_master=no, this is the start time for OLS data extraction. The first line with a time greater than start_time is the first OLS output line. A response of 00:00:00 instructs rdsin to begin processing at the first scan line. DMDM and special sensor data start at the first valid time (see description above).
Any valid time is allowed (see formats). The default is 00:00:00.
If use_master=no, this is the number of OLS (smooth) lines to be written to the output OLS dataset. If the end of pass is detected before the output dataset is complete, the output dataset is truncated.
The valid range is [>=1]. The default is 2000.
If use_master=no, this is the first sample to extract from the pass. Samples are numbered starting with 1.
The valid range is [1 to 1465]. The default is 1.
If use_master=no, this is the number of samples written to the output set.
The valid range is [>= 0 <= 1465]. The default is 1465.
This parameter specifies the extent to which calibration is performed on the special sensor data. When counts is specified, the raw sensor counts are output along with the calibration information needed to convert the counts into antenna temperatures. When antenna_temp is specified, antenna temperatures are output. When bright_temp is specified, calibrated brightness temperatures based on the algorithm of Wentz (See NOTES) are output. When hughes_bt is specified, calibrated brightness temperatures based on the algorithm of Hughes Aircraft, Space and Communications group, are output.
Valid responses are [counts, antenna_temp, bright_temp, or hughes_bt]. The default is bright_temp.
OPTIONAL. Determines which, if any, of the SSM/T1 and SSM/T2 "edge" samples to set to bad value (see datasets) due to the signal contamination produced by the OLS glare obstruction bracket (GLOB) that is in place on the spacecraft during terminator orbits. A value of 0 indicates all samples should be processed, a value of 1 indicates SSM/T1 sample 7 and SSM/T2 samples 25-28 should not be processed (i.e. set to bad value), and a value of -1 indicates SSM/T1 sample 1 and SSM/T2 samples 1-4 should not be processed.
Valid responses are [-1, 0, 1]. The default value is [0]. This parameter can only be set by an explicit specification on the command line.
OPTIONAL. Instructs rdsin to apply a limb correction to the SSM/T1 antenna or brightness temperatures (see calibration above). This limb correction should not be applied to data that will be used as input to the t1edr retrieval program but only to data used for qualitative study or "imaging". The corrections are a function of channel and beam position, and were extracted from the DMSP Processing Guide, written by Aerospace Corporation, El Segundo, CA.
Valid responses are [yes or no]. The default value is [no]. This parameter can only be set by an explicit specification on the command line.
OPTIONAL. Determines whether the special sensor block format indicated in the telemetry should be overriden and the "default" formatting used. The (real-time) data block format can differ from the default for tactical or other reasons, however in some cases it may just be bit errors suggesting a different format. In this latter case, the user should override the format.
Valid responses are [yes or no]. The default value is [no]. This parameter can only be set by an explicit specification on the command line.
OPTIONAL. Instructs rdsin to print out the embedded times it encounters in processing the telemetry.
Valid responses are [yes or no]. The default value is [no]. This parameter can only be set by an explicit specification on the command line.
OPTIONAL. Specifying yes instructs rdsin to try and find a good start time for the pass using the times embedded in the telemetry or the archive times stored when the pass was acquired. Specifying sync_time=no, instructs rdsin to bypass the satellite and clock times and use the operator given time (the time in the pass header). Note: if telemetry embedded times are not used, special sensor data cannot be processed.
The default value is yes. This parameter can only be set by an explicit specification on the command line.
OPTIONAL. Determines the number of bit errors allowable for obtaining sync with the special sensor data block's 64-bit sync word. If syncbits=0, then the 64-bit sync word must match the predefined pattern exactly. If syncbits=N, then N out of 64 bits may be incorrect and the sync word will still be accepted. This parameter may help in extracting blocks of special sensor data that may be lost due to noisy telemetry, i.e. bad sync words. Note: the processing time will likely increase for syncbits > 0.
Valid range is [>=0 and <= 64]. The default is 0.
OPTIONAL. Determines whether rdsin prints diagnostic messages regarding time gaps in the telemetry and the insertion of missing data.
Valid responses are [yes or no]. The default value is [yes]. This parameter can only be set by an explicit specification on the command line.
OPTIONAL. This specifies the number of seconds that is to be considered a valid time gap in the telemetry stream. If a time gap occurs that is less than this time, rdsin attemps to insert the proper amount of "missing" data. If a time gap occurs that is more than this time, rdsin assumes the apparent time gap is caused by a bit error in the time word and ignores it.
Valid responses are integers [> 0]. The default value is [90]. This parameter can only be set by an explicit specification on the command line.
OPTIONAL. Setting archive_time=yes overrides the use of the embedded satellite times and instructs rdsin to use the clock times archived into the data at the time of acquisition to find a "good" start time for the pass. If it does not find a valid archive time after sat_time_test seconds, it will then use the operator time in the pass header (see DESCRIPTION). This parameter applies only to RDS telemetry.
Valid responses are [yes or no]. The default value is [yes]. This parameter can only be set by an explicit specification on the command line.
OPTIONAL. This is the number of seconds to search for valid satellite and/or archive times at the beginning of the pass.
The default value is 90. This parameter can only be set by an explicit specification on the command line.
OPTIONAL. This specifies to the number of DMDM characters to extract from the pass. Since there is about one DMDM character per OLS line, and the DMDM message is 184 characters, and since getdmdm has to process three consecutive, consistent DMDM messages in order to provide an accurate DMDM, getdmdm requires that rdsin store a minimum of about 800 characters. Noise in the pass may require more characters to be stored in order to find three consecutive, matching messages.
Valid responses are [> 0]. The default is 2048.
OPTIONAL. This specifies whether to extract the DMDM message from the light or thermal RDS telemetry stream. The message should be identical in each, however transmission errors may produce contamination in one or both of the data streams. The default is to extract the DMDM from the thermal (TS) stream.
Valid responses are [yes or no]. The default value is [yes].
See EXAMPLES in rtdin.
$TSCANROOT/refdata/satel/f-*/orbdata $TSCANROOT/refdata/satel/f-*/ols $TSCANROOT/refdata/satel/f-*/ssmi $TSCANROOT/refdata/satel/f-*/ssmt1 $TSCANROOT/refdata/satel/f-*/ssmt2
dmsp, ssmt, ols, dmdm, ssmi, datasets, formats, etx, getdmdm, getest, sdfin, rtdin, geoph, t1edr, t2edr, miedr, subsamp, magnify, fixline, master.
An attribute called telemetry is written to OLS output datasets to distinguish datasets derived from rtd, rds, sds and sdf telemetries.
Warning: In the later stages of the F-9 spacecraft, the OLS thermal data went out of specification and the temperatures may be incorrectly calibrated. Correction tables are available that can be applied to correctly calibrate the data if necessary.
DMSP Data Specifications, IS-YD-821B, 7 March 1991. Special Sensor Microwave/Imager User's Guide, NRL Rep. Branch Rep., Sept. 14, 1987. System Summary Report Passive Microwave Sounder (SSM/T). Aerojet, Report 5542, CDRL A006, 23 November 1977. System Summary Report for the SSMT2 Water Vapor Profiling Sensor Hardware Segment. Aerojet, Report 9538, CDRL 035A2, 18 June 1990. Hollinger, J.P., 1988:DMSP special sensor microwave imager calibration/validation. Naval Res. Labs, Wash. D.C. Wentz, F., 1987, JGR, Vol.91, C2, pg. 2289. DMSP Processing Guide, Aerospace Corporation, El Segundo, CA.
Last Update: $Date: 1998/05/29 20:19:42 $