Re: covered pixels

[hjohnson@pluto.njcc.com (Herbert R Johnson)]

On Wed, 20 Dec 2000 19:12:14 -0600, Tom Droege <tdroege@veriomail.com> wrote:
*>The dark frame problem will be helped when I get the PROMs straightened out 
*>so that you can get a measure of the dark current from the data.  I am 
*>working on it.
*>
*>Meanwhile, there are some covered pixels that could be used.  Just not as 
*>many of them as there could be.  You just have to figure out where they 
*>are.  ;^)  I give up, the present layout makes no sense to me.  I think it 
*>is an array dimensioning problem, and you all know that this can result in 
*>almost any error.  Still a little work with the pixels outside the image 
*>and the thermometer readings might produce something useful.
*>
*>Tom Droege

Tom, you should not give up on resolving these covered pixel problems. It
is a small issue but frankly you are the only person with the knowledge,
and the cameras, and the instruments, to fix it - with a little help.
Whether this is an "important" issue or not is not for me to say,
I just see it as a problem that I can contribute to fixing so it
has MY attention. Whether you or others choose to fix it is a judgement
call. But you recently mentioned again the value of public discussion
and of "why do it THAT way?" questions. So here is my bit of discussion,
incomplete but I think useful.

For a variety of reasons, I simply can't put a lot of work on
this in a short time and report IMMEDIATE results. But partial results,
I suspect, look tedious to some TASS members. This is frustrating
as often other TASS members react quickly when a problem is noticed,
but move on to other problems if they are NOT resolved quickly. But I
will report what I have in hand NOW before attention "moves on" again.
Consequently they will be incomplete.
                 
Tom, thanks for sending me the programs you use to generate these ROMS, which
control the timing of clocks and such to your CCD chip, and to the A/D and
such. I did not run the programs, but examined them by hand to determine
what the binary patterns are which they produce. Thanks also for
your preliminary description of the PROM's signals so I can interpret
these results. Tom says he will "publish" these at some point.

* Background on CCD digitizing and control methods

For the rest of us: Tom uses PROMS as a kind of microcontroller. Each
PROM output (eight outputs for CCD vertical/row controls, 16 outputs
for horizontal/columm and A/D control) controls a single function or
CCD control line. For discussion of the covered pixels, the relevant
lines are the three clocks and the "integrate" line which controls
the A/D. A CCD needs clocks to provide timing to shift pixels around
so they can be "read out". Tom uses "fast clocks" to compactly
clock out pixels he will not be digitizing, and "slow clocks" with
an "integrate" signal to read out and digitize a pixel value.
Tom has told me his "compact" scheme is not to save time per row,
but to reduce the total size of necessary control bytes in his PROMS
to stay within their capacity. Tom has written BASIC programs to generate
the bit patterns that correspond to the signals and commands I've mentioned
and others I have not mentioned.

* CCD control schema

For each CCD row, Tom's PROMS appear to do the following, as based on
interpreting his BASIC code and his logic descriptions:

clock 4 pixels fast but don't integrate - do that twice.
clock one pixel slowly and integrate - do that twice.
clock 4 pixels fast but don't integrate - do that twice.
clock one pixel slowly and integrate - do that twice.
clock 4 pixels fast but don't integrate - do that once.
clock one pixel slowly and integrate - do that "many" times.
  (here is where the imaging pixels are produced)
clock 4 pixels fast but don't integrate - do that THREE times.
clock one pixel slowly and integrate - do that once.
clock one pixel slowly and integrate AND stop the scan- do that once.
  (here are the last few pixels of the row.)
clock 4 pixels fast but don't integrate - do that "many" times.
  (this probably serves to clear out trailing pixels and such.)

* resulting data in image

The net result in the image row is the following. My comments in
parenthesis are by inspection of dark images as per METHODS
in my Tech Note 71, of dark images in Tom's Mark IV disk 16 (unpublished
results from work prior to this inquiry).

skip 8 pixels, then read and digitize TWO
        (column 0 pixels not studied)
        (column 1 pixels have VERY LOW standard deviation.
         St. Dev. is about 2 ADUs if several pixels removed
         from 3 standard deviations; if not removed, st. dev.
         is about 15 ADU's.)
skip 8 pixels, then read and digitize TWO
        (column 2 pixels not studied)
        (column 3 pixels same as col 1 and very close in values)
skip 4 pixels, then read and digitize "many"
        (column 4 pixels not studied)
        (column 5 pixels same as col 1 and very close in values)
        (pixels 6 through 2000 are approximately consistent but
         may have effects in first "tens" of columns. Standard
         deviation is otherwise about 20-40 ADU's roughly, after removing
         several pixels beyond 3 standard deviations. Before
         removing such pixels, st. dev. is about 100 ADU's.)
skip 12 pixels, then read and digitize TWO and end scan
        (last columns not examined)

* observations

Read TN 71 for some previous work by myself and others about dark
images and covered columns.

The reason I did not examine pixel columns 0, 2, and 4 is that from
previous reviews of these columns of images from early Mark IV results,
as per Tech Note 71, these columns had larger deviations and different
values from either columns 1, 3, 5; or later columns from dark images.
Column 0 in particular was too "bright", it had larger ADU values.
The last two image columns also were reported to have some inconsistencies,
to date I have not re-examined them. As the camera has changed over time
I will have to look at these columns again to see what they are doing NOW.

One of the issues that emerged previously was that it appeared that
only columns 1, 3, and 5 were apparently "covered" pixels, rather
than the first 6 columns as Tom intended. We have called them "covered
pixels" since. TN 71 and other TN's reference those discussions.

* POSSIBLE EXPLANATION

It would appear that Tom's scheme of fast/slow clocking (and
possibly other timing signals not discussed here) has
the effect of producing a PAIR of pixels as follows. The first
pixel, after several "fast" clocks, has a reading that seems "odd"
relative to pixels in columns in dark images. The second pixel
appears to have an UNUSUALLY CONSISTENT value from row to row,
and is also consistent with the second pixel from the OTHER TWO
pairs of pixels from columns 0 to 6. CONSEQUENTLY, I suspect
something occurs as a result of the change from "fast" to "slow"
clocking; or an effect is dissipated after the first few "slow"
clock cycles.

The bulk of the image is clocked out using Tom's "slow" method
and we know most of the results of that method are reasonable or
self-consistent. There may be some effects in the first tens
of column pixels that may merit some study.

The last two columns are again clocked out "fast" and "slow". I have
not studied those lately, at one time there was at least ONE pixel
produced thereby which was similar to pixels columns 1, 3, and 5.

* SUGGESTED EXPERIMENTS

I don't have the means or data in hand to diagnose this problem
further. I can only suggest experiments that may be informative.

Tom, you have said you can't expand your programs in your PROMS. But
how about changing the ORDER of your "slow" and "fast" clocking schemes?
Instead of alternating "fast" and "slow" clocking and digitizing,
clock "fast" through the early pixels; clock slow for SIX pixels
(not two) to get the covered pixels; and continue to clock slow for
the imaging pixels. This will show if the problem is when you change
from "slow" to "fast" clocking, or if there is another problem.
(I have no suggestions yet for the trailing covered pixels.)

Another scheme:
        fast clocking to get to the covered pixels;
        slow clocking to get the "middle" covered pixels;
        fast clocking to skip the remaining covered pixels;
        slow clocking to get the imaging pixels;
        (clock as needed for trailing covered pixels).

...with similar comments as previous.

Either of the above experiements can be done by changing the order of
your PROM programs. I believe -but I can't confirm- that you need not
change any other PC software or your control hardware to accomodate
these tests. A review of the images by columns will hopefully be
informative. My Tech Note #71 includes the MS-DOS programs and
C code I use for such reviews.

Herb Johnson




Herbert R. Johnson              http://pluto.njcc.com/~hjohnson
hjohnson@pluto.njcc.com         voice 609-771-1503, New Jersey USA
             amateur astronomer and astro-tour guide
           S-100 computer parts, manuals as "Dr. S-100"
    reseller of 68K Macs & accessories for your computing pleasure