[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CCD Charge clearing, is it required?
- To: firstname.lastname@example.org
- Subject: Re: CCD Charge clearing, is it required?
- From: Tom Droege <email@example.com>
- Date: Fri, 30 Jan 1998 11:08:17 -0600
- Old-Return-Path: <firstname.lastname@example.org>
- Resent-Date: Fri, 30 Jan 1998 12:56:28 -0500
- Resent-From: email@example.com
- Resent-Message-ID: <"JDT17C.A.tTE.Fog00"@kani.wwa.com>
- Resent-Sender: firstname.lastname@example.org
Chris and all,
At 10:21 PM 1/29/98 -0800, you wrote:
>Thanks for the comments. I think I know a bit more then I
>did a few days ago.
>It sounds like charge clearing is required if the CCD has been
>sitting around for a while. How long is "a while" and does it
>need to be cleared once or several times.
A while is the time it takes to accumulate charge. This can be from
leakage current while warm, from light, or even from cosmic rays.
>I also hear that CCDs can be cleared quickly with some binning
I think that once the charge has migrated all over the chip, that
a fast clear no longer works. It just takes a while - probably
minutes - to get it to a stable state. You might as well do standard
40 second read operations as anything else during this time.
Time is what it takes ones you have saturated the chip.
For normal exposures, though, one read clears everything. It
is only necessary to have a fixed time between the end of a
read and the start of the following exposure to assure a constant
There is room in the prom for a second operation. This could be
a fast clear. But I can think of better uses for it. Say a read out
of only the 500 x 500 center of the chip for a faster focus
sequence. This would only take 2.5 seconds or so.
Hmmmm! Come to think of it, a fast read for focus program would
also be a fast clear. So possibly these two programs would
provide everything we need.
OK, below you are thinking like an "interrupt" programmer. In
all the below is the assumption that you don't know what the
sequence might be. Well this is much tougher than running
in "schedule" mode where you schedule an all night sequence
and only check as you go along that you are keeping to your
My preference would be to run in "schedule" mode. Here you
set up an all night schedule with known intervals between the
end of one exposure and read out and the start of the next. This
makes all exposures have the same dark background, and the
same read out errors. It is then only necessary to have one clock
interrupt at which you "poll" your task list and see what it to
be done. I call this type of programming "poll" driven as
opposed to "interrupt" driven. I know that interrupt driven
code is most popular with programmers. The advantage of
poll driven programming is that you never fail deep into an
interrupt structure where it can be very hard to unscramble
what went wrong. With polling, you just check you list at
each interrupt. Then you know immediately - woops! - I
got to item 7 too late - fail. You always know where you
failed and why. But I admit my experience on this goes back
to 1968. Several years of interrupt driven code for our PDP-8
communications processors faild to produce robust code.
When the code was rewritten for polling, this only took a
few months and immediately produced bullet proof code.
This was back though when our high speed trunk lines were
9600 baud, and we were running ASR-35s.
OK, Chris, you all will do what you want. I will write polling
code in QBasic for the prototypes. Then you will get to write
I figure the way I have the system designed, I will be able to
write everything needed to run a stand alone station in
QBasic. I can even imagine having the QBasic program
read a file at intervals to pick up commands put there by
an Ethernet link. Beyond that, running some sort of
communication program to put the stuff in the file, is
beyond my abilities. But I can imagine running a "stock"
program that allows me to telnet to load the file from
a remote location.
Wow! 200,000 lines of code to do this. I can't imagine how
so much code was written.
In answer to the bright star question below, I think it will
be hard for much charge from a bright star to be left behind.
This could happen if the star is at the very top of the frame (last
line to be read out) and some charge from it has leaked to
the adjoining substrate. The trails from a saturated star seen
in the present data are a different effect. A saturated pixel
leaks to the adjoining pixels. All this charge is removed on a
frame read out.
>Here is what we can do to perform the "expose" command:
>Option 1, the Mk IV has no erase mode:
> 0) When the memory board sends the interrupt, signaling that
> the CCD has been read out we start a timer running.
> It counts in seconds.
> 1) When we get an expose command we check if the shutter is open.
> if open we send an error back and quit.
> 2) So now we know the shutter is closed. First check the timer.
> if the timer has a large value or if it is not running then
> we do a read out operation and clear the timer. This takes 40 sec.
> 3) open the shutter. start an exposure timer.
> 4) when exposure timer expires we close shutter and send the
> pulse to signal a CCD readout.
> 5) When memory board is full (interrupt happens) do step zero
> and read out the memory to a disk file.
> This will let us do back to back exposures but will force a
> clear operation if there has been some time between exposures.
>Option 2, there is an erase mode.
> This is easy. We just do an erase every time before opening
> the shutter. We need not care how long it has been sense the
> last time we took an exposure.
>The question I have is will bright stars leave their imprint on
>the CCD from one frame to the next? I think it may be a matter
>of degree. I remember the trail effect on the Mk III. Saturated
>stars leave trails. Apparently some charge gets left behind
>when you row shift if the star is bright enough.
> --Chris Albertson home: email@example.com
> Redondo Beach, California work: firstname.lastname@example.org