During its brief 106-days of lifetime, the Seasat-1 spacecraft, launched on June 28, 1978, by NASA’s Jet Propulsion Laboratory (JPL), collected information on sea-surface winds, sea-surface temperatures, wave heights, internal waves, atmospheric water, sea ice features, ice sheet topography, and ocean topography….
Seasat was not equipped with an onboard recorder, so in order to collect data during the mission, three U.S. and two international ground stations downlinked data from the satellite in real time: Fairbanks, Alaska; Goldstone, California; Merritt Island, Florida; Shoe Cove, Newfoundland; and Oakhanger, United Kingdom.
The data were originally archived on 39-track raw data tapes. Years later, to ensure the preservation of the data, those tapes were duplicated in 1988 and again in 1999. During the second transcription, the raw telemetry data were transferred onto 29, more modern SONY SD1-1300L 19-mm tapes. It is from these 13-year-old tapes that ASF’s online Seasat archive was obtained.
An off-the-shelf SAR processor was not available to decode or process Seasat raw telemetry data. However, ASF was able to use the Vexcel product SyncPrep to byte-align the data captured from disk, validate that the data appeared to be Seasat SAR data and estimate the bit error rate (BER) of the data. The BER provided insight into how much of the original SAR data could be processed to products and how difficult that process would be.
In the initial analysis of a 14 GB raw telemetry file, SyncPrep reported bit error rates as high as 0.4, or as many as 1 bit in 2.5 bits in error. This extreme level of “bit rot” persists for much of the Seasat archives and initially seemed to make much of the data unusable. Only through concerted efforts over the course of a year were approximately 90 percent of the Seasat SAR data able to be recovered.
The commercial product SyncPrep, used for much of the raw data ingest at ASF, does not decode Seasat telemetry. So while SyncPrep will analyze the data, it will not actually decode metadata or create the range lines needed for focusing the raw data into SAR imagery. Accordingly, a decoder for Seasat raw signal data had to be developed at ASF. First, though, an understanding of the telemetry data format was required.
According to the Interface Control Document for Seasat, the telemetry stream is organized into repeated 1,180-bit telemetry packets, referred to as minor frames. Each minor frame begins with 40 bits of metadata followed by 1,140 bits of payload. The exact subdivision of the minor frames is diagramed below:
Seasat Raw Telemetry Format: Seasat minor frames are comprised of a 24-bit sync code, a 1-bit fill flag, a 7-bit frame number, 8 bits for time and status, and 1,140 bits of payload. The sync code signifies the beginning of each minor frame. The fill flag is supposed to be 1 when no valid data is being sent, 0 if the payload is valid. The frame number allows for sequencing of minor frames and the creation of range lines from them. The time and status bits encode several metadata fields. Finally, the payload contains the actual data samples recorded by the satellite.
The payload in each minor frame is only 1,140 bits. A complete range line of Seasat data consists of the payload from 60 minor frames, each of which contains 228 samples of 5 bits each. So, in order to form range lines from the telemetry data, the payloads from up to 60 minor frames needed to be combined.
Each minor frame number 0 denotes the start of a range line. Minor frame numbers then increase until the start of the next range line, when they are reset to 0.
Aside: Determining Data Size
The pulse repetition frequency (PRF) Rate Code and the Bits Per Sample are required in order to determine the number of minor frames per range line. Seasat had four PRF rate codes: 1: 1464 Hz, 2: 1540 Hz, 3: 1581 Hz, and 4: 1647 Hz. For the entire mission, Seasat stayed with a PRF rate code of 4 and a Bits Per Sample of 5. This should result in 60 to 69 minor frames per range line according to the platform specifications. ASF engineers found that no range line had more than 60 minor frames; they always had either 59 or 60 minor frames. Thus, the output range lines were sized using:
60 minor frames * 1,140 bits/frame * 1 sample/5 bits = 13,680 samples
Thus, 13,680 should be the final size of a single range line once it is decoded into byte samples. For each such range line created, a set of 18 metadata values are also generated.
Range Line Creation: Creation of a single range line of data requires combining the payload from up to 60 minor frames in order. The 228 samples from minor frame 0 go into the output range line first, followed by the 228 samples from minor frame 1, those from minor frame 2, etc., until all minor frames for this range line have been unpacked. When only 59 frames are in a range line, the remaining 13,680 samples of output for that range line are set to zero. Concurrent with data sample unpacking, image metadata from the Time and Status bits in the first 10 minor frames are decoded and stored.
The time and status bits encode 18 metadata fields subcommutated in the first 10 minor frames of each range line, i.e. each of these fields need to be created using certain bits from certain numbered minor frames. For example, the Last Digit of Year can be found in bits 33-36 of minor frame 0, giving a range of values from 0-15. Of course, this field should always be 8, as 1978 was the year Seasat was in operation.
The metadata field Day of Year must be created using bits 33-37 of minor frame 4 as the lower-order 5 bits, and bits 37-40 of minor frame 5 as the higher order 4 bits, giving a 9-bit value. Similarly, the MSEC of Day field is 27 bits long and constructed from all or parts of the time and status bytes from minor frames 1-4. The following table shows how each of the 18 metadata fields were created.
Time and Status Byte: Locations of subcommutated metadata values. Only minor frames 0 through 9 contain valid time and status words; in all other minor frames, the time and status word is unused.
| Metadata Field | Definition | Type | Notes |
|---|---|---|---|
| Station Code | Signifies which ground station collected the data during the mission | Constant | 5: Fairbanks, AK; 6: Goldstone, CA; 7: Merrit Island, FL; 9: Oak Hangar, United Kingdom; 10: Shoe Cove, Newfoundland. |
| Last Digit of Year | Last digit of the year | Constant | Should always be 8, since the mission was in 1978 |
| Day of Year | Julian day of the year | Rarely | Since no datatakes could possibly be more than a day, this value will change at most once in a datatake. |
| MSEC of Day | Millisecond of the day | Linear | Should change consistently throughout a datatake |
| Clock Drift | Timing offset in spacecraft clock | Curve | Must be added to the other times in order to get proper spacecraft locations |
| No Scan Indicator | Unused | Bit Field | Unused |
| Bits Per Sample | Number of bits per data sample | Constant | Throughout the mission, this value was always 5 |
| MFR Lock Bit | Unused | Bit Field | Unused |
| PFR Rate Code | Pulse Repetition Frequency Code | Constant | Throughout the mission this value was always 4, denoting a PRF of 1647 Hz |
| Delay to Digitization | Delay between sending pulses and when pulses are listened for | Rarely | Used to calculate the slant range to the first pixel in a datatake |
| SCU Bit | Unused | Bit Field | Unused |
| SDF Bit | Unused | Bit Field | Unused |
| ADC Bit | Unused | Bit Field | Unused |
| Time Gate Bit | Unused | Bit Field | Unused |
| Local PRF Bit | Unused | Bit Field | Unused |
| Auto PRF Bit | Unused | Bit Field | Unused |
| PRF Lock Bit | Unused | Bit Field | Unused |
| Local Delay Bit | Unused | Bit Field | Unused |
Metadata Fields in the Raw Data: Eighteen fields of metadata can be decoded for each range line created during decoding. There are 10 bit fields, four fields that should be constant for a datatake, two fields that should change rarely, and two fields that should change steadily.
Written by Tom Logan, July 2013
A glossary of terms used in the Seasat project…
Cite data in publications such as journal papers, articles, presentations, posters, and websites. Please send copies of, or links to, published works citing data, imagery, or tools accessed through ASF to [email protected] with “New Publication” on subject line.
| Format | Example |
|---|---|
| Seasat data 1978 (NASA). Processed by ASF DAAC 2013. Retrieved from ASF DAAC [add URL if print publication: asf.alaska.edu] [day month year of data access]. | Seasat data 1978 (NASA). Processed by ASF DAAC 2013. Retrieved from ASF DAAC 7 December 2015. |
Include appropriate credit with each image shown in publications such as journal papers, articles, presentations, posters, and websites. For more information, see NASA guidelines.
| Example |
|---|
| Credit: NASA 1978, processed by ASF DAAC 2013. |
Seasat was the first NASA satellite with synthetic aperture radar deployed….
Before and After Images showing the difference between the Seasat images being optically processed shortly after the mission and digitally processed in 2013…
The Alaska Satellite Facility was tasked by NASA with creating a digital archive of focused synthetic aperture radar (SAR) products from data collected by NASA’s Seasat mission.
The basic steps involved in this process are as follows:
Seasat Processing Project Data Flow: Starting with raw signal data on tapes, the Seasat data was successively (1) captured to disk, (2) validated and byte-aligned, (3) decoded, (4) cleaned of bit errors and discontinuities, (5) focused into SLC imagery, (6) processed into georeferenced ground range products, and (7) packaged as HDF5 with XML metadata. Step 2 was performed using the Vexcel product SyncPrep. Step 5 was accomplished using the repeat pass interferometry (ROI) package from JPL. All other steps utilized software developed in-house at ASF.
These pages tell the story of the data cleaning and product processing in detail.
1. Raw Telemetry
2. Decoder Development
3. Decoded Data Analysis
4. Data Cleaning (Part 1) (Part 2)
5. Classification of Bad Data
6. Slope Issues
7. Cleaned Swath Files
8. Focusing Challenges
9. From Swaths to Products
10. Quality Issues
11. Data Product Formats
Written by Tom Logan, July 2013
This section provides a detailed description of the HDF5 data format used for the final generation of Seasat synthetic aperture radar (SAR) products….
Sea-ice imagery and data products are supported under NASA’s Making Earth System data records for Use in Research Environments (MEaSUREs) program….
Each flight line was segmented into approximately 25 km long sections with 20% overlap on each end. Each segment contains the following data in a zip file:
1. Thickness data 32 bit float binary, 10 m pixel resolution ‘seg#_thickness’
2. Thickness data GeoTIFF ‘seg#_thickness_geo.tif’
3. Thickness data graphic ‘seg#_thickness.gif’
4. Image data 32 bit float binary, 10 m pixel resolution ‘seg#_image’
5. Image data GeoTIFF ‘seg#_image_geo.tif’
6. Image data graphic ‘seg#_image.gif’
7. Header file with columns, rows, projection information, and corner map coordinates ‘seg#.hdr’
8. ASCII file with latitude, longitude, and aircraft altitude of corresponding segment ‘seg#_0_0.pos’ where the last two numbers represent waveform and channel. There are 4 waveforms and as many as 8 channels.
‘seg#’ refers to the segment number ie: 0_3, 3_7, 7_11 etc.
GISMO – May 23, 2006, Outbound Flight Line
products for segment 0_3 | 0_3_thickness.gif
products for segment 3_7 | 3_7_thickness.gif
products for segment 7_11 | 7_11_thickness.gif
products for segment 11_15 | 11_15_thickness.gif
products for segment 15_19 | 15_19_thickness.gif
products for segment 19_23 | 19_23_thickness.gif
products for segment 23_27 | 23_27_thickness.gif
products for segment 27_31 | 27_31_thickness.gif
products for segment 31_34 | 31_34_thickness.gif
products for segment 34_38 | 34_38_thickness.gif
products for segment 38_42 | 38_42_thickness.gif
GISMO – May 23, 2006, Inbound Flight Line
products for segment 42_46 | 42_46_thickness.gif
products for segment 46_50 | 46_50_thickness.gif
products for segment 50_54 | 50_54_thickness.gif
products for segment 54_58 | 54_58_thickness.gif
products for segment 58_62 | 58_62_thickness.gif
products for segment 62_66 | 62_66_thickness.gif
products for segment 66_70 | 66_70_thickness.gif
products for segment 70_74 | 70_74_thickness.gif
products for segment 74_78 | 74_78_thickness.gif
products for segment 78_82 | 78_82_thickness.gif
products for segment 82_86 | 82_86_thickness.gif
products for segment 86_89 | 86_89_thickness.gif
Each flight line was segmented into approximately 25 km long sections with 20% overlap on each end. Since there were only 4 channels for these data, good left-right separation was not possible, thus there is no image or thickness data available for 2007. The following is what is included in the product zip files:
1. ASCII file with latitude, longitude, and aircraft altitude of corresponding segment ‘seg#_0_0.pos’ where the last two numbers represent waveform and channel. There are 4 waveforms and as many as 8 channels.
2. 450 MHz (Sept 10) intensity data 32 bit float binary, 5X25 m (pixel x line) resolution which includes both the surface and base part. Slant range imagery can be used to get the nadir thickness information. ‘seg#_inten’
3. Azimuth compressed header file with column, row, resolution, wavelength, and # looks ‘seg#_0_0.azcom.par’
4. Azimuth compressed nadir file with latitude, longitude of first pixel of each azimuth line in the slant range image, aircraft altitude, and roll angle in degrees (last column) ‘seg#_0_0.azcom.nadir’
5. 450 MHz (Sept 10) Surface/Base profile gives an estimate (may not be exact in some areas) of the surface and the base profile. ‘seg#_surface_base.profile’ *note not all segments have this file*
Ice_elevation = (base_pixel – surface_pixel)*5.0/1.8 (m)
‘seg#’ refers to the segment number ie: 0_3, 3_7, 7_11, 100_110 etc.
GISMO – Schematic Labeling the Inbound and Outbound Flight Lines
Sept 10, 2007, 450 MHz Outbound Flight Line A
Sept 10, 2007, 450 MHz Outbound Flight Line B
products for segment 194_200
products for segment 200_210
products for segment 210_220
products for segment 220_230
products for segment 230_240
products for segment 240_250
products for segment 250_260
products for segment 260_269
products for segment 271_280
products for segment 280_288
products for segment 290_296
Sept 10, 2007, 450 MHz Inbound Flight Line A
Sept 10, 2007, 450 MHz Inbound Flight Line B
Each flight line was segmented into approximately 25 km long sections with 20% overlap on each end. Since there were only 4 channels for these data, good left-right separation was not possible, thus there is no image or thickness data available. The following is what is included in the product zip files:
1. ASCII file with latitude, longitude, and aircraft altitude of corresponding segment ‘seg#_0_0.pos’
2. 150 MHz (Sept 12) Intensity data 32 bit float binary, 5X25 m (pixel x line) resolution which includes both the surface and base part. Slant range imagery can be used to get the nadir thickness information. ‘seg#_inten’
3. Azimuth compressed header file with column, row, resolution, wavelength, and # looks ‘seg#_0_0.azcom.par’
4. Azimuth compressed nadir file with latitude, longitude of first pixel of each azimuth line in the slant range image, aircraft altitude, and roll angle in degrees (last column) ‘seg#_0_0.azcom.nadir’
5. 150 MHz (Sept 10) Surface/Base profile gives an estimate (may not be exact in some areas) of the surface and the base profile. ‘seg#_surface_base.profile’
Ice_elevation = (base_pixel – surface_pixel)*5.0/1.8 (m)
6. Image, thickness, and header data for two segments 450_460 and 480_490 ‘seg#_image, seg#_thickness, and seg#.hdr’
7. Image and thickness GeoTIFF’s for segments 450_460 and 480_490 ‘seg#_image_geo.tif’ and ‘seg#_thickness_geo.tif’
8. Thickness data graphic for segments 450_460 and 480_490 ‘seg#.thickness.tiff’
‘seg#’ refers to the segment number ie: 0_3, 3_7, 7_11, 100_110 etc.
Sept 12, 2007, 150 MHz Outbound Flight Line
Sept 12, 2007, 150 MHz Inbound Flight Line
products for segment 255_262
products for segment 270_280
products for segment 280_290
products for segment 290_300
products for segment 300_310
products for segment 310_320
products for segment 320_330
products for segment 330_340
products for segment 340_350
products for segment 350_360
products for segment 360_370
products for segment 370_380
products for segment 380_390
products for segment 390_400
products for segment 400_410
products for segment 410_420
products for segment 420_430
products for segment 430_440
products for segment 440_450
products for segment 450_460 | 450_460.thickness.tiff
products for segment 460_470
products for segment 470_480
products for segment 480_490 | 480_490.thickness.tiff
products for segment 490_500
Each flight line was segmented into approximately 25 km long sections with 20% overlap on each end. Each segment contains the following data in a zip file:
1. Thickness data 32 bit float binary, 20 m pixel resolution ‘seg#_thickness’
2. Thickness data GeoTIFF, 20 m, ‘seg#_thickness_geo.tif’
3. Thickness data graphic ‘seg#.thickness.tiff’
4. Image data 32 bit float binary, 20 m pixel resolution ‘seg#_image’
5. Image data GeoTIFF, 20 m, ‘seg#_image_geo.tif’
6. Header file with columns, rows, projection information, and corner map coordinates ‘seg#.hdr’
7. ASCII file with latitude, longitude, and aircraft altitude of corresponding segment ‘seg#_0_0.pos’ where the last two numbers represent waveform and channel. There are 4 waveforms and as many as 8 channels.
8. Intensity graphic ‘seg#_inten.tif’ where the along track is in the vertical direction and the cross track (slant range) is in the horizontal direction from left to right. The brightest part on the left is the ice surface. There are discontinuities between the surface and the base resulting from different azimuth looks. Only two looks are used to create the surface portion (left) and 20 looks are used to create the base portion (right). The white line (right) represents the base and is an estimate of the nadir profile.
‘seg#’ refers to the segment number ie: 0_3, 3_7, 7_11 etc.
Example of intensity
tif 310_320_inten.tif
Low aircraft elevation data and high elevation data overlap.
thick red line = high elevation
thin black dotted line = low aircraft elevation
2008 Outbound Flight Line
products for segment 0_7 | 0_7.thickness.tiff
products for segment 9_20 | 9_20.thickness.tiff
products for segment 20_30 note: 20_30 data segment corrupt. Intenstity graphic and ASCII file only
products for segment 30_37 | 30_37.thickness.tiff
products for segment 39_50 | 39_50.thickness.tiff
products for segment 50_60 | 50_60.thickness.tiff
products for segment 60_70 | 60_70.thickness.tiff
products for segment 70_80 | 70_80.thickness.tiff
products for segment 80_90 | 80_90.thickness.tiff
products for segment 90_100 | 90_100.thickness.tiff
2008 Inbound Flight Line
products for segment 100_110 | 100_110.thickness.tiff
products for segment 110_120 | 110_120.thickness.tiff
products for segment 120_130 | 120_130.thickness.tiff
products for segment 130_140 | 130_140.thickness.tiff
products for segment 140_150 | 140_150.thickness.tiff
products for segment 150_160 | 150_160.thickness.tiff
products for segment 162_170 | 162_170.thickness.tiff
products for segment 280_290 | 280_290.thickness.tiff
products for segment 290_300 | 290_300.thickness.tiff
products for segment 300_310 | 300_310.thickness.tiff
products for segment 310_320 | 310_320.thickness.tiff
2008 Southbound Flight Line
products for segment 190_200 | 190_200.thickness.tiff
products for segment 200_210 | 200_210.thickness.tiff
products for segment 210_220 | 210_220.thickness.tiff
products for segment 220_230 | 220_230.thickness.tiff
products for segment 230_240 | 230_240.thickness.tiff
products for segment 240_250 | 240_250.thickness.tiff
2008 Northbound Flight Line
products for segment 250_260 | 250_260.thickness.tiff
products for segment 260_270 | 260_270.thickness.tiff
products for segment 270_280 | 270_280.thickness.tiff
products for segment 162_170 | 162_170.thickness.tiff
products for segment 170_180 | 170_180.thickness.tiff
products for segment 180_190 | 180_190.thickness.tiff
Each flight line was segmented into approximately 25km long sections with 20% overlap on each end. Each segment contains the following data in a zip file:
1. Elevation data 32 bit float binary, 20m pixel resolution ‘seg#_elevation’
2. Elevation data GEOtiff, 20m, ‘seg#_elevation_geo.tif’
3. Elevation data graphic ‘seg#.elevation.tiff’
4. Image data 32 bit float binary, 20m pixel resolution ‘seg#_image’
5. Image data GEOtiff, 20m, ‘seg#_image_geo.tif’
6. Header file with columns, rows, projection information, and corner map coordinates ‘seg#.hdr’
7. Base Intensity data 32 bit float binary, 5X25m (pixel x line) resolution which include both the surface and base part. This slant range image can be used to get the nadir elevation information and as a reference to the elevation maps. ‘seg#_base_inten’
8. Azimuth compressed header file with column, row, resolution, wavelength, and # looks ‘seg#_0_0.azcom.par’
9. Azimuth compressed nadir file with latitude, longitude of first pixel of each azimuth line in the slant range image and roll angle in degrees (last column) ‘seg#_0_0.azcom.nadir’
10. Surface/Base profile gives an estimate (may not be exact in some areas) of the surface and the base profile. ‘seg#_surface_base.profile’ *note: not all segments have this file*
Ice_thickness = (base_pixel – surface_pixel)*5.0/1.8(m)
‘seg#’ refers to the segment number ie: 0_3, 3_7, 7_11, 100_110 etc.
Low aircraft elevation data and high elevation data overlap.
thick red line = high elevation
thin black dotted line = low aircraft elevation
2008 Outbound Flight Line
products for segment 20_30 | 20_30.elevation.tiff
no surface_base.profile file
products for segment 32_40 | 32_40.elevation.tiff
products for segment 40_45 | 40_45.elevation.tiff
products for segment 47_53 | 47_53.elevation.tiff
products for segment 55_60 | 55_60.elevation.tiff
no surface_base.profile file
products for segment 60_69 | 60_69.elevation.tiff
products for segment 71_80 | 71_80.elevation.tiff
products for segment 80_90 | 80_90.elevation.tiff
2008 Inbound Flight Line
products for segment 90_100 | 90_100.elevation.tiff
products for segment 100_108 | 100_108.elevation.tiff
products for segment 108_113 | 108_113.elevation.tiff
products for segment 115_120 | 115_120.elevation.tiff
products for segment 130_139 | 130_139.elevation.tiff
products for segment 141_145 | 141_145.elevation.tiff
no surface_base.profile file
products for segment 147_155 | 147_155.elevation.tiff
products for segment 155_162 | 155_162.elevation.tiff
no surface_base.profile file
products for segment 166_173 | 166_173.elevation.tiff
products for segment 173_180 | 173_180.elevation.tiff
products for segment 180_190 | 180_190.elevation.tiff
2008 Southbound Flight Line
products for segment 213_220 | 213_220.elevation.tiff
no surface_base.profile file
products for segment 220_230 | 220_230.elevation.tiff
products for segment 230_239 | 230_239.elevation.tiff
products for segment 241_250 | 241_250.elevation.tiff
products for segment 250_257 | 250_257.elevation.tiff
products for segment 261_271 | 261_271.elevation.tiff
2008 Northbound Flight Line
products for segment 190_198 | 190_198.elevation.tiff
products for segment 198_205 | 198_205.elevation.tiff
products for segment 207_213 | 207_213.elevation.tiff
products for segment 271_281 | 271_281.elevation.tiff
products for segment 283_290 | 283_290.elevation.tiff
2008 Coastal Flight Line
products for segment 290_300 | 290_300.elevation.tiff
products for segment 300_310 | 300_310.elevation.tiff
no surface_base.profile file
products for segment 310_316 | 310_316.elevation.tiff
no surface_base.profile file
The University of Alaska Fairbanks is an AA/EO employer and educational institution and prohibits illegal discrimination against any individual: Learn more about UA’s notice of nondiscrimination. UA is committed to providing accessible websites. Learn more about UA’s notice of web accessibility
