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.

Jim, TJ, Robert

We damped the periscope on ISCT1 by removing the dog clamps one by one and inserting a strip of 1/16" viton between the dog clamp and the base of the periscope before retightening, making sure that the strips crossed the corner of the base. This is not the most effective way of damping the periscope but it was the fastest, safest and most simple damping we could do. Jim measured the Q to be around 1000, so we didn't have to do much to get an improvement. In Jim's first transfer functions after the damping, the peak looked a little wider.

Fil, Keita, Daniel, Camilla  WP12598 WP12584

We swapped the old REFL Analog Camera to a Gige Digital Camera (Basler acA720-290g m S/N 40477593) on ISCT1 and cabled to the table feedthrough. There was no beams today so the alignment may need to be touched up.

Keita and Daniel also removed the MCL steering mirror, controller and the in-air POP-X WFS (S1300511, now stored in the EE shop) with mirror and lens from ISCT1. MLC controller and PZT will be stored in mid station storage. The beamsplitter towards the old POP-X path stayed but was blocked with the beam dump that used to be dumping the POP-X reflection.

Table layout D1201103 not yet updated. Photo of table attached. 

WP 12572
The 24V power for the table enclosure lights on ISCT1 and IOT2L were rerouted through the Interlock/Lighting patch panel D1201535. Panel has a power switch and Status On/Off indicator. The dimmer functional was left in place and requires both the panel power switch and dimmer in the ON position for LEDs to power on.

WP 12574
New GigE camera was installed in ISCT1, alog 84866. Camera is connected to the new CER switch, port 12. Three ports on the SUS-R1 patch panel are available for new GigE cameras.

Power to the three IOT2L analog cameras was disconnected:

1. WFSA
2. WFSB
3. REFL

Power cable did not have a dedicated Feedthrough. Analog cameras are no longer used. The 18V power cable is on top of IOT2L if power needs to be reconnected.

HWS servers now point to /ligo/data/hws as the data directory.

The old data directory, h1hwsmsr:/data, is now moved to h1hwsmsr:/data_old

The contents of the old directory were copied into the new directory, except H1/ITMX, H1/ITMY, H1/ETMX, H1/ETMY, under the assumption that these only contain outputs from the running processes.

HWS processes on h1hwsmsr, h1hwsmsr1, h1hwsex were stopped and restarted and are writing to the new directory.

h1hwsey had crashed previously and wasn't running.  It was restarted and is also writing to the new directory

This is a very quick first look at the ASC performance with the HAM1 ISI. Jim is still working on bringing the ISI up to full performance, but the first attached plot compares the INP1 P and CHARD P error spectra from March 31 just before the vent and yesterday, when we locked to full power and low noise with HAM1 in the isolated state.

Before the vent, we were running feedforward of the HAM1 L4Cs to CHARD, INP1 and PRC2. PRC2 is now on the POP sensor, and CHARD and INP1 both use a combination of the REFL WFS 45 MHz signals. The large peak around 20 Hz before the vent appears to have reduced in INP1 P and shifted down in frequency in CHARD P. The second attachment shows that large peak in CHARD P is coherent with the HAM1 GS13s, from about 10 to 20 Hz, especially with RX, RY, RZ, and Z.

There is also a peak at 6 Hz, which we know is a vertical resonance of the RMs, 84712.

WP12596

Daniel, Vicky, Kevin, EJ, Erik, Dave:

We have installed new h1ioplsc0 (RCG5.1.4) and h1omcpi(RCG5.3.0) models. This led to a small IPC receive error rate on h1omcpi. To correct for this we upgraded h1omc0 from RCG5.3.0 to the latest RCG5.5.0, rebuilding all the models [h1iopomc0, h1omc, h1omcpi] against this RCG. Erik booted h1omc0 from the new boot server h1vmboot5-5 (and removed it from h1vmboot0). We are letting it sit for a while to ensure there are no IPC errors before a DAQ restart.

Fri Jun 06 10:04:56 2025 INFO: Fill completed in 4min 52secs

For FAMIS #26389:  All looks well for the last week for all site HVAC fans (see attached trends).

To investigate the 70Hz feature in HAM1 chamber, which Jim reported in his alog (LHO 84638) I started looking into the structural resonances of the periscope which is installed in HAM1 (see two pictures which TJ sent me, was taken by Corey here - view01, view02) .

Betsy, handed me a periscope (similar but not exactly the same) for investigation purpose, which is now setup in staging building. I attached an accelerometer to the top of the periscope and connected it to the front end of the B&K setup for hammer impact measurements - see picture of the experimental setup here. 

At first I used two dog clamps to secure the periscope. The results of the two dog clamp B&K measurement is shown in this plot (data from 0.125 to 200Hz)) - one can see a 39Hz feature in the Z hit direction. See zoomed-in (30-100Hz) figure here.

Next, I attached a third dog clamp, just like in HAM1 chamber and took a second round of measurements (especially for Z direction impact). 

This plot compares the two vs three dog clamps scenario on the periscope and one can see that the resonance mode has been pushed up from 39Hz to 48Hz. 

FAMIS28948

The quarterly reminder came at a good time for us to restart fresh for observation next week. Reboot went as expected, no hiccups. Reboot started at 1553UTC.

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.

I was only able to take the broadband measurement due to an earthquake that knocked us out of lock a minute later. We had been at full power for around 5 hours at the time this measurement was run. Unfortunately since we weren't able to take the Simulines measurements, I am not able to run the report.

Broadband:

Start time: 1433118749 (2025-06-05 00:32:11 UTC)

End time: 1433093874 (2025-06-05 00:37:36 UTC)

Data found in: /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20250605T003226Z.xml

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.

I haven't had time to post this because of the wind fence work, but I haven't been able to finish the commissioning of the HAM1 ISI because of a 70-ish hz feature in mostly the X and RZ plants. I didn't see or appreciate how large this 70hz feature was in my close out measurements before doors went on, and it's making the loop design very difficult. I was trying to notch the loops to make the ISI work, but 70hz is very close to the nominal 30hz loop ugf. The X,Y,RZ and Z loops are marginally stable right now, and the  70hz feature gets injected into the IMC when ALS is locked. I think that I can get the loops working, but probably with less gain than we would otherwise get.

Attached PDFs are the loops currently installed, the ISI is set to not use the RX and RY loops, but the X loop is probably ringing at 70hz when the ISI is isolated. We are currently running with just the damping loops though.