Thursday: AS WFS 90MHz centering (afternnon), Noise hunting afterwards

Friday: HWS/TCS morning, OMC noise/noise hunting afterwards

Saturday: SRC work

Sunday: -

Monday: Noise hunting

Tuesday: TCS work

I wanted to try using the buried STS at ETMY for sensor correction when it wasn't windy, to see if it worked. On the 22nd, for half an hour or so I switched it, and it seems to work. Attached spectra shows that using the buried STS gives similar performance to the STS in the building, at least when the wind is low, and we are using sensor correction at the micrseism. Red and pink are the ST1 T240 and buried STS when using the buried STS, dark blue and light blue are the ST1 T240 and the inside STS when running in our normal configuration. Both measurements were taken with the 90mhz blends, so all of the isolation between the T240 and ground between .1 and ~.2 hz is due to the sensor correction.

Unfortunately, when I tried this when it was windy, I got no isolation at all. I'm still looking into that.

at 11:10 PST h1boot generated an nfsd error (see below). All front end computers have locked up. We tried rebooting h1susauxh2 but h1boot is no longer permitting this (missing root file system). We need to first reboot h1boot, then all front end computers.

Cao, Elli

In order to use the ITMX HWS during TCS commissioning, we have removed the polarization sensor optics which were placed in the HWSX path on the HWS table by HAM 4.  (Placement of the polarization sensors is detailed in alog 24046.)  We removed the PBS and the HWSX_ALIGN_M1 mirror from next to the periscope and have bolted them out of the way behind the HWSX camera for the time being.  We also dumped the two sled beams coming through HWS_ALIGN_BS.  We can see the sled beam on the HWS.  I adjusted HWS STEER M10 (the mirror right before the camera) to center the beam on the camera, and did not touch the periscope mirrors.

Updated the corner Beckhoff code to incoporate the tidal servo engagement delay and the new EOM driver readback calibration.

Looks like there is a failing CPS at ETMY. I noticed on the Detchar sumary page, ETMY was not performing as well as the other BSCs above 1 hz, and has been for a little while (since about Feb 2nd). When I started looking at spectra, I saw that the Y CPS blend in was high at high frequency, digging down to individual sensors, it looks like ST2 H3 is to blame. LLO had a similar failure last year sometime. We should be able to stick a new card in and still run okay, or maybe we just need to check some connections. Probably not a big deal for now, but we should address this soon. Attached plots shows the CPS for St2 (first plot) and St1(second). Green on the first plot is the bad sensor. The St1 sensors look okay, though H2 (blue, second plot) looks a little high as well.

WP 5744, II 1206, FR 4418

Code oversite fixed.  Guardian restarted.  All HPIs are good.  Tested on HAM6, positive function.  ISI guardians not restarted--should do next Tuesday to confirm no issues there.

files updated:

hugh.radkins@operator3:~ 0$ userapps
hugh.radkins@operator3:release 0$ cd isi/common/guardian/
hugh.radkins@operator3:guardian 0$ svn up
U    isiguardianlib/isolation/const.py
U    isiguardianlib/isolation/states.py
U    isiguardianlib/damping/states.py
Updated to revision 12715.

Here are the changes and additions to fix the oversite

hugh.radkins@operator3:guardian 0$ diff isiguardianlib/damping/states.py isiguardianlib/damping/states.pybuhr
 

>         if (iso_const.ISOLATION_CONSTANTS['SWITCH_GS13_GAIN']) & (top_const.CHAMBER_TYPE != 'BSC_ST1'):

<         if (iso_const.ISOLATION_CONSTANTS['SWITCH_GS13_GAIN']) & (top_const.CHAMBER_TYPE != 'BSC_ST1') & (top_const.CHAMBER_TYPE != 'HPI'):
---
hugh.radkins@operator3:guardian 1$ diff isiguardianlib/isolation/const.py isiguardianlib/isolation/const.pybuhr
139,144d138
<             GS13_GAIN_DOF = ['H1', 'H2', 'H3', 'V1', 'V2','V3'],
<             SWITCH_GS13_GAIN = False,
<             FF_DOF = dict(
<                 FF = [],
<                 HPI_FF = [],
<             ),
 

hugh.radkins@operator3:guardian 1$ diff isiguardianlib/isolation/states.pybuhr isiguardianlib/isolation/states.py
319c319
<             if (iso_const.ISOLATION_CONSTANTS['SWITCH_GS13_GAIN']) & (top_const.CHAMBER_TYPE != 'BSC_ST1'):
---
>             if (iso_const.ISOLATION_CONSTANTS['SWITCH_GS13_GAIN']) & (top_const.CHAMBER_TYPE != 'BSC_ST1') & (top_const.CHAMBER_TYPE != 'HPI'):
321c321,322
<             iso_util.turn_FF('OFF', iso_const.ISOLATION_CONSTANTS['FF_DOF'])
---
>             if (top_const.CHAMBER_TYPE != 'HPI'):
>                 iso_util.turn_FF('OFF', iso_const.ISOLATION_CONSTANTS['FF_DOF'])
490c491
<             if (iso_const.ISOLATION_CONSTANTS['SWITCH_GS13_GAIN']) & (self.has_requested_gs13_gain_switch == False) & (top_const.CHAMBER_TYPE != 'BSC_ST1'):
---
>             if (iso_const.ISOLATION_CONSTANTS['SWITCH_GS13_GAIN']) & (self.has_requested_gs13_gain_switch == False) & (top_const.CHAMBER_TYPE != 'BSC_ST1') & (top_const.CHAMBER_TYPE != 'HPI'):
494c495,496
<                     iso_util.turn_FF('ON', iso_const.ISOLATION_CONSTANTS['FF_DOF'])
---
>                     if (top_const.CHAMBER_TYPE != 'HPI'):  
>                         iso_util.turn_FF('ON', iso_const.ISOLATION_CONSTANTS['FF_DOF'])
 

JRPC Notes

• LLO vent 3/2 - mid June
• Engineering Run for LHO
• No LHO vents planned, commissioning has list of tasks to be discussed

SEI

• HEPI Guardian work (Hugh)
• FRS ticket moved to Hugh

SUS

• HAM3 SUS Sattelite box work (Richard)

CDS

• Sattelite box (noted above)
• Software part of hardware watchdogs (Jim B)

Facilities & VAC

• CP3 still being fed manually (Kyle)
• X2A cable short for ion pump (Kyle)
• Laser safe (Richard will transition) at EX for pulling cable...this afternoon
• Soft close of X&Y arm GVs for snorkel lift crane over X-arm beam tube this morning (Bubba)
• Fire alarm trouble alarms in the corner & staging bldg (Richard/Bubba/Fire Dept

(45) FRS Reports ongoing, and NO new FRS reports (Vern)

Operating Mode:  Engineering 

LVEA Laser SAFE

H1 was not locked & Guardian was in Ready state when I walked in.  

Was notified Bubba was on the floor doing some craning.  Concurrent work to be done with this activity:

• HAM3 SUS Sattelite box work (Richard)
• HEPI Guardian work (Hugh)
• Karen cleaning up crane work mess in the LVEA 

Switched Operating Mode: Corrective Maintenance

Evan, Den

Tonight we asked ourselves a question whether 1/f (or 1/f^2) noise, seen in DARM around 100Hz, comes from the OMC or not. We put a bandstop filter to the DARM control loop at 92-127Hz and made a correlation measurement between AS 45 WFS SUM and OMC PDs at this frequency band. The idea is that if there is any OMC noise coherent between 2 OMC PDs, it should not be present at the RF detector.

Attached plot shows the results of the measurement. Cross-spectrum between WFS and OMC PDs around 100Hz is almost the same (15% lower) as cross-spectrum between two OMC PDs. We integrated for 3.5 hours and AS 45 WFS SUM channels are not DQ. We can significantly improve the measurement if we record these channels and integrate for ~20 hours.

At the current precision of the correlation we can not say that noise around 100Hz comes from the OMC. Right now it looks vice versa.

Today Keita and I spent some time thinking about OMC length noise, there will be an update coming soon with more information and a noise projection.  

We spent some time looking at some nonlinear behavoir noise in the drive to PZT1.  Our dither frequency is 4100 Hz, and looking at the low voltage PZT monitor we can see a small 8 Hz and a larger 16 Hz comb.  There is also other non stationary noise in the monitor, and a broad peak at 12.7 kHz.  We have moved the dither line frequency to 4100.21 Hz, so if this was the cause of the 16 Hz comb in DARM we would now expect it to be more like a 16.84 Hz comb.  Evan Goetz tells us that we need 15 minutes or more of data in low noise to evaluate if this has changed any combs in DARM. 

We have just reached nominal low noise at 3:14:34 UTC Feb 25th, although the low frequency noise (below 50 Hz) is worse than normal.  I've temporarily changed the dither frequency in the OMC guardian, so if there is a longer lock later tonight it should also have this changed dither frequency.    (If anyone wants to double check what the dither frequency is, the channel is   H1:OMC-LSC_OSC_FREQ

Den, Patrick, Evan

During IX coil driver investigations yesterday, we rang up some violin modes to very high amplitude (~4×10⁻¹⁴ m rms in DARM, about 4 orders of magnitude higher than our optimal, damped mode height).

The existing violin mode damping settings, which consisted of a few wide filters meant to actuate on multiple modes simultaneously, were damping some of the modes while causing others to ring up.

This is not the first time we have been hoist with our own wide-bandwidth pitard. Additionally, we have more the enough filter modules per test mass to damp each first harmonic individually, which alleviates the problem of having to find a filter to damp multiple modes simultaneously.

There were five IX modes visible in DARM on rf readout. For these five modes, we constructed narrow, individual damping filters (8th order butterworths). The settings are as follows:

Note the narrow bandwidth of the filters for the two 501.2 Hz modes.

These use the IX L2 damping SFMs, numbers 1 through 5. The corresponding OAF monitor filters have been updated as well.

That means there are three other first harmonics on IX that are yet to be damped.

Per work permit 5741 began the process of modifying all Suspension Satellite Amplifiers.  Drawing D0901284-v4 calls for the addition of Cap C601(10uF) and C602 (.1uF) between the -17V to Ground around U503 the Negative Regulator VEE1.
Today with Ed M. Soldering away in the lab we were able to complete all of Han2 units.
Complete are:
MC1, MC3, PRM, PR3, MMT1, MMT2, SM1, SM2  All Stages.

We did have a problem with two Sat Amps. One shared between MC1 and MC3 and the one for  MMT2,a trace blew when it was powered up.  So replaced SN 1100117 with SN S1000287 and SN1100068 with SN1100066.

DaveB restarted the guardian computer to correct a tconvert issue, WP 5740.

After this, every HEPI platform guardian reports this error:

2016-02-23T17:52:24.50084 HPI_HAM1 [ROBUST_ISOLATED.enter]
2016-02-23T17:52:24.57873 HPI_HAM1 W: Traceback (most recent call last):
2016-02-23T17:52:24.57874   File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/worker.py", line 459, in run
2016-02-23T17:52:24.57875     retval = statefunc()
2016-02-23T17:52:24.57875   File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/state.py", line 240, in __call__
2016-02-23T17:52:24.57876     main_return = self.func.__call__(state_obj, *args, **kwargs)
2016-02-23T17:52:24.57876   File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/state.py", line 240, in __call__
2016-02-23T17:52:24.57877     main_return = self.func.__call__(state_obj, *args, **kwargs)
2016-02-23T17:52:24.57877   File "/opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/decorators.py", line 86, in wrapper
2016-02-23T17:52:24.57878     return func(*args, **kwargs)
2016-02-23T17:52:24.57878   File "/opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/decorators.py", line 86, in wrapper
2016-02-23T17:52:24.57879     return func(*args, **kwargs)
2016-02-23T17:52:24.57879   File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/state.py", line 240, in __call__
2016-02-23T17:52:24.57880     main_return = self.func.__call__(state_obj, *args, **kwargs)
2016-02-23T17:52:24.57880   File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/state.py", line 240, in __call__
2016-02-23T17:52:24.57881     main_return = self.func.__call__(state_obj, *args, **kwargs)
2016-02-23T17:52:24.57882   File "/opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/isolation/states.py", line 490, in run
2016-02-23T17:52:24.57882     if (iso_const.ISOLATION_CONSTANTS['SWITCH_GS13_GAIN']) & (self.has_requested_gs13_gain_switch == False) & (top_const.CHAMBER_TYPE != 'BSC_ST1'):
2016-02-23T17:52:24.57883 KeyError: 'SWITCH_GS13_GAIN'
2016-02-23T17:52:24.57883
2016-02-23T17:52:24.57888 HPI_HAM1 [ROBUST_ISOLATED.run] USERMSG: USER CODE ERROR (see log)
2016-02-23T17:52:24.62596 HPI_HAM1 ERROR in state ROBUST_ISOLATED: see log for more info (LOAD to reset)
 

I've reloaded and restarted both HAM1 and HAM6 and the error returns.  It sure looks like it is related to the updates to get the ISI guardian to switch the GS13 gains depending on the state.  I can not find documentation (logs) that the HPI nodes have been restarted since the gain switching updates which were intended for the ISI.

I've elected to not attempt any code corrections at this time; I suspect Hugo will correct this easily.  Meanwhile, I don't know if the guardian will actually function if it trips.  This can be done easily however with the command scripts isolating to level1.

Den, Sheila, Evan

~> We tried reverting to the old QPD offsets (the ones we used throughout O1) for the soft loops and the PRM pointing loops. These seemed to make the recycling gain slightly worse, and did not improve the jitter coupling. This indicates that (as we had suspected) these offsets are no longer good to use.

~> We measured the 9 MHz oscillator phase noise coupling into DARM. This had been done previously (19911), but with a suspicious calibration and in a way that also drove the 45 MHz phase. This time, we used the OCXO to drive both the harmonic generator (bypassing the 9 MHz distribution amplifier) and to serve as a reference for an IFR/OCXO PLL with a >40 kHz bandwidth. The IFR is used to drive the 9 MHz distribution amplifier. The error point of the PLL was offset in order to maintain the relative time delay of the 9 MHz and 45 MHz signals. When we relocked, we found that the 18 MHz and 27 MHz signals had flipped sign, but otherwise the interferometer locked normally. However, there was a great excess of 45 MHz noise in DARM (worse even than before we installed the 9 MHz bandpass). Nevertheless, we were able to drive enough to see the effect of 9 MHz phase modulation in DARM. The coupling is roughly 2–4×10⁻⁶ mA/Hz above 100 Hz.