The original NASA specification for pointing at the IRTF was ±1 arcsec over a 60-degree radius around the zenith. We needed to prove to NASA that the telescope was within specs.

When we were ready, Rich Capps, the Division Chief, came up to the IRTF to do a formal qualification pointing run. First, we did the standard sky map, which produced 0.9 arcs RMS fit on both axes, but that fit is to the same data that derived the correction coefficients, so it doesn't count as a performance figure. Therefore we did another sky map, using the coefficients just derived from the previous sky map to make the slew corrections, recording the setting errors for each slew. The RMS fit of the slew errors of about 130 stars was 1.1 arcsec for each axis over the whole sky above the 15 deg. horizon,, not just the 60 deg. cone at the zenith, and the champagne corks popped. This was plenty good enough for NASA. We had passed the qualifying test and NASA therefore paid for the telescope. We had a steady stream of observers who complemented us effusively for the excellent pointing and tracking of the new telescope.

The specification of tracking performance was 1 arcsec over an hour of tracking, and since the tracking correction is simply the rate of change of pointing correction, we were within that specification also.

For years, pointing runs would result in an RMS fit to the data set of anywhere between 0.9 and 1.5 arcs, with benchmarks in the 2 - 3 arcsec range. At times, of course, there were problems, such as the mirror shifting in its cell when crossing the meridian or an incremental encoder skipping counts because of its heater blanket not working. When a pointing run was demonstrating poorer than expected slewing, we would stop the sky map and investigate the problem. Once found and corrected, the telescope would be back to its usual RMS fit of about an arcsecond on each axis.

Following are some historical RMS pointing run values. Values earlier than these are in a printout folder at the IRTF. I should retrieve those to eventually include here, for posterity.

I believe the 10/94 run was the first with the MIM on the telescope.

The actual RMS values don't tell the whole story, though they do show the trend. When we do pointing benchmarks (I didn't include them here), the pointing errors are mostly double digit, as is the experience of the telescope operators during regular operation. It would seem that the surface fit analysis makes a heroic effort to stretch around bad points, but slews are not repeatable and don't match the equivalent slew during the pointing data acquisition sky map.

Non-repeatable slews or step changes in slew error are the main causes of bad pointing. The correction algorithm may be able to fit a data set moderately well, but if the slew error is not repeatable poor performance will result. If a structural or optics problem causes a step change in slew error, the data set can't be fit with our algorithm, which produces waves in the error surface propagating from the step.

In February 1996 we made a series of pointing benchmarks on the sky. When the errors of the four runs were overlaid on a plot, it was obvious that some of the slews were wildly off from the others. Before the run we noticed that a couple of the chopping secondary spider vanes were loose and floppy. When we repeated the same benchmarks with those vanes clamped to lengths of angle iron, the benchmark plots were normal. Since then, the crew has adjusted the tension on the spider vanes and further tests did not show the large errors previously seen. Nevertheless, Paul reports that the chopping secondary spider structure has been stressed beyond its limits and there are cracks around some of the attachment points. I don't trust that secondary, and doubt if it will ever be free of contributions to the pointing problem until it is rebuilt or replaced.

Only one or two pointing runs have been made with the new tip-tilt top end. Pointing results did not show noticeable improvement with that top end. Paul informs me that there are no written specifications or procedures for adjusting the vane tension on either of our secondary structures. The crew goes by their best judgement and experience.

Most of the mirror support problems that have been documented by Doug Toomey et. al. may well give rise to mirror alignment instabilities which would affect pointing. This includes mirror kickout, rocking on pieces of gravel, improper pressure in the air support causing the mirror to float or shift, improper edge support, and other effects. Without load cells it is difficult to know exactly how the mirror is restrained. Mirror support problems are quite likely to be contributing to the pointing error, since we don't see much improvement when switching top ends.

When doing pointing runs I now collect absolute position encoder readings at each star as well, so the incremental encoder positions can be compared to the absolute positions. There are drifts in the position index of the two readouts. I have had a difficult time characterizing the drifts. They are tantalizingly regular, but I haven't yet found a formula that would provide at least a reliable first order drift correction. Incremental encoder drift could cause pointing anomalies by changing with time or velocity, or just generally not being repeatable (for which there may be some evidence). The absolute position encoders are an order of magnitude coarser than the incremental encoders, so comparisons have to be statistical rather than direct.

I hope it is an unfortunate coincidence that we have not had an accurate pointing run since the MIM was installed. We need the MIM. Please, tell us the MIM is not at fault. At one time I was tempted to recommend that during some engineering time we go to the trouble of removing the MIM and associated equipment just to do a pointing run, to resolve once and for all if the telescope structure is overloaded by the MIM to the point of structure relaxation. Then, the problems with the chopping secondary spider were found, and the moving finger pointed away from MIM. However, besides the thousands of pounds of MIM + instruments on the back end, the Seurrier truss front end has MIM counterweights which may be distorting it beyond its design so that at certain places in the sky the optical axis may shift. Numerical engineering studies might help to resolve this.

Let's trade this one in on a new IRTF. Seriously, we need engineering expertise to address each of these points, and perhaps suggest other possibilities that I haven't thought of. Anyway, here are some thoughts on each of the issues addressed above.

A: Secondary structure:

I would recommend not putting remedial work into the chopping secondary, unless Paul thinks he can repair the overstress damage and bring the spider back up to spec. Otherwise, we should either replace the whole secondary with proper instruction from the design engineer as to adjusting the vanes, or retire it. The very constituency that needs to use the chopping secondary also usually needs good pointing/tracking, so we really need to do something with that spider, or explain to the community (MOWG? NASA?) why we aren't.

Up to now, tip-tilt time has been dedicated to high priority tip-tilt work, with very little time for pointing tests. If we are concerned about pointing, we will need to reserve at least a half night (not half of a half night) for pointing tests with the tip-tilt spider which will probably consist of repetitive benchmarks and special sky map patterns.

B. Mirror support

Work on this is progressing, and when Doug T. is satisfied that the mirror support is as good as it gets, and there are no rocks under the mirror or kickout, or sloshing of mercury, or shifting hold-downs, and load cells are installed and easily monitored, and Doug's graphs show excellent images all over the sky, then we can write off mirror support as a cause of pointing problems.

C. Incremental encoders

There are comprehensive tests I can do in the daytime to run tests of the incrementals vs. the APES. I should budget time on a trip to get as much data as I can and then continue analyzing it. I should focus on slew repeatability as well as encoder slippage. If we could get high resolution index marks on the bull gears it would help a lot to control index shift due to encoder slippage.

D. MIM

I don't want to say this, but if we really want to eliminate the MIM from consideration as a perpetrator, we should dismount it, remove all the associated counterweights, and do a full pointing run and benchmark. Then, remount it and do another pointing run for comparison. Sorry, but this should be considered. If MIM is contributing, we will have to either live with it or start a design project to correct it.

Jim Harwood (photo by Bill Golisch)