Camilla and I tested going to Observing with no squeezing following the instructions on the Observation With or Without Squeezing Wiki. There were a few edits to the wiki so I'm glad we got the chance to test it. We purposefully did not change the state of H1:GRD-IFO_OK (ie. we didn't actually go into observing), but all nodes reported OK other than SDFs, which are simple to accept in this state.

Going to or from this odd IFO configuration is still not super straight forward. It requires editing the definition of the nominal states of 5 guardian nodes in 5 separate python files, then taking the ISC_LOCK node to manual, requesting the INJECT_SQUEEZING state, then manual back to the NOMINAL_LOW_NOISE state. I can't think of an easy way to make it simpler than this though, and this situation should rarely come up.

Naoki, Vicky, Sheila, Camilla. WP 11470.

OPO Crystal Move

Following last time we moved the OPO crystal 65684, we used the wincam dell laptop and gray E-870 PI shift driver box (stored in LVEA SQZ cabinet) and the OPO crystal cable Daniel attached the the +X HAM7 flange. Adjusted OPO temperature from 31.684 degC to 31.804 degC for co-resonance while scanning rather than stationary. 

To scan the OPO PZT fast enough, we used external function generator and Thorlabs driver at the racks for the OPO PZT to scan over more than 1 FSR (around 1-9V scan). 

We were able to move the OPO crytal over its full range and found 6 spots with red/green co-resonance, attached pdf shows the places we moved. LLO found 10-13 potions which is surprisingly more than us, 73502. 

Through O4 we've been using the 2nd posltion from the right, but left the crystal on the 2nd spot from the Left. 

Photos attached of the PZT scan (yellow trace), OPO IR trans light measured on HD PDA (pink trace), Green trans from CLF path (green trace). The green alignment looked bad at all spots. This could be from misalignment of OPO path or HOMs present in fiber. When we next go into HAM7 we can look at this. 

NLG Measurement

Turn down green pump power with SQZT0 wave plate to 4mW in to stop the OPO lazing. We measured NLG of 14 (OPO_IR_PD_LF_OUTPUT amplified / unamplifed = 0.0136/0.00092). This reduced to NLG of 12 over a few minutes. 

Homodyne Measurement 

We balanced the HD by reducing the seed power and realigned to maximize visibility. At start of measurement visibly was 14 and at the end it NLG was 12. Vicky, Sheila Naoki took Homodyne measurements which were hard with NLG drifting. Measured 4.5dB whihc is less than the 6dB measured last week 73376. But we think we could have offloaded the ASC alignments incorrectly to not see good SQZ on the HD.  

• PDA 98.6% Visibility (Min 10.3mV Max 1.48V) = 2.75% loss (1- Vis^2)
• PDB 98.0% Visibility (Min 14.8mV Max 1.5V) = 3.87% loss

SQZ in IFO

Ended with NLG of 13.5 into IFO. Amplified power of 0.0196, unamplified seed of 0.00149. Though this may be changing quickly. 

Took some no sqz data while TJ tested updates to the Observing with No SQZ wiki. Accepted sdfs to go back into observing. Vicky adjusted OPO tempurature and had to adjust the SQZ angle from 142 to 163, squeezing looks better 4dB+ but we expect the angle and OPO tempurature may need to be adjusted over the next hours...

Jordan, Gerardo

Today, we were able to install one of the new 150 l/s ion pumps on FC-CII, C6 cross. The Ion Pump/Tee/Angle valve assembly was pre-built in the staging building and then pumped down and leak checked. This assembly was stored under vacuum and then brought to the Filter Cavity Enclosure.

We closed FCV-3 (BSC3), FCV-6, FCV-8, and FCV-9 (HAM8) to isolate the C6 cross. Then closed the -Z axis GV on the C6 cross to isolate the ion pump port. We then vented the ion pump assembly with N2 and removed the angle valve/6" zero-length reducer on the cross, and installed the ion pump on the 6" CF port. A genie lift was used to lift/hold the ion pump while the connections were made.

Once installed, we used the leak detector/small turbo to pump down the assembly, and then helium leak tested the one CF connection that was made. There was no detectable signal above the helium background of 9.5E-10 Torr-l/s.

The ion pump was powered on locally, and quickly dropped to ~2mA. The -Z gate valve remains closed, and the rest of the FCT gate valves were reopened once the ion pump was leak checked and powered on. We will continue with the installation of the rest of the pumps in the following weeks.

Fil, Dave, Rahul

Turns out that the fault reported by Jenne (see alog 73447) at the ETMY R0 Test Coil Enable (which went red) was due to a faulty cable connecting Binary Input to the Binary Card in the IO chassis. It took us 3hrs to figure it out after checking the IO chassis and Coil driver - which were working fine. Dave also power cycled the IO chassis to help us figure it out. Fil thought it could be the binary card (at first and IO chassis later) which we replaced (only the binary card - GCRBS96004326) with a new one but no success. In the end we changed the cable and it made the Test coil (channel F1 and F2) working again.

WP 11477 Closed.

WP11462 Run latest Picket Fence code on nuc5

Edgard, Erik, Dave:

Erik upgraded the userapps git checkout of the picket fence code last Friday, I restarted the code on nuc5 this morning. The only change I made was to add the display of the state borders to the map.

WP11469 Testpoint Stress Test h1pemcs

EJ, Joe, Dave:

With the static DAQ DQ list unchanged, I tested how many testpoints could be opened on h1pemcs.

Result: 62 TPs can be opened (get low level DAQ error if 63 are attempted). PEM measurements require 43 accelerometer TPs, which leaves 19 additional TPs which can be used for PEM injection measurements.

Test code is h1pemcs_testpoint_test.py (web_svn) more details of the test can be found in the comment header block.

WP11468, WP11473 Reconfigure h1didivideo[0,1,2] network ports and reboot

Jonathan, Patrick:

The h1digivideo[0-2] machines were made to be dual-homed, giving the camera LAN a separate ethernet connection. As part of this upgrade, the machines were rebooted which cleared the almost full memory.

WP11477 h1susey BIO readback error

Fil, Rahul, Dave:

Fil and Rahul investigated the ETMY reactionary chain BIO readback, showing F1 DAC drive was in test mode. During the investigation the h1susey front end was fenced from Dolphin and power cycled.

The Contec6464 card for the R0 signals was swapped with a spare:

The problem was found to be in the cable connecting the Contec6464 card to its BIO Chassis. This means that the removed card is most probably a good card.

Tue Oct 17 10:11:38 2023 INFO: Fill completed in 11min 35secs

J. Kissel

Betsy asked me to put together a prioritized list of 18-bit DACs that could be upgraded to 20-bit DACs during the upcoming Jan / Feb 2024 commissioning break in order to close out IIET:13232 and IIET:20828. We don't think we'll have time to do *all* the DAC upgrades during the break, and thus we again find ourselves asking the priority DACs / IO chassis to hit first.

I note that in IIET:13232, the last comment *attempted* to create this list what remaining "pum" stages needed upgrade based on what was *not* mentioned in LHO:66836, but the story is incomplete because IIET:20828 says that "we just need to upgrade them all."

So, here's the prioritized list of the 31x 20-bitDAC cards remaining to upgrade, granulated into 3x to 5x card swaps.
	(a) [2x] Close out [1] and upgrade PRM M2/M3, and PR2 M2/M3. 
		DAC5 (Slot 8, card_num = 5) on h1sush2a for PRM
		DAC4 (Slot 7, card_num = 4) on h1sush34 for PR2
	(b) [2x] Upgrade PR3/SR3 M2/M3 DACs
		DAC6 (Slot 9, card_num = 6) on h1sush2a for PR3
		DAC3 (Slot 6, card_num = 3) on h1sush56 for SR3
	(c) [1x] Upgrade ITMX and ITMY UIM DACs
		DAC4 (Slot 8, card_num = 4) on h1susb123
	(d) [3x] Finish out susex IO chassis upgrades (which is ETMX M0 / R0 and TMSX M1)
		DAC0, DAC1, DAC2 on h1susex
	(e) [3x] Finish out susey IO chassis upgrades (which is ETMY M0 / R0 and TMSY M1)
		DAC0, DAC1, DAC2 on h1susey
	(f) [5x] Finish out susb123 IO chassis upgrade (which is ITMX M0/R0, ITMY M0/R0, and BS M1)
		DAC0, DAC1, DAC4, DAC5, DAC9 on h1susb123
	(g) [3x] MC2 M2/M3, MC1 M2/M3, MC3 M2/M3
		DAC3 (Slot 7, card_num = 3) on h1sush34 for MC2
		DAC3 (Slot 6, card_num = 3) on h1sush2a for MC1
		DAC4 (Slot 7, card_num = 4) on h1sush2a for MC3
	(i) [3x] MC1/MC3/PRM/PR3 top masses
		DAC0 (Slot 2, card_num = 1) in h1sush2a for MC1/MC3 M1
		DAC1 (Slot 4, card_num = 1) in h1sush2a for MC3/PRM M1
		DAC2 (Slot 5, card_num = 2) in h1sush2a for PRM/PR3 M1
	(j) [3x] MC2/PR2/SR2 top masses
		DAC0 (Slot 2, card_num = 0) in h1sush34 for MC2/PR2 M1 
		DAC1 (Slot 4, card_num = 1) in h1sush34 for PR2/SR2 M1
		DAC2 (Slot 5, card_num = 2) in h1sush34 for SR2 M1
	(k) [4x] SRM/SR3/OMC top masses
		DAC0, DAC1, DAC2, DAC3 in h1sush56
	(l) [2x] IMs
		DAC0, DAC1 in h1sush2b

Of course, you can group the lower priority stuff in larger chunks, if you like and/or if you don't want to drag out the upgrade across many days.

Or if it's easier to replace an entire IO chassis DAC cards, rather than think about / risk the mistake of replacing the wrong card, you can do that too (this is what LLO did in the end).

If you want to do it by IO chassis, here's a prioritized list for that instead:
	(b) h1sush2a (to get the PRM, PR3 M2/M3's up to 20-bit DACs, you'll get all the less important MC1 / MC3 M2/M3 stages and top-masses with this "for free")
	(c) h1sush34 (to get PR2's M2/M3 up to 20-bit DACs, you'll get all of MC2 and the rest of SR2 upgrades "for free")
	(d) h1sush56 (to get SR3's M2/M3 up to 20-bit DACs, you'll get the top-masses of SRM and SR3 "for free")
	(a) h1susb123 (to get the ITM UIMs up to 20-bit DACs, you'll get the ITMX, ITMY, BS top masses "for free")
	(e) h1susetmx (to finally get all the end-station top masses done)
	(f) h1susetmy (to finally get all the end-station top masses done)
	(g) h1sush2b (to get the IMs)

Note that there's a few discrepant documents out there quotes a total count of 
    - "29x," (Keith's Mar 2023 inventory, E2300281) 
    - "30x," (Fil's re-inventory in Sep 2023, as a part of the A+ O5 review E2300309) 
    - and here I quote 31x cards.
I would guess that this discrepancy results from folks missing a DAC or two here or there; could be, for example, that the IMs were overlooked.
If we don't have the cards for the IMs, that would be the first set of 2x 20-bit DACs that I would suggest we convert to 1x 16-bit DACs (and change the AI chasis, accordingly).

Maintenance has completed, we will begin relocking.

Work done by Patrick Thomas and Jonathan Hanks

WP11473 was completed.  We adjusted the network setup of the h1digivideo0-2 machines to match h1digivideo3.  Now all 4 systems are dual homed, with one interface on the workstation subnet and on the aux/camera network.  This allows for a simpler multicasting network setup (and matches LLOs setup better).  This is done as a preparation step for eventual replacing the core network switch in CDS (with a simpler multicast setup).

We updated the DNS to move h1digivideo[0-2] to the 10.22... network and added h1digivideo[0-3]-cam entries to reference the 10.106... network entries for the systems.

WP11468 was to reboot the h1digivideo0-2 machines.  We did this as part of our check that things where working after the network changes.  The idea was to restart the system to clear up some long running memory leaks.

As the FSS RefCav TPD has been trending down and a remote alignment did not improve it, I went into the PSL enclosure this morning to tweak the beam alignment on the table.  All work was done with the ISS ON unless otherwise noted; I had to increase the ISS RefSignal from -2.00V to -1.98V to keep the ISS stable with the enclosure environmental controls ON.  In addition, the IMC was OFFLINE for the duration of my time in the enclosure.

I started by taking a power budget of the FSS path:

• FSS In: 290.9 mW
• AOM In: 289.9 mW
• AOM Out, Single-pass: 175.0 mW
  • Single-pass diffraction efficiency: 60.4%
• AOM Out, Double-pass: 125.7 mW
  • Double-pass diffraction efficiency: 71.8%
• EOM Out: 125.7 mW

Seeing the single-pass diffraction efficiency low, I adjusted the AOM alignment to improve it; the AOM had to be moved DOWN.  This resulted in the single-pass AOM output at 216.9 mW and a single-pass diffraction efficiency of 74.8%.  The double-pass AOM output was then measured at 155.4 mW, so I adjusted mirror M21 to see if I could improve it.  This resulted in the double-pass AOM output at 160.1 mW and a double-pass diffraction efficiency of 73.8%.  Much better.

I then double checked the beam centering on the EOM, which was good so I relocked the RefCav.  I needed to adjust mirror M23 slightly in pitch to get the RefCav REFL beam in roughly the same place on the REFL camera, then the RefCav autolocker locked it with no issues.  I used the picomotor mounts to tweak the RefCav alignment to max the TPD; this gave a TPD of 0.99 V.  Very good.  To finish I unlocked the RefCav, tweaked the beam alignment on the RFPD, then locked the RefCav again and measured the visibility:

• Unlocked: 1.326 V
• Locked: 0.225 V
• Visibility: 83.0%

Job done, I left the enclosure.  During my time in there the PMC Refl power had increased from ~16.1 W to ~17.9 W (this increase is normal with enclosure incursions), so I turned the ISS OFF while the PSL enclosure and PMC returned to thermal equilibrium.  At the time of this writing the PMC Refl power has dropped back to ~16.8 W, so I will continue to monitor it over the remaining maintenance time and turn the ISS back on once it gets closer to its normal value.  Also at the time of writing the IMC has been relocked; with the IMC locked the FSS TPD is ~0.96 V (the change with the IMC locked is normal).  This completes WP 11474.

Following alog 73227, reduced  H1:SQZ-SHG_FIBR_REJECTED_DC_POWER from saturated value of 0.7mW to 0.04mW.

TITLE: 10/17 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 4mph Gusts, 3mph 5min avg
    Primary useism: 0.06 μm/s
    Secondary useism: 0.41 μm/s
QUICK SUMMARY: Lost lock as I was typing out this log ending a 24.5 hour lock. Unsure of the cause. Primary and secondary useism are high, hopefully this is a non-issue for relocking after maintenance.

TITLE: 10/16 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 162Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY:

- EX saturation @ 5:17

- 5:29 - inc 5.5 EQ from Iran

• 6:17 - EQ mode activated, back to CALM @ 6:27

- Violins have been stable over the course of the night after the ring heater changes from earlier today

- "PSL FSS TPD transmission low" notification has been popping up sporadically throughout the night - Tagging PSL
LOG:

No log for this shift.

TITLE: 10/16 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
INCOMING OPERATOR: Austin
SHIFT SUMMARY:

We dropped out of Observing to reverse the previously (last week, alog73445) done ring heater changes in 2 steps 2 hours apart, first step was done from 20:39:51 - 20:40:23UTC, the second was from 22:41:46 - 22:24:19UTC. alog73503

The wind has started to pick up over the past 2 hours, gusts up to 35mph which is probably what's degrading our range over the same timeframe, and microseism remains slightly elevated.

LOG:                                                                                                  

Ryan informed me at 20:48 UTC (13:48 PDT) that he was getting a PSL Chiller alarm, a likely indication that the level was low.  I had to watch the chiller for several minutes as the level slowly moved up and down with the regular flow of water in and out of the reservoir, but sure enough the water dipped just below the threshold and the chiller threw a Low Water Level alarm.  I added 150mL to get the reservoir to the Max line and the alarm went away.

We are averaging ~180mL of water added every 6 weeks, this has been fairly constant since late-April 2023.  I'll be in the enclosure tomorrow so will be able to do our customary leak check (a habit that's developed since we don't go into the enclosure unless necessary); I don't expect any leaks since the amount of water being added has not accelerated, but it's good practice to check while I'm in there.