Some ATM lines for IPY have bad bands marked for some lines. However, the bad parts seem to correlate with areas where there is bright sunshine shining on white snow - in other words where the value is going to be pretty close to max. It's possible either this is incorrectly causing it to be classified as bad, or else that the max value is itself being used to mark bad data.

Eg. Green Box line 1:

azgcorr ver 4.8.9, causes segmentation fault when processing the full data and also when processing certain "chunks" of data, defined by a number of lines. For example using a chunk of lines 1-5000 works ok, but 1-5200 fails. 1-12402 works ok, 1-12403 fails. This is using the Eagle data from IPY07-06.

Data location: ~arsf/arsf_data/in_progress/2007/flight_data/ipy/IPY07_11-2007_200a_Helheim

Data arrived from ARSF via SATA disk transfer in August, with post-processed GPS arriving in December following Kidlington visit.

Scientific details: (details of IPY applications not currently available at PML)

PI: Tavi Murray

Note this is a subset of a single flight split into two for convenience - previous ticket tracking whole flight is #92.

Sensors:

• ATM (Delivered 23/05/08)
• CASI (Delivered 09/05/08)

Quicklook