Julia, Georgia

We turned on violin damping filters during lock using the 2W Gaurdian settings.

Some problematic modes:

• ITMX mode 3; wasn't responding to damping
• ITMY modes 5 & 6
• ETMY mode 1; damping rung up the mode

For ETMY mode 1, we noticed that despite using the 2W damping setting, the gain for this filter was 0.1 (rather than 0, which is the value set for the gain in the 2W setting in the VIOLIN_DAMPING.py script). Since we were ringing up the mode with -0.1, we tried setting the gain to 0.05. This successfully damped.

We looked through the VIOLIN_DAMPING.py script and found that the 2W settings were not actually being executed for any of the modes. Georgia found a possible typo in the script where an iteration is ran through "modes.key", but the list is titled "mode" (not "modes"). Georgia then edited this line of code, changing "modes.key" to "mode.key" to fix the issue. We'll confirm this the next time we attempt violin damping when lock is aquired.

Jonathan, Erik, Dave:

At 12:28 Fri 30may2025 PDT the GC/CDS switch which provides GC networking to the MSR stopped working. Visually the switch looked functional, but it was not providing network services.

Main impact on the control room was:

 . loss of GC/CDS NAT router, no offsite access; DARM FOM stopped (unable to get references), loss of teamspeak

 . loss of all VOIP phones (they were still getting POE power, but reporting no network service).

On Jonathan's suggestion we power cycled the MSR switch. After a very long startup boot (~8 minutes) all services were recovered.

Down time was 12:28 - 12:58 PDT

DARM FOM was restarted.

This switch is called sw-osb165-msr-0. It is in rack MSR-02 U40. It is a Ruckus ICX 7850-482P (48 port, POE, 2 power supplies).

Attached photos show front and rear of the switch. To power cycle, both rear power cords need to be pulled out, orange=UPS black=FAC (note they have locking brackets which need to be disengaged). Power cords are circled in the photo.

Sheila has been driving us through ENGAGE_ASC_FOR_FULL_IFO, TMS_SERVO, and ENGAGE_SOFT_LOOPS.

She closed all of the WFS-based ASC loops by hand, with CHARD at reduced gain.  We are sitting in at an alignment which is not the best buildups we've seen so far, but is stable.
The CHARD P sensing matrix is now REFL A 45 I = 1, and REFL B 45 I = 0.5.

Green references have been reset to our current alignment to hopefully make ENGAGE_ASC_FOR_FULL_IFO work automatically next time we acquire, without yanking the IFO out of lock.
Screenshot of the references posted.

Now engaging ADS loops.  This cleaned up the buildups for us a bit.
Now resetting the green references again.

Now turned on the transmon servos, which made a big difference in the green references.
So we are resetting the green references again again.

Now turned on all SOFT loops, reduced gain for PRM Pitch (ADS PIT 3).
Now resetting green references again again again.

Fri May 30 10:14:26 2025 INFO: Fill completed in 14min 22secs

M. Todd, C. Cahillane, S. Dwyer

I ran another estimate of the PRG, following Craig's method in alog  58327, and estimate it to be around 54.2 W/W.

I compared the TRX power to Input Power ratio during the FIND_IR state versus the PREP_ASC_FOR_FULL_IFO state, with the PRM transmission as a normalization factor.

                       TRX_POWER_FULL_IFO  /  INPUT_POWER_FULL_IFO
PRG   =    -------------------------------------------------------------------------------------
                     TRX_POWER_FIND_IR   /  (Tp  * INPUT_POWER_FIND_IR)

I've attached the quick script I've used for the interesed reader.

This is for FAMIS #26419.
Laser Status:
    NPRO output power is 1.863W
    AMP1 output power is 70.07W
    AMP2 output power is 140.4W
    NPRO watchdog is GREEN
    AMP1 watchdog is GREEN
    AMP2 watchdog is GREEN
    PDWD watchdog is GREEN

PMC:
    It has been locked 11 days, 1 hr 18 minutes
    Reflected power = 23.1W
    Transmitted power = 105.5W
    PowerSum = 128.6W

FSS:
    It has been locked for 0 days 0 hr and 5 min
    TPD[V] = 0.8038V

ISS:
    The diffracted power is around 4.0%
    Last saturation event was 0 days 0 hours and 55 minutes ago

Possible Issues:
    PMC reflected power is high

TITLE: 05/30 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 8mph Gusts, 4mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.09 μm/s
QUICK SUMMARY:

ISC lock is in the GREEN_ARMS_MANUAL state.   H1 is listed as PLANNED ENGINEERING.

Camilla, Georgia, Daniel, Vicky, Kevin

We looked at the squeezing on the homodyne as in 83039 and 82202.

We ran into an issue with the mounting of the homodyne PDA in the box. The power on PDA would intermittently drop to almost zero with us just standing there. After Vicky pressed hard on the PD, we could recover the same power after slightly adjusting the alignment on to the PDs again. We ultimately achieved 98% visibility after optimizing the subtraction.

The SQZ angle was recabled to use RF3 in transmission of the OMC rather than RF6 on reflection of the OPO in 83407. Today we split the phase to go to both the OMC and homodyne so that we can use either the interferometer or the homodyne without having to switch the cables as shown in the attached picture.

We then measured between 6.4 to 7 dB of SQZ, 14.6 dB of anti-SQZ, and 12.1 dB of mean squeezing. This is consistent with the measurement of 83% efficiency in 83039: based of off the anti-squeezing that would lead to about an NLG of 11.5 and 6.7 dB of squeezing. We measured an NLG of 9.35 but did see pump depletion so it's plausible that the NLG could be closer to 11.5.

TITLE: 05/30 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY: See alog84660 for a summary of the commissioning done this evening. Since then, I have been unsuccessful in relocking H1 up to PREP_ASC to do more commissioning of the ASC loops. Sometimes I can make it to that state for up to a few minutes, but eventually there's a lockloss from somewhere I can't explain, possibly the wind or something else. The lockloss tool shows IMC tags for several of the locklosses today, but I haven't been able to find a cause for why the IMC would be dropping out at these times (they certainly don't look to me like the NPRO glitches from last fall that I believe motivated the creation of the IMC tag). I'm leaving H1 in 'DOWN' for the night and commissioning can pick back up in the morning.

S. Dwyer, J. Driggers, G. Mansell, R. Short, others

The efforts to close more of the ASC loops in ENGAGE_ASC_FOR_FULL_IFO continued this evening. Sheila was able to find some new values for ASC input matrices by stepping different DOFs, and they have been added to ISC_LOCK. With these, we were able to close every ASC loop in the main method of ENGAGE_ASC except for CHARD_Y and ADS (so, INP1_P/Y, PRC2_P/Y, SRC1_P/Y, SRC2_P/Y, and CHARD_P). Jenne relocked ALS-X as it had unlocked with Sheila's CHARD steps, and we started the ALS QPD scripts to keep green arms locked from there. Since CHARD_Y was continuing to confuse us, we decided to move on for the time being and converge ADS error signals with the hope that bringing more alignment together that CHARD_Y would be easier. Jenne tried to move PRM around to bring ADS3 closer to zero, but this caused a lockloss when moving too far. I paused in CHECK_SDF to set the ITM camera references to match the new ALS QPD offsets and accepted them in SDF (see attachment #1 for ALS-X and #2 for ALS-Y).

Before the next lock attempt, I ran an initial alignment with the new green references, doing our usual thing of only doing PRC alignment up to the PRX steps and aligning PRM by hand. Georgia also edited the ENGAGE_ASC state in the following ways with the hope of running the state now that we had several loops closed:

• [lines 3221 - 3239] in PREP_ASC_FOR_FULL_IFO CHARD P and Y intrix values (copied over from time machine)
• [lines 3489 - 3490] in ENGAGE_ASC_FOR_FULL_IFO CHARD Y input on and gain ramp
• [lines 3510 - 3511] in ENGAGE_ASC_FOR_FULL_IFO ADS DOF3 (PRM) gain turn on

Once relocked, we attempted ENGAGE_ASC_FOR_FULL_IFO, and the loops closed successfully! ISC_LOCK was then waiting for ADS to converge (which it wouldn't as ADS wasn't engaged), so Jenne tricked ISC_LOCK by having it think the DAS error signals were zero. This allowed Guardian to move into the run method of ENGAGE_ASC, which has a gain increase of PRC2 gain. This gain increase caused PRC2 to ring up and cause a lockloss.

On another attempt, we made it to PREP_ASC and tried running the loops closing steps in the Guardian shell, but we missed that PRC2_P was on its soft limiter, so it was too far off and caused a lockloss.

At this point, I've been struggling to relock up to PREP_ASC with several random locklosses along the way, even though I've been touching up DRMI alignment on almost every acquisition. Wind speeds have been increasing and just surpassed 30mph, so that may be having some impact.

During the opening of GV7 and GV5 last Wednesday I noticed that the EDC had some brief drop-outs of about 1000 channels. This Wednesday something similar was seen, and on investigation I found that HAM1 IP work was happening at this time.

This piqued my interest and on further investigation I found:

This has happened 9 times so far, the first on Monday 28apr2025.

The EDC disconnects from 1118 channels each time, the only DAQ EDC INI file with this number of chans is H0EPICS_VACLY.ini Trending channels from LY INI show flatlines around these times confirming this is the IOC in question.

The disconnection is brief, most being 8 Seconds in duration, some 9 Seconds, one 16 Seconds. The EDC disconnection number goes from 0 to 1118 in one step at the start, and usually drops back to 0 in one step at the end.

Patrick has found logs on h0vacly saying its CDS network port detected disconnections around these times.

We have no clear mechanism between opening gatevalves, working on chambers, pumping dewars and the h0vacly's network connectivity (none of these activities are anywhere physically close to the vacuum rack). Or as to why h0vacly and not h0vaclx.

Full details in FRS34265

TITLE: 05/29 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 13mph Gusts, 7mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY: Work continues to close ASC loops. We've been able to close about seven of them so far with new input matric values, and we'll continue this evening.

Work at the EX windfence has been completed. While laying out the last panel (furthest North) it was discovered that the new panel had been stitched incorrectly. An old panel that was in good shape was reused.

Ibrahim, Rahul

Attached below are the B&K (Bruel & Kjaer) measurement results of A+ HRTS (suspended config.) mounted on BBSS structure - see picture over here. We used a tri-axis accelerometer mounted on the BBSS frame as shown in this zoomed-in picture - X axis is along the longitudinal side of the BBSS, Y axis is the vertical and Z is transverse.

At first we measured BBSS alone (without mounting the HRTS) - see results posted here. Using a hammer (force transducer attached to a front end - recording the hammer and accelerometer data on the B&K software) we hit BBSS structure in X, Y and Z direction (of the accelerometer). The hit was hard enough to not cause a soft hit, while taking care its not saturating the sensors. We see a small spike at around 68Hz on X axis hit, which is similar to what Jim saw in his measurements few months ago - LHO alog 79930. However, at that time BBSS was without its side braces for providing structural rigidity.

The second plot represents BBSS with HRTS mounted on it. Here as well we see some peaks below and around 70Hz.

Both the suspensions were unlocked and suspended during this measurement.

I am processing and analyzing some additional data (taken for sanity check) by moving the accelerometer to a different location on the BBSS, and will be posting those numbers soon.

S. Dwyer, R. Short

While in PREP_ASC_FOR_FULL_IFO this afternoon, Sheila and I re-phased REFL9 similar to Georgia's attempt in alog84646, but we think we had a better result this time, maybe because alignment is a bit better now.

SDFs of gains and new phasing screenshots are attached. Phasing template has been saved with updated references as /opt/rtcds/userapps/release/asc/h1/templates/phasing/phase_REFL9_mrtodd.xml

TITLE: 05/29 Day Shift: 1430-2045 UTC (0730-1345 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: The morning was spent trying to get back to PREP_ASC_FOR_FULL_IFO as it was found this morning. Locking DRMI was proving to be tricky even though camera flashes looked good and the POP 18&90 flashes also looked good. I would wait 5-10min, make minor adjustments to BS, PRM, or PR2 and try to increase the frequency or magnitude of the flashes. Sometimes this worked, sometimes it wasn't needed, and sometimes we gave up and ran an initial alignment skipping green. We've ran 3 initial alignments so far. We are now sitting at PREP_ASC_FOR_FULL_IFO and control room users are rephasing POP, tuning loops, and checking on other loops. I've had to touch up POP90 &18 at this state with SRM, as long as PRC2 is on to follow. I've also been turning on the RF violin mode damping whenever we sit in this state to help reduce teh high violins that we currently have.
LOG:

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.

J. Freed

The reason we picked the ZFL-500HLN amp for SPI's Double Mixer was that it was an amp that met requirements from minicircuts

-frequency range contains 80MHz (our operating frequency)

-Operates at voltage supplied by Low Noise Power(15V, 17V, 24V etc.)

-Has a P1dB well above our output power of 10dBm (to remove non-linearity)

-No heat sinks (to fit in a 1U chassis.) (This requirement actually doesnt matter, the ones discussed here are still the best even compaired to amps with heat sinks)

-sma connections

-Low noise

-Low gain (we only need ~8dB of amplification)

The ZFL-500HLN was chosen because it fit all those requirements, with the cavieat of having to attuniate before amplification (adding noise). Though if I am correct and the Low noise power board 5V Vcc port is capable of supporting a 63mA load, another option would be the ZX60-P105LN+ instead due to the lower gain and lower noise. This would remove the need for an attinuator before amplification but its low input return loss means alot of power is reflected back towards our mixers (Also causeing noise). So it becomes a pick your poison of adding noise by attinuating before amplification vs by reflections back into our mixers. In practice, I believe both would operate about the same. Will add a comment if something changes

Double-MixerAmpComparison.png shows a quick comparison of the 2 amps