GB08/15, flight day 129/2008, Eaves_Wood_day

[mark1]

Data location: /users/rsg/arsf/arsf_data/in_progress/2008/flight_data/uk/GB08_15-2008_129_Eaves_wood_day

Data arrived from ARSF via initial SATA disk transfer on 12th May 2008

Scientific details: see /users/rsg/arsf/arsf_data/in_progress/2008/ARSF_Applications/GB_and_NL/GB08-15 Science Case.pdf

PI: A. Blackburn

Shares common ATM files with GB08_15-2008_130_Eaves_wood_night. Probably only need to process first 10 ATM files with suffix .129.

Sensors:

• ATM (delivered 4th July 2008)
• Eagle (delivered 17th June 2008)
• Hawk (delivered 17th June 2008)

Quicklook

TBD.

[mark1]

Was no logsheet or rinex data on data supplied via SATA disk. Has been downloaded from daphne.

[mark1]

Have removed ATM files 12,13,14,15 since these relate to project GB08/15, flight day 130/2008, Eaves Wood Night. If they are required for any reason they are located in /users/rsg/arsf/arsf_data/in_progress/2008/flight_data/uk/GB08_15-2008_130_Eaves_wood_night/atm

[mark1]

Eagle line 7 header file says only 100 lines. This was false, and have changed it to 4835 lines.

[mark1]

ATM data wont process properly. In azatm, each flight line tested gives 1000's of errors like:

scan jump from: 35877 to 35878 scan: 35878 rejected
scan jump from: 35877 to 35879 scan: 35879 rejected
scan jump from: 35877 to 35880 scan: 35880 rejected
scan jump from: 35877 to 35881 scan: 35881 rejected
...

and then sets all scanlines after when this occurs to 0. qcdisplay shows that there is ATM data in the file. When remove -g option from azatm command line, final image appears to contain all the data but not corresponding to the correct navigation times, and with gaps in.

[mark1]

Delivery directory created for Eagle and Hawk data. Located at
~mark1/scratch_space/GB08_15-2008_129_Eaves_wood_day/

[anee]

Minor changes, Rsynced to: ~/arsf_data/in_progress/2008/flight_data/uk/GB08_15-2008_129_Eaves_wood_day

[mark1]

Eagle and Hawk data delivered on hard disk 17th June 2008

[mark1]

Managed to get the ATM to process through by using the -scNO command on azatm. On 2 lines (5 & 8) have had to remove bad scans (as per some of the 2006 data processing), and flight line 5 seems to be screwed as far as the timing goes. Have corrected it such that the central portion of the flight line is reasonably wobble free, but northern portion of the flight line is a bit wobble crazy. What appears to have happened with this line is that it is syncing to different portions of the navigation data and not in a continuous manner.

[mark1]

Delivery directory created for ATM data. Located at ~mark1/scratch_space/GB08_15-2008_129_Eaves_wood_day/delivery/20080625/GB08-15/

[mark1]

Have split flight line 5 (ATM) up into 2 sections, Northern and Southern, applying an SCT offset of -2.1 secs to the southern part. This seemed the best solution to get both parts of the flightline corrected for timing offsets.

[anee]

Looks fine, rsynced to: /users/rsg/arsf/arsf_data/in_progress/2008/flight_data/uk/GB08_15-2008_129_Eaves_wood_day

[mark1]

ATM delivered via DVD on 4th July 2008.

[mggr]

Data sent to NEODC for archiving.