Michael Richmond
richmond@astro.princeton.edu
Feb 1, 1997
The US Naval Observatory has just released a gigantic new astrometric catalog, A1.0, which covers the entire sky. It is based on scans of several Schmidt-plate sky surveys, and includes stars down to close to the plate limit -- i.e. down to around 18 in red, 20 in blue.
Brian Skiff sent me a nice description of the catalog, so
let me quote him here:
As some of you may know, the U. S. Naval Observatory in Flagstaff has
produced a colossal star catalogue called "A1.0". The catalogue contains almost
500,000,000 detections, including stars, galaxies, etc. The data will not in
general be available except for scientific use, and cannot be used in
commercial applications. The general Web site describing the catalogue can
be found at:
The site includes links to two third-party search utilities, one from
Doug Mink at SAO/CfA and the other to the Lowell Observatory site.
Since Lowell Observatory folks will making use of the catalogue for
various purposes, Bruce Koehn of the Lowell staff has made a Web page with a
form for searching small areas of the A1.0 catalogue. The URL is:
http://asteroid.lowell.edu/cgi-bin/koehn/webnet
This is the top page for various asteroid-related products. Included is Ted
Bowell's 32,000+ asteroid orbital element database, asteroid search routines,
and other goodies. There is also a link to "refnet", which is the star
catalogue search form.
The search form includes access to the full A1.0, the "SA1.0" faint
astrometric subset (for use with small CCD fields, for instance), and also
the complete PPM catalogue (480,000 brighter stars). The search inputs
include RA/Dec, search area, magnitude, and so on; the output can be sorted
by RA, radius from search center, etc.
The output itself includes the A1.0 position (equinox 2000 at epoch of
the POSS-I blue plate used for the scans, i.e. about 1950-1955), the red and
blue magnitude, the radius from the search center, and the position angle. At
the moment the p.a. runs the wrong direction (i.e. sweeps around from north to
_west_), but this will get fixed eventually. The magnitudes have been adjusted
only very approximately, and possess zero-point errors of up to a couple of
magnitudes. The colors inferred from the red/blue magnitudes can likewise be
completely non-physical---I've found stars with "blue minus red" colors of -3
to -5, which cannot occur in the real world except in blue jeans and lapis
lazuli. I'm finding the blue magnitudes are closer to reality than the red
ones.
The form defaults to a search area 10 arcminutes square. Unles you are
well outside the Milky Way, this results in very long star lists. I would
advise changing this to at most 1'-3' (60 or 180 arcseconds on the form).
Like other catalogues built from scans of photographs, there are gaps
around bright stars (often including the bright star itself), bright galaxies,
bright globular clusters, etc., where the plates were simply black and the
star-finding algorithm couldn't operate. By "bright", I mean stars brighter
than mag. 10-12, and galaxies with total V magnitudes brighter than mag. 12
or so---stuff that's completely saturated on the Schmidt plates.
Have fun with it!
Tom Droege
droege@wwa.com
Feb 2, 1997
While I was taking a dark run, camera #7 just died. Norman's program just said, "I'm too hot" and turned off. I would prefer that it said "I'm too hot", made some terrible noise, turned off the second stage cooler (which is the only thing it can do to reduce the heat) and kept taking data. In this case, the camera has died and one is cut off from the only source of information one might have. Just a comment of philosophy of alarm systems.
It just happens that I was watching the temperature indication and so I knew it was not actually too hot. I just dug out the diagnostic program (tass1c.bas) and started looking. This program has a TEST and an ADCTst button that allows checking each of the channels into the ADC. The first thing to check is the +/- 5 volt power supplies. These read the correct +1.6 and - 1.6 volts. The temperatures both read something crazy like -80 C.
The temptation with a problem like this is to frantically change out all the parts for different ones. One can quickly shuffle so many different parts so that soon one has introduced 2 or 3 new troubles. I did my best to remain calm and tried to use my head. Eventually I found that the problem was due to a pin pulling out of the connector to the center camera. It just happened to be the +15 volt power that feeds both of the thermisters that are in the center camera. This caused the ADC to read 0 volts for these temperature sensors which is interpreted as a "very cold" temperature by the program. I guess Norman does not differentiate between very hot and very cold. Note that I had visually inspected the connectors through the inspection windows on the connector. It was not until I started pulling on each wire that I found the loose pin.
All this has a point. Glenn Gombert has told me that one of his runs shut down with an over temperature reading a few hours into a run. Norman, if you shut down on a single hot reading, you might cause a run to abort from a noise pulse. Like the refrigerator turning on at just the wrong time in the data cycle. As I imply above, there is no sense in stoping the program. There might be some useful diagnostics that result from later read out. Slowly watch as it melts down. I assume that we mostly won't be watching. I start a run and go to bed. Even if it made noise I would not hear it.
I would recommend a little more complicated strategy. Wait until a few successive readings confirm that it is really over temperature. Then set the TEC command to 1 Volts or so to turn off the second stage. Note that the temperature cannot jump suddenly. A quick back of the envelope computation indicates that about 0.1 C per second is about as fast as the water temperature can rise. This assumes dry running with the water just blown away somewhere. The CCD temperature can move a little faster, particularly with a backwards power supply connection. But a 1 degree change between readings is almost impossible.
All this is being improved on the Mark IV. I am designing so the computer can turn on the pump and the TEC power supply. At the moment I am pondering (Are you pondering what I am pondering Pinky?) how to prevent plugging the pump into the TEC power supply and vise - versa. I would like to use these with their factory plugs, but the solution may be just to put AN plugs on them with different shells.
Nick Barnes
nickb@harlequin.co.uk
Feb 3, 1997
> All this is being improved on the Mark IV. I am designing so the computer > can turn on the pump and the TEC power supply. At the moment I am pondering > (Are you pondering what I am pondering Pinky?) how to prevent plugging the > pump into the TEC power supply and vise - versa. I would like to use these > with their factory plugs, but the solution may be just to put AN plugs on > them with different shells.I suggest small daubs of differently coloured paint. Or daub one and leave the other undaubed.
Nick Beser
beser@aplcomm.jhuapl.edu
Feb 3, 1997
> All this has a point. Glenn Gombert has told me that one of his > runs shut down with an over temperature reading a few hours into a > run. Norman, if you shut down on a single hot reading, you might cause > a run to abort from a noise pulse. Like the refrigerator turning on > at just the wrong time in the data cycle. As I imply above, there > is no sense in stoping the program. There might be some useful > diagnostics that result from later read out. Slowly watch as it melts > down. I assume that we mostly won't be watching. I start a run and > go to bed. Even if it made noise I would not hear it.I would like to second Glenn's comment. We ran Camera #5 on Jan 29, (more to get oriented and to calibrate the system than to collect meaning data). In addition to showing us getting very close in the alignment, and imaging Mars (thus verifying our location (Dec wise), the data collection shut down due to a strange event. The program eventially shut down due to a temperature reading of 135 degrees (which I don't think actually happened.) The data curve at that point was just a momentary spike. The strange event was a sudden drop in CCD temperature and a complete saturation of the CCD array (all three arrays). It seems that the controller card had locked up somehow. We were able to rerun the program and it seemed to operate correctly.
> I would recommend a little more complicated strategy. Wait until a few > successive readings confirm that it is really over temperature. Then > set the TEC command to 1 Volts or so to turn off the second stage. Note > that the temperature cannot jump suddenly. A quick back of the envelope > computation indicates that about 0.1 C per second is about as fast as the > water temperature can rise. This assumes dry running with the water just > blown away somewhere. The CCD temperature can move a little faster, > particularly with a backwards power supply connection. But a 1 degree > change between readings is almost impossible.I am going to put two data files at storm, showing the frame when data collection went bad, and the frame (short one) when the system shut down. It show a sudden spike in temperature. The two files are called 0479983.FTS and 0479992.FTS and they are being put in the incoming directory. 0479992.FTS shows the spike in temperature.
I would like some comment (from anyone) as to what happened during the data collection. All three camera files are identical to this one. I think I should also point out, that it was getting light at this time (but the cameras did not see the sun!).
I did notice something rather odd when we imaged mars. The mars image was so bright, that we saw some effects in all three camera each time one of them passed in front of mars. The only time that did not happen was when it seemed to get a little cloudy. I will upload two image files a little later that show the effect.
Tom Droege
droege@wwa.com
Feb 3, 1997
On the subject of mis-mated plugs, you are talking to someone who has seen a 120 pin AN male connector mated to a 120 pin AN male connector up inside the wheel well of an S2F on a carrier deck. Since the only way this could have been done was standing on a ladder ane putting them together over ones heat it had to require the strength of a gorrila to do this. But it was done. Fortunately we discovered this on a pre flight check or there would have been one more order for Grumman for a replacement. A little paint does not even slow them down. It has to be easy and obvious.
Nick Beser
beser@aplcomm.jhuapl.edu
Feb 3, 1997
The APL-TASS observatory ran some test data on January 29, and we were fortunate to image Mars during the test run. I noticed that the flare from the image was visible on all three cameras. I'm not sure what might be causing that.
One posibility was due to the use of optical windows in the telescope housing. All three cameras imaged Mars, and on two of those cases, duplicate flares were seen in the other CCD images. The only time that did not occur was during poorer seeing conditions (slight clouds). We don't think there was a reflection path between the primary CCD (the one that saw Mars) an the CCD's. Is there a electrical or software path?
A comment on quality: We just moved the camera pointing angle up to 0 degrees DEC (it was 10 degrees low), and we have not yet adjusted VCO. We see that alignment on the two outer CCD's need some tweaking. A request to Tom: The alignment hardware has been a source of some difficulty. It has been very difficult to home in on the exact setting. If you are working up a similar arrangement for the Mark IV, please look at making a course and fine adjustment.
Glenn Gombert
ggombert@infinet.com
Feb 3, 1997
I have uploaded a TASS image (30T0478.642) to the 'incoming' area of storm.fnal.gov that shows an asteroid trial in the lower left hand corner. I thought that folks might find it interesting..
Glenn Gombert
ggombert@infinet.com
Feb 4, 1997
I have just uploaded to storm an image (M42V.tif) that was made using Software Bisques "TheSky" and "ImageLink". It shows part of the Belt of Orion area with a TASS Image overlayed with data from "TheSky". The variable stars in the image are identified with little "v's" and the suspected variable stars are identified with "v's" and a question mark "(?)". The variable stars are easy to identify in the TASS image. Once this is done it is easy to make differential photometric measurements using reference star(s) in the same image. This image was taken using a "V" band filter. This is the TASS imag showing the three stars in the Belt of Orion from the Dayton TASS Camera Home Page. I will try to post a "how-to" on this subject on the Dayton Home Page in the next few days.
I thought that this subject might be of interest as I seem to remember some "contest" that was discussed here in the last several days :-) :-) :-)...
Glenn Gombert
ggombert@infinet.com
Feb 5, 1997
I would like to "throw out" some ideas on TASS data analysis based on the "mountain" of data that I have collected here in Dayton and the lack of a "good solid" procedure for getting some good solid data analysis from all the data that has been collected. And see how this might pertain to Tom's "Variable Star Contest".
Due to the huge amount of data that is collected from one single TASS camera one easily sees the need for automated analysis of the data. This has been the focus of much of the effort by folks on the list for the last few month's . A lot good solid work has been done by a number of individuals, but few good solid measurements have been generated from all of the data that has been collected. I think that this probably has a discouraging effect on those people operating camera's who lack good solid techniques for getting results from the data that is collected.
It might make sense to "backup a step" and use more conventional methods to make differential photometric measurements from TASS images and compare these with published measurements for known stars, and then to use these measurements to validate the automated data reduction techniques that we are in the process of being developed. With the large field size of TASS images (3 X 3 square degrees) it will probably be relatively easy to find reference stars in each TASS image that is taken. It seems that perhaps making a number of measurements manually (from each TASS Image) using a known reference star(s) in each image as the basis for the measurements is a straight forward process and has been used successfully by amateurs for a number of years. Also getting in the habit of matching up TASS images with conventional star charts or sky atlas programs is probably a good thing to get in the habit of doing anyway.
The above is probably a good "first step" to compare automated measurements against as they are performed and probably be done on a regular basis. In regards to Tom's Variable Star contest it might be a good idea to make at least some of the measurements at each site using differential photometric techniques, especially if the data is going to be presented by Tom at the AAVSO meeting. These sort of measurements can then be used to verify more sophisticated automated measurements.
Several software packages exist to make differential photometric measurements from FITS format images which use reference stars in the image to compute the magnitude of "unknown" stars. Also many good "sky atlas" programs are in general use that allow TASS star image fields to be found along the path of 0 degree declination where most TASS images are taken. This also might serve as a good way to start to compare and correlate data that is taken at different TASS Camera sites.
The above represents some suggestions that I would like to "throw out" for consideration, they are based on proven techniques for making differential photometric measurements. This is what I plan to do for the next several months here in Dayton as well as to contiune the development of automated technqiues. Hopefully this will help in the overall analysis efforts as well as enable lots of good variable star measurements to be collected as well.
Tom Droege
droege@wwa.com
Feb 5, 1997
> As a first thought, it seems to me that the winner will almost by > definition have fairly good equipment already. If you are designing a > contest, why not design one such that the winners will get something they > very much NEED, rather than something that only > improves opon what they already HAVE?The purpose of all this is to start a serious measurement program that will result in a larger variable star catalog. The winner most likely will not have a camera of the quality I plan to offer as a prize. The contest is a test to see that the winner is seriously interested in the science to be done. The proposed prize is equal 30 tass cameras in chip area and to 11 in pixels. So it is a large step in performance.
I also plan to have two divisions. One for tass camera holders and one for people running with LX-200s and the like.
Tom Droege
droege@wwa.com
Feb 5, 1997
> I think that you actually might possibley make TWO different > catagories of awards (not necessarily with the same prizes) the first is for > the number of variable star observatoions, the second might be for > "technical achivement"... That is the most inovative, additions to the TASS > data analysis suite of tools over the next two months. It could we be used > for the contest of course but would be of benifit to the overall TASS > efforts in helping to process the mountain of data that is going to result, > both now and in the future.... > > You of course would make the determination of how all this adds to > the TASS effort.First I want to point out that this is a "measurement" contest and not a variable star finding contest. The idea is to publish something as close to the raw data as possible. The raw data is just too large. So I am asking for measurements and the proceedure used to make them. Later someone can use this data to do a scholarly analysis looking for variable stars and other interesting stuff.
I tried to cover Glenn's "technical achivement" comment below with my section 7)
>> 7) This is intended to be a friendly and cooperative competition. All >> are encouraged to freely exchange their measurement techniques and >> software. The Management reserves the right to award more than one >> camera system if heroic work is detected.I am in fact going into production on the Mark IV cameras. We will find a way to get one to everyone that is willing to do the work required and has a sustained interest in this topic. The contest is just a way to sort this out. If it works, we will probably run one every year until we have a network that can measure everything and detect earth colliding asteroids. I figure that this will take about 100 years.
Tom Droege
droege@wwa.com
Feb 5, 1997
I tried to clean up storm incoming last night and found that I did not have the necessary permision. I believe this has now been changed so that anyone can write and delete files in storm/incoming.
I would like to ask you all to police your own files. It is fine to leave stuff there for a while, but I don't want to attract attention by filling the disk of a computer that is being made available as a courtesy to me.
Tom Droege
droege@wwa.com
Feb 5, 1997
Chris Albertson commented to Tom about the contest...
> you could make life easyer for yourself if you required anyone > accepting data to pass that data on to another person if requested. > This could cut your work by at least half. I have almost stoped > thinking about analysis for lack of a steady source of data to > analyse. This could get me working again, well after that client/ > server stuff goes out the door to Norman.Good, I like your idea about passing on the data. I will send the tass home base data to the first person that asks for it, under the condition that he pass it on to the next person that asks ...
> One more comment: It would be good if the lists where written out > in FITS table format. This is good because it is self documentingI agree with your FITS format for data. I was about to send mail to our resident FITS expert, Jure Skvarc, to see if he wants to take on the job of the format specification. Are you listening Jure?
> If you call this "raw data" then I agree it does not > need to be further processed but it is unpublishable most places. > > If it where processed to corelate multiple measurements of stars and > to assign catalog numbers to stars then it would be more usful to > others. Well maybe in 1999?As to how to format the catalog. I have mixed feelings. If we muck about with it too much, then it may not be possible to unfold it back to the raw data. For example, how will one decide that two measurements are of the same star? It may not be so easy. Various analyzers may want to make different cuts. This is a good point for discussion by the resident professionals??? I think I lean as stated. We publish measurements by observer, with a full disclosure of what was done to process the raw data to a star/ magnitude list.
Jure Skvarc
SKVARC@eros.ijs.si
Feb 6, 1997
Of course, I can try to write a specification for output files. I understand from your post that Chris has written some wider proposal what to do. You cite a part of his message, but I could not find the original in my mailbox. Probably it was sent directly to you only. It would help me a lot if you (or Chris) forward it to me.
One more thing. Some time ago I proposed that we establish a small library of test images so people could test and compare their software on them. I think we still need this, located on some permanent location. If disk space is a problem, I think I could find 100 MB or so on one of computers here. However, do not expect fast data transfer.
Tom Droege
droege@FNAL.GOV
Feb 6, 1997
We can still use Storm as a relay point as long as we don't let the files grow without bound. I think we are good for 50 Mb or so. It will move in about a month, but I think it will be available for the next year. After that, I hope to have a site set up at Princeton. We are presently working on a proposal which would provide for this.
It appears that I was successful in getting the permission set up so anyone can load and delete files in storm/incoming. This will require some discipline. Possibly one of you can take on the job of managing the files there, cataloging them, and deleting the obsolete stuff.
Chris, can you send Jure your ideas on the contest FITS format?
Michael Richmond
richmond@astro.princeton.edu
Feb 6, 1997
I can offer several hundred MBytes of disk space on a machine with good Internet connections, so people who wish to donate images to an "Image Library", please contact me directly.
It strikes me that the library will be more useful, the more annotated each image is ...
Jure Skvarc
SKVARC@eros.ijs.si
Feb 7, 1997
OK, I will think about FITS tables and output files during this weekend and then post my conclusions.
Michael Richmond
richmond@astro.princeton.edu
Feb 7, 1997
Glenn Gombert is planning to use his camera to make "conventional" differential measurements of a few variable stars per TASS image, rather than trying to deal with hundreds of stars at once. He asked me some questions, and it seems to me that others may be interested in the answers. Oh, and if I send material to the TASS mailing list, it is archived for future reference, so I don't have to re-type it :-)
If you want to do differential photometry, it would be _best_ to include a star of known brightness, to set the zero point properly. As you point out, the Landolt stars are too sparsely scattered to appear in any image on the equator.
If you want to _try_ including stars of known brightness, you could check to see if one of the Landolt stars, or one of the stars from Skiff's complilation
http://www.astro.princeton.edu/~richmond/tass/refs/skiff_photom.html
just happens to appear in your field. If so, fine!
Whether or not there _is_ a star of known magnitude in your field, you should choose more than one "standard" per field. If you include 5-10 "standards", you can check to make sure that no "standard" is itself a variable; you also can measure the precision of your measurements by calculating the internal scatter among the "standards".
By choosing "standards" which span the width of an image, you will notice if variation in the PSF across the frame causes any change in precision; by choosing standards which span the length of an image, you can check for variation induced by changes in the sky brightness or transparency (all this assumes that you make measurements of these "standards" on a large set of different frames).
It is good practice to make sure that at least 2 "standards" are close to the target star, so that they should have roughly the same sky background and PSF.
Well, this depends on your goal. If you are studying a star which is known to vary by several magnitudes (like Mira), then a precision of 0.1 magnitude may be fine and dandy for your purposes. If you want to measure variations in a star which is known to have a tiny amplitude, you'll need even tinier errors.
So, decide on your goal, and act accordingly. Perhaps you might start out by including ALL the stars, even the faint ones with big errorbars. After several days/weeks/months, you might assess your work, and decide that you really want measurements with errors smaller than X percent; well, you can throw out all the others. It's harder to go in the other direction :-)
TASS Technical Note #19 describes some measurements I made of stars in fields with known standards; comparing my measurements to each other, and to the known standards, both yielded about 5% accuracy for stars brighter than V=12. I suspect one can do a bit better.
Even if MOST of your images don't include any known standard stars, I plead with observers to include at least a FEW fields with known stars. By comparing your magnitudes to the standard ones, you can
Yes, I have :-) This is an excellent point, and a source of worry. But there _is_ something you can do; by following the plea in item 3 above -- taking images of some Landolt fields -- you can at least check your V magnitudes to see if they vary significantly with stellar color. If you discover that, indeed, redder stars are systematically brighter than bluer stars in V, you at least KNOW the problem exists, and you have some idea for the SIZE of the problem.
Famous last words: I plan to make an observing run next weekend. Just watch a giant storm system cover the Northeastern US from Feb 13-17 :-)
Herb Johnson
hjohnson@pluto.njcc.com
Feb 7, 1997
I now have more time for TASS stuff. I like asteroids...
Glenn (?) recently offerred a TASS image which included a trail of an asteroid. I downloaded it (via a pointer on the TASS site, thanks Michael!). Since I don't have reliable FITS viewers around, I've exhumed a old program of mine to create .gif files, and I modified it to convert the file to .gif in order to display the "asteroid" image file on my MS-DOS/Windows system. Doing this "cold", I'm not up on all the background of TASS image format. But the file appears to have been processed by another program to create a FITS file. My questions and comments may be instructive so I'll post them.
It appears to have a FITS like header which is correct, sort of. It would seem that the data in the file has an offset of around 0xAB00 rather than 0x8000 (32768); or the sky background is signifigant! I was able to "image" the file sufficiently to see the apparent asteroid trail in the lower right hand portion of the screen. Unfortunately it goes off the edge of the field of view.
Knowing when the scan initially imaged that portion of sky, you could determine location. Knowing the rate of pixel advance (the column clock rate), and the angular size of the pixel row, you could determine sidereal rate of motion. With the raw data and knowledge of ADU count vs magnitude, and allowing for the integration across the observed path, you could regenerate the average magnitude. Monitoring the ADU's pixel by pixel, you can monitor the magnitude per scan time, to see if there is a cyclic rate of rotation. I'd have to do my homework on the Mark III constants (not included in this file's header) to obtain these values, presuming the data in this file is not "processed". Is the raw TASS file available with this other data I've mentioned, including observation times? Are the stars identified in the field near the asteroid? Etc.
An interesting note is that the asteroid apparently went near or across a star: such information is very useful for asteroid orbit determination. That bit is beyond me, but others can do that better than I. This would call for knowing the site's geographic location. Given the long interval of pixel clocks (tens of seconds as I recall), unfortunately any occultation shadow information would not be resolved: you can't likely determine the diameter of the asteroid with a Mark III camera!
Neat, eh?
Bill Dillon
bdillon@houston.geoquest.slb.com
Feb 7, 1997
Herb Johnson wrote in part:
>I now have more time for TASS stuff. I like asteroids... > > An interesting note is that the asteroid apparently went near or across a > star: such information is very useful for asteroid orbit determination. > That bit is beyond me, but others can do that better than I.
I like asteroids too, and have an account with the Minor Planet Center. If you can supply the time and RA and Dec, I can identify which asteroid it was (and how bright it was suppose to be).
Norman Molhant
molhant@ERE.UMontreal.CA
Feb 7, 1997
I have again some time to put on the LINUX version of the data collection program, so I'm back at work on that still buggy piece of software.
Chris, did you finish the client/server code, and if so, where can I download it from? If you haven't, don't worry, I have found some sample client/server code I could use instead... although it is on paper. :-(
Herbert wrote:
> Glenn (?) recently offerred a TASS image which included a trail of an > asteroid. > ... > But the file appears to have been processed by another program to create > a FITS file.Which program appears to have somehow removed most of the important FITS header data. Why, Glenn?
> It appears to have a FITS like header which is correct, sort of. > It would seem that the data in the file has an offset of around > 0xAB00 rather than 0x8000 (32768); or the sky background is signifigant!Glenn?
> Knowing when the scan initially imaged that portion of sky, you could > determine location. > Knowing the rate of pixel advance (the column clock rate), and the angular > size of the pixel row, you could determine sidereal rate of motion.All these infos were in the raw data file header.
> With the raw data and knowledge of ADU count vs magnitude, and allowing > for the integration across the observed path, you could regenerate the > average magnitude. > Monitoring the ADU's pixel by pixel, you can monitor the magnitude per > scan time, to see if there is a cyclic rate of rotation. > I'd have to do my homework on the Mark III constants (not included in > this file's header) to obtain these values, presuming the data in this > file is not "processed".What kind of processing was done on it, Glenn? Nice image, by the way.
> Is the raw TASS file available with this other data I've mentioned, > including observation times? > Are the stars identified in the field near the asteroid? > Etc.
> An interesting note is that the asteroid apparently went near or across a > star: such information is very useful for asteroid orbit determination. > That bit is beyond me, but others can do that better than I. > This would call for knowing the site's geographic location.Which info was also included in the raw data file header.
> Given the long interval of pixel clocks (tens of seconds as I recall),No, it's a tad below one second per row.
> unfortunately any occultation shadow information would not be resolved: > you can't likely determine the diameter of the asteroid with a Mark III > camera!In fact, you could, if you were driving the row clock too fast, so as to get trailed stars: the star trail and the asteroid trail would cross over a number of rows, with a dip in the amplitude of the pixels where the asteroid did occult the star. You could, for instance, drive the CCD at twice the sidereal rate, thus getting a bit less than 0.5 seconds per row and enabling you to time the occultation down to better than half a second. This would, however, require comparing the trailed image with an untrailed one taken at the same time, hence using two Mark III cameras together.
> Neat, eh?Indeed!
Glenn Gombert
ggombert@infinet.com
Feb 7, 1997
The file was processed (dark-frame subtracted) with a "beta-test" version of CCDSoft it is Software Bisques new 32 bit image processing program that I have been Beta testing. It does destory most of the information in the FITS header. I have talked to Tom Bisque about this and they are going to fix the problem before it is released to production.
Having said that I can try and locate the source image again if it is of interest and reload it onto Storm. (I just cleaned a number of files off of there per Tom's request)
Glenn Gombert
ggombert@infinet.com
Feb 7, 1997
For Herb (and all those that may lack a good DOS FITS viewer) I can recommend Herb Raab's Astrometric Program that can be found at:
http://mars.planet.co.at/lag/astrometrica/astrometrica.html
It does quite a nice job of diplaying TASS FITS images as well as being able to perform simple scaling as well as blinking several images together.
It also has a very handy feature that you can plot a selected region from the Hubble Guide Star Catalog by specifiying a center RA and DEC and a field size. Once the region is plotted it can be rotated and scaled to match the comparison ccd image. All VERY useful for identifying the exact fields that TASS images are taken from.
The program is normally used to supply asteriod observations to the Minor Planet Center. It is shareware and can be downloaded (along with instructions) from Herb's Home Page. If you use it regularly (like it do mine) Herb asks for a $25.00 fee to become an "offical" registered user.
All in all it serves as a good basic program for viewing and doing basic analysis of TASS images.
Herb Johnson
hjohnson@pluto.njcc.com
Feb 8, 1997
*>> Glenn (?) recently offerred a TASS image which included a trail of an *>> asteroid.Apparently this image is reprocessed TASS data, and Glenn has addressed this in a subsequent message. Glenn will hopefully have the original image and data. I appreciate that he's offerred the image to gauge interest. I hope he has the original data on hand, I'd like to do things with it as I suggested.
*>> unfortunately any occultation shadow information would not be resolved: *>> you can't likely determine the diameter of the asteroid with a Mark III *>> camera! *> *> In fact, you could, if you were driving the row clock too fast, so as to *> get trailed stars...Point being, if the TASS camera did not follow the sidereal rate, you'd have many more exposures of the asteroid. However, it would be lost in the star trails unless it were in relative motion at some angle to the equinox (i.e. the earth's plane of rotation). The Mark III camera's intention is long exposures of a broad path of sky. Certainly, other "missions" for it make sense to me. I suggested as much for the Mark IV recently. I'm getting "itchy" to do some asteroid observing for myself!
Tom Droege
droege@wwa.com
Feb 8, 1997
I should remind everyone that one sees lots of these trails. Every evening and morning I get a few from satelites. There is also one from time to time in the middle of the night. Then there is the airplane, not always so bright. People who want to look at moving stuff will not be disappointed. But I think moving stuff is harder to sort out. I guess everything is hard. For variable stars one must be much better calibrated. I guess we will also see meteors.
That is why I am so interested in doing this. There is lots of stuff to see, and not many are looking.
Glenn Gombert
ggombert@infinet.com
Feb 8, 1997
I uploaded the "asteroid" image again to storm.fnal.gov: 30t0478.642 It is the "raw" image without any processing done to it so the header data should be intact. It has not been dark-frame subtracted. As Tom pointed out it may not be a asteroid but it seems to be an interesting image to anayze since there is obveously something moving in the frame.
Glenn Gombert
ggombert@infinet.com
Feb 9, 1997
I just uploaded to Storm a "finder chart" that shows where Brian Skiff's standard field stars are located with respect to the zero degree declination angle that the TASS camera's image along. It is called "skiff.prn" and should be able to be printed on any laser / inkjet printer. It is meant to be "copied" to the printer output to be printed. As can be seen, it looks like there should be enough standard field stars along the line of zero degree declination to get some idea of the photometric qualities of each TASS camera.
I also create a "sky database" containing the information from Brian's list if anyone is interested I can upload it as well. You would need "TheSky" Level IV software to be able to use it.
Jure Skvarc
SKVARC@eros.ijs.si
Feb 10, 1997
Recently Tom announced a contest which purpose is, as far as I can see, to encourage people to actually build databases of star data obtained by CCD cameras and image analysis software. Chris proposed to (loosely) define some format in which the information is stored. Indeed, without some definitions one could hardly guess what those files actually mean and it is rather difficult to imagine how would data about individual stars be extracted. I started to build an outline of output file format which would be useful not only for the purposes of the contest but also for regular TASS operation. So, here it goes:
This message is about output files produced by image analysis programs. The basic content of output files will be a list of objects found on images produced by CCD cameras. There will be some additional information to make observations useful for TASS purposes. The final destination of objects will be some database. The format of files should be FITS using tables.
To simplify matters, let's exclude from output files any extended objects: galaxies, star clusters, the Moon, the Sun, mother ships, birds, as well as trails from planes, satellites and meteorites. This leaves us mostly with stars and asteroids.
All objects coming from the same image share a lot of information. I will name at least some of them:
It seems that items under a) are quite essential and should be included in every output file and items under b) can be useful but are not so critical. Most of these information is already present in the original image file (by "the original image file" I mean a file taken by image analysis program, not a file produced by aquisition program). Image code should unambiguously identify image. The best place for all the information above is in a FITS header.
As far as I can see, there are only few values specific for every object in the list. They are:
This can be very important and useful, although it is possible to live without it. By ID I mean star numbers from catalogues (such as PPM or GUIDE) and asteroid designations.
These three numbers exist for every object at some moment during the image analysis. In a long run they may provide useful information. For example, it may turn out that all objects from camera 5 and x-coordinate range between 100 and 200 have their brightness 0.5 magnitude lower than for other coordinates.
These two are also useful but I am not so sure whether it is possible to give some reliable estimates for every individual measurement. All in all, only the first four values (RA, DEC, MAG and image code) need to be present, others are optional.
So, with this definition we can build a FITS file containing all of the measurements from a single image. But we want to have a database of all measurements. Since we still don't have any suitable database program working for us I propose two possible provisional solutions.
The first is to do nothing: each output file can be treated as a large record. If somebody wants to search for certain objects, he has to check coordinate range given in every FITS header and proceed with search only if wanted object falls in this range. (It may be a good idea to sort records in every file according to magnitude).
The second is to make a primitive database consisting of two (types of) files: one with image descriptions from FITS headers and another with object information as defined above. Files would be in plain ASCII, with comma delimited fields and newline delimited records. I guess that many database programs would take this and it would be easy to write a perl or awk program to manipulate with data. With the second solution we loose flexibility of FITS but we gain flexibility of simple ASCII, what is not negligible.
This message is already too long so I will conclude for now. The basic idea here is that all the people who have image analysis programs should adapt them to output their results as a FITS file or write a filter program which will transform program output to FITS. Detailed format with keywords will be defined after we come to some agreement about the database fields proposed here. I welcome your suggestions and comments.
Jure Skvarc
SKVARC@eros.ijs.si
Feb 10, 1997
I have some concerns about data quality TASS cameras will produce, especially about photometry. Mark III has rather large field of view and it is quite likely that some gradient of camera sensitivity occurs because of clouds and maybe other reasons. I think we should take term "data reduction" quite literally and reduce the amount of data by throwing away images if we have any reason to believe that photometry can not be done up to some standard we define. Currently I don't see how is it possible to do any acurate photometry without comparing reference stars from the image with those from some catalog. So, I propose to reject every image where comparison of reference stars gives too large a discrepancy or where it is not possible to do a comparison. The amount of data produced by TASS, although reduced, will still be large but the quality will be highly increased.
Glenn Gombert
ggombert@infinet.com
Feb 10, 1997
I think that you point is well taken, however if we perform "differential photometry" then the check and reference stars should have roughtly the same magnitudes if taken from the same frame of data the results should not be too bad. With the large pixel sizes for Mark III the limit of accuracy is probably about 5% or so. this agrees with TASS Technical Note #19 written by Michael Richmond. I have been doing some differential photometry on several TASS images today and have been able to get reasonable results down to about 13.5 magnitdue with the tools that I have been using. After that the stars are difficult to accuratley identify and the photometric results become much more uncertian. But using differnetial techniques helps to minimize the variaition from one TASS frame to the next..
Martin Pittinger
PittiMJ1@central.ssd.jhuapl.edu
Feb 10, 1997
I uploaded an image of a jet trail (Feb. 4) to STORM (Jet.fts) and a text file w/ information (jet.txt) about this image.
It appears that the sharp horizontal line at the end of the trial seems unusual for an asteroid. I've seen the same feature for jet trails (Re. Jet.fts), especially near-by jets.
I hope this information helps with the determination of this object.
Herb Johnson
hjohnson@pluto.njcc.com
Feb 10, 1997
*> ...because of clouds and maybe other reasons. I think we should take *> term "data reduction" quite literally and reduce the amount of data by *> throwing away images if we have any reason to believe that photometry *> can not be done up to some standard we define..... *> Jure Skvarc
While this is a reasonable consideration, it ignores the possibility of DETECTING events and objects, even if they cannot be resolved photometrically to a given level of resolution. I suspect in the end data archiving is limited by a site's capacity to both collect and archive data. Perhaps other sites can be found to retain "discarded" data for later analysis. Meanwhile off-line storage costs (tapes, CD's, etc.) drop by the month.
Establishing standards, however, is valuable in its own right. One issue is the ability to "qualify" a given TASS image to some level of consistancy and quality. The unique problem of the Mark III camera is that parts of the image are progressively "older" and may suffer from changing sky effects; rather than representing a literal "snapshot" of the sky. Other than monitoring the sky background and standard stars (which begs the question during the star recognition process), how do we know the "state of the sky" at any point of the image?
Glenn Gombert
ggombert@infinet.com
Feb 10, 1997
I just created a "skiff.gif" file and uploaded it to Storm with the same information, hopefully folks will be able to read it OK. The "prn" file wasn't a good choice for people to be able to read.....
Chris Albertson
chrisa@wavenet.com
Feb 10, 1997
Norman,
I put a snapshot of the client/server code on ftp.logicon.com/open/chris/Sockets.tgz
I resisted the temptation to clean it up before posting it. In fact some files may not even compile. I use RCS for revision control and have included the RCS directory, so you also have all previous versions of all my files. I have had the system up and running but went through another round of adding features and as of now am not finished.
You can look at what I have and we can talk about what to do next. I do intend to finish this. I can work on the part you need first first. Let my know what that is.
I could also do testing here. How hard would it be to create a test version of your linux kernel driver that always returns a constant or some other kind of test patern. It would at least let me test everything downstream of where you introduced the test patern and could let work on a client start sooner.
Tom Droege
droege@wwa.com
Feb 11, 1997
My computer is moving today at Fermilab. Best that you contact me at droege@wwa.com until I say I am back up.
There is more evidence that the mail list is cranky. If you make a post and don't see it echo to you, then try again. I have no better solution at this time. We hope to solve this in the future by moving the whole thing to a University some where.
Arne Henden
aah@nofs.navy.mil
Feb 11, 1997
Jure raised the question regarding photometry through clouds, and Glenn correctly replied that differential techniques can be used. With our FASTT telescope/drift scan, we can do reasonable (2percent) photometry under pretty awful conditions. Unlike a stare-mode frame, the drift scan frames are not exposed at exactly the same time and you do suffer some sky extinction problems along the strip. However, if you select your comparison stars nearby the program object, they do have almost simultaneous exposures and the ensemble gives a good differential value.
As far as photometric standards are concerned, I am willing to both cull the literature (such as the Mermillod catalog) and take extra VI data to generate a set of 8-12mag standards along the equator for the proposed 'contest'. This can also be used as a calibration set for learning the proper techniques for drift-scan photometry.
As far as using the TASS cameras for variable star work, since the images are pretty rotten you actually might do pretty well in uncrowded regions. I would not be surprised if 2-3percent photometry were possible in these cases. We certainly do better than that with the 8" FASTT telescope. As part of my variable star survey along the equator, I have many new large-amplitude variables such as Miras that could be used as test cases. Even 10percent photometry is useful for these stars since their amplitudes are large and what you are primarily looking for are periods, light curve shapes and color changes during the pulsational cycle. If anyone is interested in these, I can provide coordinates, a rough idea of magnitude and period, and finding charts.
Glenn Gombert
ggombert@infinet.com
Feb 11, 1997
After a short conversation with Tom he felt that we should stay focused on automated measurements from TASS images (and not try to make manual measuremnts). This is especially true since the next generation of cameras's will collect a LOT more data and any type of manual measurements would be counter-productive (except perhaps to calibrate the measurements that are made using automated techniques)....
Over the weekend I was able to get precise center of the field locations for 10-11 TASS images and also measure (manually) several stars in each image. This will be very useful for calibrating the output from several of the programs that are used to produce automated star lists. It does not appear to be an objective of the "contest" to measure specific variables in the images but to calibrate (RA, DEC, and magnitude) measuremnts that are made from the TASS camera images. And to perhaps to quantify (with some sort of error-term) the magnitude estimates made from automated means.
Perhaps Tom could further expand on the above and help use to use the "contest" to further the TASS data reduction techniques to the greatest extent possible in the next several month's.
Arne Henden
aah@nofs.navy.mil
Feb 12, 1997
It is often better to walk before learning how to run. I'd suggest working with 'constant' stars at this stage of the game and make sure that you can do repeatable photometry on them. That gives you a handle on how well you can do photometry on various parts of the chips and under varying sky conditions.
The Landolt standards tend to be faint and often in crowded regions. Due to our drift-scan survey for variable stars, I have R-band photometry on some 1M stars near the equator, and can search the database to locate a subset that (1) are constant; (2) are reasonably bright, like V=9-10; (3) are in uncrowded regions. I'd suggest picking a half-dozen regions along the equator and providing several stars in each region. That gives you an idea as to repeatability for isolated stars, and also how well you can do differential photometry in a smaller area.
If there is interest in this exercise, I'll generate the list and post it on Mike Richmond's web site.
Ed. note: the list now appears under the Catalogs section of the TASS home page. MWR, Feb 14, 1997
Glenn Gombert
ggombert@infinet.com
Feb 11, 1997
Well... I think that I have made a major beakthrough tonight in being able to measure PRECISE astrometric and photometric properties from TASS Images (or any other ccd image for that matter) and do this in an (almost) automated fashion. Tonight I was able to determine how to calibrate the new version of the "Sextractor" program to give VERY precise photometric measurements from ccd images by "tuning" the "magzero_point" parameter in the configuration file.
The test image that I used was an image of NGC891 taken with a SBIG ST-6 and a 16 inch F/4.5 Newtonian telescope. The brightest star in the image was "GSC 2839:969" which had a GSC magnitude of 10.1 the measured magnitude from Sextractor was "10.3033". The faintest star in the image (that was found in the GSC data) was GSC 2839:302 with a HGSC magnitude of "14.9" the MEASURED magnitude from Sextractor was "14.9040". Right on the money! About 15 - 20 other stars in the image were compared with similar results the magnitude was usually within +/- 0.2 magnitude. With better reference stars and more careful calibration I am sure that better results can be obtained! All these measurements were made automatically once the parameter file was set up correctly. This should allow a whole nights run of TASS images to be processed AUTOMATICALLY once the appropriate parameters have been set up.
The procedure that I have come up with is outlined below:
That's it! The procedure that I have outlined above works and the only thing that costs $$ is Software Bisques "TheSky" program. The rest of the programs can be downloaded with links from the TASS Home Page. I hope to repeat the same procedure with a TASS image in the next day or two and post the results on Storm for people to review.......
Glenn Gombert
ggombert@infinet.com
Feb 12, 1997
I just uploaded to Storm an example image and catalog output from my first attempt at TASS Photometry using the method that I described in the eariler message. The image that I uploaded was 31t0457.636 and the photometric catalog that was generated was 1t457636.cat. In the Star-List are 8-10 GSC and SAO Stars and their GSC Magnitudes for comparison purposes. This is the first time that I have tried this with a TASS Image and the results don't look to bad. I am sure with more careful calibration much better results could be obtained. I left the X / Y posiitons (not RA and DEC) so folks could relate the photometic measurements to the image for comparison purposes. I will try and upload a better example over the weekend.....
Arne Henden
aah@nofs.navy.mil
Feb 13, 1997
Glenn wrote that he was getting +-0.2mag for photometry off of his TASS image of NGC891. While he considers this precise photometry, Mike has indicated that 5percent (0.05mag) photometry is possible, and my experience with drift scan systems sez that 0.01mag precision is within the realm. I think the major part of your error is in using the GSC magnitudes, since these are photographic and have +-0.3mag precision at best. I would repeat the same exercise for one of the Landolt fields. Still, the goal is fully automated results and your solution is certainly one approach that shows promise!
You didn't report the astrometric precision. Depending on the image profile, you should be able to achieve 0.05 pixel centroiding accuracy, or something around 0.5-1.0arcsec if you use a fair reference frame of GSC or higher accuracy stars.
Nick Beser
beser@aplcomm.jhuapl.edu
Feb 13, 1997
Calibration work is continuing on the APL TASS camera (#5). The last run we made (Feb 9) shows some continuing alighment, and VCO problems with CCD0 and CCD2. Based on the star charts, we determined that the centerpoint in Declination for the three camera were:
CCD0 -0 deg, 2 min, 59.97 sec CCD1 0 deg, 19 min 19.73 sec CCD2 1 deg, 29 min 50.79 secThese numbers are derived from slightly out of focus, with VCO problem images, so they may be inaccurate. We are showing CCD2 as pointing more than 1 degree above the other camera. Tom can you suggest any adjustment that we can use to fix this problem?
CCD1 shows the cleanest results, with CCD0 and CCD2 requiring additional adjustment for alignment.
We will be reporting on more results from the Feb 9 run.
Tom Droege
droege@wwa.com
Feb 13, 1997
Nick asks how to align the cameras in declination. My original plan was to shim them. On the roughly three inch base, A one mil shim should be about a minute of arc. Just slip a shim between the mounting plate and the bar below. Possibly washers under the screws.
One might ask, why care? Just take data where they are pointing. This will result in a distribution of the tass data. Since most cameras will cover the equator, we will get a lot of measurements there. Out at the wings there may be only one camera looking and we will get less data - but of different objects. Might be a good plan to understand what we want to do in the future.
What does everyone think???
Tom Droege
droege@wwa.com
Feb 13, 1997
I wonder if I could get a show of hands from those that are interested in entering the camera contest with the present rules. So far, I don't feel I have a strong response. I have been thinking instead to offer the prize for the first person to submit a public domain program that takes a data file and Norman's log file and automatically processes a star list from it.
Since Glenn has been working on this using a piece of commercial code (The Sky) I think it would be OK with me if this is not too expensive.
What do you all think? So far I have been mostly underwhealmed by the response.
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 13, 1997
I have been working on just such a public domain program myself. Actually the "star" program I published at the Cincinnati TASS site has all the steps with the exception of matching x and y to RA and Dec. I hope to fold in Michael's "match" program to the next verion of "star" to provide the last piece. I will enter my data into the contest as soon as that last piece is in place.
Arne Henden
aah@nofs.navy.mil
Feb 13, 1997
> One might ask, why care? Just take data where they are pointing. This will > result in a distribution of the tass data. Since most cameras will cover > the equator, we will get a lot of measurements there. Out at the wings there > may be only one camera looking and we will get less data - but of different > objects. Might be a good plan to understand what we want to do in the > future.Correct me if I am wrong in the following statements -- I certainly have not been as deeply involved as the rest of you!
My assumption was that two cameras used I-band filters so that false detections could be removed (if not seen in both images). One camera used a V-band filter so that you then had two colors, and therefore a color index, for all objects. This being the case, then you would want all three cameras to see the same strip. Errors of an arcmin or so only affects the outer few columns, but you want this loss to be as small as possible. Likewise, if you all intend to scan the same region (namely the equator), then I'd suggest that all TASS systems would be aligned to the same central declination as well to maximize the overlap.
I haven't seen any description of rotational alignment (so that stars track down the same column)...I'm sure its there, but someone might enlighten me off-line.
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 13, 1997
> Glenn wrote that he was getting +-0.2mag for photometry off of his TASS > image of NGC891. While he considers this precise photometry, Mike has > indicated that 5percent (0.05mag) photometry is possible, and my > experience with drift scan systems sez that 0.01mag precision is within > the realm. > I think the major part of your error is in using the GSC magnitudes, since > these are photographic and have +-0.3mag precision at best. I would > repeat the same exercise for one of the Landolt fields. Still, the goal > is fully automated results and your solution is certainly one approach > that shows promise! > You didn't report the astrometric precision. Depending on the image > profile, you should be able to achieve 0.05 pixel centroiding accuracy, or > something around 0.5-1.0arcsec if you use a fair reference frame of GSC or > higher accuracy stars.
I have done a little hand matching of stars in the images I have acquired to date. The best I've done is about 0.015 mag from one night to the next for the same camera. For different cameras with the "same" filter this degrades to about 0.020 mag. I'm getting about 0.15 pixel position errors.
These values are all for relatively bright (mag 8-9) stars. The photometric values are all differential measurements.
Arne Henden
aah@nofs.navy.mil
Feb 13, 1997
I wrote:
> Glenn wrote that he was getting +-0.2mag for photometry off of his TASS > image of NGC891. While he considers this precise photometry, Mike has > indicated that 5percent (0.05mag) photometry is possible, and my > experience with drift scan systems sez that 0.01mag precision is withinThen Michael Gutzwiller wrote:
> I have done a little hand matching of stars in the images I have acquired > to date. The best I've done is about 0.015 mag from one night to the next > for the same camera. For different cameras with the "same" filter this > degrades to about 0.020 mag. I'm getting about 0.15 pixel position errors.Sorry -- I was referring to Michael Richmond and TN # 19, not any results that Michael Gutzwiller has achieved. Please excuse any confusion that my 'Mike' comment may have caused. Gutzwiller is getting close to the number that we get with the FASTT telescope, with the exception of degraded centroiding. This may be due to the different image profiles between our telescope and the TASS cameras, or it may be due to different centroiding algorithms. How are these positional errors calculated? Differentially between common stars in two frames, or from an astrometric catalog, or just the sigma of the fit in the centroiding?
Glenn Gombert
ggombert@infinet.com
Feb 13, 1997
"Count me in" either way I would be interested in the "contest" whichever way you would like to run it. When you mentioned a "star list" I assume that you mean RA, DEC and Stellar Magnitude, NOT X, Y, and Instrumental Magintude!
I use "TheSky" to find the center of the field of a TASS images accurate to several arcseconds. IF someone has a better way to to this presently I would be most interestd. I the value that Normand calculates is not accurate enough for good Astromerty soulutons.
Arne Henden
aah@nofs.navy.mil
Feb 13, 1997
You guys are going to get tired of my postings!
I have a concern with the new concept for the contest. It leaves out those who may not have sufficient programming experience to write such a program, and gives an unfair advantage to those who have already started writing an equivalent program. It is difficult to come up with a good contest! Even the earlier version, looking for variables (or at least counting stars), gives an advantage to those in darker sites or that have better weather.
I would rather see you folks working together to create the best possible system, perhaps with outside 'judges' or at least the use of test regions and calibration data, to ensure that you get the maximum return and that your data might be useful to professionals as well.
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 13, 1997
> ... Gutzwiller is getting close > to the number that we get with the FASTT telescope, with the exception of > degraded centroiding. This may be due to the > different image profiles between > our telescope and the TASS cameras, or it may be due to different > centroiding algorithms. How are these positional errors calculated? > Differentially between common stars in two frames, or from an astrometric > catalog, or just the sigma of the fit in the centroiding?The astrometric errors are the RMS difference between the RA and Dec computed by Michael Richmond's match program and the RA and Dec of the matching stars from the SAO catalog.
Tom Droege
droege@wwa.com
Feb 13, 1997
Chris Albertson wrote:
> Maybe a prize should go the the first person who could reduce 100 > frames of TASS raw data "hands off" and to some defined quality > standard. Say 10% photomety. By "hands off" I mean you enter > only one command or make only one mouse click and the whole process > is "automagic" you get a set of FITS format tables with star lists.I think I agree with you 110%. I have been thinking along these lines.
This really allows everyone to enter. We would put up some frames of tass data, and everyone could have at them.
As you may know, the program that Norman Molhant writes many 1.4 Mb overlapping (20 lines each way I remember) files. It also writes a log file with information about all the files. So I would like to see a program that took the log file as input, and just produced a measurement list as the output. Jure Skvarc is, I believe, working on a spec for the output file format. Then I assume, it would also write an exception file. Something funny in frame 17, too many clouds frame 34 to the end., etc..
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 13, 1997
> As you may know, the program that Norman Molhant writes many 1.4 Mb > overlapping (20 lines each way I remember) files. It also writes a > log file with information about all the files. So I would like to > see a program that took the log file as input, and just produced a > measurement list as the output. Jure Skvarc is, I believe, working > on a spec for the output file format. Then I assume, it would also > write an exception file. Something funny in frame 17, too many > clouds frame 34 to the end., etc..The only caveats to this is the necessity of specifying (and many times generating) the dark and flat vectors needed to process the files. We should be able to get to nearly automagic processing but for now I like "seeing" the steps along the way.
Joe Ronchetti
jronchetti@earthlink.net
Feb 14, 1997
I agree with Tom in this matter as it is the first time I have seen the contest available to those with out cameras.
Nick Beser
beser@aplcomm.jhuapl.edu
Feb 14, 1997
I just saw the following posting on the comp.os.linux.announce newsgroup. I think it may be useful for the linux version of the control software.
> ----- > > R J Gerharz: Timer Hook Patch for Linux Kernel Fri, 14 Feb 1997 > 03:36 > > I have placed my timer hook patch and some usage instructions at: > http://www.erols.com/rgerharz/Linux/ > > This patch allows, for example, data acquisition and control device > drivers to obtain control at precise, periodic intervals. > - -- > Reinhold J. Gerharz > http://www.erols.com/rgerharz/ >
Herb Johnson
hjohnson@pluto.njcc.com
Feb 14, 1997
*> I wonder if I could get a show of hands from those that are *> interested in entering the camera contest with the present *> rules. So far, I don't feel I have a strong response. I have *> *> What do you all think? So far I have been mostly underwhealmed *> by the response.I myself am more interested in asteroids these days. With a TASS camera, I'd support other work including variables and I'd support (but not offer online) an archive of raw data. I might get "drawn in" to variable work, or at least do some blink comparisions to look for flare stars. But my personal response is that there are a number of people better than I at variable star work and I've presumed they would win before I.
But it's funny how that works. I've found many amateurs just want to do what they want to do, and will not consider taking other people's equipment, offers for assistance or for collaberation. Astronomy is often - but not always - a solitary activity. Also, people develop their own ideas for reducing data or observations, for various reasons. So good equipment, observatories, and opportunities are more available than one might first imagine. Persistance and initative sometimes wins out over experience.
Seems to me a reasonable goal is to get good equipment into the hands of those who will use it and share the results, raw and processed. Such procedures to insure the above are desirable. Archiving for instance is a tough business, mostly tedious, but I think it's very important. But it won't win any contests, it won't get a pretty picture into Sky and Tel.
Hope this mix of reactions helps. I'm reluctant to say much more, personal comments can become "targets", and I don't feel like being a target.
Meanwhile, speaking of software, I've been introduced to "Astrometrica" via this newsgroup. It's a shareware program for astrometric work on comets and asteroids. I've started to look it over and it looks promising! And, it runs under MS-DOS (sorry) which with Windows is my primary OS. Contests notwithstanding, I'm going to look at some TASS images with it and see what I can see. I'll probably snatch Richmond's reduced GSC and integrate it into this program if I can. The program also does some blink comparisions between images. So, I'd like to get some successive TASS image files and see what this does with them.
Arne Henden
aah@nofs.navy.mil
Feb 14, 1997
Jure started a discussion regarding possible output file formats for image analysis software, and I just wanted to pass on some comments.
While I am highly in favor of FITS for handling the images, I am less favorable towards using FITS tables for ASCII data. Sure, IRAF with the STSDAS extensions can read them, but in most cases I want to use the ascii data for input into small data analysis programs (plotting packages, matching programs, etc.), or edit them with a system editor like vi or DOS-edit. To me, if the output is ascii, it is easier just to have a pure ascii file rather than adding the complexity of FITS overhead.
I would recommend including the following information in the TASS output (based on the values we have found necessary with the FASTT telescope):
1 ... camera location flag
2 ... CCD frame in yymmddfc.xxx format (f,c are filter,camera)
3 ... date of observation (julian format)
4 ... UT time of observation in hours
5 ... CCD x position
6 ... CCD y position
7 ... fwhm in x
8 ... fwhm in y
9 ... peak DN in image
10 ... total DN in image
11 ... total DN in sky under image
12 ... conditions flag
Note: this is the first extraction from the raw FITS files.
The camera location flag will uniquely identify the source of the data for
those programs combining data from several locations. It also can be used in
conjunction with the date and time to determine the sidereal time of the
observation if the pointing directions of the cameras are known. The CCD x,y
are (as noted by Jure) used for checking any systematic differences in the
reduction of images trailed through different parts of the system, and are
of course the raw input to astrometry. The fwhm in x and y can tell you
whether an object is stellar, blended, fuzzy like a galaxy or trailed like an
asteroid. The peak Digital Number and the two totals tell you fundamental
information regarding the photometry. The conditions flag tells you about
the quality of the night (photometric or not, good seeing, etc.).
The camera location flag is used in a lookup table to obtain latitude, longitude, engineering parameters, etc. for a specific site.
Our second (intermediate) output file is used after an astrometric and photometric solution is made, and includes the extra fields RA (J2000), DEC (J2000), standard magnitude, and solution errors in RA, DEC, magnitude.
Our final output file is the combined results from many scans, and includes the fields:
1 ... internal star designation 2 ... mean J2000 RA in hours 3 ... mean J2000 DEC in degrees 4 ... mean V magnitude 5 ... mean V-I color 6 ... number of observations used to compute RA 7 ... number of observations used to compute DEC 8 ... number of observations used to compute V 9 ... number of observations used to compute V-I 10 ... mean error in RA (sigma*cosD) in arcsec 11 ... mean error in DEC in arcsec 12 ... mean error in V 13 ... mean error in V-I 14 ... mean epoch for the RA 15 ... mean epoch for the DECNote that this output format won't handle moving objects well, except that they can show up as objects with large RA,DEC errors. Variable objects are easily identified by looking at the mean error in the magnitudes, and then we look back in the second (intermediate) file to obtain the date/time magnitude data for period searching.
I hope this listing of what we find important for our use is helpful in determining your file formats.
Nick Beser
beser@aplcomm.jhuapl.edu
Feb 14, 1997
I am passing along a message from Marty Pittinger to you concerning hardware and systems debugging issues. We have been running the APL/TASS Observatory as a large project, with people who are primarily interested in telescope/observatory design and operation setting up the Observatory and checking out the camera, and people who are data and image analysts working up software and procedures, and processing the data that the operations guys have collected. I think you should treat Marty's e-mail as a reminder, that while the analysts among us have been sharing the ideas, software and results, the guys who have setup the camera and have run into unusual problems have not communicated as well. We have made great strides in understanding the care and feeding of a TASS Triplet. However, in the past, when there is a e-mail message describing a problem, it is buried under many times that amount of analysis type messages. It would be very useful for the people who have actually setup the TASS camera's to document the problems that they ran into, or at least subscribe to a sublist that will focus on those problems.
----Message From Marty Pittinger--------
Tom,
We've been working with Nick on the TASS #5 triplet since early December. We are nearing that goal, having TASS #5 perfectly focused and aligned. We appreciate all the work he has done, especially in image processing and file archiving. Without him we would still be struggling with our unit. We would like to participate, but we're not quit ready yet, maybe by the end of March.
Having seen the great TASS images from others, as driven us to succeed. We have had to overcome: bad weather, material problems, no time to work on TASS, software incompatibilities and the lack of documented guides/troubleshooting. (I'm sure everyone had these problems somewhere along the way). From our "First Light" image, we have pushed to get TASS #5 online and it's images accessible.
Tom, we continue to make progress towards these goals, but please keep the troops in the trenches in mind when you pick through the mail bag. I would like to know we are not alone when it comes to hardware and system problems. Would you consider splitting you listserv into "Programmers / Technicians" and put me in the technician pile?
Thanks,
Marty Pittinger, President
APL Amateur Astronomy Club
JHU/APL Laurel, Maryland
Glenn Gombert
ggombert@infinet.com
Feb 14, 1997
I have uploaded to Storm another example of photometry using the Sextractor program. I have also uploaded another test image M67v.fit which was taken with the SBIG ST-6 of the standard "M67" calibration area. The image is taken with a "V" filter in front of the ST-6. The output catalog produced is M67v.cat, the reference star magnitudes (in the V-Band) in the image are taken from the AAVSO standard calibration chart that was supplied by Dr. Mattei.
As can be seen from the calcualtions the output is within the +/-5% range that we need for measuring TASS images. If Arnie could supply us with a list of "standard" stars this would help to calibrate our images photometrically in the +/- 3 degree declination are that present TASS cameras operate.
PS. If anyone would like a copy of the M67 calibration chart I would be glad to supply it :-)
Glenn Gombert
ggombert@infinet.com
Feb 15, 1997
Marty, Nick;
Don't get discouraged over the "learning curve" in setting up and operating at TASS camera. Before Tom sent me Serial #1 to operate here in Dayton, I have spent 4-5 years doing convential ccd imaging with several Newtonian's and my ST-6 and it still took the better part of two month's to "get the hang" of setting up the Mark III here in Dayton. Don't be "shy" about asking questions!
Holler if we can help, those who have currently operate Mark III camera's all have gone throught the same "learning-curve"..
Herb Johnson
hjohnson@pluto.njcc.com
Feb 15, 1997
Summary: Some camera owners suggest seperate maillist communications on camera issues. I make some related suggestions: encourage Tech Notes on the Web site, use the maillist with some discretion. - Herb
Nicholas Beser
I suppose another solution would be simply a cc: list to TASS camera
holders and to the maillist. Are there that many out there? But I think
the "analysts" should be aware of "technical" problems so fixes can
be incorporated into software when appropriate. For that matter, while
I don't have a camera, I have worked on one and I'm (apparently) one
of the few electrical engineers on the list. I am sympathetic to the
sense of "being alone" among the large volume of software and systems
discussions that occur, but I don't think that is intentional on anyone's
part. But seperate lists may not be the best all-around solution.
We must keep in mind we share a common goal, even as we have different
skills and priorities. It helps me when I see "progress reports" posted,
summaries of results and problems, written for our general audience.
Hopefully they can be accumulated on the Web page for subsequent reference.
Conversely, as I've said before, messages that are highly detailed and for
a *very small* audience may best be handled via private email, followed by
a *public* summary or resolution for the general audience. Rule of thumb:
if a thread only have two-three participants, take it private and post
the RESOLUTION. This may well have happened already.
A reality check: what *are* these camera problems? Have you resolved them?
Have you offered problems and resolutions as "tech notes" to Richmond's
TASS Web site for future reference? It's easy to talk about problems,
harder to document them *and* their resolution, especially after the
problem is solved. But most of us would like to READ such notes, especially
if we have a problem in hand. You could post open problems as such:
just update the Web site when it's resolved.
Hope these suggestions are helpful. Bottom line would seem to be: make
"better" use of both Web site and maillist, and provide some tech notes
on camera setup and use to the Web site as both a resource and an
encouragement.
This also appears as
Technical Note 24
Herbert Johnson suggested that we summarize some of the hardware
problems that we have run into with TASS #5. The following is not a
complete list (that means I drew it from my memory):
Cooling Problems:
Our mount is about 14 feet above the observing room on the roof of
Building 40 (JHU/APL Complex in Laurel, MD). The facilities engineers
specified 1/2 inch tubing to go from the water tank to the roof, hook
into the camera and then 1/2 inch pipe coming down from the roof. We
noticed that the water flow was not very large due to the decrease in
diameter at the camera. This was fixed by threading a 1/4 inch tube
through the 1/2 tube up to the camera.
Water pump (submersible sump pump) was heating the water to about 95
degrees F, and needed to be primed before it would work. Solution: A
motorized external pump (rotory design) was substituted). The water flow
is about 1 Gal per minute. Water temperature is slightly below room
temperature. A mix of environmentally safe antifreeze was added to the
water to keep the water from freezing in the event of a power failure.
Housing Problems:
The housing was initially pointed to -10 degrees declination. This was
later adjusted to 0 degrees.
The camera was mounted too far forward in the box, so that the focus
adjustment had no room for the telephoto lens to come out farther. The
camera was slid back slightly. Note that we have optical windows in our
system that keeps the lens from moving too far out.
Remote control of the doors seemed to effect the control hardware of the
camera (ie The data collection could not happen when the doors were
being opened). Solution was to take dark current files, and then shut
software off, and open the doors. There seems to be some electrical
noise in the system (we have solved that by procedure rather than
design). The door control is also being modified so that the html home
page control of the telescope will control the powering on of the TEC
and opening/closing the doors.
This last one was wierd. We share the roof with some radar dishes. The
people doing some installation up there tied a crane to the railing
(same one where the telescope was mounted on). The wind (blowing the
crain) was causing visible motion effects on the data. Solution (the
crane tie down has been moved)
Telescope Control and Data Issues:
Twice our data collection has gone over to pre-dawn hours (about 5-6am.)
The data files indicate that the ambient light levels are too high to
continue recording stars. At the end of the run, the sensors completely
saturate including the dark current pixels on each line, and the
temperature gauges indicated a sudden shift in temperature. The program
eventually shuts down when it indicates a temperature of 135 C. The
temperature does not really happen, it seems to be a controller failure
brought on by the saturated system. (NOTE: At no time has our camer
viewed the sun).
Alignment and Focus of the camera reminds me of the problems I had
converging a color monitor (ie. I can never get a color monitor
converged). We have seen the following problems:
Alignment setting is not smooth, ie. it sticks and then overshoots the
setting. (Need coarse and fine adjustment) I know it has silicon greese.
I know it also sticks and then shoots past the setting.
VCO setting seems unstable. A camera that seems to be completely
aligned, in focus suddenly exhibits the symptoms of VCO setting errors.
We currently have CCD2 higher by 1 degree than CCD1 and CCD0. CCD2 and
CCD0 both need alignment adjustment. It is also possible that the VCO
may not be correct for these two camera, however, it seems correct for
camera CCD1. We are still investigating this problem.
We are still slightly out of focus. (Focus is very close on CCD1, and
can be improved on CCD0 and CCD2)
Saturated pixels on one camera become visible on the other cameras. We
have seen examples (Mars images) that have the specular pattern repeated
on the other cameras. This is a design issue, and there is nothing we
can
do about it.
Current Status:
Our primary problem right now is that the weather in Baltimore has been
very cloudy since Feb 9 (the last observation session). We have worked
up a way of turning on the TEC power remotely (so that we can have it on
1 hour before we start observing). We also can open the doors remotely
(we need to wire that in). This is being done by X-10 remote control
devices under control of a unix workstation. I also have a RPC program
that may run under windows 95, and can be used to cause the TASS data
collection machine to start collecting data remotely by rebooting itself
in MSDOS mode, running tm3get11 and then when it ends, come up in
Windows mode with a FTP server operating. We really would like to get
our hands on a linux version of TM3GET11. We also are investigating
workarounds (There is a patch just announce for the linux kernal that
will enable real time control interrupts.)
More after Marty and Bernie have a chance to look at this.
I've uploaded a file showing typical TASS astrometric errors to the
incoming directory on storm.fnal.gov. The file,
matched.txt
shows the
residual errors I got when matching a TASS image with the SAO catalog using
Michael Richmond's matching program.
In brief the standard deviation was 0.12 pixels in RA and and 0.19 pixels
in Dec. Some of the difference between RA and Dec is due to the incomplete
solution Michael's program used since it used only the 20 brightest stars
from the subset of the SAO catalog I used while there were 75 SAO stars in
the image. Analyzing the residual errors implies that the Dec standard
deviation could be reduced to 0.17 pixels.
Also included are errors between the calculated magnitude and the SAO
magnitude. The standard deviation for magnitude was 0.62 mag. Not
unexpected since the image was taken with the "I" filter and the SAO
magnitudes are either photometric or visual.
This is very good stuff, speaking as a hardware/software person. It would
seem that oversaturated pixels have a profound effect on the TASS Mark III
system, even between cameras! If this effect can be duplicated "on the bench"
it can be diagnosed. The other items mentioned are good operational issues.
I hope Nicholas et al will, after some offline or online discussion, write
this list up as a Tech Note. Even unresolved issues are a "flag" for other
sites to consider.
To the extent I can be helpful, I'll privately email Nicholas on this stuff.
I don't have a camera on hand so my inputs are limited.
So far, I have only received a few messages from people who want to
enter "The Contest". But I am undaunted.
I am thinking of changing the rules from a tass camera owners contest
to a contest everyone can enter. The prize would go to the best production
software that turned TASS images into star measurement lists. I would then
put blocks of data up on the net for practice and anyone could enter. There
would be a number of things to be judged for "best". These would include
things like ease of use, availability of the platform used, accuracy of
the results, included tools, etc..
What do you all think?
Nick and all,
Thanks for sharing the various problems. I often would rather hear of
problems and their solutions than to see great pictures or data. It
helps a lot on future designs.
It may be that the 0.916 line time is not the best one. I did some work
on this the other night and found a different number was better. I will
present this in a day or two. This just means that the lenses are not
exactly 135 mm in focal length. I would not expect them to be correct
to better than a few percent. If they do not match, then we are out of
luck to the extent of the match.
The operating scheme sounds neat. Some day we will get some clear skys.
Then we will all get some data.
Tom, myself, and now Nick have noticed that it's harder to get nice,
sharp images in the I-band images than in the V-band. Tom wonders
I hope that the observers who are currently getting lots of data
can provide more information here. There are good fields for
comparison with standard V,I magnitudes in
Another guess is that the lenses on current TASS cameras just
don't focus light well at wavelengths as long as I-band (around
8000 Angstroms = 800 nm). I _hope_ that's the problem, because
one might simply try a more expensive lens...
Oh, and you may recall that I was planning to make an observing
run this past weekend. Well, the weather may or may not have
been good -- I haven't the faintest idea, because I was flat on
my back with the flu. I hope to recover before Mardi Gras
(and no, I'm not really joking :-(
I have not commented on Tom idea of a contest so far before I was
trying to win another contest I have with myself ( I should
win this one, but I don't know when ) :-)
The way I see it is that Tom has long finished building all his
cameras, and that he also see very little coming out of it so far.
This is normal since this is not a large project with 30 full
time programmers, but it is also normal to get anxious, and to be
willing to see something coming out of it before the Mark VI comes
on line...
My european point of view ( I guess most of the readers of this list
are americans ) is that the idea of the contest is a way to speed up
the process and get nearer to the point where TASS will produce useful
results. The idea of a contest, with something to win, I appreciate
as mostly a cultural difference ( i.e. I found the idea a bit bizarre,
but understand why most people would consider it normal ).
If it can reach its goal, then I have no problem with it.
I guess we are now in the boring stage. Building new equipment is
always exciting, making new discoveries is also very exciting, and
the in between phase, were everything must be tested, making sure
it can achieve its goal, writing all the required software is much
less exciting time. But it is required. Maybe the winners of the
contests will be everyone, because TASS will be in a position to
produce data.
I must confess I haven't read thoroughly the technical messages on
the list since a long time, knowing that the people in charge will do
the right job ( and it is a complicated one ).
As some of you may know, I am mostly interested in asteroids so far.
The only positive comment I can make is that we are porting our
asteroid detection code on PC. We use sextractor 1.2 on a Unix
workstation and it works great ( it can digest a 122 megabytes scan
in less than 7 minutes on a quad processor Sun workstation ). Glenn
Gombert has done two successive ports of this program on a PC. We have
a matching program which takes 3 catalogs coming from scans of the same
regions, find asteroid candidates, let you blink them on the screen
to confirm or reject the candidates, and performs the final astrometric
reduction. It is likely that when it will be stable enough, we will
put it as freeware somewhere.
Also, I would like to point out AVE, a remarkable Windows program which
takes variable star data and let you find periods, with very nice
displays and the like at :
http://www.gea.cesca.es/~rbarb/aveint.html
It was written by the GEA, a spanish group who has some serious
interest in variable stars ( they have discovered 30 new variable stars
in 2 years, this is nothing compared to TASS of course, but is already
quite an achievment already ). Their link is quite slow, but the program
is worth the wait ( maybe we should find a copy of it on Mike's site ?? )
Ask Rafael Barbera about this ?? )
Also, the last version of QMIPS32 ( v1.8 ) has a lot of very interesting
routines to perform automated astrometry and photometry. Up to you
to look at it.
Wonderful comet isn't it ?
M. Richmond wrote:
I am a little confused. Looking at the images in TN0019, the V-band
images are far worse than the I-band. They show lots of coma. The
I-band images look, from these poorly reproduced frames, much cleaner.
Am I missing something? The V-band images will probably look ratty
because you don't have a red blocker. The I-band images will most
likely be poor because that is outside the normal range these lenses are
spec'd. Does the focus change in the right sense (to match the IR-marking
on the lenses)? Does the psf change depending on the radial distance in
the field...that is, can you ever get sharp images at the center? Does
the psf have an obvious shape, such as astigmatism or coma? Can you stop
the lens down and see if that makes an improvement in the image sharpness
(sacrificing light while improving optical quality)? If someone has additional
filters, such as R and perhaps something halfway inbetween R and I, it would
be very useful to get data taken through them as well to see if the change
in image shape is consistent with wavelength. You may have to switch to V & R
instead of V & I if the focus cannot be adjusted properly at I.
Before you can say that your V,I system closely matches the Johnson/Cousins,
you need to take some data in a standard field where you get a wide range
in color (yet well-exposed in your frames), especially including stars with
large (V-I) such as in SA111.
Meanwhile, with the nice weather in the Northeast, I am looking at building
my permanent observatory in my backyard. I have a modest GEM mount and an old
10-inch I can put on it. The mount is incomplete, and I need a building
to wrap around it. But the mount is in place and very roughly aligned.
Other options are available, and I have potential sites for a TASS
camera in a number of NJ locations near and far.
Herbert R Johnson wrote:
I posted something yesterday that I did not see on the TASS mail list.
basically I said that I thought the VCO (or scan rate) should match
the image scale not the focal lenght. I said that focus error effects
image scale.
I have to retract that posting.
I still think it is technically correct but the effect is very small
for distant objects. Now in the case of stars within say, 1/2 meter
of the lens, focus would have a huge effect on image scale but then
we'd have even bigger problems with cooling and saturated pixels :-(
I though I would put up the numbers I am getting from Norman's
focus table. The results below were taken with a clock period
of 0.9101 seconds. I do not guarantee that the stop watch is
that good. The period was adjusted for a minimum value for the
middle camera (V filter) down reading. The numbers were written
in the log by hand, so they are representative and do not indicate
that they were all taken at the same time.
Bernie removed the telescope to add a mount bar on the bottom (in order
to make alignment easier). He is also adding a photocell failsafe on the
remote doors to insure they will be closed by dawn. I expect the
telescope to be reinstalled by the end of the week. The earliest we will
be able to collect the numbers for you will be some time next week
(weather permitting).
Larry Marschall just sent this to me, and now I send it all to you:
Many amateur astronomers now have telescopes in the 0.2- to 0.5-meter range
equipped with professional-quality CCDs and powerful software. With plenty of
observing time, high-tech equipment, and a love of astronomy, a growing
number of amateurs are capable of doing first-class science. Yet few do
systematic research, and even fewer collaborate directly with professionals.
With the shutdown or imminent closing of many small national research
telescopes, caused by a reduction in funding for research, it is
difficult for many professionals to get the data they need.
This suggests the need to foster more
*> We have made great strides in understanding
*> the care and feeding of a TASS Triplet. However, in the past,
*> when there is a e-mail message describing a problem, it is buried under
*> many times that amount of analysis type messages. It would be
*> very useful for the people who have actually setup the TASS
*> camera's to document the problems that they ran into, or at least
*> subscribe to a sublist that will focus on those problems.
**> [quoting Marty]
**> Tom, we continue to make progress towards these
**> goals, but please keep the troops in the trenches in mind
**> when you pick through the mail bag. I would like to
**> know we are not alone when it comes to hardware and system
**> problems. Would you consider splitting you listserv into
**> "Programmers / Technicians" and put me in the
**> technician pile?
**>
**> Thanks,
**> Marty Pittinger, President
**> APL Amateur Astronomy Club
**> JHU/APL Laurel, Maryland
Tom and I had an online discussion of this sort a few months ago. We suggested
a set of keywords to put into the "subject" header, so people could
easily seperate messages by category. Nothing much came of it. Maybe this
idea should be revived? I myself can quickly look at a message and
decide its disposition, but of course this takes time and I limit my
email: your mileage may vary. Seems to me a subject header should
clearly represent the message therein. For long messages, a summary
at the beginning would be helpful too.
Nick Beser
beser@aplcomm.jhuapl.edu
Feb 15, 1997
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 17, 1997
Herb Johnson
hjohnson@pluto.njcc.com
Feb 16, 1997
*> Herbert Johnson suggested that we summarize some of the hardware
*> problems that we have run into with TASS #5. The following is not a
*> complete list (that means I drew it from my memory):
Tom Droege
droege@wwa.com
Feb 17, 1997
Tom Droege
droege@wwa.com
Feb 17, 1997
> Telescope Control and Data Issues:
> Twice our data collection has gone over to pre-dawn hours (about 5-6am.)
> The data files indicate that the ambient light levels are too high to
> continue recording stars. At the end of the run, the sensors completely
> saturate including the dark current pixels on each line, and the
> temperature gauges indicated a sudden shift in temperature. The program
> eventually shuts down when it indicates a temperature of 135 C. The
> temperature does not really happen, it seems to be a controller failure
> brought on by the saturated system. (NOTE: At no time has our camer
> viewed the sun).
This problem is well understood, and will be corrected on the next
design. (But not fixed on this one). I am using 5 volt multiplexer
chips on a system with op-amps that connect to +/- 15 volts. When there
are out of range conditions, the amplifiers can present more than 5 volts
to the multiplexer chips. In this case a big signal can "spill over" into
a different channel.
> Alignment and Focus of the camera reminds me of the problems I had
> converging a color monitor (ie. I can never get a color monitor
> converged). We have seen the following problems:
>
> Alignment setting is not smooth, ie. it sticks and then overshoots the
> setting. (Need coarse and fine adjustment) I know it has silicon greese.
> I know it also sticks and then shoots past the setting.
The idea here was that I was trying to build a simple and cheap system.
The rotation only has to be done once. I figure things done only once
can be a pain to adjust.
> VCO setting seems unstable. A camera that seems to be completely
> aligned, in focus suddenly exhibits the symptoms of VCO setting errors.
Yep. The VCO is marginal for this design. In my case, the computer is
in my basement which is pretty constant temperature. I just leave it
on all the time, or start it up several hours before I start a run. At
least mine seems stable to 1 part in 1000 when warmed up. This should
be good enough but not great.
> We currently have CCD2 higher by 1 degree than CCD1 and CCD0. CCD2 and
> CCD0 both need alignment adjustment. It is also possible that the VCO
> may not be correct for these two camera, however, it seems correct for
> camera CCD1. We are still investigating this problem.
I at least notice that the I filter data is pretty fuzzy compared to the
V now that I have things adjusted. This may be the result of there
being no IR block filter. I hope that Michael R., our filter expert,
will give this some thought. For me there is a point where adjustment
does no more good.
> Saturated pixels on one camera become visible on the other cameras. We
> have seen examples (Mars images) that have the specular pattern repeated
> on the other cameras. This is a design issue, and there is nothing we
> can do about it.
Yep, this is the problem above. I just hope this does not turn out to be
a big problem for data analysis.
Michael Richmond
richmond@astro.princeton.edu
Feb 17, 1997
> ... This may be the result of there
> being no IR block filter. I hope that Michael R., our filter expert,
> will give this some thought. For me there is a point where adjustment
> does no more good.
If the problem were caused by light on the long-wavelength
side of the I-band filter "leaking" through in our I-band images,
then I would expect the (V-I) colors of stars measured from TASS
images would not match the standard (V-I) colors very well.
However, the little comparison I've done (see Technote 19) shows
good agreement.
SA 101 centered on (2000) Right Ascension 9h 56m
SA 102 10h 56m
SA 103 11h 56m
(as well as other fields at roughly one hour intervals). I can
provide people with images of these fields with lists of standard
stars.
Alain Maury
maury@ocar01.obs-azur.FR
Feb 17, 1997
Arne Henden
aah@nofs.navy.mil
Feb 18, 1997
> Tom, myself, and now Nick have noticed that it's harder to get nice,
> sharp images in the I-band images than in the V-band. Tom wonders
Herb Johnson
hjohnson@pluto.njcc.com
Feb 18, 1997
*> Tom, myself, and now Nick have noticed that it's harder to get nice,
*> sharp images in the I-band images than in the V-band. Tom wonders
*>
*> Another guess is that the lenses on current TASS cameras just
*> don't focus light well at wavelengths as long as I-band (around
*> 8000 Angstroms = 800 nm). I _hope_ that's the problem, because
*> one might simply try a more expensive lens...
Camera lenses do have a signifigant focus shift for IR, as I recall.
Some older cameras are marked for this difference, for the use of IR
sensitive film. The "solution" is to change focus with film, or in
this case with filters. The "not as well" part I can't comment on,
except generically that a set of lenses are optimized for a small number
of frequencies, with nonvisible ones given "lower priority".
Herb Johnson
hjohnson@pluto.njcc.com
Feb 18, 1997
*> This problem is well understood, and will be corrected on the next
*> design. (But not fixed on this one). I am using 5 volt multiplexer
*> chips on a system with op-amps that connect to +/- 15 volts. When there
*> are out of range conditions, the amplifiers can present more than 5 volts
*> to the multiplexer chips. In this case a big signal can "spill over" into
*> a different channel.
Can the outputs be bridged with zener diodes and regular diodes for positive
and negative overruns, respectively? I recall 5.1 volt zeners are
an available value.
*>> VCO setting seems unstable. A camera that seems to be completely
*>> aligned, in focus suddenly exhibits the symptoms of VCO setting errors.
*>
*> Yep. The VCO is marginal for this design. In my case, the computer is
*> in my basement which is pretty constant temperature. I just leave it
I've heard of a fix for temperature stability of crystals: namely,
a thermisitor in contact with the crystal which draws a current. Temperature
changes will change the current draw in the thermistor, which will act
against the temperature change. I don't recall if you need a positive or
negative coefficient thermistor on this. I've also heard of incadenscent (sic)
bulbs used for temperature/current stabilization.
*> It may be that the 0.916 line time is not the best one. I did some work
*> on this the other night and found a different number was better. I will
*> present this in a day or two. This just means that the lenses are not
*> exactly 135 mm in focal length. I would not expect them to be correct
*> to better than a few percent. If they do not match, then we are out of
*> luck to the extent of the match.
This is an interesting point: different lenses requireing different scan
rates. Running three camera at three scan rates would be too complicated.
But there is likely some least offensive value for each triplet.
Herb Johnson
hjohnson@pluto.njcc.com
Feb 18, 1997
*> I'm thinking of changing the rules from a tass camera owners contest
*> to a contest everyone can enter. The prize would go to the best production
*> software that turned TASS images into star measurement lists. I would then
*> put blocks of data up on the net for practice and anyone could enter. There
*> would be a number of things to be judged for "best". These would include
*> things like ease of use, availability of the platform used, accuracy of
*> the results, included tools, etc..
*>
*> What do you all think?
I'll be interested in working with the data, but I've decided my interests
are primarily in asteroids. I'll be curious as to what others do with the
same data. I hope you have some consecutive days's data for comparisions.
I'm going to start with some subtractive comparisons and look for shifts
and changes: maybe some variables will fall out of this. And I'll spend
some time on the various TASS Web sites to see what has been done. I'll
be using Windows and MS-DOS based tools, simply for my own convenience.
I have Linux 1.2.13 and can use it, but I want to get my hands in the data
and not with configuring a Linux system. When I've mucked around enough
to know something I'll get better or smarter tools.
Chris Albertson
chrisa@wavenet.com
Feb 18, 1997
> Camera lenses do have a signifigant focus shift for IR, as I recall.
> Some older cameras are marked for this difference, for the use of IR
> sensitive film.
Yes there is a "focus shift" but a better way to describe it for our
purposes (drift scan imaging) is that
the lens' focal lenght is a function of wavelenght. Could it be that
the VCO (scan rate) has been tuned by eye, using the V-band as a
reference?
If so, and if the V and I lenses are both at thier optimal focus
the I-band image should trail. Trail by enough to see? I don't
know.
Tom Droege
droege@wwa.com
Feb 18, 1997
E (I) M (V) W (I)
Left 1.78 1.40 1.68
Down Left 1.35 1.28 1.57
Down 2.18 1.49 2.21
Down Right 1.43 1.29 1.54
Right 1.65 1.39 1.68
What do others see for these focus numbers?
Nick Beser
beser@aplcomm.jhuapl.edu
Feb 19, 1997
Michael Richmond
richmond@astro.princeton.edu
Feb 19, 1997
-------------------------------------------------------------------
AAS TO HOLD SESSION ON AMATEUR/PROFESSIONAL RESEARCH COLLABORATION