Format of the AMSU Swath Files

The AMSU Swath files are in McIDAS format. Each file consists of three blocks, the Area Block, the Navigation Block, and the Data Block. If you don't have McIDAS, you can still use the data--just follow the shortcut below.

Area Block

The Area Block consists of 256 bytes of intermixed 4-byte integers (words) and ASCII characters. Depending on what kind of machine you have, you may have to swap the byte order of the integers. (But don't swap the order of the characters!) It's easy to tell if you need to swap the order by looking at the second word, which is always 4. Here's the format of the Area Block:

Word Contents In the AMSU files,
expect this
1 contains zeros if the record is valid 0
2 area format: always 4 4
3 sensor source number NOAA satellite number + 50 (65 indicates NOAA 15)
4 start date; YYYDDD Year = 1900 + YYY
5 start time; HHMMSS UTC  
6 starting line number 1
7 starting element number 1
8 not used 0
9 number of lines in the area  
10 number of elements in each line 32 or 92
11 number of bytes per element (1, 2 or 4) 2
12 line resolution; number of image lines between consecutive area lines 1
13 element resolution; number of image elements between consecutive area elements 1
14 maximum number of bands per line of the area 1
15 length of the DATA block line prefix, in bytes 0
16 McIDAS user project number under which the area was created 0
17 ingest date; date the area was created; provided by the ingesting computer; YYDDD  
18 ingest time; time the area was created; provided by the ingesting computer; HHMMSS  
19 32-bit filter band map for multichannel images; if a bit is set, data exists for the band; band 1 is the least significant byte (rightmost) 2**(channel -1)
(some products don't have channel numbers)
20-24 satellite specific information 0
25-32 memo; 32 ASCII characters available for comments a brief description of what parameter is in the data field
33 area file number; last four digits of the file name 1
34 byte offset to the start of the area file's DATA block 768
35 byte offset to the start of the area file's NAV block 256
36 validity code 0 (not used)
37-45 satellite specific 0
46 actual image start date; date the ingestor begins receiving image data; YYYDDD  
47 actual image start time; time the ingestor begins receiving image data; HHMMSS  
48 actual starting scan line; the first scan line received by the ingestor 1
49 length of the DATA block line prefix documentation region, in bytes 0
50 length of the DATA block line prefix calibration region, in bytes 0
51 length of the DATA block line prefix level map region, in bytes 0
52 image source type; for example, VISR, VAS, AAA, ERBE, AVHR TIRO
53 calibration type; units in which the digital data is stored; for example, RAW, TEMP, BRIT BRIT
54-59 internal use only; initialized to 0 0
60 byte offset to the beginning of the area file's AUX block 0
61 length of the area file's AUX block, in bytes 0
62 not used 0
63 byte offset to the beginning of the area file's CAL block 0
64 number of comment records in the area file's AUDIT block 0

Navigation Block

The Navigation Block also consists of 512 bytes of intermixed 4-byte integers (words) and ASCII characters. In the Navigation Block are the orbit and attitude parameters necessary to calculate where each scan spot is. The parameters are as follows:

Word Parameter In the AMSU files....
1 navigation type; 4 ASCII characters TIRO
2 sensor source, year, day of year (SSSYYDDD) sensor source is given in Area Block Word 3
3 start time; HHMMSS UTC Should be same as Word 5 in the Area Block, but in the past has been mistakenly set to zero. See Word 48, which is what McIDAS uses.
4 orbit type; always 1 1
5 epoch date; YYMMDD  
6 epoch time; HHMMSS UTC Note: Word 15 has the fraction of a second in epoch time
7 semimajor axis; km*100  
8 orbital eccentricity; *1000000  
9 orbital inclination; degrees*1000  
10 mean anomaly; degrees*1000  
11 argument of perigee; degrees*1000  
12 right ascension of ascending node; degrees*1000  
13 no. of elements per line same as Area Block Word 10
14 angular increment between elements; degrees*1000000 -3333333 or -1111111
Negative indicates left-to-right scanning looking downtrack.
15 fraction of a second in epoch time; *1000  
16-45 (reserved) 0
46 direction of satellite pass (+1=ascending, -1=descending) set to 1, but these are whole-orbit files, so both ascending and descending portions are included
47 number of earliest line to navigate 1
48 time at start of earliest line, milliseconds from 000000 UTC  
49 time interval between lines, milliseconds (see Word 53)  
50 flag for inverted data (0=normal, 1=flipped) 0
51 number of lines in the area (for flipped)  
52 number of elements in the area (for flipped)  
53 same as Word 49, but in microseconds (preferred over 49)  
54 time interval between consecutive elements; microseconds*100  
55-120 (reserved)  
121-128 memo; 32 ASCII characters available for comments blank

Data Block

The last thing in the file is the data. (The AMSU data files do not have an AUX block, a CAL block, or an AUDIT block.) Each datum (scan spot, pixel, element) is represented by two bytes. The calibration is explained below.

The data are arranged in terms of scan lines. Note that there is a bit of trickery here. Due to a quirk in McIDAS, the number of elements in a scan line must be a multiple of 4. However, AMSU-A has 30 elements per scan line, and AMSU-B has 90 elements. To make the AMSU data work in McIDAS, it was necessary to tell McIDAS that AMSU-A has 32 elements per scan line and that AMSU-B has 92 elements. The first and last elements in each scan line, therefore, are always set to the "not observed" value (see calibration, below).

The total number of bytes in the Data Block is twice the product of Area Block Words 9 and 10.


The pixel values in two-byte AMSU swath files are stored in little-endian, two-byte integers. Positive integers indicate "good" values. Negative pixel values indicate problems:

-1Not observed
-2Not retrieved ("flagged")
...Other problems

To retrieve the parameter value, simply divide the two-byte pixel value by 100. The units of the parameters are as follows:

File ExtensionParameterUnitRange
C01...C20antenna temps in channels 1-20K70 - 325
RRAMSU-A rain ratemm/hr0 - 30
RRBAMSU-B rain ratemm/hr0 - 30
TPWtotal precipitable watermm0 - 75
CLWcloud liquid watermm0 - 6
ICEsea iceAreal coverage in percent30 - 100
IC2sea ice (with edges)Areal coverage in percent30 - 100
SNOAMSU-A snow coverAreal coverage in percent0 or 100
SNBAMSU-B snow coverAreal coverage in percent0 or 100
LATlatitudedegrees-90 - 90
LONlongitudedegrees, east is positive-180 - 180
THK1000-500 hPa thicknessm 
L07limb-adjusted channel 7K 
SFCsurface type (AMSU-A)coded0=ocean, 1=land, 2=coast
SFBsurface type (AMSU-B)coded0=ocean, 1=land, 2=coast
IWPice water pathmm0 - 2
E2323 GHz emissivityunitless0 - 1
E3131 GHz emissivityunitless0 - 1
E5050 GHz emissivityunitless0 - 1
TSFsurface temperatureK 


It is fairly simple to read the AMSU files without using McIDAS. The first 768 bytes of each file contain McIDAS header information, as described above. If you don't have McIDAS, you can read and ignore this information. The remainder of each file contains the data.

To use the data, follow these steps:

  1. Find the file which contains the parameter you want. Also locate the .LAT and .LON files with the same file name.
  2. Read and ignore the first 768 bytes of each file.
  3. Read a two-byte integer from each file. The data are little-endian, signed, two-byte integers.
  4. If the parameter is less than zero, the value should be ignored.
  5. If the parameter is greater or equal to zero, divide it by 100. Also divide the latitude and longitude by 100 (e.g., 123 becomes 1.23). The parameter and the latitude and longitude are now in the units listed in the above table. Process this pixel however you wish.
  6. The file name contains the start and end time of the swath. You can tell the time of each pixel by interpolating between the start and end times.
  7. Go back to step 3 and continue until the end of file is reached.


If you have questions about any of this, contact me, Stan Kidder, at