SwathS, flight day 176/2023, Grosseto

[jann]

Data location: /users/rsg/airborne/2023_arsf_data/flight_data/italy/SwathS_23-2023_176_Grosseto

Data arrived from NERC-ARF via hard drive September/October 2023

PI: Martin Wooster

Sensors:
Fenix1k (requested, flown)
IBIS ( main requested, flown)
OWL ( requested, flown)

[wja]

Navigation Processing

Basestation data converted to RINEX. All previous flights are also included in the basestation data, so just this flights data needed to be extracted (done with teqc).

GPS and GLONASS broadcast ephermides, along with precise ephemeris data accessed from CDDIS. PosPac could not access these itself.

Completed processing using the single base method.

[jann]

Missing calibration files for flight lines 3 and 22.

For flight line 3, used calibration files for flight line 4 and for flight line 22 used calibration files for flight line 21.

[asm]

Owl

Creating a delivery using @jann processed data. Owl flightlines 28-37 do not have any mapped information or nav data, those were likely collected with the landed aircraft for testing and will not be included in the delivery.

[asm]

Owl DC

Started.

[asm]

Owl DC

Created logsheet and readme. All checks have been run and passed. Mapped files have been zipped. This project is ready to be delivered.

[dac]

Delivery

Copied to FTP server (arsf1)

[wja]

Fenix1k Processing

Have created updated wavelengths of raw data and generated a APL config.

The following steps are need to improve data quality:

• Boresight
• Update swath mask (aircraft is obscuring port side - why has this changed?).
• Looks like a small timing offset is present in several lines

Data looks noisy

[wja]

Fenix1k Processing

Wrong IMU data for lines 4 & 9 (IMU pointing at angle, Fenix pointing at nadir).

Will not map.

[mark1]

Odd things with the nav data. The fenix realtime specim nav files have heading in opposite direction to travel (i.e. the start/stop gps positions suggest travel in opposite direction). Post-processed nav was reprocessed with imu rotated 180, so post-processed imu data now agrees with gps positions (we think). Mapped Fenix data still has appearence of acquiring data in the opposite direction (e.g. slit bend suggests flight direction oppostite).

[wja]

Creating Fenix1k Delivery

Mark has got the data processed with a new boresight.

Creating delivery.

[wja]

Fenix1k Delivery

Ready for checking.

[dac]

Fenix1k Delivery Check

• In the readme the mosaic of flightlines can see that alignment is off for the lines, looks like an SCT problem.
• check_apl_cmd ran through OK.
• Alignment for a lot of the lines lines is off in check_apl_cmd output, looks like an SCT problem.
• I've checked the mapped data in the delivery for lines 18 and 19 which were off in the check_apl_cmd output and these look good so I think problem is likely that wrong nav files were copied over but needs further investigation.
• Spectra looks good when compared to simulations using Py6S.

Everything else looks OK so will give another check once alignment has been sorted.

[wja]

Fenix1k Delivery Check

• check_apl_cmd resulted in alignment issue because it didn't used the flipped view vectors for the fenix data, which is required for this flight
• I have re-made screenshots
• I have re-made the readme to include a good mosaic screenshot
• Have included a comment in the ReadMe about navigation issues - mark1 had trouble processing because the realtime navigation and post-processed navigation were travelling in different directions.

I have included the flipped view vectors BIL and included this in the example aplcal commands

• Zipping mapped files

Todo:

• Need to update the view vectors TXT file to match the flipped view vectors provided with the BIL.

[wja]

Fenix1k Delivery

Flipped view vector text file.

Marking ready to deliver.

[wja]

Fenix1K Delivery

Added geometry files (aplcorr --atmosfile outputs) to the deliveries at PI's request.