In addition, there is another chronological consideration: the estimate
of time of observation presumes some rate of drift scan, which is ultimately
based on the VCO frequency or the "row shift rate" (typically .914 seconds per row)
which appears to vary. I include discussion of those considerations. For reference, the
total exposure time of each Mark III row in drift scan is the scan rate times the length
of the column, or 512 pixels X .914 seconds, or 7.8 minutes. As these issues
were unresolved in Aug 1999, and whereas the discussion reveals
some important program operating parameters, I simply report
the discussion then, with updates as they occur, and offer some of my conclusions.
Where I provide quotes, my comments to those quotes are encased within square brackets.
Additional information may be found in my Tech Note #57 TASS Mark III database: software and datasets by site. My thanks in particular to Arne A. Henden for his encouragments and discussions on determining times of observation.
Every Mark III image file has a FITS header with a date and (usually) a
time "stamp". This should mark the chronological start of data collection, but....
The following are some details on that time stamp and considerations by
various TASS members.
In a TASS maillist message of July 1999, Arne noted:
"Herb - the FITS standard DATE-OBS and UT/TIME-OBS keywords
are given in UT with specific format. For extracted
data, the traditional publication time is given in
Heliocentric Julian Date, or HJD, with a decimal
day fraction equal to the precision of the measurement.
For TASS, since the exposures are ~8min in length,[the time a star
drifts across
the CCD array,] a day fraction to the nearest 0.001day [86 seconds]
is quite adequate."
"Also, note that my program suite [see "software programs" in the other TN] gives HJD (Heliocentric Julian Date) as its output, applying the heliocentric time correction. Again, since this can amount to an 8-minute time error [the difference between heliocentric and geocentric time], has it been applied to the Star output?"
Arne, as well as Chris Albertson, also noted the following (quoting Arne):
"Note that for the Mark III and its fixed-position cameras,
you can actually determine UT from the date and astrometry,
if you know the latitude/longitude of the site and the
direction to which the cameras are pointed. I leave it
to the reader to figure out how to apply such corrections
to the tenxcat database!"
Michael Gutzwiller said in response:
"There was no heliocentric time correction applied [to my data]
but I doubt it's much more
significant than the accuracy of the PC's clock. A typical star can be
observed by a Mark III camera for a stretch of about 120 days since it must
cross the meridian to be observed. This implies about 4 minutes of range
for the heliocentric correction. This is also smaller than the 8 minute
exposure time. Except for extreme cases I doubt this is significant.We
can still correct for it fairly easily though."
Says Arne:
"Mike, I think the number is more like 150 degrees since you
lose an hour on each end of sunset/sunrise, or 30 degrees.
Plus, it is 8min light travel from earth to sun, so close
to 16min across the entire orbit. The correction is not minor
and needs to be included."
"However, equally important is the PC clock. I harped on this subject early on. Some observers forgot to reset their clock on daylight savings change and so the header times could be an hour off in addition to the often many minute error within the hour. When you are working with Miras, such errors are insignificant. When you are working with a 6-hour eclipsing binary, they increase the scatter you find for the light curve."
"Even though exposures are close to 8mins, remember that the exposure time is for the midpoint and that is well defined. You don't want errors anywhere close to the exposure length. Like I've said, time is one measured quantity that you have almost total control over and should be recorded as accurately as you can."
Tom Droege said:
"OK, I know that I have not been as good as I should about setting [my] PC's
time while taking Mark III data. Several runs were an hour off due to DST
changes.... Still, once you have either the Mark III or the Mark IV lined up,
and know
where it is pointing in the case of the Mark III or know the position of
the limit switch in the Mark IV, one can get the time whenever a star is
found. ...Compared to other things computed, this is no big deal.
"One only has to know the time accurately once, and mark that frame in the case of the Mark IIIs to know the accurate time forever after (until one bumps the mount)....I think the software should save me and figure out the time and where I am pointing."
As for the accuracy of the PC clock itself, the following is from private correspondence, July 26 1999 with Nick Besler as regarding their time references for post Nov 98 data:
"Chris and I rigged up a method for the linux system to periodically interrogate another system to update the clock. Every minute, the data collection computer runs a cron job (runs rdate against a host that has an accurate clock). The real time linux has a tendency to drift in time, and rdate resets the clock every minute."
There was also casual discussion of the tendency of a PC's time of day clock to drift over the course of time. That drift is known to depend on temperature and the condition of the PC's CMOS battery (which also operates the TOD clock chip). In December 1999, Chris said in the TASS maillist: "With PC clocks (DOS, Windows or Linux) you do need to use some method to keep them sync'd to some kind of standard. They can drift as much as minutes per day. On my system this is automated and the eror is << 1 second but on the DOS based systems automation is not possible and I'll bet sometimes people forget to set the system clock each night before making an obervation run and even if set could drift over an eight hour run....I'd treat most of the Mark III data as being +/- "a few minutes".
Time and these issues are revisited often in the TASS maillist.
In later TASS discussion, Arne and Chris said in December 1999 regarding
Mark IV driver development:
[Chris says:] "[As] Arne says "start of exposure" is a convention [to time stamp the image file], so that's what I'll use in the [Mark IV] FITS image files. I think the database should contain the heliocentric time of the mid-exposure so a conversion will be required at some point in the pipeline."
[Arne replies:] "Usually the heliocentric correction occurs after the astrometry step has been performed. This is fairly early on with Star, but might be a couple of steps later with other reduction packages. Note also that there are several time-based corrections if you want the most accurate timing, along with proper setting of the PC clock as mentioned by Chris. Since these are all 'corrections', I don't think they should be in the raw fits header, but perhaps should be applied before adding observations to the database."
The following is quoted from the JHU/APL Web document VCO Test from October 29, 1998, at:
http://www.jhuapl.edu/APLastronomy/tassvcotest.html
"The JHU/APL Tass Observatory collected data last night as part of a VCO setting evaluation. A new version of the Linux Data Collection software was provided by Chris Albertson and installed on out data collection system. The new version prints out he data collection time interval. Since we are able to command the linux version from our solaris computer, we set up a series of vco setting commands, changing the vco setting every 15 minutes throughout the evening. Although there were problems around 3:00am (The Linux system seemed to be unable to fork a new process), sufficient data was collected through the normal operating region. Data collection began around 6:15pm. The VCO settings were changed at 7:00pm, and were programmed to change every 15 minutes until the last command at 5:00am. The vco settings studied were from 9700 to 10500. Due to the process failure, the last setting was 10340."
"The following are the measured average times for each VCO setting:
VCO Average TimeNote that all images were obtained prior to the VCO change (i.e. VCO was now stable and output image represents that VCO setting). All images are raw (no dark current and flat field correction)".
9700 0.972033
9720 0.971461
9740 0.968872
9760 0.965540
9780 0.965124
9800 0.962854
9820 0.959804
9840 0.958696
9860 0.957135
9880 0.95396
9900 0.95181
9920 0.950979
9940 0.948256
9960 0.94544
9980 0.944135
10000 0.942767
10020 0.939897
10040 0.937895
10060 0.936758
10080 0.934154
10100 0.931591
10120 0.930498
10140 0.928728
10160 0.926010
10180 0.924324
10200 0.922932
10220 0.920662
10240 0.918040
10260 0.916842
10280 0.914946
10300 0.912303
10320 0.910986
10340 0.908543"Note that the images included in this web page represent settings:
9700 First setting
10080 Best Setting for CCD 1 and CCD 2
10200 Best Setting for CCD 0
10280 Optimum Measured Interval
10340 Last Setting for run.
Analysis [again quoting Nick Beser]:
"TASS Tech Note 26, (General Considerations for Drift Scanning) suggest that an optimum interval for a telescope pointing at 0 degrees declination should be 0.91416. That corresponds to VCO setting 10280. As can be seen by the data, the performance is not optimum. One possible reason is that the alignment of all three cameras are not the same. CCD1 and CCD2 are slightly more out of alignment than CCD0. It is quite possible that by adjusting the vertical alignment of all three cameras, we can get them to perform at a high quality level at the same VCO setting. It remains to be seen if we should attempt to adjust all three cameras so that the measured time interval matches the target of 0.91416. During the next hands on session, the alignment will be adjusted, and then a sequence of VCO measures will be retaken."
[End of Beser quote]
1) A day of 86,000 seconds implies that by Arne's standard, a reasonable day fraction is 86 seconds. A PC can easily drift by this amount over days or weeks, mostly due to temperature shifts. In addition, a PC battery that is near discharge will often slow the time of day clock to the point where it loses MANY minutes a DAY. Finally, as noted, operator errors or neglect can cause a time offset of as much as an hour when DST is not corrected. In those extreme cases, however, the "star" program will not "find" a positional match between the image stars and the chosen section of the astrometric database [see "software notes"] and this may alert the operator to correct the time setting.
2) From my personal review of the "tm3get" source code version 1.1, the time/date stamp in the FITS header is set to the PC time just before the data files are first opened; followed by the writing of the FITS headers and then the first data reads. This is after the CCD is cleared and the first set of non-data reads (to stage the CCD pixels to the proper dark current). I also observed in this driver's code that the "row shift time" in the FITS header has a default setting of .916 seconds. It is otherwise reported as defined in the .rc file, or as commanded from the command line during camera operation. The same is true of the VCO setting, with default value 10250.
Verson 1.1 source code does not encode a running harware timer counter into the CCD line, as the Linux driver supposedly does.
3) From Dec 1999 TASS correspondence with Chris, he said: "[I looked] at the code in the Linux driver. I use the time the file is first created. I create the file just after the first scan line's last pixel comes off the ADC. I use a routine in the CFITSIO library to get the date from the system and format it correctly [for the FITS header]." An inspection of an image file produced in Oct 1998 by one use of the Linux driver, showed that the FITS header had a date stamp but no time stamp. Versions of the driver subsequent to that date (such as version 0.4 compiled Nov 11 1998, which produced the FITS header in this Tech Note) included a time stamp.
4) As for the use of Chris' Linux Mark III "VCO servo" program, while it affects the VCO setting in use, that change would not be noted in the FITS header of the image file. IF the Linux driver is also recording the VCO timing in pixel 0 of the image file, then that would record any VCO changes, intentional or otherwise. The "servo" program (that would record such information, see the Tech Note on Mark III software) is probably not in general use. NIck Beser's experiments with VCO settings and image results are mentioned in his section on his site's information; a specific Web page document is referenced.
5) Time can be set on a Mark III system in several ways, accuracy as follows (my thanks to my TASS colleagues for contributions and comments on this list):
I agree with my colleagues who say that the Mark III needs to maintain a time reference correct to within a few seconds. As the total row exposure time is about 84 seconds, errors of seconds of time ABSOLUTE would simply not be noticed. But if the VCO was slower or faster than recorded in the FITS header, the *accumulated* error in absolute time of observations by the end of the image run may be signifigant (I have not estimated the likely error, it's simply based on the row shift rate times the number of rows in the image).
In addition, I recommend that we document in the FITS header the relationship between the time stamp in the FITS header as the time of completion of the first exposure of the first row of image data; and insure that the MS-DOS and Linux programs record that time in the image FITS header. (Note: the previous version of this document implied the time of initial exposure, the Mark III drivers were simply not implemented that way.) And, if any timing data is recorded in the image columns, the FITS header should have comments to that effect, just as it has comments on the rest of the image column format.