Something is really only marginaly stable.

Attached is an example of low frequency oscillation of IMC WFS DC measured by using a DB15 break out board on the front panel of the DC interface (i.e. the breakout board is inserted between WFS head and the WFS DC interface).

This is easily triggered by disconnecting the WFS DC cable from the front panel of the WFS DC interface and then plugging in again. In this case it was WFSA, segment 4 (i.e. between pin1 and pin9, why is this not the segment 1, I don't know), and it's oscillating at about 100Hz. When this happens, all the quadrants show similar symptom, and it doesn't go away spontaneously. Sometimes this goes away by wiggling the cable or touching some of the pins on the breakout board.

It's not exactly easy to make things accidentally oscillate at such a low frequency, I'm suspicious about power problem, maybe weak grounding of big capacitors e.g. power capacitor on the WFS head.

Interestingly, when the breakout board is not there, when you look at the fact channels for WFS DC, the oscillation dies down on its own within 10 or 20 seconds for WFSA.

I was curious to do the same measurement for WFSB, and with the breakout board it does something similar (second picture, in this specific  case it was slower). Without breakout board, I didn't see any craziness. Also, when this was going on, the +-18V power that are passed through to the WFSB head were also showing something similar (third picture, in this case the WFSB was oscillating faster than when the second picture was taken) . I haven't measured WFSA power (see the entry attached to this one).

When they're not oscillating, things look OK-ish in that nothing is outrageously wrong.

The SATABOY RAID unit associated with the h1fw1 system suffered a controller board failure at 1:30am Sunday. Dan (LDAS) diagnosed the problem and for now removed the failed controller card and moved everything over to the second controller card. A replacement card is on order, we will schedule a h1fw1 outage when this arrives.

h1fw1 resumed writing frames at 15:30 this afternoon local time.

The optics airbake oven that had been located in the LSB optics lab has been re-re-located (delocated?) to the OSB optics lab. There should be no competing issues with bonding now.

Events/work, that I was notified to take place:
- 8:30 am, UniFirst to change mats
- 9:20 am, Paradise water, water delivery.
- 10:28 am, Travis heading into the LVEA, BSC01 work, unlocking quad.
- 10:50 am, ITMY watchdogs trip, Travis working in chamber.
- 11:10 am, Jim B. move power for fiber rack, per WP3675.
- 11:34 am, Praxair, LN2 delivery to Y-End.
- 12:00 pm, Hugh has unlocked BSC01 HEPI.
- 12:00 pm, Mark making ITMY measurements.
- 2:44 pm, Travis checking ITMY for interference, bad transfer function, Travis out.  TF start again.
- 3:03 pm, CP7 starts alarming, delivery symptom, curve in DV appears to slow down, now at 99.3.

Mark B.

Commencing another round of Matlab TFs on PR3.

Mark B.

I committed a handy Matlab script to the SUS SVN that automates the process of creating safe.snap files for SUS: 

^/trunk/Common/MatlabTools/save_safe_snap.m

Typical usage is 

>>save_safe_snap('H1','ITMY') 

It backs up the current state to a temp file in /opt/rtcds/userapps/release/sus/${ifo}/burtfiles/, puts the suspension into the safe state by switching off the master switch, test filters, damping filters, lock filters and alignment offsets, makes the safe.snap file, restores the suspension to the saved original state, and deletes the temp file. It's fairly verbose and describes in detail what it's doing, so if it should hit an unexpected condition and stop it should be fairly obvious how far it got and how to recover.

At the end of its output it supplies the text of an svn commit command that can be copied and pasted into the Matlab command line to commit the new file.

It supports QUAD, BSFM, HLTS, HSTS and HAUX, and has been tested on all of those on H1. For HAUX, you can specify a single optic, e.g., 'IM1' but since there's only one model for IM1-4, it necessarily does them all.

It assumes that the safe.snap files are symlinks pointing into the userapps SVN, according to the scheme imposed on H1 by Jeff K in alog 5133.  If/when LLO adopts the same layout, the script should work there as well. 

Mark B.

The PR3 TFs that failed before (5191) ran fine when restarted with the typo fixed (the call to Matlab_TFs() had invoked model hsts_metal, not hlts metal):

Undamped: ^/trunk/HLTS/H1/PR3/SAGM1/Data/2013-01-21-1042830122_H1SUSPR3_M1_0p01to50Hz_tf.mat
Damped: ^/trunk/HLTS/H1/PR3/SAGM1/Data/2013-01-21-1042852645_H1SUSPR3_M1_0p01to50Hz_tf.mat

The damped plots are all fine. The undamped plots are rather noisy in L, P and Y, and the fundamental pitch mode (0.66 Hz) has pretty much disappeared in P and L. Probably needs a look over and another round of TFs.

Mark B.

Per alog 5200, starting DTT TFs on ITMy. Will do M0 and R0 in parallel.

ITMy in BSC1 is now suspended. Mark is running a set of quick TFs to check for rubbing, and once deemed healthy, we are back to alignment for both SEI and SUS.

The H1 DAQ SATABOY disk raid system in the MSR failed at 01:27 local time Sunday morning (the Sunday gremlin?). From that time onwards h1fw1 has not been able to write frames. We will leave the system in its broken state for LDAS to do some forensics. This is the system that was upgraded to Sol11 on Thursday, we are investigating if that had anything to do with the failure.

Yesterday we measured again the MC2/MC3 crossover frequency. Again, tecnical problems prevented us from going all the way to the actual crossover frequency, but we were close enough to estimate confidently it to be close to 100 mHz.  See attached plot.

Because of the peak right above 1 Hz and the observed instability if we try to increase the MC2 path gain, Matt designed a new filter to replace the elliptical one and roll off the gain before the offending peak (basically a LP filter at 1 Hz with at attenuation of at least 20 dB at 1.2 Hz, where the peak is). We then increased the MC2 loop gain by a factor to (0.005->0.01)

As a follow up to Hugh's post on Friday, I am posting some numbers to substantiate our claim that the BSC has not moved much from it's pre-move position. The attached DTT trends show the vertical CPS readouts from Jan 8th, after the chamber was vented, but prior to the initial ISI lock-up, up to our work on the 18th. Final cps numbers are kind of lost in the noise at the end, so final numbers are noted on the right side of each plot.

This weekend, I glued the second primary prism to the PR3 optic (the 3rd of its 4 prisms).  I'll note here that the temperature of the room was higher than normal due to the fact that the original air bake oven was moved into the cleanroom and started for a 200 deg bake load over the weekend (Greg/TCS, see alog below).  I used the Fluke probe and measured the RT to be 26.6 degC.  Our optic bonds specify a 6 hour 34 degC air bake in the new custom oven, so we'll need to watch dor dualing air bake ovens in the future.  I think we should start pulling work permits for this (and probably should have been in the past.)

The document contains a report on the recent measurements of hydrocarbons at the y
end. The principal results are the attenuation of the hydrocarbon pressure with time
and their significance for the future.

Test of an alog submission, reports of full disk problems.

[Paul, Cheryl, Giacomo]

Yesterday (Friday) evening the reading from WFS_A and WFS_B didn't quite seem to make sense, despite them having been aligned a few hours before by Cheryl. Paul and I went back to the IO table to do some more systematic testing. Bottom line is that quadrant 3 of WFS_A seems defective. It has a large offset and possibly a reduced sensitivity (although the fact that it has some sensitivity might be partially good news).

Note that this is the same unit that showed the anomalous heating described in entry 5131. The tests performed in that occasion were too superficial to notice the defect.

Although it might be initially possible to still use this sensor for some ASC test (by compensating for the offset and sensitivity in software), we will eventually need to remove WFS_A from the table and test it. To our knowledge, no spare is readily available.

This is the set of measurements we performed (values are in adc counts). We first (column 2) measured the dark current (note that for some reason the single quadrants have a sign inversion wrt the sum), then centered the beam on the WFS witht he IMC locked (column 3), then intentionally unlocked the IMC (column 4), then realigned the beam again (column 5) and finally re-locked the IMC (column 6). Note that the change in reading between IMC locked/unlocked in not necessarily due to beam wondering, as the shape of the beam itself is very different between the unlocked (mostly gaussian) and locked (mostly junk) states.

Mark B.

Deepak centered the OSEMs on PRM and PR3 so I rechecked settings and got the damping working. I noticed that the WD thresholds had not been set nor the filters enabled, so I fixed that and redid the safe.snap files.

Damped and undamped TFs for both will commence shortly and continue through the night. The respective Measurement Status indicators will light when a measurement is in progress.

The IMC lost lock tonight at about 4:00 AM local time. It is not clear why (no big drift in the control channels).

We had trouble recovering lock this morning, unitl we discovered that there were problems with the windows machine controlling the slow digital system.

After we reset the system, restore the working settings on the common mode board and readjusted the delay line value (I'm stressing this as the default setting after a reset of the system results in almost all the signal being in the Q quadrature, with a consequently unusable error signal... good to keep in mind!), we were able to reacquire lock very easily.