- Patrick, Cheryl, Jeff, Kiwamu 

Morning spent with Patrick and I investigating IMC poor locking, i.e. only brief locks.  Keita started us on the issues of too much gain on H1:SUS-MC2_M2_LOCK_L_GAIN, which he changed form 0.2 to 0.008, in order to get any locking last night. 

Looked at Stefan's autolock script and the channels it changes, and all was OK. Compared MC Common Mode channels/settings, all was OK. 

Tracing the GAIN path backward, I found we could lock with autolocker settings and MC2_M2_LOCK_L_GAIN at 0.2, if I lowered the overall MC2 LSC gain from 1.0 to 0.15. 

Jeff joined us, we burt restored h1lscepics and MAGICALLY the IMC locked with the MC2 LSC gain back at 1.0!  Somehow that fixed the gain issue, though we have not located the exact setting that changed.

At this point Jeff reenabled HAM2 ISI and set it to Level 3 isolation. This helped with 1Hz oscillation seen in REFL. Then we set HAM3 isolation to Level 3 from Level 2, and further decreased the 1Hz noise. This allowed for a long lock and I was able to align manually to get REFL down to 240 and MC TRANS around 2200.

We tried to engage WFS, but found it driving the lock to a bad place, REFL = 800. Kiwamu arrived, and is now working on WFS.

WFS are not well aligned, and MC2 TRANS QPD is high in pitch.  This means the IMC alignment is good for REFL, but not for the IMC as a whole, which could be my alignment changes to MC1, or changes in the PSL input beam pointing from PZT's being turned off and on yesterday (see NOTE), or changes to the PSL input beam pointing from temperature change made by Rick in the PSL enclosure, or all 3 combined.

NOTE... I ran scripts attached to the WFS medm screen yesterday, which apparently have NEVER been run here before, and were written at LLO.   Why do we do this to ourselves?  I was telling Jeff the script to turn off ASC turns off the PZT offsets WHICH SHOULD NEVER BE TURNED OFF!!!  Now I learn from Kiwamu that no one has ever run any of those scripts at LHO.  Are these scripts even used at LLO?  This sort of thing is a death trap for an IFO.

Currently Kiwamu is working of WFS.

The staging building X1 triple test-stand has been configured ready to accept OMC (OMCS) suspensions for Phase 1b testing. This procedure is similar to that which I had previously carried out on the LLO triple test-stand (see LLO aLog entry 6842).

I've remotely logged-on and set-up the test-stand as follows:-

1) svn'd up the /ligo3/svncommon/SusSVN/sus/trunk/OMCS$ directory

2) svn'd up the /ligo3/svncommon/SusSVN/sus/trunk/Common$ directory

3) Started the x1sushxts05 model, thanks to the local efforts of Jim Batch (see LHO aLOG entry 7727).

4) Burt restored the most recent working triple suspension configuration from /opt/rtcds3/tst/x1/userapps/release/sus/x1/burtfiles/20120911_x1sushxts05_PRM.snap

5) Reset all stage OSEM INPUT FILTER gains and offsets to their default values, +1 , and -15000 counts, respectively.

6) Used updated ligo3/svncommon/SusSVN/sus/trunk/OMCS/Common/MatlabTools/make_susomcs_projections.m Matlab script to populate OSEM2EUL and EUL2OSEM matrices with elements for OMCS geometry, using the "fill_matrix_values" script, as follows:-
- fill_matrix_values('X1:SUS-HXTS_M1_OSEM2EUL',OSEM2EUL.M1)
- fill_matrix_values('X1:SUS-HXTS_M1_EUL2OSEM',EUL2OSEM.M1)

7) Copied M1 DAMP filter block and gains from LLO triple test-stand.

8) Taken a new safe BURT snapshot, which has been committed to the svn, /opt/rtcds3/tst/x1/userapps/release/sus/x1/burtfiles/20130911_x1sushxts05_OMC.snap

Finally, to expedite testing, I've copied over some of the most relevant DTT OMCS templates from X2, in which the excitation amplitudes have already been tuned to optimize coherence in all 6 DOFs. These DTT templates (and accompanying exported ASCII data) are available on the svn as follows:-

X1/OMC/SAGM1/Data/2013-09-11_1200_X1SUSOMC_WhiteNoise_L_0p1to50Hz.xml
X1/OMC/SAGM1/Data/2013-09-11_1200_X1SUSOMC_WhiteNoise_T_0p1to50Hz.xml
X1/OMC/SAGM1/Data/2013-09-11_1200_X1SUSOMC_WhiteNoise_V_0p1to50Hz.xml
X1/OMC/SAGM1/Data/2013-09-11_1200_X1SUSOMC_WhiteNoise_R_0p1to50Hz.xml
X1/OMC/SAGM1/Data/2013-09-11_1200_X1SUSOMC_WhiteNoise_P_0p1to50Hz.xml
X1/OMC/SAGM1/Data/2013-09-11_1200_X1SUSOMC_WhiteNoise_Y_0p1to50Hz.xml

This should now provide sufficient infrastructure to proceed with Phase 1b testing of the OMC suspensions.

I have the x1sushxts05 model running now. 

In X1SITEMAP_TRIPLES.adl, the macro substitution used for the 05 models used FEC=17 instead of FEC=18.  I changed the macro to use FEC=18 for both HLTS05 and HSTS05, which allowed me to open a working X1SUSHXTS05_GDS_TP medm screen.  This in turn allowed me to press the BURT button after the X1 IOC started, which allowed the model to continue to run.

It's been broken for quite some time, so I don't know why the wrong FEC number was in the X1SITEMAP_TRIPLES.adl file.

I note that there appears to be an excitation test point 119 that shows up on the GDS_TP screen.  When I run diag, it indicates no test points are set, and no excitations are running.  Not sure where it's coming from, but if it bothers you I can try harder to get rid of it.  It'll probably involve rebooting stuff.

I restarted the daq. It was configured to read the Beckhoff GPS EPICS channels from the timing master with a new ini file (H1EDCU_GPS.ini)

Cheryl reported that IMC wouldn't lock and WFS was breaking the lock.

When I came into the control room the DC alignment of MC seemed OK. Disabled ASC output and manually enabled the PZT offset.

MC2 M3 watchdogs were found tripped, and assuming that this stage is necessary for locking I reset the watchdog.

After this IMC would lock but it lasted for 3 seconds that's incidentally the same as the ramp time for M2 and M3 lock filter. The lock was repeatedly broken by an oscillation at a few Hz that develops right after M2 and M3 lock filters were turned on.

I disabled the L-L element of the drive align matrix of M2 and M1, and the lock would last until the M3 coils rail.

Apparently something changed between this morning and afternoon, and now I had to make the M2 and M1 gain ridiculously small, otherwise a few Hz oscillation just kills the lock.

For the moment I changed the setting in Stefan's lock script such that H1:SUS-MC2_M2_LOCK_L_GAIN is 0.008 (VS the nominal 0.2) and M1_LOCK_L_GAIN is 0.3 (VS the nominal 1). I didn't fix anything, whatever the problem is it's still there, and the lock lasts for only a few minutes at most until M3 coils rail.

I haven't done anything to WFS, I don't know if it was doing something bad, but the DC alignment right now is OK.

One of the BIO bit representing the status of the analog dewhitening filter of the TMSX is either not displaying the right value, or the dewhitening filter is not switched to the requested state, cf bit 8 (RT LP) of picture attached. I will check tomorrow with Richard to see where the problem could come from.

J. Kissel

Here're some spectra that are the same as what Vincent had posted, but focused on the LF and RT OSEMs, and calibrated into [um/rtHz]. I show four configurations (each config has the ISI/HPI in its best performance state):
(1) As we discovered the problem, with all SUS damping loops closed (shows giant feature)
(2) With only V loop turned off (still shows giant feature)
(3) With V and R loops turned off (does NOT show giant feature)
(4) With V and R loops turned off, and with a broad-band 1000 [ct] excitation sent out of the RT COILOUTF bank (does NOT show giant feature).

Note, I also measured 
(5) With only R loop turned off (still showed giant feature), 
(6) With V and R loops turned off, and with a broad-band 1000 [ct] excitation sent out of LF COILOUTF bank (still did NOT show giant feature), 
(6) With V and R loops turned off, and with a broad-band 100 [ct] excitation sent out of LF COILOUTF bank (still did NOT show giant feature), 
(6) With V and R loops turned off, and with a broad-band 10 [ct] excitation sent out of LF COILOUTF bank (still did NOT show giant feature), 
but they were redundant with the above information, and would have over-crowded an already crowded plot.

First page of the attachment shows configurations (1)-(4). Second page shows the ASD of the 1000 [ct] excitation, meant to look roughly like a damping loop signal. 

Given that we only see this feature with the damping loops that involve LF and RT ON, and we don't see it by turning the damping loops OFF and driving an artificial, non-OSEM-sensor, signal AND we know it's not a loop instability, I think we can narrow down the source to something in the analog sensing chain that is oscillating.

We should replace the M0LFRT, R0LFRT satamp tomorrow, and see if this feature goes away. I blame the satamp, because the satamps have plagued use wih a terrible history of oscilliations.

I bet $1.00 USD.

If anyone is betting against, please please please, shoot me more ideas on how to narrow down the source further.

J. Kissel, V. Lhuillier

With all SUS damping loops closed and with the ISI in full isolation, I've taken open loop gain transfer functions of the H1 SUS ITMY's Vertical and Roll Level 2.1 damping loops. As predicted by design, and by what was seen on H1 SUS ETMY there is plenty of phase margin, and no features around 6.18 [Hz].

NEXT: Determine whether it's the coils or the sensors, or some nasty interaction between them.

Sebastien, Jim

We are currently testing the BSC-ISI unit #6 in the staging building. The 2 stages are unlock and balanced, everything seems to be well connected.

The power spectra show something wrong on GS13-V1 and GS13-V3 (see figure attached).

After further investigation, the issue seems to be 2 bad cables. They will be change tomorrow.

In the optimal laser configuration (current = 1.503A, see alog7695), the power before ALS-FI2 was measured to be 39.7mW, while the power after the FI was measured to be 37.6mW. Thus, the throughput of the ALS-F12 was about 94.7%. The first jpg (532nmALSfI2FullCurrent.jpg) shows the beam profile after the ALS-FI2.

The first pdf (BeamProfile532nmRefALSFI2.pdf) is a graph displaying the mode measurement of the 532nm beam with ALS-F12 as a reference. Meanwhile, the second pdf (BeamProfile1064nmRefALSM1.pdf) is a graph displaying the mode measurement of the 1064nm beam with ALS-M1 as a reference. Using the 13.5% width (or 1/e^2 diameter) of both the horizontal and vertical profiles, the radii for the two profiles were determined at various distances from the respective reference points. In addition, the graph includes error bars of one standard deviation. A line of best fit was produced, and the difference between the line of best fit and the data points was plotted in the lower portion of both figures.

Kyle - replace transducer at EX

TMSX measurements lst night

TMSX - Keita and Corey in AM - Betsy, Jeff, Andres in PM - gone now - TF running

BS - alignment in LVEA test stand - some alarms

IMC - Jamie working on Guardian, IMC has drifted out of alignment, WFS won't engage, left off waiting fix

After modifying the signs of the gains from the medm, I took a new set of transfer functions of phase 3b (under vacuum) M2 mass of the beamsplitter over the last week end (cf alog 7677 and 7693). During the measurement, the ISI was damped. The plots of the attached document are described below :

- H1 SUS BS M2-M2 undamped transfer functions phase 3b with corrected gain signs (Sept 06th 2013 19:00, in black) compared against H1 SUS BS M2-M2 undamped tf (Sept 06th 2013 15:00, in orange) against the model in blue.

The last measurements are showing a very good match with the model

Will fix tomorrow (after wasp hive relocated)

Last Friday, I was mainly searching for the 6.18Hz in the HEPI and ISI actuators/sensors. There was no real conclusion from the study except that the 6.18Hz was not coming from HEPI and it was visible mainly in the vertical degrees of freedoms.

Then, the SUS was suspected. Few tests were done:
- The damping loop and the coil drivers were unplugged. The 6.18Hz didn’t show up in the ISI spectra.
- The coil drivers were re-plugged. The 6.18Hz didn’t show up in the ISI spectra.
- Then, the damping loops were turned on independently. It appears that main chain damping loops using the left and right OSEMs create the vertical motion at 6.18Hz. Then, this motion is transmitted to the ISI and spectra show a 6.18Hz feature.

Two MO OSEM sensor spectra are presented in attachment. In both cases, the ISI is isolated.
- Without SUS Damping (first figure)
- With SUS Damping

J.K and A.P are taking open loop transfer functions.

During the hunt, I saw some excess noise on R0 OSEM RT

Added h1iscex channels to the DAQ. 

Stopped h1fw1 writing frames and un-mounted disk system. Dan then replaced both controller cards on the MSR SATABOY RAID. Once the file system was available again, I re-mounted and restarted h1fw1. The data gap on this frame writer is from 11:33 to 13:43 local time. h1fw0 was writing frames the whole time.

Created a new MEDM screen to show GPS diagnostics for the Timing Master unit. It was attached to the SITEMAP via a new SYS related display button. On the next DAQ restart these channels will be added to the frames.

Restarted the h1fe-cds EPICS gateway to see if this sped up the reconnection of MEDM to the Guardian IOCs. It did help somewhat but the reconnection is still slow.

We're done with in-vac cable test.

Tomorrow Corey needs to re-rout the cables on ISI back to the intended position (i.e. closer to the real feedthrough).

Phase 3b spectra have been measured on the beamsplitter after Jeff Kissel implemented the new filters.

The attached pdf are showing a comparison between spectra taken in March 26th phase 3a (in blue), and May 17th phase 3b (in green) with the suspension damped (first pdf) and undamped (second one). The ISI was damped.

Data, measurement lists and figures have been commited on the svn