Glenn Gombert
ggombert@infinet.com
Mar 1, 1997
I am getting some differences in the image-scales that I have been calculating for some of Tom's Images that are somewhat differnet than those that Michael got when he put togther his TASS Technical Note. I was wondering if anyone had tried to measure these? I am especially interested in this since it directly affects the accuracy of my Astrometic calculation.
The centroiding algorithm that I am using gives better than 1 arcsecond resolution when used on digitized POSS data so I am sure that it is fairly accurate.
Arne Henden
aah@nofs.navy.mil
Mar 1, 1997
Glenn G. wrote about image scale calculations. I did an independent measure in my astrometric note, and got 13.73 arcsec/mm on average.
Which POSS digitized data are you referring to when you quote 1arcsec resolution? And what do you mean by 'resolution'? How are you measuring the accuracy of the centroid? Actually, 1arcsec accuracy for centroiding the POSS plates, if you are working from the original plate material, is not as good as the professional groups are getting. For instance, the PMM is quoting 200mas astrometric accuracy over the entire sky, including all of the bending and optical distortion corrections, and local accuracies higher than this. However, we are probably comparing apples and oranges here! Note that photographic plates DO NOT have gaussian-shaped images as they are inherently non-linear. The PMM uses a Fermi-Dirac function for its fitting.
If you want to test your centroiding, get a series of TASS images of the same region of the sky on different days and test the repeatability of a frame of isolated stars within a section about 3 degrees square. I'm sure someone has already done this, and so please accept apologies if I haven't read the proper emails!
Arne Henden
aah@nofs.navy.mil
Mar 1, 1997
Chris replied to Tom's request regarding file naming conventions. I'm glad someone had the courage to attack the problem and open themselves up to flak!
My strong preference is to continue with the DOS/ISO9660 8.3 filenames. You have to match the lowest common denominator. Chris has done so.
I would prefer that, in any naming convention, the date is contained in the leading characters. This makes sorting and directory listings easier.
TM3GET has a unique idea in using a modified Julian Date in the file name. This saves space, as a 4-digit day number is valid for nearly 30 years! It is a little harder for a human to identify, so my preference is, if enough characters are available, to use the yymmdd format.
Chris suggested using common 3-character extensions like TXT and FTS for the files. If you are compressing a lot of information into the file name, it doesn't seem sensible to be extravagent in the extension and waste characters.
Therefore, here is another suggested naming convention.
yymmddxy.mnn yy year - 1900 mm month dd day x site a-z y filetype a-z m camera 0,1,2 nn sequential file number for that cameraNote that yymmdd could be replaced with jjjj (modified Julian Date ala tm3get), leaving an extra 2 characters that could be reserved at this time.
After flatfielding, I do not see further processing of the FITS frames. All steps following extraction will have astrometry tied to them, so I see no need to keep individual extractions separate; rather, a single star list for a given camera for a given night should be made.
So maybe another file format would be:
jjjjxmnn.ccc jjjj modified julian date x site m camera nn sequential file number (set to 00 for starlists) ccc file type.
Now the file type can be a squandering of 3 characters as suggested by Chris, with perhaps RAW for the raw fits, and RED for the flatfielded fits, and some other extensions for other filetypes.
Chris suggested a 3-digit julian date, which won't work as that only gives you 1000 days before rollover (and it depends on what day you start as to when the rollover occurs).
Just some mutterings. I've been shovelling too much snow lately and I'm afraid my brain has shut down...
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 1, 1997
Chris Albertson wrote:
> One thing to watch out for is that you will be running two programs, > your rsh'ed temperature monitor, and the tm3get11 program. both will > be accessing the same hardware. This is a clasic problem in > computer science. You need some scheeme to insure that this does > not cause problems. Believe me with no such scheeme you will have > problems. (one program sets a register a millisecond before > the next one re-sets it) One easy way is for the highest priority > process (tm3get11) to toggel a flag that controls access by the second > process.It gets simpler than that. tm3get11 is not running when I do a rsh to monitor tass. After enough time has elapsed, I stop issuing rsh to monitor, and issue a three rsh:
Now as far as I understand the configuration (and we have not tested this), TM3GET11 will be running to completion before windows 95 comes back up. There will not be a rpc capability in the system until windows 95 comes back up and starts the rpc task. So there will be no conflicting task asking for status. Since the homepage script is the program that is issuing the rsh for monitoring, we can cut it off until a message is sent from the windows 95 system saying it is up. If the program terminates early, when windows 95 comes up, it will alert the unix system, who will know what time it was expected to come up. The unix system will close the remote doors, and then shut off the power to the TEC.
> I assume the data is showing up on one of the UNIX machine now via > NFS mount of whatever. If it is, why not just read the temperature > out of the raw FITS data file. It is (should be) recorded in one of > high numbered columns of peudo-pixels.At this time, there is no nfs mounted file system or smb file system. The problem is that tm3get11 runs best in DOS mode, and does not run very well under windows 95. I plan to run the program during the boot cycle for windows when it runs stand alone dos utilities.
> > Until we have a Linux version of tm3get11, I plan to copy a autoexec.bat > > The _best_ thing would be to have the driver broadcast the enginerring > data to any client who requests it. I have just about finished this > part of the Linux driver code. I have not heard from Norman in > ages. If anyone does, would they ask him to e-mail me at the address > below on my sig line. > > P.S. What you have is not (if you use common technical terms) a > "remote procedure call (rpc)". It is best called a telnet or rsh > server as that is the protocol used. An RPC is used by a > programmer to call a subroutine or function tha physically resides > on another machine.Chris I agree with your definition of the RPC. I am using the Winsock RSHD/95 utility so I should call it a rsh server. I would much rather be using a linux system, but since I am stuck at home recoverying from surgery, I can't get into the lab to write or debug it.
Arne Henden
aah@nofs.navy.mil
Mar 1, 1997
First, I want to make a point. Most of my messages seem to be negative, and could be interpreted as downplaying the quality of TASS data. This is in no way true! I wouldn't be commenting at all if I didn't feel that TASS had a place in the scientific community and that the final data quality would not be comparable to many professional sites. I'm sure Richmond and Paczynski feel the same way! There are some really bright people associated with this project, am I'm learning new things every day.
Chris asked about the astrometric accuracy to perform a couple of projects.
But TASS is almost there. Factors of 2-4 can usually be made up at this preliminary stage. For example, Tom's camera1 (V) images are far better than the I-band images, and the reported fwhm is poor only because there is trailing on the frames. You may have to stop down the I-band cameras to improve image quality; switch to R-band filters; or use two V-band cameras and one I-band camera. Likewise, once the hardware is adjusted, improved centering techniques using knowledge of the typical TASS camera image profile may increase the astrometric accuracy.
As a professional, I would much rather reported data that had: (1) 0.5arcsec coordinates instead of 3arcsec; (2) 0.01mag photometry instead of 0.10mag photometry. I think both are doable with TASS without major effort.
Tom Droege
droege@wwa.com
Mar 1, 1997
It seems to me that a few arc seconds is quite good enough to do the first (easy) part of this experiment. We only have to do 1) below, that is sort the star measurements. Then we can monitor our strip of sky for a year and find lots of good stuff. Then we can write a paper on what we have found, and wait for a shower of money (or a lot of copy cats) to do it better.
Tom Droege
droege@wwa.com
Mar 1, 1997
I have been running Mike Gutzwiller's star program on two days of "B" fields. I am very pleased with the result.
Running at 5 sigma, I get pretty much the same stars in all six fields. This is very encouraging to me. The astrometry would appear to be good enough to sort the stars, which is all that is needed to make the first pass at analysis for variable stars.
I like to look at data by hand with a pencil and paper. It allows one to see obvious junk in the data that can be missed until the program gets very sophisticated. So I printed out the first 100 stars in the B field from each of the six measurements and looked at them.
Camera 0 + 0.60 to - 2.28 degrees declination Camera 1 + 1.41 to - 1.38 Camera 2 + 1.23 to - 1.46
These fields were determined by looking at the extremes of 100 stars so the edges may not be quite right.
The sigma of the four I magnitudes measurements in general was less than the measurement sigma. With my non statistical background this indicates to me that the systematic errors are less than the measurement error, which is where we want to be. This was more true for the faint stars than for the bright ones, which probably suffer from saturation effects.
If the data gets no better than this, and the analysis gets no better, then we can still do a nice search and catalog experiment. We should find a thousand or more interesting objects. This is just great!
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 1, 1997
Bernie Kluga did a little redesign on the sensor alignment hardware for TASS#5. Marty and I are going to try to get him to document what he did and report it to the group. He replaced some of the mechanical linkage with teflon and other hardware so that it would not be temperature sensitive, and would produce a more accurate rotation of the sensor. The knob now does not have a large dead zone, and is easier to align. Now if the weather would clear I can give you examples of the data. The first run we did February 27 showed two of the three sensors aligned pretty well. The problem was that it was cloudy, and the third sensor could not see anything. We really only got about two files of party cloudy data before conditions closed in.
We are hoping that this will take care of the alignment problems we have been having, and will allow us to collect data for the paper.
Tom Droege
droege@wwa.com
Mar 1, 1997
> First, I want to make a point. Most of my messages seem to > be negative, and could be interpreted as downplaying the quality > of TASS data. This is in no way true! I wouldn't be commenting > at all if I didn't feel that TASS had a place in the scientific > community and that the final data quality would not be comparable > to many professional sites. I'm sure Richmond and Paczynski feel > the same way! There are some really bright people associated with > this project, am I'm learning new things every day.Views of a professional are much appreciated. I see you as someone who pushes us to achieve the best possible limit. This is just great. It keeps us on our toes. But I want to point out (again) the real goal of this project. It is to get people interested in all sky surveys, and go develop a pool of software tailored to the job.
The long term goal is to solve the earh colliding astroid problem with a group of amateurs before the government gets around to making it a big project out of it. There are a lot of other possible goals in between.
So I tend to think a little differently about presenting data from the project. What will make people more excited and get more people working on the project? Fussing too much about the last decimal point, though good science, will turn off some of the adventurous types that might want to join a treasure hunt. Thus I think it will be good to early on find a few variable stars and possibly an asteroid or two and then announce that we have done so.
> 2) To track a discovered solar system object. For near-earth > asteroids, the current 3arcsec accuracy will often be good enough. > Comets, because of their diffuse nature, are always difficult objects > to get highly accuracte coordinates. Distant asteroids require > higher precision; usually, reported coordinates with greater than > arcsec errors are thrown out of the solution.As a survey project, we just have to detect that we have a moving object. Then others (who are interested and have better instruments for the purpose) can follow up.
> But TASS is almost there. Factors of 2-4 can usually be made up > at this preliminary stage. For example, Tom's camera1 (V) images > are far better than the I-band images, and the reported fwhm is > poor only because there is trailing on the frames. You may have > to stop down the I-band cameras to improve image quality; switch > to R-band filters; or use two V-band cameras and one I-band camera. > Likewise, once the hardware is adjusted, improved centering techniques > using knowledge of the typical TASS camera image profile may increase > the astrometric accuracy.Don't get me wrong. I will certainly encourage us to to the best that we can possibly do. But I would like to go in stages. First discover a few things, then learn to perfect their measurement.
> As a professional, I would much rather reported data that had: > (1) 0.5arcsec coordinates instead of 3arcsec; (2) 0.01mag photometry > instead of 0.10mag photometry. I think both are doable with TASS > without major effort.As an amateur, I want to have fun. My temprement is more that of an explorer than that of a precise cataloger. I think science needs both types. The structure of tass (anarchy) is such that any tass member can choose either approach.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 1, 1997
A few thoughts on file names for raw TASS files. My first thought is that Tom's current scheme or something very close to it is reasonable enough. We have "bigger fish to fry", and the FITS header can provide a LOT of information: the filename need not do it all. The names need to be reasonably unique and informative.
*> I assume many people are still limited by DOS's 8.3 filenaming *> restriction.Yes, notibly the manufacturer of the cameras (!). Me too.
*> I will propose a convention very close to what Tom used when *> he posted his data to Storm's incoming directory. *> *> It is still possible to mix up files written by multiple sites *> but isn't that what directories where made for.Yes, until you create other directories and use other people's files and so on. I would encourage a filename format that would encourge each filename to be *unique*. Tom's scheme for filename (ignoring extension) would allow this if you replace the "T" with a site or camera designation, a preassigned letter for each camera (no site has two Mark III cameras). That easily supports 26 cameras, adequeate for the next year or two, long enough.
Tom uses the file extension for fractional date: I'm not so comfortable with that. Chris's alternative has some merits in that way, extensions are needed to identify file TYPES. But Tom's use of it for raw images may be an acceptable exception: raw data will have a numeric extension. Even so, programs that DEMAND a .FTS extension (or .fits) may stumble over raw data with the same filename. This can probably be lived with.
*> One last idea: The file F0789654.TXT would comtain an *> explaination of the contents of F0789654.FTS but one could *> supply a file called FX789XXX.TXT to explain all flat files *> made on day 789.If such info can be put into the FITS header, it should. A simple program to extract such comments and create this .txt file is easily constructed. Fewer files is better.
Glenn Gombert
ggombert@infinet.com
Mar 1, 1997
I have just uploaded to Storm /incoming a file called STARPOS.ZIP which contains the astromertic reduction of the following files:
File Star-List
G0483967.FTS A0483967.CAT
G0483977.FTS A0483977.CAT
G0493669.FTS A0493669.CAT
G0493678.FTS A0493678.CAT
G1493669.FTS A1493669.CAT
G1493678.FTS A1493678.CAT
G1493946.FTS A1493946.CAT
G1493955.FTS A1493995.CAT
G2483921.FTS A2483921.CAT
G2483931.FTS A2483931.CAT
G2493623.FTS A2493623.CAT
G2493900.FTS A2493900.CAT
G2493909.FTS A2493909.CAT
Michael Richmond
richmond@astro.princeton.edu
Mar 1, 1997
There are now two items described near the top of the TASS home page, each chock full o' data.
One is the page containing data from Tom's Feb 1997 collection. You can find the raw images, plus star lists generated by Gutzwiller, Richmond, and Gombert, plus astrometric analysis by Henden, all under
http://www.astro.princeton.edu/~richmond/tass/tom_feb97/tom_feb97.html
The other is a (small but growing) collection of star lists for the special fields "A" and "B" which make up the "Stupendous Man Scan Plan", or SMSP for short. Mike Gutzwiller has provided star lists from 4 different nights, and I'm hoping that Tom Droege will send some data he has mentioned. You can find this data under
http://www.astro.princeton.edu/~richmond/tass/smsp/smsp.html
Again, anyone who has data or analysis on either dataset, please contact me directly so that I can continue to add more material to these pages.
Tom Droege
droege@wwa.com
Mar 1, 1997
I have put a dozen files up on storm under incoming. They are
S30t0504.714
.723
505.714
.723
s31t0504.677
.686
505.668
.677
s32t0504.677
.686
505.677
.686
Neither day was particularly good. The moon was right there and
so were some thin clouds. These were all recuced with Mike G.s
sigma setting at 3. This gets down to mag 13 + which I want to
see for political purposes. I think a cut on position will sort
things out nicely from the noise. But what do I know about
statistics, so I will recompute these with the setting at 5 if
you all wish.
I compared one of Mike's files to one of mine by printing out a 100 stars. The two lists look much alike. The stars found on both lists all compared within the stated error (well within 3 sigma).
I continue to be encouraged.
George Turner
turner@bigbang.astro.indiana.edu
Mar 2, 1997
> So maybe another file format would be: > > jjjjxmnn.ccc > > jjjj modified julian date > x site > m camera > nn sequential file number (set to 00 for starlists) > ccc file type.Arne's suggestion is a good one; I have thanked the stars so many times that we decided to use JDs with our RoboScope data. It is a very powerful tool to be able to manipulate large amounts of data in a numerically sequentially way. You've got to keep in mind that computers will be dealing with the data much more than humans in a one on one way Often times a simple sort of filenames gives me the sequence for input data further down in the data reduction pipeline. I would however move the sequence number to after the MDJD to be able to take advantage of this sorting ability; How's about :
jjjjnnmx.ccc jjjj modified julian date nn sequential file number (set to 00 for starlists) m camera x site ccc file type.I also have swapped the camera & site because all filenames will have a certain predefined value that has the same meaning at all sites; the site variable will be different to everybody by definition. Simple MJD to local time conversion programs can easily makeup for any handicap resulting from humans not being able to decipher the filename.
Usually when a human wants to look at the data, it'll be because you want to go to that frame to find out what went wrong in the data reduction pipeline. Your data repository will be very much like a library; think about going to the library card catalog, getting the address of the data you want then going to that location and looking at the data. You'll often want to compare data from that point both forward and backwards in time. The simplest way would be to take the MJD of the time the file is opened . Since it's a drift scan, the length of the file will give you some sense of time with each row representing some kind of cosmic tick of the TASS clock.
(With RoboScope running on VMS & Un*x systems we use the full JD out to 7 decimal places with the decimal used as a period in the filename; this gives you 1/100 of a second which is the limit of most computer systems clocks. Setting your clock to that accuracy will be the topic for another discussion.)
Another idea is to use hex numbers for the sequence number; that'll give you 255 numbers instead of 99 and computers can easliy deal with them. Heaven forbid someone has enough trouble in one night with the thing starting & stopping that much; but hey, RoboScope can very quickly generate tremendious amounts data, mail messages, filled disks, overflowed buffers and other computer disconcerns when things don't go right.
Arne Henden
aah@nofs.navy.mil
Mar 2, 1997
Looking back over my emails, I think that I am replying too quickly and often without thinking. I am going to make it a policy to hold off 24hrs before answering a mail-list comment/question to give others a chance to voice their equally valid opinions, and to give me time to better compose messages that might be taken incorrectly!
Glenn G. wrote:
> The centroiding algorithm that I am using gives better than 1 > arcsecond resolution when used on digitized POSS data so I am sure that it > is fairly accurate.I replied:
> Which POSS digitized data are you referring to when you quote 1arcsec > resolution? And what do you mean by 'resolution'? How are you > measuring the accuracy of the centroid?...This dialog might be construed to mean that I think Glenn's results are poor. He has been getting results as good as anyone else! The POSS comparison is a good reality check, and shows that his centroiding is in the right ballpark. The point I was making is that the POSS material is considerably different than TASS images, and that to refine your centroiding, you need to compare TASS images with other TASS images. However, I am genuinely interested in the questions presented above...they were not meant to badger!
Once the quality of the images has improved (or at least everyone agrees to leave them in one state or another), then I think an investigation into different centroiding schemes could be valuable. The best article I've seen on centroiding techniques is Ron Stone's (AJ,97,1227,1989). We've found that most techniques work well on mid-brightness stars; they differ for saturated objects, extended sources, and stars near the sky level.
Arne Henden
aah@nofs.navy.mil
Mar 2, 1997
Tom wrote:
> ...But I want to point out (again) the real > goal of this project. It is to get people interested in all sky > surveys, and go develop a pool of software tailored to the job.Thanks for properly reminding me of the second letter in TASS! With the results from Tom's posted images, it is clear that you can cross-match star lists, get 'ok' astrometry and photometry, adequate for many projects and personal interests. I forgot to mention the obvious in replying to Chris' comment about what quality of data was necessary -- you don't need high quality astrometry to discover moving objects.
At the same time, if a couple of nights of effort can improve the quality of the images, you win big-time, even for the asteroid problem. For example, changing the 3.4 pixel fwhm to say 1.2 pixel fwhm:
Chris Albertson
chrisa@wavenet.com
Mar 2, 1997
> At the same time, if a couple of nights of effort can improve the > quality of the images, you win big-time, even for the asteroid problem. > For example, changing the 3.4 pixel fwhm to say 1.2 pixel fwhm: > (1) a sharper peak makes star detection easier.One of my questions was "Can you do this?" Assuming the lens resolves 80 cycles/mm at the center and we use 9um pixels.
What _should_ this lens be producing? Remember it is far from defraction limited. The 80 figure is just a reasonable guess but the figure could be between 60 and 100.
Michael Gutzwiller
Michael_Gutzwiller@AICI.COM
Mar 3, 1997
>*> FWHM in x and y for each. The software then finds the median FWHM in x and >*> y for all the candidates and assumes this is the FWHMs of a "typical" star. >*> The software then throws out any of the candidates from the first step >*> whose FWHM in either x or y varies by more than 25% from the median. This >*> throws out spurious peaks, **saturated stars**, etc > > Does this account for the lack of bright stars (> mag 8 or so) in your list: > they've saturated some pixels and are rejected?Most of the bright stars are rejected because I mark as invalid any pixel at 32767. No peak is allowed to have an invalid value so almost all bright stars are thrown out apriori. The brightest stars detected in an image are in the mag 6.5 to 7.0 range.
>*>> Along these lines, some figure of merit for "best astrometic fit" to all >*>> the appropriate catalog *positions* would be useful. >*>> .... I can probably get you a good >*>> PROCEDURAL example from the (radio) Ohio (State University) Survey >*>> publications in the Astrophysics Journal: let me know. >*> >*> A good idea. There are lots of other figure of merit as well, such as >*> constantness of the sky background, etc. In general in any halfway decent >*> image all SAO stars are seen unless they are too >*> bright and saturate the CCD or A/D converter. > > Hmmm. The implied question by my comment is: how good is your determination > of RA and dec for this image? You've used the SAO catalog, and "fit" some > of the stars in it to corresponding stars in the image. How good is the > fit? (I'm not presuming in this you are using the MAGNITUDES from the SAO, > incidently: for example, Michael Richmond does not use this information > in his location/astrometric algorithms. That would be another kind of > "fit", I think.)Unfortunately the fit to the catalog varies from image to image depending on the vagaries of the star matching routines and the distribution of the brighter stars. If the image and the test section of the catalog overlap only in a corner but enough stars overlap for a good match to occur then the stars in the opposite corner have poorer RA and Dec determinations than usual. Even in these cases though the RA and Dec should be good to about 1/2 pixel.
Arne Henden
aah@nofs.navy.mil
Mar 3, 1997
George Turner suggested some good mods to my second cut at filenaming.
I originally suggested using a sequential file number (00-99) in the filename rather than julian day fraction because: (1) I didn't see any need to know the starting day fraction of an exposure since each row in the frame has a different time tag; and (2) it was easier for me to identify the stored file at a later date. If it had a file number of 06, then I knew that there were 5 earlier files. 99 files seemed to be a reasonable number based on the 15-minute intervals in each FITS file.
After thinking about it, I'm not sure that approach is best. The starting julian day number will often change during a night (for Arizona, it changes just before dawn; for Europe, it changes after dusk), and then how do you handle a sequential file number? Perhaps it would be best to use the day number and day fraction like tm3get and Roboscope. Or, alternatively, take the approach that many observatories use: keep the julian date as the starting julian date for the entire scan, even if it rolls over during the scan.
If you use the day number and fraction, then you run out of characters without modifying the extension. For example (Henden v3),
jjjjfffm.xcc
where
jjjj Julian Date -2450000 fff JD fraction m camera x site cc file typeor, if you are happy with 14.4 minute granularity for the date (Henden v4),
jjjjffmx.ccc
or, like George mentioned, you could make jjjj, ff or both into hex or
base-26 (a-z) to save a digit or two at the expense of human readability.
I currently like version 4, as it works with the current TASS scanning strategy. It has the limitations mentioned by George (such as when you are starting/stopping with greater frequency than the current 15-minute file intervals), but meets the 8.3 spec. If you find it constricting, then use base-16 or base-26 to encode the date/time.
Our filenaming with FASTT is quite different. We use the year, daynumber, and sequential file number like
y97d053.105
primarily due to historical reasons and to keep commonality between all
of the CCD systems (stare as well as drift scan). Also, FASTT does more
than TASS-like drift scans, as it has a shutter and can move in declination.
Therefore, a typical night's observing includes a variety of projects, from
scanning long strips to looking at single objects as they transit. This means
that coming up with a good file-naming convention for TASS is just as new to
me as it is to you!
Michael Richmond
richmond@astro.princeton.edu
Mar 3, 1997
Following Arne Henden's suggestion, I have created a new subset of the HST Guide Star Catalog for TASS data-munchers to use. It contains one star per 20x20 arcmin grid, all the way around the celestial equator, covering Declinations -4 to +4 degrees. The stars range from 8 < V < 13.
The file has a simple ASCII format, to allow easy access. It contains 26,653 stars, and occupies 1.14 Megabytes. You can download the ASCII version, or zip'd version which is about 336K.
You can find a more complete description on the "TASS Catalogs" page,
and also download the catalog from that page.
I'm at work making comparisons between the various posted lists
of identified stars from one of Tom's test images g0483.967 (an
I band image at RA 200 to 206, decl -3.0 to 0.0). Richmond will put the
results on the Web page as I complete them. They are not fancy, simply
"do your stars look the same and are in the same place as my stars?"
for one of Tom's many files. I'm a little frazzled as this involves
printing sorted lists and matching stars by trial and error; and
hand calculations of many little numbers rather than writing programs
and using spreadsheets. My sample is small, too: the first 50 or so
stars out of hundreds, for one file out of several. So far, I'm looking
at position and magnitude for comparison. I hope to uncover any catastrophic
problems between these list: a "reality check", not much more.
One question arises in this process: To M. Richmond, M. Gutzwiller,
G. Gombert (two Michaels's here force this name convention):
What are you guys using for an absolute magnitude reference in your
posted star lists? Richmond I believe is using the Landolt stars, where
such appear in the image field. If they don't, what do you do? (My
image file of choice apparently has no Landolt stars.). Gutzwiller, are
you using the SAO magnitudes - my file of choice has about 40 of them
in it, but it was not obvious to me they "appear" in your output lists
as matching identified stars. Seems all these are close enought that
there is *some* effort to use absolute candles!?!
Simple results:
MAGNITUDE: Richmond
offers both "instrumental" and "abs. magnitude" values: I ignore the
former for comparisons, he says they differ by a constant from the latter.
Gutzwiller and Gombert provide magnitudes. Richmond's and Gutzwiller's
seem more consistent (over my sample, within +/- .2 mag) than
Gombert's (over my sample, Gombert's varies from about half a magnitude higher,
with occasional highs to one magnitude).
POSITION: using Richmond's findings as a reference, Gutzwiller
RA varies from Richmonds by +/- .0015 or so; Gutzwiller's dec varies by a
similar value roughly. Gombert uses pixel positions only: his X value
(column) is 15 pixels higher than Richmond's, his Y value (row) one pixel
higher. Additional variance is about .1 pixel in column and a little more
in row.
REFERENCE STAR LISTS:
As noted above, for one file the SAO offers 40 stars, the Landolt zero.
More clever calculations of distributions and noting exceptions can
be done by the principles, or by me at a later time. (Whew!)
Here is a man after my own heart. One who actually prints out data and
then looks at the numbers and adds things up with a pencil and paper.
Well, Herb, there are not many of us left.
I have been doing the same thing. First I printed out a few star lists,
then I wrote a QBASIC program which helped with the process so now I can
have it find all the data for a star and put it up on the screen. It is
easy to see on the screen when you look at the data that the high sigma is
due to one funny point from anothe star in the data.
The two of us with our hand methods will keep the big computer program
users honest. I have seen such efforts in physics turn out complete
nonsense until some of us actually looked at the real data. (Reactions
in the target shielding were producing off track events. The big programs
were confused, but as soon as one hand plotted a few raw events you could
see what was happening.)
Does anyone have a good clean and deep image that overlaps
one of more of the TASS fields that were posted. The Palomar
survey is now published on a set of eight CD-ROMS. Would
this work or has the compression algorithm killed the data?
I would like to be able to answer two questions about a list
of objects reduced from a TASS frame:
I know there are other ways to do 1 and 2 (especialy 2) but
I'd still want a clean image that goes a mag or two deeper then
TASS.
aah@nofs.navy.mil wrote (with edits):
I can probably come up with an ST-6 image taken with a 16 inch F/4.5
Newtonian that might be useful for comparison purposes. I will check my
"image archive" and see.
The "Real_Sky" data takes up a LOT of space ~15 megabytes for a 1
degree square field (thats the largest area the software will let you select).
You have made an excellent suggestion, one that we should try to
make some measurements/comparisons on...
Rick White did a paper on hcompress (available on the net) that
references some studies on image quality for Astronomical data. His
conclusion was that Astrometry is hardly affected by compression of
modest ratio's (20:1), and degrades for higher ratios.
The DSS is available on the net, however, it is in very small field of
view. Do you have access to the actual CD-ROM's?
in a later message
The URL to the Digital Sky Survey is:
http://stdatu.stsci.edu/dss/dss_form.html
There are other methods for retreiving the data. Take a look at xephem
3.0. I have not been able to get it working yet, but it is supposed to
read fits files, and retreive the DSS of the matching area.
The first half of my March observing run occurs this weekend, and so
far long-term forecasts look good. My intent (along with other projects)
are to provide 3 photometric sequences in each of the SMSP-A and SMSP-B fields.
The ones in SMSP-B are at:
The SMSP-A sequence centers have not been determined, but they will be
at roughly the same relative location (but centered on known variable stars).
Note that the CCD images for these sequence fields can be obtained from me
after Monday if you want high-quality images in the SMSP fields, and I can
probably provide CCD images from FASTT for the SMSP-A field at any time
(I just have to restore them from a tape archive).
Key to authors:
All in all, I'm still a little *amazed* that there is not a better established
list of reference stars. Having been around astronomy for awhile, I'm
not *surprised*, however.
According to my notes, the pixel size is given by
Using this, the drift scan rate on the equator is given by
Tom was getting 0.9178 for his Feb12 scans, considerably different than
the numbers above. I trust that the pixel size is probably very close to
9 microns, so my guess is (and assuming Tom has done his arithmetic right)
that the true focal length of the lens is more like 134.5 mm.
What are the scan rates that other sites are coming up with?
Also, a related site-specific question: for those sites actively scanning,
what fwhm are you finding for the 3 cameras? I'm curious as to whether the
3.4 pixel fwhm from Tom's February data is comparable to other sites.
Anyway, my basic question with regard to the software your running is why
stop with eight characters?
If you're using Win95, DOS itself (exit to DOS) will handle long file names
without any problem. I don't run Linux (we use NT in the shop for a
variety of reasons) but I would think it should be able to handle long file
names.
As an introduction: I'm a software developer with an interest in Astronomy.
My major strength is 3D real time graphics on PC's. I have to admit I
haven't been keeping up with the list, more or less just download a few
notes now and then.
I have thought about taking a look at some of the software mentioned on the
list .. I use a very fast DBMS system (CTree) that could help with some of
the routines I think, but I'm pretty busy at this point getting my next
software contract.
Since several people have asked for a "deeper" image of one
of Tom's fields, I've created some GIF pictures from the
Digitized Sky Survey CD-Rom. You can find them on the
page dealing with Tom's dataset,
http://www.astro.princeton.edu/~richmond/tass/tom_feb97/tom_feb97.html
The GIF images are a portion of the field visible in images
g0493946 and g2493909, two I-band images at high galactic
latitude.
If people find this useful, I can make available the FITS data
for this area, and/or create a GIF image for an area covered
by some V-band scan in Tom's set.
Bohdan Paczynski kindly provided a subset of the General Catalog
of Variable Stars, selecting stars with declinations (1950)
between -3 and +3 degrees. I have slightly re-formatted the
information, and precessed the coordinates to equinox 2000.
You can download this ASCII text file containing 386 stars
from the "Catalogs" sub-page under the TASS home page:
http://www.astro.princeton.edu/~richmond/tass/catalogs/catalogs.html
I have heard that the positions in the GCVS aren't very precise,
so don't be surprised if they aren't where you expect...
I tried running tm3get11 under a dos window in Windows 95. It couldn't
keep up. I don't have the tass control card installed in a linux system
yet (I am waiting on the linux version of tm3get11 before I install
linux on the TASS computer.)
I just couldn't find anything that was free and sufficiently high
performance, so that's why I went with CTree. There may be other
solutions, I was just brainstorming.
Because I've got a dark sky site and, due to work, lot's of computers
standing around, I've thought I could be a good site for a TASS setup after
things get settled down. I'm in Upstate NY. However, we've had three days
of starlight since December :-(
The 135mm f/2.8 should be about 50mm in diameter, which gives a
diffraction limit of
Bottom line: I still think you should be able to get 1.2-1.5 pixel fwhm
with the TASS cameras.
Chris wrote:
Michael noted that the coordinates for the General Catalog of Variable
Star objects are rumoured to be not very precise. My findings, in looking
at several hundred of these stars over my career, is that the coordinates
are within 20arcsec or so of the true position about 95 percent of the time.
There are some real outliers, but they are rare.
What is more common is misidentification, both in terms of whether the
star is even variable and in determining the variability type. Do not
believe that a star listed as an eclipsing binary is a binary...it could
equally easily be an RR Lyrae or Cepheid variable. Periods are often
aliases of something shorter.
Also, note that the GCVS has 386 stars in the +-3 degree zone. We found
in our variable star survey a statistical 4000 variables in 1/10 of that
zone, so there are about 100 times as many variables in the +-3 degree
zone as are currently known.
I was confused by Nick's recent message about Win 95, restarts, changing
autoexec.bat, etc. etc. until I saw this:
I want to make it clear that the reason we are playing with rsh, windows
95, and restarting is not to monitor temperatures remotely. We want to
run the data collection remotely. An ideal solution is a linux version
of tm3get11. What I am setting up for the APL TASS camera is a stop gap
procedure that we will throw out after the linux version comes on line.
The Tass Monitor task will let one unix computer monitor a DOS machine
prior to a data collection run.
For those of you interested in detecting asteroids in the TASS frames,
especially in the SMSP field A, there is an interesting paper by
D. L. Rabinowitz, "Detection of Earth-Approaching Asteroids in Near
Real-Time," 1991 AJ 101,1518. He describes the algorithms used by
the Spacewatch telescope to detect 'streaks' (fast motion in a single
frame) and 'motion' (slower movement between frames). He also gives
an indication of the magnitude of motion you should expect for asteroids
at different distances.
I played a little bit with different 135mm f/2.8 lenses on my KAF-400
based camera and found that most lenses are of very bad quality when
used without narrow band filters... they generally show a large blure
around a pretty sharp core... my guess is that is comes from chromatic
abberations...
I took some images using one of the lens that Tom uses and found that
It will give some very good images when used with a narrow (10nm) band
H-Alpha filter...
I still think that a high quality lens could improve the detection
by nearly 1 magnitude...
For reference, the fwhm with the 10 nm filter was 1.2 pixel.
The solution for TASS, as mentioned earlier, is to set up our own reference
frame, tied as closely as possible to the Landolt standards. Then, hopefully,
only a zero point will be necessary to compare TASS results with other
observers in the future.
While I still had the data on the hard disk I went through and
calculated the "average" FWHM of the detected objects in each of Tom's
images. Here are the numbers that I came up with:
I will try and repeat the same measurements from some of the data
taken here in Dayton over the weekend.
I have seen the same thing using standard 35mm camera lenses on a Cookbook
camera. I don't think the problem is limited to cheap lenses. One of my
lenses is an Olympus lens that ought to be pretty good. The problem is
that the designers never considered having to color correct these lenses
out to 10000 Angstroms.
Benoit wrote that he achieved 1.2pix fwhm with a 10nm filter, which sounds
reasonable to me. The 1.2pix number comes from the fact that the error
budget for imaging is less than one pixel, but you _never_ measure fwhm that
is only 1 pixel; it always gets spread a little.
Chris wrote:
My guess on this is as follows (and I mentioned it before):
A few variables (like Mira) _do_ change be enough that they would still
stick out -- but not many.
We've got to make our own photometric catalog, I think.
On Feb 19, 1997, Tom Droege wrote:
A quote from CCD Astronomy's Final Issue (last page, by Leif J. Robinson):
Folks, forgive a really dumb question:
is there a reason that TASS doesn't just use some kind of RFT Newtonian? A
wide angle Newtonian, with the imaging chip placed at the focal point
(non-visual) would be fairly well color corrected, wouldn't it? I'm
thinking that a short F ratio conventional Newtonian would have less
contrast due to the size of the secondary, but you could reduce the
secondary by putting the CCD in the tube, couldn't you?
If it's a dumb question, flame me privately and I'll go away
Don't get me wrong, so far, the project sounds really important and
superbly run. I hope to eventually be able to provide a site, as dark
skies and computing hardware is in abundance here, but so far we've had
only about four clear nights all winter :-( I'm in Upstate NY and lake
effect clouds seem to be the norm in the winter (this one's been
particularly bad).
Hi Tom -
I've been watching on the sidelines for a long time
but have been completely absorbed with my SNe studies.
But I thought that the CCD comment was the ULTIMATE complement.
TASS is representative of true 21rst century agressive
astromony done with pure guts and dedication and little money.
If nothing else comes of it other than the proof that
such cooperative effects can be done,
then you have been an immense success.
You should be very proud that you have had the
capabilities to keep this moving and flowing.
Not many people have these qualities. Congratulations!
Looks like I again got a bunch of pretty good data last night.
Boy, it is a struggle to get it processed and up in a timely
fashion.
I have been trying to put the star lists together and make sense
of them. One thing is clear, however bad the astrometry is, it
is good enough to match stars. The photometry is the big problem.
Some runs are much better than others when you compare the photometry.
Out of the seven runs I was studying for the V filter, three were
pretty good matching to about 0.1 mag at mag 12, three were so so,
matching to about 0.3 mag at mag 12, and one had 1 mag variations.
I purposefully don't say what I mean by "matching" above.
It is obvious we need lots of data. It is also obvious that we have
to adjust/select each star list as is is "added" into the "sum".
This all takes a lot of discipline. More than I have, since I am
doing a lot of other things. I will concentrate on taking data and
hope one of you can make good sense of it.
I encourage everyone else to take all the data they can. Particularly
the B field before it goes away (soon).
All questions are acceptable. It is not easy to say what is dumb.
The problem with the Newtonian is that if you have 135 mm focal length,
then you you get only a 34 mm dia lens at f/4. Putting a 3" diameter
CCD camera in the tube does not leave much light gathering ability. ;^)
At f/4 you have a chance to get the camera outside the tube, so it
can be done. But you can't begin to match camera lenses for possible f/
ratios.
The problem all comes from the size of available CCD's and the desire to
cover a large angle in the sky. To cover 3 degrees (and we want to cover
more per camera) the focal length is determined by the radius that forms
a 3 degree angle with the CCD width. This is close to the "standard"
135 mm focal length telephoto lens.
There are other problems with reflectors. If we had big CCDs, then it would
still be hard to get big reflectors because it is hard to get a large flat
field. This can possibly be done with Schmidt cameras, and we are exploring
that. But at the moment, the cheap and easy solution seems to be camera
lenses.
Tom and Mike G. so far have been gathering data on SMSP-B and posting that
data on Michael R.'s computer. Both of these sites have been using Mike G.'s
extraction software.
I would like to encourage these sites to archive their raw scan data.
There is still some discussion regarding how to properly flat-field these
frames, and much discussion as to the proper way to extract the data and
apply astrometric and photometric corrections. If the raw data still exists,
then we can go back and try different techniques.
Also, regarding Mike G.'s package, I would request that he add a couple
lines of code and output the fwhm in x and y for each detected object.
I know that he applies some shape parameter cuts before accepting an
object as real, but there will be many blended objects that pass such
tests and adding shape information to the output file will help us in
determining how to handle such objects.
I think the reason for using the 135mm lenses was one of cost and field-of-
view. I don't think it would be possible to buy mirrors (or more correctly,
mirror-lenses) of that focal length. You may get a better answer from some
of the other guys on the list. Tom?
I have been enhancing the "star" program and in the process discovered a
systematic error that, for once, is actually good news. I had created a
catalog for the "star" program based on the mini-GSC files Michael Richmond
created a while back. This was for both astrometric and photometric
considerations. Hopefully the astrometric values are better in the GSC and
since it went deeper in magnitude I could match more stars.
The new version of "star" will adjust the magnitude scale of the list to
best match the catalog. While testing the software I found the amount of
shift in magnitude increased as the catalog I was using went to fainter
magnitudes in the GSC. By the time the catalog got to mag 12 the shift
stopped moving though and the shift was the same for a mag 13 catalog and
the mag 14 catalog. Looking at the data by hand I discovered that brighter
stars were consistently measured below their GSC values. To illustrate
this effect I have uploaded an Excel spreadsheet to:
storm.fnal.gov/incoming/graph669.xls
The graph is a scatter plot of GSC magnitude vs. the difference in
magnitude between the star list and the GSC magnitude in Tom's g1493669.fts
image taken to 3 sigma. The graph shows a flat distribution for all stars
between mag 9.0 and mag 13.5. A notch appears beyond mag 13.5 when the
limiting magnitude is approached. From the graph I estimate the limiting
magnitude at 14.5 (50% efficiency).
For brighter stars (mag < 9.0) a systematic error begins to take effect so
that the magnitude error increases as the GSC magnitude decreases. The
effect is such that a matched star with a GSC magnitude of 7.0 is typically
measured at 8.0 in the list.
I believe what's happening is that bright stars which have TASS V or I
magnitudes lower than the GSC magnitudes (B?, P?) are preferentially
selected since they are bluer and do not saturate the A/D converter as
easily. ("star" ignores any star which has a saturated core.)
The end result is that the magnitudes published by the "star" program based
on its (100,000 ADU = mag 8.5) baseline are about 1 magnitude too low. I
now estimate the TASS 3 sigma limit to be near mag 14.5 as a result.
Arne wrote:
I seem to be good at this kind of dogwork, so I'll continue on it.
Richmond is posting my reports on the Web page (under Tom's "original"
set of images and further analysis"): I encourage comments.
Meanwhile, one comment not yet in my reports. Richmond and Gutswiller
apparently use the same pixel coordinates in their starlists: they
report the same stars in the same places. But Gombert's star lists
(the two I've checked) are consistently reporting "X positions" or
pixel column values 15 pixels greater; and "Y positions" or pixel
row values 1 pixel greater. Mutual agreement would be convenient.
After gathering ~160 megabytes of data last nigth (still unreduced)
I have outfited one of the "I" band TASS cameras with an infrared blocking
filter that I use with my ST-6. It should block any wavelength's longer than
about 0.7 microns. I am interested in finding out how the PSF varies as the
near-infrared is removed from the "W" TASS camera.
I will calculate the mean PSF that I have calculated from the data
run taken last night and compare the two it should be a very interesting
experiment. It may help to sort out how the wavelenght transmission through
the lens varies as a functions of wavelenght for the TASS triplets.
I will post a raw image or two on Storm when I get some data taken
(tonight if the weather clear's up).
Iam *very* curious as to where the "offset" is coming from, after
matching up numerous stars to postions measured on the image I get < +/- 1
pixel variation from the "raw" image to the postion shown in the star lists.
It would be nice to get to the "bottom" of this. There should be little
variation between the three technqiues (especially on btighter stars's X & Y
positions)
I have posted several example(s) of this in the last several weeks
and will show this in the TASS Technical Note that I am putting together on
astrometric and photmetric data reduction.
An interesting thing to try :
since a good deal of the star light is spread over n pixels, reducing
the aperature of the lens might actually improve star detection when
the camera is used in light poluted areas...
The core of the star image might stay about the same while the background
level would go down.
Glenn G. wrote:
Regarding pixel addressing: The 15 pixel offset is of course because one
program ignores the beginning blind pixels (i.e., only uses the true image
area) and the other one includes them. Likewise, a +-1pixel error usually
is due to whether the program is counting rows starting at 1 (like Fortran
and IRAF) or at 0 (like C).
I have yet another request for folks writing the extraction programs.
You list the RA,DEC,x,y,mag, etc., but you should also include the UT or
JD for each object (since they are not identical). This is the only
way we can properly handle variable stars. The UT can be calculated by
using the beginning UT for the frame and adding the 0.91sec/row offset.
This is a very tough practical problem.
The location of my reports on the Web page is described in another TASS
mail message today. I would be encouraged by any suggestions as to how
to make additional and useful stellar magnitude comparisons. The "astrometrics"
of location seem to be a solved problem.
It's occured to me that another way to reduce saturation is to use a
rotating mask, that is to block the field of view for some percentage
of the time. Since we do a row shift every .9 seconds, a half-moon
circular mask rotating at, say several rotations per second, would
reduce starlight by 50%. In effect you are sampling the stellar field
at a rate much faster than the shift rate. This scheme would preserve
the focal ratio and other optical parameters in use - an easy camera
modification for most of us. (Keep the motor away from the camera.)
But we need 9th magnitude or better to find asteroids and other objects,
so this scheme is at best a way to calibrate to brighter, better-known stars.
The intent is to use only and IR blocking filter and not an "I"/"V" band
filter(s) to use all the visible light shorter than 0.7 microns. Then
conpare this to see what kind of effect this has upon stellar FWHM in as
compared with "I" band images.
From my perspective, I read those comments as congratulations
more than anything else.
I am however puzzled by the position of Leif Robinson. Indeed
there is a lot of new astronomy that can be done using CCD
cameras, and TASS is only a small aspect of it all.
I'd then appreciate if Sky and Tel would show less amateurs
pushing glass, and guiding nice astrophotos, and more amateurs
doing astronomy instead. If Sky and Tel is not showing the
way, then who's role is it ?
When the average John Doe starts astronomy, he looks in sky and tel
to see what the others are doing, and usually he does the same,
he starts looking at NGC0001 and stops at NGC9999, then photographs
the same. Hasn't done much astronomy in the end, and Sky and Tel
is ( to my opinion ) partly responsible of this state of
affairs. CCD cameras are changing the way we do astronomy only
if people are shown that this can be the case. Reducing the
CCD camera to a faster way of making nice images of the sky
is in the end ( taking into account all that's left for amateurs
to discover ) quite pityful.
Sky and Tel ( since CCD astronomy does not exist anymore ) should
open a new regular page on amateurs doing astronomy. And there are enough
of them to make a full page in each issue. I am aware of those
amateurs discovering variable stars, novae, supernovae, following
satellites, following asteroids, doing spectrographic studies,
surveying the sky with blurry 135mm cameras ;-), you name it.
So Leif, put the paper where your mouth is :-)
( I hope this remark is as mild as I hope it is, cross my finger
that this translation is not agressive ! ).
Sky and Telescope is attempting to reach a common denominator, as an
observer rather than a industry leader. This gets into the fuzzy area of
the role of the journalist as a maker of the news instead of the
reporter. I feel that you are correct in that by not showing amateurs
crossing the line into professional research they are not reporting the
whole story. You may also be correct that by limiting what the amateur
sees as a scope of effort, S&T may also be implying that extending the
state of the art is not the realm of the amateur.
I think it may be useful to forward this thread to Sky and Telescope.
Their e-mail address is:
(This is listed for General editorial inquires. There is a long list of
e-mail address at:
http://www.skypub.com/s_t/s_tmail.html
Well, I finally gave in and bought a second ZIP drive to move
data from the basement to the 2nd floor data analysis machine.
The problem was that the 2120 in the basement was only slightly
compatable with the TR3 drive on the analysis computer. It would
loose about 1 file in 10. A real pain. So I thought the Zip would
be easier. ;^(
Installing the ZIP took all morning. The Zip software would just
hang the computer when it got to the program that loaded the program
that found a drive letter for the Zip. This lead to the standard
problem. Something in autoexec.bat was hanging the computer but I
coulden't edit autoexec.bat because it was hanging the computer.
Now where is that DOS boot disk when I need it.
I finally got it going after extensive excercising of my four letter
vocabulary. It turns out that the Zip drive did not like mouse.com
in the autoexec.bat file. Now just why should that be?
In any case, I am now set up to send 100Mb data sets out to data
munchers that don't have a telescope. I am preparing a disk for
Arne, perhaps he will pass it on to someone else that wants it.
Herb's point is well taken that the lack of good "standards" make it
difficult to make good photometric calibrations of TASS images. I have added
a "Tech Note" to the Dayton TASS Camera Home Page, as well as asking Michael
to add this to the TASS Home Page on photomertic calibration using the image
of M67 that I posted to storm several weeks
ago.
(http://www.infinet.com/~ggombert/tass.html)
It was taken with a 16 inch Newtonian telescope and SBIG ST-6 ccd
camera with a "V" band photometric filter. The image has 11-12 well known
reference stars in the image that have well published photometric magnitudes.
Dr. Mattei at the AAVSO was kind enough to supply a copy of the
AAVSO cailbration chart for the M67 region that was very helpful in
calibrating the catalog output for the image.
I carefully tried to set the "zero point" of the Sextractor program
and then checked the magnitudes that were generated for the other 11
reference stars in the image. It is an excellent way to compare the
photometric accuracy of any method for generating star-lists. I have shown
the star-list output as well as the photometric magnitudes for 11-12
refernece stars (with comments out to the side).
It looks like a few percent photometric accuracy should be possible
on a routine basis with careful calibration. The other star magnitudes in
the GSC/SAO catalogs are just not accurate enought (as Arne has pointed out
several times). This makes it very difficult to tell how accurate
photomertic magnitudes as being calculated in TASS images.
I would be happy to supply as set of the AAVSO M67 field reference
data upon request. (Just give me a mailing address). I think that this image
should prove useful in evaluating various ways of calculating instrumental
stellar magnitudes.
Ya know, the Japanese have a real astronomy magazine. It puts S&T to shame
as an instructional device for observational astronomy.
The following is a report on my cross-comparisons of three star
lists of Tom's image S31T0493.669; list made of course by Richmond,
Gutzwiller, and Gombert. Michael Richmond, please archive this as file
"rpt1493.txt" in the area of the Web page with my other report. It's
short enough that I thought I'd simply put it out on the maillist.
(Note: the report exceeds 80 columns of text.)
I'll make no further astrometric comparison reports, as it seems
we have no problems there. I'll do no further photometric reports until
I come across "better" catalogs. As Glen Gombert noted, the catalogs
in hand are not sufficient. - Herb
THe "pretty pictures" explanation is the only way to account for the
photos of star trails in the astronomy magazines.
As a member of a number of astronomy clubs, I can personally confirm
increased public interest: we have larger memberships, more people
come to our events, star parties are bigger and there are more of them.
As for your comments that all this is "not real astronomy": well, again
my amateur experience is that very few amateurs engage in scientific
data collection. I recall, for instance, an amateur who has set a goal
of being the person to have seen the most asteriods. He does this
by charting where they will be, and then he looks at them on successive
nights (to confirm their motion) and then he makes a simple diagram in
his notebooks. *However*, to my surprise, he does not bother with efforts
to note the *exact* time of his observations, nor does he bother to determine
exactly *where* in the sky the object is. Thus, his observations have
little scientific value. But he *is* #2 in the world now in "counting
asteroids".
The point is, it is futile to argue about what "real astronomy" is or
should be. The point is to do it, as best you can, and to report results
and "spread the word" that even simple but CAREFUL observations can make
a difference - and can be fun at the same time. Asteroid occultations
are brief events, but even with a telescope and stopwatch they can
be EXTREMELY important in establishing asteroid orbits and size, as
well as determine very close double stars.
As we report on our observations
and how we do them, someone else will be inspired to do more careful
work. That's how *I* got into all this. But we must all work harder to
write up and report our results. Write a paper; give a talk; post
results and methods on a Web page. Most astronomy clubs and Web sites
are BEGGING for original work!
As for the public interest in pretty pictures: well, the public provides
donated funds for many of our astronomy clubs, and their taxes pay for
many government-funded astronomy programs, so there that is.
I would not suggest complaining to Sky and Tel; I'd suggest writing
articles, and *encouraging* these magazines when they PUBLISH original
AMATEUR work of scientific merit. Just my opinions of course.
And of course we also need "better" reference catalogs, if such can
be found or made.
I *would* encourage a sequence number for all lists, to make references to
individual stars easier. Then of course any computed information can
be easily added to a secondary list crossed by sequence number.
Herb asks "how good is the shift clock timer?". I give it about 0.5% over
normal room temperature. If you let it warm up, and have the computer in
a room at pretty constant temperature, then it will hold to about 0.1%.
The next one will be at least x10 better.
I am preparing a couple of Zip disks with raw data. I have nearly
10 days of B data and I think 9 days of A data. I plan to ship these
to Arne Hendon with instructions to ship them on to the next person
on the list who asks for them. Anyone else want them? Otherwise, I
will just have him send them on to Michael Richmond.
I made another trip to Vermont this weekend to run the triplet.
I'll write a detailed report in the future, but here's the short
and sweet:
Do you have a way to copy this 100MB or so of data to some
other media?
For example I do not have a zip drive but can translate between
QIC-80, 4mmDAT, CD-ROM formats. Maybe someone else has a few
other formats they can read/write.
What media does everyone have? Those of you with cameras
and without cameras. If we all post our capibility it
may be possible to work out an exchange order where no one
has to spend money for new hardware.
I'll go first:
Chris Albertson:
With my 4mm drive, I would not mind archiving data. The
cost is low. I can store about 3GB of image data on one
$9.00 tape.
Chris suggested we list what media we can support, as a guide to data
transfer capability.
At work, we use Exabyte almost exclusively. Similar to DAT (just older
technology) and about the same cost/GB. Our drives are 8500's, 5GB/tape,
$2/GB. Very slow access, though.
I archive all my CCD data on CDROM as we have an old writer at the
Observatory. Cost is higher: $15/GB or so. Very fast random access,
but at 120MB/night, the current round of CDR only holds 4-5 nights of raw
frames.
We also have the 3.5" MO 240MB drives. Commonly only used for backups
for the PCs. Expensive media, but rewritable.
At home, I use a 2120 (CMS Jumbo 250) for most of my backups. Tom has
convinced me that I need a Zip drive for compatability with him, so I
will go out and buy one this week and probably install it on an Observatory
PC so that I can get his files onto the local network. Zips are ok,
kinda slow and more expensive/GB than the other alternatives. Drives are
cheap, though. The Jazz might be a better choice since it holds 1GB/disk.
My personal preference is to save the raw TASS frames on tape (DAT/Exabyte)
as that is the current cheapest method. Tapes do not have long-term
stability, but once you get the extraction software debugged and stable,
you should rarely have to go back to the raw files. Tapes are difficult
to write so that they can be read at other sites, so they should probably
be local archive only, and some smaller media selected if you want to
ship data site-site. Internet is ok between two sites with high-speed
links, but you wouldn't want to transfer 100MB/night over a 28.8 modem.
Hopefully, this round of raw fits file transfers will not be the norm,
and we can just transfer the extracted data in the future.
This is getting off the subject of the TASS project, but it's worth making
the point that if the work we do is to be useful, it must be done in
a repeatable, verifiable way. I'm over 40: I was taught the
scientific method in JUNIOR HIGH school (8th year of public school). Today,
all that kids probably see of science is a bunch of "first discoveries"
rather than the patient, persistant, repetitious nature of most
scientific work. In this context, sometimes I feel foolish just for
asking for old data: who wants to be "second"?
Just an observing update for those of you working on the SMSP-B field. I've
had two clear nights so far, with another clear one predicted for this
evening (this is why the Southwest is a desired astronomical site).
I have data now on three SMSP-B fields, a total of several hundred
stars in BVRI filters and from V=9-17. I should be able to get it
reduced by the end of the week and will send the results to M. Richmond
to post. These sequences should give workers a good start in determining
the faintness limit with the cameras, and more stars with which to
perform color transformations. I also have data in the SMSP-A field,
but am not concentrating on it this month. Also, this setup of secondary
standards is a special case for the SMSP fields. I don't intend to do
it throughout the entire equatorial region as it just takes too much
observing and data reduction time. I feel it is important to do it for
these special cases for proper calibration and understanding of the
TASS camera performance.
I can't work much brighter than V=9 here. If someone wants to get some
data on stars from, say, V=6 to V=9 in the SMSP-B field, I think that
would be very useful in checking saturation limits and magnitude effects
on the cameras. I am willing to help such an observer in reducing the
data and setting up the proper 'cookbook' for standard star observing.
Chris A. wrote:
This is a good point, and I'm glad Chris brought it up as many folks
may not have used _real_ database systems before. However, I don't feel
it is all that useful for the TASS database. There will be a different
set of parameters for each FITS file, and so many for a given night,
and that doesn't count the multiple cameras/site and multiple sites. When
you start combining these datasets, especially if you start indexing on
an individual object rather than a given frame, there may be considerable
added complexity. I _much_ prefer to tag each observation with its
unique time, and then you can combine any way you want.
Also, I still feel that all TASS software needs to be public domain and
not a purchased commercial product. We do this bookkeeping with homegrown
programs at the observatory with little effort, and more customized than
the typical database program. That is not to say that an individual can't
munge the TASS dataset with whatever software they have available, but I
would like to have some basic tools available to all.
Hmmmm! GB Weld works great to patch a hole in your auto manifold,
possibly not so good at -20 in Vermont though. I used this over
standard Epoxy because I though it would be stronger. Next time
you fly in a jet liner remember they are mostly glued together.
Just remove the lens ring (four screws) and scrape off the surface
so you can glue it square, and use 10 Ton epoxy to glue it back on.
Make sure both surfaces are clean. I have had one or two lenses
pop off, mostly from a shock.
The VCO setting will depend on the tempreature of the room with the
PC. My thinking was that people lived where PCs live and generally
like to be at about 20 C. The next design is better. I have also
set it up so the computer can read the temperature of the VCO and
make a second order correction.
I don't understand the temperature jumping problem. With the roof
off the shed, I would worry about condensation on the printed
circuit board in the camera. Possibly just put it in a warm dry
room for a couple of days. Is there such a thing in Vermont?
Even a few drops a second of water will be enough to cool the camera
so no damage is done. Then the warm water will soon make it's own
path.
Hearing about problems is very helpful to me. Believe me, every one
affects the design of the Mark IV. I keep designing in more
corrective and diagnostic features.
Congratulations on adding to the data store. We should soon have
enough for some modest statistics.
Michael Richmond noted in his technical report on Droege's February
images that he saw an anticorrelation between dark current level and
TEC temperature. That is, as the temperature went down, the dark current
seemed to go up.
Actually, I think Michael was seeing an effect that we have on all of
our CCD systems. The data Michael was using were the 'blind' columns after
the image array, and those pixels include both dark current and read bias.
On our CCD systems, it is the read bias that changes most with temperature
after you get the CCD relatively cold, and it does change in the opposite
direction. For example, on our Tek/SITe 1024x1024, the bias level is zero
at -60C and 200 DN at -100C. This is one of the reasons why it is nice
to have CCD overscan, as you can separate the two effects.
Nick suggested CDR media for TASS data storage, and in general I agree that
it is the most transportable and longest-lived of the mentioned media.
After all, that is why I archive all of my CCD data on CDROMs!
I didn't suggest it for storage because not all sites have CDR writers.
These still cost $500-1000. While Nick was willing to burn CDROMs for
TASS (and I could as well here at the observatory), you still have the
problem of getting the data to Nick. That is why I mentioned the Zip
drives, since Tom already has one, and they are in the $150 range, install
off of the printer port, and you can reuse the media (making it ideal for
transport to different sites). Also, I still feel this is a short-term
solution as we shouldn't need the raw fits files. Roboscope (I.U.) throws
away all of its frames after processing; our 1.3m with its 6kx8k will
probably do the same.
My experience is somewhat similar to Michael's in that I usually end
up with a different VCO setting that I use on a given evening's data
collection run. I often spend 45minutes to 1 hour "tweaking" the VCO to give
the best results.
I have found that if I do not do this that the data quality (FWHM,
etc) is not nearly as good as it could be if I do not take the time to
adjust the VCO.
As I understand it, CCD overscan simply means that you read out a few
extra pixels on each line??? If so, why don't we do it? Note we would
not have to change the format, we could (just) modify the code to read
out a few extra times, then put the data somewhere in the existing blank
positions. I would not want to change the data format at this time - in
the middle of a data run, but we might do it before the next serious
push, which I would judge will be starting in July.
Comments, Arne, Norman??
Glenn wrote:
Sorry about the VCO problems. Not much to be done at this time.
I make sure I turn on the computer several hours before I start taking
data. I also try to keep it at a uniform temperature. Note that you
can run dark frames while it is still light (lens caps on) and do
VCO adjustments at the same time. You do not have to lose observing
time.
in a following message
OK, I agree that the VCO is a problem. How about it Norman, do you
want to demonstrate your virtuosity?
Everything we need is there to automatically adjust the VCO. At least
to the PC clock accuracy, which could in theory be corrected by the
stars as they go by. So how about setting the VCO time interval instead
of the VCO DAC setting. The software could check the time every 100
lines, compute the real clock rate, and make a correction to the DAC
setting. Closed loop servo enthusiasts will note there can be a stability
problem. It will just take a small enough loop gain, or some serious
analysis.
Dear Tom,
in a following message
We have been going through a long and painful process of alignment, VCO
adjust and focus on our camera. I have noticed that the VCO settings
seem to need adjustment over each observing period. That may become a
problem if we operate our camera remotely.
Is it possible for the computer the make the adjustment automatically
(assuming that the problem is that the scan is not occuring at precisely
.914 seconds?). Have the computer do a average number of lines collected
over time, and adjust the settings to come out to the expected value?
One problem with ANY elaborate data file format is the long term. Ten
or twenty years from now, will these formats endure? That is why we
went to a FITS format for raw data, is it not? And if you argue that
"who cares in twenty years?" - recall we lack "old data" of
photometric and astrometric quality: but we may produce the "old data"
needed twenty years from now.
I was going to comment on the issue of software transportability and operating
systems. I'm not going to, it's like arguing against progress. But *please*,
don't make the *data* too fancy for someone else to use it. Pretend you're
sending it to your father, which is in a way true.
How far away is the Linux version of TM3GET11?
As has been noted by several camera operators, the VCO stability
is a problem for some installations where the electronics are not in a
temperature-stable environment such as Tom's basement. This is also a
problem for me.
When I get #5 back, I plan to work on a modification to improve
the stability. Tom, of course, could do it, but he's occupied with the
Mark IV development and shouldn't sidetrack to take care of a minor
problem on the previous generation. Anyone else could work on the
problem but most are busy with software. I am just mentioning my
interest in attacking the problem so that others can be aware that
the problem won't be ignored.
in a later message
It seems that a software servo may take care of the problem faster than a
hardware solution and not require field mods. But if a hardware fix is
needed for good enough results, I still stand ready to tackle it.
I was processing some data we collected last night, through the star
program to correct for dark current, and I noticed a line wrap around
problem. One of my images had a aircraft come in from the right side.
The line continues for a small part of the image. On the processed
image, the line appears on the left and then wraps around to the right.
Michael, if you would like, I can ftp the orignal and processed file to
storm for you to look at.
I displayed the image with my copy of deepsky, and with fitswin95, and I
believe the wrap-around is in the processed data.
Nick:
The PC clock can actually be pretty accurate ... if you use the right
routines. If you're doing Windows programming, use the multimedia timers
-- they are right on usually. The human ear can really detect when an
audiostream isn't on, so the multimedia timers are very accurate. In DOS,
you can (with the right routines) get very accurate timers also. The
standard 'get tick' stuff is only accurate to 17ms I believe -- pretty
coarse.
I'd build in a routine to send a few status bytes periodically instead of
trying to dump a screen anyway. You can format the data.
A "watchdog" timer might be a good idea if you're worried that the remote
device isn't paying attention.
I didn't think I exported this bug but apparently I have. In some versions
of "star" an extra FITS card appears in the processed header. This has the
effect of shifting the image by 40 pixels. If the first 40 pixels in the
first row of the processed image have consistent values of (I think) 8224
then that is indeed the problem. This has been corrected in later versions
and in any case did not affect the positions of the stars in the star list.
If this is not the case then let me know, otherwise it will be corrected in
the version of star going out
in the next couple of days.
Tom asked about overscan, and Norman replied that there is an empty position
in the current format that could be used to store an average of X overscan
readings.
Since the overscan is just that -- extra reads in each row that theoretically
have no signal -- you could store the average of X overscan readings as
Norman suggested. There is a finite chance that a cosmic ray could hit the
serial register and contaminate the average, but I think it is unlikely.
Another alternative is to replace the first set of blind columns since they
don't work well anyway. I prefer the blind column replacement since we can
then look at a number of overscan columns/row and have a handle on the rms
scatter as well. That also keeps column 799 (0-relative) open for future
expansion.
So my proposal is:
Norman -- fwhm = full width at half maximum. I love acronyms :-)
I would like to hear more about the VCO drifts. Norman was quoting a
value of 1% fluctuation, but I didn't hear over what time span this
variation was occurring. Note that the VCO stability is a major constraint
on the quality of the astrometry. If it was off 1 part in 1000, then
you are off one pixel in a given FITS frame, and the RA error would
be off by 14 arcsec! Obviously, you are doing better than that, but I
plan on checking Tom's latest dataset to see if there are any trends
in the astrometry that could be attributed to this drift.
I'm not sure the PC's clock is all that accurate. On the PCs at Lowell
and at least one PC here (though we aren't a PC house by any means), I've
seen drifts of 1-4min/day, or worse than 1 part per thousand. Usually,
it is consistent and could be calibrated out, but perhaps not in a
non-temperature-controlled environment. I think perhaps the best empirical
way to adjust the VCO is to monitor the fwhm in RA and adjust for the smallest
width on the central column.
Also, and I'll keep harping on this, all extractions need to have the
objects time-stamped if you ever intend to do serious monitoring of variable
stars. If the VCO drifts during a scan, the time/pixel varies as well.
We time-stamp each row as it is stored (extra telemetry). Norman -- is
the UT in the header referring to the first row of the image (even though
these first n rows are from the previous fits image/scan), or the first
new row?
Michael Gutzwiller wrote:
From an amateur's point of view...
It seems to me that the UT of the time-stamp of the reduced data should
coincide with the middle of the exposure. This would be the UT when the
row that is being read out was in the center of the chip.
Ron Wickersham asked,
This could work with TASS images, but note that, with the current
800x896 format, each one takes 15minutes to read out. If you just used
the UT for the center of the 'exposure', then the accuracy is
only +-7.5mins, when knowledge of the actual central
exposure time for a given row is far better than this. For some slow
variables like Miras, such an error is irrelevant. For fast variables
like RR Lyr stars, you would really like accuracies approaching 1second.
Because of the 468sec exposure time, you don't have 1second time resolution
on the light curve, but you can place the blurred mean point very accurately.
Likewise, when you start scanning away from the equator, the images become
banana-shaped and you can start getting even better time resolution along
the trail.
One reason I have not got the data disk out the door yet is that
I keep getting good data. I am just swamped moving data from one
place to the next and getting it on archive tape. Soon the moon
will be looking right down the telescope and I will catch up.
I did look at a few events - four where the sky was clear - in the
A data set. When sorted and searched I got four measurements for
almost every object with the sigma level set at 5. I wrote BASIC
code to look for BOSOs (bright objects seen once). But I did not
find any. ;^(
I will wait to run more data through Mike's program until the moon
is here and I get the next version of the code. This data set of
four scans in V looks very nice. .1 mag sigma for most 12 mag objects
and .02 mag for the bright objects. So I am optimistic that another
round of corrections will help.
Dear Nick,
I have had several requestes for the source files (*.c, *h) files
that I have complied to run under windows95. I have uploaded a file called
"Esource.zip" that contains the files that I have been using.
No "warrenty" is implied but I will try and answer any questions.
I've placed the
source code ZIP file
into the Software area
of the TASS home site. MWR
Norman wrote, in response to Nick:
Norman - let me know what you think of 2.0.2 Linux. I've held off
installing Linux on the home machine until I've heard that it is stable
for development purposes (I no longer try to stay on the 'cutting edge',
having had too much blood drawn in the past).
I have just converted Emmanuel Burton's new version of "Sextractor"
(ext12b.zip) over to run under Windows95 and uploaded it to Storm /incoming.
It is version 12b, which looks like it has a number of new features which
will prove useful in reducing TASS images.
It has not undergone extensive testing but appears to work OK on my
Dell Notebook computer running Windows95. No "implied warrenty" but I will
try to answer any questions if I can. I plan on using to reduce the "A" and
"B" fields from the TASS data beging collected here in Dayton.
I will try and put together a TASS technical note in the next few
days about the new features of Sextractor and how they might be of use.
I've placed the
executable ZIP file
into the Software area
of the TASS home site. MWR
The change should only be made between files so the astrometrics are
consistent for an individual file.
Norman asked for input regarding changes to the next version of tm3get,
and one area of changes was in the fits header. I've gone back through
images taken at several professional sites, and want to suggest some
additions and changes that should be straightforward.
Any comments?
The perpose of setting the VCO frequenty is to keep the scan line
period constant.
Norman asked if TASS should use pixel 800 as a counter or time stamp
for each row (this was based on my comment that FASTT timestamps each
row). Since the exposure time/row is on the order of 468 seconds, and
the VCO is at worst 1part/1000 accuracy, then if you use a known UT
for the start of a frame and just offset by clockrate*rownumber, you
get sufficient accuracy. I don't think, for TASS, there is sufficient
justification to use the single remaining engineering telemetry 'pixel'
for timestamping.
However, you should be able to adjust your PC clock to a few seconds
accuracy so that the starting UT is reasonably correct. An accuracy of
+-4 seconds would give about +-0.0005day error in the JD, which is about
right considering the length of the exposure and the expected periods
of the variable stars to be discovered. As mentioned earlier, I would
suggest that every object extracted from the TASS frames be timetagged
at the 0.0001 JD level.
I would not expect the VCO to drift very much in any one 15 minute
period. The main thing that causes it to change is temperature. The
usual reason that one might see any drift is that you have just turned
the computer on and it is warming up.
A few simple rules should keep the VCO pretty constant.
The noise an jitter should be nearly invisible. i.e. no short term
variations. This because there is a big integral involved in the
count down circuit.
I have looked at this long ago with a counter timer. I did not see
anything short term within the accuracy of the test equipment.
I was quite skeptical when Tom designed his camera around a VCO.
We are using the quartz clock of a microcontroller to provide for
a reference. The effect of an unstable source clock is to "stretch"
the right ascension scale, i.e. it might provide for a poor
astrometry, or at least a non repeatable one. I think that the
criteria has to be better than just "getting round stars".
I do believe that for Mark II it is OK ( or barely OK ? ) to use a
VCO, but clearly for a longer focal length telescope, this is
an important point to take into account. A stalibilsed quartz source
or any other system stable to 10e-6 would be preferred. I don't know
what USNO is using as a reference clock for their scans, but for
example the Observatoire de Bordeaux transit circle is using a
rubidium clock, in order to make really high precision astrometry.
We are about to change our system, since we found that at a given
level of precision everything changes, even the telescope "at rest"
is not at rest really, it keeps flexing mostly during the beginning
of the scan exposure. Then the quartz clock is not stable enough. So
we are going to get a 5 MHz fed into the system coming from atomic
clocks at the other end of the Observatory.
I believe a stabilised quartz should be OK for the next version. I do
believe also it will be better than the PC clock.
The first camera Christian Buil got running in scan mode was using an
internal timer of the PC. If you have a detailed description of PC's
hardware you will see that somewhere ( don't remember of it right now
but could look it up ), there is a free running counter which you can
not program but which you can read on the fly. I guess this is the one
which generates the 18.2 something interruptions by seconds. The idea
is to know that you need such and such time interval, and you read
this timer with a small assembly language routine in order to see
how much has elapsed since the last time you read it. Say if you need
a time interval of 0x1000, you read the timer and if you suppose that
it is at 0x9000, you are going to read it until you have passed 0x8000,
then watch for 0x7000, 0x6000 and so on. An assembly routine can read
the timer within a few counts of precision, and it works well from
what I have seen.
Which enviroment and which software is the group as a whole using. For a
while I thought that linux and IRAF was the choice but now it seems that
win95 and sextractor is the choice. Are these exclusively different
softwares or are they similar but on different OS's?
If someone could clear up this issue for me it would be appreciated.
How difficult would it be to a quick alignment capability to TM3GET12?
One reason it is taking so long to align our telescope is that we must
wait for the telescope to clear and then ramp up before we can see if the
camera must be adjusted for alignment. Even after that, we must judge by
eye if the rotation was too much or not enough. Is there a way to readout
how much alignment error we have?
These are two very different tools. IRAF is a giant collection
of many different "packages", which are designed for specific
sorts of analysis. There are "packages" for astrometry, for
photometry (many of these), for spectroscopy, for X-ray images,
etc. It's very complex, with many different parameters which
the user may adjust for each task. The learning curve is steep.
Don't even think about trying to modify the source code :-)
On the other hand, it already does almost anything you want.
Sextractor is a small program that analyzes "reduced"
optical images. It does one thing. It's simple, the source
code is small, and one can imagine modifying it. Just yesterday,
I wanted to know what sort of algorithm it used for centering --
and found it in about 4 minutes, without looking at the manual,
just by reading the source code.
If you want to tinker, or spend less than 30 minutes trying to
figure out how to use the program, choose Sextractor. If you want
to do many different sorts of analysis, including the dark-subtraction
and flatfielding, and you like cool interactive windows and graphs,
choose IRAF.
Just my opinions.
Arne has kindly referred me to his previous work on TASS and dark pixels,
and has noted the first ten or so pixels do not behave as dark pixels
should. My apologies for initially stating otherwise. Although they
are "old ground" I will look at them further, and the more legitmately
"dark" pixels at the other end, in preparation for further work on
problems of pixel timing and on sky background. Tom has noted to
me that sky background dominates dark current, which is true. But
dark current is more easily determined, and whatever tools and
analysis I develop for the former will help with the latter. I have
some other experiences with backround removal that may produce something
new to us later.
in a following message
Chris notes this avoids the problem of reading a pulse on demand, requring
some kind of interrupt. Makes sense to me. A generic 24-bit I/O card
for the PC ISA bus can be bought for about $45. A divider could be added to
it, again driven by the aforementioned stable source only at a higher
frequency. Before I look further, is THIS of interest: a somewhat
programmable, stable counter I/O card?
Other provisos; Norman says "he's out of slots in his Pentium". I tend to
think of a TASS PC as a seperate computer, probably some old 386 system.
"One computer per task" is my preference, your mileage may vary. He suggests
counter resolutions toward .1 millisecond. 16 bits offers 64000 counts,
that would be 6400 milliseconds before wraparound.
But this idea is approaching the point where it's "cheaper" to fix the
Mark III cards than to develop elaborate work-arounds....Mica Wickersham
suggests he'll look at this, I've offerred him some suggestions privately.
Meanwhile, the software to process a PC's internal counters could likely
be adapted to read an I/O port for a custom counter card.
It is already there in tm3get11 The "F" key gets you the point spread
function. You don't have to wait the full 470 seconds. You can tell
pretty quick if you have done the right thing. Remember, you get to
make three adjustments at once. I usually set the VCO way off. 10%
or so. This gives nice long diagonal lines for the stars. Then you can
rotate the three cameras at once and see how they change. Four or five
trips to the camera gets everything rothated. Then you just have to
make a few changes in VCO speed and plot them to figure out where the
minimum is. The F key plot give a pretty quick indication of the
direction that you have made the change, so you only have to wait out
the full 470 seconds when you are very close.
I find I can usually do rotations and focus adjustments at the same
time.
Don't be too fussy. You will get to as good as the camera can be in
an hour of so of adjustment. You can do this any time there are holes
in the clouds, so you don't have to waste a good night. Please don't
try to make a silk purse out of this sow's ear. An attempt at a perfect
focus may be appropriate where the optics is perfect, but these camera
lenses are not that good.
I have found that the instructions that Tom has shipped with his
Mark III cameras actually works fairly well. The key is to get the long
streaks (with an "off-tuned" VCO) perfectly aligned in the N/S direction. A
fraction of a degree can cause the tilt to show up after a full-frame has
been read out from the camera.
It takes some practice to get the "hang" of it but you get to know
what to look for as you experiment with different settings.
I am in the process of putting together a TASS Technical Note on the
Sextractor program, it salient points, and the new features that the latest
release has to offer.
It is optimized to be used on large scale astronomical survey
projects such as the TASS project, it typically reduces a TASS image in
30-40 seconds on my Dell Note book computer with litte difficulty.Several AJ
artciles have been written about data reduction projects that have been used
by folks other than (other than the author), you can see some of these by
doing an Alta-Vista search on "Sextractor".
It also has the advantage of being able to calculate RA and DEC
directly once the World Coordinate System Key Words have been added to a
FITS image header. It is very easy to operate (just feed it TASS files) once
the parameter file has been setup for TASS image parameters. (I have posted
several examples of the parm's file that I have been using to reduce TASS
images here in Dayton).
I am well along on a GUI interface to replace the current paramter
file which should make it even easier to use.
Alain Maury has been using my version on Windows95 platforms that
run considerably faster that his UNIX workstation (perhaps he could comment
on this??) He has some very large scan files that have been reduced with the
Win95 version that I uploaded to Strom last Fall.
I did some research as promised. I'm attaching some source for getting
sub-ms accuracy directly from the CMOS hardware.
However, that's NOT the most accurate timer. On a Win32
platform the Win32 function QueryPerformanceCounter() is QUITE a bit better
(0.8 microseconds, or 0.0008 ms). I haven't tested Win95 yet, it might
actually be a bit slower as it's threads are mixed with 16 bit code. In
any event, it's possible to get at least 1ms out of Win95 with the
multimedia timers. This is without writing a VxD (Virtual device driver)
which would be the right way to do it anyway.
The multimedia timers I talked about before are in fact accurate to
within 1 millisecond. Although they are called "Multimedia timers" all you
have to do is call the right function, you don't have to actually play MIDI
files or anything (MIDI requires sub ms accuracy).
Again, the PC CLOCK will NOT be as accurate, because some software
(LEMMINGS is an example in the Microsoft knowledge base, interestingly) is
rather poorly behaved and makes the CPU miss the 'timer tick'. Any ISR
that delays longer than 18ms will make this timer tick miss. Recently,
some 3D video cards were guilty of this, so it's not just old software.
But if you use the hardware directly, you get the above accuracies.
The confusion comes from equating the PC clock (i.e. time at the DOS
prompt) with the CPU timer tick. The latter is accurate, the former isn't
always. On CPU's that support timer services, we can get to the
microsecond area via the QueryPerformanceCounter().
Furthermore, don't forget, the CPU timer is pretty accurate, as it's got
to refresh the DRAM on the motherboard. After all, the main processor
clock is crystal controlled of course.
LINUX on a PC would use the same hardware with the same limitations of
course -- I'm not sure what the Linux equivalent to
QueryPerformanceCounter() is. DEC Alpha PC's seem to have the same or
better counters on board that are accessible through
QueryPerformanceCounter().
Now, don't get me wrong, I'm not against building a better timer on the
TASS hardware cards, I just wanted to check out the PC accuracy. Why build
extra parts if we don't have to? Still, might not be a bad idea. I don't
know how accurate the PC Xtal clock is when the temperature swings,
although the power supply would keep it a bit warm.
P.S. Caution about the source code below: it's quite old, and I note
4.77Mhz being used in a couple of spots -- I'd recommend experimenting with
it before you use it (if you don't want to use QueryPerformanceCounter()).
Look at the source code and explanation.
The World Coordinate System Parameters are calculated by selecting
25 brightest stars from the FITS image and the HGSC region that the image
occupies, then a "pattern match" between the two is utilized to calculate
the WCS parameters from the image.
A routine to do this can be found in the Universtiy of Iowa's
ATFTools Kit. The process is decribed in TASS Technical Notes #22/#23. It
does not requires that the stars generated from the star-list be "matched"
with another program. It allows the RA/DEC to be calculated for each object
that is "extracted" from the image.
If you have any more question let me know.
We did some spring cleaning a few weeks ago; correcting
the problem with the nuts glued to the wires, checking
clamps on the water hoses, dusting and cleaning the lens.
We placed TASS 5 a.k.a. 6 (since I'm not sure which one we
have) back into our enclosure and waited for clear skies.
Everything worked except the images from the West pointing
camera, which seemed to have no real focus point. I get fuzzy
rings or fuzzy dots (or like a snow flake). I suspect it's frost
inside the CCD chamber, but the hose that connects
the desiccate tube fell off and moisture may have entered.
Tom, do you pull a vacuum on the drying system?
Can moisture easily enter the CCD chamber?
Have you ever experienced frost inside the chamber ?
I also suspect a problem with a TECs. When starting up the TASS,
CCD Temp remains at 0.65 until the clearing routine is completed,
sometimes it lasts through the Ramping Up phase.
This is unusual, normally the CCD temperature starts dropping
immediately, eventually settling at -10 deg C.
It appears one of the TECs doesn't kick in immediately and since
measuring system does an average temperature you would get
this reading, if the following is true.
Conditions: X = TEC at -10 deg C. (OK) & O = TEC at ambient (or failing
to cool)
Alain wrote:
We get our absolute time (to about a millisecond) from GPS, and then
use that to update the internal clock in the Silicon Graphics about every
5 minutes. The internal clock gives us microsecond resolution, sufficient
for our scan rate generation.
For the fast CCD system I built with Mark Wagner at OSU, we use a pair
of internal boards in the PC. One contains the power and mechanical hooks
to mount a small GPS receiver. The other is a small micro that keeps a
counter of GPS time, and holds the count in registers when an external
trigger occurs. We use this system to time-tag rows on the MMT CCD controllers
after the fact using IRAF, so that we don't have to modify existing software.
The external trigger in this case is the start of a new row. For the
high time resolution CCD system, we are not interested in sidereal rate
generation, but just to clock the CCD at the fastest possible rate.
Note that there are several schemes of getting accurate absolute time
into a PC, including the 2board setup above as well as WWV clocks, modem
time signals, NTP protocol across the Internet, etc.
John Gwinner posted a long note on accessing the 8254 counter/timer
chip in the PC. Yes, it has good time resolution, but I am not sure of
the basic accuracy or stability since it just uses the on-board crystal
with no temperature compensation. I've never seen where anyone has checked
this!
Herb suggested building up a timer on an I/O card for the PC. There are
many of these available commercially, ranging in cost from $50 up. The
cheap cards use a crystal oscillator fed into an 8254 or a 9513 counter
chip; the expensive ones use a temperature-compensated oscillator. This
would of course reguire another slot, which seems to be a rare commodity
in some computers.
Tom's suggestion of changing the VCO at most once per frame is good,
though I wonder about the 20 extra scan lines at the end of one frame
(since they are supposed to be at the beginning of the next, and therefore
supposed to have the scan rate quoted in the fits header). Perhaps the
solution is to use the 800th pixel and store the current VCO rate there,
and allow it to vary even within a single frame. Then decide how you
want to determine the new rate (external frequency counter, fwhm calculation,
whatever).
I would still like to see the magnitude of the effect. How much do you
change night/night, and during a night? If the effect is real, it may be
of low-enough magnitude that it only affects the astrometry (since your
images are huge), and can be calibrated out.
There are a couple of tests that I would like to see, but since I don't
have a TASS camera I am asking someone who does have one to make them.
The image size question still remains. Michael has taken some data with
one of his cameras 'stopped down' by using an aperture mask. An expansion
of this test would be useful, perhaps using aperture masks on both an I
camera and a V camera, and varying the size of the mask. This will tell
us if stopping down the current lens/filter configurations will improve
the images and by how much. Second, I would like to see someone try an
R filter instead of an I filter to see if using a passband within the
corrected range of the lens will help (note that this also has the potential
of giving TASS V,R,I as an option). Third, if someone has a narrower
passband filter, such as a Stromgren or Gunn, around 500-600nm, it would
be interesting to see if narrowing the wavelength range improves the images.
Another test would be to replace one of the lens with a lens of supposed
better quality (like a true Pentax or Nikon lens), and see if the images
get better.
The flatfielding issue is unresolved. I would like to see someone take
some data during twilight, at about half-saturation in the camera, to remove
stars and to make local light sources less important. There were two other
flatfielding schemes proposed: a white card placed in front of the lens,
reflecting either twilight sky or moonlit sky; and a diffusing screen/glass
placed in front of a lens, with any light source (including the night sky)
imaged through it. Flatfields taken these ways can be compared with median
flats from scans to see if there are overall gradients that impact on the
photometry.
I will be happy to reduce the data from any of these experiments.
I saw an announcement in sci.astro.research today from the
Planetary Society (a private organization which supports
planetary research). They are planning to award grants
ranging from $1,000 to $25,000, and will accept proposals
in 3 categories:
There appears to be no description of this NEO Grant Program on
the home page of the Planetary Society:
Personally, I have no plans to apply -- I don't NEED the money to
do what I want to do. Everyone has a unique situation, of course;
but I suspect that, as a group, we'd get more done by ignoring tnis
announcement and just working hard for the next few months.
Dear Marty,
I'm going to the pulsation meeting in Los Alamos in June (close to the
time of the AAS meeting), and will be presenting a paper on the FASTT
variable star survey.
At the same time, since TASS is covering SMSP-A, which happens to
lie inside one of the FASTT regions, I would like to include V and V-I
data from the TASS scans for the variable stars discovered by FASTT.
Does anyone have any objections to this? I think it is another
avenue of publicity for TASS.
Below are the "A" & "B" fields that I have identified (so far) in the
Dayton TASS data. Since all the data is archived on tape I had to sift
through it over this weekend. It took a while to search through all of the
data taken so far.
Hopefully I will be able to generate calibrated star-lists from the data in
the next few days for the TASS Home Page.
I finally finished this round of changes to the star program. I have also
moved to a new ISP so the URL has changed to:
http://home.fuse.net/deepsky/tass.html
The changes to star include:
I've uploaded to storm.fnal.gov under /incoming/smspbstd.tex a list of secondary
standards for the SMSP-B field. This file is in latex format; someone
(Michael?) can edit out the TeX commands if you want to use it as
input to a reduction program.
The catalog is available at
http://www.astro.princeton.edu/~richmond/tass/catalogs/catalogs#smspb
These standards are in three 11x11arcmin regions in SMSP-B. They range
in brightness from V=8.6 to V=17, and so should be good to use in determining
faintness limits on the TASS frames. The astrometry is good to about +-0.1
arcsec; the photometry is typically 0.01mag accuracy, using a 12arcsec aperture.
They were determined on the basis of three consecutive photometric nights on
the 1.0m telescope. I don't think there are any variables lurking in this set,
but to do really good secondary standard work, you would need to take one or
two additional photometric nights spaced from the original three to remove
long period variables. Also, I do not have very many 'bright' stars in this
set; I could have selected my fields a little more carefully to give you a few
more brighter stars. Maybe next time!
I have started getting standards in the SMSP-A field, and hopefully will
have results for you after the April observing run.
in a subsequent message
After observing the three SMSP-B photometry fields and thinking about
TASS photometry in general, I have a suggestion for all writers of
extraction software.
In comparing photometric data sets, you have to be careful that you are
not comparing 'apples with oranges'. Especially with the large images
from the current TASS setup, there will be image blending at different
scales. Magnitudes calculated from psf-fitting will be different than
aperture magnitudes, which in turn vary depending on the size of the
aperture. When combining datasets, it is best that the magnitudes used
are all from the same algorithm.
Now, I am not going to judge that one extraction program is better than
another. What I am saying is that we need to have ALL extraction programs
output a common magnitude for comparison, perhaps in addition to any
magnitude scheme that the program usually provides.
What I recommend is, for the next few months until the AAS and LANL meetings,
the extraction programs provide at least the following aperture magnitudes:
aperture diameters of 2,3,4,5 pixels, with annular sky at 6-9pixels. Sky
should be determined by the daophot 'mean-median' formula (sort sky pixels,
average the 10percent of pixels around the median to form a mean). The
four aperture sizes will cover the best to worst images I've seen reported.
I just wrote a small console program to time some things, so ironically I
needed the timer routines myself
All I did was to #include
Interestingly, the timer resolution was 179,660,000 which is pretty good!
(PentiumPro, 180Mhz, I'll also run it on a P-90 when I get a chance. I may
be able to put the P-90 outside to really acid-test it.
If your processor can't handle the I64 word, the LARGE_INTEGER is a union,
so you can break it down.
I'll try this under Win95 later this week, but it looks like all that would
be required is to include that header and then get better timer resolution.
Again, this is a console app, no GUI.
John D. Gwinner wrote:
I think it is an interesting problem but maybe not do-able with standard
PC hardware.
BTW the equivalent system call in UNIX-like OSes (Linux is one example)
returns time in u-sec as an integer but is only documented to be
accurate
to within 10Msec. Pretty poor. Some UNIXes may be better then 10Msec
but
if you depend on undocumented accuracy then your code is not portable.
The same coulbetrue of PC hardware. _My_ P100 system may have a very
good
Xtal oscilator with temperature compensation but some other PC could use
something much simpler.
Herbert R Johnson wrote:
What I got back from people who looked was that the CCD was temperature
cycling
with a period just shorter than the length of the raw data file. I was
also
told that the dark frames were taken early in the night perhaps before
the CCD
had reached a stable temperature.
Try taking a look at the stability of the dark (non-imaging) pixels of
files
posted more recently. Some of these turned out much better (flatter)
For accurate time on a PC, a GPS card (US$600 last time I checked, but
perhaps cheaper now) is a good option. If you only need time accurate
to +-1 second and precise to +- 0.01 second, the shareware program
rightime (downloadable from the WWW) does a reasonable job.
The important thing with the snipped I posted is that it's NOT a GUI ..
therefore, the tm ... program could use these timing services.
It's FAR better than the timing tick. So this is moving forward even if
not all the questions have been answered.
Not to be picky, but I hope folks are not confusing 'accuracy' with 'resolution'
or granularity.
John Gwinner wrote:
The bottom line: yes, you can get better timer resolution than from the
clock services. No, it is no more accurate than the VCO in the cameras.
Arne wrote:
I'm not sure I agree on the set aperture sizes you have proposed. The
"star" program uses an aperture based on the size of the psf for that
image. The width and height of the aperture are set to about 2*fwhm in x
and y of the psf. For Tom's images and mine this represents an aperture
diameter of usually 5 to 7 pixels. Anything less than this and I would
worry about jitter in selecting the peak position to contribute
significantly to the error in measuring the ADU sum within the aperture.
As for generating N magnitude measurements the obvious question becomes,
which one should be used when comparing one image to another? Eventually
you would have to pick one and always use it because of the volume of data
we need to process. I would feel more comfortable if I knew the aperture
was based on the size of the psf for that image so that a certain
percentage of the star's light was always inside the aperture.
Calculating the sky background as a mean of the median 10% is certainly
feasible and probably better than the absolute median that "star" uses now.
How do the others using SExtractor, IRAF, or other list generators feel
about these issues?
not to argue, I am proposing to do both. See below.
For those not read up on PSF fitting here is a overview. I have left
out
some detail:
I can also see a disadvantage to PSF fitting -- It is harder to do
correctly.
Getting a good PSF model is not easy. One must collect sample data and
build a database of measurments. A PSF should be modeled as a two
dimensional
function of (about) four variables.
So if I had to reduce a big pile of data today. I'd use aperture
photometry
as it is quick and simple but in the long run I suspect the PSF method
will
give better result.
Now I see there are basicaly two groups of people here on this list.
Those
with cameras and an immeadiate need to reduce data and those with access
to
only a sampling of data.
I will propose to two phased approach to TASS data reduction. 1) What
has
already happened put of necessity, a production mode. 2) A experimental
mode. I expect people who have cameras and data to be interested in #1
while others would somehow form a coordinated effort at #2. Results of
#2 could be folded back into the production effort when it warents.
Lately #1 seems to be taking shape. I suspect there are others
interested
in #2 but that there is zero organization of that effort.
I read over all the postings of who has what media types.
Interesting: not one flopy disk in the group ;-)
It _may_ be possible to work out a complex musical chiars
media format dance (where A give media type x to B who
copies to type y and forwares to C and D then D copy to
z and passes it to E and so on.) I think any such scheeme
would quickly break down. If there where only one or two
types of media we all shared it would work but here is the
results followed by some ideas:
I think we could use this USNET Model If we agreed on a set of rules
that realy amount to just being polite then data distribution
should work without a detailed plan. Here are my proposed rules:
The rules do not talk about media type. That is to be worked
out between each sender/reciever pair.
The key to making this work is for people to post "I have, I want"
messages. This plus agreement on a set of rules like the above
and we should have a regulated anarchy
I would be happy to supply my "A" / "B" Field data to anyone that is
interested. My other data is achived on bulk "Trevan-3" style magnetic
tapes. It would be more difficult to send out (but it could be done possibly).
I suggest that we make the "A" / "B" filed data available to anyone
that would like it , as well as any other "observing projects" that are
undertaken in the future.
This sounds good to me. The remaining thing needed is a place
to post the "I haves". Seems like the home page is the place.
I will try to work up a list of the "good data" that I have and
will ask Michael to post it on the home page. What say Michael?
One way to do this is to just archive the yyyymmdd.tm3 files that
are generated by Norman's program. There is a small problem in
that without extensive editing, there is only about 50% good data
on the runs that I have selected to be "good". It is a tremendous
job to edit out just the good data. So I would propose to post the
raw .tm3 files and let the "buyer beware" that the data requested
might not all be good. One might not always want the best data
anyway. If one is studying data to see how far into the clouds one
can push analysis, or working on "good data" detection algorighms,
then one wants some not so good data.
I would very much like to see Chris and some of the other data
munchers that don't have a camera have access to the data. This
seems like a good way.
My simple comparisons of the extraction programs on Tom's test images certainly
demonstrates that these programs do produce inconsistant magnitudes. It's not
only the methods that are different, it's also the photometric references.
And of course, they all beg the question as to which one is most correct,
as so far our photometric reference data sets are sparse. Worse, unless
our images are uniform (sky conditions consistent through the run), these
sparce references will not be enough. INcidently, I don't think we have a
"figure of merit" for quality of sky conditions. The traditional method
to minimize local conditions during sky surveys is multiple runs and averaging.
One of my intents, as I tinker with the data,
is to get a feel for camera conditions before I tackle such issues.
Not to complain, but the whole purpose of the media question was for easy
transport of reasonable amounts of TASS raw fits images. As I mentioned
much earlier, Internet is the logical wave of the future for this, but many
sites (including ours) do not have high speed data links. This means that
transfers of even one night's data from one site takes a significant
fraction of a day, and hogs the bandwidth from other users.
Also, say that we actually do get all 7 sites up and going, and that
half of them are taking data on any given night. This means 1GB data/night
coming from TASS sites, and even Michael R. is not going to give up that
kind of storage space on his computer for Internet downloads!
Tom has a Zip drive, and it makes sense to use that media as a first
choice to copy data to users with slow links and without cameras (Nick could
copy the Zips to CDROM for those users without Zip drives), at least for
the SMSP-A and -B fields. After that, I still say that the raw frames can
be archived at the originating site in any fashion that site wants, and then
send the extracted data files to Michael R.'s computer.
Michael G. wrote:
Saying that, I also realize that the TASS apertures are HUGE. For example,
in the 3 SMSP-B fields that I imaged, there were typically 100 stars brighter
than V=17 within a 100 square arcmin field, or about 1 per square arcmin
on average. The fwhm of Tom's I-band cameras is about 3.5 pixels, or about
a square arcmin. This means you have about a 50/50 chance of any aperture
containing two stars instead of just one, and with that second star contributing
10 percent or more of the flux. And this is 20 degrees from the galactic
plane and away from the galactic center to boot!
Therefore, my suggestion was a compromise. I did make a typo, as I
meant to say 2,3,4,5 pixel radius instead of diameter, which then matches
what Michael G. suggested: 2*fwhm as a minimum size. I suggested a range
of aperture sizes because some camera/filter combinations are giving fwhm
near 2 pixels, and some are giving fwhm of 4 pixels, and if the extraction
programs report a range of apertures, then the off-line reduction can select
the best aperture for the given site. The jitter in the peak position is
smaller than the error due to neighboring stars, so I would err on the side
of smaller apertures.
As I mentioned before, and as Michael Richmond has mentioned, a master
list of objects should be created by merging those nights with photometric
conditions. This will supply the list of 'known' magnitudes and colors.
Then all variable star measurements are differential with respect to this
master list, and even relatively poor nights can give good photometry.
As long as the photometric nights are transformed onto the Johnson system
using Landolt standards (or my small area regions), and use the same aperture
sizes so that the same number of neighbors are included, then results from
different sites should be combinable.
(You can sure tell when I get into work in the morning!)
Chris A. wrote regarding psf fitting. I agree with most of his points,
and you will find that many groups working with crowded field photometry
(such as MACHO and SDSS) are using psf fitting for their photometry. This
is most likely the best approach for TASS as well, since the big images
mean even sparse regions will act 'crowded'.
However, I've done a lot of psf photometry, and there are several major
problems. (1) you eventually need to place your photometry on some
standard system, and that requires aperture photometry for best results
since that is how Landolt acquired his photometry. This is very obvious
in fields like Ru149 and Ru152, where he is including several fainter
stars in the same aperture as his standards, so it is the ensemble that
is the 'standard'. (2) Automatic psf photometry is complex. Chris mentioned
several off-line and inspection steps to ensure that the subtraction was
done properly, and for TASS these steps have to be automatic. I think that
several man-months of effort are going to be necessary to get programs to
do automated psf fitting and deblending, and so strongly suggest that the
first approach is to do the simple task of aperture photometry and then
as a second step work on the psf fitting. (3) I am not convinced that
the TASS cameras are supplying their best images yet, and as the cameras
converge on the optimum image size, the psf delivered by these cameras
will change shape. Therefore, selecting an optimum technique for calculating
the psf may change as well. I would rather see effort put into getting the
cleanest images first, then step back and see whether something simple like
a two-dimensional Gaussian will work adequately or whether you need an
empirical correction such as that calculated by DAOPHOT.
The photometric literature is full of lists of stars. The historic problem
as it appears now seems to be: they did not use consistant standard stars,
they did not use consistent, *band-limited* methods. The additional problem
WE have that THEY did not is: we have inconsistant sky conditions. (We can
bypass this by only using the "best" images, but our skies are not good
even at their "best", and besides resolving this problem is more useful
to the AMATEUR community.)
Some comments:
Chris argued for removable IDE drives, and against tapes, CD-ROMs and
ZIP drives. Tapes are too much trouble, I agree there. Otherwise I
disagree with his assessments. To save time, let's just tote the costs:
One CD-ROM, under $10. CD Rom drives are "free". Writers require some
scrambling to find, they will be cheaper soon enough.
Five ZIP disks, 500 MEgabytes, $75. Divide cost of Zip drive by number of uses,
or borrow it, or ask the requestor to ship HIS/HER drive to you.
Cheapest IDE drive, $120-$150 new. Add docking station, removable drawers...
Tapes are slow, not standardized, and are incompatible sometimes anyway.
My ranking: CD-ROMs and ZIP drives, IDE removables a distant third with tapes.
I won't comment on Chris's distribution proposal as I disagree with his
premises. I will say the Usenet news analogy does not hold: being an archivist
or data producer is an intensive HUMAN activity and requires some particular
equipment. Passing News packets around is an automatic procedure with equipment
in hand.
There is a kind of "who bells the cat?" flavor to this discussion. Seems to
me it comes down to this: who will help the Mark III camera owners burn some
CD-ROM's? And: who will offer to provide custom data subsets from the
CD-ROM archives? The same people need not do both if you make more than
one CD-ROM set, which is only reasonable.
I would suspect the camera owners will find Zip drives convenient,
but it doesn't matter HOW they *temporarily* archive their data. But its
a signifigant effort and responsibility: if they aren't interested, the
argument is moot.
Some one or some group can act as archivist in two ways: to ARCHIVE the data
and to DISTRIBUTE the data. Archivists should have access to CD-ROM writers
and ZIP drives (requestors can always SEND THEIR DRIVES), support UNIX and/or
MS-DOS file systems, and/or provide an Internet FTP site: how they take it
in from the camera owners is between them and the owners, as Chris suggests.
How they trade in all this really is idiosyncratic (as you suggest),
so long as they can produce to meet demand. I guess this is a "marketplace"
model: the *public* question is, "are Zip disks and CD-ROMs and FTP acceptable
media to recieve TASS data?" My answer is obvious.
Finally, all this is a "tempest in a teapot" if few people want all the data,
and most people want a little data. Needs, interests, have not been established.
There are still discussions about throwing out raw data!
Chris, since it's ultimately up to the camera owners, and we have too
much maillist mail, I'd suggest taking this discussion *only to them*,
and also to any who want to be archivists. Has anyone volunteered to
"bell the cat"? Not me!
Initially, I'm not sure if your remarks are
speaking about the current efforts to produce papers for the AAS, or the
TASS effort in general. There is not much time for "production" vs.
"experimental" modes when the conference is this summer. My sense is that
we are *currently* trying to refine our methods to produce good data, i.e.
lotsa stars in position and magnitude.
In any case, Tom has made it clear we should focus our efforts on these
AAS papers and that seems reasonable to me as *time is short*.
If you want to develop a "production mode" process, it presumes a long-term
effort toward specific goals and results. If these results are to be of
reasonably professional quality, it seems to me that these upcoming AAS
papers will force us to create tools and resources that are of this quality.
I'm not so sure we are there yet. And, as you point out, we are still working
on the software. All in all, I'd suggest "honing the tools"
over "refining the process".
Not to mention: do we have consensus on a long-term plan? I don't want to
start an argument on the long term, but I'll mention one fundamental point.
Some folks have suggested "we don't need to retain raw data" as
we will (eventually) produce good star lists. I strongly disagree and I'm
not alone.
Your "division of labor" presumes those who have cameras will also reduce
and supply the refined data. I don't know that either, unless all this is
limited to TASS III camera owners, in which case all this argument is moot by
the Golden Rule: he who has the gold makes the rules. The TASS Mark III
"camera club" is of fixed membership: if you guys want to do specific
things together, presumably you can do so. But the Mark IV owners may
have other ideas....
As for your second group, I would not call my "experimental" efforts
"zero organization". If you mean it is not directed by a consensus, or by a
particular person; well, is yours? Is Gutswiller's? is Richmond's? Seems to
me you each developed your programs from your given backgrounds, plus
discussion among yourselves and others. To that extent, there was little
"organization" until Tom announced the AAS initiative. I've likewise taken
some direction from that initiative, and then from those who respond to
my work with "this is a solved problem" or "this needs more work" or
"thanks for your support of this". These kind of remarks are
all focused by the a priori statement, "we need these things for the AAS
papers".
If experimental efforts seem "unorganized", speaking for myself I say
that I've had to *work* to get at the processes and assumptions used to
create the various starlists to date, and work to develop insights into
what affects the data. Few people, and fewer amateurs, will do this kind
of work. Also, good documentation is also hard to produce: I commend
Michael Richmond and others for maintaining Web pages and writing such
Tech Notes as are written. I've organized my work to date in chunks that
represent my "learning curve", hopefully at least leaving a trail that
others can learn from too. Is TASS to be a "production" effort or an
AMATEUR effort?
Finally, I'll humbly suggest the critical problem *at this time* is now good
and confirmable MAGNITUDE estimates. The programmatic and observational
side of this is trying to resolve the consequences of variations in
sky conditions, and different methods between programs in use. The data-driven
side of this is finding a reference star list of "sufficient" distribution
of stars in our passbands. If we limit ourselves to near-perfect observational
runs of small areas with "many" and "known good" stars
we can sidestep this, but that won't work in general. ***Frankly, the
converse excites me: can we refine techniques to do good work in bad
skies?*** That's the AMATEUR side of TASS, and the great (but rarely cited)
value of CCD cameras in amateur astronomy. (Like Maury, I get weary of
beautiful pictures in the astronomy magazines: the good picture in crappy skies
is much more exciting!)
BOTTOM LINE
The bottom line of my response is this: we have AAS papers to produce,
primarily about generating good lists of good stars AND what it takes to
do so. Our core problem is consistent magnitudes, from a good reference
base of photometric stars; and either observing on clear nights or resolving
variable sky conditions. Might I suggest: When all *that* is done,
AND we get some feedback from the amateur and professional community,
we can get better organized around a production version of that work,
develop the appropriate resources and materials, and set some agreed-opon
goals. Then our starlists will be of known quality and thus of value.
Meanwhile, if you want some specific "experimental" analysis done,
*ask* for it explicitly, and (continue to) provide documentation so
it can be attempted: if other experimental work is also done which
suggests other directions or improvements, take it and offer thanks.
As for production work in the long term: if the Mark III owners have
some consensus on this they can of course do "production"; but they in
fairness should create opportunities for other folks to look at raw
data to "produce" their own results, either as new objects beyond the
production list, or to support a process of self-education and learning
(could be both of course!).
A closing self-comment: If you think my remarks are annoying, wait
until you are in front of an auditorium of amateurs and professionals and
you are telling THEM how you got your results! Better the devil you know
(me) than the devil you don't know (them). ;)
Looks like I've started an argument, I was trying to be neutral and
diplomatic
I was simply predicting that a grand plan for exchanging data would
likely not work and that data exchanges will have to be worked out
as bilateral agreements between sets of two people at a time. I was
also saying that with enough of these agreements everyone can have all
the data they want without over working any one person. I also do not
favor one media type over an other. Each has it's uses
Herbert R Johnson wrote:
It would be a very good idea to save up a few months of "A" and "B"
field
data then burn a half dozen copies to CD-R. but this would be a once a
month issue. _I_ will even offer to make a few CD-ROMS now and then but
I don't see it as a production mode media.
I think it all depends on volume and frequecy of transfer and what you
already
own. For example if two people found that they both owned 4mm tape then
they
would certainly pick that, as it can write multi-gigabytes to a $9.00
reusable
cartridge and is as fast as a SCSI disk.
I proposed a distributed system where nobody is required
to send out more data then they collect. I think I've beatten this
subject
to death. So I promise not to post any more of this stuff to the list.
My one idea that I think may have been missed is that there are enough
people that we can do it all: Reduce data now _and_ work on next
generation
data reduction techniques.
That was the summary. Details follow: (stop reading here if not
interested)
A few man months is a reasonable estimate. It is a small sized well
defined
problem that is solvable by a few people working together via the
Intrnet.
If the task were larger, getting into 1+ man year then I say we hadn't a
chance of success but this looks doable.
From what little I've seen I think you need a sophisticated model. The
PSFs
are not figures of revolution. Streaked stars may only be Gaussian in
on dimension and something else in the other direction. Likely worse,
the
Gaussian and "other" functions may be mixed as the streeaks appear to be
diagonals. I think this is a good area for study.
in a following message
This was sent to me and CC'd to the list but did not appear on the
list. I am reposting it.
It is from BARTHOLDI Paul
There is also an interesting method of Lucy to locate quite accurately,
even in overcrowded fields, the nearly exact position of the stars.
If you are further interested, I can send you the references to CLEAN
and Lucy's method.
This data interchange problem (I believe) is only a short time issue;
once TASS "goes into production" the only images you'll be keeping are
probably random images from a night to check quality control
or perhaps the software will evolve to a point where the data reduction
software can trigger the camera computers to save a particular
image because it found something interesting; (when it gets this far
let me know & we'll tie it into RoboScope's Trigger mechanism)
but we're a ways from that at this point. You're going to be producing
so much data that you won't be able to hold it all. Probably what will
happen is that the camera operators will archive as much data as their
disks can hold and oldest data gets deleted to make room for new data.
Right now the problem is getting data from the camera operators
to the software folks and getting their results feedback to the
camera folks. There is some need to exchange lots of
images because we're studing the stability of the camera systems
and an evolution of the software to deal with the various aspects
we're seeing in the images. But, I think this is best handled
by network servers for this volume of traffic. (in a couple of weeks
I can probably help out here) At some point we'll want to test the
software against large amounts of data files; one on one solutions
worked out then will be the best.
I think if everybody is expecting to have a duplicate copy of
all the data then they've got a huge, unweildy, problem on their
hands and no pratical way of doing anything with the data once they've
got it; just keeping one copy of all the data would be no less challenging.
(some infinities are bigger than others) The TASS system will have to be
an automated system and this data will have to be dealt with much as
time is; it's a fleating thing and you've got to make the most of while
you have it. Snapshots are allowed; keeping all of reality is not.
The full update to my report has been added to
the previous report
on the
TASS Home page edited by Michael Richmond. It will
have more "raw data". TASS maillist readers who are not interested
in numbers and analysis can probably ignore this message. - Herb
Chris suggested that my finding of "drift" in Tom Droege's dark pixels
(columns 790 to 794, counting from 0) was likely a temperature drift,
which he had previously noted. He suggested I look at other people's
images. This was a surprising tough assignment: only Tom is posting
raw data for the most part. I found an old image of Glenn Gombert's,
the image with an "asteroid" streak in the far end of some rows; and
an image of Michael Gutzwiller's. I could not find any of Michael Richmond's
raw images. Perhaps camera owners could be encourage to keep at least
a FEW raw images "around" for the curious.
Files from Gombert and Gutzwiller did not show the "drift" that Tom's camera
image did. The shifts in local average pixel value (run of 50) vs the overall
average (run of 890 or so) were smaller and varied inconsistently, well below
the standard deviation of the overall average. I also found that
Glenn's image, originally posted as "an asteroid trail", actually extended
into the dark pixels and I had to "edit" an affected row out (it's the only
Gombert image I could find) to remove its impact. This effect should be noted.
I think my method of monitoring the dark pixel columns - comparing runs
of 50 pixels to the entire run, normalized to the standard deviation of
the whole run - is a good measure of "stability". And it apparently also
offers some degree of automated "outlier" monitoring. If there is some
consensus on this, I'd encourage it be incorporated into our data analysis,
and maybe reported in the FITS header in some fashion.
Droege file "d0500244.fts":
Gutswiller file "32t0433.814" and Gombert's file "30T0478.642":
Reporting columns 790, and reporting the most negative and positive differences
in absence of a clear pattern:
**Raw Data: Glenn Gombert's camera, with "spike"
For Gombert's file, there was a bright streak which apparently extended into
the so-called "dark pixels". If these are truely dark pixels, this must
be an instrumental effect, maybe the previously mentioned "saturation
crossing over from one camera to another" problem (see the TASS Tech Note
on Mark III hardware problems which I hope references this).
I have been experimenting the last several evenings using Michael's
star matching code that I complied to run under Windos95 last fall and the
two (SOA, MGSC) catalogs that were generated by Mike G. to use with his
"Stars.exe" program. These two catalogs cover the entire area that TASS Mark
III camera's cover and this should provide more convinent access to using
star-matching as a way of providing astromertric calibration of TASS Images.
I was planning on using this as a method of "cross-checking" the direct
calcualtions of RA and DEC that are made by the SExtractor program from the
WCS parameters that are stored in the FITS heaser(s).
The reason that I was interested in trying this apporach with the
combined catalog files created by Mike G. is that it gets around the problem
of having to exract a "box-of-stars" for each image that you desired to
calcaulte RA and DEC for.
The TASS files that I have been using were several "B" fieldds that
have been collecting here in Dayton for the past several months. They should
yield similar results on most TASS images.
Prelimiary results show that about 20% of the stars that are
detected in the images are actually "matched" to entries in the SAO catalog.
This holds true for the 3-4 images that I tried this on last night.
When I tried the same files with the HGSC catalog all I got were
"heap overflow" errors from the star-mathing program, this was probably due
to the large amount of objects in this catalog as compared with the SAO
catalog. I probably need to change the C++ compiler setting(s) for the Heap
size and then try this again on the same files.
I will post some results to Strom if I can get a good set of results
with the complete HGSC file.
It appears the matching program you are using is nearly identical to one
of the matching tasks in IRAF. In fact, in the "stars" help file
Michael
says it is. If this is the case then the program does the match using a
similar triangles method and it is not such a good idea to have one
field
be much, much larger then the other. The reason is the software picks
the
best (brightest) 20 (or whatever the parameter is set to) stars in each
list to do the match with. If they do not cover close to the same areas
the
two sets of 20 stars will have few in common and the fit will not be so
good.
It is not hard to get WCS data from the FITS header, do a bit of math on
in and then use it as a selection criteria against a catalog. Then
create a catalog subset on demand for each image (your box of stars.)
You
do not need the whole GSC as the matching program will pick and use only
the 20 (or so) brightest stars for the match.
I still feel sory for you guys writing in C. I can do all of the above
in
six or ten lines of CL. ;-)
You have made a couple of good points, I find that I can only
"match" about 20% of the stars in any one given image using the SAO file of
Mike G. And Michaels star matching program. If you have to extract a
separate file (a "box" of stars) for each file to process than it gets very
cumbserom to process a lot of images this way.
It apperas that Michael has gotten around this problem by
pre-computing some of the matching information for each area of declination
by extracting each region and processing it ahead of time.This probably
works well for the region around 0 degreess DEC but what happens when the
Mark IV and beyond when you must "match" stars over the entire sky from many
different composite images? That's probably a "whole nother ball game"......
I guess this is why (conceptually) that I like the idea of
calcualting the RA and DEC directly for each object in an image from the WCS
parameters in the FITS image header.
I have been working through my lists to reprocess them with the latest
version of star. Is this appropriate at this time, Mike? The idea is
to get a big enough number of measurements for each star to start looking
for both a "fixed" set of candidates and a "variable" set of candidates.
Mike, do you plan to update your star lists on the web page?
I have just been making final arrangements with Dr. Bob Havlen to
give a talk on the TASS Project at Universe-97 that is to be held June 28,29
in Chicago at the Hyatt Regency. Bob is the Executive Director of the
Astronomical Society of the Pacific (ASP) and coordinator of Universe-97.
I will probably try and use some of the reduced data from the "SMCP"
to present as prelimary results for the talk. Universe-97 is the annual
professional meeting of the ASP and usually also includes several "high
level" talks by amatuers.
The TASS project is going to get some "good press" in the next
several months with Michael's talk at the June AAS meeting, the talk at
Universe-97 and a major article underway on the TASS Project for Sky and
Telescope.
The "URL" for Universe-97 is
http://www.aspsky.org/html/annual.html
if you would like to
check out further details. I attended two years ago at Universe-95 and found
it to be well worthwhile. Many of the talks are give by profesional
astronomers during the two days of "Universe" that carry it far beyond the
usual "star party".
Mike G. wrote, in response to Tom:
There seem to be enough scans to start this kind of processing. I
strongly suggest that you start with field A, as I know which stars are
variable there. It is always best to check against known results and
make sure you are doing things right before proceeding to the unknown.
You will need some time to learn how to match starlists, adjust the
photometry and detect variables. This is the fun part!
Given below is the abstract that I sent in for the June Pulsation
Conference meeting in Los Alamos. The TASS results will be put on one
panel of the poster paper, so TASS should get reasonable publicity.
These pulsation conferences occur every two years, and comprise most
of the active researchers in intrinsic variable stars. The group is
normally a few hundred professional astronomers, though this edition has
promise of being the largest ever since it is in honor of Art Cox, one
of the premier theoreticians.
This paper will present the preliminary results of photometric studies
of a subset of these variables. Future plans for investigating
these stars include additional photometry with the USNO 1.0m and 1.3m
telescopes and the cooperation of The Amateur Sky Survey (TASS) and
Astronomical Studies Group (GEA).
Tom has sent me two Zip disks full of scans through the SMSP-A and -B
fields. I've copied these disks over to my workstation and will be
busy for the next week or so looking at the images.
Who wants these disks next? I can send them on at any time, now that
I am finished with them.
It is time to write an abstract for the June 10 AAS meeting.
I propose that I be the presenting author and that Michael Richmond
be the introductory member. I suppose I could try to join before the
meeting, but I am already in IAPPP and ASP. I am not sure that
I like the style of the super large scientific meeting. I will
probably not go to such a meeting again.
I would propose the following author list:
Please, anyone who thinks they should be on the list or that others
should be on the list, let me know. It is intended to be an inclusive
rather than an exclusive list. Apologies if I have left anyone obvious
off the list.
Looking at the form, I propose to show the professionals with their
institutions, and the the amateurs with the institution "Amateur".
In listing the authors, I have tried to show everyone who did actual
work. So I have tried to include everyone who has taken data, written
extensive comments on data analysis, written tech notes, provided
support, etc..
I will, of course, contact each on the list and ask them for their
permission. I will also put the abstract up for comment before
submitting it.
I keep looking at data, it is going to be hard to normalize it well
enough to find anything. At least for me working with analysis
tools written on the spot in BASIC. I hope the rest of you have
better tools so we can have a couple of graphs to show in June.
I will write an abstract in a couple of days. Everything will be
put up for editing and discussion.
It looks like both Michael Richmond and my self will submit papers.
We have agreed that I will emphasize the history and orginazation
of tass and the Michael will present data.
Here is a try for an abstract. Note that we are limited to 300 words. I think
the below contains 299. So if you want to change something, you cannot increase
the number of words.
Please check spelling and construction of the text. Also make sure you all
send me your correct titles and affiliations. I like just being an "Amateur"
as to affiliation, but can understand why some of you might want to have your
organization listed.
TASS - The Amateur Sky Survey
As a non-astronomer watching Shoemaker/Levy crash into Jupiter through the
postings on sci.astro, it occurred to me that it might be fun to build a comet
finding machine. After wild speculations about how such a device might be
built - I considered a 26" x 40" fresnel lens and a string of pin diodes -
posts to sci.astro brought me down to earth. I quickly made contact with both
professionals and amateurs and found that there was interesting sceince to be
done by an all sky survey. After several prototype drift scan cameras were
built from FAX linear array CCDs, it was determined that the real problem was
software.
How does one get the software written for an all sky survey? Willie Sutton
could tell you. Go where the programmers are. Our strategy has been to build
a bunch of drift scan cameras and just give them away (without software) to
programmers found on the internet. This author reports more success by this
technique than when he had a business and hired and paid programmers at a cost
of a million or so a year.
To date, 22 drift scan cameras have been constructed. Most of these are
operated as triplets spaced 15 degrees in Right Ascension and with I, V, I
filters. The cameras use 135mm fl, f.2.8 camera lenses for a plate scale of
14 arc seconds per pixel. The cameras reach magnitude 13. There are 768
pixels in the drift scan direction. Four of the triplets and a single have
taken data. Operating procedure is usually to turn on and run through the
night. A triplet will then collect 200 Mb of data.
Production has started on 25 second generation cameras which use 2k x 2k
devices and a barn door mount.
I have been using the MathWorks "MatLab" program on my DELL Notebook
for the last few months and one of the things that it does very nicely is
make "scatter plots" (which are just X-Y plots) showing 2-D data with the
"third" dimension color-coded as required.
It seems with some simple scatter plots of different data sets it
ought to be quite easy to see how well data from different sites/technqiues
correlate. The RA and DEC positions could be plotted from the same fields
(not too crouded), and then the intensity plots could be color-coded (to
show magnitudes) to produce some nice plots. It seens like this would be an
easy way to normalize data from different sites / measurement techniques
without too much trouble.
There was some interest here about a Linux real-time TASS camera
driver. Norman was (is?) working on one.
I think I have found something that will make development of a
Linux driver simple. There is a real-time extension to Linux
for "hard real-time" scheduleing. The way it works is this:
It is a simple real-time scheduler that will always give the CPU
to the task that is (1) amoung those ready to run and (2) has
the highest asigned priority. Now the key - Linux itself runs
as a task but with the lowest priority.
The camera task would run as a peer to Linux and would not be
required to follow conventions and rules for normal Kernel
based drivers. Also the interaction and interface between
the camera driver and Linux kernel would be minimal or non existant.
The camera task would only be required to read data from the
interface when an interupt occures and write it to a FIFO buffer
with a provided function. A second task running as a normal user
program sees the other end of the FIFO buffer as a file that could
be opened, read and copied to disk.
Real time Linux appears to be supported and under active development
There is a mailing list and a small user community.
For more information see
http://luz.cs.nmt.edu/~rtlinux/
The paper "a draft of a paper on RT-Linux" is a good semi-technical
overview.
I intend to download the software and install it on my machine.
I should know very quickly how hard it will be to use.
in a subsequent message
Good news.
I now have a real-time Linux system up and running. I am using
it to write this. So it is not vaporware. Look at the e-mail header
timestamps. It took only a few hours and that included time to
eat dinner and play with my 5 year old. In that time I downloaded the
code, appied the patch to the RedHat 4.1 kernel (vers 2.0.27)
recompiled the kernel installed the software and got the test cases to
compile and run. No I'm not fast it is just that easy to use.
A real-time task is currently running. It is catching about 8200
interrupts
per second. While this is going on, I am writing this using netscape.
I
have a live PPP link to my ISP and am doing an un-related
compile and have an Ethernet link to a Windows95 machine down stairs.
The X11 Windows system is up and to top it off I've loaded IRAF, xephrem
and a word processor. All this and the real time task seem to get
along.
I've looked at the code. A minimal real-time task is quite simple,
about 100
lines. My estimate for the amount of work required to write a TASS
real-time
camera driver given that we now have real-time linux is about this:
Assuming
I could "pirate" code from tm3get11 about 4 or five evenins work to get
a
minimum functioning linux TASS camera driver.
If anyone wants to work with me on a Linux TASS driver let me know. I
can do
any of the code except that which accesses the TASS hardware.
I have to give credit to the guys at New Mexico Tech. who developed
RTlinux.
For those interested I've quoted an overview from the documentation
below
For more information see
http://luz.cs.nmt.edu/~rtlinux/
This variant of Linux allows to handle time-critical tasks. This is
accomplished mainly by insertion of Real-Time Kernel layer between Linux
kernel and hardware interrupts. This eliminates the main source of Linux
unsuitability for time-critical processing - big interrupt latency.
Under RT-kernel Linux kernel is just another real-time task. It has
the lowest priority, and can be preempted when needed.
This structure imposes some restrictions on RT-tasks. They can not
easily
use Linux drivers, networking, etc. They can, however, transfer data
to/from ordinary Linux processes through memory buffers.
Simple FIFOs are implemented for transferring data between real-time
processes and Linux processes.
A typical application consists of real-time tasks that deal with
hardware
directly, e.g. acquire data from a device, and Linux tasks performing
non-real-time processing, such as recording data on disk, sending it
over network, etc.
The shortest feasible period for a real-time task under the RT-Linux
scheduler
is currently about 150 us on Pentium 120. Interrupt driven tasks can
have smaller
periods.
I just located the last wire on the last pc board layout
for the Mark IV. Well, it is not the last wire since now
I have to check everything and fix my errors. ;^) It is
also not the last printed circuit board layout. There are
a couple of little boards needed for the controls and the
stuff in the camera.
There are four major boards. The one I just finished has
the CCD scanners and the front end analog stuff. One that
went out last week contains all the controls. The camera
PC board is back and looks OK. The memory board is nearly
done at the vendor and should be in next week.
Soon, we will be checking out the electronics. My time line
is for first light in June. This gives me 3 months of check
out to make it. Seems reasonable to me.
Norman wrote:
Here is a quote from the documentation:
Periodic tasks are those who make a system call to RT Linux
asking to executed at some specified periodic rate. Example
#2 is one of these. Interrupt driven tasks are tied to a
hardware interrupt like the programable timmer. #1 does this.
Both example programs are very small, about two screen fulls
of code. When compiled RT tasks are Linux kernel loadable
modules. So tasked are started with the "insmod" command from
the keyboard and stopped with the "rmmod" command. One you
"rmmod" all your tasks RT Linux becomes just Linux again, no
reboot is required.
I've been running a 125usec polling loop on this system for
about 16 hours now. With this running I can still transfer
data over the modem at full rate and access the disks and so
on. Stability looks good.
The trick to making this work is to do the *Absolute* minimum
work in the real-time task. Just poll the hardware and if
ready read the data an place it in a memory buffer, then
quite. All other fuctions would be done as normal user programs.
The first one to write would be one to read data out of the
memory buffer and copy it to disk.
The Mark IV is being designed so it is not at all time sensitive
for the interrupt. It will interrupt once a frame - probably about
once every 100 seconds. There is not much that has to be fielded
except to dump out the buffer before telling it to end the exposure
and read out again. This should leave lots of time for the display
task and to format the data for storage.
It is nice in theory to think that things only have to be written
once. Certainly I support writing clear cut processes in a modular
form. The real problem is that we probably don't understand what
the real problems are. So we will tend to have to re-write things
anyway. That is really the purpose of the Mark IIIs. To teach us
what the problems are when doing a survey project.
I have written a new Technical Note, number 28, comparing the star
lists generated by Gutzwiller, Gombert and Richmond for the same
images taken by Tom Droege. You can find the report at
There are tables and plots. The bottom line is, in my opinion,
that all three methods USUALLY yield very comparable magnitudes
when run on the same images. I'm slightly less happy with the
astrometry, but I think it will do for some purposes.
I request that both Glenn and Mike G. send me clarifications
or fixes to the mistakes I've put into the reports, in the
description of their techniques.
I have now run Mike Gutzwiller's latest version of Star on all
my available "A" data. Michael Richmond please add these files
to the home page.
The program was run at the default settings.
The camera pointing is not ideal. But I don't plan to change it
unless you all really beat me up. One can keep fussing and never
take any real data. There were continuous efforts to get a
better focus and to find the best VCO setting during the various
data runs. There were also changes in the camera pointing angle
about the middle of these runs. It will be obvious from the
data.
The following "A" runs are (or soon will be) up on
storm.fnal.gov. I have listed the run file, the background noise
level, the PSF size, and the number of stars found in each run.
The OK means that the match to the default catalog was
reached. One set of files that looks to be good did not succeed
in matching the catalog. This set of files has also been put up
on storm so Mike G. can try to figure out what is wrong. This
set is:
30t0524.817
30t0524.827
(I won't get these up until Tuesday afternoon as it takes too long
to send them from home)
*All "A" area on one file.
This is all my good "A" data to date. I can find files that are
full of clouds for those that want to study "bad" data.
I've read Richmond's new Technical Note on the comparisons between the
various datasets for Droege's images. Note that Tom has posted new data
for these nights, with frames that hopefully overlap in V and I so that
photometric transformations can be made.
While the astrometric agreements are in general very good, I have one
suggestion to make. Use the GSC positions as the fiducials, and do
differential comparisons of GSC vs. Richmond, GSC vs. Gutzwiller, etc.
so that you do not include systematic trends in the results. I may have
astrometry in one of these regions that is truely accurate (50mas or better)
that might be an even better fiducial dataset. The +-1pixel offset in
the x,y positions is due to whether you are using Fortran (1-relative
indexing) or C (0-relative indexing), and the 15 pixel offset is due to
the removal or inclusion of the beginning blind pixels.
The photometric comparisons match what I've seen from my own reductions.
I am in the process of finishing a suite of programs that take the raw
extraction lists and produce master mean star lists out the other end, for
use in creating master lists for the smsp
I've just discovered, and fixed, a bug in the star program. The bug
caused the dates shown in the star list to be calculated incorrectly for
certain images. Without going into the gory details, the time read from
the image file was interpreted as an octal number if the hours, minutes,
or seconds began with a 0. Unfortunately 08 and 09 are not good octal
numbers. Fortunately the extension that Norman used is time sensitive
so the files in error are easy to pick out.
Files with extensions in the range 833 - 916 will have time values in
error by between eight and ten hours. These will certainly have to be
re-run. (I know how you feel Tom, I did analysis on 10 nights worth of
data over the weekend and was ready to upload it.)
Another set of files will have time errors of between eight and ten
minutes. I don't know if these are worth rerunning or not. I probably
will myself. The extensions with this error amount are:
Herb Johnson
hjohnson@pluto.njcc.com
Mar 3, 1997
Tom Droege
droege@wwa.com
Mar 3, 1997
Chris Albertson
chrisa@wavenet.com
Mar 3, 1997
Chris Albertson
chrisa@wavenet.com
Mar 3, 1997
> If you use the day number and fraction, then you run out of characters
> without modifying the extension. For example (Henden v3),
> jjjjfffm.xcc
> where
> jjjj Julian Date -2450000
> fff JD fraction
> m camera
> x site
> cc file type
>
> or, if you are happy with 14.4 minute granularity for the date (Henden v4),
> jjjjffmx.ccc
Just a few comments.
Glenn Gombert
ggombert@infinet.com
Mar 4, 1997
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 4, 1997
> Does anyone have a good clean and deep image that overlaps
> one of more of the TASS fields that were posted. The Palomar
> survey is now published on a set of eight CD-ROMS. Would
> this work or has the compression algorithm killed the data?
I think I can answer your question about compression on the Digital Sky
Survey. The algorithm was designed by Rick White at Space Telescope
Science Institute. It is the hcompress algorithm using the haar wavelet.
Rick did a study that evaluated different compression ratio's. There is
loss, but in the region that we are working, I don't think the loss will
be noticable. The DSS plates are digitized to 25 microns at a precision
of 15 bits. (I am reading from the Guide Star Sampler), The Digital Sky
Survey Home Page says that the first generation was 1.7 arc seconds, and
the second generation plates were 1 arc seconds. The compression
algorithm distorts this somewhat, but if the data were reduced to the
accuracy that we see with TASS, the effect of compression should drop
out. The compression algorithm gives higher accuracy to low pass data
(reduced resolution of the image) (that assumes that hcompress works
like a conventional wavelet.)
Arne Henden
aah@nofs.navy.mil
Mar 4, 1997
8:49:00 +01:15
8:52:50 -00:10
8:50:00 -01:15
And each is 11 arcmin square. These sequences will have +-0.01mag errors
at V=17, and so should be good for both additional calibration stars over
and above the available Landolt standards, and for determining limiting
magnitude and precision at faint magnitudes. I will provide the data at
both the 12arcsec aperture size that Landolt used, as well as a huge 50arcsec
aperture size that the current TASS images seem to require.
Arne Henden
aah@nofs.navy.mil
Mar 4, 1997
> Does anyone have a good clean and deep image that overlaps
> one of more of the TASS fields that were posted.
Chris, do you mean one of Tom's fields? I have FASTT scans covering
most of these fields (except g1493946 and g1493955) that go to R=18 or so.
They are stored as 2048x2048x16bit FITS images (8MB each, 50x50arcmin).
The resolution (3 arcsec artificially blurred seeing) may be poorer than
the Digitized Sky Survey, but the relative photometric accuracy will be
better. What do you want to do with the 'clean and deep image'? If you
just want something pretty, then the Digitized Sky Survey will be better.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 4, 1997
*>> Herb
*> Mike Guztwiller
*>> What are you guys using for an absolute magnitude reference in your
*>> posted star lists?
*>
*> The 8.5 and 100000.0 were determined to give approximate matching of the
*> calculated magnitudes and the SAO catalog.
OK, thanks for the details.
*> At this point a more interesting question might be how the
*> relative magnitude
*> varies between the lists. If all the programs were consistent then the
*> magnitudes calculated between two lists should differ by a constant for all
*> stars.
Lacking at the moment a reliable and extensive absolute reference list, and
seeing as we need to present findings of position and magnitude for this
AAS paper(s), I first chose to look at self-consistency among the lists.
The SAO list gives only 40 candidates, but I'll try them next as a reference:
at least they'll force me to look over different parts of the image.
*> Since Michael R. is using the GSC and I'm currently using the SAO the
*> varience [in position] between our lists is expected. I plan to use the
*> GSC or possibly the USNO-SA1.0 instead of the SAO soon.
...such radical changes being the reason I don't spend more days on a more
exhaustive review. If I can automate it I might. Meanwhile, is the varience
*small enough* that it can all be attributed to differences in lists (and
different PSF, and dark and flat correction, etc. etc...)?
Arne Henden
aah@nofs.navy.mil
Mar 4, 1997
scale (arcsec/pix) = [206.265*p]/f
where p=pixel size in microns, f=focal length in mm
for the 135mm lens and the 9micron pixels, this gives a scale of 13.75 arcsec/mm
assuming 135.0mm focal length and 9.000micron pixels (neither of which is
probably true, and probably not constant between the lenses and/or V-I
focal points).
time (sec/pix) = 86164.09 (sec/sid day)
-----------
[[360*3600 (arcsec)]/13.75(arcsec/pix)]
or 0.9142 seconds/pixel. This changes to 0.9143 at 1 degree, and 0.9147
at 2 degrees off the equator.
John Gwinner
gwinner@northnet.org
Mar 4, 1997
> I'm still learning this terminal emulator at home, so sorry
> about the errors in the last mailing!
> Continuing, with corrections:
Pardon me for jumping in; my first post so there's a brief intro at the
end.
Michael Richmond
richmond@astro.princeton.edu
Mar 4, 1997
Michael Richmond
richmond@astro.princeton.edu
Mar 4, 1997
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 4, 1997
> There is an ADC on the Data Board and a DAC on the Control Board.
> It is not necessary to load the DAC unless you are trying to change the
> set point of the temperature controller, or the frequency of the
> drift scan.
>
> It sounds like Norman's routine will do just what you want. However,
> I notice that Norman's program does not set the temperature DAC until
> it completes the clear process and starts ramping up. What I do at
> home is to start Norman's program, and wait until it completes the
> clear. Then I abort the run and delet nnnnnn.tm3. Then after things
> have stabalized, I start the run again.
>
> It looks like you will have to find the place in Norman's code where
> he loads the temperature command value into the DAC. Then you can load
> it up. Or you can just do what I do and after a power on start and restart
> the program.
>
> Note the DAC will hold it's set point until the power is turned off. With
> the VCO not very good, it may pay to keep the computer on all the time.
You raised some interesting points. Let me go over the way we will
operate the system:
Any comments?
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 4, 1997
> > 7. I will either periodically ping the system (it should not respond
> > until windows 95 comes back on line). As an alternative, I will try to
> > execute a remote shell, that should not work until windows 95 comes up.
> > That will be my signal that the program has finished. The program has
> > failsafe measures that shut it off if the temperature goes bad. I may be
> > able to tie a serial I/O line into the system to send critical data back
> > to the home page system. Has anyone tried to run tm3get with I/O stored
> > on a NFS or SMB (samba) system?
>
> Could you place a program in the Win95 "start up" folder that would
> notify the UNIX system when Windows has come back up? Maybe even
> place an rsh command in the startup folder?
>
> Did you ever try to run tm3get under dosemu with Linux? Just wondering
> if it would work.
I will have to look into a rsh from Windows 95 to unix, that would be
easier and cleaner.
John Gwinner
gwinner@northnet.org
Mar 5, 1997
> You are right. Every major operating system being sold today can handle
> long filename. Problem is some people are still using older systems.
Well, we could also backdate the software for 286 computers too :-) My
bias: I'm an upgrade bigot, at least you'll know that from the start!
> Also many DOS and even windows programs, cannot accept long filenames
> even though the OS can.
True, 16 bit programs will not; 32 bit programs will, unless special effort
is made in the software to screw things up.
> If it where me making decisions I'd use longer more desciptive names on
> the archive and let people with 8.3 systems rename the file _after_ they
> are downloaded.
That would work .. changing file names is required for Web work anyway.
> Is this database Free or covered by the GNU or GPL style lincense?
> That is the problem with many DBMSes. If you require our users to
> buy a DBMS product you code is not so popular.
True. I guess it depends on what we're doing; I had in mind compiling the
routines in and distributing the compiled code, but if we are all compiling
at home, then we'll need something free of course.
Arne Henden
aah@nofs.navy.mil
Mar 5, 1997
>One of my questions was "Can you do this?" Assuming the lens
>resolves 80 cycles/mm at the center and we use 9um pixels.
9um pixels is 110 pixels/mm. 80 cycles/mm means 160 resolution elements/mm,
so roughly the resolution should be about the same as a pixel. Since
seeing is <14arcsec, then theoretically, the TASS images should have
fwhm of <1pixel. I don't know for sure what the quality of the Aubel
lenses should be. One way of checking would be to take a lens of known
quality (something that has been lab tested in Modern Photography or
something) and put it on one of the TASS cameras.
difflim (arcsec) = 0.252 * lambda(nm)/D(mm)
or 2.5arcsec for the V bandpass. So you are right: if the resolution is
100 l/mm, then the lens is not diffraction limited. That is ok, since
the pixels undersample the diffraction pattern anyway.
Arne Henden
aah@nofs.navy.mil
Mar 5, 1997
> (1) The convention of using the last three characters is so old and
> entrenched
> that it is not likely to go away. The dot-three part of 8.3 goes way
> back and pre-dates DOS or even CP/M. I'll bet 11 characters fits real
> nicely into the word size of some very old computer. I think we are
> stuck with "ccc".
I think we are stuck with 8.3 because of the ISO9660 standard for CDROMs
(I know, there are extensions, but lowest-common-denominator again) and
DOS x.x. I am not so certain that the dot-three needs to have any special
format as each program has developed their own extension. Witness WORD
with .doc and .rtf; AUTOCAD with .dxf, etc. There is nothing unique about
these three characters, just the 8.3 format itself.
> (2) file names only have to be unique within a directory. What will be
> mixed in one directory?
The problem arises when datasets are combined from different sites. George
touched on this. For example, it may make more sense to keep the merged
(but raw) nightly star lists separate from the photometrically calibrated
star lists, so the directory tree may look different at the reducer's
site than at the camera site.
> (3) I picked jjjfff as the unique id because it is easy to derive from
> the filename written by tm3getxx. You just drop one "j". I can write a
> simple script to do this but more complex mapping require a program to
> do the filemane changes from tm3get's convention.
Note that George Turner's mods and my mods and your suggestion are all
similar. George and I moved the julian date to the front of the filename
for sorting ease. We use a 4-character julian day number so that you don't
get rollover as quickly. Also, why use a script to do the mapping -- there
is nothing preventing the modification of tm3get to output the agreed-upon
file name.
Arne Henden
aah@nofs.navy.mil
Mar 5, 1997
Herb Johnson
hjohnson@pluto.njcc.com
Mar 5, 1997
*> 3. At this point I really want to monitor temperature to see if we are
*> in trouble. Is there any harm constantly resetting the temperature DAC,
*> or should I leave that alone and every minute, run a task that just
*> reads the temperature and voltage?
Aha! Some time ago I suggested to Tom et al that an overtemperature
circuit, a single chip, can detect excessive Peltier temperatures
and cut them off before they cook themselves. I've sent Nick the details
for further consideration. I'd do it myself, if I had a camera in hand.
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 5, 1997
Arne Henden
aah@nofs.navy.mil
Mar 5, 1997
Benoit Schillings
benoit@be.com
Mar 5, 1997
Arne Henden
aah@nofs.navy.mil
Mar 5, 1997
> All in all, I'm still a little *amazed* that there is not a better established
> list of reference stars. Having been around astronomy for awhile, I'm
> not *surprised*, however.
All-sky photometry at the 0.01mag level is truely difficult. That is
why there are only a handful of astronomers pursuing the task of setting
up standards. Space missions, where you get above the atmosphere, are
the obvious solution, and the Hipparcos/Tycho results are anxiously awaited
(even though they didn't choose true B & V passbands!).
Glenn Gombert
ggombert@infinet.com
Mar 5, 1997
File: SkyBackground(ADU) RMS Sky FWHM(Average)
G0483967.FTS 11167.6 55.4055 3.61
G0493669.FTS 11698.1 97.5382 3.88
G0483977.FTS 10926.8 49.9414 4.02
G0493678.FTS 11753.2 95.8544 3.81
G1493995.FTS 11439.9 52.8192 3.62
G1493669.FTS 13155.8 63.7128 2.66
G1493678.FTS 13154.2 62.4993 2.91
G1493995.FTS 11705.8 52.7644 3.44
G2483931.FTS 99972.7 45.9182 4.23
G2493623.FTS 12642.9 96.1175 5.49
G2493900.FTS 10704.7 49.7170 4.08
G2493909.FTS 10772.3 50.5891 4.10
Allen Gilchrist
gilchris@ipxpress.aws.waii.com
Mar 6, 1997
Arne Henden
aah@nofs.navy.mil
Mar 6, 1997
> Why is this? My 80 l/mm estimate was based on tests done with
> photographic film. The film's spectral sensitivity acts like Benoit's
> narrow band filter.
I thought photographic film was polychromatic and therefore does _not_
act like a narrow band filter. Lenses are usually achromatic and, like Chris
said, only perfectly corrected at two wavelengths, but these wavelengths
are chosen so that the lens is almost perfectly corrected throughout the
wavelength range of color film.
Allen wrote:
> I have seen the same thing using standard 35mm camera lenses on a Cookbook
> camera. I don't think the problem is limited to cheap lenses. One of my
> lenses is an Olympus lens that ought to be pretty good. The problem is
> that the designers never considered having to color correct these lenses
> out to 10000 Angstroms.
Allen, were you talking about using the lens unfiltered, or at least
without a red blocker? Then I can fully understand poor image quality.
Allen makes the very valid point that photographic lenses are not
color-corrected at 1000nm. In fact, the 'IR' marking on most of these
lenses refers to 650nm or so.
(1) the camera with best focus is #1 (V). For Tom, it was 2.8pixels
fwhm or so. Michael R. told me earlier that he has seen 1.8pix
fwhm on his camera1 without careful focussing. No one else has
given me any image quality data for their TASS cameras, so I
don't know the spread in this measurement.
(2) the cameras with worst focus are the I bandpass. Few camera lenses
expect the user to have film sensitive to 800nm light, and I doubt
they correct their lenses out here.
(3) Benoit showed that the Aubel lenses work ok at H-alpha (650nm),
essentially at the R bandpass.
Therefore:
(4) I think better focus can be achieved at V than you are currently
getting. You may want to try an experiment of using a red blocker
with the V filter to remove any hint of long-wavelength aberrations.
(5) I think for the 'I' bandpass you are either going to have to stop
the lens down to remove some of the aberrations, or else switch
to an R filter to get back into the 'corrected' range of the lens.
Stopping the lens down, using a red blocker and using an R filter should be
easy tests that don't have to be done by all sites. Paying careful attention
to focus should be done by all sites, preferably on cameras pointed at the
equator and then only for the middle columns.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 6, 1997
*> All-sky photometry at the 0.01mag level is truely difficult. That is
*> why there are only a handful of astronomers pursuing the task of setting
*> up standards...
*> The solution for TASS, as mentioned earlier, is to set up our own reference
*> frame, tied as closely as possible to the Landolt standards.
A "wholesale" approach might be to use a large set of stars that, in the
aggregate, have sufficient precision in magnitude. I suspect, however, that the
distribution of errors is not uniform, and of course it begs the question to
determine it. I've noticed that some star catalogs are many decades old:
would an average (mean? mode?) of readings across the decades, hopefully
at similar passbands, provide a better value for a given star; or at least
remove some long-term variables?
Michael Richmond
richmond@astro.princeton.edu
Mar 6, 1997
> I've noticed that some star catalogs are many decades old:
> would an average (mean? mode?) of readings across the decades, hopefully
> at similar passbands, provide a better value for a given star; or at least
> remove some long-term variables?
No, I don't think so. For the great majority of variable stars,
the amplitude of variation is small enough that systematic differences
between different stellar catalogs would swamp any true variability.
That is, a catalog made in the 1930s, based on photographic measurements,
and a catalog made in the 1960s, based on photoelectric photometry,
will have effective passbands which are far enough apart that individual
stars which DON'T vary, in truth, will still appear to have different
magnitudes, simply due to the passband mismatch.
Peter McCullough
pmcc@astro.uiuc.edu
Mar 6, 1997
> Hmmmm! What does it mean when the last page of the last
> issue of a magazine says you are an arrogant maverick?
> I like it! It comes very close to meeting a particular
> goal of mine. - Tom Droege
From that I was left with the impression that the article
was uncomplimentary (although T.D. felt it was a compliment).
In fact, the article was a compliment in the traditional
sense too. Below I attach the paragraph for those without
CCD Astro Magazine.
> ...The Amateur Sky Survey (TASS)...aims to keep 1,000 square
> degrees of sky under continuous electronic surveillance to
> magnitude 15. (You can find out more at
> http:/www.astro.princeton.edu/~richmond/tass/tass.html.) Comets
> and variables stars are obvious prey, but it's the promise of
> the unforeseen -- gamma-ray bursters,perhaps -- that excites
> my gray cells. I'm sure [Fritz] Zwicky would have loved the
> arrogance of this observing project.
So it wasn't T.D. that was said to be arrogant, but the TASS
project itself, and in a very complimentary, positive way.
John Gwinner
gwinner@northnet.org
Mar 6, 1997
Mike Schwartz
pfactors@ix.netcom.com
Mar 6, 1997
>Sometimes my sense of humor gets me into trouble. ;^)
>
>I did not really mean to mis-quote the article.
Tom Droege
droege@wwa.com
Mar 7, 1997
Tom Droege
droege@wwa.com
Mar 7, 1997
Arne Henden
aah@nofs.navy.mil
Mar 7, 1997
Allen Gilchrist
gilchris@ipxpress.aws.waii.com
Mar 7, 1997
Michael Gutzwiller
Michael_Gutzwiller@AICI.COM
Mar 7, 1997
Michael Gutzwiller
Michael_Gutzwiller@AICI.COM
Mar 7, 1997
> Tom and Mike G. so far have been gathering data on SMSP-B and posting that
> data on Michael R.'s computer. Both of these sites have been using Mike
> G.'s extraction software.
> I would like to encourage these sites to archive their raw scan data.
> There is still some discussion regarding how to properly flat-field these
> frames, and much discussion as to the proper way to extract the data and
> apply astrometric and photometric corrections. If the raw data still
> exists, then we can go back and try different techniques.
I have archived all my runs on tape going back to October 1996 and will
continue to do so. I too believe in keeping the raw data including dark
images for reanalysis with better techniques. This tendency probably goes
back to my high energy physics days where teasing 20 events out of 3 months
of data was considered a horn of plenty for my thesis.
> Also, regarding Mike G.'s package, I would request that he add a couple
> lines of code and output the fwhm in x and y for each detected
> object. I know that he applies some shape parameter cuts before
> accepting an object as real, but there will be many blended objects
> that pass such tests and adding shape information to the output file
> will help us in determining how to handle such objects.
I cringe whenever somebody asks for "a couple of lines of code" but in this
case it actually won't be more than about 10 lines since I already
calculate FWHM while creating the PSF. It will be in the next version of
"star" coming out next week.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 7, 1997
*> I have been trying to put the star lists together and make sense
*> of them. One thing is clear, however bad the astrometry is, it
*> is good enough to match stars. The photometry is the big problem.
This is my impression also, as I'm working on a second set of
star list comparisons. We can find stars, across all three sets of lists.
The two who are determining RA and dec (Richmond and Gutswiller) seem
to correlate well: I'm still looking at SAO and GSC catalogs to see
where those stars fit in. But magnitudes are another matter.
Glenn Gombert
ggombert@infinet.com
Mar 7, 1997
Glenn Gombert
ggombert@infinet.com
Mar 7, 1997
Benoit Schillings
benoit@be.com
Mar 7, 1997
Glenn Gombert
ggombert@infinet.com
Mar 7, 1997
> but there will be many blended objects that pass such
> tests and adding shape information to the output file will help us in
> determining how to handle such objects."
Arne has made a point I think that is critical to accurate data
reduction. I have seen several examples in the last couple weeks where a
faint background star is in the aperature of the star that is being
measured. I think that a way to detect this and make sure that it can be
identified for each star that is being measured is very important for
accurate results...
Arne Henden
aah@nofs.navy.mil
Mar 8, 1997
> After gathering ~160 megabytes of data last nigth (still unreduced)
> I have outfited one of the "I" band TASS cameras with an infrared blocking
> filter that I use with my ST-6. It should block any wavelength's longer than
> about 0.7 microns. I am interested in finding out how the PSF varies as the
> near-infrared is removed from the "W" TASS camera.
I hope that this is a misprint, or that Glenn did not include a couple
of key words! If you put an IR blocker along with an I filter, you will
get zero throughput, since the I filter peaks around 8500 A. The IR
blocker should accompany the V filter ONLY.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 8, 1997
*> The new version of "star" will adjust the magnitude scale of the list to
*> best match the [GSC] catalog.
*> While testing the software I found the amount of
*> shift in magnitude increased as the catalog I was using went to fainter
*> magnitudes in the GSC. By the time the catalog got to mag 12 the shift
*> stopped moving though and the shift was the same for a mag 13 catalog and
*> the mag 14 catalog. Looking at the data by hand I discovered that brighter
*> stars were consistently measured below their GSC values. To illustrate
*> this effect I have uploaded an Excel spreadsheet to:
I don't have Excel up at this time. I'd appreciate a simple plot of
magnitude vs. this shift you mention, maybe exported as a .GIF file or
whatever is reasonably universal. This shift begs a question: is it an
artifact of the GSC? My discussions with Richmond on the GSC suggest it
is not a good *photometric* reference: for instance, when a given area
of sky has "enough" reference stars, the list ends for that area - so the
GSC is not a random or "complete" sampling.
*> I believe what's happening is that bright stars which have TASS V or I
*> magnitudes lower than the GSC magnitudes (B?, P?) are preferentially
*> selected since they are bluer and do not saturate the A/D converter as
*> easily. ("star" ignores any star which has a saturated core.)
Interesting....of course this is a statistical argument and also dependent
on galactic location.
*> The end result is that the magnitudes published by the "star" program based
*> on its (100,000 ADU = mag 8.5) baseline are about 1 magnitude too low. I
*> now estimate the TASS 3 sigma limit to be near mag 14.5 as a result.
Odd. My reports, on the first 50 or so stars between you and Richmond,
did not show a 1-magnitude difference between the two of you. My sample was
small however (and with an I band image. I'm now looking at a V band image.)
Are you saying "one magnitude too low *relative to the GSC*"? Richmond tells
me the GSC magnitudes, as determined from the Paliomar Survey
E band plates, are closer to V band results than I band results: so using
the GSC magnitudes for the I band is even less appropriate.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 8, 1997
*> since a good deal of the star light is spread over n pixels, reducing
*> the aperature of the lens might actually improve star detection when
*> the camera is used in light poluted areas...
*> The core of the star image might stay about the same while the background
*> level would go down.
There would be fewer saturated star images with a reduced aperture, and
some dim stars would be lost, so the range of *detected* magnitudes would
shift to the brighter stars. This might be a plus in terms of finding
reference stars as there seem to be brighter stars available in
some lists. As it stands now, we need a 9th magnitude or better catalog!
Glenn Gombert
ggombert@infinet.com
Mar 8, 1997
Alain Maury
maury@ocar01.obs-azur.fr
Mar 8, 1997
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 8, 1997
> So Leif, put the paper where your mouth is :-)
>
> ( I hope this remark is as mild as I hope it is, cross my finger
> that this translation is not agressive ! ).
Tom Droege
droege@wwa.com
Mar 8, 1997
Glenn Gombert
ggombert@infinet.com
Mar 8, 1997
Bob Goff
goffaxe@azstarnet.com
Mar 8, 1997
Herb Johnson
hjohnson@pluto.njcc.com
Mar 9, 1997
---------------------
Comparison of star list magnitudes of Droege S31T0493.669 image
Herb Johnson March 9 1997
Image is V band. GSC catalog stars from E plates of Paliomar Sky
Survey plates. SAO is ??
SAO
---
SAO catalog for RA 117.4 to 117.999, dec 0.X to -2.4999
Richmond .AST stars for same area, by Richmond number and .AST magnitude
(Radius R of 3.5 pixels).
Gutzwiller stars for same area, by magnitude
Gombert stars for same area, found via Richmond .AST and .PHT lists only,
by Gombert number and magnitude
SAO RA dec mag Richmond Gutzwiller Gombert (via Richmond)
135145 117.4584 -2.0664 8.5 30 8.343 7.992 59 8.4326
135150 117.4934 -1.4697 9.0 46 9.608 9.232 90 9.6976
135154 117.5285 -1.6822 8.0
135157 117.5583 -1.4593 8.2 76 8.062 7.725 146 8.1444
135161 117.6426 -1.6099 8.5 107 8.075 7.698 226 8.1587
135171 117.7191 -2.4953 8.3 142 8.329 267 8.5695
116019 117.7222 0.0792 6.6
135175 117.8137 -0.4750 9.0 8.850
135176 117.8221 -0.4620 9.1 8.896
116031 117.8242 -0.1050 9.0 195 9.213 8.850 350 9.3497
135178 117.8348 -2.0626 8.6 199 8.256 7.906 366 8.3489
116040 117.8938 0.3830 8.7 222 8.215 7.878 400 8.3967
GSC
---
GSC stars RA 117.4 to 117.999, decl -0.0 to -2.4999
Richmond .AST stars for same area, by Richmond number and .AST magnitude
(Radius R of 3.5 pixels).
Gutzwiller stars for same area, by magnitude
Gombert stars for same area, found via Richmond .AST and .PHT lists only,
by Gombert number and magnitude
GSC RA dec mag Richmond Gutzwiller Gombert (via Richmond)
GSC0483201258 117.5306 -0.3429 10.74 62 10.304 9.947 109 10.3989
GSC0483601452 117.5929 -2.2431 10.77 90 10.571 10.171 162 10.7619
GSC0483200773 117.6202 -1.3077 11.62 100 11.681 11.316 175 11.7486
GSC0483600053 117.6446 -2.0127 11.23 108 11.245 10.930 203 11.2856
GSC0483200475 117.6488 -1.6444 9.37 110 9.426 9.066 227 9.0574
GSC0483200400 117.6892 -0.0030 11.69 125 10.982 10.624 234 11.1109
GSC0483201504 117.7124 -0.9779 10.95 140 10.638 10.302 263 10.7166
GSC0483200700 117.7204 -0.6528 10.76 145 9.995 9.645 269 10.1181
GSC0483200544 117.9566 -0.6752 11.94 256 11.519 11.213 448 11.6452
GSC0483201812 117.9848 -0.3181 11.98 11.223
GSC0483600017 117.9922 -2.0378 10.00 268 10.362 10.012 476 10.4492
Other stats:
-----------
Richmond's list: 1400 stars (to #268 identified on GSC; #222 id'ed on SAO)
Gutzwiller's list: 2182 stars (to #388 identified on GSC; #322 id'ed on SAO)
Gombert's list: 2207 stars (to #476 identified on GSC; #400 id'ed on SAO)
No overlap for the 12 SAO and 11 GSC stars in this range of .6 degree RA
and 2.5 degrees in dec (1.5 degrees square).
Methods
-------
All files sorted by RA.
Catlog file (SAO, GSC) edited for stars of RA 117.X, stars out of dec
range removed from list.
Richmond .AST file manually searched for matching RA and dec to about +/- .02.
Gutzwiller file manually searched for matching RA and dec to about +/- .02.
(In most cases, the most adjacent stars are off by much more than this.)
Matching stars in Richmond .AST list found in Richmond .PHT list by
Richmond number; pixel address converted to Gombert pixel coordinates;
(add 1 to Richmond row address; add 15 to Richmond column address)
corresponding Gombert star found.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 9, 1997
*> I'd then appreciate if Sky and Tel would show less amateurs
*> pushing glass, and guiding nice astrophotos, and more amateurs
*> doing astronomy instead. If Sky and Tel is not showing the
*> way, then who's role is it ?
*> When the average John Doe starts astronomy, he looks in sky and tel
*> to see what the others are doing, and usually he does the same,
*> he starts looking at NGC0001 and stops at NGC9999, then photographs
*> the same. Hasn't done much astronomy in the end, and Sky and Tel
*> is ( to my opinion ) partly responsible of this state of
*> affairs.
As my uncle used to say, "don't blame the cow for sour milk". My
impression is that Sky and Tel (and Astronomy magazine also) is
following the popular trend in (American) astronomy: a growing public
interest due to major celestial events and upgrades to the Hubble Space
Telescope. The events (comets and Jupiter impacts) have increased interest
in observing, and general interests in astronmical stuff. The Hubble
repairs, and subsequent pretty pictures, have "raised the level" of
expectations for pretty astronomical pictures. Related events include
lunar and martian space probes, and the growing use of CCD cameras to
produce even *more* pretty pictures. Also, growing Web use by the
public as supported by NASA and HST Web sites with, again, lotsa pretty
pictures.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 9, 1997
*> Herb's point is well taken that the lack of good "standards" make it
*> difficult to make good photometric calibrations of TASS images. I have added
*> a "Tech Note" to the Dayton TASS Camera Home Page, as well as asking Michael
I'll read this most carefully. Thanks!
*> It looks like a few percent photometric accuracy should be possible
*> on a routine basis with careful calibration. The other star magnitudes in
*> the GSC/SAO catalogs are just not accurate enought (as Arne has pointed out
*> several times). This makes it very difficult to tell how accurate
*> photomertic magnitudes as being calculated in TASS images.
I presume this assumes that the seeing is consistent and clear for the length
of the run. I don't think the problem will be "calibrating" the camera,
although that also needs to be established over long periods. The problem
we won't have obvious data on, or control of, will be the less-than-perfect
skies. As amateurs, we can make a signifigant contribution in my opinion
if we can work around (or through) this. The professionals of course
simply throw out data from bad skies at otherwise perfect sites: we
don't have that luxury.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 9, 1997
*> I have yet another request for folks writing the extraction programs.
*> You list the RA,DEC,x,y,mag, etc., but you should also include the UT or
*> JD for each object (since they are not identical). This is the only
*> way we can properly handle variable stars. The UT can be calculated by
*> using the beginning UT for the frame and adding the 0.91sec/row offset.
I don't want to argue, but if the UT can be easily calculated, then
why add it to the lists? It would have some error anyway, unless Tom
was very careful in recording the start of data collection; and unless
there is no odd drift or roundoff error in the timer used to shift the pixel
rows. [Incidently, how good IS that shift clock timer anyway, Tom? ;) ]
Shorter list files are better.
Chris Albertson
chrisa@wavenet.com
Mar 9, 1997
> *> I have yet another request for folks writing the extraction programs.
> *>You list the RA,DEC,x,y,mag, etc., but you should also include the UT or
> *>JD for each object (since they are not identical). This is the only
> *>way we can properly handle variable stars. The UT can be calculated by
> *>using the beginning UT for the frame and adding the 0.91sec/row offset.
>
> I don't want to argue, but if the UT can be easily calculated, then
> why add it to the lists? It would have some error anyway, unless Tom
> was very careful in recording the start of data collection; and unless
> there is no odd drift or roundoff error in the timer used to shift the pixel
> rows. [Incidently, how good IS that shift clock timer anyway, Tom? ;) ]
> Shorter list files are better.
Most Database Systems (even Microsoft Access) have the concept of a
"computed field" This is a kind of column that is derived as a function
of other data. Is is not stored on the disk but none the less may be
printed or even sorted or used as part of a selection criteria. It will
not be to long before these lists will be stored in databases rather
then
files when this happens you will have your UT column or maybe some
other column.
John Gwinner
gwinner@northnet.org
Mar 10, 1997
> *>I'd then appreciate if Sky and Tel would show less amateurs
> *>pushing glass,
>
> As my uncle used to say, "don't blame the cow for sour milk".
Interesting, as the ATM list generally feels that less attention is given
nowadays to making good optics, and instead the general lack of quality
optics in commercial scopes is ruining some amateur's experiences.
> As we report on our observations
> and how we do them, someone else will be inspired to do more careful
> work. That's how *I* got into all this. But we must all work harder to
> write up and report our results. Write a paper; give a talk; post
> results and methods on a Web page. Most astronomy clubs and Web sites
> are BEGGING for original work!
I generally don't see that much on what observations are needed to be done.
I've seen some web pages on lunar occultation's, and I have to admit I've
been more focused on actually making a scope to be able to get out from the
terminal. However, I think one good thing to do might be to start a
newsgroup with 'observations needed' or something to coordinate amateur
observations (web URL's cheerfully accepted). I know there's several
societies out there -- heck, that's why I joined this mailing list! Making
them more accessible might help. One of the things I like about TASS is
that the sky is 'registered' so that if I get a camera or build one or
whatever, I can feel assured that I'd get the guidance to point it in a
direction that will do a lot of good. If I'm just randomly timing
asteroids I'd feel that I was potentially duplicating an observation made
countless times before (of course, verification is important too).
Tom Droege
droege@wwa.com
Mar 10, 1997
Tom Droege
droege@wwa.com
Mar 10, 1997
Michael Richmond
richmond@astro.princeton.edu
Mar 10, 1997
- a wind storm blew the roof off the shed housing the camera
several weeks ago, but fortunately, no rain/snow fell in
while it was off. The camera was probably shifted by
the wind, though
- I spent half of one night trying to re-align the camera.
It would much better to have the triplet body mounted
on a pier ... mine just sits, loose, on the base of the
shed.
- the best VCO setting for this visit was very different
from the last one (a few months ago)
- I couldn't use Norman's program because my triplet has some
wiring problems (I think) which cause the CCD temperature
and water temperature values to jump between 3 or 4 different
values. Norman's program halts whenever the CCD is warmer
than the water, and the bogus values always caused this
to happen quickly.
- Tom's old BASIC program still works fine!
- During a recent power outage, the pump stopped moving
water in the coolant tubes, and much of it froze.
There was just a trickle of water coming out of the return
tube this weekend, but I judged it to be sufficient.
I _had_ placed about 8 gallons of antifreeze into 20 gallons
of water, but I guess it wasn't enough.
- I got one gloriously clear night, with 8 or so hours of
scanning.
- during this night, I placed an "aperture mask" over one of the
I-band lenses for several hours, then removed it. We can
see if the mask (which had a diameter about half that of
the lens) caused the PSF to improve
- the next morning, when I replaced the lens caps, one of the
I-band lenses felt loose. I jiggled it a little, and it
CAME OFF IN MY HAND! Yikes! Evidently, the cold temperatures
(about -10 or -15 Celsius) cause the metal strip Tom used
to fasten lens to triplet body to become brittle. I'll
have to find some way to re-attach the lens the next
time I observe....
Overall, a success -- I brought back about 224 Meg of data, and will
try to reduce it this week.
Chris Albertson
chrisa@wavenet.com
Mar 10, 1997
> I am preparing a couple of Zip disks with raw data. I have nearly
> 10 days of B data and I think 9 days of A data. I plan to ship these
> to Arne Hendon with instructions to ship them on to the next person
> on the list who asks for them. Anyone else want them? Otherwise, I
> will just have him send them on to Michael Richmond.
As it looks like Tom will be shipping data on ZIP disks I have
one question for Arne Hendon first and then others who would
want this data:
0) No camera
1) QIC-80 tape drive, 120MB native uncompressed
2) DAT 4mm DDS1 tape drive, 2GB native uncompressed
3) CD-ROM Writter (at the office)
If you all would post something like this I could sort it
out.
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 10, 1997
> As it looks like Tom will be shipping data on ZIP disks I have
> one question for Arne Hendon first and then others who would
> want this data:
>
> Do you have a way to copy this 100MB or so of data to some
> other media?
When I return to the lab in 3-4 weeks, I will be able to read the ZIP
disks, and copy them to CD-ROM (I have a CD-ROM writer). The lab pays
about $7.00 for a blank CD. I have not priced them at Comp USA recently.
We can make a limited number of copies of CD's (about 650Mbyte each).
I'm guessing that our cost will be about $8.00 total ($7.00 for the CD,
$1.00 for postage). I can get a better estimate after I return to work.
Arne Henden
aah@nofs.navy.mil
Mar 10, 1997
Herb Johnson
hjohnson@pluto.njcc.com
Mar 10, 1997
*>> *>I'd then appreciate if Sky and Tel would show less amateurs
*>> *>pushing glass,
*>
*>> As my uncle used to say, "don't blame the cow for sour milk".
*>
*> Interesting, as the ATM list generally feels that less attention is given
*> nowadays to making good optics, and instead the general lack of quality
*> optics in commercial scopes is ruining some amateur's experiences.
I think Alain was a bit excited when he made that particular remark. His
point was otherwise about "pretty pictures" over good science.
*>> As we report on our observations
*>> and how we do them, someone else will be inspired to do more careful
*>> work. That's how *I* got into all this. But we must all work harder to
*>> write up and report our results. Write a paper; give a talk; post
*>> results and methods on a Web page. Most astronomy clubs and Web sites
*>> are BEGGING for original work!
*>
*>I generally don't see that much on what observations are needed to be done.
It's not just observations, but the *methods* and *record keeping* that
are critical. My example made that point: an amateur who observed thousands
of asteroids (I recall a number like 6000) but who did follow good practices
(recording time, determining RA/dec, etc.). He was a great observer, but not
a good scientist.
*> However, I think one good thing to do might be to start a
*> newsgroup with 'observations needed' or something to coordinate amateur
*> observations (web URL's cheerfully accepted).
*> direction that will do a lot of good. If I'm just randomly timing
*> asteroids I'd feel that I was potentially duplicating an observation made
*> countless times before (of course, verification is important too).
Verification is the core of the scientific method. The whole IDEA of
modern science is that YOU can see the same thing I see, if you perform
the same experiment in the same way. THis is why science is not mysticism:
it is not *personal* experience, but collective and repeatable experience.
Arne Henden
aah@nofs.navy.mil
Mar 10, 1997
Arne Henden
aah@nofs.navy.mil
Mar 10, 1997
> Most Database Systems (even Microsoft Access) have the concept of a
>"computed field" This is a kind of column that is derived as a function
> of other data. Is is not stored on the disk but none the less may be
> printed or even sorted or used as part of a selection criteria. It will
> not be to long before these lists will be stored in databases rather
> then
> files when this happens you will have your UT column or maybe some
> other column.
Tom Droege
droege@wwa.com
Mar 10, 1997
Arne Henden
aah@nofs.navy.mil
Mar 10, 1997
Arne Henden
aah@nofs.navy.mil
Mar 10, 1997
Norman Molhant
molhant@ERE.UMontreal.CA
Mar 10, 1997
> - the best VCO setting for this visit was very different
> from the last one (a few months ago)
I have the same problem here from night to night. It doesn't vary much,
but the variations keep adding up.
> - I couldn't use Norman's program because my triplet has some
> wiring problems (I think) which cause the CCD temperature
> and water temperature values to jump between 3 or 4 different
> values. Norman's program halts whenever the CCD is warmer
> than the water, and the bogus values always caused this
> to happen quickly.
There are (documented) parameters in the configuration file (tass.rc) that
can be used to turn that module off: make the maximum acceptable difference
100 Celsius or more, lo! Doesn't stop any more.
> - Tom's old BASIC program still works fine!
Sure. Fun is: I inserted te offending module at Tom's request.
> - During a recent power outage, the pump stopped moving
> water in the coolant tubes, and much of it froze.
> There was just a trickle of water coming out of the return
> tube this weekend, but I judged it to be sufficient.
> I _had_ placed about 8 gallons of antifreeze into 20 gallons
> of water, but I guess it wasn't enough.
I am using half antifreeze (glycol), half water, which is a much more
appropriate mixture for Quebec's winters. It should also do for Vermont, no?
> - the next morning, when I replaced the lens caps, one of the
> I-band lenses felt loose. I jiggled it a little, and it
> CAME OFF IN MY HAND! Yikes! Evidently, the cold temperatures
> (about -10 or -15 Celsius) cause the metal strip Tom used
> to fasten lens to triplet body to become brittle. I'll
> have to find some way to re-attach the lens the next
> time I observe....
Is it the metal or the glue that broke?
> Overall, a success -- I brought back about 224 Meg of data, and will
> try to reduce it this week.
Great news! Wish I had such good news to report...
Glenn Gombert
ggombert@infinet.com
Mar 11, 1997
Tom Droege
droege@wwa.com
Mar 11, 1997
Norman Molhant
molhant@ERE.UMontreal.CA
Mar 11, 1997
> My experience is somewhat similar to Michael's in that I usually end
> up with a different VCO setting that I use on a given evening's data
> collection run. I often spend 45minutes to 1 hour "tweaking" the VCO to give
> the best results.
Indeed, the stability of the VCO is nothing to call home about. I use my
home-made periodmeter (based on a 1 Mhz Xtal oscillator) to adjust it whenever
I try to get a run. From cycle to successive cycle, the period is stable to
within about 1 msec, but from day to day the VCO setting to get the correct
period changes and there seems to be a more-or-less regularity to it: the
changes do slowly accumulate as if some component were aging (is that a
possibility, Tom?). On top of that slow but regular component of variation
there is also a much stronger but nearly random day-to-day fluctuation that
could be thermal in origin, or might reflect fluctuations in the power supply
voltage of the PC, or... I don't know. Where the PC sits on my desk, the
temperature varies between a minimum of 15 Celsius during the coolest clear
winter nights (10 Celsius when the blizzard blows, but I don't try to get
a TASS run in these conditions) and a maximum of 21 Celsius during hot summer
nights (that's because my lab is in a heated [but not cooled] basement), with
an average around 18 Celsius... Could such temperature differences explain
the seemingly random fluctuations in the VCO setting (typically around 1%,
sometimes up to 3%). Oh, yes, my PC has an open chassis (necessary to let
me put probes here and there on the Tass Control Card) and the power supply
fan does not blow over the Tass Control Card.
> I have found that if I do not do this that the data quality (FWHM,
> etc) is not nearly as good as it could be if I do not take the time to
> adjust the VCO.
Same thing here, albeit the star images are quite large here - because I have
no filter on the camera, I suppose. By the way "FWHM" represents the width
of the point spread function, allright, but what is it the initials of?
(yea, I know: sentences shouldn't end with of :-)
Tom Droege
droege@wwa.com
Mar 11, 1997
Norman Molhant
molhant@ERE.UMontreal.CA
Mar 11, 1997
> As I understand it, CCD overscan simply means that you read out a few
> extra pixels on each line??? If so, why don't we do it? Note we would
> not have to change the format, we could (just) modify the code to read
> out a few extra times, then put the data somewhere in the existing blank
> positions. I would not want to change the data format at this time - in
> the middle of a data run, but we might do it before the next serious
> push, which I would judge will be starting in July.
Sounds like a very good idea, if that's what CCD overscan really is (Arne?).
We still have an empty position in the current format (the last pixel is
always 0 for now), we could use it to store an average of X overscan readings
(what do you think, Arne? what kind of X would do here?).
Fairly easy to do.
I could do it for the DOS version of tm3get before the end of this week.
If I'm going to implement that, what else should I implement right away?
> OK, I agree that the VCO is a problem. How about it Norman, do you
> want to demonstrate your virtuosity?
Well, my brain seems to be functionning anew, so why not?
> Everything we need is there to automatically adjust the VCO. At least
> to the PC clock accuracy, which could in theory be corrected by the
> stars as they go by. So how about setting the VCO time interval instead
> of the VCO DAC setting. The software could check the time every 100
> lines, compute the real clock rate, and make a correction to the DAC
> setting. Closed loop servo enthusiasts will note there can be a stability
> problem. It will just take a small enough loop gain, or some serious
> analysis.
Ok, I'll think about it - I might be able to do something along these lines.
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 11, 1997
Herb Johnson
hjohnson@pluto.njcc.com
Mar 11, 1997
*>> Most Database Systems (even Microsoft Access) have the concept of a
*>>"computed field" This is a kind of column that is derived as a function
*>> of other data. Is is not stored on the disk but none the less may be
*>> printed or even sorted or used as part of a selection criteria. It will
*>> not be to long before these lists will be stored in databases rather
*>> then files when this happens you will have your UT column or maybe some
*>> other column.
*> This is a good point, and I'm glad Chris brought it up as many folks
*> may not have used _real_ database systems before. However, I don't feel
*> Also, I still feel that all TASS software needs to be public domain and
*> not a purchased commercial product. We do this bookkeeping with homegrown
*> programs at the observatory with little effort, and more customized than
*> the typical database program. That is not to say that an individual can't
*> munge the TASS dataset with whatever software they have available, but I
*> would like to have some basic tools available to all.
(sigh) sometimes I feel like an old man defending old habits. But it
seems to me that a number of people interested in TASS data, now and
in the future, will not necessarily have either Unix systems or experiences
with particular database systems. The raw data files are large but not
overwhelmingly so, and the near future will provide media and technology
to archive them at modest (but accumulative) cost. The PROCESSED data files
are even smaller, so a "raw" or "flat" format for them is not unreasonable.
I've argued against a data field that can be easily computed from scratch.
But if it was a choice between adding another 10% to the size of the
processed data vs. making it a database file, I'd choose the former.
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 11, 1997
> what else? I'll consider any suggestion received before thursday 18:00 EST.
We are setting up a poor man's remote system with the TM3GET11 software
under control of a unix system. At the moment there is no feedback while
data collection is going on. Ideally, I would like to receive a snap
shot of the screen every minute or so just so I can see how things are
going. At a minimum, the temperature, voltage, current and median
readings would be good. If I were to add the code in the TM3GET11
software to send data over a serial link, at what point in the data
collection process should I add the routine? I was told that if I wanted
to save the VGA screen, that I should tie into the VGA driver, and
respond during the vertical retrace period.
Mica Wickersham
rjw@crl.com
Mar 11, 1997
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 11, 1997
John Gwinner
gwinner@northnet.org
Mar 11, 1997
> ... I was told that if I wanted
> to save the VGA screen, that I should tie into the VGA driver, and
> respond during the vertical retrace period.
Whoo, that's a mess. The PC doesn't have a really good way to tie into
that retrace, and the retrace period is highly variable from PC to PC
anyway (depends on what the refresh rate of the screen is). Although you
can with some technologies (DirectX) get at the retrace (for frame
buffering) you're talking messy programming.
Michael Gutzwiller
Michael_Gutzwiller@AICI.COM
Mar 11, 1997
>I was processing some data we collected last night, through the star
>program to correct for dark current, and I noticed a line wrap around
>problem. One of my images had a aircraft come in from the right side.
>The line continues for a small part of the image. On the processed
>image, the line appears on the left and then wraps around to the
>right. Michael, if you would like, I can ftp the orignal and processed
>file to storm for you to look at.
>
>I displayed the image with my copy of deepsky, and with fitswin95, and I
>believe the wrap-around is in the processed data.
Arne Henden
aah@nofs.navy.mil
Mar 11, 1997
0-13 overscan
14-781 image
782-793 blind/dark
794-799 telemetry
That keeps the same format for all of the sections folks have used to date.
Arne Henden
aah@nofs.navy.mil
Mar 11, 1997
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 11, 1997
> If this is not the case then let me know, otherwise it will be corrected in
> the version of star going out in the next couple of days.
>
> Mike Gutzwiller
I downloaded the version that is on your home page, and the problem did
not recur. I think there are some wayward copies floating about the net
(I may have obtained my first copy from storm.fnal.gov.)
Mica Wickersham
rjw@crl.com
Mar 11, 1997
> Also, and I'll keep harping on this, all extractions need to have the
> objects time-stamped if you ever intend to do serious monitoring of variable
> stars. If the VCO drifts during a scan, the time/pixel varies as well.
> We time-stamp each row as it is stored (extra telemetry). Norman -- is
> the UT in the header referring to the first row of the image (even though
> these first n rows are from the previous fits image/scan), or the first
> new row?
Arne Henden
aah@nofs.navy.mil
Mar 11, 1997
>It seems to me that the UT of the time-stamp of the reduced data should
>coincide with the middle of the exposure. This would be the UT when the
>row that is being read out was in the center of the chip.
>Is this the best time to report as the time of the observation, or is
>there a professional "norm" that reports the end of the observation,
>when the row is being read?
With stare-mode observations, the usual practice is to use the starting
UT in the header, along with both the total exposure time and the total
'dark' time (i.e., time between initialization of the chip and the readout.
The dark time may differ from the exposure time if you are suspending and
resuming an exposure due to clouds. When extracting information from
this image, you usually report the observation time as UT + 0.5*darktime.
Tom Droege
droege@wwa.com
Mar 11, 1997
Norman Molhant
molhant@ERE.UMontreal.CA
Mar 12, 1997
> We are setting up a poor man's remote system with the TM3GET11 software
> under control of a unix system. At the moment there is no feedback while
> data collection is going on. Ideally, I would like to receive a snap
> shot of the screen every minute or so just so I can see how things are
> going. At a minimum, the temperature, voltage, current and median
> readings would be good. If I were to add the code in the TM3GET11
> software to send data over a serial link, at what point in the data
> collection process should I add the routine? I was told that if I wanted
> to save the VGA screen, that I should tie into the VGA driver, and
> respond during the vertical retrace period.
Don't do it, that's not the way to go.
Could your program cope with receiving something like 400 to 500 bytes per
second from the serial link?
If so, I could send each and every line (in a packetized format) through the
serial link and also accept keyboard input the same way, thus providing a
full remote control capability.
I'll provide the source code and executable for an appropriate serial device
driver (that code has been sitting in my archives for years, it was used to
provide remote control of a plastic bottle factory data acquisition system).
> How far away is the Linux version of TM3GET11?
I've too many problems with Linux 1.3, so I've decide to switch to the latest
RedHat distribution (that should be 2.0.2, I think) to continue development.
Right now, I'm waiting for the RedHat CDROMs, ordered last week.
By the way, the problems were in getting the device driver to run. I had
exactly no problem with intercepting the timer ticks and doing the real time
data acquisition. I hope RedHat is not as flaky as 1.3 proved to be... :-(
Glenn Gombert
ggombert@infinet.com
Mar 12, 1997
Arne Henden
aah@nofs.navy.mil
Mar 12, 1997
>Could your program cope with receiving something like 400 to 500 bytes per
>second from the serial link?
>If so, I could send each and every line (in a packetized format) through the
>serial link and also accept keyboard input the same way, thus providing a
>full remote control capability.
This is similar to the remote observing capability I provided for OSU
in communicating with their 72" telescope in Flagstaff from a remote
observing room in Columbus, OH. It is easy to do, as Norman suggested,
with the major problem being error recovery (what happens when things
crash). Of course, at 400/500 bytes/sec, you can't transmit the raw drift
scan data (which comes over at 2000 bytes/sec), but you can keep track of
how things are working.
Glenn Gombert
ggombert@infinet.com
Mar 12, 1997
Michael Gutzwiller
Michael_Gutzwiller@AICI.COM
Mar 13, 1997
> What say, friends?
> Should I program a servo loop adjusting the VCO to the PC clock (and you
> would specify the row shift period in time units, say tens of microseconds
> or something like that), or should I program a servo loop adjusting for
> minimum column-wise star width (and you would specify the initial value in
> DAC units like you do now - there would also be a way to freeze that servo
> in order to get dark frames etc)?
> I'd rather prefer the first way (using the PC clock), but I'd like your
> opinions.
I vote for using the PC clock. There's too many ways a program looking at
star sizes could be fooled. Especially since the program wouldn't know
whether the VCO was too fast or too slow and would need to "experiment" to
find the correct solution. I would also suggest using the shift time in
the tass.rc file as the value to use in the program. That way adjustments
could be made for individual PCs.
>> If the VCO drifts during a scan, the time/pixel varies as
> well. > We time-stamp each row as it is stored (extra
> telemetry).
>
> OK, we have the 800th pixel for that. It's 16 bits only, so what should I
> put in there?
Again change the VCO only between files and put the result in the FITS
header. Save pixel 800 for something else.
> Another think: as I'm going to make changes in tm3get11 (it will become
> tm3get12, by the way), why not change also what's wrong with the
> header? I've been told that the RA and DEC in decimal degrees cause
> problems, so my question is: what would work well here? What units and
> format should I use for RA, DEC and increments thereof? What else
> should be changed, added or removed from the FITS header of the raw
> files?
I would say leave units alone. The "star" program relies on the validity
of the RA in the header to determine where to start looking for matches to
the catalog. The last time I looked the RA was being calculated correctly
but the value of CDELT1 (delta dec) was of the wrong sign.
Arne Henden
aah@nofs.navy.mil
Mar 13, 1997
CHANGES
change TIME to UT or UTSTART. These are more standard.
change EXPOSURE to EXPTIME. This is more standard.
ADDITIONS
RA = 'hh:mm:ss.ss' / usually central RA for the image.
DEC = '+dd:mm:ss.s' / usually central Dec for the image
EQUINOX = 2000.0 / for the above coordinates
FILTER = 'V' / for this camera
SCALE = 13.7x / for this camera, arcsec/pix
GAIN = 2.5 / for this camera, electrons/adu
RDNOISE = 20.0 / for this camera, adu
IMAGETYP= 'OBJECT' / for this frame. choices are OBJECT, BIAS, DARK,
SKY FLAT, DOME FLAT.
BIASSEC = '[1:14,1:896]' / overscan region
DATASEC = '[15:782,1:896]' / image area for this frame
DARKSEC = '[783:794,1:896]' / dark pixels for this frame
Plus the appropriate white space to get things lined up. The RA,DEC,EQUINOX
fields are there for ready identification by a human; the WCS information is
what would be used by the computer. The filter is normally associated with
the camera, but adding it here makes it easier for a human reader (and I've
already noticed a couple of cases where filters have been changed on a given
camera for various tests). SCALE is just a constant for helping a non-TASS
person understand the camera. GAIN and RDNOISE are used in determining
photometric errors and for using psf fitting. We don't know what these values
are yet, but they can be determined for each camera. IMAGETYP was missing from
the TASS frames I was examining, and is used in automated reduction. The
three image sections (BIAS,DATA,DARK) are used for automated reduction and
presumably would remain constant.
Chris Albertson
chrisa@wavenet.com
Mar 13, 1997
> The change should only be made between files so the astrometrics are
> consistent for an individual file.
I thought the problem was that the VCO drifts even within one
file. Didn't Norman say he saw line to line diferences in the
scan period?
Arne Henden
aah@nofs.navy.mil
Mar 13, 1997
Tom Droege
droege@wwa.com
Mar 13, 1997
Alain Maury
maury@ocar01.obs-azur.fr
Mar 13, 1997
Joe Ronchetti
jronchetti@earthlink.net
Mar 13, 1997
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 13, 1997
Michael Richmond
richmond@astro.princeton.edu
Mar 13, 1997
Herb Johnson
hjohnson@pluto.njcc.com
Mar 13, 1997
*>> An obvious short-term solution would be to get a surplus pulse generator
*>> of the desired stability. As this is sub-audio, you might get one at
*>> a hamfest for tens of dollars. Meanwhile, you software guys, I can give you
*>> a cheap UNSTABLE version in a week from Radio Shack parts, suitable
*>> for software development, for the cost of a cheap lunch. Let me know.
Chris Alberson asked me: "How about this: build a "relative clock"":
*>Take a 10Mhz Xtal temperature compensated Ocilator and divide it by 10
*>then feed it to a 16 bit counter. The counter output goes to a 16 bit
*>port on the AT buss. Now all the software needs to do is copy the
*>content of the 16 bit port to the last column of each scan line.
(Later, Norman Molhant suggests a different divider rate and refines the
concept.)
Tom Droege
droege@wwa.com
Mar 13, 1997
Glenn Gombert
ggombert@infinet.com
Mar 13, 1997
Glenn Gombert
ggombert@infinet.com
Mar 13, 1997
John Gwinner
gwinner@northnet.org
Mar 13, 1997
Glenn Gombert
ggombert@infinet.com
Mar 14, 1997
Marty Pittinger
PittiMJ1@central.ssd.jhuapl.edu
Mar 14, 1997
E - S - W = East / South / West CCDs
X - X - X = -10 deg. = Average of East (-10) + South (-10) + West (-10)
O - X - X = 0.0 deg. = Average of East (-10) + South (-10) + West (+20)
O - O - X = +10 deg. = Average of East (-10) + South (+20) + West (+20)
O - O - O = +20 = No TEC or Average of East (+20) + South (+20) + West
(+20)
This would indicate one (1) TEC is a bit flaky.
Any help would be greatly appreciated.
Arne Henden
aah@nofs.navy.mil
Mar 14, 1997
> ...I don't know what USNO is using as a reference clock for their scans
Arne Henden
aah@nofs.navy.mil
Mar 14, 1997
Michael Richmond
richmond@astro.princeton.edu
Mar 14, 1997
It strikes me that _if_ there are one or more TASS members
_seriously_ interested in using Mark III or Mark IV cameras specifically
for finding NEOs, then they _might_ want to get together and
submit a single proposal.
http://www.transatlantech.com/TPS/TAhome.html
but you can write for more information to:
The Planetary Society
65 North Catalina Avenue
Pasadena, California
91106-2301
Phone: (818) 793-5100
Fax: (818) 793-5528
tps@mars.planetary.org
Please, please think CAREFULLY before you post replies to this
message! People who apply for these grants must be willing to
spend LOTS of time coming up with a coherent plan, and also find
a good reason to ask for money. It will be a lot of work.
Norman Molhant
molhant@ERE.UMontreal.CA
Mar 14, 1997
> Everything worked except the images from the West pointing
> camera, which seemed to have no real focus point. I get fuzzy
> rings or fuzzy dots (or like a snow flake). I suspect it's frost
> inside the CCD chamber, but the hose that connects
> the desiccate tube fell off and moisture may have entered.
>
> Tom, do you pull a vacuum on the drying system?
> Can moisture easily enter the CCD chamber?
> Have you ever experienced frost inside the chamber ?
I would suggest getting the camera back inside at room temperature, then
separating the objective from the camera body (4 screws to unscrew), letting
both of them warm up for a few hours, then re-installing the dessicant and
tubing, and pumping the camera body to a vacuum for a few hours, before letting
air in via the dessicant and re-assembling the camera.
May I suggest you try this in as dry a place as you can find?
Universities are full of dry places, so finding one should not be too
difficult.
> I also suspect a problem with a TECs. When starting up the TASS,
> CCD Temp remains at 0.65 until the clearing routine is completed,
> sometimes it lasts through the Ramping Up phase.
> This is unusual, normally the CCD temperature starts dropping
> immediately, eventually settling at -10 deg C.
> It appears one of the TECs doesn't kick in immediately and since
> measuring system does an average temperature you would get
> this reading, if the following is true.
Dear Tom, are there NTC's on each CCDs (connected in series or in paralle?),
or is only one of them equipped with an NTC resistor?
If more than one, then the equation to convert NTC readings to temperature
is wrong, either on serial #0, or in all others.
Arne Henden
aah@nofs.navy.mil
Mar 14, 1997
Herb Johnson
hjohnson@pluto.njcc.com
Mar 14, 1997
*> There are a couple of tests that I would like to see, but since I don't
*> have a TASS camera I am asking someone who does have one to make them.
*> ...
*> The flatfielding issue is unresolved. I would like to see someone take
*> some data during twilight, at about half-saturation in the camera, to remove
*> stars and to make local light sources less important.
*> I will be happy to reduce the data from any of these experiments.
I am also gearing up to work on this problem, and I too would like to
see some attempted flat field images. It's tough to produce these
in an even way. Twilight might do it, if you create a mask for the
camera so it does not saturate. Because of the scan mode of operation,
the mask must be dynamic. COnsider a rotaing circle with a "wedge" cut
out of it: the wedge reduces exposure by the ratio of its arc to the
circle. If it rotates "much" faster than the pixel row clock, there
will be no aliasing effects. This sounds odd as hell, but it's a simple
scheme to construct. Good Luck!
Glenn Gombert
ggombert@infinet.com
Mar 16, 1997
================================================================================
13-March-97
Field-B 31T0521.617 RA = 128.565
31T0521.630 RA = 135.284
31T0521.639 RA = 138.643
Field-A 31T0521.752 RA = 179.099
31T0521.761
31T0521.770 RA = 185.851
Field-A 30T0521.773 RA = 187.35
30T0521.742 RA = 190.72
Field-B 32T0521.649 RA = 127.00
32T0521.658 RA = 130.378
32T0521.667 RA = 133.737
Field-A 32T0521.817 RA = 187.74
32T0521.826 RA = 191.119
32T0521.808 RA = 184.36
11-March-1997
Field-B 31T0519.601 RA = 128.31
31T0519.606 RA = 122.76
31T0519.626 RA = 131.68
Field-A 31T0519.775 RA = 185.53
31T0519.784 RA = 188.92
Field-A 30T0519.737 RA = 187.07
30T0519.747 RA = 190.44
Field-B 32T0519.654 RA = 126.77
32T0519.663 RA = 130.14
Field-A 32T0519.822 RA = 187.42
32T0519.831 RA = 190.80
09-March-97
Field-B 31T0517.626 RA = 129.737
31T0517.635 RA = 133.092
Field-A 31T0517.785 RA = 187.102
31T0517.756 RA = 190.949
Field-A 30T0517.747 RA = 188.562
30T0517.756 RA = 191.949
Field-B 32T0517.663 RA = 128.17
32T0517.672 RA = 131.54
32T0517.682 RA = 134.917
Field-A 32T0517.822 RA = 185.647
32T0517.831 RA = 189.031
07-March-97
Field-A 31T0515.787 RA = 185.83
31T0515.796 RA = 189.21
Field-A 30T0515.749 RA = 187.333
30T0515.758 RA = 190.71
Field-B 32T0515.674 RA = 130.368
32T0515.684 RA = 133.735
Field-A 32T0515.824 RA = 184.35
32T0515.833 RA = 187.729
32T0515.843 RA = 191.109
15-Feburary-1997
Field-B 31T0496.681 RA = 129.181
31T0496.691 RA = 132.548
31T0496.700 RA = 135.91
Field-B 32T0496.728 RA = 131.018
32T0496.737 RA = 134.386
28-January-1997
Field-B 31T0478.727 RA = 127.742
31T0478.736 RA = 131.122
31T0478.745 RA = 134.502
Field-A 30T0478.848 RA = 186.72
30T0478.858 RA = 190.109
Field-B 30T0478.689 RA = 129.23
30T0478.699 RA = 132.61
Field-B 32T0478.773 RA = 129.642
32T0478.783 RA = 133.026
Michael Gutzwiller
Michael_Gutzwiller@AICI.COM
Mar 17, 1997
Let me know if there are any question or comments.
Arne Henden
aah@nofs.navy.mil
Mar 17, 1997
John Gwinner
gwinner@northnet.org
Mar 17, 1997
LARGE_INTEGER liCount, liEnd;
QueryPerformanceFrequency( & liCount );
printf("Performance Frequency: %I64d\n", liCount);
QueryPerformanceCounter( & liCount );
QueryPerformanceCounter( & liEnd );
printf("Performance Count for Queryx2: %I64d\n",
liEnd.QuadPart-liCount.QuadPart);
Chris Albertson
chrisa@wavenet.com
Mar 17, 1997
> I just wrote a small console program to time some things, so ironically I
> needed the timer routines myself
I hate to argue but how does the above tell you anything about accuracy,
timmer stability or short term jitter? It only tells you that the
numbers
run fast. The problem to be solved is to measure a time interval of
approximtely one second to an accuracy of about 0.1Msec or better and
get
repetable results day after day even when the room temperature changes.
Chris Albertson
chrisa@wavenet.com
Mar 17, 1997
> This is another report in a series of spot checks of Tom's sample images.
>
> **Method: for each file, I peeled off columns 790, 791, 792, 793. Columns
> were counted from 0, and values converted such that 32768 --> 0.
> Even if we debate the "darkness" of the dark pixels, these are undenyibly
> dark in this file.
>
> For each column, I computed the mean (sum/rows), median (max/2 -min/2),
> standard deviation of the mean. I ALSO computed a mean for groups of 50
> rows, and computed (mean of all - mean of 50). I reported this difference for
> the first 50 rows, the next 50 rows, etc. Any drift would show as a change
> in this difference. I printed all the differences in order, then eyeballed
> them for any pattern.
>
> **Results: All three files shows a consistant drift in the mean of 50 pixels
> (relative to the mean of all pixels in the column) from minus 1.5 standard
> deviations, through zero, to plus about .75 standard deviations. Again, this
> is a drift in the difference between the mean of 50 rows and the mean of
I looked at this same data a while back. I had not heard of "VCO drift"
back
then but was looking fro drift in the dark current. Sure enought I
found
about what you did. I posted a few graphs and a couple paragraphs of
test.
Peter McCullough
pmcc@astro.uiuc.edu
Mar 18, 1997
John Gwinner
gwinner@northnet.org
Mar 18, 1997
> I hate to argue but how does the above tell you anything about accuracy,
> timmer stability or short term jitter? It only tells you that the
> numbers run fast.
True, but up to this point the general consensus with the list was that
timer accuracy on the PC was only to 18ms. Obviously, it's better than
that with the free hardware that's supplied, but I agree that there are
other questions to be asked.
> BTW the equivalent system call in UNIX-like OSes (Linux is one example)
> returns time in u-sec as an integer but is only documented to be
> accurate to within 10Msec. Pretty poor.
> ..
> The same coulbetrue of PC hardware.
It's not; all PC hardware that's MPC level I certified (most any PC sold
nowadays) has to be able to handle MIDI streams, and they have to be
accurate to about a ms. (millisecond as opposed to Ms = Megasecond).
That's why the multimedia timers (as I previously posted) are pretty good
timing services if you're in a GUI state.
Arne Henden
aah@nofs.navy.mil
Mar 18, 1997
>True, but up to this point the general consensus with the list was that
>timer accuracy on the PC was only to 18ms. Obviously, it's better than
>that with the free hardware that's supplied, but I agree that there are
>other questions to be asked.
The PC timer tick has a resolution of 18ms, but the accuracy is much
better than that (i.e., the tick occurs every 18 ms +-0.001ms on average).
The various C/windows timer ticks use the raw input to the 8254, which is
1.8MHz if I remember correctly, which is why their resolution or granularity
is better. The basic accuracy is given by the 1.8MHz oscillator in both
cases.
Michael Gutzwiller
Michael_Gutzwiller@AICI.COM
Mar 18, 1997
> What I recommend is, for the next few months until the AAS and LANL meetings,
> the extraction programs provide at least the following aperture magnitudes:
> aperture diameters of 2,3,4,5 pixels, with annular sky at 6-9pixels. Sky
> should be determined by the daophot 'mean-median' formula (sort sky pixels,
> average the 10percent of pixels around the median to form a mean). The
> four aperture sizes will cover the best to worst images I've seen reported.
I agree that all the programs should do aperture photometry. TASS psf's
can be time dependent due to VCO drift and seem to be spatially dependent
too.
Chris Albertson
chrisa@wavenet.com
Mar 18, 1997
> I agree that all the programs should do aperture photometry. TASS psf's
> can be time dependent due to VCO drift and seem to be spatially dependent
> too.
I agree doing PSF fitting with a constant PSF would not work to well.
But
Why do that? PSF fitting appears like it should work very well for TASS
images and in fact may have advantages. As I see it, the trick is to
have
a very good model of the system PSF. TASS PSFs have these
characteristics
that the PSF model should capture: 1) They are not radialy symetric. 2)
they
are not constant over the field of view. As long as the PSF model
captures
this in model parameters, PSF fitting should work.
There are two advantages to this: 1) PSF fiting should handle "blends"
very
well. A visual examination of tass images shows that blends (over
lapping
star images) are very common. 2) There is a very good feedback
mechanism,
the residual frame, that allows us to see how well the process is
working.
> I'm not sure I agree on the set aperture sizes you have proposed. The
> "star" program uses an aperture based on the size of the psf for that
> image. The width and height of the aperture are set to about 2*fwhm in x
> and y of the psf. For Tom's images and mine this represents an aperture
> diameter of usually 5 to 7 pixels. Anything less than this and I would
> worry about jitter in selecting the peak position to contribute
> significantly to the error in measuring the ADU sum within the aperture.
>
> As for generating N magnitude measurements the obvious question becomes,
> which one should be used when comparing one image to another?
Just an idea. I think you should compare each new object list with a
composite made from all previous lists. In other words it is a "merge"
operation. In other words a star's location is a wieghted average of
all the locations it has been.
Chris Albertson
chrisa@wavenet.com
Mar 18, 1997
IDEA: Do you all know how Internet USNET news is transfered?
articles eventualy get to every newsserver (almost) but there
is no central braodcast site. All sites are peers. They
use a protocol called "I have, I want" and articles are exchanged
between two servers. Agreemets are made bilateraly between
server operators. Thousands of bilateral agreements make up
a "network". It works because there are rules.
Glenn Gombert
ggombert@infinet.com
Mar 18, 1997
Tom Droege
droege@wwa.com
Mar 19, 1997
Herb Johnson
hjohnson@pluto.njcc.com
Mar 18, 1997
*> Now, I am not going to judge that one extraction program is better than
*> another. What I am saying is that we need to have ALL extraction programs
*> output a common magnitude for comparison, perhaps in addition to any
*> magnitude scheme that the program usually provides.
Arne Henden
aah@nofs.navy.mil
Mar 19, 1997
Arne Henden
aah@nofs.navy.mil
Mar 19, 1997
> I'm not sure I agree on the set aperture sizes you have proposed. The
> "star" program uses an aperture based on the size of the psf for that
> image. The width and height of the aperture are set to about 2*fwhm in x
> and y of the psf. For Tom's images and mine this represents an aperture
> diameter of usually 5 to 7 pixels. Anything less than this and I would
> worry about jitter in selecting the peak position to contribute
> significantly to the error in measuring the ADU sum within the aperture.
>
> As for generating N magnitude measurements the obvious question becomes,
> which one should be used when comparing one image to another?
My CCD photometry indicates that the optimum sized aperture is usually
5*fwhm. See Steve Howell's article on photometry in Astronomical CCD
Observing and Reduction Techniques, ASP Conference Series #23, or his
article on growth curves in CCDs in Astronomy, ASP Conference Series #8 for
further information on selecting the optimum aperture size.
Arne Henden
aah@nofs.navy.mil
Mar 19, 1997
Herb Johnson
hjohnson@pluto.njcc.com
Mar 19, 1997
*>> As for generating N magnitude measurements the obvious question becomes,
*>> which one should be used when comparing one image to another?
*>
*> Just an idea. I think you should compare each new object list with a
*> composite made from all previous lists. In other words it is a "merge"
*> operation. In other words a star's location is a wieghted average of
*> all the locations it has been.
I don't think I'd go for "average", but I think you've begged the question.
My findings are that the *locations* are pretty consistent across different
programs. It's the *magnitudes* that are not. Hard to imagine that any
refinements of current programs will degrade the astrometrics of position.
But magnitudes are still an open problem, and as I look at prior work in
professional photometry it looks harder, not easier. And an average of few
samples, with odd correlations, is not so good I think: I would hope new
magnitude estimates are BETTER than old.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 19, 1997
Herb Johnson
hjohnson@pluto.njcc.com
Mar 19, 1997
*> Now I see there are basicaly two groups of people here on this list.Those
*> with cameras and an immeadiate need to reduce data and those with access
*> to only a sampling of data.
*>
*> I will propose to two phased approach to TASS data reduction. 1) What
*> has already happened put of necessity, a production mode. 2) A experimental
*> mode. I expect people who have cameras and data to be interested in #1
*> while others would somehow form a coordinated effort at #2. Results of
*> #2 could be folded back into the production effort when it warents.
*>
*> Lately #1 seems to be taking shape. I suspect there are others
*> interested in #2 but that there is zero organization of that effort.
Something is grating me about this description, on several grounds. I'll
express my reactions and then cut to the chase. Sorry it takes a few
paragraphs, you can skip to "BOTTOM LINE" if you are impatient. I'd sooner
discuss work on data for the AAS papers, which I think should be our
immediate goal. - Herb
Chris Albertson
chrisa@wavenet.com
Mar 19, 1997
> Chris argued for removable IDE drives, and against tapes, CD-ROMs and
> ZIP drives. Tapes are too much trouble, I agree there. Otherwise I
> disagree with his assessments. To save time, let's just tote the costs:
No, no, no, I was not arguing for IDE drives as any kind of standard I
was
just pointing out an option that was overlooked. It may work in some
cases.
For example if I happen to have an old 850MB drive laying around I could
buy
two drawers for it (at $30.00 each) and have a quick and cheap 850MB
removable
device.
> One CD-ROM, under $10. CD Rom drives are "free". Writers require some
> scrambling to find, they will be cheaper soon enough.
Yes I expect they will drop to the $300 level and stay about there.
Cheap
enough. _But_ have you ever tried to make a CD ROM? This is not
something
you want to do 5 or 6 times in one day. The practical aspects of CD
burning
are such that you just will not use CD-R in a production mode.
> Five ZIP disks, 500 MEgabytes, $75.
> Divide cost of Zip drive by number of uses,
> or borrow it, or ask the requestor to ship HIS/HER drive to you.
Tom just e-mailed me. Says he has already had enough of using ZIP to
transport
data even between two computers in the same house. Says it takes stacks
of
disks and the process is dead slow. Looks like his use of ZIP is
pushing the
media past it's usfull limit (Tom, sorry for the bad paraphrase) I
think
ZIP has it's place but not for storing multi-gig data sets.
> Cheapest IDE drive, $120-$150 new. Add docking station, removable drawers...
Removable setup = $30.00 for each computer. Must buy drawers all at
once
from the same vendor as they are not standarized. Add up the numbers
and see
if it works for you, may or may not. Very cheep if you have a "free"
drive.
> Tapes are slow, not standardized, and are incompatible sometimes anyway.
No, **cheap tape drives** are slow, not standardized, and are
incompatible.
If you have $700+ to spend on a tape frive these problems go away. That
is
a big "if" and I assumed no one would buy one of these drives. But
several
people already have them. New DAT drives are as fast as SCSI disks and
_are_
standardized. exchange is not a problem. Holds 8GB on a small cheap
cartdridge
but at $1K per drive. Also you can random access to any file in one
minute.
This is realy the way to go but the cost is a killer.
> My ranking: CD-ROMs and ZIP drives, IDE removables a distant third with tapes.
> Some one or some group can act as archivist in two ways: to ARCHIVE the data
> and to DISTRIBUTE the data. Archivists should have access to CD-ROM writers
> and ZIP drives (requestors can always SEND THEIR DRIVES), support UNIX and/or
> MS-DOS file systems, and/or provide an Internet FTP site: how they take it
> in from the camera owners is between them and the owners, as Chris suggests.
I could do the archive, but I don't see how I (or anyone else) could
handle
data distribution themselves. I'd spend half of every day burning CDs,
copying
tapes and running to the post office. Nice as it sounds I just don't
think
you will find one volunteer willing to be the central distribution
point.
Chris Albertson
chrisa@wavenet.com
Mar 19, 1997
> Chris A. wrote regarding psf fitting. I agree with most of his points,
> and you will find that many groups working with crowded field photometry
> (such as MACHO and SDSS) are using psf fitting for their photometry. This
> is most likely the best approach for TASS as well, since the big images
> mean even sparse regions will act 'crowded'.
I think we agree: 1) PSF should be a long term goal but 2) It is hard to
do so 3) we stay with aperture photometry for now.
> However, I've done a lot of psf photometry, and there are several major
> problems. (1) you eventually need to place your photometry on some
> standard system, and that requires aperture photometry for best results
> since that is how Landolt acquired his photometry. This is very obvious
> in fields like Ru149 and Ru152, where he is including several fainter
> stars in the same aperture as his standards, so it is the ensemble that
> is the 'standard'. (2) Automatic psf photometry is complex. Chris mentioned
> several off-line and inspection steps to ensure that the subtraction was
> done properly, and for TASS these steps have to be automatic.
What I envision is a fully automated process. But when you run any
automatic
process you want a means of quanitative quality control. You then
periodicaly
improve the automation and use your quality controls to see if the
improvement
was in fact an improvement.
> I think that
> several man-months of effort are going to be necessary to get programs to
> do automated psf fitting and deblending, and so strongly suggest that the
> first approach is to do the simple task of aperture photometry and then
> as a second step work on the psf fitting.
Yes. This is my point too. I think there are enought pepole here to do
both
at once. I do not want to suggest giving up the current effort.
Some can reduce data using what works now and others can research
new methods. I think that every fractional percent in improvement in
data
reduction technique will translate into the discovery of hunders of
otherwise
un-noticed variables.
> (3) I am not convinced that
> the TASS cameras are supplying their best images yet, and as the cameras
> converge on the optimum image size, the psf delivered by these cameras
> will change shape. Therefore, selecting an optimum technique for calculating
> the psf may change as well.
I think one thing that needs to be developed is a way to get the PSF
from
the data automatically. Perhaps the software first searches for a few
isolated stars....?
> I would rather see effort put into getting the
> cleanest images first, then step back and see whether something simple like
> a two-dimensional Gaussian will work adequately or whether you need an
> empirical correction such as that calculated by DAOPHOT.
I think you can have both. Image improvement can only be done by a few
people who have access to the equipment. There are others with nothing
to do.
> For those not read up on PSF fitting here is a overview. I have left
> out
> some detail:
>
> 0) off line, build a good model of the system PSF. This could be
> based
> on closed form equations or tabular data or both.
> 1) Extract a list of of stars by any method one likes. The list will
> contain lines of (x, y)
> 2) For every (x,y) extracted in #1
> 2.1) attempt a least squares fit of the PSF model to
> the data at point x,y.
> 2.2) Record the peak of fitted function as (x', y'). This is the
> instrumental Mag. and fine-fitted possition.
The "volume" is probably a much better estimate of the Mag, in
particular
if the shape of the PSF is changing with the position on the field.
> 2.2) Subtract the PSF model from the data (removes the star from
> the image.)
From my experience, and that of most if not everyone doing PSF fitting
it is better to substract only a fraction of the fitted PSF ((0.1 to 0.9
depending on S/N) for every star in the list and then iterate on the
residuals. This is the so called "CLEAN" method.
> So if I had to reduce a big pile of data today. I'd use aperture
> photometry
> as it is quick and simple but in the long run I suspect the PSF method
> will
> give better result.
You could use aperture photometry as a bootstrap for PSF fitting, as for
PSF you need initial values, and the better they are the faster the
convergeance.
George Turner
turner@bigbang.astro.indiana.edu
Mar 20, 1997
Herb Johnson
hjohnson@pluto.njcc.com
Mar 20, 1997
Here's my findings:
------------------
Here's some summary data:
------------------------
row 790 791 792 793
mean 6737.5 6647.88 6622.14 6627.31
median 6656.0 6665.0 6640.0 6652.0
st. dev 21.67 21.47 20.72 20.84
1st diff -35.82 -35.28 -33.82 -35.69
last diff +16.34 +15.00 +14.66 +15.91
avr diff +2.2 +2.38 +2.4 +2.4
The "avr diff" is the average of all the differences. The "diff" values
reported are actually the largest of the first few diffs, and the largest
of the last few diffs. "Few" is four or less. Simple arithmetic yields
the equivalent diffs in standard deviations.
site gombert gutzwiller
mean 8094.85 9567.12
median 8092 9569
st. dev 11.90 26.73
max neg diff -2.79 -4.08
max pos diff 3.99 3.84
avr diff .01 -0.04
These differences are only a few ADU's, well below the standard deviation.
The edited row, from cols 790 to 799, and its successor row are:
10216 9464 8952 8626 37007 40301 33066 54255 11198 0
8096 8064 8078 8046 37011 40305 33064 54255 11199 0
Note that columns 790 through 793 of the first row are all impacted, and
that the values in the second row are more consistent with the mean
value and each other.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 20, 1997
*> From my experience, and that of most if not everyone doing PSF fitting
*> it is better to substract only a fraction of the fitted PSF ((0.1 to 0.9
*> depending on S/N) for every star in the list and then iterate on the
*> residuals. This is the so called "CLEAN" method.
As a matter of fact, my colleague Dr. Robert Dixon at Ohio State (and
his advisor at the time, John Kraus) used this method before it was
"discovered". They were reducing radio astronomy data from their
drift scan Ohio Survey instrument. In effect, they had a "one-pixel"
array. Richmond has posted my references to their work on the TASSS web
page, and I have the original papers on hand, which describe the method
in detail. I'm ready now to look at this and post something on it.
(Dr. Dixon has not answered my email request to post the original
articles.)
Herb Johnson
hjohnson@pluto.njcc.com
Mar 20, 1997
*> Looks like I've started an argument, I was trying to be neutral and
*> diplomatic...
I would like to give Chris credit for trying to work something out
about archiving and distributing data. It's a general problem for all
kinds of computing and research work. I'm surprised that CD-ROM's
are *still* difficult to make: I'll say no more as Chris reminds me
I have not made one. The good point of his discussions is that we've
all had a glimpse into the merits and problems of various media. The
consensus seems to be: private arrangements at the camera sites to
archive data; no consensus as to how to distribute the data; and
hopes that "tomorrow" the problem will be solved by (choose a technology).
I agree with Chris there's been enough on this subject. As for distribution:
*> I could do the archive, but I don't see how I (or anyone else) could
*> handle data distribution themselves.
If there is a demand, and people will pay, someone will do this. Big if's.
I hope we don't discard raw data in the long term, but it's hard to justify
the effort to archive it.
Glenn Gombert
ggombert@infinet.com
Mar 20, 1997
Chris Albertson
chrisa@wavenet.com
Mar 20, 1997
Glenn Gombert
ggombert@infinet.com
Mar 21, 1997
Michael Gutzwiller
deepsky@fuse.net
Mar 24, 1997
> You have made a couple of good points, I find that I can only
> "match" about 20% of the stars in any one given image using the SAO file
> of Mike G. And Michaels star matching program. If you have to extract a
> separate file (a "box" of stars) for each file to process than it gets
> very cumbserom to process a lot of images this way.
Actually this is how the star program works. While the whole catalog is
read in at the start, Michael Richmond's star matching routines are fed
subsets of the catalog of the same size as the image for each attempt at
a match.
> It apperas that Michael has gotten around this problem by
> pre-computing some of the matching information for each area of declination
> by extracting each region and processing it ahead of time.This probably
> works well for the region around 0 degreess DEC but what happens when the
> Mark IV and beyond when you must "match" stars over the entire sky from
> many different composite images? That's probably a "whole nother ball
> game"......
Michael's star matching routines assume that the coordinates are
rectilinear, not a bad assumption for RA and Dec near the equator. Away
from the equator though the catalog subset would need to be projected
onto a plane and then matched.
Tom Droege
droege@wwa.com
Mar 24, 1997
Michael Gutzwiller
deepsky@fuse.net
Mar 24, 1997
> I have been working through my lists to reprocess them with the latest
> version of star. Is this appropriate at this time, Mike? The idea is
> to get a big enough number of measurements for each star to start looking
> for both a "fixed" set of candidates and a "variable" set of candidates.
I think so. If we're going to have enough data to analyze for June we
need to stop cutting bait and do some fishing. Enhancements to star and
other programs will continue but we need to have some data to analyze.
> Mike, do you plan to update your star lists on the web page?
I will update those lists and add some more. I have several other
nights with A and B fields to add, some going back as far as October
last year.
Glenn Gombert
ggombert@infinet.com
Mar 24, 1997
Arne Henden
aah@nofs.navy.mil
Mar 25, 1997
> .... If we're going to have enough data to analyze for June we
> need to stop cutting bait and do some fishing. Enhancements to star and
> other programs will continue but we need to have some data to analyze.
Arne Henden
aah@nofs.navy.mil
Mar 25, 1997
Title: Variable Stars in the SDSS Calibration Fields
Authors: Arne A. Henden (USRA/USNO), Ronald C. Stone (USNO)
ABSTRACT
The USNO Flagstaff Astrometric Scanning Transit Telescope (FASTT) has
been used to scan 384 total square degrees in 16 regions along the
Celestial Equator. The primary emphasis has been in providing accurate
astrometry of all stars from R=9-17 within these regions. As a
byproduct of the project, 2000 new variable stars have been discovered.
With very conservative cuts, approximately 0.4 percent of the scanned
stars are shown to be variable. Since this is a magnitude-selected
sample that spans a wide range of galactic longitude and latitude, it
is useful in statistical studies of stellar formation.
Arne Henden
aah@nofs.navy.mil
Mar 26, 1997
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 26, 1997
> Tom has sent me two Zip disks full of scans through the SMSP-A and -B
> fields. I've copied these disks over to my workstation and will be
> busy for the next week or so looking at the images.
> Who wants these disks next? I can send them on at any time, now that
> I am finished with them.
Send them to me, and I can setup a limited number of CD-ROM's. I will be
back in the lab on Monday and I can burn the CD-ROM during the week.
Tom Droege
droege@wwa.com
Mar 27, 1997
Professionals:
Michael Richmond
Bohdan Paczynski
Arne Hendon
Paul Rybski
Amateurs:
Mike Gutzwiller
Glenn Gombert
Chris Albertson
Norman Molhant
Herb Johnson
Nick Beser
Ron Wickersham
Jure Skvarc
Tom Droege
droege@wwa.com
Mar 27, 1997
Glenn Gombert
ggombert@infinet.com
Mar 27, 1997
Chris Albertson
chrisa@wavenet.com
Mar 29, 1997
Tom Droege
droege@wwa.com
Mar 29, 1997
Chris Albertson
chrisa@wavenet.com
Mar 29, 1997
> When I investigated RTlinux about a year ago, the timer interrupt could not
> be used to drive a real-time task, as it could not be programmed to give fast
> timer ticks without completely disturbing the system.
> If that has been changed, i.e.: if it is now possible to get time-ticks as
> short as 100 microseconds or so, then RTlinux is worth investigating.
I think it will work now. RT Linux is under active development and
the last release was in 1997, It comes with some example real-time
programs that show that it does almost the 100usec you want. It
may do better but these work on my machine.
The shortest feasible period for a real-time task under
the RT-Linux scheduler is currently about 150 us on
Pentium 120. Interrupt driven tasks can have smaller
periods.
Tom Droege
droege@wwa.com
Mar 29, 1997
Tom Droege
droege@wwa.com
Mar 30, 1997
Michael Richmond
richmond@astro.princeton.edu
Mar 30, 1997
Tom Droege
droege@wwa.com
Mar 30, 1997
Run Background PSF Size Stars Found Match Found
S30t0483.931 43.8 7x7 480 OK
S30t0483.940 42.7 7x7 396 OK
S30t0493.900 49.9 7x7 382 OK
S30t0493.909 44.8 7x7 408 OK
S30t0511.851 59.4 9x7 195 OK
S30t0511.861 59.5 11x7 186 OK
S30t0515.838 59.4 11x7 226 OK
S30t0515.848 57.7 11x7 185 OK
S30t0517.831 77.1 9x7 90 OK
S30t0517.840 71.3 9x7 100 OK
S30t0518.831 41.6 9x9 368 OK
S30t0518.840 39.2 9x9 346 OK
S30t0519.829 40.1 7x9 438 OK
S30t0519.839 38.1 7x9 379 OK
S31t0483.884 41.5 5x5 544 OK
S31t0483.894 41.4 5x7 443 OK
S31t0493.863 51 5x7 441 OK
S31t0493.872 48.8 5x7 453 OK
S31t0515.802 47 5x9 334 OK
S31t0515.811 40.9 5x9 432 OK
S31t0518.795 39.6 5x5 426 OK
S31t0518.804 39.8 5x5 438 OK
S31t0519.793* 40.2 5x5 489 OK
S31t0524.771 44.4 5x5 361 OK
S31t0524.781 42.4 5x5 481 OK
S32t0483.884 44 7x9 499 OK
S32t0483.894 43.2 7x9 494 OK
S32to493.863 48.1 7x11 436 OK
S32t0493.872 48.7 7x9 371 OK
S32t0515.802 53.6 9x7 312 OK
S32t0515.811 46 9x9 439 OK
S32t0518.795 39.8 7x13 470 OK
S32t0518.804 42.4 7x13 462 OK
S32t0519.793 40.5 7x15 448 OK
S32t0519.802 38.4 7x15 445 OK
S32t0524.771 45.1 7x13 418 OK
S32t0524.781 45.3 7x13 408 OK
Arne Henden
aah@nofs.navy.mil
Mar 31, 1997
Michael Gutzwiller
deepsky@fuse.net
Mar 31, 1997
505 - 507, 547 - 549, 588 - 590, 630 - 632, 672 - 674,
713 - 715, 755 - 757, 797 - 799, 922 - 924, 963 - 965
The time calculated for all other files will be correct except for a
small subset with 8 to 10 seconds error, too small to worry about. The
corrected version of star has been uploaded to the TASS Cincinnati site
http://home.fuse.net/deepsky/programs.html