These channels were remnants of the pem changes from O3 to O4 (there is no more SQZT6 or ISCT6), and we overlooked changing them earlier. As such, people who use static channel lists might run into issues with the disappearance of the ISCT6 and SQZT6 channels.
Tagging DetChar.

See LHO:69633 for further information on this work (both steps that were completed and those which were not).

Unfortunatelt this made the LSC noise worse, which is the exact opposite direction we want to go. I am reverting the change.

The error was likely a sign flip. These filters should be tried one more time.

Overall, this implementation was a failure. The new SRCL filter did not work and caused a lockloss (there was a large high frequency portion of the filter we forgot to correct for). The MICH filter increases the noise in DARM. Both Gabriele and I are confused why the new feedforward has failed to improve the noise.

However, I think we need to try again. I am attaching a quick coherence I took from this lock, showing the high coherence from all three LSC loops. This is costing us significant range. This likely explains most of our range drop after we implemented the new DARM and SRCL offsets.

Evan Goetz, Debasmita Nandi, Taylor Starkman, Ansel Neunzert

We compared the weekly average spectrum starting May 10 with the week starting May 17. We saw a few noticeable changes in the weekly spectra, but careful follow-up shows that several of them are unassociated with the HWS changes. In particular, daily spectra show that changes in the 29.96 Hz and 1.66 Hz combs do not happen at the same time as the HWS changes.

There is a small 14.9009 Hz comb that seems to turn on during the week of the test and off afterward. (That is, the comb seems to be associated with the HWS being in the off state, which is fairly counterintuitive). Only a few peaks are visible, and it has not been noticed since.

Mostly noting these things here for future reference and searchability. We do not see large-scale spectral changes associated with this test.

The EtherCAT overview screen is now mostly green.

3 of the baffle PDs are saturated: H1:AOS-ETMX_BAFFLEPD_1, H1:AOS-ETMY_BAFFLEPD_1, and H1:AOS-ETMY_BAFFLEPD_4. This could be fixed by reducing their gain by 20dB to 0dB, when we are in high power.

The other channel with an issue is H1:PEM-Y_EBAY_RACK1_TEMPERATURE which reads unrealistic values and needs fixing.

When re-locking the RefCav after RF was powered back on, I had to do it manually at first.  It would catch, but then oscillate and would not stop and the autolocker would not engage the temperature loop.  Once I re-locked manually and manually engaged the temperature loop, the oscillations stopped.  The manual re-locking necessitated a change in H1:PSL-FSS_TEMP_MANUAL again, with corresponding SDF diff, so I acccepted it and attach a screenshot here.  Will keep an eye on the RefCav to see if this behavior with the autolocker continues.

Tagging ISC, PEM, and DetChar -- this is a follow-up action taken now that we've found that the detector is particularly sensitivity to scattered light from the ETMX cryo baffle; see LHO aLOGs 69598 from Evan, and 69603, Andy's ID that it may be this fan that Bubba has now turned off as indicated in the above aLOG. The game plan: since improving the isolation / damping of the cryo baffle would require an end-station vent which we're not willing to do, we're instead looking to reduce the input motion to the cryo baffle's isolation system. 

Last night after this change, the detector was left in observing mode for roughly 9 hours. This data that does not contain any visible 4 Hz glitching (see attached spectrogram). Additional checks of data during daytime hours would be helpful to confirm that the 4 Hz glitching is no longer an issue, but this is a promising sign. 

WP 11193

The primary motivation for today's work is to truly isolate the DC power supply for new, segregated h1omc0 IO chassis that houses only the new 524 kHz low-noise ADC which reads out the OMC DCPDs -- i.e *the* DARM gravitational wave sensors -- from known loud RF source generators, like Bekchoff chassis and the RF distribution system. That rack, SQZ-C1, had been powered by a cobbled together mish-mash of available DC power supplies in the DC power rack H1-VDC-C2, which powers lots of other things including RF sources, which -- we suppose -- are polluting and down-converting the OMC DCPD (the DARM) sensitivity. So, technically, you might say this work falls under the scope of ECR E2200441, and IIET Ticket 25756. This covers actions 1, 2, 3, and 4 below.

The secondary motivation is to continue the campaign of replacing ailing and failing power supplies.

I'll leave it to Marc to aLOG what actually happens today (cite the old addage "plans are out of date as soon as you make them"), but for historical reference, here's the list of changes he's planning on doing plus some context as I understand it, and a gathering place for all of the drawings and serial numbers involved.


    Actions: 
    * This swap is to keep the SQZ and ISC supplies grouped together. 
        1 - Add a +/-24V tap to the C4 junction box above H1-ISC-C4, connect tap to internal +/-24V source.                 # Impact: TEMPORARY BAD: ISC-C4 must get powered down, GOOD: segregating the h1omc0 
                                                                                                                            #         IO chassis power (in SQZ-C1) from RF distribution system, less lines in DARM

        2 - Move +/-24V sequencer cable from C3 junction box to new C4 junction box +/-24V.                                 # Impact: TEMPORARY BAD: ISC-C3 must get powered down, GOOD: segregating the h1omc0 
                                                                                                                            #         IO chassis power (in SQZ-C1) from RF distribution system, less lines in DARM

        3 - Move H1-SQZ-C1 cable in H1-VDC-C2 Power Rack from U26 to U34 RHS, set U34 RHS Kepco to +24V.                    # Impact: TEMPORARY BAD: SQZ-C1 must get powered down, h1omc0 IO chassis must get 
                                                                                                                            #         powered OFF, GOOD: h1omc0 IO chassis gets this dedicated power supply, less lines in DARM

        7 - Install new power run from H1-VDC-C2 to H1-SQZ-C1 for +24V supply for the segregated SQZ-IO [h1omc0] chassis.   # Impact: TEMPORARY BAD: SQZ-C1 must get powered down, h1omc0 IO chassis must get 
                                                                                                                            #         powered OFF, GOOD: h1omc0 IO chassis gets this dedicated power supply, less lines in DARM

    * balance load between the two Beckhoff +24V power rails 
        4 - Move H1-ISC-C3 cable in H1-VDC-C2 Power Rack from U34 to U26 RHS, set U26 RHS Kepco to +24V.                    # Impact: TEMPORARY BAD: ISC-C3 must get powered down, GOOD: as stated in Marc's work permit, 
                                                                                                                            #         balancing the DC power to Beckhoff chassis, and a cable rearrangment fall out of Action 3 above  
        5 - Move +24V H1-ISC-C3 Breakout Rail input cable to old H1-ISC-C3 +24V junction box above rack. 
        6 - Move ISC-Beckoff +24V cable from IO-ALS & IO-LSC power and to the new +24V power rail powered from H1-ISC-C3. 

    * repair failing power supply
        8 - Replace H1-ISC-C1&C2 -18V RHS with new supply.                                                                  # Impact: TEMPORARY BAD: ISC-C1 and ISC-C2 must get powered down, GOOD: noise source from failing power supply mitigated

Systems Affected: ISC-RF Generation ISC-C3 & ISC-C4 ISC-Signals Conditioning ISC-C1 & ISC-C2 ISC-Beckhoff in ISC-C3 SQZ-IO Chassis in SQZ-C1


SQZ-C1
    - Primary Functions: New home for Segregated OMC IO Chassis (and AA Chassis) and SQZ system's Beckhoff chassis
    - Wiring diagram: D1100683 for Bekchoff, New Segregated OMC IO Chassis Location Not indicated in D1900511
    - Graphical layout: D1600513 for Beckhoff, New Segregated OMC IO Chassis Location Not indicated in D1600513
    - Serial Number: S1800536

H1-VDC-C2
    - Primary Function: +/-18 and +/-24 V DC power supplies for many PSL, ISC and SQZ racks (and +/- 18 V for SUS field racks, SUS-R1, SUS-R2, SUS-R3, SUS-R4)
    - Designation of which power supply powers which rack D2300167, page 7
    - Serial Number: S1301896 

H1-ISC-C1
    - Primary functions: Audio Frequency ("Fast") Signal Conditioning for LSC and ASC IO chassis, and the IO chassis themselves
    - Wiring Diagram: D1900511, pages 1 and 2
    - Graphical layout: D1001427
    - Serial Number: S1301876

H1-ISC-C2 (Not involved in today's work)

H1-ISC-C3 
    - Primary functions: (Radio Frequency) RF distribution and CER IO Chassis Timing Fanout
    - Wiring diagram: D1900511, pages 6 and 7
    - Serial Number S1301878
    - Graphical layout: D1001427
    - Note: timing system is powered by different power supplies that the work planned today, so the work today should not impact CER timing system.  #crossfingers

H1-ISC-C4
    - Primary functions: RF generation and distribution system RF oscillators and DEMODs used by PSL, IMC, ALS, SQZ, LSC, ASC, etc.
    - Wiring diagram: D1900511, pages 8 and 9
    - Graphical layout: D1001427
    - Serial Number: S1301879

Additional Effects From This Morning's Power Supply Work For The ISC RF Racks:

1. This RF work affected the PSL's FSS & PMC, so Jason came in to disable their locking until this RF work is complete.
2. Since the Corner Station ISI CPS' use a timing signal from one of these RF racks, this caused all the ISI CPS' in the corner to trip.

See LHO:69652 for Marc's description of what was actually completed. In short, they did NOT do Actions 7 -- isolate the h1omc0 IO chassis on its own power supplies, nor did they do action 8 -- replaced the failing power supplies that support ISC-C1 and ISC-C2.

Naoki, Sheila, Vicky. It was great that Camilla did these meausurements last night!

OPO TRANS DC POWER = 39.6 uW. According to calibration on 2/3/23, which has been pretty trustworthy, this is about NLG = 3.92, so generated SQZ = 9.24dB.

• no sqz 1368254000 - 1368254627
• asqz 1368255661 - 1368255794 (~2min, +276.8 deg). About 6.3-7dB anti-sqz, call it about 6.6dB asqz.
• mid-sqz 1368256444 - 1368256532
• sqz 1368256735 - 1368258507 (+161deg). About ~2.6-2.9 dB sqz, call it -2.7dB sqz.

Based on the no-sqz data at this time, IFO losses are below 35%, and more like 20-30%. These sqz/asqz levels suggest either significant 50% squeezer losses (15-30% excess sqz losses from ifo losses), or that our NLG is mis-calibrated/mis-tuned due to wrong opo temperature at the time.

If we had only the known levels of squeezer injection losses (say common 20-30% losses with ifo + additional 7% sqz injection losses, total ~30% loss), I'd expect we'd have seen ~7.5-8 dB asqz, and over -3.7dB sqzed noise reduction, which was clearly not the case.

Assuming fixed/real NLG, adjusting losses to match observed sqz/asqz. With NLG = 3.92, this gives generated SQZ = 9.24dB. To only see Anti-SQZ = 6.5dB and sqz = -2.5dB, suggests the squeezer sees 45-50% total losses, so like 15-30% excess of ifo losses.

Given these SQZ/ASQZ levels, calculate NLG and losses. Best-case for losses, an NLG=3.3 and losses 42% would be sensible. This is still excess 10-20% sqz losses from ifo losses.

What was our NLG? Today Naoki measured NLG=3.75 after several DAQ restarts. This would need about 50% sqz total losses, 15-30% excess sqz loss from ifo losses.

Potentially the opo co-resonance temperature is mistuned for red/green co-resonance, given that I'm not sure we re-tuned the OPO temp optimally with this lower NLG and the recent LVEA temperature drifts. Maybe our AS42 offsets are also bad, we have not updated them in a while, and there have been many computer restarts last week. As well, we've had FC alignment/ASC changes; we've checked for clipping but maybe with recent computer restarts it is worth double-checking. We'll check everythign again after today's sqzt0 table work, and see if we can reconcile these numbers. We can try to more often quickly check asqz/mean-sqz to better understand our losses.

I checked the logic and removed the weighted the edge between SQZ_ASC and FREQ_INDEP_SQZ in SQZ_MANAGER so it should now go straight to FIS if it is requested. It can also go between FIS and FDS as icky and I previously added. 

Looking into why SQZ_FC was slow (3 minutes) getting from FIS to FDS, see attached:

• 1st t-cursor - TTFSS unlocked. SQZ_LO_LR went DOWN and SQZ_MANAGER went to SQZ_READY_IFO and closed BDiv. Correct behavior, but why did TTFSS unlock?
• 2nd t-cursor - FC green lost lock, SQZ_FC took itself DOWN
• 3rd crosshair cursor - SQZ_MANAGER SQZ_READY_IFO requested SQZ_FC to GR_LOCKED, is our aim to have it relock here?

As the FC goes from FIS --> FDS, the FC guardian is bringing FC2 from MISALIGNED --> IR_LOCKED. But in the process of physically moving FC2 back, it is free-swinging, and I wonder if maybe the CLF glitches through FC resonance in this time. The CLF going through FC resonance kicks the LO loop, which kicks TTFSS, and in turns brings down the LO loop, causing SQZ_MANAGER to go back to SQZ_READY_IFO, since it looks like the LO loop failed. When we're locked next, we can check if the LO loop can stay locked while the CLF glitches through, and if it can, maybe the guardian brings down the LO loop pre-emptively even if it doesn't have to.

Maybe we don't care to switch faster between FIS --> FDS. But if we do, I wonder if we could just tune the FC out of band, as far as the RLF-CLF can go. Or, we can bring FC-IR back with bdiv closed, or open with the LO loop unlocked. If we need to do this for upcoming sqz scans, I think we can smoothen out this transition.

To comment about the losses quoted above -- I think the losses were weirdly high b/s squeezer was in a not optimal way, related to our SDF mess after computer restarts, maybe our low NLG and higher CLF powers we happened to be using for a week or so, and other semi-random technical problems that have popped up over the last 1-2 weeks. I think our previous measurements of 3.5-4dB SQZ exclude losses of order 50%, when the squeezer is operating nominally and things are "normal". But we will check asqz/sqz more regularly now, to help track losses.

Accepted the changes for IY07 on SDF.OBSERVE, screenshot is attached below.

I can confirm that the new IY05/06 settings work well for multiple locks. They can be guardianized!

I have confirmed the above settings in the lscparam.

Attaching a plot from last night (6 hours of damping went fine).

For the noise impact we eventually found from this change in fans -- specifically in fan 1 -- see LHO:69603.