• Title: 2/12 OWL Shift: 16:00-00:00UTC (08:00-16:00PDT), all times posted in UTC
  

• State of H1: Commissioning
  

• Shift Summary: Started out the day with Richard and Fil trying to solve a noise problem in SR3. A few other various measurements took place during that time. Then Jenne, Sheila, and I struggled with getting the ASC to engange properly during DRMI.

• Incoming Operator: Nutsinee

• Activity Log:

• 15:15 Chris S to Xarm near Xend for beam tube sealing.
• 16:19 Jim W taking HAM3 ISI down for SEI work
• 16:57 Fil to the lVEA to check SR3 sat amp
• 17:27 Hugh to LVEA to move STS to bier garten
• 17:49 Fil out and back in
• 18:06 Hugh out
• 18:28 Kyle, Gerardo to MY
• 18:35 Evan H to LVEA for some 9MHz testing
• Hugh to EY to rezero a seismometer
• 19:29 Richard to LVEA to transition to laser safe
• 19:41 LVEA Laser SAFE
• 19:56 Kiwamu done with ISS 2nd Loop work
• 20:11 Small group on roof
• 20:11 Fil out
• 20:38 Aiden Brooks changing TCS model
• 22:48 Hugh to EY again
• 23:51 Kyle, Gerardo back

Two of the three channels still seem to be stuck on the rail.  I did two centering pushes today.  I'll continue next week, hopefully it will stabilize by then.

While investigating the high frequency oscillations seen on SR3, we decided to modified the satellite amp units for OMC and SR3 (Bottom). Two decoupling capacitors were placed on the input of the negative regulator (U503), as implemented at LLO. 

C602 0.1uf
C601 10uf

The OMC units modified are S1100129 and S1100127. For the SR3 unit, we removed unit S1000287 and replaced with a modified unit S1100074. High frequency oscillations 1.7KHz and 1.9KHz seem to have cleared. Work to continue next week, as some channels still show some noise on the spectrum.

The automation of the 2nd loop engagement has been updated to use the front end funcionts (alog 25473) and confirmed to be functional.

We do not have to do the manual engagement any more. Yay.

[some more words]

I have tested the automation once as part of the full locking sequence in this Wednesday. The test in full lock exposed some minor issues with my implementation (e.g. some settings were not properly initialized and etc). Today I fixed the IMC_LOCK code so that the automation startd from the proper initial settings. I tested the new implementation with the input mode cleaner multiple times and confirmed that it was functional as intended. The automation is fully implemented.

WP--5683; ECR-- E1500455

I've center the masses now and they seem pretty good after 4 or 5 attempts.  We'll see how things have thermally stabilized after the weekend.

Also II 1203.  Otherwise:

It looks like the Block Properties specifying the parameters for HAMs4 & 5 are still just duplicates of HAM3.  See attached.  There may be more to it but at the moment I'll say, I need to correct these parameters and recompile the models to get the correct medm generated.  I'll file an integration issue as I see this as just an oversite correction.

Yesterday Jim and I resurrected the hardware watchdog (HWWD) system on the DTS. It did not take too much work as the system had been pretty much left intact. We hooked up the ADC and DAC lines to the x1susey chassis and reconfigured x1boot to PXE boot the new faster computer which is running as x1susey. This front end is running the x1iopsuseywdt  and the x1susetmywdt models. We did a quick test of setting the countdown timer to 2 minutes and then disabling the OSEM LEDS (via relay unit). After 2 minutes the HWWD zeroed the SEI enable signals. Restoring the LEDs and pressing the RESET button restored the SEI drives.

I went through the wiring and  have made a new as-built drawing as sheet 2 of https://dcc.ligo.org/D1300475

Dave, Elli

We are using two cameras on ISCT6, AS_AIR plus CAM_17, sert up at different gouy phases, which we are using to measure the SRC gouy phase.  Today we shifted the positions of these two cameras, and took some images with them as we moved PR2 and BS and tracked the spot locations across the cameras.  Attached is a photo with the changes to the table. Analysis to follow.

DIAG_MAIN - Temporarily removed the HW inj test until the CW inj are running again.

TCS_CO2 - Made the nominal state LASER_UP and added them to the GUARD_OVERVIEW medm.

(And as if on cue, H1 had a fabulous 14hr lock stretch last night with a range near 80Mpc and it was very clean/not many glitches.  See attached image.)

The local Press Conference event occuped much of the morning and went swimmingly.  After the hub bub, here are a few of the Day's Activities:

• 19:10-19:56:  Stopped the SR3 Cage Servo, & Power cycled SR3 (Keita, Kiwamu)
• 19:12:  Transitioning to Laser Hazard (Kiwamu)
• 19:35:  lveaws1 had to be rebooted (Dave)
• After the transition to Laser HAZARD, Elli & David O, went out to ISCT6 to do Guoy phase measurements with H1 in an SRY unlocked configuration.  They will be using the AS AIR camera for some of this work.

Nutsinee has kindly offered to cover the last couple hours of the DAY.

May The Gravitational Force Be With You.

Most cpu overruns associated with the faster SUS computers (which were installed in the end stations this Tuesday) only glitch the SUS-IOP and SUS-ETMX,Y models. Once in a while the glitch extends to the SEI IOP/ISI model and the ISC/ALS models and also glitches the SUS-TMS and SUS-PI models.

To keep the overview GREEN and help with trending, I have extended my end_station_sus_diag_resets.bsh script to clear these additional models. This script is ran roughly once a minute on opsws16.

WHAM6 ISI is lifting itself almost 40um from its free hanging position during isolation.  The drive to the Z actuators is running nearly 2000 cts on average.

What's the issue?  Excess drive ==> excess noise?  Unnecessary heating?  Trip vulnerablility?

The attached plot shows 15 minutes when I deisolated the ISI.  Channel 9 shows the free hang sag position.  This was not so low until the HAM6 work back in April/May when it decidedly dropped.  While I balanced and leveled the platform, maybe we need to bias that work high to deal with thermal sagging.  I don't see it obviously sagging lower over time.  See Channels 14 thru 16 for the vertical drives.

Second attachment is 120 days of the outside temp and the vertical drives.  I'd say there is nice inverse correlation with phase thrown in related to our typical step wise heating response to seasonal temperature changes.

My recommendation is remove some payload to raise the free hang position.  Maybe not to big a deal but the free hang positions of the Vertical CPS are on the low side (Channels 4 thru 6.)  This requires a vent of course so maybe not.

Otherwise, we should accept & show that the OMC position does not care about the 90um shift and reset.

Evan and I left the interferometer in the observing mode at around 20:00 pm local last night. The ISS 2nd loop now keeps correcting the diffraction power all the time via a feedack loop and maintains it at 8%.

This is yet another followup of Kiwamu's cage servo followup: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=25416

In the attached left panel is a 12-days trend of SR3 signals. Left column is the EPICS version of M3 witness sensors, and PMON is used for the cage servo. Middle column is a DQ-version of the same signal.

At first YMON and PMON were going happy together with DQ version, but at around Feb 02/03 midnight UTC, PMON and YMON got huge at the same time the cage servo went crazy, but WIT_Y_DQ didn't feel it. Later when Kiwamu turned down the cage servo gain, WIT_P_DQ (middle bottom) went back to normal-ish but PMON and YMON didn't.

It turns out that when you look at non-DQ version of these signals (attached middle panel), there are huge lines in all four M3 OSEMs of SR3 at 1.7kHz and its harmonics, totally dominating the RMS (top). Bottom plot shows the comparison between SR3 (green) and PR3 (red), and PR3 doesn't show any of these huge lines.

DQ version is decimated by the frontend, but it seems like PMON (as well as YMON and LMON) are just sparsely sampled version of the fast signals, no filter modules therefore no decimation, thus the high frequency junk directly goes into low frequency (right panel).

In the past, the solution for oscillating satellite amps was to power-cycle them repeatedly until the oscillation stops.

1515 - 1600 hrs. local -> To and from Y-mid 

Next over fill to be Friday, Feb. 12th before 4:00 pm

Today I cut off the excess length of HV cable at the controller end which included the suspect portion of cable previously noted but the short did not change.  I inspected the length within the raceway in the VEA but nothing looks suspicious.  Thus, all of the length which is accessible looks unremarkable.  There is still 10'-15' that is within EMT conduit in the VEA that could be exposed if pulled through the conduit body at the exterior wall penetration but other than that there isn't much else to do barring pulling another 900' run of "not free" 10,000V rated cable.  

Recall that the ion pump controller was found tripped off several days ago and could not restart the ion pump do to its power limiting feature and can only achieve 500VDC @ 0.5 amps implying 1000 ohms between HV conductors.  This "shorted" resistance value is duplicated with the "Megger" unit, as well as, with the low voltage VOM which measures 1080 ohms.

Feb. 10 2016 ~ 21:51 UTC Stopped Conlog process on conlog-test-master. Had connected to channels on Feb. 3 2016 16:38 UTC (alog 25344).