State of H1:  PSL crew continue to work on plumbing - crystal chiller was filled in preparation for turning it back on

Additional Activities:

• Gerardo to LVEA - labeling - done
• Kyle to LVEA - vertex RGA work - done
• Kyle - Mid-Y - CP3 fill - ongoing, left around 4PM to do this

Sitewide:

• two loads of LN2 delivered
• Platt electric delivery
• pest control in LVEA and all out buildings

State of systems that might effect H1 locking:

• ISC_Lock guardian in DOWN
• IMC_Lock guardian in DOWN
• BRS at EX and EY set to "Not in use"
• IMC common mode board was worked on today in the EE shop and reinstalled, but not yet used for an IMC lock
• HEPI for BS chamber, BSC2, had alignment drive load reduced, with changes in ofther DOFs (alog 29495)

TJ, Jim

This afternoon TJ walked me through making a guardian node for the Compact BRS in the Biergarten. This BRS is only destined to be used for Newtonian Noise studies, but has been drifting a bit since install. Up to today, the monitoring system has been Krishna watching from off-site, then sending me an email when the PZTs go out of range, if I don't catch it before then. Now there is a guardian that monitors the PZT readouts and recenters them automatically.

This is not a critical node, so if CDS needs to kill the node for any reason, we can do that, but it's nice having BRS babysitting automated. I've added this node to the Guardian Overview, in the top right above the TCS nodes, but that screen is getting pretty busy. I've also added/commit the guardian code to the userapps/isi/h1/guardian repository.

The node has 3 states:

1. INIT which returns to RUN, 

2. RUN which monitors the outputs to the PZTs and

3. RECENTER, which ramps off the damping, then the outputs of the PZTs, clears the histories of the PZT CTRL filters, ramps the CTRL gains on, then restores the damping and returns to RUN.

During today’s maintenance, I looked into a couple of peaks in DARM that have been present in recent weeks, even though we have been at low sensitivity. The peak at 56.8 is from the EX HWS. We should power it on a separate 18V supply like EY, or remember to shut it off for the O2 run. The peak at 451.5 was associated with Kyle's RGA bake-out pumping by HAM4, but I think he completed that today, so the peak should go away.

Re-Installed Common Mode Servo Board S1102626 for use with the mode cleaner.  This is the unit that had problems when the filter board was installed 23 Aug.  This unit has the 200kHz filter installed.  
Took advantage of the PSL work to fix the first channel on the DeMod board.  This has been re-installed and the mode clean is again going through the first channel.

State of H1: PSL crew working on plumbing and flow sensors - taking lunch and will return to the PSL this afternoon

Maintenance Activities: 

• Karen LVEA cleaning
• Fil LVEA HAM2
• PeterK PSL plumbing
• Kyle LVEA multiple-visits-vertex
• JoeD LVEA Batteries eyewash maint
• Betsy ETMX-ETMY charge-measurements
• Ed LVEA HAM6
• Jim-Hugh LVEA BSC2-BS-offset
• Fil LVEA BSC4-cabling
• JeffB LVEA HAM6 cleanrooms
• Travis MY bins
• Alfredo EX camera
• Richard LVEA ISS board
• PeterK PSL plumbing
• Robert EX noise-hunt
• Jason PSL plumbing
• Joe LVEA maintenance
• Karen EY cleaning
• Chris EX maintenance
• Betsy, Travis LVEA parts
• Bubba, Betsy LVEA 3IFO
• Robert LVEA ...

Current Activitiy:

• no one in the LVEA, Mids, or Ends
•  
• 
   

I've collected the alignment changes in the IMC, the IMs (IM1-4), PRM, PR2, RM1, and RM2.

I've also included the senors that see the beams related to these optics, WFSA, WFSB, IM4 Trans, and ISS2 QPD.

WFSA and WFSB are plagued by a mirror in HAM2 that we believe is loose, because the signals ont he WFS jump when there's no indication of IMC mirrors jumping.  Because of this feature in the WFS signals, I subtracted out the jumps from the segments of drift, and combined the drift segments to get a total drift over O1.

I've highlighted two sets of numbers:

• red = greater than 100urad change in optic alignment, or a change greater than 0.5 normalized qpd units
• blue = greater than 50urad change in optic alignment (less than 100urad), or a change greater than 0.25 normalized qpd units (less than 0.5 qpd units)

I included RM1 and RM2 since they follow the change of the beam.

Most changed optics:

• IM3 yaw at -111urad
• PR2 yaw at -115urad

Persuant to WP 6133, II 1150, FRS 4649 JimW & HughR

With the SEI completely deisolated, we lifted the platform with the HEPI payload springs.  We addressed the Z and tilt dofs.  The vertical drives on the Actuators were reduced substantially (8-6000 cts reduced to ~1200 or less.)  Sadly, the horizontal drives increased albeit less than the verticals were reduced: a few hundred cts to 5000, 2000, 1500, & 900 cts.  We would have addressed these too but Jim found Spring #4 (SE spring of SW pier) was feeling very galled.  Will file an Integration Issue to track this Spring problem.  Probably would need to remove the vertical actuator to access the Spring/XBeam Foot connection, but maybe we could get lucky.

The attached trends show the BS HEPI drives (OUTF ij OUTPUT) and the cartesian positions (..LOCATIONMON.)  The unisolated positions (when the drives are 0) can be seen changing as we adjust the springs.

The next largest HEPI Drive is horizontal on the ITMY where 4000 to 5000 counts are holding a 300um +X offset remaining from Initial Alignment--II 1151, FRS 4650.  After that, the BS Horiz, HAM1 Horiz, HAM2 and ETMX, if we care.

True, as long as HEPI is running fine, no big deal.  And, unless we take all DOF errors out, IFO ops will not be possible without the HEPI Isolated.  Would be nice to head to a state where, if we were to lose HEPI Pump Stations or a platform for a time, the position was such that IFO operations could continue.

Attached are long trends showing today's added ETM charge data.  Note, Kissel switched the sign on the bias of both ETMs last week, but I only see it show up on the ETMX plot, and not the ETMy plot.  That said, I have confirmed that the signs of the bias on the ETMs is as he now intends them to be as per his alog 29397. 

The attached plot shows the atomic clock drift over the past 400 days. The current drift is about -6ns/day. The PPS monitors for the atomic clock were updated to a nominal value of -500ns (from 0ns).

FAMIS#6078

T240's

There are 6 T240 proof masses out of range ( > 0.3 [V] )!
ETMX T240 2 DOF X/U = -0.396 [V]
ETMX T240 2 DOF Y/V = -0.458 [V]
ETMY T240 1 DOF Y/V = -0.328 [V]
ITMX T240 1 DOF X/U = -0.338 [V]
ITMY T240 3 DOF X/U = -0.31 [V]
ITMY T240 3 DOF Z/W = -0.365 [V]


All other proof masses are within range ( < 0.3 [V] ):
ETMX T240 1 DOF X/U = 0.056 [V]
ETMX T240 1 DOF Y/V = 0.054 [V]
ETMX T240 1 DOF Z/W = 0.052 [V]
ETMX T240 2 DOF Z/W = -0.213 [V]
ETMX T240 3 DOF X/U = 0.008 [V]
ETMX T240 3 DOF Y/V = -0.033 [V]
ETMX T240 3 DOF Z/W = 0.039 [V]
ETMY T240 1 DOF X/U = -0.013 [V]
ETMY T240 1 DOF Z/W = 0.025 [V]
ETMY T240 2 DOF X/U = -0.12 [V]
ETMY T240 2 DOF Y/V = 0.039 [V]
ETMY T240 2 DOF Z/W = 0.022 [V]
ETMY T240 3 DOF X/U = 0.02 [V]
ETMY T240 3 DOF Y/V = -0.022 [V]
ETMY T240 3 DOF Z/W = 0.011 [V]
ITMX T240 1 DOF Y/V = 0.092 [V]
ITMX T240 1 DOF Z/W = 0.062 [V]
ITMX T240 2 DOF X/U = 0.078 [V]
ITMX T240 2 DOF Y/V = 0.083 [V]
ITMX T240 2 DOF Z/W = 0.071 [V]
ITMX T240 3 DOF X/U = -0.293 [V]
ITMX T240 3 DOF Y/V = 0.048 [V]
ITMX T240 3 DOF Z/W = 0.108 [V]
ITMY T240 1 DOF X/U = 0.029 [V]
ITMY T240 1 DOF Y/V = -0.033 [V]
ITMY T240 1 DOF Z/W = -0.163 [V]
ITMY T240 2 DOF X/U = 0.102 [V]
ITMY T240 2 DOF Y/V = 0.026 [V]
ITMY T240 2 DOF Z/W = 0.012 [V]
ITMY T240 3 DOF Y/V = 0.072 [V]
BS T240 1 DOF X/U = -0.058 [V]
BS T240 1 DOF Y/V = -0.011 [V]
BS T240 1 DOF Z/W = 0.056 [V]
BS T240 2 DOF X/U = 0.046 [V]
BS T240 2 DOF Y/V = 0.046 [V]
BS T240 2 DOF Z/W = 0.074 [V]
BS T240 3 DOF X/U = -0.123 [V]
BS T240 3 DOF Y/V = 0.037 [V]
BS T240 3 DOF Z/W = -0.106 [V]

STS's

2016-09-06 10:23:53.363517
All STSs prrof masses that within healthy range (< 2.0 [V]). Great!

Here's a list of how they're doing just in case you care:
STS A DOF X/U = 0.0 [V]
STS A DOF Y/V = -0.0 [V]
STS A DOF Z/W = -0.0 [V]
STS B DOF X/U = 0.117 [V]
STS B DOF Y/V = -1.252 [V]
STS B DOF Z/W = -0.251 [V]
STS C DOF X/U = -0.0 [V]
STS C DOF Y/V = -0.0 [V]
STS C DOF Z/W = -0.0 [V]
STS EX DOF X/U = -0.295 [V]
STS EX DOF Y/V = 0.561 [V]
STS EX DOF Z/W = 0.049 [V]
STS EY DOF X/U = 0.045 [V]
STS EY DOF Y/V = 0.33 [V]
STS EY DOF Z/W = 0.257 [V]

 

State of H1:  PSL is down, PeterK is working on the cooling lines

Activities:

pre-15:00UTC(8:00AM local):

• ChrisS - LVEA - rigging strap inspection, opening high-bay roll-up door - complete
• Kyle - LVEA - vertex vacuum guages - complete
• Contractor - Mid and End stations - port-a-potty maintenance
• PeterK - PSL - working on plumbing

I am leaving it to the morning PSL crew.

I had another look at the slow drop in sideband powers that consistently breaks lock within 20 minutes of powering up to 50 Watts.  

This time I changed the soft loops to X,Y degrees of freedom (first I made the pitch filters for dsoft match csoft, this worked fine but isn't in the guardian).  I ran dither lines on the test masses and tried to move offsets in the soft loops to keep the spot positions stable, but this didn't help the tanking sideband powers at all.  I tried moving PR2/SR3/POP offsets.  SR3 can help improve the AS90 build up after a PR2 move that helps POP18 but walking these together didn't work out well.  I tried locking at 40 Watts where we have more time to move offsetsm but didn't find any alignments that could help the sideband build ups.  We might have to look at some lensing.  I tried using offsets in the POPX to PR3 loop, but as we expect these only made things worse.  

The fastshutter lockloss checker seemed to think that the shutter had not fired in one lockloss today, but as shown in the attached screenshot, it did fire. Leaving the IFO with Kiwamu for the night. 

After Peter King brought back the laser, we relocked the interferometer.
We had to increase the OMC scan range ( omcparams.scan_vramp ) from 40 to 60 for the guardian to find both sidebands.

Then we again lost it twice during the COIL_DRIVER swtiching because of a 2Hz CSOFT signal (pitch and yaw) ringing up. Lockloss plots of both locks are attached.

Next we switched back to ther old COILD_DRIVER_SLOW switching. Interesting, we still had problems once we stated switching test masses (ETMY  - the first one tried). All the corner optics switched without problems (Actually, SRM and SR2 had 0 seconds matrix ramp time, and still were fine. I set it to 1 sec for now - we should speed that switching up. )

In a second attempt I tried only switching ETMY by itself - with all top mass relief loops off (because the high BW offloading was one of the things we changed). still no luck - same 2Hz instability.
Still something changed with the test masses - it is not just the switching script.

A large earthquake spopped further work. I left the slow COIL_DRIVER_SLOW state as a parallel path in the Guardian for debugging. Also It currently only switches PRM, PR2, SRM, SR2, BS.

Kiwamu will try to do some ISS work with the IMC during the quake.

Attached is a 5 minute plot of the monitor signal for the current of diode box 3.  The initial reported value of 50.14 A is
corrected.  ~44 seconds after the start of the plot, the monitor signal hits 100 A.  Whilst the switching from the true value
to the false value was going on, the error bit on the corresponding Beckhoff terminal did not change state from 0 to 1.  The
output value changed from ~12460 to ~24880 counts.

    Since an ADC most likely does not change its reported value unless the signal it is monitoring changes, the problem would
seem to lay with the output monitoring signal of the power supply.  Without knowing what is in the output monitoring circuit of
the power supply, the problem I have is explaining why it resets itself after a period of inactivity unless it is a temperature
related fault.  The evidence for it being temperature related is purely circumstantial at this stage.

    I would suggest that the power supply be switched out.

Came to site just now to find laser off. 

Summary:

Filter configuration for ISS 1st loop to generate RIN channels (H1:PSL-ISS_PDA_REL_OUTPUT and PDB) doesn't look good. It seems as though we're somehow chosen to use inferior of the two filters in place both for  "CALI_AC" and "CALI_DC", assuming that D1001998-V2 (PD circuit diagram) and D1001985-V2 (ISS circuit diagram) are correct.

I made somewhat better filter for "CALI_AC". For "Cali_DC" probably it's good enough to use the one we're not using. I loaded the coefficients for the new file for H1PSLISS from H1PSLISS_GDS_TP MEDM screen.

This doesn't affect the loop because these channels are not in the feedback loop, but making these filters right makes it easier for different RIN channels to be compared.

Details:

Reading D1001998-V2, D1001985-V2, T0900630, analog part of the monitor output for PSL-ISS_PDA and PSL-ISS_PDB ADC have analog z, p and k of [0.0723;2700;0.0707] Hz, [3.3607;130;3.12;2300] Hz, and 0.2, they're all in the PD box (ISS box is just the pass through as far as these outputs are concerned). These are DC coupled.

After they are received in the front end model, the signal is first converted to volts but not dewhitened by PSL-ISS_PDA, and then distributed to PSL-ISS_PDA_CALI_DC and PSL-ISS_PDA_CALI_AC. In DC the signal is low-passed, and in AC it's dewhitened and high-passed, and AC is devided by DC to give RIN (first attachment).

In CALI_DC path, there are two filters FM1 and FM2, only FM1 is used (second attachment left). I also plotted the inverse of the analog whitening transfer function including the DC gain in the same attachment. FM1 looks like a strange  dewhite, nothing wrong with that, but I don't see any reason to prefer FM1 over FM2. Just use FM2.

In CALI_AC path, there are also two filters FM3 and FM4 (second attachment right). Compared with the inverse of the analog, it seems like the one in use (FM3) underestimates the RIN by 18dB at 1kHz. FM4 looks better but it's DC coupled. I made a new filter (green) and put it in FM5.

It's kind of odd that we're keeping DC gain factor in two different parts (CALI_DC and CAL_AC) instead of upstream. However, moving this gain into upstream affects PDASTAT thing (see the first attachment again), so I'll not fix this.