S. Dwyer, J. Kissel, D. Sigg

While finding out the best effective frequency noise estimate on the SQZ side of things, we found a VCO calibration in FM3 available on the fast path of the SQZ LO frequency servo (H1:SQZ-LO_SERVO_CTRL), which turns that out-of-loop, pick-off path into a diagnostic effective frequency noise estimate (in lambda = 1064e-09 [m] "red" light). See attached screenshot for how to find this filter bank.

While we can't quickly find any documentation/aLOG on this calibration, it makes sense to us that it has the same frequency response (a zero at ~40 Hz, and a pole at ~1.6 Hz) and roughly the same gain as the primary CARM / IMC Common Mode board servo's fast path (~237000 [Hz/V]).


    IMC VCO calibration     FM3 "VCO"   zpk([40],[1.6],237000,"n")         LHO:65175 (Updated Sept 2022)
    SQZ LO VCO calibration  FM3 "VCO"   zpk([39.72],[1.5292],260000,"n")   (Installed O3 era, we think)

I've accepted the VCO, FM3 filter as ON in the H1SQZ safe.snap SDF, and confirmed that it's either ignored or by default *also* saved to the OBSERVE.snap. 

DAQ Channel Changes:

* Fast channels were renamed (name, bytes, rate):

new H1:SQZ-SHG_TRANS_RF24_I_NORM_DQ 4 16384
new H1:SQZ-SHG_TRANS_RF24_Q_NORM_DQ 4 2048
old H1:SQZ-SHG_TRANS_RF35_I_NORM_DQ 4 16384
old H1:SQZ-SHG_TRANS_RF35_Q_NORM_DQ 4 2048
 

GDS Channel Changes:

The fast channels were also being sent to DMT from the GDS machines. They were renamed from RF35 to RF24.

The COMM beatnote has been a bit low lately, and coupled with higher microseism and temperature changes, it has caused us some locking troubles. So today Sheila and I brought PR3 back to a time that had a good top mass osem alignment around 20 days ago, then we went to ISCT1 to get a better buildup by adjusting the two beam splitters circled on the table layout attached while trying to maximize H1:ALS-C_COMM_A_DEMOD_RFMON. I mainly had to move in yaw, walking a bit with both optics.

In the end we ended up with the beatnote around +3dBm.

WP11510 h1hwsey IOC simulation

Dave:

I am running a simulation HWS-ETMY EPICS IOC on cdsioc0. This is a python pcaspy file, h1hwsetmy_dummy_ioc.py. Its channel list is a combination of those in the EDC and in the slow controls SDF. For those SDF entries with non-zero set points, the IOC sets its epics to those values to zero the difference counter.

I have undone the temporary changes made while HWS-ETMY was unavailable: green EDC with 86 disconnected channels, set tcshwssdf OBSERVE.snap values to zero.

WP11506 SQZ Beckhoff Slow Controls Code Change

Daniel, Dave:

Daniel's Beckhoff changes resulted in changes to H1EPICS_ECATSQZCS.ini and h1syscssqzsdf monitor.req files. I generated the new H1EDC.ini ready for a DAQ restart. I restarted the h1syscssqzsdf node on h1ecatmon0.

Move CDS WIFI WAP control IOC from opslogin0 to cdsioc0

Dave:

I finally got round to moving the h1_unifi_ioc code from its 'temporary' location on opslogin0 to its permanent location on cdsioc0. This was in response to some issues with nomachine which slowed my restarting this service this morning. h1_unifi_ioc runs under systemd control on cdsioc0 as user ioc, its configuration if under puppet control.

WP11514 h1sqz model changes

Daniel, Jonathan, Dave:

We installed Daniel's latest h1sqz model. This added some slow channels, and renamed two fast channels. DAQ restart was required. We discovered the two fast channels were in the GDS configuation.

DAQ Restart

Jonathan, Dave:

The DAQ and EDC were restarted for the model and Beckhoff changes above.

gds0 had an extended downtime when we found that the renamed RF35->RF24 channels were in the GDS channel list. Once we had resolved that on gds0 and gds1 the restart proceeded with no issues.

Initial alignment - For Input alignment I needed to trend IM4 and PR2 top mass osems back to where they were at the beginning of the last lock acquisition, then move PR2 a bit to get good flashes down the X arm. I also bumped up the LSC-XARM gain from 0.04 to 0.06 to help catch.

The rest of initial alignment went smooth and we will begin the main locking sequence now, with some code tests on the way up.

The cable for the 40MHz delay line used to lock the green filter cavity, ISC_SQ_498, was moved from sqz chassis 4 slot 13 to the new sqz chassis 5 slot 10.

LVEA Swept following T1500386. WAP off. Noticed nothing other than what Oli noted in 73244. I thought I heard a louder fan noise in the computer HV mezzanine but Fil checked that it was just the usual noise.

Robert was still in LVEA entrance, clearing up with lights on but will turn lights off.

From the safety injections on 2023-10-24 it seems like three channels (not in the usual H1 channel list) have gained a coupling to h(t) in the frequencies around 100 Hz since the 2023-07-26 injections. The low-frequency coupling is not new. Here are the channels: H1:ASC-OMC_RIN_OUT_DQ, H1:ASC-OMC_B_NSUM_OUT_DQ, and H1:ASC-OMC_A_NSUM_OUT_DQ. 

Channel | Omegascans 2023-07-26 | Omegascan 2023-10-24

H1:ASC-OMC_RIN_OUT_DQ | https://ldas-jobs.ligo.caltech.edu/~geoffrey.mo/hwinj/o4/H1_20230726/omegascans/H1:ASC-OMC_RIN_OUT_DQ.png | https://ldas-jobs.ligo.caltech.edu/~geoffrey.mo/hwinj/o4/H1_20231024/omegascans/H1:ASC-OMC_RIN_OUT_DQ.png
H1:ASC-OMC_B_NSUM_OUT_DQ | https://ldas-jobs.ligo.caltech.edu/~geoffrey.mo/hwinj/o4/H1_20230726/omegascans/H1:ASC-OMC_B_NSUM_OUT_DQ.png | https://ldas-jobs.ligo.caltech.edu/~geoffrey.mo/hwinj/o4/H1_20231024/omegascans/H1:ASC-OMC_B_NSUM_OUT_DQ.png
H1:ASC-OMC_A_NSUM_OUT_DQ | https://ldas-jobs.ligo.caltech.edu/~geoffrey.mo/hwinj/o4/H1_20230726/omegascans/H1:ASC-OMC_A_NSUM_OUT_DQ.png | https://ldas-jobs.ligo.caltech.edu/~geoffrey.mo/hwinj/o4/H1_20231024/omegascans/H1:ASC-OMC_A_NSUM_OUT_DQ.png

Not sure if this is expected or worrying, but I thought I'd report it.

As part of the preparation to add a PMC to the squeezer, a new squeezer EtherCAT chassis 5 was installed. As a side effect, the RF channels with prefix H1:SQZ-SHG_TRANS_RF35 have changed to prefix H1:SQZ-SHG_TRANS_RF24, but only in the slow controls.

The slow controls for the squeezer also got a new H1:SQZ-PMC subsystem that is in an error state due to the fact that the the new chassis is not connected to the field chassis yet.

Tue Nov 07 10:07:57 2023 INFO: Fill completed in 7min 53secs

TJ, Camilla. After we found both CO2 output powers have been changing since the timing master swap 74025, we recalibrated the CO2 rotation stages this morning ~ 16:20UTC. Last done in September 72961. 

Followed the README.txt file in /opt/rtcds/userapps/release/tcs/h1/scripts/RS_calibration/. We did this with annular masks in. I'd previously tried this without using the matlab fitting code and hadn't been able to make a good fit. 

TITLE: 11/07 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Wind
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 17mph Gusts, 8mph 5min avg
    Primary useism: 0.06 μm/s
    Secondary useism: 0.37 μm/s
QUICK SUMMARY:

Detector is DOWN and in WINDY due to high wind. Taking us to Preventative Maintanance for today's maintanence.

Was alerted at 8:49UTC.

Guardian was having trouble with automatic initial alignment due to ALS_XARM being stuck at CHECK_CRYSTAL_FREQ with no valid state to jump to afterwards.

I hit "Load" and restarted initial alignment and waited until Guardian got past this stage in initial alignment, which happened around 50 minutes later at 9:30.

Things seem to be working now so I set guardian/IFO_Notify back to self-managed and expect to be called again if we get stuck for any other reason.

Motivated by interested results from Sheila's ESD tests last week (LHO:73913) and Gabriele finding that there is some nonlinear noise coupling in ETMX L3 from <4Hz to 15-25Hz in DARM (LHO:73937), I've started taking a closer look at the DARM loop to 1.) reduce ETMX L3 actuation below 4Hz (nominally by increasing L1/L2 actuation at low frequencies) and 2.) to have the UIM stage roll off more aggressively, similar to what LLO has had in place since O1 (see for example page 10 of G1501372 and page 11 of G2000149 ). 

I'm uploading the "DARM critique" generated by pyDARM for H1 based on report 20231027T203619Z. This is still a work in progress; I'm just leaving these plots & links here for my own future reference.

As was briefly mentioned in alogs 73853 and 73917, I injected into thermistor 2 (hot one which is directly mounted on the compression ring of the OM2 mirror) and thermistor 1 (cold one mounted on the back of the T-SAMS structure) independently, and measured the transfer fucntion from the injection to DCPD-SUM (and some other TFs).

All traces in the attached show the transfer function and coherence from OMC-TEST_EXC (calibrated to the voltage across the Thermistor) and DCPD_SUM (in mA) when H1 is in high power. Red is the injection into Thermistor 2 (hot one), green is into Thermistor 1 (cold one), both while the heater was ON. There are many peaks, most notably the one centered at around 277Hz (that's where CW people observed the most problematic comb structure) but there are others like 78, 93, 105, 144, 154, 166, 314 and 356Hz with good coherence.

The coupling is actually very small for broadband noise, it's only problematic for lines like we've experienced. For example, even if we take the peak at 277Hz (-75dB = 1.8E-4 mA/V) for Thermistor 2, in order for the voltage noise to be comparable to e.g. the shot noise for 40mA DC (~1.1E-7 mA/sqrtHz), the voltage noise should be ~600uV/sqrtHz (because 1.1E-7 [mA/sqrtHz] / 1.8E-4 [mA/V]) at 277Hz, which is a big number.

Thermistor 1 TF amplitude is smaller by more than 30dB than Thermistor 2 measured at around the 277Hz peak. This cannot be explained by the current difference due to lower resistance of the hotter thermistor (thermistor 1 is 7.41k, thermistor 2 is 4.08k, measured on the floor). It should be the location of the thermistor. FYI Thermistor 2 is mounted on the compression ring of the T-SAMS and is therefore much closer to the mirror than Thermistor 1 that is mounted on the back.

Within the resolution of this measurement, frequencies of Thermistor 1 peaks that are visible do match with Thermistor 2, but the resolution is not great (~2Hz at around 277Hz) so it's not clear if we're looking at the same resonance driven by different thermistors, or if this is actually two different resonances, each belonging to one thermistor but not the other.

Blue is the injection into Thermistor 2, but this time the measurement was done immediately after the heater was turned OFF. I only measured down to 220Hz or so, but anyway I see no real difference between the blue and the red. This means that the magnetic field formed by the heater loop around the mirror is NOT relevant for the coupling. Since our experience was that the comb was NOT there while the OM2 was cold, maybe the coupling is dependent on the tightness of the compression ring.

Injection amplitude was constant (A=8000 i.e. 16000cts pp sine wave for all frequencies, corresponding to ~4.9Vpp across the thermistor), and I was making huge lines in DARM (2nd attachment).

After the measurement, all breakout boards and temporary cables and handheld voltage reference and things were disconnected from the system (but were left on the work table by HAM6, I'll pick them up during the next maintenance). EXC cable was connected back to the DCPD whitening, and Beckhoff cable was connected back to the OM2 heater driver.

I've done some injections today but I'll alog about that later.

After I was done with the injections, the breakout board was removed from the back of the OM2 heater driver and the Beckhoff cable was fully connected again. This happened at around 21:40 UTC today.

Yesterday during the maintenance, Fernando and Daniel changed the Beckhoff configuration such that the Beckhoff terminal won't switch between thermistor 1 and thermistor 2 (alog 73886). Now it's only reading thermistor 1 (cold one) w/o switching. Thermistor 2 (hot one) is not read out.  Detchar, please see if you can see the comb.

We've done three measurements assess OMC loss, but we've found that there's something weird about DCPD transient response (will attach another alog, but it seems as if something is railing inside the chamber, or maybe the OMC DCPD inductor is responding nonlinearly causing some kind of soft saturation, or maybe it's just a whitening-dewhitening mismatch).

Because of this, Measurement 1 below is suspect, Measurement 2 is definitely OK, Measurement 3 is probably OK too.

Analysis will come later.

Throughout the measurement, RF sidebands (9, 45 and 118) were OFF, H1:OMC-DCPD_A_GAINSET and B were set to low (a factor of 10 smaller than nominal), and IMC-PWR_IN was 10W.

Measurement 1. Scan OMC PZT and measure the MM loss.

Lock OMC, align OMC reasonably well, unlock, scan the PZT slowly. The best scan is between 19:26:25 and 19:34:44 UTC (t=[-31m,-23m] in the 1st attachment).

"Align reasonably well" was a challenge as we were using the OMC QPD for OMC ASC, changing alignment meant changing QPD offset, and doing so frequently railed OMC suspension. While changing the offsets, maximum DCPD_SUM I could reach was 16.9, but I kept bumping OMCS so I gave up (sensor correction was off for the first half of this effort and that didn't help). In the end, usable data was obtained with default offset that gave us ~16.6 when locked, but we know that that was NOT the best alignment.

As you can see, the peaks in DCPD_SUM during the scan are all about ~14, much smaller than 16-something. (At t=-36m, the OMC was held at resonance and DCPD_SUM was ~16.6. After the scan at t=-20m, DCPD_SUM was ~16.45. So the alignment drift wasn't much of a problem.)

It turns out that we had to scan slower than this even though this was REALLY slow (~8 minutes for one cycle) and/or lower the laser power.

Measurement 2. OMC throughput.
Lock the OMC to 00 resonance (19:37:27-19:38:28 UTC, roughly t=[-20m, -19m] on the 1st attachment).

Measure DCPD_SUM, input power (via ASC-OMC_A and ASC-OMC_B SUM) and reflected power (via OMC-REFL_A).

With the same alignment into OMC, find the time where the OMC was off-resonance (DCPD transmission was minimal  19:25:58-19:26:20 UTC), and measure DCPD_SUM, input power and reflected power.

Calculate the throughput.

Measurement 3. OMC Finesse

I roughly kept the OMC at resonance by adjusting pzt voltage. DCPD_SUM was slowly drifting but it was about 16.0.

I started injecting into PSL frequency with an amplitude of ~+-600kHz (1.2MHzpp) via IMC-L_EXC. I slowed down the injection frequency until the peak value gets back to 16.0. (Second attachment.)

Best scan data is obtained 19:56:20-19:57:20 UTC.