Results of June 10 pointing tests

The points on this graph represent encoder errors vs. position on the sky. Dave and Bill did 4 sky maps using the benchmark 16-star pattern, with stars separated by about 30 degrees. The "skymap" program acquires the RPR error at a star, along with the refracted apparent catalog coordinates. The program also records the APE reading at each star. The plots are for the declination encoder error for both the RPR (top) and the APE (bottom).

The RPR error is simply the difference between the current declination RPR reading and the apparent refracted catalog position of the current star centered on the crosshairs. The APE error is similar; the apparent refracted declination coordinate minus the APE reading when on the star.

The X-axis represents the sequence number in the sky map, not declination degrees. Hour angle as well as declination changes during the sky map. As many as 8 points are plotted for each sequence number, four for RPR and four for APE. (Stars were not always available at a particular point in the map.)

The plots are sort of sinusoidal due to the pointing error surface, which represents the way the encoder error changes over the sky for an axis due to flexure and other causes.

No new pointing surface was computed or used from this data set; the purpose was only to check the repeatability of the encoders.

There is obviously a much greater degree of scatter of the RPR points compared to the APE points. The telescope returns to the same part of the sky within a few arcseconds for the APE, but the repeated position as indicated by the RPR differs by up to about a minute of arc at some sequence numbers.

Note that stars are drifting through the HA/DEC sky map as time goes by. Thus, the telescope doesn't return to the same star on successive runs, but to a star within an acquisition circle of about 3 1/2 degrees. Sometimes, there is no FK5 star in this circle so the point is skipped. The pointing shouldn't change by more than a few arceseconds over three degrees, so encoder error values in successive runs should correspond quite closely but not exactly.

These data are highly significant in that they tell us that the mechanical and optical assemblies of the telescope are not the source of the pointing problems, at least insofar as the declination APE indicates. Everything included from the optical axis of the primary/secondary out to the declination APE can't be creating significant pointing hysteresis.

The RPR is the position reference for the telescope drive. The large scatter in RPR data shows that the pointing problem is contained in the RPR or associated components or related software. We would actually be better off right now using the APEs as our primary position reference, except that the HA APE has an electronic defect whereby a periodic error in the readout occurs of about 15 or more arcseconds. This periodic error is quite visible by watching the RA console display, which rolls while the telescope is tracking on a supposedly constant RA position.

So why is the relative position register for declination so unreliable? Here are some ideas:

1. Software? The computer never updates the RPR. Scatter in the RPR readings at the same relative position in the sky can only be hardware-related. The software is supposed to correct for encoder slippage and inaccuracies in the incremental encoder ratio. These corrections are included in the overall pointing correction and software problems here will cause inaccurate slews, but not RPR scatter.
2. The surface on which the declination encoder roller rides may have oil in places, or gouges/nicks/scratches. Anything like this would shift the position reference every time the encoder roller passes over or through the contaminated region.
3. There may be defects in the yoke support of the declination axis and telescope tube outside of the declination servo loop. If the pointing error correlates highly with hour angle, this could well be the cause. (I was seeing signs of this in a previous pointing run; more on this below.)
4. The digital servo control electronics could be dropping pulses or injecting noise pulses. Or, the incremental encoder could be putting out a poorly shaped waveform, causing displacement pulses to be dropped or injected. Usually, when something like this happens, a huge change is noted and the problem is immediately apparent.

George is going to arrange for a simplified daytime verification of these results. Using primitive Super Tech program commands, the telescope will be slewed in a 30 degree square pattern about the zenith, repeating the pattern four times. No pointing corrections or other on-line software will be involved. George will record the declination APE position and APE-RPR difference at each point of the pattern.

Pointing tests done earlier (my e-mail to the staff of 5/19/98) showed a uniform change of declination hysteresis error with hour angle, something that seems most likely to be caused by software. (Hysteresis error should be random.) When I tried software changes that greatly reduced the error for that particular test, the changes when applied to other data sets made things a lot worse. I couldn't find a software scenario that worked for everything. I still think software may be involved, and this next test may again point to software, or absolve it.

While George is arranging for the test, I am going to repeat this analysis for the hour angle axis. Our experience is that declination pointing is a lot worse than hour angle. If the hour angle plots turn out similiar to the declination plots, perhaps the scatter in RPR data compared to APE data is an artifact of repeating the sky map pattern over and over, and may be the result of normal slippage and change in the incremental encoder ratio (displacement counts per arcsecond).