### OBSDATE ### 20120814 ### LOGDATE ### 120814 ### OBSERVERS ### BAW ### WEATHER ### Light cloud at start, but blew away within 1/2 hour. Very good afterward. ### LOCATION ### Home ### PROGRAM ### ACR's Sco-Cen targets ### SIDEROSTATS ### n3 s3 ### TARGETS ### Tau Sco (HR 6165), Tau Lib (HR 5812) to start as they were on opposite sides of zenith offering an interesting opportunity for pointing data. These targets were then repeated twice more bracketed by cals: Pi Sco (HR 5944) mostly, but also Rho Sco (HR 5928) once. I was unable to find fringes on Rho Sco on a subsequent attempt. An attempt was made on Eps Sco (HR 6241) as a potential calibrator, but no fringes were found (because it is a K giant and resolved). Later, Del Sco (HR 5953) was observed thrice, bracketed by cals: Pi Sco, again. ### QUALITY ### Very good (several calibrated points) ### PROBLEMS ### Autosave remains dangerous, at the start, pavo would save a couple of seconds of data when only one beam was acquired. On the second or third target, I turned off autosave and started saving manually after fringes were acquired. Fairly often, I would get "slewing failed" messages from the siderostats. This is a known problem. It is generally OK. The error tolerance is still just a bit too tight. In the server window, type "sb" (start background). Check that it is in a reasonable place, and type "track". It will likely start tracking just fine. I have added these words to the bugshooting page. I have also added loosening the error tolerance to my to do list (it should have been there already). I occasionally noticed S3 overshooting in its slews. Generally, it will turn around and go back, and be OK. This seems to be a hardware dependent problem, some sids undershoot, some overshoot. I don't know if there is anything intelligent to be done about it. If it goes way too far, try "stop" and "track" again. I have added these words to the bugshooting page. I occasionally lost one beam soon after acquisition (especially, the north). This is perhaps related to the target brightness. It wasn't a big problem, and there was no obvious pattern. Manually reacquired. I should add something to the bugshooting page, but I am tired. The relative humidity sensor at SUSI is reading 0. This is a known, intermittent problem (or perhaps, I should say that it intermittently works). It has been added to the on site to do list for the next SUSI trip. Early on, I got a "cable car out of position" message, but when I checked, it was fine. Probably, it was only marginally out, and slid back in during the stop procedure. Anyway, I just clicked "track," and continued on. I should add something to the bugshooting page, but I am tired. The ark siderostat controllers are not sending their positions to skymon. I suppose this was known as it was already on my to do list. For delta sco, it was slightly north of west, so I initially switched to north periscopes. All was good with S3, but I had to redo the autocol position for N3 before I found the star. I was not able to find fringes anywhere. I noticed that the tracking speed was getting quite high, so I decided to go back to south periscopes to make sure that was still working. By this time, delta sco was more or less due west. Good fringes were found and data was taken (as above in the targets section) with tracking speeds up to and exceeding 1 mm/s! It is somewhat worrisome that I could not find fringes with the north periscopes, but I didn't know where to look, and there is no reason to believe they would be in the same place as on the south periscopes (different set of mirrors). Not problems, exactly, just comments: I found SN on/off values of 2.1/1.7 to be quite good for these targets I have added "pointing offsets to try" and fringe locations to the SUSI baselines/status wiki: http://pavo.wikispaces.com/susi-baselines I have added a bunch of words and made modifications to the troubleshooting page, but it seems that there is still quite a bit of out-of-date advice on there: http://pavo.wikispaces.com/susi-bugshooting