Version 6 (modified by mggr, 9 years ago) (diff)


Specim instruments

You can find a thesis covering the underlying principles of the Specim instruments (Eagle & Hawk) at

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.


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 apparently 55ms regardless of frame rate (i.e. a frame is captured 55ms before the nav sync pulse).

Consequently the timing of a start of acquisition is next_GPS_PPS - navsync_time - 55ms. [mggr: check this isn't +55ms!]


Detector size 1024x1024
Raw sensor bit depth 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 -
Field of View (FOV) 37.7 degrees (from manufacturer datasheet retrieved 20090817 -
Pixel size 12 micrometers (unbinned)
IFOV 0.037 degrees (from manufacturer datasheet retrieved 20090817 -

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

IFOV calculations

Using the 2 * tan-1( PIXELSIZE / 2 * FOCAL_LENGTH) calculation from, 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.


Detector size 320x256
Raw sensor bit depth 14 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 -
Field of View (FOV) 24.0 degrees (from manufacturer datasheet retrieved 20090817 -
Pixel size 30 micrometers (unbinned)
IFOV 0.075 degrees (from manufacturer datasheet retrieved 20090817 -

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

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 %."