NASA Responds

UPDATE:
Re-reading their response, I noticed they didn't actually admit in the body of the e-mail to making up all of channel 4's readings. But that's what they do. You can read about it at one of the links they provided here: AIRS/AMSU/HSB Version 5 Modification of Algorithm to Account for Increased NeDT in AMSU Channel 4
===

I just got a response from NASA about the various questions I raised in this post regarding the AMSU on the Aqua satellite.

Basically, their response is that channel 4 failed sometime in late 2007 and now they invent the readings from channel 4 from whole cloth and feed those invented readings into the calculations.

Despite my post on noise, this invention of an entire channel's readings isn't as far-featched as it first sounds. The recurring patterns that exist in all the footprints for all the channels make this far easier to do than if we were dealing with something like land-based thermometer readings. For example, given a single footprint reading on any channel, you can make a reasonable guess as to what all the other footprint readings will be for that channel. The between-channel values also have a very consistent relationship to each other. An example of that consistent relationship is shown in the graphic at the beginning of this post.

They also said that having no automaticQualityFlags for a month marked as "passed" is not a big deal, and that the values for badData, etc., are not the same in every file. On that last one, I'm not so sure. I dug into the files with a text editor and looked at the badData values myself, rather than just trusting my code. They were all the same. But, for now, I'll take their word on it and assume there's something there that I'm not yet understanding.

Anyway, here's their response:

Thank you for your interest in Aqua AMSU-A data. Before your specific questions are answered, understanding the following background information about Aqua AMSU-A will be helpful. All documents referenced here can be found at our public archive at the Goddard Earth Sciences Data and Information Services Center (GES DISC) at http://disc.sci.gsfc.nasa.gov/AIRS/documentation.

Aqua AMSU-A is a microwave sounder that is very similar to AMSU-A instruments flown on many NOAA satellites as well as on the European MetOp-A satellite. Aqua AMSU-A senses the atmosphere in 15 distinct data channels. One of these channels, Channel 4, failed in late 2007, as described in AMSU-A Channel 4 NeDT Update: 20 December 2007 at the document archive.

Aqua AMSU-A products include a variety of flags to indicate data quality. However, not all data quality flags are particularly useful for indicating actual data quality. In particular, ‘AutomaticQualityFlag’ is not an effective flag to check because any datasets less than 100% complete will be marked “suspect.” You may wish to review the AIRS Version 5 Released Files Description document to find more suitable QA flags. We suggest you look at “NeDT,” “state1” and “state2” as being better data quality indicators.

Since the degradation of AMSU-04, the AIRS Level 2 retrieval code does not utilize AMSU channel 4 brightness temperatures. You may want to review AIRS/AMSU/HSB Version 5 Modification of Algorithm to Account for Increased NeDT in AMSU Channel 4 to understand how we are addressing the loss of Channel 4 within our retrieval software.

With that background, let us address your 3 specific questions:

Is it considered normal to have zero Level 1B AMSU data files for a month pass QA?

It is a mistake to characterize a granule in which AutomaticQualityFlag is set to "Suspect" as not passing QA. In fact, this is a “normal” condition since late 2007, and it merely reminds us that the dataset is not 100% complete.

Is it normal for all Level 1B AMSU data files for a month to have the exact same numbers for bad data, missing data, special data, and total data?

All Level-1B data files for the month of January 2010 do not have identical values for NumBadData, etc. For example, data collected over a spacecraft maneuver will reflect the state of the instrument at that time. This situation is typical, and most data for any given month should be in the current nominal state. The typical month will contain 1-3 short intervals of bad data from spacecraft maneuvers.

Doesn't the statistics engine used for AMSU limb adjustment require valid data from channel 4 in order to correctly adjust channel 5 data, the channel which is used to create temperature anomalies provided to the public?

The AIRS retrieval code (statistics engine) does not incorporate a limb adjustment as you have described above. Where reliable sensor data is available, it is applied directly to the appropriate portion of the atmosphere, taking into account the angle of the observation. Of the 2378 infrared and 15 microwave channels available to the AIRS retrieval algorithm, no particular channel is most important in deriving our products. Instead, the unique combination of all these channels of data allows us to develop a very complete and accurate temperature and water vapor profile throughout the entire atmosphere, and that is why our data products are very important to weather forecasting and climate studies.

Again, the AIRS Project believes that many of your technical questions can be answered reviewing the documentation at: http://disc.sci.gsfc.nasa.gov/AIRS/documentation. If you have further questions, we request that you contact us via our “Ask AIRS” portal at http://airs.jpl.nasa.gov/AskAirs/. You may also want to register as an AIRS Data User at http://airs.jpl.nasa.gov/DataRegistration/data/index.cfm. In that way you will be notified whenever a significant announcement regarding the AIRS Project or the AIRS and AMSU-A instruments is issued.

Thank you for your interest in AIRS data,

Previous Posts In This Series:

AMSU Limb Adjustment

Noise

Proof That Temperature Area Determines Temperature Anomaly

Trying To Find The UAH January Anomaly In The Raw Data, Part 1 Of 2

Overview Of The Aqua Satellite Project, Update 1 Features

Aqua Satellite Project, Update 1 Released

Spot Checking The Spot Check

NASA, UAH Notified Of QA Spot Check Findings

About The Aqua Satellite Project

UAH January Raw Data Spot Check

So, About That January UAH Anomaly

A Note On UAH's High January Temperature

References:

NASA, UAH Notified Of QA Spot Check Findings

Noise

Aqua Satellite Project, Update 2 Released

Update 2 for the Aqua Satellite Project is ready. You can download it here. It includes a new AMSUSummary program for summarizing temperature data into the usual daily and monthly values. AMSUSummary provides average, minimum, and maximum values by day and month.


Like last weekend, the all night coding sessions have left me exhausted, so the change log will have to do for now as  a description of the new features.


=== UPDATE 2 March, 7, 2010
The following improvements were made for Update 2:

*) Added AMSUSummary program for summarizing extract data in csv format. Summaries include  daily and monthly averages, minimums, and maximums. Includes command line help text.

*) Bash shell script for running AMSUSummary has been added. It's name is amsu_summary and it's located in the Scripts folder. See the comments inside the script for details on using it.

*) Added Limb Effect Check to AMSUQA. This check is turned on using the -l switch. The limb effect check examines channels 4, 5, and 6 to ensure their readings are within expected limb variations as defined in "The Limb Adjustment of AMSU-A Observations: Methodology and Validation" Goldberg, et al. 2001. Footprints 1 through 12 and 19 through 30 are checked.  Footprints 13 through 18 are not checked due to their small limb effect values, which  allows for even small fluctuations to cause a failure.

The -l switch has an optional tolerance parameter which defaults to 0.5. This parameter specifies how much above or below the values of Goldberg, et al. 2001 a reading can be. A value of 0.5 provides a margin of +/- 50%. A value of 1.0 provides a margin of +/- 100%.

*) Changed AMSUQA -f switch to -i. Added -p switch to specify output file name prefix. amsu_qa script changed to use new switches.

*) Changed AMSUExtract -f switch to -i and -F flag to -f. amsu_extract script changed to use new flags.

*) Added -q switch to AMSUExtract to indicate only data that passes QA should be extracted. The -q switch includes a check for limb effect at 0.5 tolerance. Only data QA values are  checked. File-wide QA values are ignored, allowing data to be extracted from files that have not passed QA.

*) Modified amsu_qa Bash shell script. Output is now placed in the directory from which the script is run, to bring it in line within how amsu_extract and amsu_summary work. See the comments inside the script for details on using it.

*) Bash shell script for removing HDF text files has been added. It's name is rm_hdf_text and it's located in the Scripts folder.  See the comments inside the script for details on using it.

*) Added Doxygen files for the source code. This is in the Doc/Doxygen/html folder.

*) Added Aqua Satellite PDF book. This is in the Doc folder.

*) Added HTML pages describing the commands and scripts.This is n the Doc/HTML folder.

*) Added zip file for sample AMSU data for October 1st, 2009. This is in the Sample Data folder.

*) Added CodeBlocks projects for cross-platform build support. These are in the CodeBlocks folder.

AMSU Limb Adjustment

This post looks at the Limb Adjustment done for the AMSU. We talk about what the Limb Adjustment is, how it is done, and some problems associated with it.

What Is The Limb Adjustment?
If you stand up, bend over at the waist and swing your arm in an arc under you, you'll notice your arm is closest to the floor when it's directly under you. And you'll notice your arm gets further from the floor as it continues through the arc in either the left or right direction.

The scanning of the AMSU on the Aqua satellite has a similar situation. When it scans directly below itself,  it gets data from closest to the surface, but the scans to the left and right of the satellite don't penetrate as deeply. Because of this, the temperatures read by the scans to the left and right need to be adjusted. This is called a Limb Adjustment. Publishing in the American Meteorological Society, Quanhua Liu and Fuzhong Weng (2006) had this to say about Limb Adjustment:

A remarkable effect of the cross-scan sensor is the variation of the brightness temperatures across the scan line, even though the scene temperature is homogeneous. The variation in the cross-track measurements due to the change of the scanning angle is called limb effect and can be as much as 30 K for the 23.8-GHz water vapor channel and 15 K for troposphere sounding channels (Goldberg et al. 2001). Because the limb effect is often stronger than the real variation of the signatures from scenes, the unadjusted measurements prevent the objective analysis of weather systems and may make the regression retrieval algorithm complicated. More important, averaging satellite brightness temperatures to a given grid map for climate study requires that the data be limb adjusted prior to averaging.

For microwave instruments, like the AMSU, a different form of adjustment needs to be done over land and water, due to surface emissivity. Again from Liu and Weng (2006):

It is a little complicated for the microwave channels. The surface emits either more or less than the atmosphere at the microwave range, with full dependence on the surface emissivity. The water surface may emit much less energy than the atmosphere in the microwave range. The weighting function of the microwave troposphere channel is broader than that of the infrared channel. Asymmetric behavior of AMSU-A channels on the two sides of the nadir is recognizable (Weng et al. 2003).Goldberg et al. (2001) have developed a limb-correction algorithm to overcome the difficulties for AMSU-A. They computed the limb adjustment from multiple-channel observations and the scan position–dependent coefficients. Their algorithm is routinely applied for National Oceanic and Atmospheric Administration (NOAA) operational products.

How Limb Adjustment Is Done
A collection of scans from the month of July, 1998 is used to provide a mean for each latitude for each footprint, within 2˚ latitude. These historical scans are combined with current scans from the channel being examined and its neighboring channels, and a set of  physical and statistical coefficients. Publishing in the American Meteorological Society, Mitchell D. Goldberg, David S. Crosby, and Lihang Zhou (2001) had this to say about Limb Adjustment:

 A global set of coefficients is used for channels 6–14. Separate sea and nonsea coefficients are used for channels affected by the surface—channels 1–5 and 15. The predictors are generally the channel itself plus the adjacent channel whose weighting functions peak below and above. In other words to limb adjust channel 6, we use unadjusted channels 5, 6, and 7 observations as predictors. The exceptions are channel 14 uses channels 12, 13, and 14; channel 3 uses channels 3, 4, and 5; channel 1 and 2 both use channels 1 and 2, and channel 15 uses channels 1 and 15.

So to adjust for, say, channel 5, the historical values for channel 5 at the satellites current location, the current scan values for channels 4, 5, and 6, and a set of physical and statistical coefficients are used.

Potential Problems With Limb Adjustment

From what I can see, there are two potential problems with Limb Adjustment. The first is when current scan values are outside the limits expected based on the historical scans. For example, the scan line shown at the beginning of this post has a value at foot print 1 that is 40% below the expected low limit, which is shown in the diagram at the start of this section.

The second potential problem is when a neighboring scan line used for the adjustments doesn't have any available data. For channel 5, the channel we've been looking at in this series of posts, the neighboring scan lines are 4 and 6. Channel 4 had no data at all in it for the entire month of January. A sample of this is shown in using HDFView in the image provided below.

Screen Shoot Showing No Data In Channel 4.

Click for larger image.

Previous Posts In This Series:
Noise
Proof That Temperature Area Determines Temperature Anomaly
Trying To Find The UAH January Anomaly In The Raw Data, Part 1 Of 2
Overview Of The Aqua Satellite Project, Update 1 Features
Aqua Satellite Project, Update 1 Released
Spot Checking The Spot Check
NASA, UAH Notified Of QA Spot Check Findings
About The Aqua Satellite Project
UAH January Raw Data Spot Check
So, About That January UAH Anomaly
A Note On UAH's High January Temperature

References:
Uses of NOAA-16 and -18 Satellite Measurements for Verifying the Limb-Correction Algorithm
The Limb Adjustment of AMSU-A Observations: Methodology and Validation

Noise

Before doing Part II on looking for the UAH January anomaly in the raw AMSU data, I figured I'd clear the boards regarding "stuff you should know when looking at data". This post covers noise. There's one other post, the AMSU Limb Adjustment, which I'll do after this one.

Noise
There's actually several definitions of noise. In this post we're going to go with noise being anything that significantly changes the signal we're interested in.

You can get noise in a signal by adding additional data to it that's not related to the original signal, which I think everyone knows. But you can also get noise in a signal by taking out data that is related to the original signal. That's not as obvious and it's why I added the graphic showing loss of information degrading a signal into noise.

Creating noise both by adding data and by taking out data is related to my post examining channel 5, footprint 15. In that post, I tried to find validity for UAH's large January, 2010 anomaly by looking at channel 5, footprint 15. That footprint and footprint 16 require almost no limb adjustments to their readings. What they read is very close to the actual temperature.

This is the reason I picked that channel and footprint. It has the smallest chance of adding noise due to any invalid statistical limb adjustments.

The drawback to using only that footprint is I could have very easily created noise by limiting myself to only that footprint. There may be important information in the other footprints that was overlooked.

I'm aware of this problem and it's why we're going to continue our search for evidence of the January anomaly in the raw data. But I thought it was important for readers to be aware of it too.

Previous Posts In This Series:
Proof That Temperature Area Determines Temperature Anomaly
Trying To Find The UAH January Anomaly In The Raw Data, Part 1 Of 2
Overview Of The Aqua Satellite Project, Update 1 Features
Aqua Satellite Project, Update 1 Released
Spot Checking The Spot Check
NASA, UAH Notified Of QA Spot Check Findings
About The Aqua Satellite Project
UAH January Raw Data Spot Check
So, About That January UAH Anomaly
A Note On UAH's High January Temperature

Proof That Temperature Area Determines Temperature Anomaly

In the previous post I used some geometry to show that the January UAH anomaly of 0.72˚ is not supported by the data on channel 5, footprint 15. The idea that the area of a temperature graph can determine the anomaly may not be immediately obvious, so I wanted to show that this must be so with an informal proof. I leave formalizing the proof as an exercise to the reader.

It's important this be done because in the raw data we're working with temperatures, not anomalies. But the published temperature changes are in anomalies, not temperatures. We need to be able to switch between the two and compare the two with confidence.

What Is An Anomaly?
By definition, an anomaly is a deviation from some standard. A temperature anomaly is a deviation from some standard temperature. The value of the standard temperature doesn't matter too much, so long as it's well defined. We'll say the standard temperature has some value we'll call ⣿. Like any other temperature, we can graph ⣿ on a chart. We'll say the temperature ⣿ is graphed by the rectangle a in the diagram at the beginning of this post. When we say the temperature anomaly is 0˚, that's equivalent to saying the temperature is ⣿.

What Is The Temperature Area?
The temperature area is simply the area of the graph below the curve showing the anomaly. So if the anomaly is zero, the temperature area is the area of the bar that maps ⣿.

The X axis of such a graph represents time. When can measure time in different ways. For example the X axis of a month with 31 days can be measured with 333,450 scan lines along the X axis. Or it can be measured as 31 days. Or it can be measure as 1 month. It doesn't really mater which unit we choose anymore than it matters if we call 36 inches 3 feet or a yard.

For convenience, we'll say the X axis is 1, for 1 month. (Note that I used 31 as the width in my previous post. That works just fine, but I'll probably use 1 from here on out to make it easy on myself.) This means when we want to calculate a temperature area, we need only be concerned with it's height. This is because the area of a rectangle equals width times height and width is always 1.

So, for example, the temperature area of ⣿ is always ⣿.

Graphing Anomalies
We can graph anomalies individually, or we can take the best fit to the anomalies. When we take the best fit we get a triangle above or below ⣿. If we instead graph anomalies we get lots of little triangles along the graph, but in the end the area of the anomalies is the same. Again, for convenience, we'll take the best fit and work with a single triangle.

If the anomaly at the beginning of the graph is zero and at the end of the graph is some positive number, ❢, then a triangle is formed with an area equal to ½❢ and the temperature area now equals ⣿ + ½❢. This is shown in rectangle b in the diagram at the beginning of this post.

If the anomaly at the beginning and end of the graph is some positive number ❢, then two triangles are formed both with an area equal to ½❢ and the temperature area now equals ⣿ + ❢. This is shown in rectangle c in the diagram at the beginning of this post.

If the anomaly at the beginning of the graph is zero and at the end of the graph is some negative number, ❧, then a triangle is formed with an area equal to ½❧ and the temperature area now equals ⣿ - ½❧. This is shown in rectangle d in the diagram at the beginning of this post.

Conclusion
We can see from these examples that as the anomaly changes, the temperature area also changes in direct proportion. Or, equivalently, we could say that as the temperature area changes the anomaly changes in direct proportion.

So if we ever see a change in temperature area and a change in anomaly not in sync, we know something is wrong.

Previous Posts In This Series:
Trying To Find The UAH January Anomaly In The Raw Data, Part 1 Of 2
Overview Of The Aqua Satellite Project, Update 1 Features
Aqua Satellite Project, Update 1 Released
Spot Checking The Spot Check
NASA, UAH Notified Of QA Spot Check Findings
About The Aqua Satellite Project
UAH January Raw Data Spot Check
So, About That January UAH Anomaly
A Note On UAH's High January Temperature

Trying To Find The UAH January Anomaly In The Raw Data, Part 1 Of 2

This is a two part series where we look to see if the January UAH anomaly can be found in the Aqua AMSU Level 1B data. The size of the anomaly we're looking for is 0.7˚ C. Each of the two parts of this post will use a slightly different method to try and find the anomaly.

I'll start off right away and tell you the answer for this post: it's not there. The rest of the post will show why.

Calibration With Past Anomalies, Footprint 15.
Both posts will use a method of calibrating the raw temperatures of the AMSU to published UAH anomalies for the same time period. In this post we'll look at footprint 15. We're using footprint 15 because it requires almost no statistical adjustment my the software for limb correction, so we don't have to worry about limb correction, bad data in channel 4, etc.

Calibration is done using 2 periods of published UAH anomalies. In this case, the January, 2008 and January, 2009 data are our calibration periods. We will then use that calibration information to examine the third period, January, 2010. The anomalies for all three periods were reported as:

January, 2008: -0.05
January, 2009: +0.3 (+0.35 from previous year)
January, 2010: +0.72 (+0.42 from previous year)

The raw data for channel 5, footprint 15 for those three months is shown below. All 1,000,350 scans for channel 5, footprint 15 are shown for the three months we're looking at. A trend line is added for each and we zoom in on the beginning and end of the series. January, 2010 is shown in red, January, 2009 is shown in purple, and January, 2008 is shown in green.

January 2008, 2009, 2010 Channel 5 , Footprint 15 Raw Data

Click for larger image

Let's look at the 2008 and 2009 data first. The beginning and ending values are:

January, 2008, Beginning: 246 K
January, 2008, End: 248.75 K
January, 2009, Beginning: 248.2 K
January, 2009, End: 249

We need a way to relate the raw temperature data to the temperature anomalies. Both raw data trends are straight, so we can treat each trend as a right-angled trapizium (i.e. a rectangle with one edge not parallel) with edges at the left, right, bottom, and trend line. This, in turn, can be divided into a rectangle and a triangle. An example of this is shown below for the January, 2008 trend.

From this we can calculate the area of the the first two trends and compare their difference to the difference in anomalies over the same period. This gives us an objective scale between the area of the raw data and the anomaly for the month.

January, 2008 Area: 7668.625
January, 2009 Area: 7706.6
Difference in Area (2009 - 2008): 37.975
Difference in Anomaly (2009 - 2008): +0.35
Anomaly/Area Ratio: 0.0092

So a difference in area of 37.975 increased the anomaly by +0.35 K. Now lets do the same area calculation for 2010 and see what the relationship is.

January, 2010, Beginning: 249 K

January, 2010, End: 248.75

January, 2010 Area: 7715.125

Difference in Area (2010 - 2009): 8.525

Difference in Anomaly (2010 - 2009): +0.42
Anomaly/Area Ratio: 0.0492

The change in area between 2010 and 2009 is less than ¼ the change between 2009 and 2008, yet change in anomaly between 2010 and 2009 is larger than the change in anomaly between 2009 and 2008. The differences in the effect of increasing the temperature area on the anomaly is captured in the Anomaly/Area Ratio. The ratio for the January, 2010 - January, 2009 change is much larger (0.0492) than the ratio for the January, 2009 - January, 2008 change (0.0092).

This clearly can't be right. In these examples, there's no relationship between an expanding temperature area and an anomaly. There should be, because an increase in anomaly represents nothing more than an increase in temperature area.

And since the rules of geometry aren't going to change, it seems there's nothing in this channel 5, footprint 15 data to support the anomaly of January, 2010.

Edit: I used 31 as the width here, representing 31 days. In the future, I'll probably use a width of 1, representing 1 month. This'll simplify calculations.

So Does This Prove The UAH January, 2010 Anomaly Is Wrong?

No. It only shows there's nothing in channel 5, footprint 15 to support the value of the anomaly as valid. Channel 5, footprint 16 will give similar results.

Those two footprints are the ones that really don't need any statistical limb adjustment. The other footprints do. So that means the support for the January, 2010 anomaly either doesn't exist at all, or exists somewhere in those other footprints with their statistical adjustments.

Which is what we'll look at next post. I don't know what we'll find when we look there. I haven't done the analysis yet.

Previous Posts In This Series:

Overview Of The Aqua Satellite Project, Update 1 Features
Aqua Satellite Project, Update 1 Released
Spot Checking The Spot Check
NASA, UAH Notified Of QA Spot Check Findings
About The Aqua Satellite Project
UAH January Raw Data Spot Check
So, About That January UAH Anomaly
A Note On UAH's High January Temperature

References:

Dr. Spencer's January UAH Anomaly Post

Overview Of The Aqua Satellite Project, Update 1 Features

In this post we're going to take a look at the three new shell scripts and new executable that come in Update 1 of the Aqua Satellite Project.

New Scripts
All three of the new shell scripts are for working with HDF files en masse. They all expect a directory structure similar to the one shown in the picture above. In this structure there are a series of folders that all contain HDF files.

The hdf_to_text script will walk this structure looking for HDF binary (.hdf) files in the immediate subdirectories. When it finds them, it creates a text subfolder in the folder containing the HDF files, converts the HDF files to text and places them in the text subfolder. At the end of the script, each of the folders shown above would have a text subfolder containing text versions of their HDF files.

The amsu_qa script is similar. It walks the subfolders and converts .hdf binaries to text in a text folder just like hdf_to_text does, and then it runs AMSUQA on the resulting text file. This saves you the trouble of having to run both scripts. The amsu_qa script is also smart enough not to convert an .hdf file to text if a text version already exists. The output of the amsu_qa script is up to three files in the text folder. These files are named passed, failed, and suspect, and contain the QA results for the files that NASA's QA marked as passed, failed, or suspect in the automaticQualityFlag of the file.

The amsu_extract script is just like the amsu_qa script, except that it runs the new AMSUExtract program rather than AMSUQA. AMSUExtract allows you to provide several different command line switches to get the data you want, and only the data you want. The amsu_extract script lets you specify these switches and it passes them on to AMSUExtract. Generally, you'll be interested in the -s, -c, and -F switches, which allow you to specify the scan lines, channels, and footprints that are extracted.

AMSUExtract
The AMSUExtract program allows you to pull scan information from a Level 1B AMSU text file. Output is in csv format and is printed to standard output, allowing you to redirect it as needed. AMSUExtract has a number of command line switches that control its functionality. These are shown below as displayed by the command's help text.

AMSUExtract Extracts scan information from an AMSU text file and sends results to standard output. Usage:
AMSUExtract [-h] -f AMSU_Text_File [-s Scanlines] [-c Channels] [-F footprints] [-a] [-H]
f The location of the AMSU text file to be QAed.
s An optional comma seperated list of scanlines to extract. Ranges can be specified using a dash. Example -s 1-5,7,10
c An optional comma seperated list of channels to extract. Ranges can be specified using a dash. Example -c 1-5,7,10
F An optional comma seperated list of footprints to extract. Ranges can be specified using a dash. Example -F 1-5,7,10
a Use this switch to extract antenna temperatures. The default is to extract brightness temperatures.
H Do not display headers. The default is to display headers.

The -f switch is required. It specifies the location of the HDF text file to process.

The -s, -c, and -F switches allow you to specify the scan lines, channels, and footprints to extract. You can specify a single number, a collection of comma separated numbers, or a range of numbers with a dash in between the start and end of the range. The comma separated numbers and ranges can be used together. The command to pull all 45 scan lines of channel 5 with footprints 15 and 16 looks like this:

AMSUExtract -f filename -c 5 -F 15,16

The first few lines of the results of that command look like this:

Beginning Date,Clock,Scan Line,Channel 5 Footprint 15 Brightness,Channel 5 Footprint 16 Brightness
2009-12-31,536457572,1,260.328,260.598
2009-12-31,536457580,2,260.262,260.116
2009-12-31,536457588,3,259.891,259.744

The output shows the date, clock time, and scan line number, followed by the channel and footprint values requested. Note that the -s, -c, and -F switches are all optional. If you don't use them, you'll extract all scan lines, all channels, and all footprints.

The csv output format of AMSUExtract makes it easy to build graphs or load values into spreadsheets. The image below shows a graph of scans for channel 5, footprint 15 for all 333,450 scan lines of January, 2010. The data was produced by the amsu_extract script and graphed using an application named DataGraph.

Requirements
All the scripts and programs work on text versions of HDF files. To convert the binary HDF files from NASA into text, use ncdump. To get ncdump, follow this instructions in this post.

The code itself is written in standard C++ and built using the free gcc compiler. It has only been tested on a Macintosh, but in theory should compile and run on any system.

The bash scripts naturally require the free bash shell.

Previous Posts In This Series:
Aqua Satellite Project, Update 1 Released
Spot Checking The Spot Check
NASA, UAH Notified Of QA Spot Check Findings
About The Aqua Satellite Project
UAH January Raw Data Spot Check
So, About That January UAH Anomaly
A Note On UAH's High January Temperature

See Also:
AMSR-E And AMSU HDF-EOS C++ Readers Are Done

References:
Looking At The Aqua Satellite Data
DataGraph 2.1.1
gcc compiler
bash shell