Contents

Michael Richmond richmond@astro.princeton.edu
Sept 03, 1996

I have made a comparison of the raw, instrumental magnitudes of stars in TASS images versus the magnitudes of the same stars in the standard Johnson-Cousins magnitude system. The data come from a set of images taken with the Vermont triplet on August 21, 1996. Please see TASS technical note 19,

http://www.astro.princeton.edu/~richmond/tass/technotes/tn0019.html

for a detailed description of the results. The note includes a few pictures, so it's not completely dull and boring :-)

A very brief summary of some of the results:

Overall, I'm quite happy with the results, but they did take me several days of work; I need to improve my methods of extracting magnitudes and matching fields.

Tom Droege droege@fnal.gov
Sept 4, 1996

Thank you Michael for a very nice technical note.

The results in TN 19 are very similar to my measurements. But I find that my I images are at least a magnitude brighter than the V images. Niether quite makes sense.

When I search an image and find a star, I get a measurement that would imply we should be more sensitive than what is actually achieved.

For example, in one image I identified a Mag 7.62 star. A 4x4 array around the star contained 860,000 ADU above the mean value as determined by taking the mean value of another 4x4 array with no visible stars. The mean value for this area was 8000 ADU. Using 2.5e- per adu this is 20,000 e-. the square root of 20,000 is 141 e- which compared quite closely to sky level as determined by the rms value of the blank sky measurements. 860,000 ADU is 2,150,000 e-. 2150000/141=15248 as the signal to noise ratio. This is mag 10.45. Adding to 7.62 gives a magnitude for the noise of 18.08.

Note that my "I" sky is 141 e- compared to Michael's 62 (mean of 5 measurements in table 1). My measurements for the cameras gave dark noise sigmas of 30 e- or so. Looking at Michael's V sky ADU one gets a mean value of 206 ADU from table 1. This is 515 e- and should give an rms value of 23 e-. Michael shows 16 ADU or 40 e- rms. However, if we add the 30 e- expected CCD noise to the 23e- expected noise from the sky background in quadrature we get 38 e-. This is close enough for those of us in government work. So unexpectedly, Michael has found a location for the tass cameras sufficiently dark that the camera noise is a factor. One question is whether or not the camera noise can be reduced. If I disconnect the CCD from the electronics, I get a noise level of 2 ADU rms. So as far as I am concerned, the noise comes out of the KAF-0400. Kodak quotes 13-20 e- as their noise figure. But I have not been able to get it.

Now Michael used 5x skysigma as his cut off and finds stars only down to 13.4. A ratio of 5 is mag 1.74. Subtracted from 18.08 gives a threshold for finding a star of 16.3 under Michael's conditions. There is a missing mag 3 in sensitivity somewhere.

I am not surprised. Nothing is quite as good as one would hope. I suspect that if we plot star magnitude vs ADU found for a star we will not get a straight line (on a log plot). We will instead see something like below: 

    |
    |
    |      A
    |**************
log |                 *
ADU |                    *
    |                       *  B
    |                          *
    |                             *
    |                                *
    |                                  *
    |                                   *
    |                                    * C
    |                                     *
    | 
    |
    ---------------------------------------------------
                  Magnitude

During the B part of the curve, everything is as we expect. The log ADU is proportional to the magnitude. During the A section of the curve, charge is lost through saturation. I attempted to scale the Mark III so that pixel saturation (85000 electrons) occurred at half full scale. With a dark end at about -24000 counts for a typical Mark III channel, and full scale at 32767 the scale factor of 2.5 e- per ADU gives a full scale of 142,000 e-. I did not expect to get this large a signal out of the KAF-0400 but it is certainly possible. The output amplifier capicator can hold 4x the pixel full scale or 340,000 e-. Everyone is advised that it requires at least a two resistor change to change the gain.

We notice that bright stars always give full scale ADC readings. I probably should have set the gain lower so that the ADC never saturated. I was worried about measuring the dark end with more bins for a better noise determination.

The result is loss of accuracy for bright stars since charge is probably conserved in the CCD and we would bet better answers if the ADC did not saturate. The limitations of ASCII art prevent me from speculating what the curve might really look like at A. It is surely more complicated than the simple sharp cut off that I have shown.

If I had it to do over again I might set the gain differently since we are not in trouble as far as resolution goes. Still the saturated ADC signals seem to indicate that each pixel really holds more than the quoted 85,000 e-. Someone told me this was only the linear range and that more charge could be held.

The curve at C is another matter. Here we don't find enough stars, even though I suspect the charge is there to be found. I suspect the real reason is that the search algorithm demands that some pixel stick up a lot from the mean background. A test of this would be to take runs with a range of focus settings. The break at C should occur earlier with a poor focus.

This is one reason why I have been so interested in a better focus tool. Thank you Norman.

Michael Richmond richmond@astro.princeton.edu
Sept 5, 1996

Tom Droege yesterday posted a note responding to some aspects of my report of observations in Vermont. I'd like to comment on some of Tom's comments -- discussing signal-to-noise ratios and overall quantum efficiency. 

> For example, in one image I identified a Mag 7.62 star.  A 4x4
> array around the star contained 860,000 ADU above the mean value
> as determined by taking the mean value of another 4x4 array with no
> visible stars.  The mean value for this area was 8000 ADU.  Using
> 2.5e- per adu this is 20,000 e-.  the square root of 20,000 is 
> 141 e- which compared quite closely to sky level as determined 
> by the rms value of the blank sky measurements.  860,000 ADU is
> 2,150,000 e-.  2150000/141=15248 as the signal to noise ratio.  
> This is mag 10.45.  Adding to 7.62 gives a magnitude for the noise
> of 18.08.

This isn't quite the correct way to measure signal-to-noise. Let me review the process. See articles in ""Astronomical CCD observing and reduction techniques", edited by Steve B. Howell, for more details.

Suppose that we have a CCD image showing a star and some blank sky. We can place an aperture over the star and measure the sum of counts inside it, then place an aperture somewhere far from the star and measure the "blank sky" signal. Let's define 

          n = number of pixels inside the aperture
          S = sum of counts inside aperture centered on star
          K = sum of counts inside aperture placed in blank sky

Compute 

          s = sum of counts from star, MINUS sum of counts from sky
We also need to know 
          g = gain, electrons per ADU 
          R = readout noise of CCD, in electrons
Now, the equation describing signal-to-noise ratio inside the aperture centered on the star is (we express all terms in units of electrons) 
      Signal               s*g
      ------ = ---------------------------------
      Noise     sqrt(n*R*R + s*g + K*g)
Here, the numerator is just the number of electrons _from the star_ we detect; that's the signal. The denominator has three terms inside the square root: 
          n*R*R = readout noise contribution
          s*g   = noise contributed by photons from the star itself
                      (this is the term Tom neglected in his computation)
          K*g   = noise contributed by photons from the sky
Looking at a sample star from a few of my images, I calculate the following very signal-to-noise ratios directly from the data: 
        V-band image: radius=2.0 pix      star V =  8.857    S/N = 320
                                                   10.434    S/N = 120

        I-band image: radius=2.8 pix      star I =  9.336    S/N = 180

Now, I can _extrapolate_, based on the number of electrons detected from each star, to the number which _would_ be detected for fainter stars. That allows me to make the following table of _expected_ S/N ratios: 

        V-band image (extrapolating from V=8.857 star)  V = 13.0  S/N = 24
                                                            14.0        11
                                                            15.0         4
                     (extrapolating from V=10.434 star) V = 13.0  S/N = 16
                                                            14.0         7
                                                            15.0         3

        I-band image (extrapolating from I=9.336 star)  I = 12.0  S/N = 19
                                                            13.0         8
                                                            14.0         3

Recall from Technical Note 19 that I was 

        - able to measure properties of stars to V=13.7, I=12.9
               (down to S/N = 10, approx)
        - able to see stars as faint as V=14.5, I=13.4
               (down to S/N = 5, approx)

Those limits, S/N = 10 for measurement (to about 10%), and S/N = 5 for visibility, strike me as perfectly reasonable. Therefore, I disagree with Tom's statement that "there's a missing mag 3 in sensitivity somewhere." I think we are doing fine. 

> ....  So unexpectedly, Michael has found a location
> for the tass cameras sufficiently dark that the camera noise is 
> a factor.

Well, this was exactly why I moved the camera to Vermont -- I was hoping to find a "dark" site. Clearly, in the V-band, we've reached the practical limits: at a darker site, the camera would be limited by readout noise, and not take advantage of the lower sky background. Note that in the I-band, however, I'm still very much dominated by sky noise. 

> We notice that bright stars always give full scale ADC readings.  I 
> probably should have set the gain lower so that the ADC never saturated.  
> I was worried about measuring the dark end with more bins for a better 
> noise determination ... If I had it to do over again I might set the gain
> differently ...

I agree. Looking at Table 1 of TN 19, one can see that the standard deviation of pixels in the "blank sky" ranges from 16 to 32 or so --- that's 4 or 5 bits (of the 16 bits per pixel) which are being devoted to measuring random noise. That leaves only 11-12 bits for stuff _above_ the noise level, which is 2^12 = 4096 = 9 magnitudes of dynamic range at most. The actual difference between the brightest and faintest stars I could measure was about 13.7-7.9 = 5.8 mag in the V-band.

A general rule of thumb is to leave 3-4 bits for the noise, so, indeed, if Michael J. Fox came by your basement with a time machine, Tom, you might want to set the gain higher by a factor of 2 or so -- that is, set it for maybe 5 electrons/ADU instead of 2.5. But this is no big deal. 

> ... I suspect the real reason [that we don't see very faint stars]
> is that the search algorithm demands that some pixel stick up a lot from 
> the mean background.

Yes, I agree that a better search algorithm would help a bit -- but it's not going to gain much. The S/N calculations above show that objects at V=15.0 are pretty hopeless.

Now, a brief note on overall quantum efficiency. I need to make real measurements of the gain and readout noise of each of my chips the next time I use the camera ... but ... 

    - using values of 2.5 electrons/ADU and 30 electrons RMS, as Tom suggests
    - assuming that clear aperture of each lens was 4.8 cm
    - adding up the detected counts inside an aperture of radius 10 pixels
           (= 140 arcsec)
    - assuming that the extinction is 0.18 mag/airmass in V, 0.07 in I
I calculated the following overall throughput (or quantum efficiencies) for the three cameras: 
     V-band: 10 percent
     I-band: 11 percent (West), 6 percent (East)

Astute readers probably noticed that TN 19 showed something strange in the East camera: it had _lower_ values for sky counts per pixel, despite much _brighter_ sky conditions.

Compare these with the values of Kodak KAF 0400L QE which Tom posted in TN 16: at 5500 Angstroms (V-band), 24 percent. At 8000 Angstroms (I-band), 17 percent.

I suspect the filters don't reach 100 percent transmission in the middle of the passband -- Tom, can you check the spec sheets? It's my experience that the overall QE of imaging systems is about half that of the detector alone, so I'm not really surprised by these numbers....

Enough for now.

Tom Droege droege@fnal.gov
Sept 5, 1996

First, thanks to Michael Richmond for a very nice write up on noise and detection limits. I will study it carefully. Sigh! I was hoping for another factor of 10 somewhere.

The V filter has a peak response fo 82%. It looks like a half sine wave with FWHM of 97 nm. The FWHM is between 488 and 585 nm.

The I filter has a peak response of 88%. It has a squared off top. The FWHM is 242 nm. The FWHM is measured between 728 and 970 nm. Note that the high end is a guess since the plot stops at 900 nm where the response is 70%.

My data has always indicated much less sensitivity using the V filter. About 2 magnitudes. But I may be fooled by appearances. It is clear that the I filter produces fuzzy images which may just look brighter. The V filter produces much sharper images. But there is not much difference in Norman's PSF to explain why the V images look sharper.

The V filter seems to produce a darker sky background. To me it seems like it is something (like skuz in the atmosphere arond Chicago) blocking the transmission rather than the sky really being darker in the V. Note that my I sky measurement is 18.5 which is very close to Michael's number.

I guess I have a lot to learn about taking these measurements. I feel some pressure to gain an understanding because I am now making decisions for the Mark IV. I know it is always too soon to make decisions, but one can only move ahead by doing something.

Note that we are not yet sky limited. One can consider what happens when you put a shorter focal length on the Mark III.

Suppose we were to go to a 90mm lens. Suppose it is a 90 mm f/2.5 which I think I remember seeing in Shutterbug. This would have 1/2 the glass area and so we would lose by a factor of 2. The exposure time in drift scan now goes up by a factor of 1.5. So we gain most of the sensitivity back and lose only 0.3 mag in sensitivity. We in sky covered to 4.4 degrees from 2.9 degrees. The sky background increases by a factor of 2.25. In my case one measurement was 8000 out of 50,000 useful range. This lens would increase this to 36% of the available dynamic range from 16% that is used up now. The noise also increases by sqrt of 2.25 or we lose another mag.44 in S/N. Looking at star distributions, it would seem that this different configuration measures about the same number of stars. We cover more area, but lose some of the fainter stars.

I keep doing these calculations and have come to the conclusion that there is a nearly constant cost to measure a star. There are other factors like computing time and field crowding that push in the same direction. Michael says we will be able to measure about 50,000 stars. I pretty much agree from my measurements. It then looks like stars cost of order $1.00 (in hardware costs) to measure. (We could cut this down to $0.05 by pointing each tass telescope at a different field.) I keep searching for more cost effective arrangements, but do not find that one configureation is significantly different from another. This includes mirrors to 36" etc..

Hmmm! If we can just sell stars for $8.95 we could have something going!

Norman Molhant molhant@ERE.UMontreal.CA
Sept 5, 1996

Serial #0 has always been complaining that its coolant (50/50 Prestone/Water) was too warm so that it couldn't get the freshness it wanted to squelch most of its dark current. It typically displayed CCD temperatures around -3.5 C, with liquid temperatures near 33.5 C, i.e.: much warmer than its siblings. After considering various options, I built a cooler for its coolant and started using it today. Basically, it is a tube within a tube: the inner tube is copper, with a 0.25 inch external diameter, kept at the center of the outer tube by copper spacers placed a foot apart; the outer tube is PVC, with an outer diameter of 0.75 inch, surrounded by 0.5 inch of yellow fiberglass (as insulation) and a sheet of aluminized paper reinforced with glass fibers (as outer shell). The coolant for serial #0 flows in one direction inside the copper tube, while cold water from my well flows in the opposite direction around it (i.e.: inside the PVC tube). As you can see from my description, the thing is designed along the same lines as the glass vapour condensers one sees in chemical labs around the world, but oversized: this coolant cooler is 7.5 feet long! Does it make cooler coolant? You bet! With only a trickle of water flowing through it (0.5 liters per minute or about 8 gallons per hour), it cools the coolant by just about 5 C, thus giving CCD temperatures around -8.5 C and liquid temperatures near 28.5 C. Surprisingly enough, doubling the flow of water to 1 liter per minute does nearly double the temperature reduction, with CCD temp. around -13 C and liquid temp. near 24 Celsius.

Not bad indeed! Serial #0 is quite happy with its cooler coolant now, but still says it would prefer to regulate its CCD temperature (which it can't, lacking the corresponding circuitry). Will that TASS camera ever stop complaining? Spoiled brat, I say! ;^)

Anyway, a 37 C difference between liquid (or body) and CCD is not too bad for this camera, even if it is not the 40 C reported by other serial numbers.

If somebody wants to build such a cooler, just tell me: I'll make drawings available for downloading then (I won't do that right away, as the current set of drawings are just hand-drawn sketches on stock 8.5 by 11 copy paper).

Tom Droege droege@fnal.gov
Sept 8, 1996

I am not an early riser. Each time I run it is a challange to get to the telescope before the sun. Two days ago, due to some problems with the construction project, I just forgot and went off to work without closing up the camera.

This is the wrong time of year to do that, as I think the sun goes right across the equator. Luckily, there were some clouds.

So last night, I ran the camera to see if it had survived. #1 and #2 look fine. #0 has a dark band down one side that is just about the width of the sun - 1/2 degree or so. I can still see stars in this area, so it is not yet clear that the chip has been damaged. It might just be that the dark current has been reduced.

In any case, I put this up as a warning that this is the time of the year when one must be especially careful about putting the lens caps on.

Tom Droege droege@fnal.gov
Sept 11, 1996

I have been running various versions of Norman's software. It now really works very nicely.

The real time display is great! I can just sit there with my Uranometra 2000.0, look at the RA display, turn to the page, and watch the stars go by. It is now very easy to match the stars to the star chart. (There is a small question of what time is to the hour.)

The on line focus aid also works great! I now have as good a focus as I think possible with these optics. I have blown up the images with a program provided by Glenn Gombert, and individual stars now look as good as I can expect. There still may be a little smear along the drift scan direction. I have not been able to do better than 2 pixels. The other directions are down to 1.5 pixels typical. I think we do not really want them much sharper than 2 pixels???

I now have several nights worth of data with the new set up. A few hundred Mb.

Both Norman and I wonder if anyone else is alive out there.

Hello? Hello? Has anyone else turned on their camera?

What I really suspect is that a few have turned on their cameras and now realize how much work it is going to be. Well, it will be fun work. If we all share it then it will not be so bad for anyone.

I urge you all to read the Bohdan Paczynski paper that Michael has put up on the reference section of the tass home page. It will tell you all why this might be worth while.

Mike Gutzwiller Michael_Gutzwiller_at_CMCEF020@maillink.cmic.com
Sept 11, 1996 

>I have been running various versions of Norman's software.
>It now really works very nicely.

I too like the latest version. Not only is it good for data acquisition but it produces files which have all the right data for analysis. 

>The on line focus aid also works great!  I now have as good
>a focus as I think possible with these optics.  I have blown
>up the images with a program provided by Glenn Gombert, and 
>individual stars now look as good as I can expect.  There 
>still may be a little smear along the drift scan direction.
>I have not been able to do better than 2 pixels.  The other
>directions are down to 1.5 pixels typical.  I think we do 
>not really want them much sharper than 2 pixels???

Correct. If the stars get too small then they become indistinguishable from noise such as cosmic rays, etc. Also if they are too sharp they will saturate the pixel too quickly making photometry much more difficult. Astrometry also requires the star cover more than one pixel. My guess is that a FWHM of about 3 pixels is ideal. 

>I now have several nights worth of data with the new set 
>up.  A few hundred Mb.  
>
>Both Norman and I wonder if anyone else is alive out there.  
>
>Hello?  Hello?  Has anyone else turned on their camera?
>

So far I've only taken "test" data of up to three hours, I haven't yet run the whole night. This is because I've been both calibrating and creating calibration tools and analysis tools. I now have tools for generating dark vectors and flat vectors and am currently testing the PSF generation code.

I will put the latest versions of the dark and flat vector calibration tools on my web site and hope to have a star list generation tool in a week or so. Then the data collection can begin in earnest.

Nick Beser beser@aplcomm.jhuapl.edu
Sept 11, 1996 

> Except for Tom, I'm getting no feedback on this program.  Is it possible that
> nobody (except Tom and me) is using it?

We will be using it, unfortunately, we are still building the observatory. We should have news on the schedule soon.

Ron Wickersham rjw@crl.com
Sept 11, 1996

I am able to run earlier versions of Norman's software with good results, but the video board didn't like it since the configurable options went into the code.

Norman kindly made suggestions to handle the problem by editing in special changes in the source. I have obtained Borland C++ compiler but not made it work. I'm going to get some local help soon to get me started with the compiler, as i am not C literate yet.

A more up-to-date video card is coming this weekend, so the compiling probably won't be necessary and I will use the same code as everyone else. (I should have done this right off!) 

> The on line focus aid also works great!  I now have as good
> a focus as I think possible with these optics.  I have blown
> up the images with a program provided by Glenn Gombert, and 
> individual stars now look as good as I can expect.  There 
> still may be a little smear along the drift scan direction.
> I have not been able to do better than 2 pixels.  The other
> directions are down to 1.5 pixels typical.  I think we do 
> not really want them much sharper than 2 pixels???
I am looking forward to seeing the focus aid working here. I have the #1 camera focused and aligned pretty good, but having trouble with 0 and 2, and switching the filters back and forth means long times to get back in business. 
> Both Norman and I wonder if anyone else is alive out there.  
> 
> Hello?  Hello?  Has anyone else turned on their camera?
> 
> What I really suspect is that a few have turned on their 
> cameras and now realize how much work it is going to be.  
> Well, it will be fun work.  If we all share it then it
> will not be so bad for anyone.
I had an intermittent solder joint in the TEC regulator circuit (the 10 K resistor to pin 5 of IC13) that is now fixed. The regulator now is very stable and I'm getting good results on camera #1.

Cameras 0 and 2 have always shown great variations that I now know to be temperature variations. Now, the TEC modules that are always on are not drawing any current in these cameras, but the one in camera #1 is doing fine.

Focusing 0 and 2 has been a lot harder than 1. I'm looking forward to the focus software making this easier.

I now have a zip drive for storing data. Also have an arrangement with Sonoma State Univ. to store data there, making it available with better connections than I have now.

Tom Droege droege@FNAL.GOV
Sept 11, 1996 

> I had an intermittent solder joint in the TEC regulator circuit (the 10 K 
> resistor to pin 5 of IC13) that is now fixed. The regulator now is very 
> stable and I'm getting good results on camera #1. 
>
> Cameras 0 and 2 have always shown great variations that I now know to be 
> temperature variations. Now, the TEC modules that are always on are not 
> drawing any current in these cameras, but the one in camera #1 is doing fine.
Hmmm! I am always glad to help on this sort of problem. At about 10 volts or so the camera should draw about 2 amps for each first stage TEC plus from 0 to 3 amps for the second stage. The first thing to check is the connectors. There are *dual* pins on the first stage because it is high current. But you can check the connectors to make sure the push in pins have not come out of their sockets. There is an inspection window for this purpose.

Don't hesitate to send a unit back to me that is giving trouble. I can probably fix it faster than you can. This goes for everyone. On the other hand, some of you will just want to fix the problems. That is OK with me.

Tom Droege droege@FNAL.GOV
Sept 12, 1996

You can find Tom's posting on the Design of the Mark IV Camera by reading Technical Note 20.

Herb Johnson hjohnson@pluto.njcc.com
Sept 12, 1996

I'm mostly "lurking" on the TASS project, notwithstanding my comments and my recent assistance (very, very much appreciated! --MWR) to Michael Richmond at Princeton on his camera, now at Vermont. The TASS project is an inspiration to me and I follow the conversation. I'm considering a related project but it has lower priority than a list of projects that I'm working through. Notible among these is a 400 MHz radio telescope that I've built at the request of a regional amateur astronomy consortium. My lack of equipment has prolonged my tuning and adjusting of this instrument, but I expect to end my part in this project soon. [Radio astronomy is very tough: you can't "see" the results!]

I've offered to accept TASS equipment for a single camera, for a drift field telescope, if and when such becomes available. The recent features added to the new TASS software will make it easier to adapt the TASS camera to this application. Perhaps in the fall or winter I'll have the time AND the equipment will be in hand. If someone has a loose KAD0400 device, I'd be encouraged.

Tom Droege droege@fnal.gov
Sept 12, 1996

The amateur sky survey is a scheme to measure a large number of stars from a number of locations. We might also find comets and asteroids, nova and the like. Read about us at :

http://www.astro.princeton.edu/~richmond/tass/tass.html

The standard tass device is a triplet of ccd cameras. Each is built around the Kodak KAF-0400 and operates in drift scan mode. The cameras are spaced by 15 degrees in RA to provide three measurements of each object in the sky as it drifts across the fixed cameras. The 135 mm focal length f/2.8 camera lenses used determine a 14 arc second square pixel and thus a 470 second equivalent exposure. Each camera scans a 3 degree wide path in the sky.

There are now 7 tass telescopes units in operation around the US and Canada. Since most of them are triplets, a total of 19 cameras can generate 115 Mb of data per hour of operation. Of course they will not all find clear sky at the same time.

It is a month now since I have posted one of these news notes. One would hope that there would be more to report.

The on line program is now up and running. I spent the last couple of weeks getting new versions of software written by Norman Molhant in Canada off a relay location and testing it on my camera in Chicago. Never have I had a software project go so well. Over several weeks, Norman was producing a new version almost every day. I would find the bugs and Norman would fix them. I would also request features and Norman would add them. I have never received such software support, even when I was paying a programming group over a Million a year in wages. It just shows how people can work together when there is mutual interest.

We now have a very nice on line display. A full screen display for one channel (there is also a three channel display) shows about 2 by 3 degrees of sky in real time. One can sit there with Uranometra 2000.0, note the RA displayed above the star field, and match the stars up to the page in the star atlas as they come by. Of course the tass cameras see a lot more stars than are in the atlas.

There are several new technical notes on the home page. There is also a very nice paper on why we might do all this in the reference section. Michael Richmond has done a lot of good work on the data in TN# 19. Take a look at this one if you are interested in what our problems will be.

All in all, the project is making expected progress. We are not quite yet making real star measurements, but soon!

Nick Beser beser@aplcomm.jhuapl.edu
Sept 13, 1996

I was just notified by the Assistant Director of the lab, the observatory is now official. That means we will be setting up a home page accessable outside the lab, and we will be making the mount/cooling and control a permanent installation. The housing for the camera is almost complete (I expect it to finish by sometime next week.) A project meeting is schedule for noon time next Wednesday.

We pulled aside two computers (One computer we have now, and a better one has been promised). I will report on the schedule for testing after our meeting.

Can I get a status update on porting the tm3get program to linux? I would like to run the httpd server and the telescope control software concurrently (giving priority to the telescope). Do you think that will be possible? An alternative would be to rig a serial interface for the control software, and run that from a seperate computer.

Tim Hager thager@pcnet.com
Sept 13, 1996

At 06:46 PM 9/11/96 -0600, Tom Droege wrote: 

> The camera will be approximately a one foot cube.  It will 
> have a glass top, and will be designed to sit out in the elements 
> with no other protection.  The optics will be mounted on a polar 
> axis.  It will look straight up.
As an amateur astronomer who has listened many a night to the "music" of hot air blowers working away on the dew that has formed on Schmidt-Cassegrain corrector plates, the first thought that occured to me is that some provision will probably have to be made to suppress the dew that will almost surely form on the Mark IV windows as they stare straight up all night. Or, is the heat generated from the eletronics sufficient to keep the surface of the window above the dew point?

I assume that currently, since the first cameras are staring at the equator, their "outhouse" enclosures provide enough protection (along with dew caps?) to keep the optics dew free. It will be another situation with a one foot square piece of glass radiating its heat straight up and out into space.

As an aside, like Herb Johnson, I lurk on the list for inspiration and a passing interest in how the TASS project will do in discovering new variable stars since that is my field of astronomical interest. Since I have neither the hardware nor the software expertise to contribute in those areas, all I can do is try to offer my moral support and interject the occasional hopefully useful observation as I have tried to do above. Keep up the good work Tom & others!

Chris Albertson Chris_J_Albertson@ccmail.orl.mmc.com
Sept 14, 1996

Maybe this would work. Depends on how fast your camera control computer is. Put Linux on it's own machine and set it up as a file server for the DOS based camera controller. You will need Ethernet cards for both machines. While the DOS machine can be taught about NFS. I find it easyer to let DOS speak it's native Microsoft SMB protocol and teach SMB to Linux. SAMBA is the name of the UNIX SMB server. It is free, easy to set up and works well. I have things set up so that when someone logs into a Windows 95 or NT PC thier UNIX home directory appears to then as drive E:. The camera controler could simply write its files to drive E:.

I have SAMBA running on both Linux and on a Sun SPARC workstation. Now here is an idea -- If you already have a Sun on the Internet someplace in your lab let it act as a file server to the tass camera controller and all the tass files appear on the net.

Chris Albertson Chris_J_Albertson@ccmail.orl.mmc.com
Sept 14, 1996

I think you are right about dew. I have a 10" SCT. Even on good nights I use a resistive heater strip wrapped around the outside of the corrector plate cell. The idea is to keep the glass at about the temperature of the air but no higher. Where I live there is no frost problem as it never gets that cold. Looks like a heater is required and a system to control it. One more thing for that little microcontroller to handle. An other thing about that glass window, depending on the refractive index of the glass there will be between 4% and 10% reflection at each of the air/glass surfaces. With two sides this gives a net loss of 8% ~ 19%. Optical coating can help by a factor between two and ten but a coated optical window 12" square will cost more then the 50mm camera lens. An automatic door may be better. While on the subject of 50mm lenses, I seem to remember flair was a problem with the Mark III. I suspect this was due in large part to a poor quality, older design lens. A lens shade is less effective with a wider lens but then new lenses are much, much better. I have tried to make a few new Nikon and Canon lenses flair by including the sun in the image frame -- no luck, new multicoated, fixed focal length lenses are very good. Canon USM lenses also contain built-in focus motors. These could be handly if remote controled focus is required. Using a standard lens mount rather then epoxie would allow the lens to be replaced with a longer one if desired. I could even see Tom requiring anyone wanting a "loaner system" to supply a lens. Someone with some extra $$ could use the 50mm f/1.2 lens or switch to a telephoto to collect higher resolution data on some object discovered with the 50mm. One way to get a Canon AF lens mount is to buy a 25mm macro extension tube.

Tom Droege droege@fnal.gov
Sept 14, 1996

I often get mail saying "what can I do to help". OK, here is something.

If I don't change the file length, Norman's program produces of order a hundred files in an evenings operation. Longer files would reduce this, but for the moment it is convenient to ship the files around on a floppy disk. Camera operators should as a group decide what file length makes sense.

In any case, I took 100 files or so last night. There is something interesting on one of them. One thing I would now like to do is to look at the tempreature data on the file and see at what time it went out of regulation. I know it did, just not when. It probably does not affect the interesting object, but I want to check anyway.

What I would like is a quick review program. One would give it the name of the first file in a sequence. It would then read the first file and produce a plot of the measured items vs time through the file. While at it, it might as well plot the mean value of the file line vs time as a cloud watch, or any better cloud detection scheme that the writer can think up. After the first file plot is put up, a key stroke would produce the next file in the sequence.

Experts may tell me that I don't need this or that there is a better way. OK I am willing to listen. Meanwhile does any one want to take on this project? I can put a few files and a .TM3 log file on storm to aid the development. Actually, it would be best if the program just read the .TM3 file for the review process. That would save typing in those long file names.

How about this for a project for someone that is not now doing anything?

Glenn Gombert ggombert@erinet.com
Sept 14, 1996

From my perspecive currently using Patric Wallaces astromerty routines to calulate the RA & DEC positions of each star / object that is detected in the image it would be well to keep the file size somewhere between 2000-4000 scan lines long so as not to lose too much resolution on the astrometric computational accuracy on each image frame. I think that going much beyond 4000 scan lines will start to lose accurcy in the computation at the edges of the field.

Tom Droege droege@fnal.gov
Sept 14, 1996

This is really a generic question. Should we develop a set of special purpose tools to do the things we will have to do in production, or should we try to use generic tools? I think the answer is not so clear. I know how the Unix gurus operate, but most tass operators are not full time at a Unix terminal type people. What does everyone think?

Chris Albertson Chris_J_Albertson@ccmail.orl.mmc.com
Sept 15, 1996

I think the question comes down to which is easier,

I do software for a living, I know how hard it is. I am not about to write something when I know it would not be half as good as something I already have up and running on my computer.

My approach is to do #1. If that does not work, do #1 again but try harder. If that still does not work do the minimum amount of #2. 

         * - * - * - * - * - * Special offer  * - * - * - * - * - *
Now, a special offer for anyone working  with TASS data.  
(I guess this includes Tom)  I'll help set up a system.  
The logistics may be hard.  Advice via e-mail 
is easy but if someone wanted me to configure a turn-key system 
I could do that too.  I could build a Linux/IRAF based system that 
boots direct to a graphical window/mouse system (with documentation 
on the local hard disk and accessable via Netscape) when the power 
is applied.  So there goes any excuse that this is hard to set up.  
Easy to use too, things can be set up so that an end user never 
sees a command prompt, just icons to double click, drap and drop.
         * - * - * - * - * - * Special offer  * - * - * - * - * - *

There is another issue. The roll your own approach never ends. You write a program to plot some relationship in your data then later you want a histogram, next a new way to display images in pseudo color, The list never ends. On the other hand if you invest a couple weeks in learning IRAF, Midas or something like it that's it, a one time effort, now you can do just about anything.

Another thing about these big systems, they are supported. They are maintained by a staff of full time programmers. The guy who wrote it does not go away. There are also hundreds of other users, mail lists, USNET groups, and user conferences. There is even a help line with a real person on the other end of the phone. All paid for with your tax dollars. Years from now there will still be people you can ask for help.

These systems are useable at several levels. With IRAF, one can:

Nick Beser beser@aplcomm.JHUAPL.EDU
Sept 15, 1996 

> Maybe this would work.  Depends on how fast your camera control 
> computer is.  Put Linux on it's own machine and set it up as a 
> file server for the DOS based camera controller.  
> You will need Ethernet cards for both machines.  While the 
> DOS machine can be taught about NFS.  I find it easyer to let DOS speak it's 
> native Microsoft SMB protocol and teach SMB to Linux.  
> SAMBA is the name of the UNIX SMB server.  It is free, easy 
> to set up and works well.  I have things set 
> up so that when someone logs into a Windows 95 or NT PC thier UNIX home 
> directory appears to then as drive E:.  
> The camera controler could simply write its files to drive E:.

Thats a good idea. I use samba at home with the PC's and the sparc station. The problem is that control of the telescope is still based on the PC and not under control of the httpd server. It may be possible to strip all of the VGA code out of the program, and have the program generate snap shots that can be displayed on the shared disk. The serial link can update the clock, and R.A. readout.

An ideal setup would allow the httpd server the luxury of bogging down with multiple uses, but still allow the PC running the telescope the ability to continue collecting data at the expense of lossing a snap shot of the data.

Tom Droege droege@fnal.gov
Sept 15, 1996

OK, I agree with Chris that a packaged program like IRAF (running under windows, I hope) is the right way to do the one of a kind project. There is still the production problem. Unless we get the production code from some project like Sloan, the commercial stuff I have seen is more designed to look at one thing than to run a production line. It seems to require a three armed man who constantly opens windows and types arcane things.

I envision something that say reads the log file produced by Norman's on line program, and generats a batch file. This file then feeds the data files to a succession of "commercial" modules. While I agree that we won't want to muck with the "commercial" modules (like a star finding routing, star matching routine, bad data finding routine, etc..) we will want to muck with the sequence of using the modules.

BTW, are there schemes with windows (the eqivalent of the DOS batch file) that allow feeding a windows program a bunch of mouse clicks to perform a sequence of functions with an existing program?

What think you all?

Norman Molhant molhant@ERE.UMontreal.CA
Sept 16, 1996

Two subjects for this message:

Data acquisition + net access

In a few weeks, there will be a Linux port of the data acquisition program, that will probably solve all your problems with making remote access available. (It certainly will if you tell me explicitely *what* you want the Linux version to do. If you don't, it will do what *I* think is really necessary - and you might find that quite different from what you want) Things that won't change: FITS image file format, tass.rc configuration file format.

Chris Albertson wrote: 

>> Maybe this would work.  Depends on how fast your camera control computer is.
>> Put Linux on it's own machine and set it up as a file server for the DOS
>> based camera controller.  You will need Ethernet cards for both machines.

Might work if the DOS box is fast enough. Will not work if the DOS file system uses a file cache for access to the network file system. 

>> While the DOS machine can be taught about NFS.  I find it easyer to let DOS
>> speak it's native Microsoft SMB protocol and teach SMB to Linux.  SAMBA is
>> the name of the UNIX SMB server.  It is free, easy to set up and works well.
>> I have things set up so that when someone logs into a Windows 95 or NT PC
>> their UNIX home directory appears to then as drive E:.  The camera controller
>> could simply write its files to drive E:.

Your approach is sound, Chris. The only remaining point is: how to control the data acquisition program through the network? Nick Beser then replied: 

> Thats a good idea. I use samba at home with the PC's and the sparc 
> station. The problem is that control of the telescope is still based on 
> the PC and not under control of the httpd server. It may be possible to 
> strip all of the VGA code out of the program, and have the program 
> generate snap shots that can be displayed on the shared disk. The serial 
> link can update the clock, and R.A. readout.

Feasible. The approach I had in mind would have used a fast (14.400 Bps or faster) serial link to allow both remote control and remote viewing of the VGA display. I have used that technique with success for one of my customer's projects. That's why I said I could program that in 2 days. 

> An ideal setup would allow the httpd server the luxury of bogging down 
> with multiple uses, but still allow the PC running the telescope the 
> ability to continue collecting data at the expense of lossing a snap shot 
> of the data.

Yeah. Simpler yet to use the Linux version of tm3get when it will be available and suffer the misery of local control with the DOS version till then, I think.

Use of "standard" programs or custom ones to process TASS data.

Chris's job is to develop software, so he knows the playground fairly well. He thinks we should stick with existing "standard" programs like MIDAS or IRAS that run perfectly well on Linux X-windows boxes. And his arguments are indeed excellent. Why re-invent the wheel when we have a perfectly round one available? I could not agree more, but...

Tom's Linux box has been transmogrified into a Win'95 box, for the usual reason: as an OS, Linux is a programmer's dream, hence a user's nightmare: it requires that either one puts one's hands in the bloody guts of the beast (i.e.: the system internals) or one finds somebody else to do that gory work. By the way, that's not a problem limited to Linux, it is the standard Unix way of doing things. So, "standard" Unix programs are not what Tom is after.

I happen to also earn my keep writing software. Alone in my basement, with my electronics lab to my left, my chemistry lab still in boxes, my optics lab half uncrated and all my software books and periodicals at my fingertips. I write software for Unix, DOS, Mac-OS, AmigaDOS, Windows 3.11 and various stand-alone or embedded computers, so I should indeed know that playground fairly well too.

Surprisingly enough, my opinion is that we should write specialised software for the specialized work we do.

I'm a bit busy with the Linux data acquisition program (and my customer's projects) right now, but I have nethertheless started development on a few specialized small tools to process TASS data. One is an "image sharpener" that deconvolves the PSF from the image data at a fairly high speed, for instance. That particular program extracts from TASS raw images a smooth background image, a noiseless sharpened image (with 0 sky background), a noise image (mean 0, sigma as the noise in the original image) and a blurred reconstructed image that approximates the original image to better than 1% eveywhere. That tool could be used on TASS images before extracting star coordinates and object tracks. The same tool also does all the data reduction, i.e.: dark line substraction and pixel gain correction. The whole program is less than 100 Kbytes long, it is easy to understand and pretty fast. I intend to use it between the data acquisition and the coordinates and tracks extraction programs. Is my approach better than Chris' one? No. It is mostly different. I hate software bloat. I don't use bloated software when I can avoid it. I never write bloated software - even when that's what my customers want. Because bloated software is a nightmare to maintain and a pain to use. As a matter of fact, using bloated software is very expensive (even when the program is "free") at least in time if not in money.

Chris explained extremely well why I don't touch huge programs when he wrote Tom that it would be better to take a few weeks to learn IRAS than to write our own tools. A program that I can't master in a few hours is a useless program. A program that my customers can't master in a few hours is a useless program. And I mean "master", not "learn to use as a novice".

That a programmer (like Chris or myself) might want to master a huge dinosaur of a program, that's perfectly understandable: it's just a time investment - that a full-time astronomer of a dedicated amateur might want to master IRAS or the equivalent, that's also perfectly reasonable: again, a time investment. But that someone who couldn't care less might need to learn such a big mother when all he/she/it wants is to let some background process do automagically what has to be done to extract all pertinent data from automagically collected images from the night before, and then automagically update some database and notify him/her/it of only what is really interesting (magnitude fluctuations, moving objects, new objects), that I find ridiculous: I don't want to have to learn how to fly in order to go from Montreal to Toronto and back once a week. Buying airplane tickets is quite enough.

As an exemple, one of my customers uses a CNC machine to make one-of-a-kind metal parts. He came to me for his programming needs, because the 3D-CAD and CNC control programs he was offered elsewhere all came with a 1 to 3 weeks full-time course that he was told he had to follow in order to become able to use these programs effectively (and they also cost hugely). So, I found him a $395.00 3D-CAD program that he learned to use in a few minutes and mastered in two afternoons, and I programmed a CNC control program that needed no learning at all. And the program did not cost him a third of what "industry standard" programs sold for. 6 years later, he has yet to express any desire to change anything in his setup.

I think that's the kind of software we want to use for the TASS project: programs that require next to no learning, if not none at all.

And I have no reason to believe that IRAF fits that bill. The same goes for MIDAS.

Anyway, that was my tuppence for today.

Tom Droege droege@fnal.gov
Sept 16, 1996

Looks like I will be giving a talk at the IAPPP meeting at Yerkes Oct 4-6 on tass.

Will see any of you there that can make it.

Michael Richmond richmond@astro.princeton.edu
Sept 16, 1996

Chris Albertson suggested that TASS users should learn a standard, supported astronomical image-processing program to reduce TASS data. Norman Molhant suggested that they might do better to use a simple, specially-written program that does just enough for the TASS images -- which works out to

I largely agree with Norman; in fact, I'd argue that _some_ (not all) TASS users may want to have a "Black Box", that slurps in raw images and spits out calibrated catalogs. Certainly, it can be fun to play with the data, and, certainly, it's necessary to examine some images carefully to find sneaky problems. But, if one wants to create a large database of measurements, from which to draw information for various purposes, it would be most convenient to let a Black Box do all the work (night after night after night after night ....).

I don't want to tell anyone else what to do, by any means. But, by golly, for my OWN reasons, I'm going to write code to do all the above steps. In fact, I've already written (and made available for distribution) code to do steps B and C. I'm currently in the middle of code to do step D in an automatic way -- you give the program a list of stars from a TASS image, it gives you back a list of (RA, Dec, mag). While it's not clear exactly how this will work, I am going to try to make it possible for users elsewhere to send data to my machine (the one on which I'm typing now, in my office, always connected to the Internet) and have the machine send back a list of calibrated measurements.

Now, I can't provide good support for the code which I write, and I agree with Chris that support is a very important issue. Nonetheless, I'll distribute what I write, and I'll use it myself, so I _think_ it ought to be pretty well designed for other TASS sites....

Oh, and I have no objections to someone grabbing something I wrote to do one piece of the big puzzle, and grabbing parts from some other package to do another piece. It will be great when Mike G. and Norman get their source-extraction code up and running; if it works better than mine, I'll use it!

In short, I plan, selfishly, to write the entire pipeline of TASS data reduction, simply because I want to reduce "my" data as quickly and easily as possible; and I've determined that writing the code myself is best for me. If it helps anyone else, terrific.

Herb Johnson hjohnson@pluto.njcc.com
Sept 17, 1996 

*> What I would like is a quick review program.  One would give it
*> the name of the first file in a sequence.  It would then read 
*> the first file and produce a plot of the measured items vs time
*> through the file.  While at it, it might as well plot the mean 
*> value of the file line vs time as a cloud watch, or any better
*> cloud detection scheme that the writer can think up.  After the
*> first file plot is put up, a key stroke would produce the next 
*> file in the sequence.

Offhand, this sound like a job for a spreadsheet! Let me know when and where a sample file is and I'll look it over. My inclination would be to convert it to some spreadsheet-importable format, or find a spreadsheet that will accept an arbitrary "database" definition; or find some robust spreadsheet-oid program that could be mangled to accept the files as input.

Then you can tell the spreadsheet what you want to look at and it will plot and analyze as you wish.

Mike Gutzwiller Michael_Gutzwiller_at_CMCEF020@maillink.cmic.com
Sept 18, 1996

Sorry it's taken me so long to respond to the topic but I've been out of town. Norman wrote: 

> (b) use of "standard" programs or custom ones to process TASS data.
>
  ...

> Surprisingly enough, my opinion is that we should write specialised
> software for the specialized work we do.

I agree. IRAF and programs like it (including my own, DeepSky) are built to be great general problem solvers that can handle most image analysis problems for typical users. Unfortunately TASS isn't typical for several reasons:

For these reasons, and those Norman stated, I believe we really should create our own software.

Glenn Gombert ggombert@erinet.com
Sept 18, 1996

Dr. Eric Hooper (from the University of Arizona) is going to be in Dayton Saturday October 13th to give a talk and an introductory IRAF workshop as a follow-up to the Advanced Adult Astronomy Camp that several of us attended last April at the University of Arizona. One of the things that we did was UVBRI photometry of quasi-stellar objects and used IRAF (DAOPHOT) for data reduction. Dr. Hooper is going to give an IRAF overview and talk about photometric data reduction.

Any one on the ccd-list that can make to Dayton is more than welcome to attend the seminar.

Glenn Gombert ggombert@erinet.com
Sept 19, 1996

TCL / TK is surley the easiest way to develop X-Windows applicaitons under UNIX/Linux. I it is sort of a "Visual Basic" for X-Windows that is a script langyage (TCL) with X-Windows extensions (TK). I have used it to develope the GUI for a large scientific database system out at WPAFB and is easiest way to develope X-Windows GUI applicaitons. It would certainly speed the development time of any kind of a camera control interface under Linux...

Chris Albertson chris@topdog.pas1.logicon.com
Sept 19, 1996

That same TCL works under MS Windows 95 too. That was my point.

Develope once and you have something usable under _both_ Windows and Linux.

With it's built in scripting, an end user can automate all those "small special purpose applications" Norman wants to write.

Chris Albertson chris@topdog.pas1.logicon.com
Sept 19, 1996

Yes TCL/TK runs on just about any computer. See the FAQ outline which I've quoted below. The next quote shows where to get the FAQs

O'Reilly and Associates publishes a good book on the subject. I've seen it in bookstores. "comp.lang.tcl" is a good place to post general questions.

If all else fails, there is a copy of it running on a Windows 95 machine here in this office, I could send a copy of that.

Yes it is free. Source code for the whole mess is available as well as pre-compiled binaries.

Other programs written in any of serveral languages can be pulled into the TCL framework and made into a TCL commands. So one could gather a bunch of "building block" programs together and slap an GUI interface on them. It end result runs faster then you would think. TCL started out as a compter science research project. One of the project's major goals was run-time performence.

There are free and commercial sources from TCL/TK, take your pick.

From the Origin of the comp.lang.tcl FAQ information. [Ed: Beware, because I can't access the URLs shown below].

Three general FAQs are available. These are spin-offs from my original source document. The first contains a bibliography of published material related to Tcl, and will be managed by Glenn Vanderburg (glv@utdallas.edu). (See tcl-faq/bibliography/part1) or ftp it at ftp://ftp.aud.alcatel.com/tcl/docs/tcl-faq-bib.gz

The second FAQ contains a series of Tcl-related questions and answers and is managed by Joe Moss (joe@morton.rain.com). (See tcl-faq/usage) or find it at ftp://ftp.aud.alcatel.com/tcl/docs/tcl-faq-Q-and-A.gz

The third contains Tk-related questions and answers and is managed by Thomas J. Accardo (tja@cpu.com). You can (See tcl-faq/tk/part1) or find it at ftp://ftp.aud.alcatel.com/tcl/docs/tcl-faq-tk-usage.gz

Tom Droege droege@fnal.gov
Sept 23, 1996

I am about to ship the serial #1 triplet to Glenn Gombert. If anyone has any problems that may need to be tested on a a triplet, let me know now. I have no idea what such a problem would be, but I will find out as soon as I ship the camera, I suppose. ;^(

Meanwhile, I continue working on the Mark IV design. Writing simulations to compare all the different ways to build it.

Chris Albertson chris@topdog.pas1.logicon.com
Sept 24, 1996

There was some talk here about using Linux for real time control of a TASS or other CCD camera. If anyone is interested in doing this, or just in seeing how this could be done then look at the web page below. 

============= BEGIN QUOTE ===================
> 
> Real-Time Linux: Release 2.0.0.1
> 
> RT-Linux is a Linux kernel with hard real-time tasks. 
> Current versions run on the x86 architectures only. 
> Real-time tasks are run as loadable modules and may
> be  periodic or interrupt driven. On a 120MHz Pentium,
> we have reliably run  tasks with periods of 150 micro-seconds.
> This is a development release and undoubtedly there are bugs
> to be found and aspects of the design that should be changed.
> We are actively looking for interesting test applications. 
> If you have a candidate application and want some assistance,
> email to rtlinux@luz.nmt.edu.
> If you develop an application, please tell us about it.
> 
> 
> FTP. ftp://luz.cs.nmt.edu/pub/rtlinux/2.0.0.1/
> Web.  http://luz.cs.nmt.edu/~rtlinux/
> Email. rtlinux@luz.cs.nmt.edu
>        
> 
> Victor Yodaiken
> Department of Computer Science
> New Mexico Institute of Technology
> Socorro NM 87801
> yodaiken@nmt.edu
>

Tom Droege droege@fnal.gov
Sept 27, 1996

I am working hard on the Mark IVb. The problem is to figure out how to spec a lens that can be built that beats camera lenses. It is hard. But there are two possible design parameters that look promising.

One is to design the lens with the bandbass of the filter used with it. There is probably a square or more to be gained here. Possibly 1/3 the bandwidth equals 1/9 the problem. Also I am told that it is easier to design at the IR end. So possibly a 700-900 nm "I" lens is easier to design than a 490 to 585 "V" lens.

A second thing is to squish out the spot size. Lens designers seem sort of offended when I brign this up. But it looks like it may make the design cheaper. If we spread out the PSF, it helps the dynamic range problem but probably hurts at the level where stars are just detected. At the low end we probably cannot make good measurements anyway, so there might be a net gain. If we make it too large, then we will have a crowding problem. So PSF fans, what it the idel spot size? What is the largest spot your PSF software will stand? Does it make sense to you to go for a larger spot size?

One thing for sure I know I am in big trouble to find a design that is better than camera lenses when I talk to lens makers and they say things like "why don't you take this problem to the University of xxxx, they might be interested in working on this problem."

Nick Beser beser@aplcomm.jhuapl.edu
Sept 27, 1996

APL Observatory Status Report
Nick Beser - Project Leader

Bernie Kluga has made good progress on the housing and mount for the TASS camera. The optical windows have been installed, and the camera has been mounted in the box. The feed through couplers for cooling water need to be obtained. We are hoping to finish the enclosure by the end of next week.

Marty Pittinger and Nick Beser have configured the first of two computers for the observatory. The camera controller computer is a 486 (33Mhz) with 32 Mbytes of memory, and two 340Mbyte disk drives. We have loaded windows 95, and added a CD-ROM and a network card. Network ip number and connection has also been obtained thanks to the FSD network support. Additional testing of the network and installation of the camera controller card will occur next week. A power supply for the TEC and the temporary water pump will also be delivered to the lab next week. We anticipate camera checkout could begin next week, with roof testing probably by the following week. We will test with a temporary cooling pump until the facilities work has been completed.

Facilities has all of the paper work to order the water pump and schedule installation for the Building 40 site. The facilities lead project engineer has told us that installation could occur from 3 to 6 weeks after the paper work is started.

A great deal of software work still needs to be done in both the control and data analysis area. We are looking for people from APL and the surrounding schools to sign up for the following tasks:

Anyone interested in any or all of these tasks should contact Nick Beser at beser@aplcomm.jhuapl.edu.

Mike Gutzwiller Michael_Gutzwiller_at_CMCEF020@maillink.cmic.com
Sept 27, 1996

Tom wrote: 

>A second thing is to squish out the spot size.  Lens 
>designers seem sort of offended when I brign this up.
>But it looks like it may make the design cheaper.  If 
>we spread out the PSF, it helps the dynamic range problem
>but probably hurts at the level where stars are just 
>detected.  At the low end we probably cannot make good
>measurements anyway, so there might be a net gain.  If 
>we make it too large, then we will have a crowding 
>problem.  So PSF fans, what it the idel spot size?  What
>is the largest spot your PSF software will stand?  Does
>it make sense to you to go for a larger spot size?

As always the answer is "it depends." Here's some basic equations that shows what the answer depends on and the choices implicit in selecting the best PSF size. Let's define the following: 

        n       Noise error at each pixel due to system noise and the 
                sky background in electrons.

        N       Total noise over the entire PSF.

        W       Width of the PSF in pixels.  Typically something like 2 
                times the Full Width Half Max of the PSF.

        H       Height of the PSF in pixels.  For the calculations below
                I'm going to assume W = H.

        F       Full well capacity or limit of linearity for a single
                pixel in electrons.

        Rmin    Minimum ratio of signal to noise to be useful.  Depends on
                the definition of useful.  Could be for detection or for
                photometric studies.

        S       Signal of a star in electrons.   Total number of electrons 
                produced by the star over the PSF.

        Smin    Minimum signal of a star in electrons to fit the usefulness
                limit RMIN is based on.

        Smax    The brightest star that doesn't overfill the well of any 
                pixel.

        D       Dynamic range.  The ratio of the signals of the brightest 
                star we can measure over the faintest useful star.

        p0      The value of the PSF at its peak.

We can calculate: 

        N = sqrt(number of pixels)*n = sqrt(W*H)*n = W*n

        Smin = Rmin*N = Rmin*W*n

        Smax = F/p0

If the width is not equal to 1 we can generally assume that 

        p0 = k/(W*H) = k/(W*W) where k is a constant.  For the kinds of 
                               PSF's I've seen k is about 3.

If the width is 1 then 

        p0 = k = 1

Plugging the general form of p0 we get 

        Smax = W*W*F/k

        D = W*W*F/k/(Rmin*W*n) = W*F/(k*Rmin*n)

From this we can conclude that widening the PSF increases brightness of the dimmest star linearly with width but increases the brightness of the brightest star by the square of the width thus increasing the dynamic range linearly with width.

Note that increasing the dynamic range in this way may not increase the number of measureable stars since there are a lot more dim stars than there are bright ones.

This is as far as I can go since there are other questions that need to be answered to calculate the best PSF width for the Mark IV:

What is the expected background noise (n) per pixel?