GB14/00, flight day 216/2014, Little Rissington

[mark1]

Data location: /users/rsg/arsf/arsf_data/2014/flight_data/arsf_internal/GB14_00-2014_216_Little_Riss_Fenix/

Data arrived from ARSF via network transfer on 8 August 2014.

Scientific objective: Boresight

Priority: Urgent

PI: Internal

Notes:
Fenix boresight. LiDAR data have been collected also but only in the Fenix boresight flight line configuration, so is not required to be processed.

Sensors:

• Fenix (requested)
• Leica LIDAR (not requested)
• RCD (not requested)

[tec]

Starting Nav Processing

[dac]

Took over nav processing.
Basestation ppp result:

Lat	51 59 26.258000
Lon	-1 17 18.74131
El	119.607

[dac]

Couldn't achieve desired position separation in IPAS TC. Values were +/- 0.2 - 1 m.
Processed using Oxford basestation rather than portable basestation deployed during flight due to problem recovering data from data logger. Will wait to hear back on data from portable basestation and reattempt processing.

[dac]

Trying with Stroud (STRU) base station.
Basestation ppp result:

Lat	51 44 21.03175
Lon	-2 18 02.78082
EL	76.317

[dac]

Navigation data processed to acceptable accuracy by including third base station at Hungford and performing network correction.

Hungford ppp result:

Lat	51 24 15.45171
Lon	-1 30 50.17029
El	183.171

Started Fenix processing.

[dac]

There were two different frame rates in the header files, changed all from the fps_set value to fps_qpf, initial value produced what looked like a varing SCT offset along the flightline. Also set 'usenav = false' in config file.

SCT values:

Flightline	FENIX
1	2.69
2	2.72
3	1.75
4	43.70
5	26.65
6	47.72
7	2.91
8	2.95

Approximate position tested in GoogleEarth

[dac]

Best possible values obtained from boresight:

pitch, roll, heading: 0.40 -0.19 0.32

After careful investigation it was found the fps_qpf values in the header files weren't correct and resulted in distortions in the data. Therefore, an alternative method was sought to determine the correct framerate.

The final solution was to use the lidar data was used to determine the length of time between two points. From the same two points the number of scan lines in the raw Fenix data was measured and these were used to determine the correct framerate.

Using this technique it was possible to find boresight values which produced an acceptable result. However, there are still some minor artifacts in the data such as wobbles in lines.

Based on the correct frame rate, updated SCT values are:

Flightline	FENIX
1	2.98
2	2.98
3	2.00
4	43.99
5	27.03
6	47.96
7	2.97
8	2.99
9	1.97

From these the best boresight values were found.

These boresight values were tested with day 217 and 219a and produced a good match between overlapping (219a) and perpendicular (217) flightlines.

Although the final boresight values produced good results, due to the numerous problems with these data another boresight flight would be preferable so we can be sure we're delivering the highest quality data.

[lah]

OWL
Only first 2 lines are of any use. No calibration data (T1 & T2 files) for any other lines due to blackbody failure noted on logsheet. Tried processing other lines with line 2's calibration file, but this just produces nonsense. (238 is suitable for use as a boresight)

[lah]

OWL
Found SCTs for first 2 lines so can compare day and night flights. 238 boresight not great for this flight, but can't do much about that with only 2 lines of usable data.

Flightline	OWL
1	1.99
2	2.00

[mark1]

Added screenshots to the fenix delivery as they were missing and causing the overviews generator script to fail.