Opened 7 years ago

Last modified 7 years ago

#616 new flight processing

GB17/00, flight day 164/2017, Alconbury

Reported by: dac Owned by:
Priority: immediate Milestone:
Component: Processing: general Keywords:
Cc: Other processors:

Description (last modified by mark1)

Data location: ~arsf/arsf_data/2017/flight_data/nerc-arf_internal/GB17_00-2017_164_Alconbury

Data arrived from NERC-ARF via network transfer (uploaded to RSG FTP) 2017-06-14

Scientific objective: Internal boresight flight

Priority: Urgent

PI: NERC-ARF

Sensors:

  • Fenix (requested/not requested, flown/not flown)
  • Leica LIDAR (requested/not requested, flown/not flown)
  • OWL (requested/not requested, flown/not flown)
  • PhaseOne (requested/not requested, flown/not flown)

Change History (27)

comment:1 follow-up: Changed 7 years ago by dac

Data unpacked and standard checks run. No log file present for Fenix line 2. James mentioned IPAS data is a different format - single file compared to multiple. Need to check if this is a problem.

comment:2 Changed 7 years ago by dac

Navigation processing

The NERC-ARF basestation and OS RINEX St Neots (SNEO) were both used for flight. Downloaded RINEX data and used ephemeris data from basestation. Need to get basestation height before this can be used for processing so proceeding using only OS RINEX data for now

Basestation PPP result for SNEO

lat 52 11 07.33081
long -0 06 44.97057
height 120.195

comment:3 Changed 7 years ago by lah

Owl checks

Ran through the Owl preprocessing checks (on wiki page) and everything looks ok so far.

As the Owl can be calibrated without waiting for the navigation or the fenix calibration to be finished I sent these jobs to the grid. Unfortunately these failed, so I will fix the script now. I saw a similar error working with the laptop batch processing script, so think something has changed in the way flags are being passed with subprocess and they now can't handle 2 inputs to the same flag in the same line (-l for memory and apl throttle) .

comment:4 Changed 7 years ago by lah

Owl

Committed code fix to https://gitlab.rsg.pml.ac.uk/arsf/internal-code/merge_requests/171. Is now running fine on grid.

comment:5 Changed 7 years ago by dac

Navigation Processing

IPAS Honeywell: Used location from file. Interpolated to match IPAS data. Default elevation mask of 10 degrees.

comment:6 Changed 7 years ago by lah

Owl

Level 1b files look fine. There is an interesting building(?) towards the end of line 5 and the start of line 1 which is showing a lot of spectral features - first time I've seen anything this distinct. Would be good to find out the material.

comment:7 Changed 7 years ago by asm

Lidar

Have tested processing lidar files using alspp.exe and the old calibration files. All worked trough with clear pitch and roll errors but they do not look very bad. Clouds are showing below the ground however.

Version 0, edited 7 years ago by asm (next)

comment:8 in reply to: ↑ 1 Changed 7 years ago by lah

Replying to dac:

Data unpacked and standard checks run. No log file present for Fenix line 2. James mentioned IPAS data is a different format - single file compared to multiple. Need to check if this is a problem.

Should probably change the sensor ID as part of unpacking for the rest of the season.

comment:9 Changed 7 years ago by dac

Hyperspectral Processing

Ran through processing using lever arms from 2015 (only Twin Otter survey) and calibration Specim provided.

Compared radiance spectra to 6S simulations using check_fenix_spectra_py6s.py and found a good match - no obvious problems.

Timing fix looks like it worked for lines 1 and 5 but not 2, 3 and 4 so will need to investigate further and possibly manually determine SCT values before boresight processing.

comment:10 Changed 7 years ago by dac

PhaseOne Processing

Processed the images using iX Capture without any problems. Colours don't look quite right so will need to check on the settings.

comment:11 Changed 7 years ago by dac

  • Description modified (diff)

comment:12 Changed 7 years ago by asm

Hyperspectral Processing

asm has taken over this project. Found SCT values:

Flightline FENIX
1 1.02
2 1.96
3 2.07
4 1.99
5 1.08

comment:13 Changed 7 years ago by dac

Navigation Processing

Processed IPAS20 data. This will now be used for Fenix processing.

comment:14 Changed 7 years ago by asm

Hyperspectral Processing

Lidar is not operative so restarting fenix boresight using Ipas20 sol file instead

comment:15 Changed 7 years ago by asm

Navigation processing

Done the NERC-ARF basestation verification. Got height from file.

lat 52 05 44.19041
lon 0 08 15.45307
El. Height 79.234 m
Ant Height 0.085 m, to L1-PC, LEIAX1202GG

comment:16 Changed 7 years ago by mark1

  • Description modified (diff)

comment:17 Changed 7 years ago by asm

Navigation processing

Litton IMU boresight angles needed to be set to 0, 0, 0 instead of default 0, -90, 90 (working for ipas_honeywell). That solved problems with the navigation (sol was providing a steady roll flight of -90 degrees).

comment:18 Changed 7 years ago by asm

Hyperspectral Processing

Found boresight for Fenix: 0.37 -0.51 -0.35 (pitch, roll and heading).

comment:19 Changed 7 years ago by dac

Hyperspectral Processing

Checked boresight values against OS Open Vectors and survey data and look good.

comment:20 Changed 7 years ago by lah

Owl

Started mapping files. A few problems with the config file were resolved manually:

  • Had to specify sol file as multiple present
  • Added boresight from previous
  • Copied owl_fov_fullccd_vectors.bil into arsf 2017 calibration folder
  • Set pixel size (defaults to 0 and causes a confusing error "Cannot create an area whose minimum x/y is greater than or equal to its maximum x/y.-0 0 0 0")

comment:21 Changed 7 years ago by lah

Scts for Owl

Flightline OWL
1 2.01
2 1.99
3 2.01
4 1.99
5 1.97
Last edited 7 years ago by lah (previous) (diff)

comment:22 Changed 7 years ago by lah

Owl Boresight

Very difficult to calculate heading offset as the only pair of overlapping flightlines in the same direction have very little overlap and the data are largely offset. Also different altitudes of the opposite direction pair make roll and pitch more difficult to identify. Going to try a bit more trial and error with the other 2 lines to see if the boresight values (0.15 0.08 0.30) can be improved.

comment:23 Changed 7 years ago by lah

Owl Boresight

Gone through a fair few changes and think that the best that can be achieved with the data is:

pitch: 0.08 roll: 0.20 heading: 0.30

Will check this looks ok for the summer school when processing.

comment:24 Changed 7 years ago by dac

Fenix processing

Set correct sensor ID in raw files using:

sed -i "s/sensorid = 350005/sensorid = 350006/g" *hdr
sed -i "s/sensorid = 350005/sensorid = 350006/g" *hdr

comment:25 Changed 7 years ago by dac

Fenix Boresight

Found new boresight pitch values with correct FOV file for load instrument. Values are now:

0.45 -0.51 -0.35 (pitch, roll and heading).

comment:26 Changed 7 years ago by asm

Digital Camera

A partial delivery previously created for testing was deleted and a new delivery was created with the new scripts. Awaiting for delivery check.

comment:27 Changed 7 years ago by dac

Digital Camera

Delivery looked fine. Corrected PI from 'ARSF' to 'NERC-ARF' in readme and finalised.

Note: See TracTickets for help on using tickets.