Specim instruments

You can find a thesis covering the underlying principles of the Specim instruments (Eagle & Hawk) at ​http://www.vtt.fi/inf/pdf/publications/2001/P435.pdf

Notes of interest

Eagle uses a 1024x1024 CCD, but only the middle ~504 spectral pixels are used in normal operation (representing the range from ~390nm to ~950nm) and is normally spectrally binned by 2 (giving 252 bands).

However, when used with a band file for "calibration mode", the instrument returns the full data width (i.e. all 1024 pixels). This must be accounted for in any calibration code. (source: phone chat with Bill, 6/Nov/2007, much amended 30/Jul/2007 following corrections to Mike's interpretation from Bill)

File format

Eagle and Hawk capture data as ENVI format BIL files (a pair of .hdr and .raw), with an associated nav file (sometimes just one per project, sometimes one per line). The header files are easy to find - they're ASCII and begin with "ENVI". The .raw and .nav files are harder to get as neither have a header.

The raw Eagle and Hawk data can be recognised by scanning for an incrementing frame number (unsigned short int) at pixel 0, band 0 of each frame.

The nav files don't appear to have a header of any kind. Apparently they are applanix POSATT format binary files and have no useful header; the data frames have a 2 byte ID, but this would not identify the file. They hold real time navigation information plus a marker indicating the exact start point of a line / capture.

Data transfer

The data from the CCD are transferred to a framegrabber card in the computer using ​Camera Link. As this is a digital protocol, there are no digitisation effects to worry about. However, there may be some digitisation error in the camera itself.

Timing

Both Specim instruments are connected to a nav-sync box that timestamps the start of acquisition against GPS time. This measures the time to the next GPS pulse-per-second, from the first start of integration pulse from the camera that occurs after the start of acquisition pulse from the recording system.

The frame grabber lag time is unknown. Previously it was thought to be 55ms regardless of frame rate (i.e. a frame is captured 55ms before the nav sync pulse), but this was actually a once-off correction applied by Specim for a single dataset. What was called the frame grabber lag time is actually an unknown timing error in the system. Further work is underway to isolate this.

Consequently the timing of a start of acquisition is next_GPS_PPS - navsync_time - <unknown and variable error>ms.

Eagle

Detector size	1024x1024
Bit depth (of sensor analog to digital converter)	12 bit
Spatial pixels	1024 (unbinned) leftmost 72 dedicated to FODIS, leaving 952 for imagery
Spectral pixels	1024 on CCD, central ~504 in use, normally binned by 2 in operation
Spectral resolution	3.3 nm
Nominal spectral range (prior to calibration)	400-970nm
Central pixel number	512 (of original 1024, unconfirmed) Once FODIS region is stripped, this is pixel no 440 (unconfirmed)
Focal length	18.3mm (manufacturer supplied) (18.5mm on manufacturer datasheet retrieved 20090817 - ​http://www.specim.fi/products/aisa-airborne-hyperspectral-systems/aisa-series.html
Field of View (FOV)	37.7 degrees (from manufacturer datasheet retrieved 20090817 - ​http://www.specim.fi/products/aisa-airborne-hyperspectral-systems/aisa-series.html[[br]]Note the FOV is lopsided as the FODIS region removes a couple of degrees on the starboard? side
Pixel size	12 micrometers (unbinned)
IFOV	0.037 degrees (from manufacturer datasheet retrieved 20090817 - ​http://www.specim.fi/products/aisa-airborne-hyperspectral-systems/aisa-series.html

The smile and keystone are <2 microns, according to the datasheet.

Note that the field of view and focal length parameters are not measured but are quoted from specifications or mathematically calculated by the manufacturer, so there will be some error.

IFOV calculations

Using the 2 * tan^-1( PIXELSIZE / 2 * FOCAL_LENGTH) calculation from ​http://www.fas.org/man/dod-101/navy/docs/es310/EO_image/EO_Image.htm, you get:

1. 0.03771002 degrees, using 18.3mm for the focal length
2. 0.037165 degrees, using 18.5mm for the focal length

Using the FOV / number of pixels method, you get:

1. 0.036816406, from FOV / 1024 (raw sensor spatial pixels)
2. 0.03960084, from FOV / (1024 - 72) (raw sensor spatial pixels minus FODIS region) - most likely to be wrong of all these.

Hawk

Detector size	320x256
Bit depth (of sensor analog to digital converter)	12 bit
Spatial pixels	320 (unbinned)
Spectral pixels	256 typically ~220 in use
Spectral resolution	12 nm
Nominal spectral range (prior to calibration)	970-2500nm
Central pixel number	160 (unconfirmed)
Focal length	22.8mm (manufacturer supplied) (22.5mm on manufacturer datasheet retrieved 20090817 - ​http://www.specim.fi/products/aisa-airborne-hyperspectral-systems/aisa-series.html
Field of View (FOV)	24.0 degrees (from manufacturer datasheet retrieved 20090817 - ​http://www.specim.fi/products/aisa-airborne-hyperspectral-systems/aisa-series.html
Pixel size	30 micrometers (unbinned)
IFOV	0.075 degrees (from manufacturer datasheet retrieved 20090817 - ​http://www.specim.fi/products/aisa-airborne-hyperspectral-systems/aisa-series.html

The smile and keystone are <5 microns, according to the datasheet.

Note that the field of view and focal length parameters are not measured but are quoted from specifications or mathematically calculated by the manufacturer, so there will be some error.

Bad pixels

Jukka @ Specim sent email (25/July/2008) detailing some properties of the Hawk sensor. A summary is:

• the detector is a mercury cadmium telluride (MCT) sensor
  • this is sealed in a vacuum, which may gradually leak and increasingly cause more bad pixels to appear
  • the leaking process takes 6 months to several years according to the manufacturer, and the sensor can be restored by a factory process (at Specim?)
  • if we see an increase in bad pixels, we may wish to have the instrument serviced, but recalibrations will save some of the pixels anyway
• bad pixel specification: "if the pixel peak responsivity differs more than +/- 30% from average responsivity, it is considered to be bad. According to specification less than 2% of pixels should be bad. In practice that is from 0.3 to 1.0 %."