Bent Gregorian Technical Observing : 10 September 2009 UT

Observer: D. Miller, J. Hill (Tucson)
Telescope Operator: W. Wack
SW support: N. Cushing

Summary

We opened for 3 hours in decent conditions. Got enough data to say that the transformation is not working for off-axis star with X-flips implememented or without X-flips implemented (as in May). At present, do not have a configuration that gives a properly positioned guide probe for LUCIFER.

We opened for another hour later in the night. Got more data on StoneAagw to confirm that we have problems in the un-flipped state. We measured rotator center on both Guider and IRTC in gorgeous seeing (0.42 arcsec at EL=45 deg).

Based on the transform residual pattern, Doug and I are thinking that there is some rotator angle problem. A closed-loop dice 5 pattern is apparently rotated by ~10 degrees. M3 failed before we were able to get a TRACK-mode dice 5. Lost 1 hour at the end of night to M3 hanging.
Note from DJT the next day:
        I looked at the data taken last night on the dice5 pattern (starting
UT 11:17).  It is completely consistent with what was actually
requested.  The observations were taken at a position angle on sky of
37.45 degrees and the dice5 pattern was using absolute offsets in
RADEC space, not DETXY.  If I "derotate" the pattern by 37.45 degrees
plus the additional 0.316 degrees I saw in data taken in May and June
I get the expected dice5 pattern in DETXY space.  If I "undice" the
pattern with offsets of 7.0 arcsec and -37.134 degrees, I get an rms
on the residuals of ~20 mas in X and ~48 mas in Y.  The guide star
used (#12) is 88 arcsec from the on-axis position and the dither
pattern would have taken it off the AGw_Y axis, so to first order the
transformation is fine and there are no sign flips other than the one
that may be traced to a left-handed AGw coordinate system (PCS_MX
having opposite sign from what I expected).

        The apparent ~10 degree rotation is actually 7.55 degrees and is
traced to a mis-interpretation of the dice-5 pattern (it is an X and
not a + on the detector) and a mis-understanding that the dice-5
pattern was executed in RADEC space, not DETXY, at a position angle on
sky of 37.45 degrees.
Data from 20090908 on StoneM (16 stars) should be analyzed to see if it can tell us anything about how the new transform would differ from the old one. That can be compared to tonights data on StoneA. There isn't enough new data to fit a transformation, but maybe enough to get a hint about what is wrong.

Preparations

- The PCS code has been patched to make the IRTCBGF and LUCIFER have the same affine transform.
- The X-FLIP and Y-FLIP values for IRTCBGF have been set to {false, false} in the PCSInstrument.conf.

(While Michele changed the code, we did not test anything about IRTC pointing tonight.)

Details

First few hours lost to weather.

Open

05:40 Open shutter doors

(Left monitor on lbtdu16 is not working.)

05:45 pointto M5_0850 ACQUIRE PAM- Adjust IE=-65 CA=-66 (Why is IE so different from last night?)

05:54 pointto M5_0855 ACQUIRE PAM- Adjust IE=-63 CA=-51 (Why is CA so different from 10 minutes ago?)

06:00 pointto M5_0864 ACQUIRE PAM- Adjust IE=-65 CA=-78 (Aaaaahhhhhhhh!)

06:05 pointto M5_0850 ACQUIRE PAM- Adjust IE=-65 CA=-64 (At least it repeats on the same star.)

06:07 pointto StoneMagw ACQUIRE gs=0 (oops, he meant StoneO)

06:09 pointto StoneOagw ACQUIRE gs=0 Adjust IE=-69 CA=-63

06:14 pointto StoneOagw ACTIVE gs=0 - collimate - wfsc 0001 to 0010 were on-axis collimate.

Repeating Doug's results of last night

06:22 pointto StoneOagw ACTIVE gs=7 PA=INDEF=269.62 (guide star on Y-axis) - star appears within 3 arcsec of center.

06:26 transtar 7 cube 0020

06:29 transtar 7 PA=315 - no star found.

Doug looks at a few more stars/angles while John edits oaccontrol.conf to put pcsmx back to -1.

Change pcsmx back to -1

06:41 stop GCS, stop and restart oacserver. wait 6 minutes.

06:51 start GCS, stopAGW, startAGW

06:57 pointto StoneOagw ACQUIRE gs=0 - Adjust IE=-73 CA=-70

07:02 pointto StoneOagw ACTIVE gs=7 PA=INDEF=269.62 - star appears within 3 arcsec of center

07:06 pointto StoneOagw ACTIVE gs=7 PA=315 - star appears within 3 arcsec of center (different angle)

07:10 transtar 7 PA=315

07:12 transtar 7 PA=225

07:19 transtar 3 PA=INDEF cube 0004

07:22 transtar 3 PA=+45 cube 0005

07:24 pointto StoneOagw ACQUIRE gs=0 - Adjust IE=-76 CA=-72

Flips in GCS / PCS back to the May state

in PCS
LEFTXYFLIP = true false

in GCS
WFS_pupil_shift_x = 1.0
pointingCorr_flip_x = 1.0
guidingCorr_flip_x = 1.0

07:28 Stop and restart PCS for LEFTXYFLIP to take effect.

07:29 pointto StoneOagw ACTIVE gs=0

07:32 pointto StoneOagw ACTIVE gs=7 PA=INDEF=269.62

07:37 transtar 7 PA=INDEF=269.62 cube 0007

07:39 transtar 7 PA=315 star is about 15 arcsec off!!

07:46 transtar 3 PA=INDEF - cube 0009 - star 10 arcsec right of hotspot

07:50 pointto gs=0 IE=-78 CA=-79

07:54 transtar 3 075533 cube 0010

08:05 pointto StoneAagw TelMode=ACQUIRE gs=0 - Wayne put star on hotspot IE=-67 CA=-71

08:15 pointto StoneAagw ACTIVE gs=0

Called Jesper. We've now determined that oacontrol changed pcsmx from +1 to -1 over the summer to accomodate the x-flip. In terms of the basic X-flip, this is correct and we have verified it on sky. But the problem apparently is that while X is flipped correctly, the transformation seems to be going in the wrong direction.

Change pcsmx back to +1 which was the May value

This should be the last parameter to put us exactly back to the May configuration.

08:17 stop GCS, stop oacserver for the pcsmx = +1 change to take effect.

08:19 start oacserver wait 6 minutes.

RPC error - maybe restarted something in the wrong order (GCS before startAGW).

08:32 Stop and restart GCS again, start and stopAGw again

08:38 pointto StoneAagw ACQUIRE gs=0 IE=-69 CA=-66

08:42 pointto StoneAagw ACTIVE gs=12 - star is 3 arcsec right of center

08:47 transtar 12 PA=37

08:50 clouds moving in

08:51 transtar 12 PA=82 - we got just enough of a glimpse of the star on the acquisition image that looks like we have transformation problem in this configuration too. Bummer. (cube for this one has no images)

Close

08:53 Close for clouds and incoming radar echoes.

Open

10:00 Reopen

10:05 pointto StoneAagw ACQUIRE gs=0 - Adjust IE=-77 CA=-74 EL=52

10:11 transtar 6 PA=0 (IRTC image failed?)

10:15 transtar 17 PA=0 cube 0014

10:18 cl < home$tran_StoneA_00.cl 0.5 x 80 cubes

transtar (12) cube 0015
transtar (16) cube 0016
transtar (17) cube 0017
transtar (18) cube 0018
transtar (14) cube 0019
transtar (12) cube 0020
transtar (6) cube 0021
transtar (5) cube 0022
transtar (3) cube 0023
transtar (12) cube 0024
transtar (11) cube 0025 - GCS chose the wrong star - the faint guide star was too close to the bright on-axis star.

Measure Rotator Center on Guider and IRTC

These images in /Repository/AGW_Data/090910w/

10:44 pointto StoneAagw TRACK gs=0 PA=180 ; setxy -u 3 -x 0 -y 612.5

10:45 set rotator to zero

10:57 guider00002 72 sec is a beautiful ring, but way out of focus (they forgot to move focus of the parked probe manually)

10:58 pointto StoneAagw ACTIVE gs=0 - seeing on guider is 0.42 arcsec.

11:02 stop guiding; offset CA by 10 arcsec (to move star away from hotspot on purpose); move rotator to 360

11:04 Invalid image (It seems like the first manual image after guiding is often invalid.)

11:05 guider00003 - good ring with center at (281,274) -ish

11:10 TakeSeq 1 x 80 to find IRTC center of rotation irtc.20090910_0027_cube.fits. Center at (157,140) DLM

Dice5 sequence to measure rotator angle

11:17 pointto StoneAagw ACTIVE gs=12 PA=INDEF=37.45 (star on Y-axis)

11:20 dice5 10x10 1 sec x 40 x 1 ^C after cube 0028 and 0029 (offset was too big, and was overexposed)

11:25 dice5 7x7 0.25 sec x 120 x 1 - This pattern is rotated by degrees relative to what we expect. So we are thinking that something has created a rotator angle problem and this is what is generating the apparently bad transformation.
Oops. The dice pattern is supposed to be rotated as we sent a position angle of 37.45 deg. See DJT's notes above in the summary.

11:33 pointto StoneAagw TRACK - preset hangs while collimating M3.

Stop and restart OSS. to free M3

Stop and restart IIF. to free preset

11:43 pointto StoneAagw TRACK - preset hangs while collimating M3.

11:46 Stop OSS and try to home M3, but doesn't do much.

11:55 Cycled power on M3 UMAC with remote switch

M3 UMAC repsonds to a ping, but not to Startup/Init from OSS. It seems that OSS is not starting properly.
Sep 10 12:04:17 lbtmu301 LBT_rpcserver: unknown rpc call for: oss:side[0].terc:startup:execute
Sep 10 12:04:17 lbtmu301 LBT_rpcserver: unknown rpc call for: oss:side[0].terc:startup:execute
Sep 10 12:04:17 lbtmu301 LBT_rpcserver: unknown rpc call for: oss:side[0].terc:startup:getStatus
Sep 10 12:04:17 lbtmu301 LBT_rpcserver: unknown rpc call for: oss:side[0].terc:startup:freeHandle
12:04 OSS finally running. Startup, Init,

12:07 Wierdness because Wayne presses "Home Sel" (confirmed by log), but the 3 legs of the mirror start homing. That worked.

12:08 "Home Mirror" seems to hang without finishing. See Issues #2329 and #2331.

12:12 PSF collimate command doesn't finish. So we haven't solved anything.

Close

12:15 We give up and close. Unable to get M3 to cooperate.

-- JohnHill - 09 Sep 2009
Topic revision: r6 - 11 Sep 2009, JohnHill
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