I spent most of today dodging the interferometer crew, as they're tasks have changed through the day, and installed ground STS to HEPI sensor correction. It runs, but I have had mixed results getting improvements out of it. I wanted to try this as it offloads some lower frequency Z isolation from the ISI, where it couples to RZ motion. I've had the  best results on ITMY, where Fabrice has installed RyanD's blend filters. The attached plots show what I've been able to get. ITMY_before_HEPI_senscor, shows the performance before turning sensor correction on, ITMY_after shows after, ITMX_before_blends shows the performance from 4 days ago, before any changes were made (the ISI was running our standard blends, with STS to St1 sensor correction, and position only loops on HEPI).  The first pages are a summary of the seismometer signals, page 2 is the oplev, page 3 is suspension point, and the rest are each of the plots from page 1 blown up.

As far as the ISI goes, pages 6 and 7 of  the attached files show the important stuff. Basically, we get good reduction in motion  above .1 hz and some amplification below, with ISI or HEPI sensor correction. I think we are doing better at ITMY now, although the oplev (page 2) seems to disagree with me, but the commissioners may have been doing something with the optic when I took that spectra. I'll be waiting with bated breath for the commissioners input, though.

Peter K, Gabriele

We were not able to close the ISS second loop. Every time the board was enabled, the output railed.

We checked that the commands to switch the board on and to select which photodiodes to use are correctly sent to the board. Also the variable gain and the reference voltage are sent to the board. Instead, it seems that the commands sent throught the other DB9 cable (boost on and integrator on) are not received. We don't know if it is a model problem or a DAC problem. However, those two commands are not relevant for the moment.

We discovered that when the board is powered up, the inputs are raised to about -11 V, regardless of the input. We traced the problem to the LT1124 used to buffer the inputs and send them to monitoring channels. Removing the LT1124 solve the problem. We checked that thae same happens with the other ISS servo board we have in the electronics lab. We don't understand this behavior. The AEI board is not bahaving in the same way.

Patrick, Dave

We reconfigured the conlog this afternoon and restarted. The difference between today and yesterday's failed restart is: h1hwsmsr, all channels marked ReadOnly in autoBurt.req (and therefore not in conlog) and new h1psliss model. Patrick is investigating off-line why the h1hwsmsr channels apparently caused conlog grief.

No problems with today's reconfigure, about 2700 channels added (SUS-QUAD_TST) and 58 removed.

HAM6 will continue to be pumped by turbo until associated noise can't be tolerated by commissioners or until pressure reaches 1 x 10-7 torr (whichever comes first) at which point will switch to ion (quite) pump

Jim, Dave

h1pemmy failed at 13:02 PDT, we went to MY and found the IOChassis had not front panel LEDs on, CPU could not see the ADC card. We verified +24V DC power supply was on, it showed 0.2A draw.

Powered down CPU, switched IO Chassis front panel rocker switch OFF, switched rocker ON and IO Chassis turned on (DC current 2A). Powered up CPU, models started, DC draw now 3A.

Had to restart h1ioppemmy one more time to get GPS time correct.

Cause of failure unknown.

9:37-11:40 Heading to End Y to check AA chassis – Sudarshan
10:25 Going to End Y – Richard
10:26 PSL model h1psliss restart – Dave/Peter/Gabriele
10:26 DAQ restart – Dave
11:06-11:48 Working at MidY – Karen
11:15 RF amplifier chassis installation in H1 PSL – Filiberto/Peter
11:52 Install Pcal beam localization camera housing on A1 adapter      window flange at EndX/EndY – Rick/Travis/Sudarshan
11:56 Taking some connectors to Filiberto in the LVEA – Ed
11:58 Back to Mid Y – Karen
12:22 Heading to work inside the beam tube enclosure between Mid Y/End Y – Robert
13:09 Going to End Y to replace the laser and re-align the Oplev – Jason
13:26 Heading into the LVEA (HAM1)- Hugh
13:31 Searching for TMS parts at EndX – Jeff B
13:51 Returned from HAM1 – Hugh
14:24 Back from End Y – Jason

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.

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.

I finished preparing the online calibration filters for the DRMI which I started in the last week (see alog 14030). The output spectra are now monitored on projector1 (see alog 14042) in the control room as shown in the above pitcture.

I checked the HSTS and BS suspension filters in the calibration paths in h1oaf. While the HSTS suspensions looked good to me, the BS suspension did not look similar to the suspension model. In particular, the location of resonances did not look correct in the first place. So I changed the BS model by running the BS design Matlab script in the SVN and, copying and pasting the result in foton. The DC gain was then re-adjusted by hand such that it is at 8.85 x 10^-5 um/cnts (= 46.40 um / (4 x 2¹⁷ counts)). Note that this 46.4 um came from DCC-T1100602-v2. And the factor of 4 in the denominator compensates to the Euler matrix in the suspension realtime controller.