Contents

Benoit Schllings benoit@be.com
Oct 2, 1996

you remember a long time ago that I was thinking of ways to give you some competition ! Nothing is better for ideas, right ?

Anyway, my drift scan system is working... what am I doing ?

I used a small 4 inch F/4 newtonian (mirror from Edmund) mounted at a fixed position on the side of my house, I use on it an SBIG ST-7 working in drift scan mode... the image scale is 4.3 arcsec per pixel, which means that I cover a much smaller field than your system... the total field of view is 0.9 degres.

The time to drift across the array is 146 seconds at the equator, this let me reach near mag 17 at SN/3... a better sky would help for 0.5 mag.

In order to process the data is near real time, the data from the camera is transmited to a second computer (a BeBox, this is a real time multi CPU machine) using a serial connection which displays the current scan + does a compare with a scan made the previous night. A list of abnormal difference is created which can be reviewed at any time (the advantage of two machines).

I got the system working for the first time last night, real fun to watch the sky drifting in real time... did spend an hour just looking at it.

Smaller field but deeper view... I guess that I will see more asteroids and less comets !

This is of course a more expensive system to setup, but I had all the parts needed.

Glenn Gombert ggombert@erinet.com
Oct 2, 1996

Well TASS Camera (Serial #1) has arrived safely in Dayton due to Tom's careful packing of the instrument. The triplet will be installed at the Miami Valley Astronomical Societies dark sky site in Yellow Springs, Ohio. The John Bryan State Park observatory is a million dollar facility (in today's dollars) that use to be a former US Air Force satellite tracking station that has been leased from the State of Ohio since the early 70's by the MVAS. The observatory has a 16 ft rotating dome and a large roll-off area which will house TASS serial #1. Some renovations has been going on out at the observatory the last several weekend in preparation for the arrival of the triplet.

The MVAS has a home page at "http://www.mvas.org" that describes the observatory and the facilities out a John Bryan State Park. A page will be added devoted to the TASS installation at JBSP when the installation has been complete. A computer has been put together to operate the TASS camera along with Norman's software to collect images. The computer is also equipped with Linux/IRAF to aid in data analysis and reduction....

Work has being going on the last month or so comparing several data reduction methods on sample data that Tom has uploaded to storm.fnal.gov .These include the "Sextractor" program for building star catalogs as well as computing stellar magnitudes. Peter Stetson's "DAOPHOT II" has also been used recently to make similar calculations. DAOPHOT II is very sophisticated program which performs crowded-field point spread function photometry that is considered as a "standard" in the professional astronomical community. A very good article on this was published in the Spring 1995 issue of CCD Astronomy ( it is highly recommended reading on the subject). is fairly easy to do this in IRAF once TASS images have been converted into FITS format.

The week of October 11th Dr. Eric Hooper from the University of Arizona will be in Dayton to give a talk to the MVAS and hold an IRAF workshop. Eric's PHD thesis has involved the extensive use of DAOPHOT II to perform UVBRI photometric data reduction (similar) to the crowded star fields found in TASS data. I plan to review our data reduction techniques with Eric and share any thoughts and suggestions that he may have with the tass mailing list. Anyone that is interested is of course invited to attend Eric's talk at the Dayton Natural History Museum.

Glenn Gombert ggombert@erinet.com
Oct 2, 1996

As Tom has pointed out several times in the past is that one of the (obvious) first uses of TASS data is to generate large quantities of Variable Star observations and light curves. To this end (after consulting with Tom) have contacted Dr. Janet Mattei (director of the AAVSO) to introduce the TASS project and seek the help of the AAVSO in the perfection of TASS data reduction/analysis techniques. Dr. Mattei seemed interested in the project and said that she would get back in touch after reviewing the package of information on TASS that I send to the AAVSO (most of which came from the TASS Home Page). My (conventional) ccd imaging partner John Chumack has just finishing up a National Science Foundation Grant project for Dr. Mattei that involves wide-field photographic techniques (similar to TASS) only using 50 mm camera lenses and photographic film in place of ccd cameras. John and I wrote an article in the February 1995 issue of Astronomy magazine (Catching Comets With CCD's) that has a nice shot of the roll-off roof area of the JBSP observatory.

Dr. Mattei said that currently the ccd variable star observations that are made to the AAVSO are based on differential photometry using detailed charts published by the AAVSO which were developed at Kitt Peak Observatory. The present challenge in using measurements based on TASS data will be obtaining good "reference points" to calibrating instrumental stellar magnitudes that are calculated by packages such as IRAF.

The new TYCHO catalog of stellar photometric data should be available in the next 12 months which will be a big help in providing a good calibrated reference standard which to use in stellar photometric magnitudes. This data can provide the kind of reference that is necessary to make high precision stellar magnitude estimates.

The focus of the efforts here in Dayton will be to refine the TASS data reduction techniques to a point that the measurements are of a high enough quality that they would be accepted by the AAVSO. Once this has been accomplished more ambitious tasks can be under taken to make other types of measurements with TASS data.

Michael Richmond richmond@astro.princeton.edu
Oct 7, 1996

This note also appears as Technical Note 21.

On Sep 29, 1996, I acquired some TASS images with the Vermont triplet. The weather had been unsettled, and the forecast called for rain late in the night (which did occur). I resigned myself to taking a few hours of scans just after dark, and decided that one good use for the data would be to study the variation in sky brightness caused by sunset and moonrise. The gibbous moon was scheduled to rise about 3 hours after sunset.

So, I got the scans, noticing that the sky became very dark for just an hour or so after the sunlight faded -- I was able to see the Milky Way very easily -- and then brightened again as the Moon rose in the east.

After subtracting a dark vector from the data, I measured the sky value as a function of time in the following way: for each row (line) of data, I calculated the median pixel value. I then made a large file consisting of row number (from 0, soon after sunset, to about 13000, around 10:15 PM) and median sky value.

I expected to see the sky value drop steeply after sunset, reach some minimum level, and then rise again as the Moon became visible. I therefore made a plot which shows the sky value (as a function of row number) and also the altitudes of the Sun and Moon above (or below) the horizon. Astronomical twilight is said to start when the Sun is 18 degrees below the horizon: at that point, the sky is supposed to be as dark as it ever gets. I also noted that a ridge of hills to the East of the site would block the Moon for some time after it had risen above the theoretical, perfect horizon, and watched carefully to note the actual time that it appeared above the ridge.

Here's a graph of the sky value, and the solar and lunar altitudes (you can click on it to get a larger version of the figure):

The filled circle in the lower panel shows the Sun's altitude, and the open circle the Moon's altitude.

What a surprise! Note how the sky value, after dropping rapidly as the Sun sinks farther and farther below the horizon, rises slowly, stay high for about an hour, and then starts to drop as the Moon is rising into the sky!. It isn't until near the end of my scan that the moonlight (and, probably, some clouds) seems to drive the sky to larger values.

At first, I figured that this strange behavior of the sky brightness must have been due to thin clouds that I couldn't see with my eyes, but then I decided to look at the images themselves. Here's a picture of the scan from rows 3000 to 4000, roughly (again, click to get a larger version); North is up, and East to the left.

By golly, this looks like part of the Milky Way! And so it is -- a section about 7 degrees wide and 3 degrees high, centered at (1950) RA = 18:47, Dec = +0:30 -- in the western edge of Aquila. Note the very bright clump of stars near bottom left, and the strong obscuration running like a snake just above it and down to the right.

And this is the answer to my perplexity --- the reason that the sky got brighter quickly, then fainter as the moon rose, was because the camera happened to be scanning through the center of the Milky Way at that time!

Let this be a lesson to people (like myself) who try to analyze their results before they look at them.

Tom Droege droege@fnal.gov
Oct 7, 1996

I had a good time at the IAPPP meeting at Yerkes. Everyone tells me this is a monster project. The implication being that we will never get any good data out of it. But we know differently? The AAVSO people look espically nervous. The talk went well, at least everyone stayed awake.

I now have a monster pipe standing by my deck. It is about a 700 pound pipe. Roughly 24' tall. Looks like it has its main resonance at about 4 Hz. Should not be too hard to tune that out. I hope to have a Mark IV sitting on it by spring.

I keep working on the Mark IV design. There is now also a Mark V in the works. Must keep going.

Nick Beser beser@aplcomm.jhuapl.edu
Oct 7, 1996 

> I had a good time at the IAPPP meeting at Yerkes.  Everyone
> tells me this is a monster project.  The implication being that
> we will never get any good data out of it.  But we know differently?
> The AAVSO people look espically nervous.  The talk went well, at 
> least everyone stayed awake.
The sign of a successful lecture. The sign that you lost them is not when they go to sleep, but when they fall out of the chair. 
> I now have a monster pipe standing by my deck.  It is about a 700 
> pound pipe.  Roughly 24' tall.  Looks like it has its main resonance
> at about 4 Hz.  Should not be too hard to tune that out.  I hope to 
> have a Mark IV sitting on it by spring.
Are you sinking the pipe into the ground, or mounting it along side of the house? 
> I keep working on the Mark IV design.  There is now also a Mark V in
> the works.  Must keep going.
I'm interested in hearing about the Mark V.

Herb Johnson hjohnson@pluto.njcc.com
Oct 8, 1996 

*>I had a good time at the IAPPP meeting at Yerkes.  Everyone
*>tells me this is a monster project.  The implication being that
*>we will never get any good data out of it.  But we know differently?
*>The AAVSO people look espically nervous.  The talk went well, at 
*>least everyone stayed awake.
"Good data" of course begs the question. If the goal is *detection* of new objects, then the data need only indicate such things as time, location, and calibrations sufficient to confirm the above. Most surveys also intend to establish relative or absolute "signal strength", which in our case is magnitude information. It would seem we "have the technology" to establish magnitudes to some fraction of magnitude, depending on calibrations and filters: Michael Richmond can make the "call" on how well this can be done.

Variable magnitude data is a tougher nut to crack, as it calls for repeated and consistent observations. So we might keep an eye on stable camera operations and consistency of camera electronics. I suspect it would be reasonable to ship TASS cameras back to Tom on some regular basis for re-calibration. Tom surely knows this game pretty well. 

*>I now have a monster pipe standing by my deck.  It is about a 700 
*>pound pipe.  Roughly 24' tall.  Looks like it has its main resonance
*>at about 4 Hz.
What's the dampening time? and what is the size of swing for some given impact like, say, a weight on a string of some length? And how does weight damp this swing? Could be an amusing experiment (and an exercise in second-order mechanics) if you have an idle hour. I suppose a mounted magnet and a large coil or analog Hall effect sensor could be used to monitor its motion relative to the deck or house.

Tom Droege droege@fnal.gov
Oct 8, 1996 

> *>I had a good time at the IAPPP meeting at Yerkes.  Everyone
> *>tells me this is a monster project.  The implication being that
> *>we will never get any good data out of it.  But we know differently?
> *>The AAVSO people look espically nervous.  The talk went well, at 
> *>least everyone stayed awake.  

> "Good data" of course begs the question. If the goal is *detection* of new
> objects, then the data need only indicate such things as time, location,
> and calibrations sufficient to confirm the above. Most surveys also
> intend to establish relative or absolute "signal strength", which in our
> case is magnitude information. It would seem we "have the technology" to
> establish magnitudes to some fraction of magnitude, depending on calibrations
>and filters: Michael Richmond can make the "call" on how well this can be done.
These guys are really nervous. I think that they see that their way of doing things is going to change. So I get lectured about putting out too many false alarms - and get told stories of hundreds of objects reported as variable that were really double stars that were wandering between two pixels. The way to win over the critics is just by producing good data. I think I will not be too quick to send stuff to the AAVSO. Let them come to tass for our lists of new objects. We are wide open - at least I will be wide open and whatever I find will be avialable with no strings. Then if someone wastes time looking at a bad object it will be their own fault.

I think I could sit down with the data I have and "find" a few variable stars by brute force and hand computation. But just finding a few is not my goal. I want to find everything within our range on one strip of sky. With error bars and great confidence that we understand the data. The rest of you may have other goals. That is allowed. 

> Variable magnitude data is a tougher nut to crack, 
> as it calls for repeated and
> consistent observations. So we might keep an eye on stable camera operations
> and consistency of camera electronics. I suspect it would be reasonable to
> ship TASS cameras back to Tom on some regular basis for re-calibration.
> Tom surely knows this game pretty well.
I will bet a bottle of good stuff off the shelf at your favoirite store that we *never* have a calibration problem that requires sending cameras back to me. Unless you call a completely "dead" camera a calibration problem. We calibrate against the sky. There are only precision resistors, the stability of the CCD itself, the cleanliness of the lens, and the ADC that might change. Possible changes of everything but the lens are of order 0.01%. So I don't think we will ever have a drift problem. But don't send a camera back for a dirty lens. I don't do windows. The sky calibration is, of course, and immense problem. That is what tass is all about. Finding a way to get good data. 
> *>I now have a monster pipe standing by my deck.  It is about a 700 
> *>pound pipe.  Roughly 24' tall.  Looks like it has its main resonance
> *>at about 4 Hz.

> What's the dampening time? and what is the size of swing for some given
> impact like, say, a weight on a string of some length? And how does
> weight damp this swing? Could be an amusing experiment (and an exercise
> in second-order mechanics) if you have an idle hour. I suppose a mounted
> magnet and a large coil or analog Hall effect sensor could be used to
> monitor its motion relative to the deck or house.
Don't know any of these things yet. I cannot get up on the roof yet to look at the pipe. The spiral staircase is not yet installed, and I don't like to climb up a ladder that tall! My hips just don't work well enough. But soon. The painters are here today, then the stair goes in, and then I can get to the roof. But I did know about putting sand in the pipe to damp it. Thanks to everyone that reminded me.

Chris Albertson chris@topdog.pas1.logicon.com
Oct 8, 1996 

> Variable magnitude data is a tougher nut to crack, 
> as it calls for repeated and
> consistent observations. So we might keep an eye on stable camera operations
> and consistency of camera electronics. I suspect it would be reasonable to
> ship TASS cameras back to Tom on some regular basis for re-calibration.
> Tom surely knows this game pretty well.
This should not be required. Short term stability is more important then long term stabitilty. As long as the camera works it should be usable.

My concern is not calibration or false reports. It is the size of the error bars but that is another issue.

Here's my reasoning:

The standard photometric technique is esentualy continous calibration. The traditional photometer sees only one star at a time. The way it is used is to alternate between "program" stars, "standard" stars and black sky. The idea is you keep doing this all night long because conditions change. A wide field CCD camera can make many measuremnts at one time but the basics are the same.

The standard data reduction technique is to compute a stars magnitude as would be seen from space (no atmosphere) with all instrumentation effects removed. (well, reduced to a "standard" intstrument, not realy removed) This is a fairly complex process. You see terms like "color transform" and "air mass". For example, The "V" magutude is not simply a function of the brightness observed through a V filter but is something more like 

        MagV = f(magU) + g(magV) + h(magB)
Where functions f, g, and h are computed from standard stars of known brightness in each band. For wide fields (like TASS) f, g, and h are not constant but change over time, RA and DEC. Notice that the "V" of the left is likely a different pass band then the "V" on the right of the = sign.

You can't simply say "the ADU value of star X is two times the ADU value of star Y and I know the magnitude of star Y....." This does not work because the stars may have different colors and our "V" passband is likely not the same "V" as the catalog's "V".

Normally the telescope can be swung around to measure the standards that surround the program stars. With TASS we will just have to hope a few of these standards drift through. I think the number of "standards" that drift through will affect the size of the error bars. Unfortunatly the only control we have on this is to get a bigger catalog of standards. We do not have the option of periodically going back and measuring the _same_ standard every 10 or 20 minutes.

I'm writing this off the top of my head and I am _not_ an expert so the above is kind of simplified and some details are no doubt wrong but you get the idea -- photometry does not require that your instrument remain calibrated over long periods of time and it does not require _absolute_ calibration at all, only the ability to measure relative brightnesses in multiple passbands.

Herb Johnson hjohnson@pluto.njcc.com
Oct 8, 1996 

*> win over the critics is just by producing good data.  
*> I think I will not be too
*> quick to send stuff to the AAVSO.  Let them come to tass 
*> for our lists of new 
*> objects.  We are wide open - at least I will be wide open 
*> and whatever I find 
*> will be avialable with no strings.  Then if someone wastes time looking at a 
*> bad object it will be their own fault.
I think it would be a good idea to read some of the AAVSO literature. It's very informative about methodology and, after all, they've been there. Things will change with new instruments, but TASS stuff should be able to be held up to fairly good standards. Our reported observations should be as solid as our equipment and sites allow. Tom gives me the impression he understands this well enough from his FermiLab work (pardon me for stating the obvious).

I have been involved with some "data archeology" with another mass survey, done by Ohio State in the 60's and 70's, using a drift field telescope of "high" resolution at the time. Namely, the Big Ear Radio Telescope. Their publications are informative about the process of survey work, including criteria for detection limits and source resolution. I'm not sure their articles and theses work can be read "cold" and be informative: I've read them and worked with both data and telescope many times in the last 15 years. Anyone interested can contact me, or inform me of a more useful text on the subject of astronomical surveys.

I should also note this "conflict" between astronomers and Tom reminds me of the same conflicts between other astronomers and the Ohio State folks who are "actually" electrical engineers (John Kraus has emphatically affirmed he is also an astronomer, of course). 

*> I will bet a bottle of good stuff off the shelf at your favoirite store that
*> we *never* have a calibration problem that requires sending cameras back to
*> me.  Unless you call a completely "dead" camera a calibration problem.  We 
*> calibrate against the sky.  There are only precision resistors, the stability
*> of the CCD itself, the cleanliness of 
*> the lens, and the ADC that might change.
...except when you point the CCD at the Sun for a few hours, Tom...

I don;t like arguing hypotheticals, nor how a really good design may have long-term drift, etc. I'd simply say: have some stable standards, and check periodically for drift and problems. *Saying* .01% is easier than to *verify* .01%, and very literally time will tell. Consider that in many areas of photometry and astrometry, instruments must be usable for *decades* in order to determine various effects or phenomena. Conversely, consider that TASS cameras are in uncontrolled enviroments and are subject to "unanticipated environmental effects". Harumph.

Thanks for the comments on your pipe. Of course, tinker with it as time permits.

Chris Albertson chris@topdog.pas1.logicon.com
Oct 8, 1996

Well yes, sort of. What I meant was simply to say

I tried to provide just enought information so people could see the above for themseves.

Chris Albertson chris@topdog.pas1.logicon.com
Oct 8, 1996

If TASS photometric data is to be combined with any other data it will have to be reduced to some standard system. I mean this in the most general way.

I think last year it was pointed out to this group that the reason the observed magnitudes (by early Mk III runs) did not correlate well with published magnitudes was because the spectral responce of the TASS camera did not match the spectral responce of the system used to build the published catalog. Adding filters helps but still the responces can not match exactly.

So even to do something so simple as compare a TASS picture to a star map and have the brightnesses match to even .5 mag we need to do some work.

So we take data in three bands which allows us to compute a color transform which will correct for the mis-matches in spectral responces.

I think the next step for us as a group is to discuss _exactly_ how to reduce the data.

OK so it is "dark frame, flat frame, bias frame corrections then off to DAOPHOT/Sextracter to get instrumental magnitudes. Then what???

Glenn Gombert ggombert@erinet.com
Oct 9, 1996

I think that Chris has made some good points in his discussion below. There is a VERY good article on this subject in the Spring Issue of CCD Astronomy called "PSF Photometry - Unscrambling StarLight In Crowded Fileds" that gives an excellent discussion about the types of measurements that are required from images (such as TASS) to make measuremts on ccd images with crouded fields.This short article makes excellent background reading on the subject.

If I can quote from the article "When working with Golbular Clusters, once a good PSF is constructed, hunddered of thousands of stars can be measured automaticallY". This is uses a program written by Peter Stetson which is called "DAOPHOT" to perform crowded-field photometry. This set of routines has been incorporated into IRAF and MIDAS. It can easily calculate the "instrumental magnitudes" of many thousands of stars.

Dr. Eric Hooper from the University of Arizona will be in Dayton this weeked and has made extensvie use of DAOPHOT in his PHD thesis I plan to discuss TASS data reduction techniques with Eric and will report to the list any recommendations that he may have.We make some measurements with Eric on some of the TASS images that Tom has uploaded to Strom.

The stand alone program "Sextractor" that Alain has pointed out to the group also does a very nice job of calculating instrumental magnitudes (in moderatly crouded fields) and can be compiled to run on almost any platfrom. It seems that using something like "Sextractor" to compute instrumental magnitudes for stars that are measured on several evenings (from the same location) would be a good way to quickly get a feel for the consistance of measurements from one night to the next. This would also be an excellent way to start a search for cantidate variable starts (with small brighness changes) from one night to the next.

Finally Tom's point is well taken that people will resist new ways of doing things (such as the tension of conventioanl film astrophotography bs film ) as a way of recording the night time sky. Old ways die hard (or so it seems).....

Chris Albertson chris@topdog.pas1.logicon.com
Oct 9, 1996

> There is a VERY good article on this subject in the Spring Issue of > CCD Astronomy called "PSF Photometry - Unscrambling StarLight In Crowded > Fileds" that gives an excellent discussion about the types of measurements > that are required from images (such as TASS) to make measuremts on ccd > images with crouded fields.This short article makes excellent background > reading on the subject.

Another reference is available on-line. "A User's Guide to Stellar CCD Photometry with IRAF" is good. It is a 69 page long document. The abstract starts out "... to guide you through the steps for obtaining stellar photometry from CCD data..." see http://iraf.noao.edu/iraf/web/docs/photom.html

Then click on the above named document (or one of the others.) They are in compressed postscript (*.ps.gz). If your browser cannot read this let me know. I may be able to convert

The documents linked to photom.html are more technical then typical CCD Astronomy articals but are still toutorials. They are also "IRAF centric" but the steps to be performed and the algorithms would be the same in any software system.

Glenn Gombert ggombert@erinet.com
Oct 9, 1996

As Chris has pointed out after we measure the instrumental magnitudes in several TASS frames, then what?? Some food for thought might be found in the Winter 96 issue of CCD Astronomy on an article on this subject by Douglas Welch. In the article Welch described a technique for data analysis of star fields that have been imaged on more than one night (possibly through several different color bands). It also has build in a straightforward method to estimate the confidence level of a stars variablility. The article also contains several good references on places to check potential "discoveries" against.

The technqiue is described on page 17 of the Winter issue and looks like a "natural" thing to do once a number of instrumental magnitudes measurements have been made of the same star field from TASS images. The calcualtion looks fairly straight forward and should be a very interesting to do for several dat sets taken on different nights. It is high on my list of things to do as soon as I get the tripplet installed and operational here in Dayton ...

Michael Richmond richmond@astro.princeton.edu
Oct 9, 1996

Here's my view on the problem of converting raw TASS instrumental magnitudes (the numbers produced by IRAF, SExtractor, XVista, etc.) into standard magnitudes on the Johnson-Cousins VRI system. I agree completely with Chris and others who have stated that we must convert the data from the natural TASS system to the Johnson-Cousins system, in order to be able to compare our values with those obtained by others. 

  Step 1: extract raw instrumental magnitudes and positions for all
          stars in a scan, using your favorite software.  The result
          will be a long list of 

                   xposition   yposition   raw_magnitude


  Step 2: figure out the positions of all stars in the scan; that is,
          perform the Astrometric calibration.  We can do this by matching
          up detected stars in the scan to stars in the HST Guide Star
          Catalog.  If you don't have a copy of the Guide Star Catalog,
          you can grab a compressed version which covers the celestial
          equator only from 

            the TASS software page

          As I have mentioned before, I'm trying to develop robust 
          software to do the matching and coordinate transformation
          automatically; unfortunately, while it sometimes works, it 
          sometimes fails miserably.  This could be made much easier
          if one could tell the program _roughly_ where the camera was
          pointing when it acquired some strip of data -- so I'm very
          happy to see that Norman's new data acquisition program provides
          this information.

          After performing this step, one should have a list of this form:

                          RA   Dec   raw_magnitude


  Step 3: Run through the list and try to find as many standard stars
          as possible, by comparing (RA, Dec) of detected stars with 
          (RA, Dec) of the standards.  If one has done Step 2 properly,
          this is a cinch.

          I plan to use Landolt's collection of standard stars along the
          celestial equator to calibrate my images.  There is roughly
          one standard field per hour of Right Ascension, plus a small number
          of single stars scattered here and there.  Thus, I expect that we
          will get a single "photometric calibration check" every hour.
          This may not be frequent enough to deal with clouds.  In the
          long-term, we can begin to create a more numerous set of 
          "secondary standards", based on measurements of many stars 
          against the Landolt standards, which should give us much more
          frequent measurements.

          You can find descriptions and references to the Landolt catalogs at

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

          and I will send individuals copies of the catalogs upon written
          request.

  Step 4: Compare the raw TASS magnitudes of the standard stars against 
          the Landolt magnitudes.  You can see an example of this in 
          TASS Technical Note 19, at

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

          Suppose that a camera has filters I, V, I.  Then one can try to 
          solve for two values in this comparison:

              A. the "average" difference between the TASS V measurements
                 of each star, and the Landolt V value.  This difference
                 is called the "zero-point" term.  One can solve for the
                 "zero-point" term for the I-band measurements, too.
                 Call the "zero-point" term for V-band "Kv", and the 
                 "zero-point" term for the I-band "Ki".

              B. draw a plot of the difference between TASS V and Landolt V
                 (on the Y-axis), versus the TASS (V-I) color (on the
                 X-axis).  Solve for the slope of the line which runs through
                 these points.  This is the "color term" for the V-band
                 measurements.  We _hope_ that this slope is very close to
                 zero, because that indicates that the TASS CCD+filter+lens
                 system has a response similar to that of the standard
                 Johnson-Cousins system ... which in turn means that our
                 measurements should be similar to the standard ones.
                 Call the slope of this line "Cv".  One can solve for the
                 slope of (TASS I - Landolt I) vs. TASS (V-I), and call that
                 slope "Ci".

                 As the example in Technical Note 19 shows, these slopes may
                 very well be zero.

 
    Step 5: At this point, one has a set of measurements of "Kv", "Ki"
            and "Cv", "Ci" throughout the night -- perhaps one set per 
            hour.  Now comes the tricky part.  One must take the raw
            TASS V-band and I-band magnitudes, and convert them to the
            standard scale, by calculating

                standard V = TASS V - Kv - Cv*(TASS V - TASS I)
                standard I = TASS I - Ki - Ci*(TASS V - TASS I)
     
            The tricky part is deciding what values for "Kv" and "Cv"
            are appropriate.  For a star very close to a standard field,
            we can use the values derived from that standard field.  But
            what about a star midway between two standard fields, 
            half an hour from each?  And what about a star taken ten
            minutes from a standard field, when there was evidence for
            clouds?  Devising a good method for interpolation could take
            some trial-and-error....

The end result of all this is that one has taken "raw" measurements and converted them to a catalog of (RA, Dec) with standard magnitudes. One can then use such a catalog to compare measurements of the same stars taken on different nights ...

I hope that this gives a general impression of simple photometric routines which might be appropriate for TASS data. There are complications, of course, but I think the method outlined above may work adequately. Reducing raw photometric measurements to a standard magnitude system is one of my research interests (well, actually, studying the properties of supernovae _after_ having converted their magnitudes to standard scale is my real interest), so I have some experience here.

Tom Droege droege@fnal.gov
Oct 9, 1996

There are really two things we can try to accomplish with the tass cameras. One is exploration and the other is measurement. My personal interest is in exploration. Some of you may be more interested in measurement. That is just fine with me.

To explore a strip of sky, we only need to take a consistent set of measurements between the various tass telescopes. We can find the variable stars, asteroids, and comets, nova, etc., without making any absolute measurements. We can probably classify the set of variable stars in the measured strip, and provide a complete catalog of the objects found between some magnitude limit. As near as I can tell (see the Paczynski paper in the bibliography) this has not been done to the level we might be able to accomplish. This, I think, would be a nice piece of science.

Tying these measurements to measurements of others is a different problem and probably a more difficult one. I am not opposed to us attempting this, it is just not my personal interest. It seems to me that the precision measurement tradition dates back to 1P21 days (or earlier). It involves a set of arbitrary filters to classify a magnitude. This is really a compromise (in my opinion) since the only way to really measure a star is to do a spectrum (and not just a visible one). A spectrum probably provides too much information for a simple classification. Thus we have the complex classification of stars that we see in the catalogs. The nature of the measurement is such that once we deviate at all from the standard procedures of the AAVSO, then we will get a different answer. We are bound to deviate because we will not be using the measured star, reference star(s) procedure of the AAVSO and the historical measuring devices. I happen to think that broad field measurements will be much more powerful. But they will be different.

I very much supported the use of filters when proposed by Michael Richmond. This at least gives us a chance to compare our results to those of others. I do not expect that we will get close agreement. Whether it will be 1 magnitude or 0.01 magnitude, we will see a difference between the tass measurements and the standard AAVSO procedure. I think this will be a problem even for those using CCD cameras switching back and forth between the various references and the measured star according to the AAVSO procedure. A CCD camera is different from the diodes previously used and will give a different result. This no matter how hard one tries to derive transformation coefficients.

As one with an explorer temperament, I would prefer to start by doing the search. I would hope that we do not do anything during the search that compromises the quality of the measurements for later calibrations to the standard procedure. I think we have done an essential procedure by using filters. I hope we can have an active discussion of this before we start taking serious data so that we add procedures where appropriate.

Herb Johnson hjohnson@pluto.njcc.com
Oct 9, 1996

Summary: Chris makes the point that photometry against multiple stars is self calibrating. I say that equipment fails in time, catch it early: and there may be other uses for the data that might necessitate "bench" calibration. Tom says "sky effects, bugs on the lens create greater problems". I say, you control what you can - the instrument - and leave the sky to God. But if Tom will not support recalibration, then at least document what such a procedure would measure so someone else could do it if one wishes.

I will not further the argument from here. It is not my practice to debate other people's hardware and software past two presentations of my position.

Hope these points are useful - Herb 

*>> [Herb said...]
*>> .... I suspect it would be reasonable to
*>> ship TASS cameras back to Tom on some regular basis for re-calibration.
*>
*> This should not be required.  Short term stability is more important then
*> long term stabitilty.  As long as the camera works it should be usable.
*>
[snip]
*> photometry does not require that your instrument remain calibrated over
*> long periods of time and it does
*> not require _absolute_ calibration at all, 
*> only the ability to measure relative 
*> brightnesses [between known stars] in multiple passbands.
I'm aware of how simutaneous photometry of multiple stars works, and that you can self-calibrate against known stars. I'm also aware, for instance, of an Ohio State radio survey 20 years ago that used background noise as a standard, because they were looking for DEVIATIONS from noise as potential signals. When they found a strong event, the software logged it in standard deviations from the RMS noise level. Now, 20 years later in reviewing the data, there are long debates on what the ABSOLUTE level of the signal was: as the measurements were dependent on both the qualities of the instrument and the noise level at the time, qualities that were not re-established and reviewed (or recorded except as raw chart recorder data), the absolute level of this event is debatable. Another group would like to use this level as a detection criterion for further work, but what level should they use? There is little interest in reviewing "someone else's old data", not to mention trying to reconstruct the original conditions.

This story has three points: one, that all the potential uses of the data were not apparent when it was first collected. Two, the value of establishing a reliable and stable calibration for the data and the instrument. And three, retroactive calibration is MUCH harder than proactive calibration. THere is little harm in going the extra mile to do calibrations at some interval; say every few years. I'm an engineer and also experienced in working with computer equipment *decades* old. When I hear an argument that does not mention equipment but only principles of observation, I am suspicious.

There is a lot of fun in building new instruments, looking at new data, writing new programs. Maintenance and calibration are not considered new or fun, and so these issues are often neglected, particularly by (excuse me) developers. I *could* construct arguments like "dedregation of filters exposed to daylight", "drift of voltage references", "increased noise of junctions with time and temperature", "damage to CCD elements from occasional solar exposure", even "ESD and EMI damage from lightning or power surges". The fact is that it doesn't matter WHAT kinds of failures and decays occur, these things happen eventually. So you try to "beat the odds" by preventative maintenance and calibration checks. Also, if these are accepted as a necessity, then such an intent can be "designed in" with testpoints and procedures developed during design, rather than years hence.

I also recall that Tom designed these instruments from ground zero (and quite well let me add). A chance to review a Mark III camera with two years field use can't help but improve a Mark VI camera design (or Mark III upgrades).

Since all equipment suffers from these problems, this is certainly not a dig at Tom's design. Indeed, if a calibration after a year or two confirms Tom's conjecture of "less than .01% change", then he's a winner and we are all winners. Even if he's wrong, we recalibrate accordingly and we still are ahead. But if some drift or error occurs but is not found until well after, it means at best recalibration and at worst bum data. Tom knows all this stuff, it's been his bread and butter, so this is only a reminder to most of us.

In a subsequent message, Tom says "we calibrate against the sky.... changes to the sky, bugs on the lenses...create effects orders of magnitude greater than [potential instrument changes]".

Good! Then a bench recalibration will not take too long. We can't control the weather or acts of God, but we can keep after the consequences of time and tide. But Tom, if you really really ARE dead-set against bench recalibration, since you'd likely be the one to do it; then can you make sure that if someone ELSE was foolish enough to do this, that you'd have documented what would be reasonable to measure in the camera and where to measure it? And make and record some of these measurements as part of your final testing before shipping the instrument?

Michael Richmond richmond@astro.princeton.edu
Oct 9, 1996

Tom is somewhat conservative in his estimate of our ability to convert TASS magnitude measurements to the standard system: 

>  I do not expect that we will get close agreement.  
> Whether it will be 1 magnitude or 0.01 magnitude, we will see a 
> difference between the tass measurements and the standard AAVSO 
> procedure.  I think this will be a problem even for those using CCD 
> cameras switching back and forth between the various references and 
> the measured star according to the AAVSO procedure.  A CCD camera is 
> different from the diodes previously used and will give a different 
> result.  This no matter how hard one tries to derive transformation 
> coefficients.
My experience has been that one can match measurements to about 0.05-0.10 magnitudes pretty easily, as long as one is using "reasonably standard" equipment (TASS qualifies as such) and as long as one is looking at normal stars (the great majority of stars _are_ normal). That is, the systematic error between magnitude measurements made by different telescope+detector systems can be matched this well most of the time. I suspect that we'll be able to do _at least_ this well with TASS. For many, many (but not quite all) classes of variable stars, and for just about all transient events, this amount of a systematic error is acceptable.

While I agree with Tom in spirit, that broadband UBVRI photometry is in some sense a relic of photomultiplier tubes, it's also true that a) any system one picks will become a "relic" eventually, and b) PMTs are still the best instruments for high-precision photometry. So I'm not opposed to hewing to the "old" UBVRI system -- not at all.

Herb Johnson (and others) have pointed out that we must be very, very careful to make sure that the TASS cameras don't suffer from long-term (or short-term!) response variations; or, if changes in reponse _do_ occur, that we be able to characterize those changes. Fortunately, there is (at least) one simple way to do this: if we measure (the same) stars every night, and keep track of the photometric solution values 

             Kv  = zero point of magnitude scale
             Cv  = color term
then we have _some_ measure of the response of the instrument. I have seen reports from 20 or 30 years of photometric observations at single sites, with plots of the above quantities as a function of time: the "zero-point" value typically falls gradually (by 10% per 100 days, in one case) due to dust building up on optical surfaces, then jumps up immediately when the surfaces are cleaned. The "color-term" value usually doesn't change much -- but if the camera response did change, say, due to exposure to the sun, the "color-term" value _might_ show it.

We have a little extra work to do in interpreting the meaning of changes, because TASS cameras always look at the same section of the sky; thus, if the extinction increases (due to a volcanic eruption, for example), it will cause a change in the "zero-point" term. We don't measure extinction itself directly, unlike most observatories....

So, if one performs photometric solutions for each and every night, and STORES THE RESULTS, one has a record of _some_ of the instrument properties.

Glenn Gombert ggombert@erinet.com
Oct 10, 1996

Tom has raised some very good points in his E-mail yesterday about the use of TASS camera's and data analysis measurements as well as using the images to search for various types of objects. It seems that to perform either one of these it is desirable (at least ) to calculate the position and (instrumental magnitude) of each object in a TASS image.

It is not desirable to move the camera's from one fixed location to another to get access to calibrated reference stars to make "all sky" photometric measurements. This procedure is generally used at most professional observatories doing "all sky" photometry. Often times in doing such work calibrated globular clusters are used to get a variety of stars (with different color magnitudes) in the same locations. It is desirable then (from a convenience standpoint) to use calibration stars that are in the images themselves to obtain the necessary reference stars. The new Guide Star Photometric Catalog will soon be available and should provide enough reference stars in most TASS images to provide a good basis for photometry in the 2-5% range (probably all that can realistically be achieved) given the large pixel scale of TASS images.

Routine operations to extracting meaningful information from TASS images would then generally consist of: (1). Image Calibration (dark frame / flat field) (2). Object Catalog Generation & Instrumental Magnitude Estimate , (3). Identifying Stars in the image for Astrometry and Photometry (4). Using these key reference stars to calculate the RA & Dec (position) and absolute magnitude for each object in the image frame. Without a basic calculation of the position and (instrumental) magnitude of each object in the frame it would not be possible to perform much real "science" with TASS images.

However once the above operations have been performed it will probably be relatively straight forward to search for various kinds of objects between data taken on different nights and between different camera installations. The combination of software that is used to perform these various operations may vary from site to site depending upon individual project goals and interests, but the results from each site should have enough of a common baseline so that data / results from each site could be compared and correlated in a meaningful way.

Tom Droege droege@fnal.gov
Oct 10, 1996

I am beginning to feel a great itch to get started looking at data.

Since I don't have the wonderful programs that might some day appear, I plan to work with what I have. So I will set up a single camera and start taking data, probably with a "V" filter.

The plan is to start now and take data late in the night. Then as the sky progresses, try to take the same piece of the sky every clear night. Since winter is coming, I should be able to follow my patch of sky for 5 or 6 months, and get 20 or so measurements on each star. An hour of data should give me 2000+ stars. I will avoid the milky way.

I will then process the same hour or so of sky taken with Norman Molhant's software through Mike Gutzwiller's Deep Sky. This will give me a star list in camera co-ordinates. I will pick out a a few stars - probably get Michel's Landot list - and do a very crude normalization. I will probably also try to convert to sky coordinates. Previous trials indicate that this is not so hard to do if you are not after high accuracy.

I will, of course, take all the data I can get ane keep it in raw form so it can be processed properly later.

I can now think of lots of ways to process the data list. One is to just fit each list to the mean of all the other lists and go for a minimum. Once I have the best fit I can throw out data sets that fit poorly. These probably have too many clouds.

Now I can look for stars with a large sigma. 10 or 20 data points should be enough to find something that is not in the variable star catalog.

Now I will do one more thing that should put the AAVSO to rest. I will get a photometer for my LX-200 and go and look at the candidates using the standard AAVSO procedure.

This gives me material for the PASP paper that I have been struggling to write. It is hard to write (for me) a tass paper without data. I know good data directly from tass is some time away. But if I use it as a search tool, then I can imagine writing a proper paper by late spring.

What do you all think?

Peter McCullough pmcc@astro.uiuc.edu
Oct 11, 1996

Hello TASS members -

This is my first email directly to tass.

Tonight, if it is clear, comet C/1996 R1 (Hergenrother-Spahr) will begin its pass across the celestial equator. It is expected to be magnitude 12.5. So it presents a good opportunity for tass to verify its comet-catching abilities. So everyone with a working camera should try to get data on it, as those data will be useful for optimizing comet-searching software.

All this info and more can be had at

http://cfa-www.harvard.edu/cfa/ps/Headline/1996R1.html

Also, on an unrelated but perhaps interesting note:

I point you to the mysterious object (I now call it the Vais object, after the student who discovered it). It is described in a memo at http://www.astro.uiuc.edu/stardial/tass.oct03 If anyone else happened to be observing that same space-time vector, I'd love to hear from them!

Benoit Schillings benoit@be.com
Oct 11, 1996

Well, I though that the following story would be interesting !

As I mentionned in a previous message, I now have a sky survey system working in my garden... it is composed of a 4 inch F/4 reflector drift scanning the area around +3 Dec using an ST-7. The limiting magnitude is about 16.2 and since the weather has been pretty good in California recently, I produce about 200 MB of data every night !

Last saturday, I was doing some test of the system with a friend called Paul Mortfield who pointed at an object on the scan which looked pretty fuzzy.

After checking the palomar survey and a new scan, the object was of course gone.

False hope, this was C/1996 R1... we just didn't have that object in the database !

We had 24 hours of big hope, until...

Now the good news is that the system is working, the data is now automatically reduced, flat fielded and compared to a previous scan, I can also get some aproximate coordinates (down to about 0.5 arcmin).

The camera is controled by a PC (486/50) who transmits the data is real time to a BeBox (dual CPU 603/66) which archives, normalise and compares the data.

The image comparaison is not done in real time yet, but this should work in a few days.

Drift scanning is REAL fun !

Tom Droege droege@fnal.gov
Oct 12, 1996

One of the expected features of tass is that we will have 20 cameras looking at once. We will no doubt be spread out in both time and space, so a funny object seen on more than one camera suddenly becomes very interesting. Note that one camera looks over a time frame of 8 minutes. Particularly in the mid west, we will have many cameras sensitive at one time. If we get a "flash" on a camera we will know it came in an 8 minute time frame. If several cameras see a flash, it will be determined even tighter. See the Alexis note today for something we might see.

I think that astronomers are always seeing funny stuff on their plates. (Can a real astronomer confirm?)

Ed note: Yes, we often do see "funny stuff", but almost always ignore it because we're already behind schedule trying to reduce the "normal stuff". MWR
Without duplicate measurements this type of event must be thrown away. Our cameras are spaced far enough apart that except for possibly the Dayton - Cincinnati pair, they will not see the same local object - satelite or meteor for example.

So guys and gals, lets get them cameras up and taking data so we can find great stuff!

Tom Droege droege@fnal.gov
Oct 14, 1996

I am down into the details designing the Mark IV. Does anyone know where I can call up and order a 2" clear aperture shutter that is electrically actuated? Don't worry, I can drive anything. Would prefer one that toggles. I.e. actuate to open or close and have it hold the state without power. I prefer a place that I can just call and give a credit card number. There is some urgency to get one in my hand as I want to design it in. This also means I want a new device, not something that I can't get ten of some time in the future. However, if there are a dozen good cheap ones sitting on a shelf somewhere, I will take a shot even if they are obsolete.

Alain Maury maury@ocar01.obs-azur.fr
Oct 14, 1996

The one we use on our 2K camera was made by Ilex and sold by Ealing. They are very expensive ( like $1200 here with the command electronics ). Fred Harris told me he had gotten the mechanism for $350. They are 63mm in aperture. I don't know of the US address of the manufacturer.

Mica Wickersham rjw@crl.com
Oct 14, 1996

The Ilex line has been taken over by Melles Griot. Unfortuantely, it is not a toggle type, the power required for the unit with 63.5 clear aperture as stated on the data sheet is 4 to 9 watts! There is also a 42.7 aperture model.

Someone around there may have the Melles Griot catalog "Optics Guide 5", check on page 16-26 or if you send me a fax # i'll send the pages. Dimensions and operating conditions are shown.

There are also the mechanical models which have the same dimensions but include "T" settings. Since they are designed for use with a cable release as in large-format (4X5) cameras, you could use a solenoid to push the cable release and get the toggle action, and there are contacts (for flash sychronization) that are closed when the shutter is fully open so you could get confirmation of the state of the the shutter. Same catalog, page 16-24. The mechanical shutters are widely used in large-format photography and are available used from the usual photo stores. The 63.5 clear aperture would be called the No.5 Universal, and the 42.7 is the No.4.

Michael Richmond richmond@astro.princeton.edu
Oct 14, 1996

I have written software which takes ASCII lists of stars and tries to determine the position in the sky of the image from which the stars were taken, and converts the (row, col) positions to (RA, Dec). There are a number of caveats, and I can't say that it always works. Please read the description 

    automatic astrometry server
which is listed under "Software" on the TASS home page.

The "astrometry server" works by E-mail. You send it a mail message with a properly-formatted starlist, and its sends back the same starlist, but with the (row, col) converted to (RA, Dec) in decimal degrees.

I've had success running it on "clean" TASS images in both I-band and V-band which I have reduced myself, but failed to get it to work on star lists created by Tom Droege. Rats. Perhaps if other people try it, we'll be able to improve it.

There's a teeny-tiny chance that one might be able to use this mechanism on starlists created from non-TASS images, but only under favorable circumstances. I would guess, for example, that a subset of an entire starlist from a STARDIAL image might yield a good calibration, but one would have to be very careful.

Anyway, read the URL, give it a try, and tell me what you think.

In the meantime, I'll move on to a _simple_ photometric calibration ...

Chris Albertson chris@topdog.pas1.logicon.com
Oct 14, 1996

Sinar sells a large format camera system that can be controlled by a computer. Part of this is a lens in a shutter that can be triped by the computer. I saw one of these running (with a CCD digital back attached) at the Calumet store in Hollywood California.

Tom, Calument is headquarted in your area. You may try 1-800-calumet. See if they will sell you a shutter. The lens I saw had a #1 or #0 shutter hooked up to a PC. It was doing tri-color (three flash pops per image) imageing with a leaf CCD back. All controlled from from the keyboard.

Shutters have been made in standard sizes for many years so a 30 year old used one could act as a engineering mockup for the $$$ electronic version. Again I'd recomend calling the above number. These guys are _much_ better then the NYC discounters They are the other end of the spectrum high service - non-lowest prices.

Alain Maury maury@ocar01.obs-azur.fr
Oct 14, 1996

Just wanted to point out that the Loral 2K that Tom intends to use for the Mark IV are "rejects" of production runs made by Loral for Leaf's digital cameras. Coincidence that Chris Albertson should point out this possibility to use these shutters...

If somehow, they have been able to stick a Sinar label on the shutter, you may expect to pay a relaticely high price..

Since Leaf does want cosmetically correct CCDs at room temperature, there are a lot of less perfect chips which Loral is able to sell at low price.

Just coming back from the "ESO miniworkshop on CCDs" held last week in Munich. Among the various info that I could echo on this list are the following. Some serious, some less. You can always stop reading from _here_.

To finish with this late message ( it is 3:00AM and raining ), just saw the last IAU circular which announces the discovery of no less than 17 Supernovae discovered in the matter of 3 observing nights. I think it is _very_ impressive.

Ed note: the redshifts of the supernovae range from z=0.09 to z=0.84! MWR
Tom, for the MARK V, please use a thinned 4K device, and also a 4 meter telescope ( diameter, not focal length please ). I will get a outhouse ready for it. ;^)

Jim Hannon jmhannon@inav.net
Oct 14, 1996

This brings up a question I had recently. We sometimes tear apart dead harddrives. The new ones with the voice coil actuators look like they could be used to make a fast shutter. The actuator moves the heads across the disk in a few ms. So it should be able to move a vane easily. Has anyone looked at this for a shutter?

Peter McCullough pmcc@astro.uiuc.edu
Oct 15, 1996

I paid a kilobuck or so for a 64 mm shutter a couple years ago. Here's the info:

Geiss-America, inc., 4821 W. Main Street, Skokie IL, 60077, (708) 674-6800, FAX (708) 674-5854. Contact Le Roy Cohen. Model E 64, 1 176 257, including the extra cost of the extra leaf ($25) for extra darkness when closed. Only sell them with their electronics nowadays, although for my application I didn't use their electronics.

The cost of such shutters is astounding. For TASS-like applications you don't need such high speeds opening and closing. I suggest considering a 35-mm camera shutter mechanism. The toy-train industry makes solenoids for switching train tracks that meet your desire to have a flip-flop toggle.

Norman Molhant molhant@ERE.UMontreal.CA
Oct 15, 1996

I have used with success a low-tech (and inexpensive) shutter that might be worth your trouble investigating this idea:

I made two 64 mm diameter round holes diametrically opposed in a 200 mm diameter alumin(i)um disk, each hole coming to 10 mm of the side of the disk. I then glued the disk (well centered) on the axis of a stepper motor (taken from a former Apple II floppy disk drive, 48 steps per turn), painted the disk matte black and used it for shutter: one quarter-turn (12 steps) to open the shutter, another quarter turn to close it. The stepper is mounted on a large round tin can, with the disk inside the can. The box is painted black inside and outside, with 66 mm diameter holes bored in the top and bottom covers so that the holes in the disk and the can can be aligned to let light through. The tin can is 22 mm high and 208 mm in diameter, by the way. I don't remember how I got it, but it might have been a can of pipe tobacco in its former life... Not sure, though! Simple, inexpensive and easy to make. Four years later, the thing still works (or so says may customer - he still seems to be happy with it, anyway).

Total cost was about $10.-, for the stepper driver and a piece of veroboard. The rest came from my junk room (a junk box would be too small for the amount of junk that keeps floating around here ;^).

Tom Droege droege@fnal.gov
Oct 15, 1996

Thanks for all the advice about shutters. I knew I would get it. Somehow, I don't want to spend $1500 for a shutter. So I am still looking for a better solution.

Someone is sending me a shutter. If this turns out to be a too expensive solution, I have a fall back position. It is a model airplane servo. One I have runs off a PWM 5 volt signal. Very easy to control. It moves about 90 degrees in 0.2 second with about 40 oz in of torque. They are gear driven, and position proportional to the pulse width. When the drive pulse goes away they just sit at their last position drawind no power. This is probably fast enough. These units cost about $30 in any model supply store. I would just make a low mass wheel out of paper backed foam with a hole in it.

I still hope for a package that I could put inside the camera head.

Benoit Schillings benoit@be.com
Oct 15, 1996

I started the second step of my drift scan work, meaning the fun of data reduction !

This was a surprise to see how difficult reliable detection of faint extended sources can be in my drift scan images, the problem is not that much to find an algorithm that detects, but rather to have consistant detection! Over a night, my drift scan system produces about 220 MB of data containing about 500000 sources... my first detection algorithm was correct down to 0.5% which left about 2500 changes to check !!! Obivously WAY too much.

I am now working on a second version of my detection algorithm which works using the following principle :

This gives me a (long) list which then gets compared to the scan of the previous night... differences are marked graphically as an overlay to the image, all that is done using a windowing/GUI interface.

Now to find the faint sources....

Finding the compact source is the same...

Now, one problem with that approche is that some source might be JUST above TRESHOLD1 on one image and just below the next day...

I am now thinking of adding a list of "suspitious" source to the main list, that way when I compare the two lists I can find that there is a suspitous source matching a good source and reject.

I will send the source files when I'm about done.

Any idea, someone ?

[in a subsequent message... MWR]

Another big problem is crowded fields... in that case the star images will overlap a lot which will cause some confusion from one night to another... is this one star or is this two ! I was thinking of using the total flux to solve that one, but this looks like a big headache.

I did some test doing PSF substraction, a little bit like the C-CLEAN algorithm but found out that the little 4 inch F/4 newtonian give a very different PSF at the edge of the field, very painful to work with space variant PSF !!

Did anybody done some test with sextractor to see how consistant the results are ?

How well does it work in crowded field ?

By the way, I see more than 30 asteroids every night, I ignore them for now since I have no good database to check them out.

Tom Droege droege@fnal.gov
Oct 15, 1996

Thanks Alain, for all the useful information. 

> Just wanted to point out that the Loral 2K that Tom intends
> to use for the Mark IV are "rejects" of production runs made by
> Loral for Leaf's digital cameras. Coincidence that Chris Albertson
> should point out this possibility to use these shutters...
It is worse than that. The chips I have are "test" runs made at Ford Aerospace before they were sold down the river to Loral. I have no idea if they will work or not. The pinout is different and the clock scheme is different. I have only an 11th level xerox on one sheet of paper to tell me all that I will know. We shall see if I can get them to work. But I have 11 of them, and it will be worth the effort.

I am designing the electronics so it will go up to 10 MHz or so for read out. Might as well prepare for what is coming. Possibly there will soon be a glut of chips that are no good for high end cameras.

Of course beer is sold in 1 liter glasses. Sigh! I am afraid that I am getting to old to drink more than two or three.

Michael Richmond richmond@astro.princeton.edu
Oct 15, 1996

Benoit is sprinting ahead (rah! rah!), and asks a few questions about the results of his data reduction. Maybe I can provide some advice (but I certainly don't have the answers). 

> Over a night, my drift scan system produces about 220 MB of data containing
> about 500000 sources... my first detection algorithm was correct down to
> 0.5% which left about 2500 changes to check !!! Obivously WAY too much.
Actually, this isn't uncommon at all. In fact, it's my experience that this must always be the case, since _most_ sources are faint, and the exact limit (from one night to the next) is never the same. The most common way to deal with it is: 
     1. detect as many sources as possible one each night
     2. compare the source lists from all nights
     3. discard all sources which don't appear in 100% of lists
           (or 90% of lists, or 50%, or whatever you like)
This sounds harsh, but it _will_ produce a list of consistent sources. Does seem a shame to throw all those faint ones away, doesn't it? :-/ 
> Another big problem is crowded fields... in that case the star images will
> overlap a lot which will cause some confusion from one night to another...
> is this one star or is this two !
The MACHO and OGLE groups use the following method to deal with crowded fields: they take data for a number of nights, and at the end, pick an image from the BEST night (with the best seeing, etc.). They identify stars in this image, and make a "master star list." Then, for all other images (which usually have worse seeing), they shift the image to match the positions in the "master star list", then perform PSF fitting using the "master star list."

If you try to create source lists from each image individually, I don't see a simple way to deal with objects which are merged on some frames but separate on others. Well, you could just throw them all away, but you probably don't want to do that ...

Again, the common theme for groups which perform massive photometry is "Throw away everything but the Good Stuff."

Peter McCullough pmcc@astro.uiuc.edu
Oct 15, 1996

A suggestion on finding unusual (point-like) events in TASS images:

In what follows, we assume images are flat fielded and a high-pass filter has been applied to remove variations in sky background, dark current drifts, emission from the milky way, nebulae.

Store a previous image as a fiducial (call it image A). Store the current image as B. Shift B to match A if necessary; call that B'. subtract: (B'-A). Ignore all pixels in (B'-A) that are near stars detected in A, and find objects. The latter step can be generalized to "ignore all pixels in (B'-A) that were brighter than a given threshold in A and find objects." This simplifies the analysis by only looking in "blank sky." Here "blank"

means that the sky looks like random noise in the difference (B'-A).

A **very** simple alogrithm for "finding objects" is to evaluate if the pixel in question is above some pre-determined value (since we've done the high pass filtering already that removes drifts in background level).

This analysis scheme works well - it is robust against variable stars and sub-pixel misalignments between fiducial and current image - but it is also very simple and no doubt one can do a lot better.

Rik Hill rhill@lpl.arizona.edu
Oct 15, 1996

I don't read all the TASS messages (I get from 100-200 messages/day) but I did read where it seemed that some TASS members are now using IRAF. I use this every day in my work (mostly planetary spectroscopy and photometry). Also there was a message that complained about resolving close stellar images. There is a routine in IRAF that I once used, and would have to find again, whereby you could give the routine a model point spread function from a good stellar image somewhere on the image, scale it for intensity, and it would automatically subtract that from the other image you want to do photometry on. We used this for an occultation of Triton and an 8th mag. star. If someone wants the information I could try and find our notes.

Ed note: Rik is probably referring to DAOPHOT, which is available in IRAF and also as a standalone program. MWR

Benoit Schillings benoit@be.com
Oct 15, 1996

I did some test using this image substraction method... one problem I have with it is that even though I can re-align the images with sub-pixel accuracy, I have some problems in the "wings" of bright stars, after substraction, I find many artefacts around them.

Another problem is that the focus changes a little bit from night to night, this is probably temperature related.

I then tried the idea of rejecting any abnormal pixels within N pixels from a previously detected bright star, but found that I still had a problem with tuning good parameters to specify what a BRIGHT star and what proximity to use.

Also, in order to detect nebular objects (comets), I need to tune the detection to find extended objects with a pixel SN of 1 !!! The eye has no problem finding them.

I uploaded a SMALL part of last night scan in my ftp directory, this will give an idea of the noise etc... note the faint galaxies at the top of the field... the image is in FITS format and is 764x128 pixels... the limiting magnitude is about 16.3 on that one, the image scale is 4.3 arcsec per pixel.

The ftp is ftp.netcom.com in /pub/be/benoit

filename is scan.fts

I would like to add that the scan.fts image can still be improve a bit ! There is still a slight alignment error on the ccd camera which causes an horizontal drift of about 2 pixels, the vertical clocking rate is also off by about 1 pixel.

For extended source this will probably not be very important, I actually find that it works pretty well to identify cosmic rays !

I do not have a very good sky to work with these days, I am in Los Altos which is pretty close from the center of Silicon Valley... I can guess the Milky way in Cygnus on a good night !

The chip is help at -6C during the exposure, it looks like the sky background is the main source of noise.

In order to flat field the image, I compute the median of a column of pixels (512) and substract that from that area of the image, I then move the 512 pixels window and do a weighted sum on the flat line... In code :

void xxx() { float flat_vector[764]; float new_vector[764]; float temp_array[512]; float temp_value; bool first_field; long i; long dx,dy; long vp; short buffer[512][764]; first_field = TRUE; for (vp = 0; vp < total_vertical_size; vp += 512) { load_image_segment(buffer, vp); for (dx = 0; dx < 764; dx++) { for (dy = 0; dy < 512; dy++) { temp_array[dy] = buffer[dy][dx]; } sort(temp_array, 512); new_vector[dx] = temp_array[128]; } if (first_field) { first_field = FALSE; memcpy(flat_vector, new_vector, sizeof(new_vector)); } else { for (i = 0; i < 764; i++) { temp_value = flat_vector[i]*3.0 + new_vector[i] ; temp_value /= 4.0; flat_vector[i] = temp_value; } } for (dy = 0; dy < 512; dy++) for (dx = 0; dx < 764; dx++) buffer[dy][dx] -= flat_vector[dx]; } } }

I typed the code from memory, the source code is at home but this gives the idea.

After that I use a simple pass to supress any BIAS variation in the other axis.

Lenn Gombert ggombert@erinet.com
Oct 15, 1996

Last weekend Dr. Eric Hooper (from the University of Arizona) was in town (as a guest of the Miami Valley Astronomical Society) and was a great help in running a series of experiments on TASS data reduction using the "Sextrator" program and compairing the results with Peter Steton's DAOPHOT program (which is integrated into IRAF). Eric has used DAOPHOT extensivley as a part of his PHD thesis and is an expert in the area of crowded-filed photometry. "Sextractor" works quite well when the FWHM star PSF's are carefully matched to the image that is being processed. The star/galaxy classifer is also quite useful in distingusihing between stellar and non-stellar objects.

Eric has agreed to serve in an advisory capacity to our TASS data reduction efforts and to help with suggestions and modifiying some of his data reduction scripts (in IRAF) over the next several months. I plan to put togeher a TASS applications note on the subject when we get a few more results quantified on several of the sample images that Tom has posted to storm.

Glenn Gombert ggombert@erinet.com
Oct 15, 1996

In regards to a "quick-look" program for TASS data analysis the Spacewatch Program incorporates a technique like this in there "real-time" data analysis program. Below is a description that Alain was kind enough to provide about how their system in France has implemented something similar. This kind of an algorithm would be ideal as a "quick-look" for TASS data followed up by a more rigorous calculation on position and magnitude.

It is on my list of "thing to do" to try and implement an algorithm like this , however the length of the list keeps growing. Hope these idea's are helpful. 

Indeed we have a thing similar to Spacewatch. The way it works should be
similar to theirs.
We first run a crude cosmic ray removal algorithm. It will simply
remove the hot pixel variety, i.e. single pixels cosmic rays.
The way this works is simply that for each pixel you take the 9
pixels  a 3x3 window centered on that pixel ) and calculate a
median ( this is better done " by hand " than by using a quicksort
algorithm ). If the center pixel is higher than so many times
the median value, replace by the median. The so many times is
determined by experiment, but 3 is a good value. You do not
want this algorithm to remove stars or things like that. If you don't
have a good sampling remove this step. In our case it removes a great deal
of false alarms.
Then we run a detection algorithm. I suppose you already have one.
Once we have three scans, we have another algorithm to calculate the
offset between the three scans. As we have the same focal length, and
the same orientation, we use a quick trick which works, i.e. take
all the vectors going from all the detected sources in one catalog
to all the detected sources in the second one, then calculate a histogram
in deltaX and another for deltaY. The offset should be the peak value
of the histogram. And it is... :-)
Then once we have the offsets, we go through each catalog and remove all the
stars ( defined as objects seen on catalog 1 and 2, 2 and 3 and 1 and 3 ).
Because of seeing and atmospheric condition changes, there may be a list,
and there generally is, which has less stars than the others, so a star
is a thing present at the same place twice out of the 3 catalogs.
With this list of stars, we trim the faintest stars and the brightest
stars, which we then compare to the Guide Star Catalog, and we use this step
to calculate the "plate constant" i.e. 
the equations which allows the conversion
from X and Y to alpha and delta on the sky.
With the list of "non stellar objects" which are things which appeared at one
point of the frame, but only on one of the frame, we run the following
algorithm:
For each nonstar of the longest catalog, we look in a 
given window on the second
nonstar catalog. The size of this window has to be proportional to the motion
of a fast asteroid. Say 5 degrees per day. For all objects having 
about the same
flux as the first nonstar in this window on the second catalog, we look in the
third in order to see if there is another nonstar, but now in a much smaller
window which would be compatible with a linear motion ( to within one pixel 
typically ). If you find a triplet, you save three subframes ( 20 pixels )
centered onthe object for visual confirmation. Having 3 frames to check removes
most of the false alarms. At least for us. We are still testing all this,
and should start regular observations soon now...
Good luck with your search program,


References: (Space Watch Telescope)

Rabinowitz, D. L. 1991 AJ 101, 1518-1529 plus plate 92: 
"Detection of Earth-Approaching Asteroids in Near Real Time".

Scotti, J. V. 1994 in Asteroids, Comets, and Meteors 1993, 
A. Milani et al. (eds.), 17-30: "Computer Aided Near Earth
Object Detection".

Jedicke, R. 1995 in New Developments in Array Technology and
Applications, A. G. Davis Philip et al. (eds.), 157-165:
"Automated CCD Scanning for Near Earth Asteroids".

Chris Albertson chris@topdog.pas1.logicon.com
Oct 15, 1996

This Suggestion brings up an interesting point. What is one looking for when one compare two images? Peter McCullough appears to be looking for new objects. Things that are in image A but not in B.

If one is looking for stars that have changed in magnitude by Mag 0.1 his suggestion will not work. (No flame Peter, I bet you were not looking for these.)

Also if one were looking for _moving_ objects there are things you can do if you have many images, (like TASS will have) just ask someone who has worked with radar systems about detection and tracking algorithms. They are able to pull targets way, way out of the noise because they tend to move predictably in straight lines.

IMO at some point in the data reduction chain we will need a fork with a branch for each type of thing we are looking for.

The talk recently has been about photometry. What else are people interested in finding?

Back to image comparisons: One problem I had when playing with the sample TASS data is that when you compare any two images, take any pair, one of them is always made on a better night then the other. So one will _always_ record many objects not recorded by the other. So no mater what I did I always "discovered" hundreds of "new" (or "disappeard") objects.

My conclusion is that you have to photometrically calibrate the images before you compare them. But even then only cary the comparison down to the detection limit of the worst image. Also remember that with drift scan the function that converts ADU to Mag is _not_ a constant even within one image. It gets worse, the detecion limit is not constant either.

Forgetting about any of these details either results in throwing away good data (by over thresholding) or in many more false alarms then could ever by tracked down by hand.

I have not solved this problem. My experiments give way to many false matches for production use. 

> A suggestion on finding unusual (point-like) events in TASS images:
I think your method would work but would only detect relatively bright objects. The problem is in practice image subtraction leaves a lot of "trash" in the diference image. So you find yourself removing it by thresholding it away - keeping only the bright objects. 
> In what follows, we assume images are flat fielded and a high-pass filter
> has been applied to remove variations in sky background, dark current drifts,
> emission from the milky way, nebulae.
> 
> Store a previous image as a fiducial (call it image A).
> Store the current image as B.
> Shift B to match A if necessary; call that B'.
> subtract: (B'-A).
Don't you need to normalize B' so the average ADU values are the same? It would then be c*B'-A 
> Ignore all pixels in (B'-A) that are near stars detected in A, and 
> find objects.
> The latter step can be generalized to "ignore all pixels in (B'-A) that
> were brighter than a given threshold in A and find objects."
> 
> This simplifies the analysis by only looking in "blank sky." Here "blank"
> means that the sky looks like random noise in the difference (B'-A).
> 
> A **very** simple alogrithm for "finding objects" is to evaluate if the pixel
> in question is above some pre-determined value (since we've done the high
> pass filtering already that removes drifts in background level).
Thresholding will find stars but the problem is you need to set the threshold value to high or you also "find" a lot of noise. Better algorithms, those that take advantage of what a point source (like a star) looks like through the optical system can use a lower theshold value.

A simple addition would be to use a "star pass" filter. Replace the high pass convolution kernal with a normalized PSF. This should filter out both high frequency niose and the varing skybackground.

Alain Maury Data extraction...
Oct 16, 1996

I'll throw my two cents in the debate launched by Benoit on how to get useful data on 500,000 or more sources, without having to check manually 5000 candidates. A few points I can say on this rainy day :

Many other possible ideas, but for 2 cents...

PS: Sextractor compiles easily on PC+Linux. If somebody was to work on the source code so as to port it to visual C++ we would be very interested. ( or compile it as a DLL and link it with a simple graphic interface ).

Tom Droege droege@fnal.gov
Oct 16, 1996

Hmmmm! We seem to have two groups of people (with at least one exception). There are those that have telescopes and could be taking data, and for the most part they do not seem to be talking. Then there are those that are talking about analysing data but don't have telescopes. If any of the latter group wants to look at real data, I have some that I am willing to put up on storm. I think I have 4 or 5 nights worth of data taken with a triplet that probably at least partially covers the same sky area. It is work to sort it out and put it up so only ask for it if you are willing to do some work on it. There are at least two days taken after Norman told me how to set the time properly, so it is good to about 1 minute in RA. It comes in 1.4 Mb chunks.

Meanwhile, I seem to be shot down for the moment. I had one chip left that I thought was good, but when I assembled it into a camera it was dead - dead - dead. So I will have to wait until I can get a chip from Kodak. So I probably won't be able to operate until next month. Then it will be tempting to set it up in my new observatory.

Rik Hill rhill@lpl.arizona.edu
Oct 16, 1996 

> I did some test using this image substraction method... one problem I
> have with it is that even though I can re-align the images with
> sub-pixel accuracy, I have some problems in the "wings" of bright
> stars, after substraction, I find many artefacts around them.
I took a look at scan.fts in IRAF. The images look good and fit a gaussian quite well. Radially they were trailed and showed scatter from that but otherwise were fine. 
> Another problem is that the focus changes a little bit from night to
> night, this is probably temperature related.
You would have to get a separate point spread function (PSF) for each image or scan since each one will probably be unique enough so the psf's can't be shared. 
> I then tried the idea of rejecting any abnormal pixels within N pixels
> from a previously detected bright star, but found that I still had a
> problem with tuning good parameters to specify what a BRIGHT star and
> what proximity to use.
Subtraction of one star from another close by one is never perfect and there is always some residual of the subtracted star. But this should, for all intents, be a constant and only a small percentage of the overall light. 
> Also, in order to detect nebular objects (comets), I need to tune the
> detection to find extended objects with a pixel SN of 1 !!! The eye has
> no problem finding them.
>
IRAF has a routine, so I am told, that will do this detection, but I have never played with it. 
> I do not have a very good sky to work with these days, I am in Los
> Altos which is pretty close from the center of Silicon Valley... I can
> guess the Milky way in Cygnus on a good night !
> 
> The chip is help at -6C during the exposure, it looks like the sky
> background is the main source of noise.
>
You could select columns with no stellar images in them (>1%) average them together and subtract that from every other column. 
> In order to flat field the image, I compute the median of a column of
> pixels (512) and substract that from that area of the image, I then
> move the 512 pixels window and do a weighted sum on the flat line...
Flat fielding is not a subtractive process but a divisional one to remove pixel to pixel variations in the response of the chip. I hope this is what your code is doing.

Herbert R. Johnson hjohnson@pluto.njcc.com
Oct 16, 1996 

*>I would like to add that the scan.fts image can still be improve a bit !
*>There is still a slight alignment error on the ccd camera which causes
*>an horizontal drift of about 2 pixels, the vertical clocking rate is
*>also off by about 1 pixel.
*>
*>For extended source this will probably not be very important, I actually
*>find that it works pretty well to identify cosmic rays !
Do not underestimate this serendipious mis-alignment as a method to characterize objects from artifacts! In the Ohio State radio sky surveys, this is one of the biggest challenges, as their analysis is entirely automatic. So, even if you could "improve" alignment you may not wish to do so. 
*>Back to image comparisons:
*>One problem I had when playing with the sample TASS data is that when
*>you compare any two images, take any pair, one of them is always made
*>on a better night then the other.  So one will _always_ record many objects
*>not recorded by the other.  So no mater what I did I always "discovered"
*>hundreds of "new" (or "disappeard") objects.
My work with the Ohio State radio sky survey suggests ways to deal with this. Survey radio telescopes are always working close to the noise level of both sky and equipment. One way they resolve this is by using a "Dicke switch": the reciever input is switched between a noise source and the sky antenna, and the detector is switched at the same rate so these two signals are subtracted from each other. The OSU folks have refined this further by using in effect "two antennas": Practically speaking, they switch between slightly different fields of view in the same antenna (i.e. either side of prime focus) and subtract one view from the other. Since their field of view is "one pixel" of 10 arc minutes by 40 arc minutes (!), "image" resolution is not lost.

Now, our CCD's field of view is too big for this, except at the pixel level. The "A minus B" method we've discussed between DAILY images could be made more "fine grained" by a "pixel A minus pixel A+1" method: subtract the adjacent pixel. One obvious problem would be with artifacts that cover several pixels, like cosmic ray hits and blooming. Resolution is reduced (factor of 2) but noise will decrease (factor of root 2). Some information would be lost if negative pixels are zeroed out, but a workaround might be to generate pairs of images from ((A)-(A+1)) and ((A+1)-(A)).

This method would reduce the effects of sky background, but it only slightly reduces changes in sky transparency. This latter effect would have to be compensated for by a kind of flat fielding: namely, determine a "transparency" coefficient and multiply daily images by this coefficient to normalize each daily image. Knowing the magnitude of stars common to both fields of interest would seem to be the way to go here.

Hope these comments are helpful. I am sometimes hesitant to comment at length like this as I don't always follow TASS analysis discussions at length due to pressures of time and other projects. But I am working to reduce my other commitments to spend more time on this stuff.

Rick Hill rhill@lpl.arizona.edu
Oct 16, 1996 

> Since you work at lpl, do you have any idea of the likelyhood of catching
> a comet (new ) with that kind of scan ? I scan about 120 square degres
> every night down to about 16 ?
In the last two years there have been a number of comets that were discovered ABOVE m(v)=16. So I'd say your chances are proportional to the time spent scanning and the area of sky covered. Several of the comets were nearly naked eye brightness when found! 
> Do not underestimate this serendipious mis-alignment as a method to
> characterize objects from artifacts! In the Ohio State radio sky surveys,
> this is one of the biggest challenges, as their analysis is entirely
> automatic. So, even if you could "improve" alignment you may not wish to
> do so.
This may be useful for sorting out some cosmic ray hits and may not matter much for extended objects, but it would be a problem in synthetic aperture photometry since you would be then forced to use elliptical apertures.

Alain Maury maury@ocar01.obs-azur.f
Oct 16, 1996

In the photographic days, the average ( and very rough ) statistics is that there would be about 300 asteroids ( main belt ) on a plate taken near opposition. Then out of ten plates, there would be a Near Earth Asteroid. Every ten Near Earth Asteroids, there might be a comet. It of course also depends on what the other guys are doing. Last year was good for that since only Spacewatch was active, and I do believe that they are scanning like 70 square degrees down to magnitude 21 3 times every months ( David Rabinowitz could maybe comment ). NEAT is now working and they are scanning a much larger area but to a fainter magnitude. We are waiting for the weather to clear but for now shouldn't do much more than Spacewatch ( less taking into account the weather ) and to a lesser magnitude, since we don't have a thinned CCD chip. We will go 4K next year, or maybe more. Since a single Schmidt plate is 36 square degrees, you can have a rough idea. Of course not looking at opposition but looking near the sun is the way to go for comets. Another back of the envelope calculation tells you that for every 12th magnitude comet found by a courageous visual observer, there are several 15th magnitude comets there to be found by a lazy tasser and some smart software... :-)

Glenn Gombert ggombert@erinet.com
Oct 16, 1996

I have compiled "Sextractor" with Visual C++ and it runs just fine on my Dell Laptop, all I had to do was make sure that the "byte-swap" parameter is declared where necessay (Big Indian vs Little Indian format). I have been using it for the last several months and compairing it with DAOPHOT in IRAF.

A simple GUI is presently in the works and should be finished shortly, it takes the place of the parameter file that is read in from the disk. I would be happy to upload the present executable (it runs on Windows95/NT) to Storm is anyone is interested. I think that Tom has already tried it out..

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

*>Hmmmm!  We seem to have two groups of people (with at least one 
*>exception).  There are those that have telescopes and could be 
*>taking data, and for the most part they do not seem to be talking.
*>Then there are those that are talking about analysing data but don't
*>have telescopes. If any of the latter group wants to look at
*>real data, I have some that I am willing to put up on storm.  I
Speaking for myself, I help Michael Richmond from time to time, so I "almost" have a camera. The point is well-taken. Michael and I have talked about putting data up for others to process. The problem is the sheer bulk of it in general, and that his camera is somewhat inaccessable at the moment and his time is limited.

I mention this becuase we've considered archiving data onto 150 Mb ZIP disks. In short, this medium is relatively inexpensive ($15-$20 US), the drives are cheap, light and portable ($150-$200 US) and in common use for just this application - the transfer of large image-based files. Some scheme whereby ZIP disks become a "medium of exchange" would be most encouraging, I believe: provided that those who have both time and resources for processing data will accept these disks, and of course actually do the "processing". Comments supporting this concept are encouraged.

Chris Albertson chris@topdog.pas1.logicon.com
Oct 17, 1996

I do _not_ want to start another long archive media war but as I have been shopping lately I could not resist posting my findings. The point I want to make is to look at not just the drive but the over all "system". Remember that at one time Kodak gave away cameras.

Zip drives are not bad. I may in fact buy one but let's look at the economics of using zip drives for a large data archive. Let's look at the cost of a drive _and_ media. 

1) Zipdrive - 1GB    $149.95 + 10 * $19.00  =  $340
2) Zipdrive - 4GB     149.95 + 40 *  19.00  =   910
3)           10GB     149.95  100 *  19.00  =  2050

4) 4mm DAT - 1GB     $590    +  1 * $12.00  =  $602
5) 4mm DAT - 4GB      590    +  2 *  12.00  =   614
6)          10GB      590       5 *  12.00  =   650

7) Hard drives (1GB) $185                   =  $180
8) Hard drives (4GB) $185  *  4             =   740
9)             10GB) $185  * 10             =  1850

Notes:

7, 8, 9 are simply buying low-end 1GB IDE drives and swapping them out when they are full. Don't laugh there is a $30.00 kit that makes this an easy one handed no-tools required operation. Kind of like a ZIF socket for hard drives.

4, 5, 6, I assumed a 2GB DAT drive. with 2GB tapes.

We use a 4mm DAT juke box here at the office for backups. Media cost is more importent the drive cost for large datasets. We keep 100+GB in a desk drawer for less about $250 in media cost. We use 8GB tapes.

An other thing to concider (for archival storage) is technology. Will there be drives for the media around in 5 or ten years? #7, 8, 9. solves that problem and I'll bet money on DAT sticking around. Still I may buy a zip drive. They are good for transporting small amounts of data.

Nick Beser beser@aplcomm.jhuapl.edu
Oct 18, 1996

We have our linux server on line (although not accessable outside of the lab). What is the status of the Linux port of the camera control software? Will a 486 linux port be sufficient to run the software?

Herb Johnson hjohnson@pluto.njcc.com
Oct 19, 1996 

*>> [Herb said]
*>> files. Some scheme whereby ZIP disks become a "medium of exchange"
*>> would be most encouraging, I believe: provided that those who have both
*>
*> Chris said:
*>
*>Zip drives are not bad.  I may in fact buy one but let's look at the economics
*>of using zip drives for a large data archive.  Let's look at the cost of a
*>drive _and_  media.
Please note the distinction I made. "transfer medium" does not equal "large data archive" medium. I stand by my statements... 
 
*>around.  Still I may buy a zip drive.  They are good for transporting
*>small amounts of data.
and I'm glad you agree.

Tom Droege droege@fnal.gov
Oct 19, 1996

If you're still looking for a shutter give Phile Brote at DACO Industries a call at (203) 874-2515. DACO makes the dark frame shutter used by SBIG in their ST6 camera. The shutter is actually a small rotary solenoid carrying a dark frame vane. The solenoids were originally made for use as warning indicators in aircraft and spacecraft instruments. When I spoke with Phile he said they could custom make a flag mechanism to your specs.

Oh, and they operate from 12V DC.

Check out http://www.mindspring.com/~tybee/daco.html

Hope this helps,

Tybee Evans Intricate Micro Systems tybee@mindspring.com http://www.mindspring.com/~tybee

Norman Molhant molhant@ERE.UMontreal.CA
Oct 19, 1996

Status or Linux port: in deep trouble - my version of Linux (kernel 1.2.x) does not run with my hardware (100 Mhz Pentium, PNP PCI bus, 2 EIDE hard drives and a bus mastering SCSI interface). I'll have to get hold of a newer version (I learned that yesterday friday, after struggling for a few weeks getting all the hardware in the new computer running together under DOS and trying for the last two weeks to get LINUX to access my second EIDE drive...). And there are nice people telling me how easy it is to get hardware that's Linux compatible and to get Linux running on about any kind of hardware... Bovine feces is what I say! It's a hell of a difficult job, indeed. Anyone knows where I can order a *recent* version of Linux to be delivered by mail? And I mean *recent*, but not *beta*. Something that knows about EIDE drives with multiple access methods (I have a 2 Gb drive that is really 3600 cylinders * 16 heads * 63 sectors but can masquerade as 975 cylinders * 64 heads * 63 sectors - Linux kernel 1.2.x refuses to acknowledge that such wierd stuff can indeed exist...) and 2 EIDE + 1 SCSI controllers working together... Any help whatsoever would be greatly appreciated. My Internet access is too slow to let me download Linux over the net, by the way.

I'm sorry for the delay in producing the Linux data acquisition program.

Michael Gutzwiller Michael_Gutzwiller_at_CMCEF020@maillink.cmic.com
Oct 21, 1996

I've begun real data taking over the last week and a half and now have 5 good nights of data. I've been analyzing the data trying to do photometric comparisons between the different data sets and have some observations to share.

The temperature regulation works fine. I find that the same dark vector works fine for each night. No need to create separate darks for each night, at least compared with the sky background I have.

Noise levels after dark subtraction are around 1 sigma = 60 ADU's. This is completely consistent with my sky backgrounds of 9000 ADU's.

Flats are a problem. I thought I could get a good flat by taking the median of the pixels in each column. And while this seems to produce a flat that levels the particular image, the flats produced this way vary from night to night, something I think shouldn't happen. Though these flats are actually the same to about +- 2 percent we need to do better to get the most from our systems. Has anyone found a good way to produce flats for their TASS camera yet?

Most of my photometric work has been comparing mag 8 stars. At the raw data level a star this bright seems to vary about 0.1 magnitudes from night to night. This I attibute to simple variation in transparency, etc. When comparing the difference in magnitudes between two stars the variance falls to about 0.015 magnitudes. This is certainly much better but not as good as the statistical prediction of about 0.003 magnitudes. I suspect the problem lies in getting good flats at this point.

Many kudos to Michael Richmond for his email astrometric server. It worked fine on the lists I tried. Michael did mention he had problems with the lists Tom produced, is this still true? How bright are the 40 brightest stars in a segment?

Tom Droege droege@fnal.gov
Oct 21, 1996

Great news from Mike Gutzwiller! It is hard for me to just sit here and wait for things to happen. By the next lunation, I should be back in data taking mode.

I will shortly send Chris Albertson a tape with several nights data on it. He can then check out the possible data problem. I think Michael was looking at very old data.

I am very pleased with the stability of the dark frames. That is what I expected. ;^)

A note to Kodak asking if there was something wrong with the KAF-0400E got me one in today's UPS shipment. I found out at the IAPPP meeting that Apogee had found a gain problem. So I don't know if this chip has a problem or not. In any case, they shipped the one I had on back order. The data sheet showed Zero defects.

I will put this in a camera with a green filter. Possibly now I will try to run a B-V combination to provide calibration data for the group. I suppose this means that I should order a second KAF-0400E? Assuming that we can now get some B data, is it meaningful to compare B taken with an 0400E with V taken with an 0400? Anyone want to comment on this?

Chris Albertson chris@topdog.pas1.logicon.com
Oct 21, 1996

I have a very basic astronomy question. A "ball park" answer would be good enough.

What is the distribution of variable stars?

I assume:

You can see what I'm doing. I want to predict what should be detected by a TASS-like system. I need some kind of gross statistical model. I'm looking for a simple model that could be put into a speardsheet of simple program.

Tom Droege droege@fnal.gov
Oct 21, 1996

This is one more opportunity to "push" Bohdan Paczynski's paper which is to be found in the reference section of the tass home page. This (to my thinking) is a fantastic paper which will explain to all what might be done with the tass system.

Chris, this paper answers your quesions and a lot more. It shows, for example distribution plots of some of the known types of variable stars in our magnitude range. It is easy to look at these plots and see that the catalog is incomplete. It also shows plots of several types of known variables compared to all the stars in the sky.

One can just look at these curves and estimate, for example, that we should find 750 new Algols (eclipsing binarys) and 500 or so RS Canum Venaticorum binary stars. These are apparently patchy stars like the sun with huge sun spots. Since these stars have small amplitude changes (0.1 to 0.2 mag), they are hard to find with photographic searches. In each case, tass might more than double the number of such stars known. These are just two of the many types of objects we might look for. The above "discovery" estimates are for only our 3 degree strip of sky. There are lots of new variable stars to be found!

One can use the curves from Paczynski's paper to estimate the total number of variables of each type. For example, there should be about 30,000 Algols of magnitude 13 or less. This compares to 3,000,000 stars of magnitued 13 or less. So 1% (roughly) of all stars are Algols. This is based on the trend for nearby (bright) stars. We cover 2.5% of the sky, so we should measure 75,000 stars and find 750 Algols.

I urge everyong to read this paper.

Ed note: you can find a Postscript version of the paper at http://www.astro.princeton.edu/~richmond/tass/refs/searches.ps

Tom Droege droege@fnal.gov
Oct 22, 1996

I suspect that very few of you have read the paper by Bohdan Paczynski:

"The Future of Massive Variability Searches"

I feel so strongly that this is a great paper that I will make copies of it and send it out to those of you that are unable to get it from the home page. I know it is not so easy as I just spent a good part of the afternoon with the lady with the pointed hat worrying about how to set the addresses and all for a post script file. We only twice printed a few hundred pages of garbage. By the time we were done she got pretty good at calling the queue manager to get the file killed. We at Fermilab have a big Computer department. But once the printer starts killing trees, there is no good way to stop it's rampage. I know this seems silly, but that is what happens when you have a big computer department.

I digress.

Send name and address and I will send back a copy of the paper.

Ed note: you can find a Postscript version of the paper at http://www.astro.princeton.edu/~richmond/tass/refs/searches.ps

Rafael Barbera rbarb@astro.gea.cesca.es
Oct 23, 1996

I'm one of this "dark men" that only read the messages flowing in the list, download all the information posted in the web pages and don't say anything... until today ;-).

Since one year or so i'm working (hard!) to develop a tool that simplify the analisys of variable stars data. First of all. I'm talking about working with light curves. I mean: nothing about photometry... this is not my work ;-) this is a previous work. What my association (GEA) need is a tool for searching periods of variables, drawing light curves and all that. Because we can't found nothing usefull, i write a program. It's a Microsoft Windows program writted in C++.

If you want to know more about it (or view some screen-shots), your can visit the AVE Page (this is the name of the program) at: 

     http://www.gea.cesca.es/~rbar

We don't offer the sources, only the binary program for free.

I hope to recive fe