Re: My problem or yours?/test

[Tom Droege <tdroege@veriomail.com>]

John and other interested parties,

OK, some of this is history and has been gone over before.

The CCD is read out by a prom coded hardware scanner.  Within certain 
limitations, I can read out anything.  I can skip rows or columns 
etc..  There are some practical limitations due to the size of the 
proms.  For example, I can read out selected rows, but the row format for 
rows that are read is always the same.  The present row format includes 15 
or 16 over scan pixels, all the good pixels, and some of the covered pixels 
at the beginning and end of the scan.

from a 27 July e-mail:

>I am reading 2064 pixels. Skip 16, read 2048, skip 16, read 16. If I have 
>it right, this gets all the covered pixels, all the good pixels, and 16 
>over scan pixels.

Note that there are 16 pre scan pixels which can be read out.  I skip them.

To answer your question about rows, I skip some rows at the beginning.  I 
would have to look at the prom code to see which rows are skipped.

What is actually being done has been gone over in earlier notes.  The 
attempt is to conserve memory space by skipping over rows and columns that 
are not interesting while picking out the good data.

In the past, I read out 2043 rows x 2037 columns.  The reason for these 
funny numbers was to stay within the 16 MB memory.  2042 x 2037 x 2 bytes 
per pixel x 2 images.

Note that the problem is that if I read out the 2048 x 2048 CCD pixels, 
then this fills the memory.  There is no room for over scan pixels.  So to 
get over scan pixels, I have to leave out some rows.  I had planned to 
change the vertical code to read out fewer than the present 2037 rows.  But 
I somehow thought that I did not need to change and that the memory would 
hold everything.  I just forgot to do the computation when I made the 
change.

When I reprogrammed the proms to get the over scan pixels, I forgot to 
change the vertical prom.  So now we are reading out 2064 rows x 2037 
columns x 2 bytes per pixel x 2 images.  This is more than 16 MBytes, so 
some of the data is lost.  I am not certain what the memory card does in 
this case.  It may overwrite the first rows, or it may just write into 
non-existent memory.  At the moment, I don't plan to fix this 
immediately.  Too many places to send proms when it all may change again.

We seem to be getting all the good area of the CCD.  Certainly this is true 
for the horizontal lines.  I think also for the vertical space.  But it is 
less clear.

OK, I am just one guy trying to do everything.  What I need is for some of 
you to work with me to get things right.  I really try to respond to anyone 
trying to sort something out.  My specialty is low level analog measuring 
circuits, grounds, low noise amplifiers and the like.  Code and format 
problems tend to make me faint and for my eyeballs to roll up into my 
forehead.  I keep hoping for someone to say "let me work with you to get 
this right".  Of course when you do, you will find that I am trying to do a 
lot of other things, so you have to be persistent.

Tom Droege



At 12:47 AM 10/28/01 -0400, you wrote:
>Tom Droege wrote:
> >
> > Chris and all,
> >
> > DS-0 gives me a 2064 x 2037 image.  That is what I expect.
> >
> > There are 2 or 3 "covered" lines at the top (W) of the image, and 4 or 5 at
> > the bottom (E).
> >
> > The overscan pixels are where they should be.  I count 15 of them and 6
> > covered at the far edge.  It is quite passible that I am one off in
> > figuring out the overscann pixels as I am not sure exactly which pixel I am
> > digitizing.  This depends on knowing how the pixels match the clock
> > phases.  I do not understand the process well enough to know which pixel is
> > actually being digitized.
> >
> > Does anyone want me to change what I am presently writing in the fits 
> header?
> >
> > Tom
> >
>Tom and all,
>
>  I'm no expert, and I've been hesitant to jump into this discussion on 
> that account,
>but I think maybe some beginner-level questions might be in order. At the 
>very least,
>I have the feeling I'm not the only person trying to figure these things out.
>So here goes:
>
>  Am I correct in thinking you're using the Fairchild CCD442A CCD? 
> According to
>the data sheet, this is a 2048x2048 array with the top 8 and bottom 8 rows,
>left 8 and right 8 columns permanently masked, leaving the center 2032x2032
>pixels as the live imaging area.
>
>  When your QBasic program calls "downfits" you tell it to read 2037 rows, 
> each
>row containing 2064 columns. I presume the 2064 represents 2048 actual 
>pixels and
>16 overscan pseudo-pixels. (Is this right?) I don't get the 2037 rows. If 
>the CCD
>has 2048 rows, and you only read 2037 of them, doesn't that leave the unread
>pixel charges in the bottom rows of the CCD for the next exposure? When I look
>at one of the later dark files (hira2157570.fits) I see that the bottom two or
>three rows are very light, and the pixels in the lower right corner of the 
>image
>area (from x=2029 to x=2049, y=1) are completely saturated at 32767. On the
>other hand, I see a very distinct 5-pixel dark strip at the top of these 
>images,
>suggesting that you're reading (some of) the masked rows, too. Hmmm.
>
>  Going back to the 2064 columns for a minute (I've looked at your 
> FLAT.BAS and at
>the downfits source and I don't see the answer to this), how does the 
>board know
>to read the overscan pixels before it clocks in the next row of real pixels?
>Is that just something wired in to the PROM code? Or is it contained in 
>one of those
>mystery variables that get passed to the Stamp?
>
>  The rest of these are questions for people who know about FITS headers. 
> (Where I haven't
>posed an explicit question, the question is "does this make any sense?") 
>To answer
>Tom's question, I think it's going to be necessary to change the headers 
>somehow,
>because even in my limited experience the IRAF CCD reduction tasks are not 
>happy
>with the current values. I think the fields involved are DATASEC (and its 
>equivalent
>IMAGESEC) and BIASSEC. (Possibly CCDSEC and TRIMSEC, but I haven't seen a 
>need for
>them yet.) I have already run afoul of DATASEC and BIASSEC in trying to 
>run "darkcombine",
>and I've found a way to fix them such that darkcombine no longer 
>complains, but I'm not
>sure I've fixed them the right way. In fact I'm rather sure I haven't.
>
>  DATASEC in the DS19 files is [17:2064, 1:2048]. The 2048 is clearly 
> wrong for
>an image 2064x2037. But my reading is that this field should describe the 
>central
>2032x2032 live-image area. If the file were 2064x2048, then I would guess that
>DATASEC should be [9:2040, 9:2040]. This would eliminate the 8-pixel 
>dark-masked
>rows and columns at the edges of the CCD, as well as the 16-pixel overscan 
>region.
>Because I don't understand the 2037 rows, though, I don't know what's the 
>right
>value here. Maybe [9:2040, 1:2032] - that would eliminate the dark strip 
>at the top,
>anyway.
>
>  BIASSEC is currently [10:15, 1:2048]. Again the 2048 should be 2037. But 
> this is
>supposed to be the overscan region, isn't it? In which case, don't we want 
>it to
>be [2049:2064, 1:2037] ?
>
>  And one last FITS-header question: what's the right thing to do with the 
> dark-masked
>regions of the CCD? Surely they contain information that could be 
>processed somehow,
>but I don't see any FITS keywords that seem appropriate.
>
>  I thought I had more questions than that, but no. I guess the thing that 
> has me most
>stuck is the 2037 rows.
>
>John McKendry