Using the newly setup PCal capabilites from the Control Room (thanks Dave!), I took some new photos of the ETMy optic post FC cleaning.  Although the IR only image is out of focus (I will take a new one tomorrow after refocusing the camera), the improvement if fairly evident.  The first photo is with green only locked, second photo is with IR only locked.  I used the same camera settings as were used pre-cleaning (F8, ISO 200, 30 sec. exposure, WB-cloudy).

J. Kissel B. Weaver

We've paused the ETMX guardian, changed the M0 coil driver state to acquire (i.e. H1:SUS-ETMX_BIO_M0_STATEREQ = 1), and we've changed the M0 P and Y TEST filter banks to have gain of +1.0, instead of the copies of the optic align gains they normally are. These are the things that we need for transfer functions that we don't initially remember to change after been away from it for a while. We pause the guardian such that the commissioning vanguard can still use the LSC CONFIGS without constantly messing around with ETMX's alignment offsets (which also screw up measurements).

We'll restore the configuration to it's nominal state once we're confident the SUS is free.

I've modified my sensor correction script, it now turns on the HEPI Z sensor correction on HAM3 instead of the ISI. This is hopefully temporary (re: .6hz weirdness on this chamber), and I haven't had a chance to test, so it may be broken, best of luck if it's needed. See my log 15591 for usage instructions.

Rick, Sudarshan, Dave:

We were successful in getting both PCAL cameras remotely controlled from the MSR. Each camera has its own mac-mini, on which the Sofortbild software is running. Just before the holidays Rick and I paired the Mac-Minis (MM) to their cameras via a local USB connection.

At the beginning of today, all systems were powered up but neither MM was seeing their cameras.

Sudarshan went to EY, and via the camera menu reconfigured the UT-1 network adapter. At this point camera h1pcalcamy established a connection to MM h1pcaly and Sofortbild took a picture (see earlier alog).

Sudarshan went to EX and reconfigured via the camera menu h1pcalcamx/UT-1. At this point h1pcalcamy established a connection with h1pcalx and Sofortbild took a picture.

At this point we are able to take ETMX and ETMY pictures simultaneously.

For a test, we then powered down the MM h1pcalx. This did not affect ETMY picture taking.

When MM h1pcalx was powered back up and rebooted, its Sofortbild could not establish an connection with h1pcalcamx (ETMY picture taking still good).

Sudarshan power cycled h1pcalcamx's UT-1. At this point h1pcalx re-established connection to h1pcalcamx but h1pcaly lost its connection to h1pcalcamy.

Sudarshan went to EY and power cycled h1pcalcamy's UT-1, now h1pcaly re-established connection with h1pcalcamy and ETMX picture taking is still good.

So if one or both Mac-Minis are power cycled, it appears we may have to power cycle both camera's UT-1 network adapters. This is not too bad, as these units are located outside of the camera enclosure, but it does require driving to both end stations.

I was testing using the MSR iMac to remote desktop to the MM. I have now started the remote desktop connection in the control room on the iMac to the left of the sci-mon station. We should leave that running for Betsy and Travis.

I've taken higher resolution measurements of the .6hz feature. I took 2 measurements over Sunday night, one measurement with a BW of 3mhz and one with a BW of .7mhz. Jeff walked me through calculating the magnitude of the peak and he says that the feature is non-stationary. The calculated magnitude for the .7mhz measurement is 1.17 (not sure of the units, but probably nm/s?), for the 3mhz measurement it's 1.66.  Attach image shows a close up of the peaK, X-axis window is from .55 to .65 hz. Blue trace is the .7mhz measurement, red is 3mhz measurement. If Keith Riles, or some one in DetChar could look at this more closely(specifically a high resolution spectrogram of this), it would be appreciated.

J. Kissel, J. Warner, D. Barker

In order to close out ECR E1400295, WP 4987, and Integration Issue 921, I've removed the remaining old guardian infrastructure from the TMTS, HSTS, HTTS, OMCS and HAUX. This required updating the userapps/sus/common/models/ directory (which removes the guardian block from the common library parts for the OMCS and TMTS), and removing the guardian blocks myself from the HSTS_MASTER.mdl, MC_MASTER.mdl, RC_MASTER.mdl, h1sushtts.mdl, and h1susim.mdl. Once removed, I recompiled, reinstalled, restarted, restored all affected models (basically, every suspension but the QUADs, BS, and P/SR3), and had Jim and Dave help me restore the SEI system and perform a DAQ restart, respectively. All common and site-specific model changes have been committed to the userapps repo.

All old guardian infrastructure has already been removed from the MEDM overview screens EXCEPT for the HSSS, i.e. the RMs, OMs, and IMs. I'll leave that for another day, but that should be that last thing LHO needs to do for this ECR, and it should require no more front-end code updates and/or code restarts.

Note all new safe.snaps have been captured for the affected SUS *before* the computer restarts. I'd confirmed that all *corner station* cavities (via camera views) are well aligned. I did *not* reaffirm the Y arm cavity, and of course this bit me. Sheila had changed the gain for the H1 SUS TMSY OPTICALIGN Pitch to be negative (see LHO aLOG 14161), but never captured a safe.snap for it. For some reason, bringing the TMS to SAFE via guardian reverted the gain to positive, flipping the sign of the alignment offset, which distorted the green / red beam pointing into / out of the cavity. We've since fixed the sign, then captured and commit a new safe. Subsequently *all* new safe.snaps have been committed.
 

I ran a quick P and V TF on the ETMy main chain, since we didn't get an under-vacuum set after the Dec pump down.  The P and V TFs line up well with the model so, so far so good.

Note, we've set the guardian state to PAUSE and the M0 CD STATE request to 1.0 from 2.0 (this switches the analog dewhitening in order to run TFs).

Now that HAM2 and HAM3 are both using the same ground instruments for sensor correction, I looked again at the coherence betwen their sensor correction channels, looking for some possible noise line at 0.6Hz.

I am using the input of the FIR filter bank:

H1:ISI-HAM2_SENSCOR_GND_STS_X_FIR_IN1_DQ

H1:ISI-HAM3_SENSCOR_GND_STS_X_FIR_IN1_DQ

The figure on the left shows the coherence between HAM2 and HAM3 channels.

The figure in the middle shows the transfer functions.

The figure on the right shows the ASDs of HAM3, and the incoherent part betwen HAM 2 and  HAM3 signals. It is well above the theoritical ADC noise, but I don't see any sharp feature at 0.6Hz.

Gerardo, Kyle 

Introduced purge/vent air into X-end sufficient to bring pressure up to 1/2 torr (at request of others) -> The desired result is to better couple suspension temperature to that of VEA room air 

Sudarshan, Rick, Dave:

We successfully got the EY PCAL camera (h1pcalcamy) to pair up with the MSR mac-mini (h1pcaly) this morning. When Rick and I tried this just before the holidays, we suspect too long a period of time expired before we could try the pairing (we physically moved the mac-mini between EY and MSR). Today Sudarshan used the camera's menu to reload the h1pcalcamy network configuration back into the UT-1 network adapter and the mac-mini connected automatically. I took a picture of ETMY (attached). We will test EY at regular periods today.

We will do the same with EX after lunch.

WP #4966

The following software has been updated for Ubuntu control room workstations:

awgstream (no change, recompile against new libraries)
gds (foton, diaggui, diag, chndump, awggui, dmtviewer, and others) fix bugzilla 288, 754, 755, 760, 761.
nds2-client  (nds2_channel_source, nds2-tunnel, nds-client-config, nds_query)
root (CERN root libraries and root)

OS X versions of the software will be updated next week.

Due to Dave's ADC reboots at EY, I've taken the TMSy and ETMy guardian states from ALIGNED to SAFE.

Turbo rotor left elevated for now

I've lowered the temperature setpoint for the XEND VEA back to 65F (down from 67).  In order to do so I have turned off the single stage of heat. We'll probably see some overshoot.

J. Kissel, B. Shapiro

The summary says most of it -- we've confirmed with two degrees of freedom of top to top transfer functions. Our best candidate is that the temperature in the VEA is too high. I tried adding a vertical offset in either direction, in hopes that we have enough range to recover the drooping, but it appears we do not. We'll first try restoring the XVEA temperature (if not surpassing it), but we may have to vent again. Cross your fingers.

Details:
Hoping that we could test the newly turned on H1 SUS ETMX ESD for functionailty, Brett and I noticed the optical lever did not appear centered in either the misaligned or aligned state. We could only restore the optical lever centering by putting the alignment offsets at 
                       P        Y       
Force Realignment    +21.3    -122.9
Original Aligned    +417.0      77.2
Change              +395.7     200.1
Further, I noticed that a P request would cause both P and Y motion, and vice versa. 

Betsy then trended the temperature in the VEA, see LHO aLOG 15877, and found it ~2 [deg F] or ~1 [deg C], which corresponds to about 100 [um] sag at the TOP mass (see T1400749, specifically LLO aLOG 15636. I note that this is at the TOP mass, because the lower stages will sag MORE, since there are cascading vertical blade springs.

We then, in the interest of time, took the transfer functions we know are the most sensitive to rubbing: P to P and V to V. These transfer functions are attached, for the various vertical offsets applied; see 2015-01-05_2358_H1SUSETMX_M0_Mono_WhiteNoise_*_0p01to50Hz.pdf. The vertical offsets were +/- 200 000 [ct], equivalent to most of the DAC range, which is roughly +/-115 [um_pk]. We can clearly see that the first several modes have shifted significantly, and several DOFs are cross-coupled in. Notable, however, is the highest-frequency modes are unaffected. This implies that the top-mass is free, and the lower masses are restricted, as seen in a QUAD's mode shapes. This makes sense, because for this most recent cleaning (see LHO aLOG 15744), the *only* activity in chamber was to clamp the test mass briefly for cleaning. Further, sadly, even with 100+ [um] of displacement in vertical, we could not move the the suspension free.

Note, we checked the reaction chain with P and V TFs, and it appears free and clear (see 2015-01-06_0152_H1SUSETMX_R0_WhiteNoise.pdf). We did not check the TMS, since it was not touched.

Finally, because we were amazed that the SUS had sagged more that 100 [um], and that we know that Betsy set the EQ stops when the VEA was at ~70 [deg C], Brett compared the top-mass displacement of the main chain, reaction chain, and TMS to gauge the amount of displacement compared to the other SUS in the chamber, which should have roughly comparable sag because they've the same blade springs and overall suspended mass (roughly). We attach two trends, EX_SAG_21DecTo5Jan.png (a 15 day trend that includes the pump down) and EX_SAG_22DecTo5Jan.jpg (a 14 day trend to zoom in on the long term temperature equilibration). From the 21st, one can see that the removal of air [the first big sharp drop], caused all SUS to drop. However, the main chain is expected to drop 170 [um] (see T1100616), and the reaction is expected to drop 100 [um]. While the reaction chain drops as expected, the main chain only drops ~125 [um], indicating a sort of bottoming out. Further, from the 22nd's trend, we see the temperature dependence is different (the bias has been removed for clarity). 

So, again. Bad news. Hopefully we can pull this SUS back up with temperature!

Last year, we thought we had found a configuration using sensor correction on HEPI that worked on HAM3. I was looking (Krishna was, too, he saw it first) at the summary pages over break and noticed that HAM3 still looked like it had the .6hz peak. I came in this morning, checked the configuration and did an on/off measurement, and HAM3 still has the same issue, even when we correct to HEPI instead of the ISI, contrary to what we found last time. See attached plot. Solids are measurement taken with sensor correction off, dashed are with HEPI sensor correction.