1D-SAR Migrated RADAR (Level 1)

Level 1 data includes 1D-SAR migrated RADAR.  These data are preliminary and subject to revision as further processing is performed.  These data have been decimated vertically but not horizontally.

The data are hosted on the following folders:

These folders are divided into a number of subfolders according to survey lines.  The survey lines have the following naming convention:

L###  –  “Long lines”.  These are north-south lines spaced at 5km

T#####  –  “Tie lines”.  These are east-west lines spaced at 33km

F#####  –  “Fuji lines”.  These are the continuation of selected tie lines to the west (Dome Fuji) side of the main grid.

V#####  –  “Vostok lines”.  These are the continuation of selected tie lines to the east (Lake Vostok) side of the main grid

Each subfolder contains a number of radar files in matlab format.  The naming convention is best illustrated by an example:

F13b_L290-209_1D_SAR.mat

In this case, “13b” is the flight number (typically, two survey lines were flown in each flight), “L290” is the line number, and “209” is the file number (each file represents ~3.5km of along-track distance).  The file number is always the 3 digits following the dash.

These files contain the following variables:

ApertureSize This is the size of the synthetic aperture (in meters) used to migrate each row of the radar data matrix.
BedBright Raw received power from the bed return (dB), defined as the brightest pixel within ±50m of “BedPixel”. Note that although the picking was done on horizontally decimated data, “BedBright” was determined from the present data, which have full horizontal resolution.
BedPixel Sample index representing the bed return. Data were picked on horizontally decimated (10x) data and then interpolated back onto the present data, which have full horizontal resolution.
CG “Combined Gain”. This is the (complex) radar data matrix. This variable was formed by merging the “Low Gain” (3μs pulse) with the “High Gain” (10μs pulse). Both have been migrated with a 1D-SAR algorithm and decimated vertically. The variables “stitchind” and “ampfactor” describe how the two pulses were merged together and the variable “cutterV” describes the decimation factor.
FlightElev Aircraft elevation, relative to WGS84.
Icethick Ice thickness of the bed return, in meters. Data were picked on horizontally decimated (10x) data and then interpolated back onto the present data, which has full horizontal resolution. Value differs from VertScale(BedPixel) because “Icethick” was defined using a variable surface given by “SurfElev”, while “VertScale” uses the mean surface within each file.
Lat Latitude, in decimal degrees.
Lon Longitude, in decimal degrees.
SurfElev Elevation of the ice surface. Value is derived from interpolation of the Bamber DEM.
TWT Two-Way Time, in seconds.
VertScale A vertical scale (in m) for the radar matrix, computed using “c_air”, “c_ice”, “surfind”, and no firn correction.
X Easting in km, in a Lambert Conic Conformal projection (parallels: 77S, 83S, origin: 80S, 80E, false easting: 2000km, false northing: 2000km).
Y Northing in km, in a Lambert Conic Conformal projection (parallels: 77S, 83S, origin: 80S, 80E, false easting: 2000km, false northing: 2000km).
ampfactor A constant multiplier applied to the low gain data to attempt to equalize amplitudes across the stitch line. This procedure can be problematic when bright reflectors cross the stitch line.
breakind Index of the sample representing the direct arrival. “TWT” is measured relative to this sample. No correction was made for delay-time of direct arrival. Value used was 44.
c_air Velocity of radio waves in air, in m/s. Value used was 3×108.
c_ice Velocity of radio waves in ice, in m/s. Value used was 1.68×108.
cutterV Vertical decimation factor. Value used was 10.
dx Mean along-track spacing (m) of data in this file. Value was typically 1.3-1.4 m.
dy_air Vertical pixel size in air (m), computed using “c_air”, “samp_int”, and “cutterV”.
dy_ice Vertical pixel size in ice (m), computed using “c_ice”, “samp_int”, and “cutterV”.
f Center frequency of the radar system. Value was 150 MHz.
h Mean aircraft height above the ice surface in this file, in meters. Value was typically about 300m.
n Index of refraction of ice used to perform the migration. Value used was 1.7889. Note that this value disagrees with the value of “c_ice” (used to compute the vertical scale and ice thickness) by 0.18%. This discrepancy will be fixed in the final data release.
samp_int Sample interval of the radar system (s). Value used was 8.333×10-9.
stitchind Index representing the last sample of Low Gain data. Value used was 225.
surfind Index representing the mean location of the surface return, as determined from “SurfElev”, “FlightElev”, and “c_air”.

Most of the data were processed with an older version of the gps processing scripts which linearized the timestamps and occasionally failed to properly fix 24hr offsets.  The final version of the data will use a newer version of the gps processing scripts in which these problems have been fixed.  A minority of the present release was processed with the newer scripts; these are listed in the accompanying spreadsheet.  Horizontal offsets in position data between the new and old scripts are typically on the order of 8m.Known Issues:

  1. The surface used for the migration reference function is not the same as the surface given here.  The surface used for migration was determined directly from the radar returns and varies by 5±5m from the surface listed here, except for the southern half of flight 21 (L700 and L750, Y<~1750km), in which low-lying clouds caused the automatic surface picker to be several hundred meters off.  The final version of the data will use the more accurate surface given here, which is why that surface was used to create “Icethick” from “BedPixel” (because “BedPixel” has no direct dependence on the value of the ice surface, this means that the value of “Icethick” for flight 21 should be accurate).  In addition, as mentioned above, the value of “n” used to define the migration reference function differs from the value of “c_ice” used to define ice thickness by 0.18%.

Unknown Issues:

If you discover any other problems in this dataset, do not hesitate to contact us.