Follow up to alog 14245

Checked the ETMy oplev laser diode current (measure w/ a voltmeter attached to the current monitor port on the back of the laser) and found the diode current was oscillating at about the same 0.3 Hz frequency of the QPD SUM out.  Classic sign of one of these lasers failing.  I swapped the failing laser (SN 199) with a new one taken from 3IFO stock (SN 104-1) and this oscillation went away (see attachment).  As can be seen, the oscillation is gone, but there appears to be a slow ramp up time after the switch.  I think this is the laser coming to thermal equilibrium, but will keep an eye on it in case it's not and there's something wrong with this "new" laser.  If anyone else notices something not working right wth this oplev, let me know.

Also, after talking with Sheila to make sure this would not interfere with any commissioning activities, I re-aligned the ETMy oplev after the laser swap.  The yaw output was getting very close to the end of the linear range of the QPD (yaw was reading -46 µrad, linear range ends around ±50 µrad), so any data was of questionable utility.  When I left the end station at about 2:00pm PDT, the oplev signal read 0 µrad in both pitch and yaw.

J. Kissel

After updating the IOP software watchdog (SWWD) status channel to obey the
${IFO}:IOP-SUS_${OPTIC}_DACKKILL_STATE
convention back in June 2014 (see LHO aLOG 12504), Arnaud had updated the SUS overview screens to match, (see LHO aLOG 12550), but we never committed them, because LLO and LHO were pioneering and prototyping ESD linearization (see 11874), and LLO did not plan to upgrade their RCG and IOP watchdogs for quite some time.

The two sites models and MEDM screens (especially the QUADs) have diverged so much now that its become intractable to maintain. As such, we're beginning the process of reconciling the models by committing these IOP SWWD changes. 

svn commit -m "Updated IOP SWWD channel name. See LHO aLOG 12550." bsfm/SUS_CUST_BSFM_OVERVIEW.adl quad/SUS_CUST_QUAD_R0.adl quad/SUS_CUST_QUAD_OVERVIEW.adl omcs/SUS_CUST_OMCS_OVERVIEW.adl hxts/SUS_CUST_HLTS_OVERVIEW.adl hxts/SUS_CUST_HSTS_OVERVIEW.adl tmts/SUS_CUST_TMTS_OVERVIEW.adl SUS_CUST_IOP_DACKILL.adl 

Sending        SUS_CUST_IOP_DACKILL.adl
Sending        bsfm/SUS_CUST_BSFM_OVERVIEW.adl
Sending        hxts/SUS_CUST_HLTS_OVERVIEW.adl
Sending        hxts/SUS_CUST_HSTS_OVERVIEW.adl
Sending        omcs/SUS_CUST_OMCS_OVERVIEW.adl
Sending        quad/SUS_CUST_QUAD_OVERVIEW.adl
Sending        quad/SUS_CUST_QUAD_R0.adl
Sending        tmts/SUS_CUST_TMTS_OVERVIEW.adl
Transmitting file data ........
Committed revision 8750.

Stuart will now begin the arduous process of upgrading the SUS top-level, library, and IOP models to RCG 2.9. Then, he can push forward with bringing the library parts up-to-date with LLO's detached models, such that LHO can inherit all the good development work they've been doing down south. All yours Stuart!

Installed new RF ampflier for EOM drive signal. Chassis was placed on the ground below the PSL table.
Power levels measured:
Input of RF Amp: 11.23dBm
Output of RF Amp (with unat-8+ connected, 8dB attenuator) 21.89dBm

Amplifier used is a mini-circuits ZHL-1A.

F. Clara, R. McCarthy, P. King

Dave, Sudarshan, Richard

LIGOCAM reported that three microphone at EY were disconnected.

I found last week that these microphone would work as normal when switched from their original channel position to some other channel on the AA chassis so, we restarted the  H1IOPISCEY yesterday to see if the problem was in the DAC. This was an unsuccessful attempt as mentioned in alog 14225.

Today, I injected 3Vpp signal on all the channels using a function generator and found out the following:

Channel 1-16 are working as normal (I happened to switch those microphones to one of these channels during my first attempt).

Channel 17-30 show nothing on the output end of medm screen monitor.

Summary: The problem is with the AA chassis board. Richard has been notified and this AA Chassis will be switched sometime next week.

For those interested in looking closer at QUAD model parameters, attached are plots comparing all of the QUAD Main Chains when suspended with wires and also when suspended with fibers.   Note, if QUAD data is missing for one of these configurations it's because there was no clean data available.  Between the 2 plotted configurations, all 12 (H1, L1, and 3IFO) QUADs are represented.  Note, I tried to chose data sets that had the same or similar environmental conditions, but it was difficult due to the fact that some QUADs were reworked on test stands and some were reworked in chamber.  In all cases they were mounted on Solid Stack Test Stands or Locked ISIs and in-air.

Data is committed to the svn and can be found at:

/ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/Data/

There does not seem to be a pattern in the data of the 2nd pitch mode peak which are clustered by a specific type of suspension (ETM vs ITM, or wire segment hang vs wire loop hang).

See the attached spectra to see the obvious problem sensor.  I swapped the cables from the H & V sensors to the Pier Pod and the problem signal followed the cable.  So, the problem is upstream with the cable or sensor.  The HAM HEPI Horizontal L4C is certainly a pain to access:

Step1-- lock the local foot (already there on HAM1)

2 -- Disconnect the HEPI Actuator--recenter and lock up.

3 -- Remove the two Actuator mounting adapters.

4 -- Remove the L4C

5 -- Replace & Level the L4C

Reverse steps and hope you didn't move the platform enough to raise Daniel's notice (we are pretty good at not moving the system during this.)

model restarts logged for Tue 30/Sep/2014
2014_09_30 08:32 h1fw1
2014_09_30 09:47 h1iopiscey
2014_09_30 09:47 h1iscey
2014_09_30 09:47 h1odcy
2014_09_30 09:47 h1pemey
2014_09_30 14:41 h1fw0

unexpected DAQ restarts. Restart of h1iscey as part of PEM ADC channel problem investigation.

Jeff K. reported a 0.3 Hz comb in the ETMy oplev.  Suspecting a bad laser I took a look at the SUM output of the QPD and sure enough, the SUM is oscillating at about a 0.3 Hz rate, 300 counts pk-pk (see attachment).  This is usually a first indication of a bad laser (or a laser going bad).  I will head out to End Y after lunch to take a closer look and maybe (probably) replace the laser to see if this solves the issue.

This is a follow up of 14209.

The trouble with the whitening was due to sub-standard quality of the DB37 connector shell of the binary IO cable.

The connector doesn't fully seat even if you tighten the connector screws, you need to physically press the shell hard towards the chassis to properly seat it. Once seated, the problem is gone until you give the cable one hard jiggling.

Once I removed the shell from one of the cables, it was easy to fully seat the connector and the whitening worked correctly even when I jiggled the cable multiple times. I removed the shell from all EY WFS BIO cables (but not from QPD BIO as they are working).

We have many of these connectors, but DB37 seems to be most problematic because the cable is very thick and gives the connector some good torque depending on how it's angled.

This type of DB37 connector shell has another problem, which is that the cable is so thick it's sometimes difficult to correctly put the shell halves together, as was documented by 12795.

At the very least, these shells need to be replaced with something more reliable. Or cables remade.

Gabriele, Peter, Dave

Restarted h1psliss with new model. Inputs and Outputs of the PSLISS common block connected to ADC/DAC at top level. After the model restart the DAQ was restarted.

J. Kissel, A. Pele, R. DeRosa

(c.f. LHO aLOG 14086)

After having spoken with the LLO team, Ryan informed me that he *did* in fact have to take considerable effort to re-arrange his sensor-correction STS2 readout system after initial install before he could use it. Regrettably, he hasn't written up any aLOGs or documentation on *how* his system is connected.

After a few more hours in the EE room, with new understanding of what was originally intended, and following cables through zipties and cable racks, I now understand that indeed the bulk of the problem is in the front-end models, AND that the HAM45 rack cables were just down-right disconnected at their AA chassis inputs for some reason. I've plugged them back in, and as suggested by Ben, in the order that the HAM16 wiring diagram (D1101584) suggests, such the DuoTone channels remain un-over-written, i.e. now ALL HAM ISIs and HAM HPIs have the following cable arrangment:
ADC_0_24   STS A X
ADC_0_25   STS A Y
ADC_0_26   STS A Z

ADC_1_24   STS B X
ADC_1_25   STS B Y
ADC_1_26   STS B Z

ADC_1_24   STS C X
ADC_1_25   STS C Y
ADC_1_26   STS C Z

As such, I don't think I need any more analog changes to the system, but it's time to dig into the top-levels of the front end models, now that I understand how the analog system is wired up. I attach a system drawing which I intend to follow, which is now a part of ECR E1400386, II 942, all cited in Work Permit 4876. I'll begin work as soon as I'm authorized, and Ben will begin updating the drawings accordingly.

Aleaxa, Kiwamu, Jenne, Sheila

• We turned on the ITMX oplev servo because we saw an oscialltion at 0.55 Hz by 2 urad pp (with sensor correction off)
• We need to install the 45 MHz amplifier to get reasonable signals for 3F.

We worked on DRMI tonight, it is locking at 1Watt within a few minutes. We are using gains of 22 for PRCL, 40 for MICH, and -400 for SRCL.  We are using the PSL-POWER_SCALE_OFFSET, so the gain settings and trigger settings in the gaurdian are now set for 1 Watt input power, but we could scale them to 10 Watts. We have been locking sometimes without the 27 Hz notches in M2 of PRM and SRM, and munually turning them on after it locks (this is needed to prevent the suspensions from ringing up).  We are using the guardian for everything else, including the offloading to M2. 

We started to measure the relative gains between 1F and 3F ( we think we need a gain of 3.2 in the input matrix to swtich PRCL to REFL 27 I) but quickly realized that we don' t have enough signal in REFL 135.  It seems like we need our 45 MHz amplifier installed before we can move on to 3 F. 

Times that DRMI was locked:

3:25 UTC october 1st - 4:21 UTC

5:10 UTC (maybe a few minutes earlier). This is still locked, Kiwamu is now scanning the OMC.

To do list:

• slow offloading to etms to help diff locking
• 3 f with amplifier
• as wfs

I started it back up with the previous channel list. It looks like it must be a problem with one of the channels that Dave tried to add. The error it logged was:

Sep 30 14:23:51 h1conlog2 conlog: ../conlog.cpp: 301: process_cac_messages: MySQL Exception: Error: Out of range value for column 'value' at row 1: Error code: 1264: SQLState: 22003: Exiting.

This would seem to imply that the value for one of the process variables was out of the range of the data type in the database. I'll try to narrow it down tomorrow.

Summary:

Some whitening settings for EY green WFSA  I3, Q3 and WFSB Q2 channel don't work. It's probably the whitening chassis itself as the whitening request and the readback agree with each other.

For now I'm leaving both of the chassis in place as there are some usable settings, but note that these guys have a history of many troubles due to chassis and crappy cablings (12159,  12138, 12127).

Details 1:

For WFSA I3 and WFSB Q2, the measured whitening gain doesn't match the request and the readback (attached).

You can see that in both cases one of four stages (+3dB, +6dB, +12dB and +24dB) is failing. It's the 12dB gain stage for WFSA I3 and the 6dB stage for WFSB Q2.

These were measured injecting 20mVpp signal at 100Hz using a function generator and a breakout board.

Details 2:

For WFSA Q3, the third whitening filter doesn't turn on.

For now:

I set the gain to +27dB and turned all filters off.

QUAD 06 (Q6) Phase 1B transfer function plots are attached.   We had a hard time obtaining good coherence in the Transverse TF, so it is a bit hashy.  Will try again.  

Most notably is that, like Q8, the second pitch mode frequency is unexpectedly pushed upward on the main chain.  Recall, we never found the mechanism to fix it on Q8.  Interestingly, both the Q8 and Q6 assemblies are of the same batch of wires and are fresh builds, but by 2 different assembly teams, and on 2 different solid stack/test stand units.  Q8 is an ETM type of QUAD while Q6 is an ITM QUAD, but both main chains have the same pendulum parameters - both are detailed in the 'wireloop' model.

The Q6 data is plotted as QUADTST.