Lisa, Daniel, Sheila

The messages:

1. We could successfully engage WFS after we aligned the cavity and centered them, using Keit'a matrix

2.  We don't see any improvement in the ALS COMM noise as measured by transmitted IR with WFS on and off. However, the noise is small to start with (around 10Hz rms). So we reached level 2 on Valera's levels of awesomeness (It worked, but it didn't improve the noise). 

(Lisa, Sheila, Daniel)

We finally added the CM summing node to the common mode path. The signals are hooked-up as follows:

1. ALS-C-REFL_DC_ERR (taken from LS-C-REFL_DC_BIAS)
2. LSC-REFL_RF9_ERR (taken from the REFL_A demodulator Q channel)
3. ALS-C_COMM_A_RF_ERR (taken from the COMM_A PFD output)
4. LSC-REFLAIR_RF9_ERR (taken from the REFLAIR_A demodulator I channel)

Fast readbacks still need to be tested. The medm screen can be accessed from the ALS overview screen.

I just noticed that the h1guardian0 machine is in need of some attention. It currently is using all its RAM and is swapping from disk, so presumably it is now performance limited.

The memory usage started increasing around 17:30 PDT Thursday 22nd, and got steadily worse. Swapping started at 03:30 PDT Friday 23rd and has been doing so ever since then.

We will most probably reboot during tomorrow's maintenance.

controls@h1guardian0:~ 1$ free -g

             total       used       free     shared    buffers     cached

Mem:            11         11          0          0          0          0

-/+ buffers/cache:         11          0

Swap:           11          5          6

model restarts logged for Sat 24/May/2014
2014_05_24 06:44 h1fw0

model restarts logged for Sun 25/May/2014

Unexpected restart of h1fw0, no restarts reported for Sunday.

J. Kissel, A. Staley

As suspected, the problem appears to be the 71 MHz local oscillator that the Y end. At the remote advice of Alexa, I increased the ALSY's "LO mon" value, H1:ALS-Y_REFL_A_DEMOD_LONOM, from 20 to 21. As soon as I did so, the arm locked up instantly, the demod error disappeared, and the guardian error message cleared. Even more strange, the monitor value, H1:ALS-Y_REFL_A_DEMOD_LOMON is still *above* 21, so the nominal must be a mean with a range not a threshold. Even more strange than that, if I decrease the nominal value back down to 20, the arm remains locked. DAH! I guess I have plenty more to learn on this system.

Anyways, the 71 MHz power supply still claims that its power supply voltages are too low, and its output monitor, H1:ISC-RF_Y_AMP71M_OUTPUTMON, says the power is 51 [dBm]. We should fix this (if its actually broken) on Tuesday. 

We should also put in some effort to making the guardian subsystem messages more clear.

For now I'll continue with the LO nominal set to 21 [??]. (Though I'm surprised that Stefan's state machine doesn't prevent me from doing this...)

Also, I attach the MEDM screen chain one has to follow to get to this information.
SITEMAP > ALS tab > ALS Overview > Y Arm PDH [little black words in a silver background box] > 71MHz RF Amp 

I'm leaving both the X and Y arm locked and well aligned. And will shoot for the moon again tomorrow.

J. Kissel, L. Barsotti, D. Hoak

Hoping to make a measurement of the length actuation force coefficient for the ETMY ESD, we tried to lock the Y-Arm using ALS. We've failed, and we don't know why. Below I outline our debugging process, but it's really not that interesting since we never found a culprit. Our best guess is something wrong with in analog at the Y-End PDH demodulator's local oscillator, because 
    - when we request the Guardian to changed to "LOCKED_NO_SLOW," it immediately faults out with a rather unhelpful "PDH" error message.     
    - H1:ALS-Y_REFL_LOCK_ERROR_MSG on the PDH overview screen claims "demodulator"
    - DEMODs complain of an error message "LO power level out-of-range" for both the "REFL" and "SPARE," where the nominal values are 20 and 22 [??], respectively and the monitored values show ~ 21.2 and ~ -36.9 [??]. Dunno what units these are in. Maybe dBm?
    - Opening the 71 MHz RF AMP screen, there are errors shown "Output RF power level out-of-range" and "Power supply voltages out-of-range" with a nominal value of 20.5 [dBm], and a monitor value of 51.9 [dBm].

X-Arm remains happily locked, and even survived a the big earthquake that took out the Y-ARM. 

Merp.


- Found no light or flashes on ALS Y GIG-E camera monitoring the transmitted light.
- Found all Y-arm ISIs tripped (probably because of an earthquake -13 hours ago, but strange that it didn't affect X-arm. Did look that hard.)
- Found ISI subordinate Guardians not responsive because a ca.get request for the master switch had faulted out.
- Reloaded all sub-ordinate Guardians, restored them in managed mode
- Reset Y-arm ISI watchdogs. Erred out because it "filters are not in expected stated," or something like that.
- Reloaded manager, switched requested state to OFFLINE to start everyone over
- Reloaded subordinates again, set to managed, requested FULLY_ISOLATED, and things came up -- slowly, but surely -- included HEPI realignment.
- Found SUS ITMY PUM WD tripped, which forced Guardian to go to safe, with the master switch OFF, and therefore no alignment biases.
- Reset SUS ITMY WD, waited for guardian to turn everything back on. As soon as alignment sliders came on, we began to get transmission flashes on the GIG-E camera. 

Since flashes, we've gotten no where. As mentioned above, the ALSY Guardian immediately faults.
- Tried tweaking alignment, because we thought transmission flashes were below locking trigger threshold. Tweaked up alignment, got normalized transmission up past 1.0, still no dice.
- Looked at optical levers after ISIs settled, there's slightly higher motion than the X-ARM, but nothing outrageous -- at MOST 0.2 [urad]_{pkpk} in ITMY, but I think that's because the blend filter configuration is different between ETMY and ITMY chambers. 
- The state machine is preventing us from changing any of the PDH Board configurations, but we find
    - Both ALSY PDH inputs disabled -- maybe because Guardian's waiting for "PDH" to be OK?
    - Error point, H1:ALS-Y_REFL_ERR_INMON shows identically zero signal.
    - DEMODs complain of an error message "LO power level out-of-range" for both the "REFL" and "SPARE," where the nominal values are 20 and 22 [??], respectively and the monitored values show ~ 21.2 and ~ -36.9 [??]. Dunno what units these are in. Maybe dBm?
    - Opening the F AMP screen, there are errors shown "Output RF power level out-of-range" and "Power supply voltages out-of-range" with a nominal value of 20.5 [dBm], and a monitor value of 51.9 [dBm].
    - H1:ALS-Y_REFL_LOCK_ERROR_MSG on the PDH overview screen claims "demodulator"
    - Similarly (but I guess less important), there are some errors in the Phase-Frequency Discriminator spare (sign wrong, and LO out of range), but I think (a) the spares don't matter, and (b) the nominal values haven't been set.


#yakshaving

No restarts reported.

(awesome compared to what we had in the past, but still only for 3 DOFs).

I started with H1:ALS-X_TR_A_LF_OUT of about 1.1, centered WFSs, engaged the servo, and it didn't work.

Then I manually aligned the arm well such that the transmission becomes 1.2-1.25, centered WFS, and it still didn't work. Since I wasn't sure if the cavity was well aligned when I measured everything before, I started from scratch.

I measured the demod phase, and the phase itself was not a disaster, but I've found that segments were totally imbalanced (I balanced them before). Fixed it such that the seg1 signal strength against length injection is matched to seg3, same thing for seg2/seg4.

Then I measured the sensing matrix again, inverted them, put them in the input matrix, and PIT DOFs started working (but YAW not).

After several rounds of enable WFSs, center WFSs, remeasure sensing matrix, I converged to a state where 2 PIT DOFs plus one YAW DOF that corresponds to PZT2 works wonderfully. Enabling 3DOFs would immediately bring the transmission up to 1.36 or so.

Lisa misaligned ETMX such that the transmission drops to 1.0-ish, we enabled the 3DOF WFS, and immediately the transmission recovered.

Don't know why the 4th DOF doesn't work but I'm leaving it as is. For now WFS is disabled, QPD centering is enabled. If you want to enable WFS, you first need to disable QPD centering by disabling the input or output of H1:ALS-X_QPD_A_PIT and such, as the WFS feedback is also added into the same PZT path and there's no convenient way to disable QPD while allowing WFS signal to be routed to PZT.

H1 SR3 in chamber (HAM5 locked) undamped transfer functions for the three stages were measured yesterday night and are attached below. Overall they look good. Damped transfer functions are currently running.

Attachments in order :

1) M1-M1 undamped tfs compared with the model
Clean tfs, excellent match with the model.

2) M2-M2 undamped tfs compared with the model
Data is noisy, which is probably as good as we can get for now.
Pitch seems to couple with the first top mass vertical mode at 1.06Hz, yaw seems to couple with the second top mass roll mode @1.97Hz. Those coupling should be reduced with damping. 

3) M3-M3 undamped tfs compared with the model

Data is noisy, but gives a good idea of the tf shape. The only odd thing in the results was the factor of 4ish discrepancy between the model and the measurement for the pitch dof (meas=4ish*model). After spending some time trying to understand, it appeared to be a wrong euler to osem basis matrix. The pitch to osems factor (8.3) was 4ish times higher than the nominal value (2.4) (from make_sushlts_projections.m under HLTS/Common/MatlabTools/). Screenshot attached shows the corrected matrix.

I doubled check for PR3, which was also wrong. The new values were saved under a safe.snap for both suspensions and commited under the svn.

Not sure I saw this reported before. Today, I tried to align the y-arm. When I hit a certain angle in TMS, ETM or ITM, pitch or yaw, the lock would go bi-stable. When moving even further, it would stay at the lower value. However, the higher value could be regained by adjusting the PDH demodulator phase. As a matter of fact a phase change of ~20º can be used to switch between the states (see attached plot). Looking at the transmitted camera both modes look like 00.

Day's Activities

• SR3 measurement continues from last night (Arnaud)
• Running long term storage purge air (low pressure) over weekend (Greg)
• Hartman work begins (David H)
• Switched to Laser Hazard
• Looking for "leaky  valve"  (Ski)
• ISS went into oscillations at about 3am last night, switched from PD-A to PD-B
• Swapping out computers on the floor (cyrus)
• Diode Chiller low flow tripped PSL Watchdog
• Cyrus added memory to some of the video monitor computers.

This afternoon the following items tripped/went down: 

• PSL
• HAM2 ISI / HEPI
• HAM3 MC2 / PR2 / ISI / HEPI

After much head-scratching, ultimately pointed our focus to the PSL (the PSL was completely down, no light coming from the PSL, Gerardo noted an Error on the Diode Chiller).  Luckily Rick was here and was already on his way up to the OSB.  Justin & I accompanied him to the Chiller & Diode Room. 

[(1)Before heading to Diode Room, we turned the ISS AutoLocker OFF.  (2)When heading to Diode Room, Kissel took the IMC Guardian to DOWN]

In the Chiller room, we noticed an Error light and message on the Diode Chiller (the one on the top which has a clear spout on it); the water in the spout wasn't moving much--it's generally more turbulent.  We couldn't clear the error at the Chiller, so we garbed up & went into adjacent Diode Room.

Here we had the Beckhoff computer to work with.  On the System Status screen we saw the following Trips (in red):

• Interlock
• Diode Chiller Flow

We hit a RESET here, but the Diode Chiller Flow was still tripped.  We then went to the Chiller screen & clicked on the RED Chiller button to bring it back.  We also clicked on the red Watchdog button.  At this point we were GREEN, and done in the Diode Room.  On the Diode Chiller the Error light was OFF (but we still saw the Error message on the LCD screen).

When we walked back into the Control Room everything was good, green, & we had PSL light.  The ISS Diffracted Power Was a little low, so we clicked it more positive (i.e. made absolute value of voltage a coule hundredths smaller.].

[when we had PSL light, Kissel requested "LOCKED" for IMC Guardian]

Lisa

At Livingston they have to realign the arms very frequently in order to mantain high power build up. It seemed like we were not seeing the same problem here, but we didn't really have any numbers for Valera.

So, I left both arms locked on green last night. The plot shows a 6 hours trend of the green transmission power for both arms, and amplitudes of the beat notes. The guardian was left on, and it was automatically recovering lock.

The Y arm power dropped by ~10-15% over 6 hours. For whatever reason X was drifting much more than Y. Still, on a 1 hour timescale, you can't really see any significant drift; over 6 hours, the X arm drift was ~50%. I don't know if it has been already observed in the past that X drifts more than Y, or if it was just an isolated event.

I've upgraded the memory in all of the wall display computers in the control room from the woefully inadequate 2GB, up to 8GB.  This should make them run much better and prevent swapping and the general malaise that makes things quit working or otherwise grind to a halt on them after a while.

After the PSL went down, MC2 IOP watchdogs tripped this afternoon, which cascaded to HAM2/HAM3 ISIs.

It tripped because of a large ISC length control offset signal applied on the left and right osems of the top mass.

Similarly as what Jeff did on the sus WD models (cf his alog), the trigger on DC osem values in the iop models (upper path of screenshot) should be removed to avoid this kind of situations.

This could be done during the vent period in two weeks. 

Reading before turning it off, 1.34X10^-04 torr.

Left the CC on for 1.5 hours.

It is off now.

This evening Lisa pointed out that the low carrier buildup can be explained by misalignment in the Y arm.

I spent an hour to carefully adjust the alignment. Indeed, after the alignment, I got a cavity flash of 45 (normalized for a single arm build up) which is the highest we ever obtained. Also, the funny REFL9I offset disappeared and I could see a PDH-looking signal there when CARM passed through a resonance.

What I did:

• Aligned ETMY to maximize the IR in Y. (CAREFUL: This is an opposite way of the proposed global alignment procedure)
• Then steered TMSY and added an offset in the TMSY QPDs to recover a high buildup for the green light.
  • The resultant green buildup is now 10% smaller than the usual, but optimized for the infrared. Not terrible.
  • ALS-Y_QPD_A_PIT now has an intentional offset of 0.8. This gave a high buildup for the green light.
  • I did not steer ITMY or BS at all in this process. In other words, I relied on the PRMI local alignment.
  • Then I did a mode scan of the Y arm to see how good the alignment is. The spatial HOMs are now small. Their power are roughly 10-20 times smaller than the carrier 00. Good.
• I tried the locking process again, starting from a CARM offset of 700 Hz with REFL45 for PRMI. This worked fine.
  • The funny offset in REFL9I was much smaller this time. It was about 10 times smaller than yesterday. Good.
• I reduced the offset to let CARM resonate while holding PRMI with 135I and Q.
  • I didn't have to re-adjust the demod phase at all this time. It was robust until the arm cavity started building up the carrier light.
  • Apparently PRMI was not able to survive through the arm cavity resonances.
  • However if the sweep through a resonance is fast enough, PRMI does not drop the lock since the carrier does not build up so high.
• I disconnected the REFL_DC_BIAS cable from the common mode board and connected the REFL9I signal in order to try self-lcoking.
  • It seemed that a good control sign is positive at the input2 of the common mode board because this brought CARM closer to the resonance.
• I tried self-locking a couple of times with no success.
  • I was not able to approach the resonance as close as 100 Hz because of the fragile PRMI before introducing REFL9I. So I tried to add REFL9I when CARM was as far as 150 Hz or so.
  • Self-locking tends to push CARM to the resonance as expected, but IMC unlocked every time. The arm power went up to 3 or 4 before IMC unlocked.
  • I tried different gains (almost randomly) in input2, but no luck. I guess that CARM is basically too far from the resonance and therefore self-locking can not squash such a big offset by its gain.