Sheila, Haocun

We switched back to 36MHz demodulation first (with Gain=33), but there was still an offset for Yaw between the REFL loops and POP loops.

Then we chose to use 45MHz demod and adjusted the phases to put the SRM into Q phase (figures attached). We used -0.1 for Pitch (POP X_Q) and +0.1 for Yaw (POP X_I) in the input matrix, taking the measurements for gain and increased the power. It remained stable till 38W.

For the past week or two, we've been annoyed by "ISS first loop is maybe off?" message in ISC_LOCK guardian, preventing guardian to go to DC. The guardian checks PSL-ISS_LOOP_STATE_OUTPUT, and if it's 32700 it passes, otherwise it wouldn't.

However, when Sheila looked back, PSL-ISS_LOOP_STATE_OUTPUT was 32000 (NOT 32700) in most of O1.

It turns out that LOOP_STATE can only become 32700 when ISS auto locker is OFF: LOOP_STATE is 32700 (1st loop ON with integrator, manual), -32700 (1st loop ON, integrator OFF, manual) or 0 (1st loop OFF, manual). The numbers are hard coded in MEDM screen buttons.

When the ISS auto locker is ON, LOOP_STATE is dictated by the state machine C code in the front end and it only outputs 32000 (1st loop ON with integrator), -32000 (1st loop ON, transition to integrator ON) or 0 (1st loop OFF, transition to 1st loop ON).

Somebody should have changed the guardian recently when we had a problem engaging ISS auto locker just to get by. But the reality is that LOOP_STATE output is sent to DAC to control the analog board, and there's no meaningful difference between 32000 and 32700 as far as analog switching is concerned.

Since ISS auto locker is working OK with larger diffraction, we changed it so it fails when PSL-ISS_LOOP_STATE_OUTPUT is smaller than 32000. This way, even when ISS auto locker has a problem, operators can change ISS to manual mode and the guardian will still pass.

1/2 open LLCV bypass valve, and the exhaust bypass valve fully open.
Flow was noted after 95 seconds, closed LLCV valve, and 3 minutes later the exhaust bypass valve was closed.

Prior to upgrading an end station sus front end system to Gentoo linux kernel 3.0.8 I have trended the ETMX and ETMY SUS statewords looking for Timing and/or ADC errors since Jan 1st. The attached plot shows the instances of these glitches on h1susetmx (red circles) and susetmy (blue circles). Since sometimes a SUS glitch is accompanied with an IOP glitch, I have also shown h1iopsusex (red cross) and h1iopsusey (blue cross).

These glitches are normally latched on. To enable trending, for the whole time a cron job running on h1fescript0 has been clearing the stateword bits once a minute.

As can be seen, the rate of errors is not constant. At the tail end of O1 EY was glitching more than EX. During Feb and early Mar both systems glitched frequently. Since then there have been quiet and glitchy periods, lasting from several days to a week or so.

The plots show that sometimes an IOP can glitch without the sus model, in most cases it is the other way around or they both glitch.

Darkhan, Kiwamu,

We have updated the h1calcs, h1calex and h1caley models to make them up-to-date by following Joe's instruction (alog 26126). We will install the models tomorrow during the maintenance period.

In addition to the implementation, we have edited CAL_LINE_MONITOR_MASTER.mdl to improve a complex division where we used to calculate the phase by a simple subtraction between two phase values. This part is now replaced with a complex division and then is converted to phase and magnitude in order to avoid a 360 deg phase ambiguity. We also had an issue with the compiler where the choice of the name for instances of the MAGNITUDE_PHASE library caused errors in a somewhat unintelligible manner. Eventually we came up with a set of names that do not make the compiler crazy. Dave is now taking a look at the code to see if there is a particular cause for this issue.

In summary, the followings are the ones we modified today.

• cal/h1/models/h1calcs.mdl
• cal/h1/models/h1calex.mdl
• cal/h1/models/h1caley.mdl
• cal/common/models/CAL_LINE_MONITOR_MASTER.mdl

Needed to power cycle the camera in the BRS Box on the floor as well as restarting the program code.  TJ was able to test his diagnostic code and all is running well now.

• The instability occurs without a DARM offset (as expected).
  • confirmed once with the interferometer locked on RF at 25-30 W
• At 25 W or a seemingly stable but high circulating power, aligning the pointing of the arms (aka soft degees of freedom) in situ lead to the instability.
  • Or perhaps the in situ alignment took a long enough time to run into the instability. Not clear.
• The DRMI 2 omega RF signals seem to show a silimiar linear dependency to arms' dP/d(theta)
  • could be a hint for localizing the position dependent loss?

An automated measurement is setup for the ITMY ring heaters. A script will turn on the ITMY ring heater for 4 hours with a 1 W power on each segment. Once the measurement is done it is going to automatically shut the ring heaters off.

The measurement will start at 22:00 PST tonight and finish at 2:00 AM tomorrow morning. Please do not change the alignment of ITMY or SR2 during the measurement.

Took H1 to DC Readout for Kiwamu to run high power tests.  

• The Power Recycling gain has been running low (i.e. 33?).  Kiwamu wanted to adjust alignment to see if this could improve this gain.  

Toward the end of the shift, H1 could not lock the OMC.  Kiwamu traced this down to a rung up violin mode for ETMy.  I remember watching others damp violin modes, but I have not done it before.  I tried looking through wikis and alogs for instructions but could not find any.  

H1 taken to a DOWN state for the night.

Summary:

By looking at the XARM HWS signals, I can see that we're overestimating the response of the CO2 central heating. As a result, we are underapplying the preheating to stablize the total value.

Also: the H1:TCS-SIM_XARM_POWER estimate is now wrong following some recalibration work on the X_TR SUM signals the other day.

Details:

I looked at 24 hours of HWS and SIM data from two days ago. Aside from glitches, there were systematic discrepancies between the measured HWS signal (when scaled by 0.5 to convert it from double pass to single pass) and the sum of the CO2 and SELF heating SIM channels.

• SELF: I spoke to Kiwamu and he suggested that some whitening filter changes may be responsible for the change in calibration of X_TR_B_SUM (here?).
• CO2: it's clear by comparing the lenses measured by the HWS and predicted by the CO2 SIM in the period between 650 and 750 minutes that the CO2 lens is overestimated
  • A best fit between the SIM and HWS suggested that this needs to be dropped by a factor 0.573
  • So: 6.23E-5 diopters per Watt * 0.573 = 3.57E-5 diopters per Watt in H1:TCS-SIM_ITMX_SUB_DEFOCUS_CO2_GAIN

This means that the TCS Guardian function for calculating CO2 power will need to be adjusted. 

The attached plots show (a) the time series from the HWS, the CO2-SIM and SELF-SIM, (b) the HWS measurement minus the optimally scaled CO2-SIM measurement and (c) the second plot minus SELF-SIM calibrated to give the smallest RMS on the whole time series.

Keita, Kiwamu

We spent some time today trying to figure out what made the engagement of the ISS second loop so hard recently.
We conclude that the SR560, which has been served as a summing point for the second and third loop signals, is the one hindering the ISS second lopp. In order to for us to be able to lock with a low noise ETMY for the planned PI measurement, we bypassed the SR560. This means that the ISS first and second loops are in the same configuration as O1 and therefore no third loop is available.

If necessary, one can reconnect the SR560 and resurrect the third loop.

[Issues with SR560]
The SR560 caused two major issues. First, it limited the range of the auto reference adjuster to +/-3V. Second, when it saturates, the output of the SR560 sticks to a negative voltage value (-3 ish volts), regardless of which sign the input signal is. Therefore, when we request the engagement of the second loop, it tried to catch a linear signal within a smaller range. If fails, it can run into a region where the error signal has a wrong sign which drives the auto reference adjuster to the opposite direction. We think this is what has been going on with the second loop engagement in the past several days.

[A large offset]
Apart from the SR560, we found one thing which appeared to be an indication of a broken op-amp or some sort; the output from the second loop circuit board was measured to be -1 V, when the inputs were all disconnected. We thought this was another issue which had prevented the second loop to engage, but as we leaned later, this offset is not critical. By the way, this relatively large offset seems to be a function of the variable gain value. What is strange is that the offset becomes large when a smaller variable gain value is requested. We pulled the second loop servo box out of the rack and checked the behavior of the circuit in the EE shop. However, we could no find any failed op amp or anything. In the EE shop, since we did not supply an external signal to set the variable gain to a certain value, the gain value stayed to be 20 dB which, as mentioned, gave us a smaller output offset of -0.1V. We measured the transfer function of every active stage and confirmed that nothing was wrong. The circuit was then put back to the rack.
Although this issue (or perhaps feature) still remains, we are able to close the auto reference adjusting loop without the SR560. This means that probably this large offset is not the one preventing the second loop from engaging it. We may check the behavior of this variable gain stage at some point. 

TITLE:  5/20 EVE Shift:  23:00-07:00UTC (16:00-00:00PDT), all times posted in UTC     

STATE of H1:   Taken to DC Readout.  

Outgoing Operator:  TJ

Quick Summary:  

• Kiwamu at PSL racks.  Sheila investigating 3Hz noise at different power levels.  Ross, Tega, & Sheila are doing ETMy ESD/PI work.
• BRS is ACTIVE for EX/EY with 90mHz Quite Blend Sensor Correction with BRS.
• Environment:  decent with us recovered from earthquake of a few hours ago, low useism, and winds generally under 20mph.
• Observatory Mode is at PLANNED ENGINEERING

TITLE: 05/20 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Corey
SHIFT SUMMARY: A few earthquakes prevented locking for a some hours, but Jim got some SEI testing in and commissioners are doing their thing now.
LOG:

• 16:37 - Richard to MY.
• 16:42 - Gerardo to LVEA to check on ion pump.
• 17:09 - Gerardo out.
• 19:40 - Sheila, Evan H, Hoacun to LVEA near HAM6.
• 19:52 - Keita, Kiwamu to LVEA PSL racks.
• 20:31 - Keita, Kiwamu out.
• 21:34 - Kiwamu to LVEA PSL racks.
• 22:10 - Gerardo to CP3.
• 22:11  -Sheila to LVEA PSL rack.
• 22:20 - Sheila out.
• 22:26 - Gerardo back.
• 22:46 - Kiwamu to LVEA.

Measurements done on IMs with damping loops turned off, and step functions put into the test alignment offsets in pitch and yaw.

Yaw shows yaw peaks.

Pitch shows pitch peaks, and yaw peaks when yaw is given a step function.

I could not locate historical Q measurements for pitch and yaw, only length, bounce, and roll.

For completeness, I've included resonant frequancy measurements from LHO and LLO.

(Chandra, Gerardo)

The annulus ion pump crashed early this morning, the plan is to replace it next Tuesday.

It appears that the pump was last replaced sometime in February of 2002.

1/2 open LLCV bypass valve, and the exhaust bypass valve fully open.
Flow was noted after 80 seconds, closed LLCV valve, and 3 minutes later the exhaust bypass valve was closed.

the h1psliss system was reporting a false difference in the filtermodules loaded vs the chans file. This was tracked to the rcg3.0 problem (reported https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=27247) with repeating filters in the working file if a filter is loaded whose name is the core for other filters. In this case ISS_SECONDLOOP_REF_SIGNAL_SERVO was loaded which is the core name for ISS_SECONDLOOP_REF_SIGNAL_SERVOINF. After verifying that the diff being reported was solely due to multiple copies of the same filters, we performed a full filter load on h1psliss to clear the error. Since at all times the filters were being overwritten with identical filters, no runtime changes were made.