[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Last Night's Run



Last night I got another run to add to disk set 18.  Jure, you will be glad 
to know that this one has a bias run at the beginning.  I will now keep 
running with this format.

It is not so simple to get a bias frame.  It takes 46 seconds to read out a 
frame.  If I read out a frame, then immediately read it out again to get 
the bias frame, this results in each pixel being exposed to dark current 
for 46 seconds.  The best I can do is 47 seconds.  For a 100 second "dark" 
exposure (the shutters are not opened for a dark otherwise everything else 
is the same) the dark current exposure is 147 seconds.  So if you subtract 
a bias from a 100 second dark, then the difference should be that due to 
100 seconds of dark current exposure.  For last nights run this was 17 ADU 
or 0.4 e- per second.  Note that the sigma for a bias frame was 10 ADU, and 
the sigma of the difference was 17 ADU.  Thus the sigma contribution of the 
dark current over a 100 second exposure was 3 ADU compared to minimum noise 
of 10 ADU for a bias and 17 ADU for a dark.  Note that some pixels have 
higher dark current that others, this explains why the sigmas do not add up 
in quadrature as one expects??

Somewhere through the night, the program decided to switch to 200 second 
exposures from 100 second exposures.  This after a long pause thinking 
about it.  I actually woke up in the middle of the night and noticed the 
change in the beep pattern.  I did not get up and look, since I eventually 
heard a beep and thought that I was just imagining that they were out of 
their usual order.  Sigh!  One more programming bug to find.

At least for disk 18j, you will have to pay attention to the exposure 
length in the fits header.  One should be doing this anyway.

All this after a frantic day trying to fix a problem that was 
intermittent.  The last several runs have ended early in the morning with 
saturated images.  Since the moon is in just about the right place to cause 
this I did not pay attention at first.  It now appears that it was due to 
the data driver at the ADC board cooling down and causing marginal write 
strobes.

Some of you have noticed "bright" isolated pixels.  This is related to that 
problem.  When I do the right things the bright pixel problem may go 
away.  Arne and Michael, if you see a "bright" pixel problem, consult with 
me.  It may be that each cable length will have to be "tuned" to be 
optimum.  Sigh!

Some of you may recall that I have used the "Bob Wilson" (builder of 
Fermilab) design technique for the Mark IV.  The idea is that you build 
everything with a safety factor of 1 instead of the usual 7.  Since you 
can't design all that accurately, many things are still over designed.  The 
rest fail and you then redesign them to work.  The result is a much lower 
cost.  There are always a few things that almost work.  It takes a while to 
find these.

Tom Droege