| 15 | | |
| 16 | | == LIDAR == |
| 17 | | |
| 18 | | The Optec LIDAR operated up to 2008 was owned and processed by ULM - see [wiki:Processing/LIDAR]. |
| 19 | | |
| 20 | | In 2008, ARSF purchased an ALS50 (phase II) LIDAR from Leica. More information is at: |
| 21 | | * [wiki:Sensors/LeicaLIDAR/MikesNotes] - Mike's notes on the Leica training course in Aug 2008 (to be digested and turned into real wiki pages at some point in the future). |
| 22 | | * [wiki:Sensors/LeicaLIDAR/MarksNotes] - Mark's bullet notes on the Leica training course in Aug 2008. |
| 23 | | * [wiki:Sensors/LeicaLIDAR/MashUp] - The digestion of both sets of notes. |
| 24 | | |
| 25 | | == Specim == |
| 26 | | |
| 27 | | 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 |
| 28 | | |
| 29 | | == Hawk == |
| 30 | | |
| 31 | | Some details on Hawk's detector from Jukka @ Specim (email 25/July/2008): |
| 32 | | {{{ |
| 33 | | The detector type on Hawk is MCT (Mercury-Cadmium-Telluride), |
| 34 | | which means that it's not a CCD that is typically used for VNIR |
| 35 | | spectral range. |
| 36 | | |
| 37 | | The manufacturer's specification for that MCT detector bad pixel |
| 38 | | is the following; if the pixel peak responsivity differs more |
| 39 | | than +/- 30% from average responsivity, it is considered to be |
| 40 | | bad. According to specification less than 2% of pixels should |
| 41 | | be bad. In practice that is from 0.3 to 1.0 %. |
| 42 | | |
| 43 | | The detector is sealed in a vacuum housing. This vacuum "leaks" |
| 44 | | very very slowly. As a result of this new bad pixels may appear. |
| 45 | | Eventually the vacuum has to be recovered using a special method. |
| 46 | | According to manufacturer it may take from 6 months to several |
| 47 | | years before this must be done. So far we've done this only for |
| 48 | | a single sensor, which had been used already for several years |
| 49 | | before that. |
| 50 | | |
| 51 | | By they way, there are no similar bad pixels on CCD used on Eagle. |
| 52 | | |
| 53 | | ... response to query from Ben re: frequency of maintenance: |
| 54 | | |
| 55 | | There is no particular way or time to say when that operation |
| 56 | | is due. You will get a hint from additional bad pixels. Also |
| 57 | | if the detector temperature is no longer as low as it used |
| 58 | | to be that could be an indication of impurity in the vacuum. |
| 59 | | |
| 60 | | You don't want to try that operation periodically. It requires |
| 61 | | sending the system here and disassembly of some parts. After |
| 62 | | that that the system must be reassembled and calibrated. |
| 63 | | |
| 64 | | I'm not expecting your system do be due for that operation yet. |
| 65 | | And I understand you are recalibrating the system at the moment. |
| 66 | | This means that new calibration file will "recover" most of the |
| 67 | | partially appearing bad pixels if any. |
| 68 | | }}} |
| 69 | | |
| 70 | | == Notes of interest == |
| 71 | | |
| 72 | | 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). |
| 73 | | |
| 74 | | 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) |