Tom Droege
droege@fnal.gov
June 1, 1997
Thanks to all of you who provided edits and material changes to the press release. Some of it with extensive changes got to me too late for consideration. It was still read in detail, and is very much appreciated. The problem was that I was already through 2 or 3 passes of re-edits from a number of you and did not want to make major changes that would require another go round.
I particularly appreciate those of you who marked their edits. Some of you came back with just edited text requiring a complete read and compare. Unfortunately I don't have software to do that so I had to read and compare word by word.
Since it has a release date, I will wait a few days and then ask Michael to put it up on the home page.
Chris Albertson
chrisa@wavenet.com
June 1, 1997
> While I am working on other things at the moment, I want to > encourage you all in the development of the on line linux system. > > Consider that you will have a 24 Mb memory to unload one byte at > a time every say 200 seconds. There will be three images of 8 Mb > each to look at. Current thinking is to use a 16 bit ADC and go > a little slower. But to do all three cameras in parallel.
So you are thinking of changing the Mk IV design? I was going to suggest going slower but then thought it is your design, and you were using two 12 bit ADCs as the pair was cheaper then one good 16 bit ADC. There realy is no point is filling the buffer memory so quickly. I guess it shortens the dead time between exposures but you need too "rewind" the barn door anyway. No point going faster then that.
Back to software.
3 * 8MB / 200Sec is not that much data. It works out to 120Kb/Sec. For Disk I/O (or even for direct to tape I/O) this is sustainable for long periods even on not-quite-state-of-the-art PCs. 432MB/Hour is not so bad either but 3.5GB per night adds up. It would fill one of my DAT tapes every night. I think real-time reduction is the only answer if you run at the 200sec frame rate. Sites with very dark skys may want to go deeper.
Good news about the Linux driver. It appears to be reading data off the chip. There are still a few bugs and unimplemented features but it should see stars this comming week. It no longer crashes the computer and it appears that the computer is still usable for normal work with the driver runing.
I can add support for the Mk IV without too much work. I'll write a driver for a simulated Mk IV first. I plan to treat the IV like a Mk III. I'll read out and store one row at a time. Just bigger rows and faster. This should allow limited testing and make some sample FITS files for testing FITS readers. If you go with a 16-bit ADC you will eliminate a big part of the software. Please keep me informed about the Mk IV design.
I know Linux is a pain to install and keep running. I think it may be possible to make the system floppy based. Just boot off a floppy and data is recorded to the DOS (Win95?) drive C: This way you would not have to keep linux installed on the hard drive. You would need a directory on drive C: dedicated to Linux's use. After a reboot back to Win95 the FITS data would be accessable on the C: drive. I'm setting up a 486 from old parts to experiment with.
Tom Droege
droege@fnal.gov
June 1, 1997
Just for fun, I took out pencil and paper and did an exercise. I know that many of you could do this with a data base and with your computer, but sometimes looking at the data with the eyes is fun.
I used Sky Catalog 2000.0. This lists stars to magnitude 8.0. I took a random number generator and picked 10 pages. Each page contains 75 stars.
Page V V? V1 V2 V3 V4
471 3 1 1
356 3 2 1
387 3 3 1
193 1 1
201 1 1
517 1 1 1
9 1 3 2
508 1 1
544 1 1 3 1
473 1 1 1
Total 15 13 2 9 3
V1 means 0.001 to 0.01 mag
V2 means 0.01 to 0.1 mag
V3 means 0.1 to 1.0 mag
V4 means > 1 mag
So 5.6% of all stars are possibly variable. 42/750
3.8% of all stars are variable. 29/750
1.6% of all stars vary 0.1 or more mags. 12/750
0.4% of all stars vary >1 mag. 3/750
Seems to me we should find most of those that vary 0.1 or more
magnitude if we work at it. This should be 1000 or more for
our strip of sky.
Tom Droege
droege@fnal.gov
June 1, 1997
Actually I was planning to use one very fast 12 bit ADC per camera and a gain switching scheme. Next to the $2000 or so cost of a CCD the cost of the ADC is not very important. I use $30 16 bit 10us ADCs. The 12 Bit 0.1 us device also costs $30.
I am now thinking of using 6 (or 12)slower 16 bit ADCs for 3 cameras. This would read out all in about 25 seconds. The tricky bit is whether one should allow overlapping exposures. So one camera could be exposing while another is reading out. The mechanical retrace time for the camera mount goes 128x speed in rewind, so that is not a factor.
All this has come about by my sitting there with a scope and looking at what real CCD signals look like at the ends of various lengths of cable.
I am just pondering at the moment. "Pinky, are you pondering what I'm pondering ..."
Glenn Gombert
ggombert@infinet.com
June 1, 1997
It appears that the IRAS Point-Source database may be of use in helping to identify stars that have extended emission in the deep-red/near-infrared. Even though the astrometry is not very accurate for this data it still may help us in narrowing the field to now which sub-set of say the Field-A stars would make lookging at in more detial worthwhile.
I will try and do a query on a major part of the Filed-A in the database and post the results if they look promising.....
Arne Henden
aah@nofs.navy.mil
June 1, 1997
Tom wrote:
>So 5.6% of all stars are possibly variable. 42/750 > 3.8% of all stars are variable. 29/750 > 1.6% of all stars vary 0.1 or more mags. 12/750 > 0.4% of all stars vary >1 mag. 3/750
Interesting result. I would prefer looking at, say, the Hipparcos/Tycho database completeness limit than the less complete Sky Catalog 2000. Yours are pretty small-number statistics. Also, I don't understand your 3.8% or 5.6% figures, since my reading of your columns are that 15 stars are known to be variable and 13 stars are possible variables, which adds up to 2.0% and 3.7% respectively. No big deal, as it means only a 2x reduction in the numbers. However, the big hit is the amplitude of variation, since the current TASS accuracy of 0.05mag will limit you far more than Tom's suggested 0.1mag level for discovery.
All this is speculation (but _fun_ speculation!). The FASTT results say that at least 0.4% should be variable, which means 30 or so variables in fields A,B,C with the current photometric extraction accuracies and without tuning up the mark III systems, but with more data than currently exists. If the systems are tweaked so that you get round images, perhaps better focussed, and a better understanding of how to optimally extract data from the images is achieved, then this number can only go upwards, and by orders of magnitude. If you use a rough guess at the number of stars in the +-1.5degree strip covered by TASS, then I get around 90,000 total stars and 360 possible variables. Even the 30 from fields A,B,C will be fun to play with!
Chris Albertson
chrisa@wavenet.com
June 2, 1997
There is a new version of the RT Linux based TASS driver on storm.fnal.gov/incoming. I fixed a problem with writing to un-opened files and generally cleaned up file writting. Most of this clean-up was just adding "hooks" for feature to by implemented later. The big thing here is that it no logger core dumps and you can run all three CCDS at once.
Also the "STATUS" command tells you which state the driver is in Idle, clearing, ramp-up, collecting. and which CCDs are turned on.
My ISP (wavenet.com) is having a problem with thier e-mail system. I can send. You and send to me but I can't read it.
Michael Richmond
richmond@astro.princeton.edu
June 2, 1997
I just can't seem to stop working on TN 31. I've added a section at the beginning with introductory material describing the field, the observations, a bit on the reductions; it also has some new graphs showing overall properties of the stars in the Field A, which may help to give non-TASSians a quick grasp of the project's capabilities.
However, I'm by no means finished. If you have any questions or comments, please send them in and I'll incorporate them into the text as appropriate.
The WWW link will always contain the latest version, and you can check the "Revision" keyword at the top of the text to see if anything has changed before looking at the entire thing.
Glenn Gombert
ggombert@infinet.com
June 2, 1997
I have just uploaded a file to storm.fnal.gov /incoming called SMSP-VI.gif that shows the scatter from both the V&I data on the same plot made from Michael's "small" data file) it is interesting to note that the I data has higher scatter than the V data (probably because the "I" data contains more measurements)...
Nick Beser
beser@aplcomm.jhuapl.edu
June 3, 1997
The new linux program has successfully collected dark current on TASS #6. I had it enabled for all three CCD arrays. I have not run the program with the 12 volt supply on.
Chris, can you modify the status command so that it will printout the voltages, currents and temperatures? I don't want to turn on the 12 volt supply with out being able to monitor those values.
The weather forecast is for more rain in the Laurel MD area, but there is a chance that Thursday night may be clear (or at least in spots). We can do a official first light on Thursday.
Nick Beser
beser@aplcomm.jhuapl.edu
June 4, 1997
The RT linux driver is currently being tested using TASS#6 at JHU/APL. The current reading is dropping which indicates that the CCD is cooling down normally. I will examine the data files to get an exact temperature profile. Based on the reduced current reading, I think it is safe to do a remote run tonight.
Tom,
Does this sound OK to you? I don't have a status reading command yet, so I can't get a actual temperature or current profile.
in a subsequent message
The weather is clearing in Baltimore, and tonight looks like a good chance to test the Real Time Linux software. Do you think you will have the mods completed so I can read voltages, temperatures and currents? I plan to run the telescope remotely from home, and use it as a way of fine tuning the VCO setting on the camera.
I have a question about the new software. What would happen to the program if I get a ppp network failure during operation. Does data collection continue? I am presuming that the t3_driver is still in operation, and did not get any new commands from t3_server. If I log in after drop out, and startup the t3_server, will that connect normally to the driver, and will I be able to resume commands?
I thought I might try an experiment lunch time today. I will be in the lab so I can monitor the current reading on the 12 volt supply (and see if it drops off as the TEC cools down).
Chris Albertson
chrisa@wavenet.com
June 4, 1997
see storm.fnal.gov/incoming/TASS_Driver_04JUN97
Hardly qualifies as a "new version", but I added a few lines to tass-fsa.c to make it remember the last value it sampled for each telemetry number. Now when you ask it to print its status it referes to those remembered values. These numbers are exactly the same as appera on the end of every scan line.
The display is ugly and is in raw ADU units but it is a quick fix until we can do a good client interface. It will print out "-1" for any value not yet measured but the measurring starts as soon as you type "BEGIN".
A moving strip chart with set points for an alarm would be real nice :-)
Nick Beser
beser@aplcomm.jhuapl.edu
June 4, 1997
Data has been collected (and is still being collected).
I have examined some of the test files, and they seem to be collecting good data. I will ftp a few to storm later.
I am varing the VCO every 600 or so lines.
This is not unusual, except I am at home, and the telescope is 25 miles away at APL.
Tom Droege
droege@fnal.gov
June 5, 1997
Lots of news to report. TASS has been taking data for a few months and is now starting to find things. You can see our first few variable stars in Technical Note 31 on the tass home page at:
http://www.astro.princeton.edu/~richmond/tass/tass.html
We will give three papers at the American Astronomical Society session on Amateur Professional Collborations on June 10.
Progress continues on the Mark IV camera. We have seen "first light" by a very loose definition. Nothing close to an image, but we have all the proper clocks working and can see the expected signals from the CCD amplifier.
We have backed off on the read out speed for the first units after looking at the signals coming from the CCD. We will now read out the 2k x 2k device in 40-50 seconds for the first camera. But faster 16 bit ADCs are coming, and we have designed the system to read out as fast as 2 MHz.
All the mechanics for the triplets have been designed and are ready to go to the shop. The package is 16" x 16" x 24" and will contain 3 ea. 2k x 2k cameras all looking at the same patch of sky with V, R, and I filters.
We uncovered a major problem with the memory board. It forgets after a few milliseconds. Just what one would expect. We are doing a major redesign. Possibly we will be able to kludge it up to work in a few weeks so we can try to get an image with the hay-wired but working electronics.
Last month I wrote:
---------------------------------------------------------------- "May will be "get all the stuff on all the boards" working month. By the end of the month we should be writing software to try to see light. We also will try to get revised board designs out to the vendors so that we can assemble boards with fewer cut and paste wires in early June for the first light tests. We will still give it the old college try to have first light in June, but this will probably only be "first light", not stars. Getting ready for the AAS presentation will detract from the effort. But it can't be helped." ----------------------------------------------------------------
Well, again we did that. We even got to the point of seeing light so I guess we are a month ahead of schedule. The Control board was made to work, revised, and we already have a new board back from the PC house which we have started to assemble. The Scanner board is being revised to run with a 16 bit 10 us ADC. There was just too many things that could go wrong with the fast two step converter. The memory board is being worked on.
Next Month (June):
This month will be clean up month. We should get the revised Scanner board out in time to have it back in June. Meanwhile we will try to get the memory working so we can try to see an image. We hope to start the memory board PC revisions.
We plan to completely revise the design so we can run a triplet of cameras with one PC and one memory board.
We will also go to AAS and tell everyone what we have been doing.
Chris Albertson
chrisa@wavenet.com
June 6, 1997
Try out TASS_Driver_06JUN97 in Storm's /incoming. I am now (I think) storing the pixels corectly. There is still some things about the hardware and CFITSIO I don't understand but if this does not work at least the results should be diferent and I'll learn something.
If there is still a problem with this would you post both the file it wrote _and_ and known good file made with tm3get that you know includes saturated stars. I'll look at them both with a Hex dump program.
Glenn Gombert
ggombert@infinet.com
June 5, 1997
Alain was kind enought to tell me about a new version of SExtractor that was released by E. Burton on June 3rd. I have converted it over to run under Windoes95/NT. I have tried it out on both platforms and it appezrs to run OK.
There are many new features in the present version including many enhanced photomertic functions as well has greatly enhanced astromertic support for using World Coordinate System (WCS) parameters with FITS format images.
The "readme" file that is included with the "DYTN0605.zip" file details some of the new features. I have not had a chance to try out many of the new features yet (not till after the AAS meeting!).....
in a subsequent message
Shown below is the new catalog parameter file for the lastest release of SEXtractor. It calculates many new astrometric and photometric quantities. The list is quite impressive on these new capabilities.
I will try this new version out on some real-live TASS data after the AAS meeting and post the results.
/*
param.h
*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
*
* Part of: SExtractor
*
* Author: E.BERTIN, IAP & Leiden observatory
*
* Contents: parameter list for catalog data.
*
* Last modify: 01/06/97
*
*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
*/
objstruct outobj;
obj2struct outobj2;
/*--------------------------------- initialization --------------------------*/
keystruct objkey[] = {
{"NUMBER", "Running object number",
&outobj.number, H_INT, T_LONG, "%10d"},
{"FLUX_ISO", "Isophotal flux",
&outobj.flux, H_FLOAT, T_FLOAT, "%12g", "count"},
{"FLUXERR_ISO", "RMS error for isophotal flux",
&outobj.fluxerr, H_FLOAT, T_FLOAT, "%12g", "count"},
{"MAG_ISO", "Isophotal magnitude",
&outobj2.mag_iso, H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"MAGERR_ISO", "RMS error for isophotal magnitude",
&outobj2.magerr_iso, H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"FLUX_ISOCOR", "Corrected isophotal flux",
&outobj2.flux_isocor, H_FLOAT, T_FLOAT, "%12g", "count"},
{"FLUXERR_ISOCOR", "RMS error for corrected isophotal flux",
&outobj2.fluxerr_isocor, H_FLOAT, T_FLOAT, "%12g", "count"},
{"MAG_ISOCOR", "Corrected isophotal magnitude",
&outobj2.mag_isocor, H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"MAGERR_ISOCOR", "RMS error for corrected isophotal magnitude",
&outobj2.magerr_isocor, H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"FLUX_APER", "Flux within a fixed, circular aperture",
&outobj.flux_aper[0], H_FLOAT, T_FLOAT, "%12g", "count"},
{"FLUXERR_APER", "RMS error for aperture flux",
&outobj.fluxerr_aper[0], H_FLOAT, T_FLOAT, "%12g", "count"},
{"MAG_APER", "Fixed aperture magnitude",
&outobj2.mag_aper[0], H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"MAGERR_APER", "RMS error for fixed aperture mag.",
&outobj2.magerr_aper[0], H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"FLUX_APER1", "Flux within fixed aperture #1",
&outobj.flux_aper[0], H_FLOAT, T_FLOAT, "%12g", "count"},
{"FLUXERR_APER1", "RMS error for aperture flux #1",
&outobj.fluxerr_aper[0], H_FLOAT, T_FLOAT, "%12g", "count"},
{"MAG_APER1", "Fixed aperture magnitude #1",
&outobj2.mag_aper[0], H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"MAGERR_APER1", "RMS error for fixed apert. mag. #1",
&outobj2.magerr_aper[0], H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"FLUX_APER2", "Flux within fixed aperture #2",
&outobj.flux_aper[1], H_FLOAT, T_FLOAT, "%12g", "count"},
{"FLUXERR_APER2", "RMS error for aperture flux #2",
&outobj.fluxerr_aper[1], H_FLOAT, T_FLOAT, "%12g", "count"},
{"MAG_APER2", "Fixed aperture magnitude #2",
&outobj2.mag_aper[1], H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"MAGERR_APER2", "RMS error for fixed apert. mag. #2",
&outobj2.magerr_aper[1], H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"FLUX_APER3", "Flux within fixed aperture #3",
&outobj.flux_aper[2], H_FLOAT, T_FLOAT, "%12g", "count"},
{"FLUXERR_APER3", "RMS error for aperture flux #3",
&outobj.fluxerr_aper[2], H_FLOAT, T_FLOAT, "%12g", "count"},
{"MAG_APER3", "Fixed aperture magnitude #3",
&outobj2.mag_aper[2], H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"MAGERR_APER3", "RMS error for fixed apert. mag. #3",
&outobj2.magerr_aper[2], H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"FLUX_APER4", "Flux within fixed aperture #4",
&outobj.flux_aper[3], H_FLOAT, T_FLOAT, "%12g", "count"},
{"FLUXERR_APER4", "RMS error for aperture flux #4",
&outobj.fluxerr_aper[3], H_FLOAT, T_FLOAT, "%12g", "count"},
{"MAG_APER4", "Fixed aperture magnitude #4",
&outobj2.mag_aper[3], H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"MAGERR_APER4", "RMS error for fixed apert. mag. #4",
&outobj2.magerr_aper[3], H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"FLUX_AUTO", "Flux within a Kron-like elliptical aperture",
&outobj.flux_auto, H_FLOAT, T_FLOAT, "%12g", "count"},
{"FLUXERR_AUTO", "RMS error for AUTO flux",
&outobj.fluxerr_auto, H_FLOAT, T_FLOAT, "%12g", "count"},
{"MAG_AUTO", "Kron-like elliptical aperture magnitude",
&outobj2.mag_auto, H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"MAGERR_AUTO", "RMS error for AUTO magnitude",
&outobj2.magerr_auto, H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"FLUX_BEST", "Best of FLUX_AUTO and FLUX_ISOCOR",
&outobj2.flux_best, H_FLOAT, T_FLOAT, "%12g", "count"},
{"FLUXERR_BEST", "RMS error for BEST flux",
&outobj2.fluxerr_best, H_FLOAT, T_FLOAT, "%12g", "count"},
{"MAG_BEST", "Best of MAG_AUTO and MAG_ISOCOR",
&outobj2.mag_best, H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"MAGERR_BEST", "RMS error for MAG_BEST",
&outobj2.magerr_best, H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"FLUX_SOMFIT", "Flux derived from SOM fit",
&outobj.flux_somfit, H_FLOAT, T_FLOAT, "%12g", "count"},
{"FLUXERR_SOMFIT", "RMS error for SOMFIT flux",
&outobj2.fluxerr_somfit, H_FLOAT, T_FLOAT, "%12g", "count"},
{"MAG_SOMFIT", "Magnitude derived from SOM fit",
&outobj2.mag_somfit, H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"MAGERR_SOMFIT", "Magnitude error derived from SOM fit",
&outobj2.magerr_somfit, H_FLOAT, T_FLOAT, "%8.4f", "mag"},
{"ERROR_SOMFIT", "Reduced Chi-square error of the SOM fit",
&outobj.stderr_somfit, H_FLOAT, T_FLOAT, "%10g", ""},
{"WINNER_SOMFIT", "Position of the winning SOM neuron",
&outobj.winner_somfit, H_INT, T_LONG, "%5d", ""},
{"KRON_RADIUS", "Kron apertures in units of A or B",
&outobj.kronfactor, H_FLOAT, T_FLOAT, "%5.2f", ""},
{"BACKGROUND", "Background at centroid position",
&outobj.bkg, H_FLOAT, T_FLOAT, "%12g", "count"},
{"THRESHOLD", "Detection threshold above background",
&outobj.thresh, H_FLOAT, T_FLOAT, "%12g", "count"},
{"FLUX_MAX", "Peak flux above background",
&outobj.peak, H_FLOAT, T_FLOAT, "%12g", "count"},
{"ISOAREA_IMAGE", "Isophotal area above threshold",
&outobj.npix, H_INT, T_LONG, "%9d", "pixel**2"},
{"XMIN_IMAGE", "Minimum x-coordinate among detected pixels",
&outobj.xmin, H_INT, T_LONG, "%10d", "pixel"},
{"YMIN_IMAGE", "Minimum y-coordinate among detected pixels",
&outobj.ymin, H_INT, T_LONG, "%10d", "pixel"},
{"XMAX_IMAGE", "Maximum x-coordinate + 1 among detected pixels",
&outobj.xmax, H_INT, T_LONG, "%10d", "pixel"},
{"YMAX_IMAGE", "Maximum y-coordinate + 1 among detected pixels",
&outobj.ymax, H_INT, T_LONG, "%10d", "pixel"},
{"X_IMAGE", "Barycenter position along x",
&outobj.mx, H_FLOAT, T_FLOAT, "%9.2f", "pixel"},
{"Y_IMAGE", "Barycenter position along y",
&outobj.my, H_FLOAT, T_FLOAT, "%9.2f", "pixel"},
{"X_WORLD", "Barycenter position along world x axis",
&outobj2.mxw, H_FLOAT, T_DOUBLE, "%15e", "deg"},
{"Y_WORLD", "Barycenter position along world y axis",
&outobj2.myw, H_FLOAT, T_DOUBLE, "%15e", "deg"},
{"ALPHA_SKY", "Right ascension of barycenter (native)",
&outobj2.alphas, H_FLOAT, T_DOUBLE, "%11.7f", "deg"},
{"DELTA_SKY", "Declination of barycenter (native)",
&outobj2.deltas, H_FLOAT, T_DOUBLE, "%+11.7f", "deg"},
{"ALPHA_J2000", "Right ascension of barycenter (J2000)",
&outobj2.alpha2000, H_FLOAT, T_DOUBLE, "%11.7f", "deg"},
{"DELTA_J2000", "Declination of barycenter (J2000)",
&outobj2.delta2000, H_FLOAT, T_DOUBLE, "%+11.7f", "deg"},
{"ALPHA_B1950", "Right ascension of barycenter (B1950)",
&outobj2.alpha1950, H_FLOAT, T_DOUBLE, "%11.7f", "deg"},
{"DELTA_B1950", "Declination of barycenter (B1950)",
&outobj2.delta1950, H_FLOAT, T_DOUBLE, "%+11.7f", "deg"},
{"X2_IMAGE", "Variance along x",
&outobj.mx2, H_EXPO, T_DOUBLE, "%15e", "pixel**2"},
{"Y2_IMAGE", "Variance along y",
&outobj.my2, H_EXPO, T_DOUBLE, "%15e", "pixel**2"},
{"XY_IMAGE", "Covariance between x and y",
&outobj.mxy, H_EXPO, T_DOUBLE, "%15e", "pixel**2"},
{"X2_WORLD", "Variance along X-WORLD (alpha)",
&outobj2.mx2w, H_EXPO, T_DOUBLE, "%15e", "deg**2"},
{"Y2_WORLD", "Variance along Y-WORLD (delta)",
&outobj2.my2w, H_EXPO, T_DOUBLE, "%15e", "deg**2"},
{"XY_WORLD", "Covariance between X-WORLD and Y-WORLD",
&outobj2.mxyw, H_EXPO, T_DOUBLE, "%15e", "deg**2"},
{"CXX_IMAGE", "Cxx object ellipse parameter",
&outobj.cxx, H_EXPO, T_FLOAT, "%12e", "pixel**(-2)"},
{"CYY_IMAGE", "Cyy object ellipse parameter",
&outobj.cyy, H_EXPO, T_FLOAT, "%12e", "pixel**(-2)"},
{"CXY_IMAGE", "Cxy object ellipse parameter",
&outobj.cxy, H_EXPO, T_FLOAT, "%12e", "pixel**(-2)"},
{"CXX_WORLD", "Cxx object ellipse parameter (WORLD units)",
&outobj2.cxxw, H_EXPO, T_FLOAT, "%12e", "deg**(-2)"},
{"CYY_WORLD", "Cyy object ellipse parameter (WORLD units)",
&outobj2.cyyw, H_EXPO, T_FLOAT, "%12e", "deg**(-2)"},
{"CXY_WORLD", "Cxy object ellipse parameter (WORLD units)",
&outobj2.cxyw, H_EXPO, T_FLOAT, "%12e", "deg**(-2)"},
{"A_IMAGE", "Profile RMS along major axis",
&outobj.a, H_FLOAT, T_FLOAT, "%8.2f", "pixel"},
{"B_IMAGE", "Profile RMS along minor axis",
&outobj.b, H_FLOAT, T_FLOAT, "%8.2f", "pixel"},
{"THETA_IMAGE", "Position angle (CCW/x)",
&outobj.theta, H_FLOAT, T_FLOAT, "%5.1f", "deg"},
{"A_WORLD", "Profile RMS along major axis (world units)",
&outobj2.aw, H_FLOAT, T_FLOAT, "%12g", "deg"},
{"B_WORLD", "Profile RMS along minor axis (world units)",
&outobj2.bw, H_FLOAT, T_FLOAT, "%12g", "deg"},
{"THETA_WORLD", "Position angle (CCW/world-x)",
&outobj2.thetaw, H_FLOAT, T_FLOAT, "%5.1f", "deg"},
{"THETA_SKY", "Position angle (east of north) (native)",
&outobj2.thetas, H_FLOAT, T_FLOAT, "%+6.2f", "deg"},
{"THETA_J2000", "Position angle (east of north) (J2000)",
&outobj2.theta2000, H_FLOAT, T_FLOAT, "%+6.2f", "deg"},
{"THETA_B1950", "Position angle (east of north) (B1950)",
&outobj2.theta1950, H_FLOAT, T_FLOAT, "%+6.2f", "deg"},
{"ERRX2_IMAGE", "Variance of position along x",
&outobj.poserr_mx2, H_EXPO, T_DOUBLE, "%15e", "pixel**2"},
{"ERRY2_IMAGE", "Variance of position along y",
&outobj.poserr_my2, H_EXPO, T_DOUBLE, "%15e", "pixel**2"},
{"ERRXY_IMAGE", "Covariance of position between x and y",
&outobj.poserr_mxy, H_EXPO, T_DOUBLE, "%15e", "pixel**2"},
{"ERRX2_WORLD", "Variance of position along X-WORLD (alpha)",
&outobj2.poserr_mx2w, H_EXPO, T_DOUBLE, "%15e", "deg**2"},
{"ERRY2_WORLD", "Variance of position along Y-WORLD (delta)",
&outobj2.poserr_my2w, H_EXPO, T_DOUBLE, "%15e", "deg**2"},
{"ERRXY_WORLD", "Covariance of position X-WORLD/Y-WORLD",
&outobj2.poserr_mxyw, H_EXPO, T_DOUBLE, "%15e", "deg**2"},
{"ERRCXX_IMAGE", "Cxx error ellipse parameter",
&outobj2.poserr_cxx, H_EXPO, T_FLOAT, "%12g", "pixel**(-2)"},
{"ERRCYY_IMAGE", "Cyy error ellipse parameter",
&outobj2.poserr_cyy, H_EXPO, T_FLOAT, "%12g", "pixel**(-2)"},
{"ERRCXY_IMAGE", "Cxy error ellipse parameter",
&outobj2.poserr_cxy, H_EXPO, T_FLOAT, "%12g", "pixel**(-2)"},
{"ERRCXX_WORLD", "Cxx error ellipse parameter (WORLD units)",
&outobj2.poserr_cxxw, H_EXPO, T_FLOAT, "%12g", "deg**(-2)"},
{"ERRCYY_WORLD", "Cyy error ellipse parameter (WORLD units)",
&outobj2.poserr_cyyw, H_EXPO, T_FLOAT, "%12g", "deg**(-2)"},
{"ERRCXY_WORLD", "Cxy error ellipse parameter (WORLD units)",
&outobj2.poserr_cxyw, H_EXPO, T_FLOAT, "%12g", "deg**(-2)"},
{"ERRA_IMAGE", "RMS position error along major axis",
&outobj2.poserr_a, H_FLOAT, T_FLOAT, "%8.4f", "pixel"},
{"ERRB_IMAGE", "RMS position error along minor axis",
&outobj2.poserr_b, H_FLOAT, T_FLOAT, "%8.4f", "pixel"},
{"ERRTHETA_IMAGE", "Error ellipse position angle (CCW/x)",
&outobj2.poserr_theta, H_FLOAT, T_FLOAT, "%5.1f", "deg"},
{"ERRA_WORLD", "World RMS position error along major axis",
&outobj2.poserr_aw, H_FLOAT, T_FLOAT, "%12g", "pixel"},
{"ERRB_WORLD", "World RMS position error along minor axis",
&outobj2.poserr_bw, H_FLOAT, T_FLOAT, "%12g", "pixel"},
{"ERRTHETA_WORLD", "Error ellipse pos. angle (CCW/world-x)",
&outobj2.poserr_thetaw, H_FLOAT, T_FLOAT, "%5.1f", "deg"},
{"ERRTHETA_SKY", "Native error ellipse pos. angle (east of north)",
&outobj2.poserr_thetas, H_FLOAT, T_FLOAT, "%5.1f", "deg"},
{"ERRTHETA_J2000", "J2000 error ellipse pos. angle (east of north)",
&outobj2.poserr_theta2000, H_FLOAT, T_FLOAT, "%5.1f", "deg"},
{"ERRTHETA_B1950", "B1950 error ellipse pos. angle (east of north)",
&outobj2.poserr_theta1950, H_FLOAT, T_FLOAT, "%5.1f", "deg"},
{"MU_THRESHOLD", "Detection threshold above background",
&outobj2.threshmu, H_FLOAT, T_FLOAT, "%8.4f", "mag * arcsec**(-2)"},
{"MU_MAX", "Peak surface brightness above background",
&outobj2.maxmu, H_FLOAT, T_FLOAT, "%8.4f", "mag * arcsec**(-2)"},
{"ISOAREA_WORLD", "Isophotal area above threshold",
&outobj2.npixw, H_FLOAT, T_FLOAT, "%12g", "deg**2"},
{"ISO0", "Isophotal area at level 0",
&outobj.iso[0], H_INT, T_LONG, "%8d", "pixel**2"},
{"ISO1", "Isophotal area at level 1",
&outobj.iso[1], H_INT, T_LONG, "%8d", "pixel**2"},
{"ISO2", "Isophotal area at level 2",
&outobj.iso[2], H_INT, T_LONG, "%8d", "pixel**2"},
{"ISO3", "Isophotal area at level 3",
&outobj.iso[3], H_INT, T_LONG, "%8d", "pixel**2"},
{"ISO4", "Isophotal area at level 4",
&outobj.iso[4], H_INT, T_LONG, "%8d", "pixel**2"},
{"ISO5", "Isophotal area at level 5",
&outobj.iso[5], H_INT, T_LONG, "%8d", "pixel**2"},
{"ISO6", "Isophotal area at level 6",
&outobj.iso[6], H_INT, T_LONG, "%8d", "pixel**2"},
{"ISO7", "Isophotal area at level 7",
&outobj.iso[7], H_INT, T_LONG, "%8d", "pixel**2"},
{"FLAGS", "Extraction flags",
&outobj.flag, H_INT, T_SHORT, "%03d", ""},
{"FWHM_IMAGE", "FWHM assuming a gaussian core",
&outobj.fwhm, H_FLOAT, T_FLOAT, "%8.2f", "pixel"},
{"FWHM_WORLD", "FWHM assuming a gaussian core",
&outobj2.fwhmw, H_FLOAT, T_FLOAT, "%12g", "deg"},
{"ELONGATION", "A_IMAGE/B_IMAGE",
&outobj2.elong, H_FLOAT, T_FLOAT, "%8.3f", ""},
{"ELLIPTICITY", "1 - B_IMAGE/A_IMAGE",
&outobj2.ellip, H_FLOAT, T_FLOAT, "%8.3f", ""},
{"CLASS_STAR", "S/G classifier output",
&outobj2.sprob, H_FLOAT, T_FLOAT, "%5.2f", ""},
{"VIGNET", "Pixel data centered on detection",
&outobj2.vignet, H_FLOAT, T_FLOAT, "%12g", "count", 2,
prefs.vignetsize},
/*
{"WINX_SOMFIT", "X Position of the winning SOM neuron",
&outobj.x_somfit, H_FLOAT, T_FLOAT, "%5.2f", ""},
{"WINY_SOMFIT", "Y Position of the winning SOM neuron",
&outobj.y_somfit, H_FLOAT, T_FLOAT, "%5.2f", ""},
{"WINZ_SOMFIT", "Z Position of the winning SOM neuron",
&outobj.z_somfit, H_FLOAT, T_FLOAT, "%5.2f", ""},
*/
/*
{"ASSOC", "ASSOCiated parameter",
&outobj2.assoc, H_FLOAT, T_FLOAT, "%13g", ""},
*/
/*
{"RETINOUT", T_FLOAT, &outobj.retinout, "%13g "},
*/
{""}
};
Tom Droege
droege@fnal.gov
June 5, 1997
Today, a 14 bit 10 MHz ADC appeared on the Analog Devices web site. This will do me. It also comes in a 1.25 and a 3 MHz version for less cost. I think 14 bits will be enough. Of course, it is not really good to 14 bits. But I think 12 bits in almost enough. So I have delayed long enough. The next board will be designed to use this device and the 10 us device that I have not. So upgrade will be easy. I will just lay out the board with both devices.
Sometimes waffling wins.
Chris Albertson
chrisa@wavenet.com
June 10, 1997
I have put TASS_Driver_09JUN97.tgz in the normal place on storm's /incoming dirctory. This may solve the ADU scaling problem. I did the following:
I was able to test here that if the buffer that is filled by tass-fsa does contain unsigned integers in Intel "little endian" format then the FITS file looks good.
Nick Beser
beser@aplcomm.jhuapl.edu
June 10, 1997
I re-ran the Linux test program, and was able to collect some data files. I ftp'd them to storm.fnal.gov (X#R_0609.211)
The data is still not being read correctly.
I am starting the tm3get11 program, and I will ftp a example to storm tomorrow.
Tom Droege
droege@fnal.gov
June 11, 1997
I am just back from the AAS meeting. As such things go we were a great success. I had people come up to me and say that when we started that they did not take us seriously, nd congratulate me on our success. The poster was very active and we had lots of people show interest.
I was grabbed several times to talk to the press. There was also the press conference. I told my best tass jokes, and the house was really cold. Then afterwards they asked me most of the questions. I guess that is the press. I finally got a giggle out of them when asked what motivated me. I replied that I had spent my life being Igor in high energy physics and that now I wanted to spend some time as (Dr) Frankenstein.
There was Dennis DeCicco, myself, and (I think) J Patterson of the Center for Backyard Astrophysics featured at the press conference. Later Patterson came up to me and said that I remined him of Burt Lancaster in the "Rain Man". Hmmm. Perhaps I should be selling snake oil. Lets see "You too can make big money surveying the stars over the internet - sign up now for our two day seminar that tells you all you need to become and expert - only $399".
Afterward we had dinner with Lief Robinson (the Editor) of S&T. He kept saying things too flattering for me to repeat. Some of the others that were there can repeat them, I won't. In any case it is a group success.
I douby that Robinson can avoid doing an article on us. I will leave that to Glenn and those that want to help. Writing for the popular press is a skill that I know I don't have I figure my next publication effort will be a hardware paper for PASP with a little data to show it all worked.
I have no idea of who if anyone will pick up a story on us. I hope you will all watch the papers. The press release went out to the world. If anyone calls you from the press, remember that I do not consider that I have any ownership over the group. So if they call you, you can speak for yourself as a member of tass. In other words, you don't have to clear anything with me.
I think that we have now had our 15 minutes of fame. The next reception won't be so friendly unless we have done some good work. Even then, we will probably never get this kind of approval again. So enjoy it.
Glenn Gombert
ggombert@infinet.com
June 11, 1997
I would just like to echo Tom's sentiments, "all-in-all" it was a GREAT time many good contacts were made and we had a very enthusiatic reception from almost everyone there.
Dr. Bob Havlen (Director of the ASP) also joined us for dinner,he is very interested in what we are doing as well. I two weeks TASS will get somemore good press at the PASP meeting.
I agree with Tom that after all the "hub-bub" dies down we need to refine our measurement technqiues and get on with taking and reducing more data...
Chris Albertson
chrisa@wavenet.com
June 11, 1997
Hello hardware experts,
Here are some very interresting numbers, well interresting to me. Nick Beser took some dark frame data this afternoon using both tm3get11.exe and the RT Linux based Driver. The files called 3*.156 came from tm3get while the X*.969 files came from RT Linux. I computed the table below mostly with IRAF. As you can see I asked IRAF to look only at columns in the range 20..780 to avoid the edges. When I compare the tm3get data with the RT Linux data it appears to me that RTLinux is collecting valid data but only with the polarity flipped. Notice that the mean values for the RT Linux dark frames are the same as the mean values for the tm3get frames if you subtract from 65535 ((2**16)-1). Also notice that the range (MAX-NIN) and STDDEV are about the same. The RT Linux driver currently writes out shorter files of 215 lines to speed up testing so that explains the difference in NPIX, the total number of pixels.
I can think of two reasons for this: 1) the outputs from the ADC chip pass through an inverter on the way to the CPU. 2) The analog part of the camera is rigged so that brighter lights cause a lower ADU value; the reverse of what I would expect. It looks like tm3get corrects for this effect which ever it is.
cl> imstat *.imh[20:780,*] # IMAGE NPIX MEAN 65535-mean STDDEV MIN MAX range 30t0612.156.imh[20:780,*] 681856 30527. 2217. 25012.35492. 10480 31t0612.156.imh[20:780,*] 681856 12835. 218.1 12312.14502. 2190 32t0612.156.imh[20:780,*] 681856 11423. 527.3 10974.25368. 14394 X0R_0609.969.imh[20:780,*] 163615 30213. 35322 1041. 25980.32863. 6883 X1R_0609.969.imh[20:780,*] 163615 52689. 12846 217.2 51144.53200. 2056 X2R_0609.969.imh[20:780,*] 163615 53664. 11871 538.6 39266.54128. 14862
Chris Albertson
chrisa@wavenet.com
June 11, 1997
Something I thought I'd pass on to the group. This may be off-topic but then maybe not?
I just had a phone/e-mail conversation with a person doing a very different type of survey but still using TASS-like drift scan TDI cameras. He is timming lunar occulations. But more then timming, he is measureing the defraction pattern caused by the edge of the moon slicing across the stellar disk. He can measure the diameter of the star and "see" very close binaries. I guess the moon acts as a knife edge and just as the star disappears there is some ocilation in it's brightness cause by defracion.
He uses a telescope with a long focal lenght and reads the scan lines out very fast. Each line gets tagged with a low-drift microsecond clock.
It looks like he is doing a type of optical inferometry on an amateur budget. Does anyone here know how well this technique would work. What are the limits and what would be the period of the interference pattern? His hardware is a lot like a Mk III but is clocked much faster and with much bigger optics.
Michael Richmond
richmond@astro.princeton.edu
June 12, 1997
Chris Albertson writes of a colleague who measures the light curves of stars occulted by the moon, with very high sampling rates (probably one per millisecond or so). There are two things one can learn about stars with this technique, and one bonus item about the moon.
First, one can use the moving limb of the moon as a simple knife edge to detect close binary stars. As the moon moves across the sky, it may cover one component of the binary system a few milliseconds before the other. Let's see ... the moon goes around the sky in about 29 days, so it covers 360 degrees in about 29*24*3600 = 2.5x10^6 seconds. So it moves about 0.5 arcseconds per second. If one samples the light from a photometer every 0.01 second, one can catch a plateau in the dimming of a star between the time the first and second components are covered, even if they are only ~0.01 arcseconds apart.
Second, as Chris mentions, even a single star will show a light curve which isn't exactly a simple, sharp drop. Due to diffraction, the light curve of a single point source covered by the lunar limb will appear to show a series of oscillations with decreasing amplitude --- like a series of strobe-light photographs of a ball bouncing across a table. Real stars, of course, aren't perfect point sources: they are teeny-tiny disks. Disks which are large enough (>= 10 milliarcseconds?) will smear out the oscillations, and, in fact, one can measure the diameters of some stars by comparing the observed light curves against models.
Finally, one can turn the problem around: if one knows the precise location of a star being occulted, the precise position and direction of the moon, the exact location of the observer, and the precise time of occultation ... AND one has measurements made by many observers over a wide area on the Earth ... then one can figure out the exact profile of the moon's limb near the position of the occulation. That is, one can detect mountains, valleys and other surface features at the very edge of the lunar disk.
All very interesting! But can we do it with TASS cameras? No. It requires extremely fast readout rates, and is in my opinion better done with photomultiplier tubes than with CCDs.
Arne Henden
aah@nofs.navy.mil
June 12, 1997
The relevant paper is Laszlo Sturmann, "Application of the TDI Method in Observations of Lunar Occultations," PASP 106, 1165, 1994. There are a lot of interesting features to using a two-dimensional detector for lunar occultations. It improves the signal/noise ratio, allows one to work on fainter stars, and (not commonly considered) allows larger aperture telescopes to be used for occultation work. The same technique can also be used for other occultation events, such as asteroids and outer planet satellites.
However, as Michael Richmond mentioned, this technique requires fast clocking of the CCD for stellar angular diameters, usually at a 1ms/sample rate. The clocking requirement decreases for just looking at binary separations, and also decreases for larger telescopes, as the relevant parameter is how long the shadow remains on the telescope mirror. One millisecond/row is not that difficult with the markIV systems, but may be out of the range of the mark III. In addition, you have to use a fabry lens and diaphragm to select only one star, so the optical configuration is more complex (and undoable with the 135mm lens).
Fun idea, though. You will find a lot of these older concepts being reworked in the CCD/computer age.
Tom Droege
droege@fnal.gov
June 12, 1997
Well, you are right Michael, we can't do it with the TASS cameras very easily. But we can do it with Mark II's and I have a lot of chips left over looking for a use.
Let's see, the moon is about 1/2 degree wide. A 120" focal length lens should just about do it. Now we again bolt down the 20" f/6 and read the ccd out like mad. I figure that we can do fast FAX rates. So we read the 2k device out in 200 us or a line rate of 5000 per second. Since the CCD has a charge transfer scheme built into it, we get an exact 200 us exposure. I would have to work out the numbers, but we can probably find a place where the moon does not saturate the CCD even with a 20" mirror, or we use a smaller mirror and image only brighter stars. I couls only run a 12 bit converter these days, but that may be enough.
At this rate, we would not even have to cool it. But it does produce a lot of data in a short time, and I would have to worry about how to do that. The Mark IV memory would not quit keep up, but I might be able to do 1000 lines a second.
Hmmmm! I guess that is 0.0005 arc second resolution for close binaries. Why isn't anyone doing this?
Now we part the whole mess ahead of the moon and just throw data away until the moon gets near. Then we fill a buffer.
It does not look like this would be very hard to do if someone wanted to put one on a telescope.
What do you think?
Tom Droege
droege@fnal.gov
June 12, 1997
It looks like the AP is running a story on TASS. I don't know anything about it yet, except I received a call from a lady in CN. It appeared in the Waterburry Republician. There is also a photographer coming out at noon from the Batavia Republician to photograph me and my telescope.
Please let us all know if the press contacts you. The way the press release was set up, it encouraged your local paper to contact you. We shall see.
If you name is mentioned, get ready for strange mail. Once you hit the papers you get letters from inmates on death row, etc.. Strange country we live in.
Save them clippings folks. Perhaps we can have a press clipping section on our home page, but don't put up a whole article without permission.
in a subsequent message
Now that there is an AP wire service story out on us, you can probably get your local newspaper to come out and do a feature story on you by simply sending a copy of the AP story and the press release to your local paper. They are always looking for stuff like this, and we are enough different that they will probably be interested.
The press release will soon be on the home page, if it is not there now. Michael, I think I sent you the latest copy, but it does need Bernie and Marty name spelling corrections.
Herb Johnson
hjohnson@pluto.njcc.com
June 12, 1997
*>I just had a phone/e-mail conversation with a person doing a *>very different type of survey but still using TASS-like drift *>scan TDI cameras. He is timming lunar occulations. But more *>then timming, he is measureing the defraction pattern caused by *>the edge of the moon slicing across the stellar disk. He can *>measure the diameter of the star and "see" very close binaries. *>I guess the moon acts as a knife edge and just as the star *>disappears there is some ocilation in it's brightness cause by *>defracion.
This technique is documented in one book in my collection, "High Speed astronomical photometry" by Brian Warner, Cambridge Astrophysics Series, 1988. The phenomena is as you describe. It works better on airless occulting bodies, but the planets can do this also. And, the planets can also produce a "flash" as the star passes directly behind the planet, as the atmosphere acts as a lense (or duct?). This distant "knife edge" can not only resolve binaries, it can provide information on stellar diameters! Since the phenomena occurs in seconds or less, millisecond resolution is important to resolve the "spikes".
Timothy Hager
thager@pcnet.com
June 12, 1997
I opened the Danbury News-Times this morning to an article on backyard astronomers helping to explore the universe and Tom's name lept right off the page at me. It was a good sized article half of which was about TASS and mainly followed the press release. They seemed to really like the "Field of Dreams" analogy.
The remainder of the article covered Joe Patterson's Center for Backyard Astrophysics group and ther was some mention of amateurs discivering asteroids with ccds. It was actually a pretty well written article.
Glenn Gombert
ggombert@infinet.com
June 12, 1997
I have been corresponding with the Danish coordiantor of IOTA on this subject of using the TDI technqiue to time occultaions. He found the article that I wrote on the SBIG home page (with Matt Longmire) on using the ST-6 in TDI mode.
I thought that the group might find it interesting...
Date: Tue, June 3, 1997, 00h55m Danish Daylight Saving Time. Mogens Blichfeldt wrote:
Dear mr. Gombert,
I permit myself to write this email letter to you because I have read your open letter about the CCD drift scan imaging technique which is found on the homepage of Santa Barbara Instrument Group.
My name and address is: Mogens Blichfeldt Jadevej 11 DK-8541 Skoedstrup Denmark Europe Telephone: (int 0045) 86 99 25 57 (Fax can be switch on when asked)I have for a very long time been pondering over the questions of using and how to use CCDs for the observing (i.e. timing) of the occultation events when minor planets occult stars as seen from the Earth.
I am today (for many years now) the Danish coordinator for IOTA for this kind of observations in Denmark.
I have here, where I live, a fully remote controlled 10 inch telescope equipped with a Santa Barbara Instrument Group type ST4X CCD-equipment, with which I am very satisfied.
I am a retired electronic engineer (70 years of age) and have besides an astronomical background been working at the Danish Space Research Institute and by ESO (The European Southern Oservatory) in a period.
Having read your open letter and because I clearly see a large vista of that many more possible amateur telescopes can be made equipped with CCDs when employing the drift scan technique, then because of this technique amateurs may be able to do very efficient studies of the skies using telescopes without motordriven mounts while simply having the telescopes mounted in an open window also in flats in town and through this means being able to reach down safely below the 15th star magnitude with professional quality.
The expenses to stable motordriven telescope mounts and dome observatories thus can be avoided, thereby increasing the number of people being able efficiently to do telescope observational works.
With this vista in view I also foresee a possible boom in the amount observers being able to partake in the observing the occultation-timings of small minor planet events when these objects occult stars.
The fundamental problem is that you can't predict these timing-events with an accuracy better than plus minus 5 to 7 minutes on both sides of the events. Furthermore, the width of the shadow paths which the minor planet casts of the occulted light of the star being passed in front of as seen from the Eart today only can be forecast with an accuracy of only abt.700 to 1000 km.s. As the widths of the individual shadow paths over the Earth approximately are of the same sizes as the physical diameters of the minor planets meeting the event a great lot of observers are needed. This kind of observartions are, on the other hand, essential for the study of minor planets. The event timings should at best be carried out to have an accuracy of abt. 1/10th of a second.
As when studying the your open letter an obvious idea ran through my mind of how easily to combine the essential feature of astrometric work being done using the drift scan imaging technique and how to achieve an effective timing. Therefore, I contacted the Danish dealer, which I know very well, for the Santa Barbara Instrument Group CCDs here, namely mr. E. Persson, and through him I got in direct contact with mr Richard Schwartz the president of the Santa Barbara Instrument Group.
I thus had a telephone conversation with mr. R. Schwartz during which conversation I mentioned the possibilities. He said that it may be advantageous if I directly would take contact with you and gave me your email address to the purpose.
This is the reason for contacting you in this way. Thus I come forward as follows:
Using CCDs and sub-pixel astrometry generally yield astrometric results being easily better than abt. as corresponding to 1/6th of the CCDpixelsize, i.e. by way of example: With a pixelsize corresponding to roughly 3 arc second in the skies an accuracy of astrometric position determination of abt. 0.5 arc second can easily be achieved. I have tried it lots of times, and I repeatedly through employing comparisons reach to this result about the accuracies obtainable through subpixel-determinations.
If drift scaning is employed hereto, then the velocity of read-out shifting of the columns for achieving a timing result of 1/5th to 1/10th second of time accuracy should be madeadjusted so that when observing an object, which undergoes an occultating event, should be somewhat a little less than with a shifting of 1 column per second. The occultation then being observed as a light level "bump" in the image streak which is the image of the object resulting from the CCD in this case.
Subpixel-technic determination of the position of the bump in the streak afterwards has to be carried out, thereby determining in time the position of the "bump" in the streak.
It is evident, that telescopes for this purpose might have to be seated on a motordriven mount to achieve that the individual objects are "viewed" correctly by the telescope during the event, but nevertheless, probably not being a mandatory requirement, in that it is just required, as a minimum demand, that the finding of the object to be viewed by the telescope somehow safely is made possible.
It may also be advantageous to position the CCD in relation to the telescope so that the object viewed produces an image streak running along a diagonal direction in the CCD field to have as long a path as possible, and not, as conventionally, in parallel with a (two) side edge(s) of the CCD.
The PC-clock has to be incorporated in such a manner that the clock-times for the "passing" of the object over the individual pixels each time is made very precisely determined and recorded together with the image results.
Therefore, it is very obvious to me, THAT FIRST OF ALL in the new adaptation of the ST6-CCD-head that the read-out velocity, i.e. the shifting velocity of the columns during read-out of the CCD, is made ADJUSTABLE WITHIN a rather large velocity range. Hereby the timing can be made easily adaptable to various declination values of the timed object in the skies and furthermore to the versatality of mounting as well the telescope as versatality in respect of possibly arranging of and running of (aiding) drift providing motor units of the telescope mount. But very essentially, also to obtain versatality in respect to the rather varying ranges of prediction qualities which nevertheless do relate to the objects expected to undergo occultation events. These comments hereby also are thought to include timing observations of stars appearing (and reappering from) behind our Moon, an important observation work also today being carried out by amateur astronomers worldwide.
This feature of adjustability is essential and important from an observational point of view as far as I can see when the drift scan imaging is going to be employed in practice.
On the other hand, I do visualize a FURTHER IMPROVEMENT being possible and perhaps of high value to be incorporated, and which improvement I have mentioned to mr. R. Schwartz. It is as follows:
If, what could be made to low additional costs, in the ST6-CCD-head two additional RAMs were included, or RAM-"areas", are introduced, then they could be employed in the following manner:
Whenever an image is read-out it is immediately arranged stored in one of the two additional RAMs. When the next image has just been read-out the image is passed to the first of these additional RAMs while the first image is passed further on to the second of the two additional RAMs, etc. A circuit of comparison of the two images stored in the two additional RAMs should also be incorporated. Whenever a difference in the read-out star/object field configuration is encountered (being indicative of an occultation event) the last received image is loaded down to be stored in the PC including clock time information. Hereby the indicated occultation events (more of these may exist due to one or more occultation events being caused by a moon encircling the object (I have myself observed such a case)) do safely and accurately become monitored and timed and the the storing of the CCD-field configuration in the PC serves as further back-up information about the field of observation being the right one. Simultaneously, when later subpixel-determining the event-timing as mentioned above an astrometric determination can also be made if it is wanted, i.e. if the position in the skies of the star being occulted is less well determined, or a recontrolling of the position should be required.
I do remark that the optional possibility with this solution exists that for sake of speed only a portion of the CCD-field configuration only is being compared between the contents of the two RAMs. Reduced field-selection can be made just as already made possible with the Santa Barbara Instrument Group CCDs.
Today it may be hoped that the new Hipparcos/Tycho-catalogues (of which I expect to get a copy in this month) will result in improved orbit-determinations. But, it must not be forgotten, that it will take time to reach this far because orbit determinations unto today fully and principally are based upon evaluating of (older) photographed (and merididian circle determined) positions having been carried out with less good accuracies than the accuracy to be obtained while using the Hipparcos/Tycho-catalogues. But such real prediction improvements being attained for the minor planet events I guess first will be practically achievable in a rather far off future.
Now I will finish this letter in that I would like to ask you a question: Is it possible for me to make the read-out velocity in my ST4X-CCD-head adjustable ?
I hope to receive your comments to my email letter to you and I also do hope that you will receive the email letter in kind manner and treat it accordingly. My hope is just somehow to contribute to the improving of CCD-technique and make it useful for as many people as possible.
Yours truly,
Mogens Blichfeldt
Valerie and Bob Goff
goffaxe@azstarnet.com
June 12, 1997
Doing this in UBVRI would gine you the spectral type and if you did it at non graze and followed the star instead of the moon into an apparent impact at 45 n and 45 s on the moon the egress would be at right angles and one could compute maybe the relative magnitudes brightnesses spectral types and orbital parameters for all of the stars in the path of the moon as a never ending project.
Chris Albertson
chrisa@wavenet.com
June 13, 1997
I have put TASS_Driver_13JUN97.tgz in storm's incoming directory. I think it fixes the ADU scaling problem. If it works or not would you FTP a couple of the FITS files it writes to storm.
It does ADU scaling in two places now. In tass-fsa.c and in write_fits.c I am only able to test the code in write_fits.c so we will just have to run it and see.
I also added a few comments to the FITS header so we can tell who wrote the file and with which version of the software.
Chris Albertson
chrisa@wavenet.com
June 13, 1997
I just looked up a paper from an old issue of Sky and Tel., back when it used to be more technical. It is in two parts, by David Evans, in Sept. and Oct. 1977 issues.
He shows the fringe pattern caused by a point star (zero diameter) being occulted by the moon. If you define the edge of the shadow as the 25% illumination point then you see an interferrence pattern with about a ten meter period and max amplitude of about 135% illumination. You can convert the period from meters to seconds if you know the speed at which the shadow sweeps over the ground.
Real stars are not zero diameter. Both the period and relative amplitude of the fringe pattern change as the stars get larger in appearent diameter and by .015 arc sec the effect is at the limit of what could be measured. .0025 arcsec stars make better targets. The author measured a .0025 star to a std dev. of .0003 All this was in 1977
The point to remember is that you don't measure diameter of stars or close binaries by timming the lenght of time it takes the light to dip. You use instead the period and amplitude of the fringe pattern. For a multiple star system you see multiple patterns supperimposed. It is possable to measure a period very acurately if you can collect several cycles of data.
I had the idea that if you have several small telescopes strung along a line, say 5 meters apart from each other and you time tagged each scan line as it came off the CCD with a usec clock then you could combine the data. Kind of like what they do with radio telescope inferometry. The point of multiple telescopes is, I guess reduced noise due to the atmosphere. I think with only two telescops only 40M apart you could double the lenght of the observation. With enough telescopes the occulation could be made to last of many seconds. 20 or 30 fringe cycles could be measured as the shadow sweeps down the line.
I think this is the way to design a low cost system. We don't care so much about absolute measurements. It is the period that wants to be measured. Another trade off is filters. You want both lots of light and small passband.
So I guess the question this system would answer is "How many binaries will you see if you could see down to one milli-arcsecond?"
Nick Beser
beser@aplcomm.jhuapl.edu
June 13, 1997
I ftp'd two data files to storm.fnal.gov (/incoming)
The first was collected on June 11 with the modified TASS linux software (field mod that we had discussed). As you can see, we have a wrap around when the star is saturated. The file name is: X1R_0610.223
The second file was collected on June 10 with the tm3get11 software. It shows a saturated star with no wrap around. The file name is: 31t0611.809.
Note that there is a inconsistency with the file names. The June 10 files has a newer julian date code in its name. That may indicate a problem with either tm3get11 or the linux software (I can't say which).
Martin Pittinger
PittiMJ1@central.SSD.JHUAPL.edu
June 13, 1997
IOTA does a lot of this distant "knife edge" to provide information on stellar diameters.
Contact is David Dunham ( dunham@erols.com ) or look at http://www.anomalies.com/ or http://www.sky.net/~robinson/iotandx.htm for more information.
Tom Droege
droege@fnal.gov
June 13, 1997
Gosh guys! We made the front page of the Kane Co. Chronicle
I hope you all will continue to report where we have been picked up by the news. The 15 minutes is almost over.
Arne Henden
aah@nofs.navy.mil
June 13, 1997
Chris had a good discussion of David Evans Sky and Telescope article regarding lunar occultations. Like I said, you are really measuring the shadow of the occultation, which is why the 2-dimensional TDI system is interesting, since it divides the mirror up into bands and then tracks those bands across the surface. You can't do that with a 1-D detector like a PMT, and so you improve your signal/noise. Chris also gives an interesting idea of placing several systems in a row for fringe detection. I think that system has many possible problems, not the least of which is that the lunar surface is not smooth, and what each system sees depends on the lunar latitude of the occultation and the angle of the motion of the moon with respect to the line of telescopes.
The real problem with lunar occultations is signal/noise. Remember, each point is a VERY short integration. The canonical number is 1000 phot/cm2/sec/A for a zeroth magnitude star outside the atmosphere. Assuming a bandwith of 1000A, a time resolution of 1msec, and a 20cm telescope, you get 300K photons/msec at V=0, or 3K photons/msec at V=5. Then assume about a 20percent QE for your CCD/filter/telescope/zenith_atmosphere and you have 600 electrons/msec. This has a Poisson noise of ~30 electrons, about equal to the CCD read noise, and so is about the faint limit for such a telescope. There are many other errors, such as the brightness of the moon, scintillation and the fact that the moon does not pass through the zenith for most U.S. sites.
There are not many stars brighter than V=5 that the moon occults, which is why you don't see a lot of stars for whom a lunar occultation diameter is given. Now the above back-of-the-envelope calculation is only for looking at things with millisecond time resolution, so looking for fainter double stars with coarser time resolution is certainly possible. Plus, redoing the known occultation stars again is fun, and if wavelengths are picked that haven't been done before, it can be scientifically interesting as well. The reductions take a fair amount of math and geometry, so be aware of this before getting involved!
Herb Johnson
hjohnson@pluto.njcc.com
June 13, 1997
*> Well, you are right Michael, we can't do it with the TASS *> cameras very easily. But we can do it with Mark II's and *> I have a lot of chips left over looking for a use. *> *> Hmmmm! I guess that is 0.0005 arc second resolution for close *> binaries. Why isn't anyone doing this?This is one of several reasons I'm interested in asteroid work: the opportunities for occultations to obtain stellar information as well as asteroid size and orbit determinations. Some of this stuff can be done with visual observations and small scopes: obviously, the measurements requireing millisecond resolution and 12 bits can't. An additional advantage the amateur has is that these events occur in very small geographic regions, a shadow path on the order of miles for asteroids. Amateurs are more likely to be near the path, or willing to travel to one, than the professionals; and they are also likely to be mobile and ready to jump on short notice as these events cannot be well-determined in advance.
Finally, most amateurs are more interested in imaging than data collection. Even so, when I invited David Durham (noted chaser of asteroid occultations) to lecture to our Princeton astronomy club, our members were impressed and intreigued by the concepts above.
So people do these things as opportunity, interest, time and equipment permits. Speaking of equipment, a lot of amateurs have CCD cameras, but many of them can only do long exposures (seconds) due to limits of the interface (serial) or design (Cookbook camera and PC parallel interface is limited to about a second). There are workarounds but only if you write your own software and the hardware is accomodating.
I'd be interested in some kind of chip or camera, Tom, for this kind of work. Incidently, I have a Cookbook TC-211 camera that I'd like to pass along to anyone interested, for about the cost of the parts. I've done about all I care to with the Cookbook and its hardware and mechanics. If any TASS members or their friends are interested, contact me. The TI TC-211 chip is small but reasonably sensitive, and the Cookbook is a 12-bit cooled camera. (Don't know if there is a Linux driver for it, however. ;)).
Nick Beser
beser@aplcomm.jhuapl.edu
June 14, 1997
The Baltimore Sunday Sun (June 15) has on page 5A the AP article from the AAS Meeting.
Michael Richmond
richmond@astro.princeton.edu
June 15, 1997
I've finished Technical Note 31, which now includes information on stars in both Field A and Field B. You can find the complete Note at http://www.astro.princeton.edu/~richmond/tass/technotes/tn0031.html
It's a little puzzling to me that Field B should have the same number of stars as Field A, despite being at lower galactic latitude, and clearly showing more stars to casual inspection.
I've spent a little time tracking down references to the very reddest stars in each field. Fields A and B each have a single star with (V-I) > 5, which turns out to be a late M giant with strong flux in the IR. People who are interested in such stars, which can be used to study galactic structure, can pick them out VERY easily from the TASS data stream.
Tom Droege
droege@fnal.gov
June 15, 1997
One of the things that I did when the reporters were here was to show them the current discussion on the mail list (between Chris and Nick) and explain what was going on as an example of how the internet works. Sigh! I don't think they understood.
Chris Albertson
chrisa@wavenet.com
June 15, 1997
richmond@astro.Princeton.EDU wrote:
> It's a little puzzling to me that Field B should have the > same number of stars as Field A, despite being at lower galactic > latitude, and clearly showing more stars to casual inspection.>
I think maybe a better say to say this could be "The object detection software found the same number of stars in each feild." I think your observation may tell us that there is something wrong with the way the detections is being done. Perhaps the parametrs are set to convervatively. Before I got started on the RT linux driver I tried experimenting with object detection. I could make lists as long as I wanted by changing parameters. There is the danger of false hits but when you combine data from several nights and several cameras these false hits are thrown out as they will appear as stars with only one observation.
Here is another guess. A blank field would have a low Std Dev or sigma. A crowded field may have a much higher Std. Dev. We use a contant sigma cut off when detecting stars. Maybe this is self regulating. The cutoff should be computed for the system not on a per-frame basis. In other words, perhaps doing noise calculations for each frame could introduce a systematic error causing us to toss out dimmer stars in crowded fields that would be kept in more blank fields.
I'm doing sockets and command line parsing. I'll let someone else work on this one.
John D. Gwinner
gwinner@northnet.org
June 16, 1997
> In any case, the Hipparcos sample of stars, mostly 8 < V < 11, > show that roughly 15% of stars are doubles with separations smaller > than 10 arcsec. ... > This study estimates that 17% of stars with 9 < V < 14 will have > companions between 0.002 - 1.0 arcseconds.Wow, great message. Interestingly, a LOT of popular astronomy texts seem to quote the number of multiples as 2/3rds. For example, "Modern Astronomy", Bradley W. Carroll and Dale A Ostlie, 1996, say 'at least half of all stars are multiple systems'. (page 201). This was a text book for an upper class Astrophysics course at Cornell, and was fairly recent.
That's a big difference. Personally, I go more by the actual star counts, but maybe I'm missing something, like brown dwarf counts?
Any comments?
Michael Richmond
richmond@astro.princeton.edu
June 16, 1997
Several days ago, I wrote about several studies of close optical binary stars:
> In any case, the Hipparcos sample of stars, mostly 8 < V < 11, > show that roughly 15% of stars are doubles with separations smaller > than 10 arcsec. > ... > This study estimates that 17% of stars with 9 < V < 14 will have > companions between 0.002 - 1.0 arcseconds.John Gwinner noticed the difference between these numbers and those quoted for multiple-star systems:
> For example, "Modern > Astronomy", Bradley W. Carroll and Dale A Ostlie, 1996, say 'at least half > of all stars are multiple systems'. (page 201).One big reason for the difference between 15 percent and 50 percent is a simple selection effect: we can't see double stars which are very close together, or which have a large difference in luminosity between the components. I recall one of the two papers stating that any components which differed by more than about 4 magnitudes would appear as a single star, for example.
Consider a "typical" star system which isn't very far away -- say, at a distance of just 100 parsecs. If such a system contained two stars which were separated by 1 AU, they would appear to be only 0.01 arcsec apart, viewed from Earth. Simple optical imaging couldn't separate such a close double. If both stars were like the Sun, they would have an orbital period of around six months. Many binary stars (like Algol) have periods of less than one week, implying that they are MUCH closer than 1 AU. Hence, they would be even more difficult to distinguish.
It seems to me that there are plenty of ways one can "hide" all those multiple-star systems....
Tom Droege
droege@fnal.gov
June 16, 1997
Yep, again the front page. Today, June 16, 1997. The Aurora (IL) Beacon News. I think this is about the last of it. Nice article I am told. Now we can get back to work. It would be nice to try to make a complete list of where we were covered for the home page. I will try to get permission to post extended quotes there.
Paul Bartholdi
Paul.Bartholdi@obs.unige.ch
June 19, 1997
You forget other sorts of double stars: widely separated (>10"), very close (<.002"), spectroscopic (<<.002"). Of course, this is mostly an observational effect. At last, ou have to take into account all those undetectable. For example, spectroscopic will not be detected if the orbital plane is nearly perpandicular to the line of sight etc.
I think that the probability of a star to be "physicaly" double has not changed during the last 20 years, and shurely not decreased. New instruments, as CORAVEL or ELODIE (which detected the first extrasolar planets) or lunar occultations and Hipparcos or the TASS project, have increased the number of detected doubles, refined the statistics, but not changed the basic facts.
Glenn Gombert
ggombert@infinet.com
June 19, 1997
I have just finished putting together my talk for the 109th ASP meeting the weekend of the 27th in Chicago. It is called TASS.ppt (in MS-Windows PowerPoint format). I would appreciate any commects/suggestions about it. I have uploaded it to Sotrm /incoming.
I have some more illustrions to add but the basics of the talk are complete. It will be about 40 minutes with about 10-15 minutes for questions/answers.The talk is not as detailed technically as the TASS talks given at the AAS meeting.
Herb Johnson
hjohnson@pluto.njcc.com
June 19, 1997
*> I think that the probability of a star to be "physicaly" double has not *> changed during the last 20 years, and shurely not decreased. New instruments, *> as CORAVEL or ELODIE (which detected the first extrasolar planets) or lunar *> occultations and Hipparcos or the TASS project, have increased the number *> of detected doubles, refined the statistics, but not changed the basic facts."Basic facts" begs the question. There is little absolute knowledge of which stars in, say, the Milky Way Galaxy are doubles and which are not. New surveys tend to provide more opportunities to test the current THEORIES about the distribution of doubles against ACTUAL observations. There are very few actual determinations of multiple stars, compared to the population of stars observable (the latter a moving target of course!). More opportunities for amateurs to make a difference!
Glenn Gombert
ggombert@infinet.com
June 19, 1997
After several hours of trying MANY different things I was able to get the PowerPoint file converted over to "GIF" images (one for each slide). The file is up on Strom and is called UNIV97.ZIP.
I hope that everyone can now take a look at the talk, Marty will make some comments tomorrow, any other suggestions are most welcome....
Ed note: text-only and GIF versions are available on the TASS home page.
Nick Beser
beser@aplcomm.jhuapl.edu
June 21, 1997
I tested the June 13 version of the linux driver last Thursday night. It produces good star image with the exception of saturated image wrap-around. I will post an example file to storm on Monday. The results were consistant with the fix that I had put in the write_fits routine.
Michael Richmond
richmond@astro.princeton.edu
June 21, 1997
I've received a message from Brian Marsden at the Center for Astrophyics (actually in Cambridge, not Boston, but close enough). He is organizing an informal meeting of people interested in Near Earth Objects (NEOs) for Sunday, July 27. I'll place his announcement at the end of this message.
He asked me if someone from TASS could be present, perhaps even describe the survey very briefly. I can't make it to Cambridge on July 27 -- can anyone else?
Please, please, please --- if you can make it, and would like to attend, send E-mail back to me: richmond@astro.princeton.edu. I'll collect the positive replies and try to help organize things, so that 18 people don't all show up, each thinking that he'll be the only TASSian there. It would be courteous not to flood the entire TASS mailing list with messages like "Me, too!" and "Ooops, sorry, my car broke down." We can set up a smaller subset of people and carry on without bothering everyone else.
Those who do plan to attend might want to start reading up on NEOs now; it will probably help the meeting to make sense. Some good places to start:
Remember, please contact me directly if you're interested in attending.
------------- message describing the NEO meeting follows ------------------
SECOND ANNOUNCEMENT: INFORMAL NEO MEETING JULY 27 IN CAMBRIDGE
There has been a moderate response to my May 2 message proposing
to hold the "informal" NEO meeting in the Pratt Conference Rooms at the
Harvard-Smithsonian Center for Astrophysics on Sunday, July 27, just
before the DPS meeting.
The Center for Astrophysics, alias Harvard College Observatory, is
located at 60 Garden Street, some 10-15 minutes walk west of Harvard
Square (two stops along the Red Line subway from MIT/Kendall Square
toward Alewife), accessible either along Garden Street all the way
from the Square, or by bearing left (following the trolley-bus wires)
when Concord Avenue begins just beyond the Sheraton-Commander hotel--the
Observatory being recognizable from Concord Avenue by the large dome of
the old 15-inch refractor. The Garden Street entrance is at a traffic
light, and it is effectively a continuation of Linnean Street, which
links Garden Street and Massachusetts Avenue, the latter end being a
short distance east of the Red Line Porter Square station, which is
the station beyond Harvard. The Observatory takes up most of the block
bounded by Garden Street, Concord Avenue, and the small cross streets Bond
and Madison, and it is in fact marked on most street maps of the
Boston-Cambridge area. The Pratt Conference Rooms can be immediately
accessed from the outside at the northeastern corner of the Observatory
complex, i.e., the part closest to the Garden Street entrance.
Five main agenda items have been proposed so far, and these revolve
around some of the principal NEO programs. These programs, and the
people who will likely say something about them, are as follows:
1. NEAT. Eleanor Helin, Ken Lawrence
2. LINEAR. Grant Stokes, Herb Viggh, Frank Shelly
3. LONEOS. Ted Bowell, Bruce Koehn, Marc Buie
4. BIGELOW. Tim Spahr, Carl Hergenrother
5. MPC. Brian Marsden, Gareth Williams
There should also be lots of time for discussion. As I see it, the
principal problem areas for discussion are: (a) Funding; (b) Southern
hemisphere. An overhead projector, and hopefully also a slide projector,
will be available.
I propose that the meeting begin at 10:00 a.m., and I expect it
will end by 3:00 p.m. I hope to arrange for lunch to be brought in to the
meeting rooms. It may or may not be necessary to make a nominal charge for
the lunch.
If further people wish to be placed on the program to speak, or if
there are to be changes in the above list, or if there are other
proposed agenda items, please let me know as soon as possible.
It would be useful to have a reasonably precise count of attendees,
particularly of those who would like lunch, by July 7. Recipients of
this message are therefore asked to respond to me by then if they will
in fact be attending (even, to make sure, those who expressed interest
by responding to my earlier message). Preferences concerning lunch
(dislikes, especially) should also be stated. Fine wines can be made
available at cost.
Brian G. Marsden
[bmarsden@cfa.harvard.edu]
Michael Richmond
richmond@astro.princeton.edu
June 21, 1997
I've written yet another long and detailed technical note. This new one tests 2 different methods of extracting magnitudes from TASS images to see if one gives better results than the other, and to see if either approaches the theoretical limits.
It will help me greatly if people who have used their own programs to create star lists from TASS images could read the "Plea for help" in this message. If a number of people send me star lists, I'll run my analysis on them and include the results in an near-future version of the Note.
For those who can't read the entire note, here's the Bottom Line:
The bottom line is that, for bright stars, I am unable to approach the theoretical precision we ought to be reaching with TASS images, even with this comparatively homogeneous subset of images. However, it is possible that we might be able to reduce the scatter significantly from that derived in Fields A and B. We need further tests to find out where the root of the problem lies.
Comments and questions are welcome -- I view TN 32 as still being in a preliminary state.
Nick Beser
beser@aplcomm.jhuapl.edu
June 23, 1997
I will be doing hands on focus testing tonight at TASS #6. If you could look at the three data files that I loaded on storm (X#R_0618.223) in the incoming area and make changes to fix the wrap-around, I could test it tonight. (If you have any other changes I can also test them tonight.) I plan to use the June 13 version for our focus testing, since I can get very short data files over to our web server linux system giving us very high quality feedback.
Michael Gutzwiller
deepsky@fuse.net
June 23, 1997
I got back from vacation yesterday and found I already had work to do for TASS! I've reanalyzed the 4 files Michael is using for his analysis in Tech Note 32. They can be accessed at:
http://home.fuse.net/deepsky/data.html
The have been processed with the latest version of "star" which does aperture photometry not only based on the size of the PSF but circular aperture photometry based on the aperture sizes recommended by Arne some time ago.
Nick Beser
beser@aplcomm.jhuapl.edu
June 23, 1997
Just a note to let Chris and Norman know that linux testing is now going on at JHU/APL TASS #6. I will be on station doing focus adjustment until about 10:30 EDT afterwhich we will run tm3get11 for data collection the rest of the evening.
Arne Henden
aah@nofs.navy.mil
June 23, 1997
I'm back from my pulsation conference with lots of new ideas roaming through a very tired mind. Meetings shouldn't be five days long!
Speaking of meetings, I understand that several of the TASS AAS attendees were going to meet over dinner. Were any ideas raised as to what experiments to run for finetuning the hardware, or decisions made regarding the equatorial survey? Other than completing my CCD book, I have no hard plans this summer and so can help out as needed.
Michael Gutzwiller
deepsky@fuse.net
June 24, 1997
Tom's asked for opinions on our next steps, plans, etc. and I thought I'd share my response with the group. Now that my vacation is over I'll be able to spend more time on TASS related activities, especially since things at work look to be a little slow for a while. I think the important issues to address are, in order of roughly decreasing priority:
Comments?
Herb Johnson
hjohnson@pluto.njcc.com
June 24, 1997
*> One idea no one has yet explored is trying to find _moving objects_ *>from a large collection of TASS star lists.This is my interest in TASS, in that *planetary objects* are likely to be moving relative to the sidereal rate. I've said relatively little on the subject in part because of the AAS project. If and when I get a TASS camera, I will persue this further. I've mentioned this kind of persuit from time to time, with minimal responses.
I'm not inclined to try to find moving objects from star lists: surely it is doable in some fashion, but I'd rather work with the image data and all its additional information. But given the discussions about archiving and transferring raw data, it seems likely I'll have to collect my own raw data. It's not my style to argue at length about this subject, especially with those hard at work supporting the Mark III or the AAS star cataloging project under their tight schedule; and especially in trying to suggest a site "should" store hundreds of megabytes.
I should say I've also been "stung" a number of times when trying to work with somebody's old astronomical data, in order to recover other information. It has been my sad lesson to date that it's very hard to get cooperation or even interest in such endeavors. TASS is remarkable in this regard for offering its data AND documentation without restriction. Just having data available is not enough: again, my experience is that it can't be reduced without documentation, and astronomical researchers aren't always good in documenting their work, especially for someone with different interests. The bottom line is that I want to work first-hand now, not second-hand.
Of course I'd be interested in any ideas Michael has "accumulated" while working across the many star lists and many cameras. Fortunately I can see him in person.
Chris Albertson
chrisa@wavenet.com
June 24, 1997
> I've written yet another long and detailed technical note. > This new one tests 2 different methods of extracting magnitudes > from TASS images to see if one gives better results than the > other, and to see if either approaches the theoretical limits. >> > Comments and questions are welcome -- I view TN 32 as still > being in a preliminary state.
I think you are doing exactly what needs to be done at this time. Find a better data reduction technique.
IMO we are throwing away to much data. Setting the detection limit at 3 sigma is to conservative. Yes going to 1 sigma will catch a lot of noise hits but if we require a star to be dectected three times before it goes into our catalog then any noise hits will go away. The photometry will not be so good for 1 sigma stars which will be about mag 14 or 15 but aren't we also looking for asterids, commets, nova, UFOs and the like. Tossing out a commet because we can only measure it's magitude to >0.5 mag seems wrong. So regardless of which software we use I'd like to suggest that we open the parameters on our detection software somewhat. We can cull these much longer lists down in later stages of analysis.
One comment about your method of finding which method is "best". I propose a method #3 that will give very small scatter and should by your rating system rank far above either "thrughput", curve fitting or aperture photometry. Here is how it works: Method #3 reads an input star list and assigns every star a magnitude of 10.0 That's it, they all are 10.0 (A side benifit of this algorithm is speed) Scatter plots look good. A strait line along the axies clear out to infinity. I'm really only half jokeing here. My point here is that there there are algorithms that could fool your technique. The one above is just the simplest. Problems in numerics can effect an algorithm. Things like integer precision and round off can make an algorithm look either better _or_ worse. If people are doing integer arithmatic there is a great change of introducing these errors.
Is there a way to evaluate data reduction techniques that takes advantage of the fact that well _know_ the magnitude of many of the stars we see? Could we plot mean absolute error and Std dev. of same vs. magnitude. Method #3 would look pretty bad under this evaluation criteria (except for a small region about the mag = 10.0 point where it is perfect.)
Glenn Gombert
ggombert@infinet.com
June 24, 1997
I have been busy (since the AAS) meeting getting my presentation put together for the ASP meeting this weekend. I appreciate Marty and Michael for talking time to review the slides and for Marty taking time to actually make some corrections himself. After I get back next week I will plan on:
Chris Albertson
chrisa@wavenet.com
June 24, 1997
> One idea no one has yet explored is trying to find _moving objects_ > from a large collection of TASS star lists.I've been thinking about it but that is all. I'd had some experience with radar systems. These systems pull moving targets way out of the noise. S/N is expressed as -xxdb with big values of xx. If we think of TASS as a radar with a very low PRF (pulse rate of only about 10 per night for tass vs a few hundred/sec for a radar) we can apply some mature and well thought out detection methods.
> My own plans involve moving to a new job and new state in August, > which will take a lot of my time. When I'm settled, I'll have a > PC on my desktop instead of a Sun workstation, which means that > it will be easy and cheap for me to purchase extra disk space. > I plan to acquire a big disk in September and set up some mechanism > by which TASS operators can send the star lists from ENTIRE NIGHTS > (not just selected areas) and store them in an archive. This > big database will be my main focus for the next six months or so.
I have been wanting to do the same thing. I was going to start on a smaller scale first. I planned on setting up a SQL database server with an ODBC interface. The idea was that automated data reduction software would dump results into the SQL database. Analysis software which could be PC-Windows or UNIX basedcould access the database using ODBC. As you may know, most Microsoft Office products talk ODBC. So a user with Excel on a PC could do a query of the database using only native Excel dailog boxes. At the same time UNIX C code could get at the data via SQL. These SQL servers all good at exchanging data with simultainious multiple clients over a TCP/IP network (like the Internet)
The other neat thing about SQL databases is that they can do quike a bit of the data mashing on the server side. No need to download megabytes of data
I've looked at a few database systems that are available for free. There is some good stuff out there. Postgres95, Msql, MySQL and a new GNU project called GNU SQL Server being written by an group in Russia. IMO Posgres95 is big on features and can handle two dimensional keys like (RA,DEC) but is also big and complex and a bit slow. Msql and MySQL are fuctional equivalents and are intended to be light wieght and fast all come with ODBC and CGI (web) or of course SQL interfaces.
My plan was to get the system working locally then let others have copies. My model was a distributed SQL database where each site would have all the data from thier local camera(s) plus maybe some data downloaded from other sites or from a central database. This is not so hard to setup. Distributed SQL databases have been around for years and as I said there is some good free software out there, enough so that evaluating it takes a bit of time. The distributed approach does not preclude one site having a super-set of all data. It would also be possible for anyone to setup a local copy of the system and populate it with data from other sites.
I think ODBC is important. There are lots of comercial ODBC clients on the market. Most poeple already have a few, even if they don't know it.
Another thing you can do with a SQL server is put a web interface on it. This makes simple queries easy for the non-expert but still allows more sophisticated things like stored SQL procedures for those who need it.
> Of course, this assumes that TASS operators are able and willing > to reduce very large quantities of data and transfer the star lists over > the Internet on a regular basis.
I think the key is automation. The RT Linux driver appears to be working. It needs more bells and whistles and a better user interface. The good news is that it uses very little CPU time. So little that it is hard to measure. Even a 16MB 486 should be able to run processing tasks in the background while collecting data.
I know what you mean about disk prices on PC vs. sun. We pay $1000 for 2GB on a sun but I was in Frys Electronics and they just got some 7GB IDE drives for $499 each. Tests here however show that even the lowly Sun SPARC 4 with it's SCSI drives blows away any PC with IDE drives when it comes to sustained IO performence.
Alain Maury
maury@ocar01.obs-azur.fr
June 25, 1997
I would like to share our own experience on using databases to extract useful things out of a catalog. This is the first thing we did in 1993 when we started to try to detect asteroid of CCD images. We used Postgres ( that was indeed before 1995 ). A student in computer science who was working with us at the time told us that this was the way to do it. He installed the database and went on his way to program the thing, and was able to detect asteroids position. Except it was taking like one hour at first ( remember the 3 frames were 8.5 megabyte frames, which had required each 2 minutes of observing time... ). I complained to him that this was not the thing to do. He told me "you know, I have written this quickly, now I can fine tune in order to decrease the computing time" So he went to "only" 30 minutes of calculations. The main problem seemed to have been caused by the fact that it was not possible to set the cache size and that because there were like 2000 objects ( tuples ) in the database, it was grinding the hard disk all the time. Still I doubt it could have been done faster than using plain, dumb C code.. ). This being said, beware of databases, even smart ones.
The type of request we have to do on catalogs is :
I'd recommend staying out of database programs. Eventhough I can invite you to try it out, just to see if our programmer was a lousy one, which I doubt.
After this failure, this guy went on to try another smart trick which was to use Voronoi trees in order to speed up the search. Very smart, except the size of the catalog grows up almost exponentially with the number of objects. Worked faster though, but would have not been able to cope with a large scan with 200000 objects on it.
It has been since rewritten not as smartly, i.e. in a straightforward manner, and works great and quickly ( in fact it takes less than a fraction of a second to compare two catalogs ).
Tom Droege
droege@fnal.gov
June 24, 1997
Here is what I propose for the rest of the year:
July
Get all the cameras up and running and taking data. Those that have cameras running (I don't at the moment), try taking data under various conditions to look for problems. When I get a camera running (soon I hope) I will try some experiments with the big lens (135mm f/2) that I have to see what aperture is good for.
I plan to beat up on those with cameras that we have not heard much from to try to get them running.
August
Get all the cameras pointing at the same declination. It should just take a little shimming. Good thing to do while the moon is out. Work on finding the best possible focus. Possibly even putting in a little extra glass if that is what it takes for all three lenses to have the same focus.
September ...
Start taking serious data. Try to keep everything running for a year so we get all we can from our strip of sky.
I would like to concentrate on what the Mark IIIs can do well. Moving targets is not their bag. The Mark IV will just wipe out the Mark III when it comes to moving targets, so I would wait until we have some Mark IVs running to go after that problem. There is a lot of good science that can be done with the Mark IIIs just the way they are.
Michael says the photometry is not as good as we might like. While I hope for an inprovement, it just might not be possible to make it better. I have been looking at a paper in the January PASP. It is a calibration of the Monitor telescope for the Slone sky survey. They are attempting to do much the same thing as we. Working on targets in the Mag 15-17 range with a 24" telescope, they should have similar results at mag 15-17 as we have at mag 10-12. I notice that they (table 6) have a 0.05 mag systematic error between their two measurement locations, MT at Apache Point and the 1 meter U. S. Naval Observatory telescope at Flagstaff. Their standard deviation quoted is 0.013 in i* similar to our I filter where we are at 0.028 to 0.09 from TN-32 Table 7. I also note that they only used the nights that data that were considered photometric at two good locations. They are the experts, and have not done all that much better than we have. (Could it be that the same experts are working on our data? It is highly suspicious that Michael works for SDSS and Arne for USNO.)
Michael says:
> Bad stuff: > - the precision of the photometry isn't quite as good as we'd like
The SDSS people don't seem to say something similar in their paper. But I bet that photomitrists always say similar things. I know for a fact that there was something wrong with their camera. But there is always something wrong.
If 0.05 is what experts can do as a systematic error between two locations, then we may not be able to do better. Perhaps Michael or Arne can comment on this paper.
I am not saying that we should not try to do better. I am saying that we should charge ahead and do what tass can do with the instruments we have today and under the conditions where we have telescopes. We shoule not delay starting a serious data run in the hope that we will find some better set of operating parameters. The present cameras will do some nice science, lets do it.
Chris Albertson
chrisa@wavenet.com
June 25, 1997
ALAIN MAURY wrote:
> I would like to share our own experience on using databases to > extract useful things out of a catalog. > This is the first thing we did in 1993 when we started to try to detect > asteroid of CCD images. We used Postgres ( that was indeed before > 1995 ). A student in computer science who was working with us at the > time told us that this was the way to do it. > He installed the database and went on his way to program the thing, and was > able to detect asteroids position. Except it was taking like one hour > at first ( remember the 3 frames were 8.5 megabyte frames, which had > required each 2 minutes of observing time... ). I complained to him > that this was not the thing to do. He told me "you know, I have written > this quickly, now I can fine tune in order to decrease the computing > time" So he went to "only" 30 minutes of calculations. The main problem > seemed to have been caused by the fact that it was not possible to > set the cache size and that because there were like 2000 objects ( tuples ) > in the database, it was grinding the hard disk all the time. Still > I doubt it could have been done faster than using plain, dumb > C code.. ). > This being said, beware of databases, even smart ones.
Postgres was a poor choise if speed was important. A good choise if cost was importent. Other databases are an order of magnitude faster and about that much easyer to use and setup. Postgres95 is better but those other systems, Msql and it's clone MySQL are intended for speed over fucntionality and IMO a better choise for TASS
One other thing a Database does. If you are setting at the other end of a 28.8K modem from the data, it does all the data thrashing on the server side. Much better then transporting the whole 99 gigabyte file down a modem line and doing the data thrashing locally.
> The type of request we have to do on catalogs is : > 1) limited in scope ( when we have a routine to extract asteroids, > variable stars, supernovae, satellites... What else would you want > to detect )... If we were to try a different type of request every > morning, indeed I would recommend a database program, but since we > can write a few, well optimised, procedures, and getting to know > what's inside the program in order to modify it if required, why would > you want to use an all purpose database program, which also tends to be > a memory hog... > 2) very specialised, with very few information to work on ( RA, Dec, flux, > hour of exposure, what else.. ? )
Try this on even the existing, very small TASS dataset:
"Give my a table of all stars between mag 5 and 7 within a bounding box of RA, DEC observed between the present and N years back where each star is observed at least three times. Sort by mag then dec."
This would be very fast. and could be done with a web interface. A user could go the the TASS Database Query web page make a few selections, click on "get" and he'd have a table of data.
Using the ODBC interface a user on a Win95 PC could do some kind of ad-hoc analysis by importing data into his spreadsheet. Spreadsheets are good at making plots and on the fly analysis and most modern Speredsheets will inport data from ODBC servers
TASS is geographicaly distributed. Also, TASS is at it's best when you have access to data from _All_ sites. What A database system will do is minimize the amount of data transferred over the Internet.
> I'd recommend staying out of database programs. Eventhough I can invite > you to try it out, just to see if our programmer was a lousy one, > which I doubt.I think his problem was that he tried to use the database as a general purpose compute engine. I've seen people do this. They write hundreds of lines of SQL code. SQL runs slower than interpeted BASIC. I do not suggest writing much if any code on the database side. The best use of a database for TASS is to cut down on the amount of data shipped over the Internet. So If all I want is stars with S/N > 3 sigma, mag < 8 that have > 3 detections that is all I download.
> After this failure, this guy went on to try another smart > trick which was to use Voronoi trees in order to speed up the > search. Very smart, except the size of the catalog grows up almost > exponentially with the number of objects. Worked faster though, but > would have not been able to cope with a large scan with 200000 objects > on it.
I hate to say it, but I think your problem was using a student programmer. What is the saying, "Don't trust anyone under 30"? I find that students and "fresh outs" are big on theory but have worked on mostly toy sized projects where things like robustness and performence are not importent.
I guess that the MkIV will do like the MkIII and produce one object per thousand pixels per frame. or 4K objects every frame. A triplet running at 100 sec/frame makes for 120 object detections/sec or about one million objects every two hours. I think we need a more sophisticated data handling system than FTP and a /incoming directory.
I think your negative experience with database systems was because your programmer tried to do _computation_ within the DBMS framework. I would use the DBMS for what it is best at, a big automated data bucket and a back-end for a web/ODBC/SQL server.
My professional experience has been with military systems. The diference between these and science type systems, as I see it is that in the scientific world you collect data then sit on it for months or years then publish. With military sensors you "publish" as the sensor is running with a continous process so maybe you can see my bias in system design.
Arne Henden
aah@nofs.navy.mil
June 25, 1997
Chris wrote a very useful email recently on using an ODBC interface. He has some valid points. SDSS is using a commercial database (Objectivity), and we considered one for the PMM plate scan catalog (for instance, USNOA-1.0). At the same time, most of the microlensing groups (MACHO, OGLE) are using their own home-grown systems. I think both approaches work.
The TASS equatorial survey is actually a small database in the current astronomical world. At best, we would have data on 100K stars from 7 sites on 100 nights/year. Most of those stars could be ignored (except in their means), as the interesting ones are variable or moving and they make up a small fraction of the whole.
I get the impression from Chris' comments that he envisions a system where each site keeps its own data, and then the Database Query web page asks for the appropriate subset of information based on the current request. That means that all sites are nodes on the Internet, which is not currently the case. I think that is why Michael R. has offered to keep all the data on his local computer. Perhaps Chris could explain his concept a little more?
It sounds to me like Chris has 'volunteered' for setting up a pilot system!
Arne Henden
aah@nofs.navy.mil
June 25, 1997
Tom opened the door - discussing the Monitor telescope for the Sloan Digital Sky Survey. He quoted results showing a 0.05mag systematic error between Apache Point and Flagstaff. There are a number of reasons for this error, and I'll give you some of them: (1) this is a new photometric system, and they have not set up a system of photometric standards yet. While the filters were purchased at the same time, I'd like to see the transformations between the two sites. (2) they used mean extinction coefficients based on theory not observation. They indicate that up to 0.07mag errors could be introduced from this. (3) this paper was designed to show that you could separate QSOs from stars using Gunn colors, and not to get accurate zero points. (4) I was here when they were making their observations on the 1.0m telescope, and I would not have accepted most of their nights as photometric!
I've seen multisite photometry campaigns on very low amplitude stars such as white dwarfs and delta Scuti stars where the datasets can be intercompared at the 1 millimag level. Similarly, I'm collaborating with several amateurs in Spain to get good diurnal coverage of some variables, and our datasets agree to within a few millimag.
What is important here is that for a single TASS site with photometric weather we are not reaching Poisson precision. This is why Michael and I keep harping on improving the extraction algorithms and thoroughly checking the hardware. Once the single-site results are understood, we can go on to the next level of reducing the multi-site zero point errors.
Don't get me wrong -- this is not to say that we delay taking data. I am just suggesting that you do not throw away the raw scans just yet, as you will probably need to reprocess the images and re-extract starlists as the algorithms improve.
Arne Henden
aah@nofs.navy.mil
June 25, 1997
Tom suggested a rough schedule, which starts real datataking in September. Sounds good to me! I might make the following suggestions of things to check in the intervening months:
Many of these points have been mentioned by various folks earlier, and I'm sure that I've forgotten others. As I don't have a camera system, all I can do is recommend that these items be investigated (and they may be impossible to do or already tried, so if so please excuse my ignorance).
Arne Henden
aah@nofs.navy.mil
June 25, 1997
I just finished reading a preprint by Zaritsky, et. al. on their drift scan survey of the LMC and SMC. It reminded me of one source of error, and suggested a solution to another problem.
The psf of images on the TASS scans changes in declination. If the same psf is applied to all images, then there will be a systematic error in the magnitude determination in declination. Since the sites do not have their cameras pointed to the same declination zone, and since this psf error is probably camera-unique, then there will be additional scatter in the magnitudes for any given star. Using aperture magnitudes, where the aperture is larger than the fwhm, should reduce this error. Alternatively, using a varying psf should work, though I am usually suspicious of such techniques as you have to get sufficient stars at any given declination to give a reasonable mean psf.
Varying sky conditions will cause zero point errors along the scan. I tried to correct for this in difcal by using only nearby comparison stars for each object, and I think that works reasonably well. Zaritsky suggested an alternative approach. If we have a good master star list with accurate mean magnitudes, then one can match the current scan with respect to the master and determine the zero point offset for each matched star. This gives you a residual map for the entire scan. Then you can fit a moderately low-order polynomial to the residual map to correct for the sky variations. I think this technique would work for cases where the sky is not varying rapidly, or where you can take smaller subsets of a scan that still have sufficient number of stars to make the fit reasonable.
Just some random thoughts.
Michael Gutzwiller
deepsky@fuse.net
June 25, 1997
I've uploaded a file to storm/incoming, deltamag.gif, that illustrates one possible source of our photometric errors. The gif file is a graph showing the difference in magnitudes measured by a single camera on two different nights. I used two of the star lists I generated for Michael, d0a_0483.967 and d0a_0493.946.
I then selected stars which:
I then plotted the difference between the magnitudes measured for each star. As you can see there is a definite trend in the difference over RA (time), presumably due to varying sky conditions. There is also one outlier point which I can't explain.
This indicates that Arne's suggestion of calculating the zero point with a low order polynomial over time may be the way to go as long as outliers can be dealt with.
Chris Albertson
chrisa@wavenet.com
June 26, 1997
> Perhaps Chris could explain his concept a little more?
I'm thinking ahead to the MkIV. I've estimated that it could produce a half mullion photometric measurements per hour. We could have a billion (10e9) record database before to long. (I hope Michael gets himself one heck of a wopping big PC)
I was thinking of a system where there _could_ be more more than one server. The data on each server could overlap partialy, completely or not at all. What data sat on each server would depend on the wishes of the server's owner. One person, maybe Michael would be interested in storing every thing he could get. Other people maybe only care about very red stars or maybe only suspected variables or all data from a given camera.
Yes not everyone has a full time Internet connection. I do here, but not at home so my server would be off line most of the time. It would contain mostly my own data. When I was on-line I could send updates to Michael's big server and maybe pull a little data off his server if I wanted. Maybe I'd ask for all stars with
(I-V) > 2 and 12 < V < 8 and (number of observations) > 5 and (date of observation) > (the last time I asked)This query would update my local database with only new measurments of red stars that had alredy been seen four times in the past from all contributing TASS sites
So in summary I'd dump all my data onto the central server then ask it for a very focused subset of it's data. I could then study these red stars when I was off line.
Servers should be able to exchange records with each other over intermitent Internet connections. It is prety easy to set up a script that calls up my internet servce provider every morning at 2:00am then moves data and hangs up. So it takes fours hours? I don't have any other use for my phone at that time. With flat rate internet service and a local call the transfer is free. Years ago (in the 1970's) UUCP was the norm and e-mail and news traveled over intermitent dial-up lines exclusively. Outbound data was queued for when the connection was available. I think we can use the same philosophy. We don't need full time connections.
There are some technical design issues to be solved but the above is not pushing the state of the art at all. For simple client access to a server no code need to be written. Just a BUNCH of configuration. For server-to-server data transfer this will require some work. Maybe some coding in C or maybe just some short SQL scripts. The database I looked at had TCL/TK and Perl interfaces too and TCL will run on Windows and Macintosh as well as UNIX.
in a subsequent message
> There's no reason why we can't try both approaches, distributed > and monolithic. Whatever works, we use.
You build a monolithic system twice and bingo you now have a distributed system. All you need to do is make certain the two systems and "talk". Worst case is the systems "talk" by exporting to ASCII, transfer via FTP then import the ACSII into the second system. I'd like to avoid this worst case senario if possible.
I'll likely start work after I get the RT Linux driver is better shape. It seems to work now but need more bells and whistles.
So I'll build something. I'd like to not duplicate effort but if we can't agree on a design then at least we should built compatible systems that can communicate. Currently, I'm thinking of using either Msql or MySQL servers running under Linux on a Pentium 100. The server would support SQL, ODBC, CGI, Perl, C, Tcl/Tk interfaces. I know that MySQL can support 50M record databases with very good perfomence on PC hardware. I can give you some web pointers to this stuff if needed.
What where you planning on doing?
If we don't want to use the same systems then we should at least have comparable table structures. This is the hardest part of any database design - getting the tables and the relationships between then set up correctly.
in a subsequent message
> I'm a newbie when it comes to database systems, especially when > they run on PCs. Remember, for the next two months or so, I'll > continue to live in the Sun workstation world :-) > > If you tell me that "database X is the best one to use on a PC", > then I'll buy database X (if I buy anything). I'll follow any > lead you give.
The first question is which operating system will you run. For a PC the choises are Windows NT 4.0, Windows 95, OS/2 and Linux. If you want to run a server that lets others access your database remotely then the only real choises are Windows NT or Linux. There is also the option of a dual-boot system where you keep two OSes on your system.
There are some good database products that run under NT. None however are free. There is IBM's DB2 ported down from the mainframe environment, Oracle 7, and Microsoft's SQL server. These are all industrial strenght product and expect to pay industrial prices.
Other databases like M.S. Access, Foxpro and the like are single user systems that you access from the keyboard. There may be a whole class of products I've left out. Maybe someone else on the list can fill us in.
Under Linux (or the Sun) there are numerus good database servers and not so many single user type systems. Any of the ones that run under Linux will also run on the Sun. So you could do some experiments with yor Sun and take your work to the PC. Most of the software I use daily runs equally well on my Sun SPARC or on my Linux PC. I just don't use Win95 anymore as I've collected UNIX software (word processors, spreadsheets, mailers, IRAF etc...) that works well. So far, I like MySQL. See http://mysql.turbolift.com/ for documentation and http://www.tcx.se/ for the MySQL home page.
> And, by gum, I'm behind you 100% when it comes to comparable > table structures! If you (or you plus other TASSians) come up > with a record structure, I'll adopt it. Well, I might ask that > it include a few extra things --- as all TASSians might --- but > I'm certainly not going to put any effort into something which > is incompatible from the start. > > Frankly, my plan was much simpler: I just wanted to be able > to store a LOT of raw star list files on a single disk somewhere, > so that I could run them all through some magical data reduction > pipeline that will appear someday. It sounds like the boring > ASCII + FTP system that you fear :-) But it's one that I can > understand, and can probably implement.This works good for you but let's say I want to make a light curve of a star I know has been measure 100 times by various TASS cameras. My only option is to download 100 files (assuming I knew exactly which files) then extract the one obervation I want from each file and assemble to 100 line in an output file. This is so much work I would not bother. I'd either just ask for a tape of the entire disk or just let you do the analysis and read the TN.
Now if you had a real DB server getting 100 records would only take a few minutes. I'd import the data into my spreadsheet, highlight the JD and Mag columns, click "charting"/"scater plot" and see a light curve. If it were that easy more people would do it.
> Believe me, if there's a relatively painless, better way, I'll > buy into it. But I'll probably _still_ want some way to generate > plain ASCII text files,I have not yet seen a database that couldn't import/export to ASCII. So you are OK.
Arne Henden
aah@nofs.navy.mil
June 25, 1997
Michael G. states that STAR throws out any star where even one pixel saturates. This is a reasonable approach for aperture photometry since you don't know how much light is getting lost. However, an interesting feature of psf photometry, such as with DAOPHOT, where the fit takes place in the wings of the image profile instead of the core, is that you can accurately measure stars that saturate as long as the wings aren't saturated.
It might be worthwhile to modify STAR to go ahead and measure _all_ stars in the frame, and just flag somehow the ones that are saturated. This might help in matching star fields at a later date ('holes' in coordinate space look pretty wierd, and may also help in understanding why some faint neighbor's magnitude is off). You may still get reasonable photometry for stars that are lightly saturated, since the central pixel or two contribute only a fraction of the total integrated light.
Glenn Gombert
ggombert@infinet.com
June 25, 1997
The StarBase software package from the Harvard CFA looks like it might have some applications for small database projects like the TASS. It uses simple ASCII table file formats and can be complied on a number of platforms. The URL for Starbase is:
http://hea-www.harvard.edu/SXG/starbase_sxg.html
It is a collaection of "C" programs that probably could be compiled on just anout any platform. Maybe Arne has had some experience with this on a project that he has worked on in the past.
It might serve well as a small dedicated database application (such as Michael has in mind) for the TASS Mark III data for the next few months. I think that a full-blown relational database (such as ORACLE) is probably overkill for what Michael has in mind....
Chris Albertson
chrisa@wavenet.com
June 25, 1997
> There is TN -0029 on the Mark IV. The mark IV is pretty simple. > You send a "start read out" command over the serial port. Currently > an 8 character string. The Mark IV then does 4M reads and stores > 8MB in the memory card. When it is done, it puts up a status flag > that can be tested with an I/O read. (Hopefully) it also puts up > an interrupt. You then get to do 8 Million I/O reads to get the data. > > It is a little more complicated than this, buth not much. You can > send a bunch of commands to the Mark IV but they are all in the > form of 8 character RS-232 strings. The first and last character > are the software verstion number. If you send the wrong version > characters the stamp will do nothing and send you back a message > to tell you it did not like the version. Otherwise is will either > say "I did it" or it will pass back measuremnts. Needless to say > you don't do anything fast this way. You have to open and close > the shutter, but not much else for normal data running. So you have > to time the exposure, but not much else is time critical.
What about running the RA drive? Is there a DEC drive? I'll read the TN again so don't answer if it is in there. I assume you give it a step rate and it moves until either told to stop or it hits a limit switch. So I guess I would need to run timmers to ramp the rate up or down for long exposures.
The real quesions are about higher level operations. I can imagine several operating modes. One where you look at the same exact part of the sky three of four times until you run out of RA movement. another mode where you take overlapping frames with various adjustable overlaps amounts. Another mode could look twice at every spot once with a short exposure and again with a much longer exposure to get a wide dynamic range by combining the images in software. Is there a way to parameterize these modes so you don't wind up with hundreds of them?
Other high level stuff like semi-auto focus and display and control, status monitoring, alarms. You are right. Pushing the data across the interface is easy. It is all the other high level functions that need to be addressed
So, I think the questions that need to be addressed (better on the tass list) are what should a Mk IV driver do, aside from pushing data across an interface. Maybe what is needed is a high level script language where you could program a whole night's observations with commands like
loop
aim (dec)
expose (100sec)
dec = dec - 10
end loop
then just walk away.
A MkIV driver needs to talk two ways, one end goes to the hardware the othe to a user. It is the user end that is harder.
Tom Droege
droege@fnal.gov
June 25, 1997
It is very useful to ask questions like this at this time. It is still possible to make a design change.
>What about running the RA drive?
It is controlled by two bits in a register. Again, an 8 character ASCII string will be decoded to do what you want.
On bit determines forward/reverse. Reverse will go 128 times forward, which will go roughly 1 step per second with a 135 mm lens, and 1/4 step per second with a 50 mm lens. I will give you a step forward just out of the stop command and a reverse to the stop command, but otherwise you will have to keep track of where you are by time. We should have about 15 degree of travel in RA, so it will take an hour to get to the limit. I assume that when you know you are near the limit, that you give the "reverse to the stop command" The only problem is that this will tie up the stamp until it finishes. You will get a message back from the stamp saying "completed - at stop", but you can't do other commands in the mean time. I will also give you a "reverse" command which will just run into the stop. It will then be up to you to stop it in time. But nothing bad will happen.
> Is there a DEC drive?
There is a dec positioner. I will give you commands like "go to the stop and move out to xx degrees declination."
> I'll read the > TN again so don't answer if it is in there. I assume you give it a step > rate and it moves until either told to stop or it hits a limit switch.Yep, but there is only a limit indication, not a limit switch. So when it hits the hard limit, it just stalls the motor.
>So I guess I would need to run timmers to ramp the rate up or down for >long exposures.Yep, you do need to run a timer (always) that determines the exposure. I figure you keep track of where the RA carriage is by accumulated exposure time, and when you get close to the stop, you rewind.
>The real quesions are about higher level operations. I can imagine >several operating modes. One where you look at the same exact part >of the sky three of four times until you run out of RA movement.Yep, I plan to run 36 ea 100 second exposures in this mode.
>another mode where you take overlapping frames with various adjustable >overlaps amounts. Another mode could look twice at every spot once >with a short exposure and again with a much longer exposure to get a >wide dynamic range by combining the images in software. Is there aYep, but I think you can do all this with only very long timers. So you don't have to have a fast interrupt for the purpose. I am an advocate of polling as opposed to interrupt driven code. You just poll at the fastest rate and ask yourself if you got there in time. If not you go off to the error recovery routine. Much cleaner than failing n levels deep in interrupt code. My guess is that there is noting on the Mark IV that has to be checked any more often than every couple of seconds.
>way to parameterize these modes so you don't wind up with hundreds >of them?My scheme is to give you the basic stamp commands and leave you all to invent the parameter space.
>Other high level stuff like semi-auto focus and display and control,
For focus you will just say move focus knob to (1 - 255).
For status there are a bunch of limit sensors.
>status monitoring, alarms. You are right. Pushing the data acrossFor status there is a 32 channel ADC that minds all the voltages, temperatures, etc.. You ask for them one at a time, - read the +5 volt supply. It gives you back the value as 4 nibbles (4 bit). This operation is slow, of order a second per item read. So you want to check one or two when you have idle time.
>the interface is easy. It is all the other high level functions that >need to be addressedYep, that is a software person talking. I slave over a hot soldering iron all day then you say it is easy, it is your job that is hard. ;^)
>So, I think the questions that need to be addressed (better on the tass >list) are what should a Mk IV driver do, aside from pushing data across >an interface. Maybe what is needed is a high level script language >where you could program a whole night's observations with commands like > > loop > aim (dec) > expose (100sec) > dec = dec - 10 > end loop > >then just walk away.Yep, this is the part I like. Just walk away for an evening of bridge.
>A MkIV driver needs to talk two ways, one end goes to the hardware >the othe to a user. It is the user end that is harder.
Yep, I assume that you don't minde me putting this up to the list.
Arne Henden
aah@nofs.navy.mil
June 26, 1997
Chris asked,
>Could you estimate the magnitude by simply counting the number of saturated >pixels? From what I have seen there is a corelation between the size of >the saturated area and the brightness of the star. Maybe it only gives you >.5 mag accuracy but this is better then tossing out the star. It would also >be an easy mod to the program.It would be interesting to see how well the number of saturated pixels fits to the magnitude of bright stars. We do this all the time with digitized photographic plates, since it can be derived that the image size correlates with magnitude, but pixels are different beasts than photosensitive sites. On my extraction program, I have another column per star that indicates the maximum pixel value in the image, which is my flag to indicate whether a star is saturated or not. The bright stars all have accurate V magnitudes in the Bright Star Catalog; if someone wanted to make a plot of all HR stars that fall in the equatorial strip vs. the instrumental magnitude on a 'photometric' night, and do this both for aperture magnitude and number of saturated pixels, then we might be able to see how well Chris' idea works. My comment regarding psf fitting is that you can recover the bright star's magnitude to, say, +-0.05mag, not +-0.5mag. In any case, I think bright stars should be added to the extraction list rather than avoided.
>Another idea is to write out the star's location to a file. then use this >file as input to DAOPHOT. Run DAOPHOT on these stars only
True, with some minor changes (you need some additional unsaturated stars to build the psf). This means, of course, that all TASS sites have to have access to something like DAOPHOT.
However, one area that everyone has avoided mentioning is the galactic plane, where TASS will lose big time due to crowding with the poor image quality. With psf fitting, you stand the chance of recovering many blended objects with reasonable fidelity.
What I am saying is that aperture photometry is the way to go when you are far from the galactic plane. It gives the most consistent results and is easy to intercompare regardless of the image quality. This is the case for fields A,B,C. When you get any closer to the plane, the photometric results will degrade until becoming almost worthless by the time you hit 270 degrees (18h). At that point, crowding will make the TASS images look like a globular cluster, or the LMC as seen by MACHO. One can either avoid those regions, or else come up with a complex extraction system (though I suspect something like Sextractor might work) that uses psf fitting with a variable psf across the frame, and with iterative fitting for blended objects. It has to be automatic, too!
Arne Henden
aah@nofs.navy.mil
June 26, 1997
Chris has been very helpful in presenting a lot of database ideas. I have a couple of comments.
Any database manager for TASS needs to be public domain software. I keep harping on this, but I don't have any free money to spend buying a commercial product, and I'm sure others feel the same way. This data is supposed to be available to the general public, and it would sure be nice if the SQL system and scripts were equally available.
Chris' system does not address the area of moving objects. Granted, it is really difficult to handle all of the multitude ways of looking at the TASS data. That is why I like at least the concept of placing all of the transformed, collated starlists on some central server. I suppose you could get moving objects by a query like 'give me all objects with only one datapoint', and then searching for those objects with similar magnitude and color that follow a reasonable orbit.
Note that, when looking for comets, one needs additional parameters beyond magnitude and position. That is why I originally included fwhm in x and y, as you could look for diffuse objects that way. The PMM project here actually includes many parameters about each image, such as all of the image moments, clumpiness, and image size in 8 different directions, so that you can distinguish between stars and galaxies and also remove artifacts. This is probably overkill for TASS, but you get the idea.
Chris Albertson
chrisa@wavenet.com
June 26, 1997
> Chris has been very helpful in presenting a lot of database ideas. I have > a couple of comments. > Any database manager for TASS needs to be public domain software. I keep > harping on this, but I don't have any free money to spend buying a commercial > product, and I'm sure others feel the same way. This data is supposed to > be available to the general public, and it would sure be nice if the SQL > system and scripts were equally available.I'm in the same boat. I'm not about to spent $2000.00 on database software. Thats about the minimum an NT Windows Server based system would cost. I am looking at something called MySQL that is free and runs under linux. Using Linux on the server end does not force anyone else to use Linux so I have no reservations about using it.
> Chris' system does not address the area of moving objects. Granted, it > is really difficult to handle all of the multitude ways of looking at the > TASS data. That is why I like at least the concept of placing all of the > transformed, collated starlists on some central server.I am agreeing here to. My proposal was neutral about the concept of a central server. There could be N servers and each could contain any subset of the total data. N could equal 1. But many people (at least me) would like to have a local mirror of a subset of the central database. However, If Tom is successful with the MkIV, and I think he will be eventualy we have one billion measurements on our hands. I expect one million measurments every two hours of operation. This will swamp a PC based server given enough time. So either we find a sponcer to give us a bigger computer or we have multiple PC based servers or we store our data on tapes in a desk drawer. The good news is that I just found I can buy a fast 7GB drive for $499.00, just came out this week.
> I suppose you could > get moving objects by a query like 'give me all objects with only one > datapoint', and then searching for those objects with similar magnitude and > color that follow a reasonable orbit.Asumming that you are not co-located with the database server but accessing via the Internet you want to minimize the transmition time at the expence of thrashing the CPU on the server. If the server is local moving 500MB is no big deal but this is not an option with a modem. It is also the best reason for having a sophisticated server when all you users are remote.
So here is my first cut at a moving target detection algorithm. I start out simple then re-state it a few times.
Query for two full frames of data. Next I'd compare these with a good astrometric catalog and remove all objects from both frames that I know are fixed stars. Next match the remaining objects on the two frames.
Any pair with a mis-match greater than some tolerence is a potential moving object. Now, eliminate all non-potential moving objects. You should have a fairly short list by now of non-catalogged objects that don't match between two frames. For each remaining object make a bounding box around where you expect to see a third observation based on seperation and uncertaintly of measurment and the range of speeds you expect. Now make one qwery for each bounding box agaist frame three.
Try to fit any objects returned from the above query to the first two points. Make a new bounding box (which can be smaller now) and repeat.
If you set the S/N of the detection software to 1.1 or so then you get many potential moving objects at first that are tossed out later. Target detection algorithms I've seen keep tracks around even after a few frames with no observations. Targets with "long" track histories are kept for a long time even with no more observations. With even one point, if it is good, you want to keep it in your list for at least a few frames hopping to find a match.
Now more detail. Each frame is a "first" frame. The detection algorithum is applied as a continous process. So for each frame you 1) add many new tracks to your track list, 2) update a few existing tracks by adding another point, 3) delete older tracks that don't look promising, 4) check for tracks that meet your "alert criteria" and write them to a file. These are good enough to warrent human eye-balling and analysis.
At any one snapshot in time your track list will contain hundreds of very young tracks, fewer "potenials" and a couple "promising" tracks. It is common for detection algorithiums to define catagories and "promote" or "demote" tracks based on some criteria.
Track promotion algorithms depend on the use of the system. For example an air defence radar would promote a fast moving, inbound track quickly even if the data quality is bad. But a track moveing tangentaly poses less threat and would not be. In our case we may want to treat tracks that act like comets or astoriods much more carfully (don't demote them quickly) then airplane-like tracks. But then an airplane could be a meteor...
Now, how to do the above and cut down on network traffic. I would but a good astrometric catalog or two on the database server. The initial match to the catalog could be done on the server end. So for each MkIV frame in the series you say:
"Give me all objects in frame #N which are not in the catalog and have a color in the range xx...yy and mag, range aa...bb"This should give you only unknown objects especialy if the astrometric catalog is made by combining many TASS observations. You want the above query to be as restrictive as possible but no more so.
With SQL you can qwery based on expresions. For example you have an "I" and "V" column but no "I-V" column you can still ask for all rows such that (A < I-V < B) and get only stars within a given color index range. The trickis to balence the work done by the server against to savings in download time. You can have very expensive qweries that are recurive. A very awful thing to do would be to ask for all stars that are within 10% in the meanian value of the set of stars seen by at least two sites that are seperated by at least 15 degrees of longitude within a day apart. SQL will allow this but you may have to wait a day for the result.
You could also just do the moving object detection at each site but then you loose the ability to combine data.
> Note that, when looking for comets, one needs additional parameters beyond > magnitude and position. That is why I originally included fwhm in x and y, > as you could look for diffuse objects that way.
I kind of like DAOFIND. It outputs ecentricity and and angle of rotation for the major axies. Maybe the ellipse model is enough.
It may depend on the image scale. With a 50mm lens everything may be just one point. With a longer lens we may be able to see the shape of extended objects.
Chris Albertson
chrisa@wavenet.com
June 26, 1997
I just put two files on storm's /incoming directory. You will need them both. Get
TASS_Driver_26JUN97.tgz TASS_Driver_LIBS.tgzThe LIBS file contains a couple directories inside combined in one easy to download tar file. The libs are pre-built just copy the *.h files to /usr/local/include and the libxxx.a files to /usr/local/lib. The Makefile in TASS_Driver_26JUN97.tgz looks in /usr/local for these.
This new version addresses the saturated pixel problem. I did it in a way that should work for Nick's weird "89" problem. Everyone else gets zeros still don't understand why 89 but this should fix the problem.
Also I added many new commands and changed the names for some old ones. (Old names should still work there is an internal alias table) The command processor is a complete re-write. Many more FITS keywords are set correctly. If you look at the source files you will see "Server_lib.c" this is the client server stuff. I've started to hook it up. I say all this to warn you that I could have broken something.
If the wrap problem is fixed, I think we are getting close to code that could be used on a trail basis for production work. We don't need stars to test the saturation fix, daylight works pretty good for that purpose.
Arne Henden
aah@nofs.navy.mil
June 27, 1997
Chris mentioned that he fixed the saturated pixel problem in the driver. His original emails on this indicated something like he was going to assume any pixel < 100 DN was saturated. Could you explain what the new fix does? I'm just concerned that you could 'fix' some good pixels also.
Regarding the mark IV datarate. An interesting paper by Kharchenko, et. al. in Astron. Nachr. 318, 163, 1997 gives predicted star counts down to 23rd magnitude in B, V, and R. If we assume R=13, then there are 190 stars/square degree on average. The mark IV with a 135mm lens covers 120 square degrees, for a total of 23K stars/frame, or one star per 184 pixels. Pretty high density! My assumption is that the three cameras will point to the same region of the sky, and so you still end up with 23K datapoints/exposure. Now Tom wants to take an exposure every 100 seconds, looking at the same region of sky for the full hour that the mount can track it, for a total of 18 exposures/field when you count readout deadtime. If you kept all extracted objects rather than coadding them, you would end up with about 410K objects/hour, or 4M objects/night on average. This is a little lower than Chris' estimate, but still pretty high. My guess is that other observers will opt for longer exposures to reach fainter magnitudes on a single frame rather than coadding, and therefore the datarate will be lower. There will be a maximum exposure time based on the sky brightness. For the mark III, sky is at about 5000 DN in 7 minutes of exposure if I remember correctly, and the mark IV pixels have about twice the area of the mark III pixels, so I'd guess that you could expose 10 minutes without problem (and assuming the drive is accurate enough!). That cuts the datarate way down, and makes the readout deadtime a smaller portion of the exposure time and therefore more efficient operation.
Nonetheless, this still means 100K objects/hour or 1M objects/night from a mark IV system. I think we have to keep this in mind when building star extractors and databases. Astrometry will be tougher, as the larger angular area means that more optical distortions will be apparent. Photometry will be harder because flatfielding is completely unknown at this field size. You will have many more airplanes and meteors in each frame. Lots of fun, though!
Chris' bounding box concept for looking for moving objects is similar to what LONEOS will be using. They will take 3 frames of every field and look for 3 images of moving objects that are properly positioned for linear motion in time. One of the hard parts for TASS will be the 'background' of non-moving objects, since with these big pixels moving objects will often be blended into some stationary source. Another method is to expose long enough so that most moving objects will be streaks. Then look for elongated images, and match only those between frames. For the most part, you can also eliminate images that move north/south or out of the ecliptic plane. Allain should have lots of ideas in this area, and there are many articles in the journals on various schemes.
Tom Droege
droege@fnal.gov
June 27, 1997
> Regarding the mark IV datarate. An interesting paper by Kharchenko, et. al. >in Astron. Nachr. 318, 163, 1997 gives predicted star counts down to 23rd >magnitude in B, V, and R. If we assume R=13, then there are 190 stars/square >degree on average. The mark IV with a 135mm lens covers 120 square degrees, >for a total of 23K stars/frame, or one star per 184 pixels. Pretty high >density! My assumption is that the three cameras will point to the same >region of the sky, and so you still end up with 23K datapoints/exposure. >Now Tom wants to take an exposure every 100 seconds, looking at the same >region of sky for the full hour that the mount can track it, for a total >of 18 exposures/field when you count readout deadtime. If you kept allThis is one of the reasons I am working on the fast readout. We may end up taking longer exposures, but I want to be able to take many short exposures. One of the things that I want to look for are close in earth passing objects. These could move pretty fast. I would like to look for them in 3 filters and in stereo. OK, so there may not be very many of these. So one wants to do bread and butter variable star observations while waiting. My goal is to make 100 second exposures with 5-10 second readout. There are now 14 bit fast converters that I can afford. Just announced June 5. So the Mark IVa will read out fast.
>extracted objects rather than coadding them, you would end up with about >410K objects/hour, or 4M objects/night on average. This is a little lower >than Chris' estimate, but still pretty high. My guess is that other observers >will opt for longer exposures to reach fainter magnitudes on a single frame >rather than coadding, and therefore the datarate will be lower. There willYep, who knows what direction we will take. I just don't want to design in unnecessary limits.
>be a maximum exposure time based on the sky brightness. For the mark III, >sky is at about 5000 DN in 7 minutes of exposure if I remember correctly, >and the mark IV pixels have about twice the area of the mark III pixels, so >I'd guess that you could expose 10 minutes without problem (and assuming theYep, but I really want to us a 50 mm lens. Then you get (I recall) about 20% of full well in 100 seconds at my location.
>drive is accurate enough!). That cuts the datarate way down, and makes theThe new drive is at least an order of magnitude more accurate than the last design. Possibly 50x better when compensated for temperature.
>readout deadtime a smaller portion of the exposure time and therefore more >efficient operation. > Nonetheless, this still means 100K objects/hour or 1M objects/night from >a mark IV system. I think we have to keep this in mind when building star >extractors and databases. Astrometry will be tougher, as the larger angular >area means that more optical distortions will be apparent. Photometry will >be harder because flatfielding is completely unknown at this field size. >You will have many more airplanes and meteors in each frame. Lots of fun, >though!Yep, we are mostly exploring pretty new territory, and that is what is fun for me.
> Chris' bounding box concept for looking for moving objects is similar to >what LONEOS will be using. They will take 3 frames of every field and look >for 3 images of moving objects that are properly positioned for linear motion >in time. One of the hard parts for TASS will be the 'background' of non-moving >objects, since with these big pixels moving objects will often be blended into >some stationary source. Another method is to expose long enough so that >most moving objects will be streaks. Then look for elongated images, and >match only those between frames. For the most part, you can also eliminate >images that move north/south or out of the ecliptic plane.
Are you sure about this? Won't it be hard to tell (quickly) if a close in object is in the ecliptic plane?? Just asking.
Arne Henden
aah@nofs.navy.mil
June 27, 1997
>Yep, but I really want to us a 50 mm lens. Then you get (I recall) about >20% of full well in 100 seconds at my location.Note that a 50mm lens gives about 10x more area coverage in the sky. If we assumed the same R=13 limit, then you would have one star every 18 pixels. Since FWHM is about 10 pixels area, this means the frame is going to be basically 'white' with stars! I see this in the 1.0m frames near the galactic plane. It is a real mess to do accurate photometry under these conditions. Personally, I'd rather go to a good 300mm lens and get 5x5 degree coverage with better pixelization if I wanted to do photometry, or look at the BACODYNE error box for GRBs. Everyone will have their own ideas and needs!
Also, Tom, I read an article in the latest Ap. J. Letters on rapid optical followup on GRBs. They looked at 12 triggers over a two year time span, and saw nothing at V=8 limit. Models indicate that you need a V=10 limit to pick up the brightest 10% of GRB sources. Of course, the models are probably wrong, but fainter is better in this game.
>The new drive is at least an order of magnitude more accurate than the last >design. Possibly 50x better when compensated for temperature.Granted, and that will be a *big* improvement. However, all 3 cameras will be on the same mount, and we will have the same tracking problem based on different focal length lenses. Also, the drive now becomes a polar mount, and you have to worry about accurate alignment to the pole and irregularities in the screw drive.
>>... For the most part, you can also eliminate >>images that move north/south or out of the ecliptic plane. >Are you sure about this? Won't it be hard to tell (quickly) if a close in >object is in the ecliptic plane?? Just asking.That is why I said, "for the most part." It depends on what kind of asteroids or moving objects you are looking for. The main belt asteroids and most comets have low enough inclinations that they will appear to move in the ecliptic plane. NEA's are a different beast, but they should streak quite nicely in normal exposure lengths. Once you know the direction of travel, you can get astrometry at the beginning and end of the trails.
Chris Albertson
chrisa@wavenet.com
June 27, 1997
> Chris mentioned that he fixed the saturated pixel problem > in the driver. > His original emails on this indicated something like he was > going to assume any pixel < 100 DN was saturated. Could you > explain what the new fix does? I'm just concerned that you > could 'fix' some good pixelsThanks Arne. You made me go back and read the code in both tm3get and the RT Linux driver. It appears Norman and myself were doing functionaly equivalent operations _except_ for the fact that Norman can type. I found this:
pixels[i] = (short)((long)buff[i] - 32678);
That 67 should be 76. Funny how 32678-32768 = 90 which is not
so far removed from 89. The good thing about dumb errors is
they are easy to fix and when you find then you can be certain.
I don't know how many times a looked directly at the above
without seeing that two character were inverted.
Nick, The latest driver may fix the problem but even if it does the method is wrong. I'll have a new version shortly. By tonight I hope.
So Nick's camera works like all the others after all. Here is how it works. I still don't know _why_. Remember this is a two's complement device. It apperas that brighter and brighter stars push the output codes to -20K, -30K, -32676, -32677,-32678, then to +32767. Our scaling convention maps -32678 -> 65535 and +32767 -> 0
Alain Maury
maury@ocar01.obs-azur.fr
June 27, 1997
I don't think NEA's will trail on 100 seconds exposures with a 50mm focal length and 15 microns pixels. Quick math give me that one pixel is about 1 arc minute, and two arc minutes ( in order to see the beginning of a hint of a possible trailing :-) ) in 100 seconds is 28.8 degrees per days. There are such beasts, but brighter than mag 13 or so, and 30 degrees per day, it will be a lucky day.
Michael Gutzwiller
deepsky@fuse.net
June 27, 1997
Michael has inspired me to investigate how good our photometric measurements could be. My investigation is based on two data files Tom made available earlier, g2483931.fts and g2493909.fts. These represent a best case since they are from a single site, single camera, use the same dark and flat vectors, with very little movement in Dec between the two nights. They also show very little drift (<0.005 mag) in time indicating that both images are photometric.
I generated star lists for both images using the new version of "star". This version does a better job of measuring background levels for the stars and uses two types of apertures for measuring magnitudes. The first type is an aperture optimized to the size and shape of the PSF derived for each image. The second type of aperture is circular. Four circular apertures were used with diameters of 5, 7, 9, and 11 pixels.
After creating the star lists I compared the magnitudes of stars which appeared in both images and matched a GSC entry. The table below shows the standard deviations for each magnitude for each aperture. The standard deviations have beed divided by sqrt(2) since they are differences between two measurements. Also shown is the theoretical or internal error for the PSF magnitude measurements based solely on statistics as well as the number of stars in each bin and the Field A results.
Magnitude
Aperture 7 8 9 10 11 12 13
PSF 0.008 0.008 0.015 0.023 0.043 0.105 0.137
5 0.020 0.028 0.018 0.023 0.040 0.085 0.132
7 0.015 0.017 0.018 0.024 0.041 0.102 0.124
9 0.007 0.010 0.023 0.032 0.054 0.128 0.219
11 0.005 0.014 0.027 0.036 0.068 0.154 0.251
Theory 0.002 0.003 0.008 0.019 0.044 0.110 0.214
# Stars 4 11 14 40 80 111 33
Field A 0.031 0.027 0.033 0.051 0.091 0.155 0.211
Several things can be determined from the table.
Arne Henden
aah@nofs.navy.mil
June 27, 1997
Alain wrote that he feels NEAs won't leave noticable trails on 50mm/100sec markIV exposures. That is why we have experts like him on the maillist! Me, on the other hand...well, ask me about variable stars, and I might give a coherent answer.
I guess I was still thinking of the 135mm or 300mm systems, rather than the 50mm system that Tom wants. Also, I think the Loral chips Tom is going to use have 12micron pixels, not the 15micron that Alain used in his calculation. (see, here I am, trying to jusify my comment...)
I would also like to know the brightness distribution of NEAs, to see if reaching mag12-13 is faint enough to be worthwhile, or if it would be better to integrate/coadd longer to go another magnitude fainter. Sooner or later, trailing will start, and that will be the faint limit for NEA detection with these systems.
Alain Maury
maury@ocar01.obs-azur.fr
June 28, 1997
I would guess ( wildly ) that there has to be an NEA close enough and large enough to be that bright about once per month, that is if we were to survey the whole sky in real time. But we won't, so I'd guess about once a year. When and if this happens though it is a big thing.
Most of the asteroids we find are fainter than 18, and most asteroids brighter than 15 are known ( it is very rare to find something brighter than 15 which is not known yet. I'd say 16.5 is the magnitude where you have a 50/50 chance that the thing is yet unknown.
I guess you can't do everything. An asteroid search or a comet search will not require the same strategy that a variable star search. But what good is it to look for variable stars anyway.. :-)
PS: No, I shouldn't be teasing variable stars observers. At any rate we all agree that all this discovery stuff is much more interesting than taking boring galaxy spectra.... ;->
Anthony Beresford
starman@camtech.net.au
June 28, 1997
>Most of the asteroids we find are fainter than 18, and most asteroids >brighter than 15 are known ( it is very rare to find something >brighter than 15 which is not known yet. I'd say 16.5 is the magnitude >where you have a 50/50 chance that the thing is yet unknown.May a lurker contribute a lttle to the debate. A quote from my own correspondence in last few days , with Brian Marsden of the MPC about attending the informal NEO meeting
" Mag 13 is indeed pretty hopeless, but I thought the TASS plan was to go to mag 17, which would be just about right (mag 20 is too faint for all-sky, and we want mag 23-24 near opposition...)"
Tom Droege
droege@fnal.gov
June 28, 1997
The reason I want to look close in is that everyone is so sure there is nothing to see. I give it sort of 100/1 long shot as to possibly being useful. I would not think of doing it except that there is other stuff to look at that is bread and butter science. i.e. we measure variable stars, a lot of them. Note that from time to time something comes skipping through the atmosphere. Sometimes they are seen, and some even take movies of them. But this does not answer the how many and how big that a very wide angle survey might answer. Note that this is something that no professional dare do. A sure way to lose whatever funding one has.
But there are several long shots. Near earth asteroids. If we look, we can get a body count and a limit. The body count may be zero, and the limit might be mag 11 or 13, but that is at least a bit of science. We should also get a nice meteor count. The wide angle telescopes are tireless. If we put two of them spaced, then we can get nice tracks. If we run through a meteor shower, we should get a nice profile of the shower. Much more precise than a lot of observers lying out in the cold in boxes counting with a note pad. Not that this is not good science, but that a wide angle stereo system should be better science. Then there are gamma ray bursts. If these are very short and decay exponentially, then getting there even 5 seconds late is a bad strategy. Much better to be looking all the time. Who knows, we may not be seeing cosmic snowballs because they are too large, and we just see our frame uniformly light up? We should look at really wide angles a bit and see if we see anything.
So there. ;^)
in a subsequent message Here is yet another reason to try to look wide angle. I am working on something called the Auger projece. This is a detector to count 10E19 to 10E21 ev cosmic rays. Two have been seen at 2E20. One existing detector uses plastic scintillator spread out over many square miles. The "Fly's Eye" detector looks up at the night sky with many PM tubes and mirrors. They have a resolution of about 1 square degree with the present detector. The incoming cosmic rays (presumed to be a single proton or iron atom, etc) hit the upper atmosphere and shower. I.e. the proton hits an air molecule and produces secondary particles. In the end 10E14 or so particles are produced. These interact with he nitrogen in the air which fluoresces. The Fly's Eye sees lots of these events, thousands a night at the lower energies. But does anyone ever report seeing one with a telescope? I have not heard of such reports. It is even worse. Besides the fluorescense of the nitrogen viewed by the Flys Eye, there is also Cerenkov light. This is several magnitudes brigher. They are bright enough that attempts have been made to see them in daylight using solar cells.
The point of all this is that there are known phenomena out there that produce general brightening of an area of the sky. No one sees them with telescopes because no one is looking at a wide enough angle.
Suppose cosmic snowballs are large difuse blobs of water. I mean a few hundred pounds of water spread out over miles. Just loosely gravitationally bound water. i.e. a comet with no core. It might bang into the upper atmosphere and hardly show up. Suppose it radiated a little in the IR. Such a thing might be an IR hot spot with a core a few degrees wide, but rather difuse. Who would see such a thing? We have the pictures of the dark spots. They look pretty big to me.
Arne Henden
aah@nofs.navy.mil
June 29, 1997
Tom came up with another wide angle idea -- looking for cosmic ray showers, not in the normal charged particle sense but by seeing nitrogen flourescence. For a background on cosmic rays, I might recommend taking a look at the Milagro homepage, http://hana-mana.lanl.gov/milagro/MGRO_Homepage.html, as this is the latest and greatest of the shower detectors. I took a tour of their facilities during the Pulsation Conference (thanks, Galen!).
The cosmic snowball idea was proposed by Louis Frank about a decade ago (see the August Sky & Telescope for a nice article). They can be seen from orbiting satellites since the clouds block the atmosphere's dayglow, and have also been seen in OH emission. I don't know of anyone who has looked for them from the ground, but that would be an interesting experiment. Two good ideas, Tom!
One thing I've often considered is to look at the radiation events on the CCD. All astronomers consider these to be 'noise', but since they are present all the time (you will get *lots* of them with the 2048x2048), you might be able to determine energy spectrums and perhaps directionality as well.
Another project is to look at the airglow in the R & I filters. Peterson at UNM, back in the early 1970's, was taking photographs using red-sensitive film (I think there were a couple of news notes in S&T on this), showing a cirrus-like structure that moved just like clouds. This impacts on how well one can flatfield R&I exposures, and might be worth a study.
I've considered using the markIV as a cloud camera. Most cloud cameras are expensive 10 micron devices. With a wide angle lens, one should be able to make movies of the sky and be able to detect clouds even at VRI and even from a dark site.
Therefore, I think there are lots of projects to do with a 50mm or wider lens on the mark IV. With a universal lens mount, you can use whatever focal length fits your interests.
Tom Droege
droege@fnal.gov
June 29, 1997
I want to make clear that the flourescense showers may be too dim to see. But the cerenkov light from the same shower should be 2-3 orders of magnitude brighter, and so should be seen. I too have visited Milagro. Auger is about 10E5 the size of Milagro. Unfortunately, the collaboration may also be that much larger, and is quickly becomming so complicated and political as not to be much fun. I will put up the home page for Auger when I get to work.
I agree with Arne, there will be a lot of targets of opportunity for a good wide angle detection aystem, ****and the software that goes with it****
The software to look for such things is the real missing ingrediant. By working together to develop such software we will open up a very exciting field.
Glenn Gombert
ggombert@infinet.com
June 29, 1997
I just got back from the 109th meeting of the ASP in Chicago. The talk on the TASS Project went well, it was not as detailed as the AAS talks but there were a lot of good questions. Several people wanted to know "how do I get involved in TASS", I gave them my E-mail address and will try to follow-up in the next few days. Vigina Trimble gave a talk("The Universe You Don't See: Existance and Nature of Dark Matter) which was the same time that I did so the talk might have had more attendance if it was in a different time-slot.
Leif Robinson also gave a talk highlightening some of the results from the AAS meeting, the TASS project again got some very nice "PR" from Leif. He will repeate the same talk at ALCON next week out in Colorado.
I had a very interesting talk with Jim Kaler (from the University of Illinois) he was another one of the speakers and has been involved with the Stardial project there. He seemed very interested in the progress that we had been making on data reduction efforts. Several members of the board of the ASP also took time to discuss the project and seemed very interetsed in what we were doing.
I did have a chance to stop by and visit with Tom and see the prototype of the Mark IV camera being assembled, he hopes to be getting some images in the next month or so. I have just been catching up on the discussion of wide-angle searches over the last several days. Lief Robinson showed a slide of a survey being conducted using a ccd camera and wide-angle lens to map the H2 regions in the Southern Sky. A talk was presented on this subject at the AAS meeting. It seems that this might be a good project as well for a Mark IV Tass camera to perhaps be used to perfrom a similar survey of the Northern Sky.
Anthony Beresford
starman@camtech.net.au
June 30, 1997
The High Energy Astrophysics group at Physics Dept Univ of Adelaide ( my alma mater) runs several cerenkov detectors at a dark site at Woomera( some 450Km NNE of Adelaide. They can only observe when the moon is not around, and they rely on coincidence detection, using 1-2 nanosecond response time PM tubes. One of the staff Dr. Bruce Dawson has worked on the Fly's eye and other stuff in Utah. I will check but I am sure the number of photons from a shower is below the noise in the night sky . The equipment is known as BIGRAT. The Japanese also have an instrument on site called Cangaroo.
In regard to looking at the nightglow. I think you will find it has already been done. One of my friends was employed part of last year operating a CCD imaging the Night glow. As a time lapse movie this shows variations in the night glow as moving striations. This was a US experiment run at the Buckland Park experimental station, for a person whose name escapses me. I think some work was mentioned in a paper in JGR last year. These striations are a manifestation of the internal gravity waves that show up particularly strongly at heights from 80-100Km in other measurements as well. My ex-colleagues from the atmospheric research group have been studying them for the last thiry years. The observation was conducted thru an interference filter, and also couldnt accomodate much moonlight.
Arne Henden
aah@nofs.navy.mil
June 30, 1997
Glenn G. gave us a synopsis of the ASP meeting - thanks! He also mentioned using a Mark IV for performing an HII survey of the Northern Sky. There have been a number of photographic surveys (you can use the POSS, plus Ted Gull of GSFC did a narrowband survey that I think was published as a book), and I thought someone had done it with a CCD + narrowband filter for the North (reported at a recent AAS meeting?). While imaging the sky is a lot of fun, deep surveys are something TASS is *not* suited for, as others have the financial backing to buy the big lenses and Schmidt cameras. TASS is much better suited for transient phenomena and long time baseline projects, or statistical studies of large samples of stars.
On a different subject, I assume that the MarkIII cameras were pointed 15 degrees apart so that one could look for rapidly moving objects, or perhaps get 1-2hr time resolution on rapidly varying objects. Can the mounts be adjusted so that all 3 cameras point to the same field? If so, I'd think that simultaneous VRI data from a single site might almost be as valuable as having the wide spacing. For example, transient phenomena such as GRBs or meteors would benefit from simultaneous color information. Rapid pulsators like RR Lyr stars change color throughout their cycle, so that simultaneous VRI is better than having the V image taken an hour from the nearest I image. Is there a chance of getting 7 'R' filters donated to TASS, or someone (like MR) applying for an AAS small grant?
Alain Maury
maury@ocar01.obs-azur.fr
June 30, 1997
I have always wanted to put a 16mm fish eye lens in front of our 2K camera. This should give something like 150degrees from edge to edge, with a 1 arc minute pixel or so. It should almost look like what a very sensitive human eye would see. Never have had time to do it, mostly since the camera is on the telescope all the time, and when it is not, it means we are working to put it back.. With the price of the Loral 2K, it become doable to use such a camera as a cloud camera. We may in the end do this when we will have finished automatising the telescope. It is then a question of thersholding the image ( clouds are always much brighter than the sky background ), and being able to convert a position in the sky to a given pixel on the cloud camera, and see if it is light or dark.
Herb Johnson
hjohnson@pluto.njcc.com
June 30, 1997
*>Most of the asteroids we find are fainter than 18, and most asteroids *>brighter than 15 are known ( it is very rare to find something *>brighter than 15 which is not known yet. I'd say 16.5 is the magnitude *>where you have a 50/50 chance that the thing is yet unknown.I'm glad to see this subject has some interest!
You suggest a somewhat surprising threshold: have recent surveys been that *complete*? And how far from the ecliptic have such surveys ranged? If we follow a "streak" strategy, we would need longer exposures, but as has been said that generates a lot of stellar objects! Also, if we are to search along the ecliptic, our Mark III cameras may need to compensate for diffrerential motion across the frame.
Of course, comets and other "new" solar system objects in far solar orbits would be discovered, even by a less sensitive but NEW survey.
*>I guess you can't do everything. An asteroid search or a comet *>search will not require the same strategy that a variable star *>search. But what good is it to look for variable stars anyway.. *>:-)You tell 'em! ;) But my understanding also suggests that it is difficult to reconcile different object (and search) strategies. More than one strategy may be required, or even different aiming strategies.
Tom Droege
droege@fnal.gov
June 30, 1997
The present design has a plate with a "t" thread screwed to the front of the camera much like the lens mounting plate on the Mark III. One can screw a "reverse t thread adaptor" into this thread for the particular lens mount that you want to use. I have found a place to buy these, but they cost $40 or so each. This allows use of 40 mm diameter t thread lenses, or any other lens for with you have a 40 mm reverse t thread adaptor.
I have tried to make things rigid enough to handle lenses up to 5 pounds or so. We shall see if the big ones droop enough to cause a change of focus over the ccd chip.