Version 12 (modified by anch, 13 years ago) (diff) |
---|
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 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:
- 0.03771002 degrees, using 18.3mm for the focal length
- 0.037165 degrees, using 18.5mm for the focal length
Using the FOV / number of pixels method, you get:
- 0.036816406, from FOV / 1024 (raw sensor spatial pixels)
- 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 %."