This is the analysis of a quiet stretch of data in SR3 oplev from yesterday. 

I checked to make sure of the following:

a) Alignment sliders have not been moved during this period 

b) There is no actuation to SR3 at this time. 

c) The signal levels on all SR3 quadrants are okay, that is the quadrants are not saturated. 

I am posting here screenshots of plots of:

1) the time series for 16 hrs at 1 sec sampling rate

2) the time series for a 2 hr stretch with 256 Hz sampling from within the 16hr stretch

3) a RIN spectrum of the SUM signal for the 16 hrs sample going down to 10^-3 Hz to 0.1 Hz

4) a RIN spectrum of the SUM signal for the 2 hrs sample going from 0.1 Hz to 100 Hz

5) A spectrogram of the 2 hrs signal showing the broadband noise injections due to the glitches in the laser.

Note:

All data for this analysis is available in /ligo/data/oplevs  at LHO. File name LHO_SR3_before_LD_Fix.mat

OPLEV Overview Screens UPGRADED

Following Stuart Aston's suggestions I have added:

1)  a bar indicator to show the SUM value. This enables us to tell at a glance if the value is close to  saturation

2) a set of menu buttons to call data analysis tools like Diaggui and Dataviewer, which open corresponding templates so that we can look at time series and spectra of relevant channels.

3) a button to every oplev screen which accesses the SUS or ISI corresponding to the Oplev, so that, if the oplev is misaligned, the corresponding suspension or table can be reached directly from this screen.

SITEMAP updated:

I have removed the menu items in ISI tab for reaching individual HAM ISI Oplevs.  As we now have the overview screens and also command line scripts to access individual oplev screens I have reduced the complexity of SITEMAP by removed these menu items.

All screens have been committed to the svn and can be customised at LLO

Screenshots attached:

Removed REFL_B from end station EtherCAT systems. This completes ECR E1500169 and issue tracker 1025 at LHO.

Greg G, Nutsinee K. Matt H, (Richard M)

So the plan going into today was to get the CO2Y laser going and to clear the AOM fault on the CO2x table

Things didnt quite go as I hoped though. Due to some miscommunication, the reason that the rotation stage on CO2Y did not work is that it was deliberately unplugged. It had been in this state for quite some time apparently (many months). This is apparently due to the issue still having with it still blowing diodes in the control box. But Richard M connected it up and we confirmed that the rotation stage works as expected. 

We then proactively decided to check out the power connection for then CO2Y laser at the table enclosure feedthrough. Turned out that it was barely connected. We tried once again trying to connect it securely and it sort of looks like it is. Then when we tried to turn the laser on, I wasnt seeing the signs that it was lasing like it should. Its very low power when look at the beam on the cards. 

We went and checked out the power supply for CO2Y and as expected for what I am seeing its drawing far less current than it should (see pic). Should be drawing about 22-24 Amps but is only drawing ~12 amps. In fact the laser is drawing less than this (more on that in a bit). So there is still a problem. Unsure if its the connector or if the laser RF driver. So as a next step Ive asked Greg to do as we did as a temporary solution at LLO and cut a big hole in a spare feedthrough so that we can make as good a connection with the laser power cables as possible and cable tie them together to make sure they dont come apart and to rule that out before swap the laser RF driver again. Note: We really need to come up with a better feedthrough solution for these lasers (I know its been low on peoples lists for awhile). 

Now back to the power supplies. Turns out my last alog about the power supply setup was slightly wrong (Greg is going to write an amendment). Turns out that an individual power supply is still powering both the CO2 laser and the AOM driver for a table. So when we "turn off" the  CO2Y laser at the MEDM screen, the laser power supply shows that it is still having 2.5Amps drawn from it. In this standby mode it should only have 0.7Amps drawn so the AOM driver is drawing 1.8Amps (this driver has not faulted).

Now I had thought that the CO2X laser and AOM supplies had been split, but I am wrong here and they are on the same supply as well. The Kepco power supply that I thought should be used for the AOM driver is being used to power the little Phoenix interlock box. This seems a waste of a Kepco DC power supply for this and like I said I thought these should be for the AOM drivers. I need to go back and look at how LLO is wired and talk to Aidan, but I do suggest that a window be found soon to bring down both TCS tables so that they can be wired up correctly. Also this would help with below problem

Now also because the laser and the AOM driver is currently coming off the same supply, because the CO2X AOM driver has faulted the way to reset this is to power toggle it. But in this current setup this also turns off the laser and I didnt want to do that to then have to allow the laser to stablise again. So CO2X is left as status quo. 

So the current situation is:

CO2x

Laser and AOM driver powered off same supply

Laser running

AOM driver faulted

Dont know about if rotation stage working (assume it is)

CO2Y

Rotation stage now working

laser and AOM driver powered off same supply

Issue with laser and current being drawn so laser turned off at the MEDM screen and at the control box and keys in key safe

Beam blocked in two locations after HWP (done on earlier visit by Alastair)

What i think we need to look at in the very near term:

Modification to feedthrough to see if can get temporarily a better connection on power cable

Connecting up TCS electronics (and this includes the phoenix interlock board) correctly

Looking at a better feedthrough arrangement that is more sturdy. 

J. Kissel, D. Barker

After Dan made changes to the OMC's ASC scheme (LHo aLOG 17325), and Dave subsequently restarted the h1asc front-end model this morning (I don't know why, hopefully an aLOG is pending by the author of the change, maybe to do with WP #5112), which uncovered a flaw in the new OM3 IPC receiver connections. T'was a simple copy-and-paste bug in the channel naming, so I just went ahead and fixed it. We await a DAQ restart to close out the work.

Details:
Attached are before vs. after screen shots. Forgive the terrible Simulink vs. Ubuntu graphics rendering, but the bug was in the OM3 stuff at the bottom, so the bad rendering doesn't affect my demonstration. Dan was presumably copying and pasting the OM1 / OM2 IPC senders, and forgot to remove the simulink-added "1" and "2" to the end of the name.

Before restarting the model, I updated the h1sushtts SDF file, seeing that the majority of the changes were alignment offsets and corresponding tramps. I presume the alignment settings are good, given the Megaparsec report from last night (see LHO aLOG 17411).

After restarting the model, I've committed the latest version of the model and the SDF capture to the userapps repo.

J. Kissel, E. Merilh 

Ed and I restarted the DAQ / framebuilder / data-concentrator ar 12:42p PDT or 19:42 UTC to absorb changes made by Daniel for the end station Beckhoff and the ASC front-end models (again, I presume an aLOG is pending, I think it's related to WP #5112), as well as the changes I made to clean up the h1sushtts IPC problems (see LHO aLOG 17428).

JimW tweeked the level2 isolation controllers to reduce the gain a few around 100hz.  This morning we got a chance to use them for a time.  The Stage stil can NOT be isolated while the Mich Locks or unlocks without tripping the stage2 watchdog.

The first attachment is an hours trends where I picked dtt start times.  The second attachment is the dtt of MICH_OUT and the ground spectra.  With what looks like a very similar ground motion during the two measurements, there does appear to be reduced output of the MICH Loop with the Stage2 Isolating in the few hz to few 100mhz band.  Good to do similar with more IFO signals when available but it seems this is an improvement.

This time I caught it on the test stand with better error reporting.

Test stand code error:

Mar 24 10:14:29 conlog-test-master conlogd: Channel Access Exception: Channel Name: Unavailable, Native Type: Unavailable, Native Count: 0, Read Access: Unavailable, Write Access: Unavailable, IOC: Unavailable, Message: Virtual circuit disconnect, Context: h1asc0.cds.ligo-wa.caltech.edu:60755, Requested Type: TYPENOTCONN, Requested Count: 0, Source File: ../cac.cpp, Line Number: 1214
Mar 24 10:55:15 conlog-test-master conlogd: ../database.cpp: 661: insert_dbr_string_value_execute: Error executing m_p_insert_dbr_string_value_prep_stmt. Parameters: H1:SYS-MOTION_Y_SHUTTER_A_NAME, 1427219715488583185, 0, �, 0, 0.
Mar 24 10:55:15 conlog-test-master conlogd: ../conlog.cpp: 314: process_cac_messages: MySQL Exception: Error: Incorrect string value: 'xC0' for column 'value' at row 1: Error code: 1366: SQLState: HY000: Exiting.
Mar 24 10:55:16 conlog-test-master conlogd: ../conlog.cpp: 346: process_cas: Exception: boost: mutex lock failed in pthread_mutex_lock: Invalid argument Exiting.

Seems to have non ascii characters in the value of the H1:SYS-MOTION_Y_SHUTTER_A_NAME channel.

Production code error:

Mar 24 10:14:29 h1conlog1-master conlog: Channel Access Exception: Channel Name: Unavailable, Native Type: Unavailable, Native Count: 0, Read Access: Unavailable, Write Access: Unavailable, IOC: Unavailable, Message: Virtual circuit disconnect, Context: h1asc0.cds.ligo-wa.caltech.edu:60755, Requested Type: TYPENOTCONN, Requested Count: 0, Source File: ../cac.cpp, Line Number: 1214
Mar 24 10:17:01 h1conlog1-master CRON[21576]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Mar 24 10:39:01 h1conlog1-master CRON[21583]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Mar 24 10:55:25 h1conlog1-master conlog: ../conlog.cpp: 301: process_cac_messages: MySQL Exception: Error: Incorrect string value: 'xEC>xBF' for column 'value' at row 1: Error code: 1366: SQLState: HY000: Exiting.
Mar 24 10:55:26 h1conlog1-master conlog: ../conlog.cpp: 331: process_cas: Exception: boost: mutex lock failed in pthread_mutex_lock: Invalid argument Exiting.

They may have failed on different channels, but this narrows it down.

The summary of all coherences can be found here:

https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_1111224016

Here is my personal summary: still a lot of coherence with MICH/SRLC/PRCL, angular motion at low frequency, PSL periscope

• low frequency power fluctuations (OMC flicker) are coherent with the power before the OMC, so they are likely generated inside the IFO and not by some OMC control. Moreover, there is high coherence with both PIT and YAW RF45 signals at the AS port, but this might be simply due to power fluctuations coupling to angular signals due to miscentering on the WFS. Coherence is good with REFL WFS too.
• Noise between 5 Hz and 20 Hz shows some coherence with HAM1 signals: HPI-HAM1_BLND_L4C_Z_IN1. There is a similar amount of coherence with LVEA seismometer signal: PEM-CS_ACC_LVEAFLOOR_HAM1_Z. HAM1 shows some coherence too.
• Between 1 Hz and 20+ Hz, many WFS signals are coherent with DARM: mainly AS_RF45, but also REFL_RF9. I can imagine two possible explanations
  1. DARM correction leaks into the angular signal due to miscentered WFS or misbalanced actuation
  2. Angular control pollutes DARM due to misbalanced actuation
• There is coherence with ITMY control, which I believe is due to the MICH feedforward. Indeed, the coherence of DARM with ITMY is the same as DARM with MICH. This means that the MICh feedforward can still be improved.
• In the 30-200 Hz region coherence with PRCL/SRCL is quite large. Maybe we need some more feedforward paths.
• 57 Hz and 74.8 Hz are coherent with magnetometers: PEM-EX_MAG_EBAY_SUSRACK_Z_DQ and SEIRACK. The harmonics are there too.
• The noise bumps at ~75-83 Hz and ~98 Hz are coherent with ASC-Y_TR_B_PIT 
• Peaks from the PSL periscope are highly coherent in the region between 180 and 380 Hz. See for example PEM-CS_ACC_PSL_PERISCOPE_X, PEM-CS_ACC_PSL_TABLE1_Z and all IMC signals
• The region between 460 and 520 Hz is completely coherent with ITMX L2 control
• At high frequency (>100 Hz) there is still broadband coherence with a lot of RF signals in REFL and POP. This is likely related to the IMC longitudinal offset issue (to be confirmed and possibly fixed)
• There is some coherence above 100 Hz with intensity noise. The projection is still a factor of few below the DARM noise floor, but not too far away. It should be easy to improve intensity noise by tuning the IMC alignment
• Around 970 Hz there is large coherence with PRCL

In general, there are many frequency bands where there is coherence with signals, so it's worth scanning though the main table to see if yopu favorite bump is coherent with something. The list would be too long to be included here.

Conlog exited with the following error:

Mar 24 09:36:28 h1conlog1-master conlog: ../conlog.cpp: 301: process_cac_messages: MySQL Exception: Error: Incorrect string value: 'xB8xEDxFBx99xE8x05...' for column 'value' at row 1: Error code: 1366: SQLState: HY000: Exiting.

Unfortunately the code to do better error reporting with the channel name that caused it is still only in trunk.

SEI - Jim is installing new osolation filters on BS.  McCarthy may install a new power supply for te EX HEPI pump controller.

SUS - Charge measuring in EY

CDS - RF cab;le pulling between TCS racks. Discuss plugging in rotation stage

Matt is working on TCS X and Y and clearing errors on TCS-X AOM

Bubba found a bad bearing on one of the axial fans. He will be repairing.

3IFO- Bubba installing dewpoint sensors on containers. Jodi ad Gary tagging ISC and Baffle stuff.

Corey working in Squeezer bay

HFD - in LSB doing tests.

08:08 IFO fully locked @ ~ 18Mpc  (according to SensMon).

Evan, Sheila, Dan, Kiwamu, Lisa 

SUMMARY 

The wind dropped below 20 mph in the evening, and we started locking. After some roll, bounce and violin damping, we made it to DC readout @ 8W. We successfully transitioned DARM to ETMY with low noise ESD and got some MICH feed-forward cancellation going. We improved the noise between 30-200 Hz, and reached  28 Mpc  (according to SensMon). 

The noise was more stationary than  previously observed . 

However,  the OMC is still shaking , and it is not good. Dan has a resonant gain for DARM ready to be tested to reduce the noise around 3 Hz, but we didn't manage to get that done tonight. 

We leave the interferometer locked at 28 Mpc starting at March 24, 2015 9:17 UTC . 


DARM control on ETMY with low noise ESD  

We did the transition from ETMX to ETMY L2 for DARM, but the interferometer was very glitchy, and we decided to abandon L2 control and try the new  Den's strategy  to do the feed-forward to ITM(Y) L2. 
Evan got about a factor of 10 subtraction (FM9 has BS plant inversion in LSC-MICHFF filter bank, gain +0.048). 

ASC cut-off filters 

Since none of the ASC loops had cut-offs, we decided to add  some . They are now engaged by the Guardian. A more fine tuning will happen at some point. 

Started switching coil driver to low noise  

We started switching the coil driver to  low noise . Evan will post a table later with the successful switches we did after acquiring the DRMI lock. We need to do more work on this, some failed.

Lisa, Dan, Sheila, Evan, Kiwamu

We checked the evolution of the flickers in OMC TRANS over time.  It appears that the features between 1-5Hz have always been there, but the amplitude has grown by a factor of ~3-6 in the past two weeks.

In the attached plot, the ampltiude of the 3Hz peak on Mar 6 was about 0.004 / rt[Hz], and today it is 0.02 / rt[Hz].

We've added rolloffs to the ASC loops, turned on the 'resg1' filter in the ETMY_M0_DAMP_L filter bank (this adds a RG at 1Hz and an overall gain of +6dB), and looked accusingly at the OMC TRANS camera image.  No change so far.  Next idea is to try a boost in the DARM loop gain at low frequency.

So what was supposed to be a simple favour for Aidan to turn the CO2y laser on turned out to be not so simple. Note: when I started this work I was unaware of the issues that Greg encountered last week (he has just put in an alog now for me alog 17302).

So at the moment the CO2y laser is still off.

Below is what observed/thought was the problem before hearing from Greg about the issues he saw previously (and is now alogging) , and also talking to Aidan about his recollections. Also will include what I think is going on for part of it and also recommendations.

Observation 1:

The rotation stage for CO2y is not working (I cant get it to do any rotation of any kind). I played with this before knowing that Greg had seen this last week also. I did not try playing with the CO2x. Based on past experience at LLO and LHO its going to be something with Beckhoff having to be reset (we really need to work out why these things just stop working). So until it is up and running I dont want to turn the laser on. And because I dont know how LHO like to proceed with doing procedures like this I took this no further. So what I need is for someone (maybe at start of next weeks maintenance period) to reset the HWP for me (probably just needs to be unplugged then replugged).   

Observation 2:

I went out to the mechanical room to check the status of the power supplies etc. I immediately saw two things that peaked my interest.
1. Only one of the Kepco power supplies is on and wired up?? and the one that was on was drawing no current (see pic Kepco power supply).  This I have seen before and indicates that one of the AOM drivers has faulted. But because things look to be hooked up weird (will discuss more later) looking on the tables I see that CO2y AOM driver is fine (indicated by the two green LEDs..see pic CO2yAOM driver), but the CO2x AOM driver has faulted (top LED red...see pic CO2xAOM driver). If you want to know what these fault lights mean please go to E1500133 and look at table 1 (someone should probably print this table out and stick it on or near the AOM driver for others for future reference). Now this has been seen before at LLO and the solution is to power cycle the power supply. However doing this will make the AOM start to work, and seeing as its not known when it faulted and what static diffraction setting the driver has been set to, once the reset occurs I could alter how much power is going to the interferometer (as CO2x laser looks like its being used). So again this is something should do during maintenance period (should note what power going to optic now and so when reset see how/if it changes and alter power accordingly). 

2. The CO2Y laser power supply seems to be drawing a funky amount of current. 2.5Amps actually (see pic TCSy power supply), even though the laser is off. Ive even turned the key on the controller off, so it shouldn't even be in standby mode where only draws 0.7Amps. Talking to Aidan he seems to think that maybe the AOM driver/AOM is drawing current from this supply (him telling me that made me recall we saw numbers like this back in the day when we were installing and the laser was off but we had the AOM driver on). He seemed to recall the AOM driver and CO2 laser are driven off the same supply still here at LHO (which was the original design), even though the plan was to change to having the CO2 laser and AOM driver driven off separate supplies (as has been implemented at LLO...the Kepco power supplies power the AOM drivers the other supplies power the CO2 laser only). But this doesnt seem to totally match with what Im seeing in the mechanical room. 

So looking at the wiring, here is what I think is the current setup at LHO. We are in some funky mid change between having one power supply do both laser and AOM driver and having separate supplies for all. In more detail......The two shelves showing the power supplies for TCS are shown in TCSracklowershelf and TCSrackuppershelf. How it should be as per the latest plan that I know of (and is at LLO) is that the on the lower shelf should hold the power supplies that power one table (ie say Y ) and for the upper shelf the power supplies for the other table (X) with seperate supplies for the lasers and the AOM drivers.  What seems to be the case is that:

       *on the lower shelf we have the Instek supply (I think thats the brand name....its the the one with the digital readout reading its drawing 2.5Amps that says TCSY on top of it) powering BOTH the CO2y laser and the CO2y AOM driver (I think this because the laser is OFF, as is the controller, but the AOM driver on the Y table has not faulted and is "running".The x table AOM driver has faulted and is not "running" and 2.5amps is an approximate number that the AOM driver could be drawing). 

       * The Kepco power supply on the lower shelf is wired up but not drawing any current at the moemnt and thus and looks to be powering the AOM driver for the X table (why... because the x table AOM driver has faulted its not drawing any current). It should be wired to be controlling the Y table if supply in the position at..or at the very least labeled clearly as to what it is powering. Mind you I could be wrong and its powering something else

      * The instek supply (the one showing the digital readout of 22.42 Amps) on the upper shelf is powering ONLY the CO2 x laser (its drawing this current as the laser is on). 

      *The Kepco power supply on this upper shelf is not even wired up and is thus off. 

What I suggest is at some stage when have some time (maybe during maintenance period next week), is to wire the system as per the new design (and as how is at LLO). One Kepco power supply is used for the AOM driver on one table and the other Kepco power supply be wired to the AOM driver on the other table. And then just have the other power supplies individually controlling the CO2 lasers. Should then also have the power supplies for one table on one shelf and the power supplies for the other table on the other shelf. 

Also when turn laser back on need to see if still only drawing half the current like Greg saw and if so investigate (probably cable connection is the problem like in the past). SO quite a few things would lile to do at next weeks maintenance period.