HRDRAD

NAME
SYNOPSIS
DESCRIPTION
BUGS
SEE ALSO
CONTRIBUTORS

NAME

hrdrad -- convert HRD format radar data to Candis format

SYNOPSIS

hrdrad -[l|t] [-nfba] -r maxgate -x airfile -c corrections -s times -h headlims

DESCRIPTION

Hrdrad converts NOAA/HRD (Hurricane Research Division) aircraft radar data from HRD native format to Candis format. HRD data are expected on the standard input and the Candis data appear, one variable slice per ray, on the standard output. The HRD data must have been read using the "rtape" utility with record headers enabled, which preserves the record structure of the file when read to disk.

The options are as follows:

-t or -l: one and only one of these two options must be selected, the first to write only data from the tail radar, the second to write data from the lower fuselage radar.
-n: Normally velocity data from the tail radar have the aircraft velocity removed and are then unfolded. This option suppresses both of these corrections. The option has no effect when the lower fuselage radar is selected.
-f, -b: Specification of one or both of these options selects either forward looking data or rearward looking data from the tail radar, or both if both are employed. At least one should be selected, or no data will appear. These options have no effect when the lower fuselage radar is selected.
-r maxgate: This option forces only the first "maxgate" radar gates to be retained in the output. All gates are retained if this option is not selected.
-a: This option causes gates to be selected for the tail radar on a uniform 300 m interval. Normally, the first 256 gates have 75 m spacing, the next 128 have 150 m spacing, and the final 128 gates have 300 m spacing.
-x airfile: If invoked, housekeeping data from the file "airfile" is substituted for that appearing on the radar tape. "Airfile" must have been created by "hrdair" from HRD in situ data, and must be converted to a single variable slice using "cdfcat".
-c corrections: If invoked, additive corrections are made to various angles and distances in the radar data. The "corrections" argument takes the following format: d_rot:d_tilt:d_heading:d_pitch:d_firstgate. The additive corrections are to the rotation (or raw azimuth), tilt (or raw elevation), aircraft heading, and aircraft pitch angles, and to the distance to the first radar gate in kilometers.
-s times: If invoked, only times (in kiloseconds after midnight) within the specified range will be written. The "times" argument has the form time1:time2, where the two subarguments specify the time range.
-h headlims: If invoked, only rays with aircraft headings within the specified range will be written. The "headlims" argument has the form requested_heading:tolerance:roll_tolerance, where headings in [requested_heading - tolerance, requested_heading + tolerance], and with the aircraft roll less than roll_tolerance in magnitude are accepted.

For both the lower fuselage and tail radars, the reflectivity is stored in the field "dbz" with units of decibels. The velocity data from the tail radar is stored in "vr" with units of meters per second. Both these fields are one-dimensional functions of range, which is specified in kilometers. The spectral width data from the tail radar are discarded. Housekeeping data for each ray are stored in scalar fields as follows:

raycnt: Ray count for this file, starting at 0 and incrementing by 0.001 for each ray. (Unity is not used as the increment because it would be reasonably possible to then put "raycnt" into the bad data range.) If subsequently converting to a single variable slice with "cdfcat", raycnt can be used as the new index field.
az: Radar beam azimuth clockwise from north in degrees.
el: Radar beam elevation positive upward from horizontal in degrees.

BUGS

This program assumes that all header records after the first are redundant and doesn't bother to decode them. (However, it does complain about their existence.) This situation generally only arises when the -f flag is used with rtape, so that multiple files on P-3 radar tapes are merged into a single file.

It is not clear that the -a option selects gates exactly correctly to get uniform 300 m spacing. Small problems may occur at the breaks in the gate spacing of the original data. These possible errors can probably be neglected for most purposes.

When midnight is crossed, the time variable resets to zero. However the monotime variable continues to be incremented.

CONTRIBUTORS