Figure 1
The CCD frame taken with the first set of tracking data. All the tracking is
automatic. The exposure time for this frame is ??? seconds.
The motors of the telescope are too inprecise to guide it correctly, because of which the star images on a CCD frame are irregular shapes, rather than dots as expected. For that reason, and when taken into account that new equipment is expensive, and currently unavailable, the decision was made to try to use the existing telescope setup and dynamicly correct the errors through a software solutions (using a computer).
Initially, the error seemed to be periodical, caused by the tracking motor which revolves with the period of around 4 minutes (which through a set of gears scales to 23h56' - a sideral day). If our assumption was right, the error would be periodical and have a period of around 4 minutes, which was yet to be determined. Until now, those errors were corrected manually, by tracking a guiding star in the searcher telescope and making the corrections through slowing down or accelerating the telescope's tracking (by pressing different buttons - effectively making it shift left or right relative to sky equator).
The initial idea was to record the buttons pressed during the manual
corrections (effectively taping the corrective shifts), and under the
assumption that the errors were periodical, make the computer repeat the
recorded sequence indefinitely thus making what the observer usually would
while hand-tracking (press the buttons for him).
Later, as the text following will show, we came to the conclusion that such
scheme is not optimal, and tried out another approach.
We wired the telescope to an IBM PC 286 computer used for tracking through the PC's parallel port, thus inserting it into the buttons-to-correction-motors chain. With this configuration, all observers input could be recorded in a file and later replay-ed. The software we've constructed works in such a way that it periodically checks if the observer presses the correction buttons (the period equals 1/18.2 seconds - standard PC timer tick), and if it detects the pressure it is written to a text file. This allows us to "play" the corrections on any other computer (thanks to fixed time interval the corrections are sampled).
Initially, we've recorded a 4 minutes period during which a star used for
guiding was kept in the cross-hairs. The first results showed an
improvement, but not as good as we'd like it to be [fig. 1].
Figure 1
The CCD frame taken with the first set of tracking data. All the tracking is
automatic. The exposure time for this frame is ??? seconds.
The second attempt was made in the direction to record more tracking serials
and have them averiged to filter out corrections of unperiodical errors.
After after averiging the tracking curves, and setting the trasholds to
provisional values (the calculated values did not prove fit) to filter out
the occasional, unperiodical errors which were recorded together with the
periodical ones [fig. 2]. The results we've gained using this method were
significantly better, even acceptable.
Figure 2
Effective periodicity of errors in tracking - we got this diagram by
adding together the recorded data of error corrections. Error corrections
are written in such way that 1 denotes positive move on the right ascension
coordinate, while -1 denotes negative move. When more curves are added
together, a graph like the one shown is got, which in shows the
effective number of observations in which a particular correction was applied
at a given time. Effectively, this curve can be thought of as the
chance the error in a particular point in time is indeed periodical. The
graph was split in two halves, to overcome the incapabilities of MS Excel
which was used for data visualization.
Following this success, Giovanni's group used the telescope with our
tracking correction software for a night, and their experience with it was
positive in the first part of the night, while the corrections showed to be
erratic during the late-night part of their observations. When analising the
cause of such behavior through recording another curve of errors in tracking
it the early morning, we've concluded that our solution of the
problem showed another one which went undetected before the application of
automatic tracking software - the electronics used to generate sinusoidals
for synchronious motors showed a behavior of generating different curves
depending on it's temperature. Further more, the telescope seemed to be out
of balance on some places, and thus having a different tracking curve
depending on the direction to which it was pointed.
We've fixed the first problem by placing a ventilator above the motor's
electronics to cool it off and keep the temperature more-less constant. The
curve after this adjustment is displayed in [fig. 3].
After placing the cooler, the situation (thermical stability) improved but
not enough for it to be useful (the error-correction curve still changed
depending on the outside temperature). Later, after further analysis, the disbalance problem was proven as
inexistant.
Figure 3
Effective periodicity of errors in tracking after the electronics cooler was
installed - we got this diagram by
adding together the recorded data of error corrections, the same way as
described in [fig. 2]. If compared to the [fig. 2] diagram, it is obvious
that this diagram strongly resembles the [fig. 2] diagram if shifted upwards
by y axes for two units. If we analise the behavior of the chart with
regards to time, it can be seen that the [fig. 3] graph is somewhat "streched"
which is the result of the fact that the slowing down and accelerating the
motor (which is used for correcting) are not of the same speed.
The graph was split in two halves, to overcome the incapabilities of MS Excel
which was used for data visualization.
We've turned to another direction - the idea we got was to use the large encoder which is usually used to get the relative telescope position and to measure the delays or early-comings of ticks. Since the encoder has ???? ticks, and it takes a sideral day to revolve, it's easy to calculate that a tick change is supposed to come every 8.4 seconds, and if it comes early, the telescope should be slowed down for a period of time, while if it is late, it should be accelerated. This method will be referred to as the "encoder tick error correcting method" in the following test.
For the method described in the previous paragraph to work, we've had to
assume the tics to come periodically, and to confirm that assumption we've
measured the delays/early-comings of ticks change.
As the graphs [fig. 4] showed, our assumption was wrong, since
the ticks showed a great deal of erratic behavior (like jumping over a
tick, and having a kind of periodical delays/early-comings). After further
analising the curves, the conclusion was made that they were unusable for
our purposes, thus making us give up on this method and reverting to the old
one. It is important to note that this method would have a chance to
succeed if the encoders were of higher quality.
Figure 4
The diagram given above shows the erratic behavior of the encoder. If the
encoder showed a normal, expected behavior, the upper curve would've been a
straight line on the x axes. For the problem to be worse, the diagram
doesn't show periodical errors [fig. 5], which prevents us to isolate true errors of
motion from the internal encoder errors. Each period is about 4 minutes
long, which equals the time needed for one revolution of the motor rotating
the telescope.
Figure 5
The diagram given above shows the non-periodicity of internal encoder
errors. This diagram is the visualization of the data recorded during manual
tracking, and, if the encoder had periodical errors the curve should have
all its minima and maxima aligned on the same y value, respectively. In this
diagram, three four minutes periods are shown.
After trying out the described methods, and considering other ways to improve the telescope tracking behavior, we've reached a consensus that the 4-minutes-period method is optimal for the Visnjan observatory telescope setup. According to our testings and experiments, to achieve further improvements, purchase of new, high quality, tracking hardware is necessary, although we leave a possibility to further improve the tracking by software. The reason we are in favor of hardware solution rather than pursuing the software one is that we consider the hardware as a long-term investment, while, as we concluded, the software solution is too dependent of many parameters to be stabile and feasable.
Paralelly, our group has created the software for automatic filter
switching, which was integrated into the tracking-corrections software (to
make it possible for a single computer to be used for both purposes). The
software was tested with a sample motor, and proved bug-free during the
testing period.
While the software was created rather easy, the step
motor used to rotate the filters showed to be too week to rotate them
without further use of gears. The problem is being worked of (by Petar
Radovan), and we expect the system to work after the hardware problems are
corrected.