NOTCam reset level jumps (on-going, updated) ------------------------
The "reset level" is the count level of the pre-integration readout of the array. It is supposed to be a function of detector temperature. When commissioning the array, it was adjusted to an optimal level, i.e. a level that maximizes the dynamical range and minimizes bad pixels. Over the years we have experienced varius jumps in this level, needing a re-adjustment of the dc-offset voltages each time.
All detector QC data obtained since we started measuring the reset level, show that there are always occasional reset level drops (by max 3000 adu) over the 1.5 hour it takes to obtain those data. The standard deviation of the mean level during this time is about +- 1000 adu. Thus, the reset level experiences instantaneous negative spikes but also more permanent level shifts.
A cron-job was set up by Ricardo to be able to monitor the reset level every hour over a longer time-span and over a larger temperature range than while observing, doing it with NOTCam off telescope. The result of 10 days monitoring was: a very smooth and approximate linear relation, the count level increasing by 750 adu for every 1 deg increase of the detector temperature. (This is consistent with the relation found for LIRIS/WHT, for instance.) During this monitoring no jumps were caught! But a few months later the mean count level had shifted by > 1000 adu, showing that monitoring was needed over a longer period, and a web page was made http://www.not.iac.es/instruments/notcam/staff/reset_level_monitoring.html
Since monitoring accumulates 1 GB of data every day, a script was made (RC) to analyze the images and delete the images at once. Data from 1 month (May-13) was found to include one "jump" (offset), and the average linear relation of counts with temperature was now 614 adu per degree. Another sequence of monitoring from Jan-14 to Apr-14 was collected and again the adu versus temperature relation is offset to the previous dataset, and has another slope.
Done:
- It was realized that due to this monitoring, we are now in the situation that the detector controller is always switched on, also during storage. This is suggested to be the reason why we no longer see the large jumps (only variations of a few hundred adu). No modification of the voltages have been made since January 2013.
- The solution to the problem seems to be leaving the array controller always switched on, also when NOTCam is not mounted.
TBD:
- When the data lost in a disk crash is recovered, some more analysis should be done on the large set of monitoring data to see whether the slope is also stabilizing.
The so-called ``reset level'' is the count level of the pre-integration readout of the array. It is supposed to be a function of detector temperature. When commissioning the array, it was adjusted to an optimal level, i.e. a level that maximises the dynamical range and minimises bad pixels. Over the years we have experienced various jumps in this level, needing a re-adjustment of the dc-offset voltages each time.
An extensive data set has been accumulated running a Cron job that monitors the reset level every hour when NOTCam is off telescope. Since monitoring accumulates 1 GB of data every day, a script was made to analyse the images and delete the images at once. Analysis of the data do show a relation with temperature, but the relation shows occasional jumps in zero-point, and changes in slope. The data sets needs to be analysed more in detail to search for the cause of this lack of stability, but the conclusion might be that no fixed value can be used, and this simply needs to be checked and adjusted when necessary.
Thomas Augusteijn 2016-05-05