Pointing

Blind all-sky pointing

  • 0.3 arcsec RMS (UA-98-01) [Note: the only official requirement we have]
  • 5 arcsec RMS (Suggested value for Lucifer commissioning??)

5 arcsec RMS is only valid when telescope structure is in thermal equiibrium. We have not yet implemented the pointing and collimation corrections to handle temperature gradients in the structure which may contribute an additional 10 arcsec RMS.

DSA: Will we be doing a new pointing model before the LUCIFER run? This will be important if we switch to using the strip encoders to point. Tom has this in the new build for MCS, but he should not deploy it until we are prepared to do a new pointing model. I expect the blind pointing need only be good enough to put the guide star on the AGw detector. Wouldn't 15 arcsecond be good enough?

Verification method

  • After correcting for thermal offset in the pointing kernel on one star, point to 30+ stars with a similar sampling of azimuth and elevation that would be used to produce a pointing model. Record departure of centroid from axis for each case and determine pointing statistics.

Test results

  • Date: Result/Data

Blind offset pointing

  • 0.1 arcsec RMS (UA-98-01)
  • No MCS overshoot (Need a more formal requirement) JMH: suggest dropping this as we only care about the final result, not the trajectory along the way. Do we want a timing requirement?

DSA: I think it would be a good idea to test the accuracy of the blind offset now. I have no data on the on-sky accuracy of the offset. If the performance needs to be particularly good, we should make the jump to pointing with the strip encoders.

DSA: After Nov 5, we should be able to greatly reduce the trajectory decoupling problem but I do not expect it will be eliminated under all conditions. If we can pin down the magnitude of the offsets, I can give you a nominal offset time for the mount. However, I do not feel we should make this requirement too tight.

Verification method

  • Select field with well-known astrometric standards such as stars in Messier 67 of Hipparcos stars. Offset between stars with well known separations, and determine error in centroid position from the expected position. Repeat test for offsets ranging from 20” to 1’ and determine RMS errors.

Test results

  • Date: Result/Data

Guiding

Specification

  • "The guiding has to be better than 0.1 arcsec" - Walter Seifert, email from 13 Oct 2008
  • Better than < 0.2” RMS for 1200 s 008s003

Verification method

  • Start guiding on off-axis guide star. Once guiding has started and has converged log the guide corrections sent to PCS from GCS over a 20 minute period. Simultaneously, take data cube with short-exposure images with IRTC (sampling at say 10 Hz) and determine that the IRTC centroid shifts match those obtained from the GCS data. Ensure that collimation look-up corrections are frequently applied so that collimation drift does not affect pointing. To achieve this one could run the active optics routine for closed-loop active correction, ensuring collimation and pointing updates every ~ 32 seconds.

JMH: Beware of the definition of "guiding". I think this should be split into specifications for "tracking open-loop" and "tracking with closed-loop" guiding.

JMH: Jumps in primary mirror collimation probably mean that it is difficult to meet this spec for more than 10-minutes, although RMS can hide a lot of sins. We still need to test the new PSF code that wll allow off-loading active corrections from M2 to M1.

DSA: I expect that the performance of the guiding will depend on the pointing model. The integral gain (which is currently not used) should be effective in making smooth guide corrections without following error when the pointing model is particularly bad. This may be the case at high and low elevation angles. Has this been characterized?

DSA: Any verification must decouple seeing from tracking which is not trivial for sub-arcsecond tracking. Can this be done with the DIMM?

DSA: This figure is dominated (or it should be) by the open-loop tracking performance. The mount meets the tracking performance (at the encoders) under light and moderate wind conditions. However at higher wind speeds we are do not have sufficient motor torque to maintain the specified tracking. Any tracking spec should be accompanied by a corresponding wind speed. The problem is that it is hard to trust our weather station.

DSA: I have seen the Gregorian vibration amplitude as high as 1.2 arcseconds. How do we roll this into the Guiding/Tracking spec?

DLM: Tracking data were collected on 6 Oct 08. The telescope was collimate with ActOpt loop while Guiding. Both Guiding and ActOpt were turned off and then an IRTC cube was acquired every two minutes, immediately after pressing "collimate" button on primary Gui. Two 20 minute data sets were collected, one at elevation 80 and the other at 53 degrees. These data have not been reduced.

Test results

  • Date: Result/Data

Misc

  • 17 October 2008 - Michele

HI Folks,

I just had a rather productive conversation with Dave Ashby on a technique to help us in our quest to tune the guiding (i.e., guide filter values, etc.). In essence, we need on-sky time and a special version of PCS in order to impose specified guide corrections into the system and observe the system response. By this I mean we need to force the magnitude and direction of the guide correction and then observe where GCS finds the star. Since we can currently block and record the GCS determined guide star positions, the PCS just has to be modified to generate (according to a defined function) guide positions which will be fed to the pointing kernel.

It seems the sooner we can formulate a firm plan, the sooner we can enact it. I will note that I will be away the first week of November at a conference; I do need to spend a little time at the end of October preparing.

  • 17 October 2008 - Dave A (From IssueTrak #1740)

Michele gave me file containing the GCS corrections as received by PCS. First, the gain appears to be far too high and second, the y-corrections do not seem to make sense. Furthermore, according to Dave Thompson, the guider is making the image quality substantially worse than the open-loop telescope performance.

JMH: I don't think we need to tune the PCS guide filters for LUCIFER. The telescope servos have their own prefiltering so they should not require the filters in the pointing kernel.

DSA: John, the guider loop is a control loop with the mount, telescope, AGw and GCS all appearing as the "plant". The "filters" in PCS are better described as the "control gains" for this loop. From what I can tell, the guider control loop is prone to oscillation and it appears that the gains are much too high.

JMH: I've seen no evidence that guiding is making the images worse. Although the 0.3 arcsec jumps do sometimes seem to irritate the guider in the sense that the jumps seem to be out-and-back on about the same timescale as guiding.

DSA: Dave T has reported that the open-loop tracking is better than the closed-loop tracking. This is clear evidence that these gains must be adjusted. He performed several tests when he collected data for is famous video.

DSA: It seem the there is some evidence that the 0.3 arcsecond jumps are coming from the guider loop. I did not seen any jumps in Dave's open-loop video. Do we have data showing such open-loop jumps?

Delivered Image Quality

Plate scale

  • "Plate scale stability must be better than 0.02% across the Lucifer field" - Email from Dave T

Verification method

  • Specify test

Test results

  • Date: Result/Data

Active Optics Acqusition Range

  • The collimation model must provide a wavefront within the capture range of the SHWFS at the start of each observing session. 008s003

DLM: ~6 sets of historical data from June have been reduced and plot created. There are ~10 more sets of "Beginning of the Night" collimation data from Sept and Oct yet to be reduced. First results show that up to 6000 nm of initial error the ActOpt loop is able to converge.

Verification method

  • Deliberately pre-aberrate the wavefront with aberrations driven into the system using the PSF GUI, and test for convergence of active collimation and M1 deformation adjustments. Combinations of low-order aberrations adding up to 6000 nm RMS WFE should be used as a starting point.

Test results

  • Date: Result/Data

Active Optics Convergence Iterations

  • The active optics system shall converge to < 400nm RMS WFE in < 5 iterations. 008s003

DLM: ~6 sets of historical data from June have been reduced and plot created. There are ~10 more sets of "Beginning of the Night" collimation data from Sept and Oct yet to be reduced. First results show that up to 6000 nm of initial error the ActOpt loop is able to converge in five iterations or less

DLM: There is an open issue as to how well (eg how quickly) the ActOpt loop converges for >6000 nm of initial aberration. This may require an "Initial Collimation Mode" where on Focus and Astigmatism corrections are applied for the first few ActOpt iterations. See collimation data from 15 Oct 08.

Verification method

  • Deliberately pre-aberrate the wavefront with aberrations driven into the system using the PSF GUI, and test for convergence of active collimation and M1 deformation adjustments. Combinations of low-order aberrations adding up to 6000 nm RMS WFE should be used as a starting point.

Test results

  • Date: Result/Data

Active Optics Stability

  • The active optics RMS WFE should not exceed 400 nm during closed loop iterations once the system has converged. 008s003

DLM: There are many (20+) sets of data where the ActOpt loop was closed for 10's of minutes. These data are yet to be mined.

Verification method

  • Leave closed loop active optics running on a near zenithtransiting star for 30 minutes and record RMS WFE for each cycle. In the long term data on variation of this performance with seeing can be determined.

Test results

  • Date: Result/Data

Wavefront correction

  • Open loop wavefront correction for 20 minute runs "no significant contribution above seeing limit". 008s003

DLM: Open-loop collimation (no ActOpt, only application of CLUT every ~32 sec) were collected on 6 Oct 08 (I can not find info in the TWiki log, but pretty sure we took these data after the tracking data above). Telescope was collimated with ActOpt loop and Guiding. Apply ActOpt corrections button on GCS Gui step to false. After each acquisition of WFSC image the "collimate" button was pressed on Primary PSF Gui. These data have not been reduced.

Verification method

  • Select a zenith-transiting star (or close to it) to maximize the change in elevation over the 20 minute test, and measure the WFE with the SHWFS without sending closed-loop corrections for 20 minutes. Repeat at several starting elevations, sampling the range of elevation from near zenith to 20 degrees elevation. Note that corrections will be sent to one or more of the primary, secondary and tertiary during open-loop testing from the collimation models.

Test results

  • Date: Result/Data

AGw coordinate system

  • Better than 0.05 degrees and < 1 arcsec (Davt T list)

Verification method

  • Test method

Test results

  • Date: Result/Data

Actual Image Quality

System Reliability

Technical downtime

  • Single Telescope – Seeing Limited Operation (LBTO Ops Plan, 002s007)
  • <10% (5%) technical down-time two years after first light
  • < 5% technical down-time five years after first light
  • >70% (80%) shutter open time for any of the facility instruments
  • <25% overhead for acquisition, setup, calibrations, read-out, storage

NC: As it pertains to software, this requirement at face value is not achievable when compared with industry historical data. First light occurred in September 2005 (3 years ago). The system has grown in complexity since that time. It will grow again in complexity when called upon to perform full binocular operations, adaptive optics, and interferometry operations. Each of these goals will constitute a major enhancement to the software.

NC: The activities for single sided prime focus (the functionality when first light occurred) should not be used as the yard stick for measuring the reliability of what can be accomplished with "new" software deployed for active optics at the bent Gregorian focal station. Nor should it be used for full binocular, AO, and interferometry features that will be added to the software in the future. The clock and expectation for reliability should start over or be significantly set back whenever a major deployment of "new" and "majorly enhanced and extended" software is deployed. The following chart shows how the reliability of software degrades with each significant release of enhanced and extended software during the software lifecycle. This chart is representative of industry historical data. This source of this chart is from: Software Engineering, A Practitioner's Approach, Third Edition, Roger S. Pressman, Copyright 1982, McGraw-Hill Inc.

SW_lifecyle_failure_curve.jpg

NC: This chart shows that every time a significant release of software is deployed the reliability is significantly affected negatively. It also shows the number of problems over time does not approach a minimum but actually increases during the lifecycle of the software. This ever increasing number of problems is most likely due (in most cases) to the added complexity and increased lines of code that are added during the software lifecyle.

Verification method

  • During Bent Gregorian commissioning, maintain a detailed observing log of failures and downtime. However, the telescope

Test results

  • Date: Result/Data

Preset stability

  • For every preset sent a guide star should be acquired, guiding and active optical correction should close their respective loops and converge to at least their minimum required values as described above. 008s003

JMH: You can't say "For every preset" as that requires 100% success. Presets sometimes fail for legitmate reasons (clouds, improper guide stars, etc. ).

Verification method

  • During Bent Gregorian Commissioning log the number of presets sent and the number of failed presets. Document system failures.

Test results

  • Date: Result/Data

Vibrations/Jumps

Test Results

  • October 17 2008 [Dave T email]

I made a movie from LUCIFER data taken a few nights ago (attached). This is a cutout of four stars roughly out at the 4 corners of the detector (all are at least 2 arcmin away from the others). The data was a 100-image sequence of 1 second exposures at about 1.7s cadence. This was taken in TRACK mode, so there are NO guiding corrections or collimation being applied during this sequence.

Any correlated motion between the four star images can be interpreted as coming from somewhere on the telescope. De-correlated motion (stars changing their relative separation) are anisokinetic effects from the atmosphere. For a star near the middle of the LUCIFER image I pulled out the centroid data and found an rms motion of 0.14784 arcsec in X and 0.18012 arcsec in Y. The images with guiding and wfs'ing look pretty similar.

This is a significant contribution to the degradation of the delivered image quality. The source of this motion needs to be discovered and eliminated.

DSA: What is the expected seeing contribution for frequencies of <0.5Hz (correlated or not). Surly some of this motion is due to seeing. How much? Do we have DIMM or polars monitor data for this period?

DLM: It is possible that some of the correlated <0.5 Hz motion is due to ground layer seeing. The wind speed was very low (<0.5 m/s?). Andrew is going to talk to someone at the VLT(?) and we will also talk to Guido.

DSA: Where are those pesky 0.3 arcsecond jumps? Can we capture one of these with the IRTC in open-loop?

DSA: The vibration is what it is for the time being. It is highly unlikely that we will be able to fix whatever we find before the LUCIFER run.

DLM: Currently the only IRTC data sets I know of are from 19 Apr, 3 Oct and 6 Oct 08. The 3 Oct and 6 Oct data have not been reduced yet. IRTC vibration data collected on 19 Oct 08 are saturated and of limited use.

-- JoarBrynnel - 17 Oct 2008

Topic revision: r7 - 22 Oct 2008, DougMiller
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback