Sat Jun 07 10:05:59 2025 INFO: Fill completed in 5min 55secs

Erik, Dave:

Web ndscope trends stopped updating around 09:45 this morning. Some nomachine sessions are having issues.

We are investigating.

Gerardo, Travis, Randy, Janos

Today we executed WP 12595, reventing, troubleshooting, closing, and re-pumping HAM1. The times of the operations are approximate.

08:00 - 08:30: GV1 and GV2 large gate valves have been closed. HAM1 turbo and Ion pump (IP13) have been valved out. The annulus IPs have been switched off, the annulus volume has been vented. Also, IP3 was valved in to the corner, after the successful troubleshooting yesterday (see aLog 84826).
08:40 - 09:53: The chamber was vented with bottled Nitrogen. Approximately 2 full bottles were needed. Only metallic parts were used between the venting port and the bottle (no plastic tubes), and the tube was flushed with Nitrogen beforehand.
10:00 - 10:40: The Y+ door has been taken off. The O-rings have been inspected, then removed. A human hair was found at 6:30 o'clock, and a little piece of white tape was found in the O-ring's groove at 8:00 o'clock, and overall, the O-rings and grooves were substantially dirty. Pictures about these in the comments. Also, the cleanroom was needed to be moved Y+ direction, to give enough room for the forklift.
10:40 - 11:40: Chamber work. During this time, Randy stayed with the forklift, so the door was hanging from it all the time, and inside the cleanroom.
11:45 - 13:30: O-ring installation: it took a few tries, but both O-rings were installed nicely. Then, installing back the door: smooth process, with shoving it in as the last step, to avoid the O-rings falling out.
13:20 - 13:50: Pumping of the annulus systems, and roughing the chamber. The HAM1 side annulus needed ~10 mins to go below the pressure it reached in the last 2 weeks, so the troubleshooting was very successful! The roughdown goes well, too.
16:15 - 16:45: Transitioning to turbo

WP12596 ADF VCXO IPC between IOP-LSC0 and OMCPI

Daniel, Vicky, Kevin, EJ, Erik, Dave

New h1ioplsc0 and h1omcpi models were installed to add two IPCs at 64kHz rate between lsc (sender) and omcpi (receiver)

    H1:FEC-7_IPC_IOP_PCI_ADF_VCXO_COS
    H1:FEC-7_IPC_IOP_PCI_ADF_VCXO_SIN

After the new models were restarted we noticed that the new receivers were flashing with a single RX error (1 out of 65536 in that second) every few seconds, randomized between the two new channels.

At this point we upgraded h1omc0 from RCG-5.3.0 to RCG-5.5.0, the new system has code to correct for such receive errors. Erik had the new 5.5.0 boot server ready to go, it is h1vmboot5-5 (a new naming scheme).

This required the rebuild and restart of all the models on this frontend (h1iopomc0, h1omc, h1omcpi). The new RCG added slow channels, so a DAQ restart was required for all these models.

The builds on RCG-5.5.0 use EJ's new rev-lock system, whereby all the source code (mdl and C) must be committed to subversion, and only the locked revision of these files are used to build the model, not what happens to be in the userapps models directory at the time. This worked like a charm.

Later Vicky added some filtermodules to h1omcpi, which required a second restart of  h1omcpi and the DAQ.

WP12597 Quarterly reboot h1guardian0

TJ

TJ rebooted the guardian machine, it came back with no problems.

WP12603 HEPI HAM1 model cleanup and removal of TT-L4C IPC senders, switch SEI-PROC to ISI HAM1 GS13 IPC

Jim, Erik, Dave:

New h1hpiham1 and h1seiproc models were installed with no problems. DAQ was restarted, both models had new INI files.

Move HWS data from h1hwsmsr local RAID to /ligo NFS

Erik, Dave:

Erik reconfigured the HWS machines to mount /ligo/data/hws as /data locally. Some files needed to be copied to the new location before the HWS cameras could operate and write current files to the new location. Archived data is being transferred to preserve lookbacks.

DAQ Restarts (plural)

Erik, Dave

Restart 1

11:02 DAQ was restarted for two changes, first the expected changes to h1ioplsc0 and h1omcpi. Second for the unexpected upgrade of h1omc0 to RCG-5.5.0 which added channels to h1iopomc0 and h1omc, and additional channels to h1omcpi.

Clean restart except GDS1 needed a second restart

Restart 2

13:52 DAQ was restarted for the h1hpiham1 and h1seiproc model changes.

Clean restart except GDS1 needed a second restart

Restart 3

14:33 DAQ was restarted for additional change to h1omcpi.

Clean restart except, you guessed it, GDS1 needed a second restart

Note that the Vacuum upgrade which would have required a DAQ restart did not go ahead today.

TITLE: 06/06 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Corey
SHIFT SUMMARY: We're pumping back down on HAM1.
LOG:                                                                         

Busy day, work completed includes but is not limited to:

Transition LVEA to Laser Safe for Upgrade Period permit

GRD restart (TJ) alog84854 // permit

OMC and LSC model restarts with DAQ restart 1 (CDS team) alog84861 // permit

HWS file work (Erik) alog84865 // permit

HAM1 door prep (including ISCT1 move, alog84850 // permit), removal (VAC team plus many others) permit, and reinstallation

ISCT1 work - new camera and old parts removal (Camilla, Keita, Daniel, Fil) alog84866 // permit, periscope damping with viton (Jim, TJ, Robert) alog84868

h0vaclx unsuccessful alog84871

HAM1_HEPI and SEIPROC model restarts and DAQ restart 2

WP 12577

I tried unsuccessfully to use the PowerShell scripts to generate the new h0vaclx TwinCAT 3 solution that adds the BCG552 gauge to HAM1. We are reverting back to using the voltage readout into the ADC on h0vacly. I think the most viable path forward may be to install Visual Studio 2019 onto h0vaclx or see if we can use the TwinCAT remote manager to configure and control the PLC on h0vaclx from another machine. If the second option can work, then I think it may be the best.

This was done on h0vaclx:
Updated WinSCP to 6.5.3.
Downloaded and copied the Inficon Trigon BCG552 EtherCAT ESI-File to C:\TwinCAT\3.1\Config\Io\EtherCAT.
Tried and failed to generate a TwinCAT 3 solution from the new PowerShell scripts.
Exported the current version of the library code in git to PLCopenXML and imported it into a new Visual Studio 2010 solution on h0vaclx. Built the solution, saved it as a library, and installed the library file into the TwinCAT 3 Library Repository on h0vaclx as version 2.0 (version 1.0 is being used in production)
Tried and failed again to generate a TwinCAT 3 solution from the new PowerShell scripts.

Craig mentioned yesterday that we might want to walk our IMC uncontrolled degree of freedom: the spot position on MC1 and MC3. I made a short script which should step the sliders of MC1 and MC3 in the correct configuration (differential step in pit, common step in yaw). If you want to run it is in

/ligo/gitcommon/labutils/imc_walk

To step both mirrors by eg 0.1 microradians, run python walk_imc_dof_4.py P 0.1

This might not end up being used since Robert suspects much of our jitter could be caused by the multiple roughing pumps running in the LVEA.

I noticed that the LLCV is railing at its top value, 100% open, it can't open no more.  This is a known issue, but it appears as if the valve is reaching 100% sooner than expected, meaning when the tank is almost half full.  First, I'm going to try a re-zero the LLCV actuator and await for the results.  First attachment is a 2 day plot of LLCV railing today and yesterday.  The second plot is a 3 year history looking at the tank level and the LLCV, it rails at 100% a few times.

Bin Wu, Julia Rice

We have been working on writing a new Guardian script that will allow us to switch off the dither loops sooner in the power up process and instead use cameras.

We first looked at the error signals in the ASC cameras to see if we could adjust offsets to better values. We did this for the CAMERA_SERVO guardian, and added new intermediate states, including TURN_ON_CAMERA_25W_OFFSETS and TURN_ON_CAMERA_MOVESPOTS_FIXED_OFFSETS. We've attached screenshots showing the graph before and after our additional states. Below are the values we used for offsets for each. The weight from DITHER_ON to TURN_ON_CAMERA_25W_OFFSETS is set to be 10.

TURN_ON_CAMERA_25W_OFFSETS

TURN_ON_CAMERA_MOVESPOTS_FIXED_OFFSETS

We also adjusted the offsets for TURN_ON_CAMER_FIXED_OFFSETS:

These are added in lscparams.py. We also added the necessary code into CAMERA_SERVO.py.

We also added a parameter in lscparams.py for new ADS camera CLK_GAIN at 25W  ('ads_camera_gains_25W', screenshot included)

Right now the new states are not requestable, so they will need to be ran manually to test. We haven't made any change to the ICS_LOCK guardian.

Today at ~11:10 am, IP3 (LVEA 2x 1250 l/s IP) failed leading to a slight pressure rise in the corner. Seen on all LVEA pressure gauges (BSC2, HAM6, etc.). Attached snapshot shows the two pumps behavior at the time of failure, pump ion current on left column, output voltage on right.

Gerardo and I went to the mechanical room to diagnose the controller, upon arrival both channels on the Dual Vac controller had tripped off. We reset the high voltage and powered on the IP. Channel 1 (corresponding to Pump A in CDS) would only reach 300 V and then would trip the controller. Channel 2 (Pump B would reach 7kV no issue but would trip when Channel 1 tripped). We then swapped to a Gamma MPC controller to test if the controller was the problem. We saw the same exact behavior where Pump A would only reach 300V and Pump B was ok at 7kV.

We then swapped back to the DualVac controller after confirming it was not the issue, but with only Pump B connected and powered on. We are continuing to monitor to make sure Pump B remains steady. In parallel, Travis and Mark are testing the HV cable to the pump to see if there are any shorts. Results to follow.

If the cable is not the culprit we will HiPot the pump to see if there are any shorts, pump will be isolated from main volume during this test. To be continued.

Daniel, Kevin, (Erik, Dave), Vicky

Kevin is interested in taking ADF sweeps around the second higher order mode arm resonance near 10.4 kHz.

We (Daniel) made model changes in h1ioplsc0 and h1omcpi that should enable higher freq ADF demods. Daniel built the models successfully. Then Dave also built these models successfully for the custom RCG running on h1omcpi for the variable duotone. We put in a WP to boot in these changes to h1ioplsc0 and h1omcpi next Tuesday 6/10.

From h1ioplsc0, we added 2 new PCIe channels to write the digital ADF LO oscillator out to PCIe. These are H1:IOP-PCI_ADF_VCXO_{COS,SIN} in screenshot 1. We also changed a rogue limiter such that the ADF should be able to scan +/-1 MHz according to the PLL.

In h1omcpi, we use the fast 64 kHz OMC PI user model to do a fast digital demodulation of the OMC_DCPD_SUM signal using the above ADF-LO PCIe channels. This is beating the fast dcpd output signal (H1:OMC-PI_DCPD_64KHZ_AHF), against the ADF LO's cosine and sine components from PCIe (H1:IOP-PCI_ADF_VCXO_{COS,SIN}), to get the demodulated ADF I/Q signals. The demod signals will have names like H1:OMC-PI_ADF_DEMOD_{I,Q}. Screenshots 2-4.

Operationally nothing should change for the ADF or for OMC-based fast PI damping. We are just using PCI to send 2 IPC channels from an IOP model to a user model on a different computer at ~65kHz, and doing the demod in a 64kHz user model (but the demod does not go anywhere, it is just used for squeezer diagnostics).

J. Freed,

Spur Problem

As discussed in part 1, the Double Mixer has good phase noise around the carrier frequency to about a 100Hz out where SPI operates, however, it also has signals every 4096Hz away from the carrier.  I had assumed that it was an issue relating to phase and amplitude mismatch on the phase delayer, but after adding attinuators to correct the missmatch, it helped, excepecially the 80Mhz + 4096Hz signal saw a ~15dB improvement. DM_Att.pdf. However, the double mixer still has large signals and the largest did not change with the addition of the attinuators.

I realize now that the problem lies with the mixers themselves as by the nature of a mixer they create spurs on the output. 

DM_Mixer.pdf Shows the output of a single mixer. Along with the expected 80MHz - 4096 Hz and 80MHz + 4096 Hz there is extra peaks which i believe is caused by the Spurs of the mixer. The largest spur is at 80Mhz + 12,288Hz. This spur is actually in phase with the main signal and is thus construtivly interfered at the power combiner. 

I do not know how to get rid of this spur as it is so close to the main carrier signal. For fun, I used a combination of Marki LC filter Design Tool and LTspice to simulate adding a filter to the end of the system to reduce the 80Mhz + 12,288Hz spur, but even an 8th order elliptical filter would only reduce the spur by ~0.04dB due to how close it is to the main signal. For fun I went to 20th order elliptic and it only reduced it by ~0.1dB. In addition, with nonstandard parts for a 20th order elliptic it got reduced by ~4dB. I am unsure of any other method to reduce the spur.

Double Mixer is a Single Sideband Mixer

I realize now that the basic design of the double mixer actually exists and is fairly common, it is called a Single Sideband Mixer (SSB mixer). Thanks to Brian, who gave me one of these mixers to test, I have something to compair the results  

DMvsIRM.pdf Shows a plot of the double mixer vs a SSB mixer. The SSB mixer is tuned to 80MHz+4096Hz as apposed to the Double Mixers 80MHz -4096Hz but comparisons can still be made. For starters, the double mixers 80Mhz+4096Hz sideband equivalent is much better in the double mixer vs the SSB. However this comes at the cost of the 80Mhz+12,288Hz sideband equivalent which is much better in the SSB. In summary, just based on this single graph, the double mixer is more likely to be better for SPI for 2 reasons. One, we have already found out that SPI would be senstive to the 80MHz+4096Hz sideband equivalent. And two, if there is a way to attinuate these spurs by filtering, the spur further away from the carrier could be more easily attinuated.

High order modes filtering

Ive already discussed that adding fliters does not help the area around 80MHz. However, it does help with higher order modes

DM_Filter.pdf Shows a plot of adding a MC80-10-4AA bandpass filter from Lark engenering that has a bandwidth of 10MHz and a center of 80MHz at different positions in the Double Mixer. The best place to put one seems to be just before the amplifier, not entirly sure if adding one is nessisary to SPI but it should be good for reduceing a possible noise source.