J. Kissel [for J. Oberling]

Jason also took the opportunity during his dust monitoring PSL incursion today to measure the distance between where the new fiber collimator would go on the PSL table to the place where it would exit at the point Fil calls the PSL enclosure.

He says 
SPI Fiber Collimator to PSL Enclosure = 9ft.

J. Kissel [for F. Clara, J. Oberling]

After talking with Fil I got some clarifications on how he defines/measures his numbers:
   - They *do* include any vertical traversing that the cable might need to go through,
   - Especially for rack-to-rack distances, always assumes that the cable will go to the bottom of the rack (typically 10 ft height from cable tray to rack bottom), 
   - He adds two feet (on either end) such that we can neatly strain relieve and dress the cable.

So -- the message -- Fil has already built in some contingency into the numbers above. 
(More to the point: we should NOT consider them "uncertain" and in doing so add an addition "couple of feet here" "couple of feet there" "just in case.")

Thanks Fil!

P.S. We also note that, at H1, the optical fibers exit the PSL at ground level on the +X wall of the enclosure between the enclosure and HAM1, underneath the light pipes. Then the immediately shoot up to the cable trays, then wrap around the enclosure, and then land in the ISC racks at PSL-R2. Hence the oddly long 50 ft. number for that journey.

Jason also reports that he rounded up to the nearest foot for his measurement of the 9ft run from where the future fiber collimator will go to the PSL enclosure "feed through."

Upon discussion with the SPI team, we want to minimize the number of "patch panel" "fiber feedthrough" connections in order to minimize loss and polarization distortion.

As such, we prefer to go directly from the "SPI pick-off in the PSL" fiber collimator directly to the Laser Prep Chassis in SUS-R2.
That being said purchase all of the above fiber lengths, such that we can re-create a "fiber feedthrough patch panel full" system as contingency plan.

So, for the baseline plan, we'll take the "original, now contingency plan" PSL-R2 to SUS-R2, 100 ft fiber run and use that to directly connect the "SPI pick-off in the PSL" fiber collimator directly to the Laser Prep Chassis in SUS-R2.

I spoke with Fil and confirmed that 100 ft is plenty enough to make that run (from SPI pick-off in PSL to SUS-R2).

I used my code to fit the scan and C02 peak for this scan. As we saw with the PSL beam the new OMC means we cannot resolve these two peaks.

But if I assume one is buried in the noise and do the fit anyway we get (0.027 - 0.0038)/(0.027 + 0.64 - 0.0038) = 3.5%  mode-mismatch for the squeezed beam matching to the OMC, with a fitted HWHM of 0.33 MHz.

NB: The factor 0.0038 mA is what I had to add to the scan data to shift the baseline to be above zero otherwise the fitting doesn't work well.

If I just use the measured height of C02 from the full scan (which is like assuming both C02 and C20 are overlapped) the mode-mismatch would be (0.029 - 0.0038)/(0.029 + 0.64 - 0.0038) = 3.8 %.

The OMC (001 is the current) parameters are given in this alog by Matt Todd, this gives a value for the half-width at half-maximum of 0.31MHz which matches our fitted one fairly closely.

The C02 peak graph (second image) has the OMC scan data in blue, fit in red, and initial guesses for the fit in purple.

Looking at this SQZ-OMC mode scan (data, mode scan), and running the same scripts as before (e.g. LHO:70866), this loss estimate based on OMC visibility using the squeezer beam doesn't really make sense. Hopefully PSL scans will make more sense. May be worth re-taking this squeezer measurement sometime.

Mode-matching and visibility make sense: Single-bounce SQZ-OMC mode mismatch ~ 4% based on TEM02/20 is consistent with Jennie's peak fitting, HOM content ~ 9-12%, and OMC locked/unlocked visibility = 1-locked/unlocked ~ 90%.

Loss estimate does not make sense: the inferred OMC transmission is ~72%, and if we ignore mode mismatch (ie assume 100% matching) this corresponds to an OMC transmission of 81%. But ~20% omc loss is ruled out by observed squeezing levels.

5.4 dB SQZ corresponds to a total loss of 20-25%, see params below including 12.3% expected sqz losses. This limits OMC losses < 10-15%, if assuming no mode-mismtch. With mode-mismatch, squeezing suggests OMC losses << 10%. This is not saying much, except this measurement is off.

• 5.4 dB of kHz squeezing, e.g. LHO:77073 
• 5 - 25 mrad phase noise (Nutsinee's < 5mrad recent estimate from in-loop noises LHO:77124 & O4a 20-25 mrad phase noise from DARM NLG sweep LHO:74318)
• NLG ~ 17.2 (many measurements @ 80 uW green trans)
• ~12.3% known SQZ losses, excluding OMC losses and mode mismatch. This is known sqz injection losses of 7.3% + known readout losses, excluding OMC losses, of 5.4%.
         ---> 1 - (1-.073)*(1-.054) = 12.3% sqz loss, excluding OMC losses and all mode-mismatch ( O4 SQZ wiki, gsheet )

So squeezing rules out the ~20% omc losses inferred from this sqz-omc visibility measurement. I'm not sure what is exactly is wrong, but in the mode scan, there was considerable TEM01/10 misalignment despite running OMC ASC + manual alignment. Unsure if alignment is the issue, or maybe something wasn't right with the squeezer beam, such that alignment couldn't improve (worth checking the beam round-ness on sqzt7?).

Script output below (code in git). Running this and Sheila's script in LHO:70866, I get the same output. So, the script seems OK, but something else is wrong with this measurement.

--------------- er16 sqz ------------------

processing measurement for er16 sqz

P_Refl_on_res*1e3 = 0.12831 mA 
P_Refl_off_res*1e3 = 1.00626 mA
Trans_A*1e3 = 0.62987 mA  (I assume OMC-DCPD_SUM_OUTPUT is calibrated into mA with the new OMC, I did not check this calibration.)
removed trans blocked of -0.00332 mA

Power on refl diode when cavity is off-resonance: 1.006 mW
Power on refl diode when cavity is on-resonance: 0.128 mW
Trans power when cavity is on-resonance: 0.734 mW 
Incident power on OMC breadboard (before QPD pickoff): 1.026 mW
Measured efficiency (DCPD current/responsivity if QE=1)/ incident power on OMC breadboard: 71.546 %

Using 4.0% mode-mismatch from Jennie peak fitting, visibiilty_00*100 = 90.885%

assumed QE: 100 %
power in transmission (for this QE) 0.734 mW
HOM content infered (like mode matching):  11.964 % 
Cavity transmission infered:  82.057 % 
predicted efficiency () (R_inputBS * mode_matching * cavity_transmission * QE): 71.546 %

omc efficency for 00 mode (incl R_inBS * cavity_transmission * QE, no mm): 81.270 %
round trip loss: 1606 (ppm)
Finesse: 372.613

h1omc0 dmesg:

[Tue Apr  9 04:34:05 2024] rts_cpu_isolator: LIGO code is done, calling regular shutdown code
[Tue Apr  9 04:34:05 2024] h1iopomc0: ERROR - A channel hop error has been detected, waiting for an exit signal.
[Tue Apr  9 04:34:05 2024] h1omcpi: ERROR - An ADC timeout error has been detected, waiting for an exit signal.
[Tue Apr  9 04:34:05 2024] h1omc: ERROR - An ADC timeout error has been detected, waiting for an exit signal.
 

Initially I thought this was an IO Chassis issue, so we power cycled h1omc0 rather than a restart all of its models (my confusion was because this front end only has one Adnaco, and is running the low-noise ADC). This brought h1omc0 back up and running.

We restarted the models on h1lsc0, which cleared the DACKILL.

Oli put the SUS and SEI for BSC1,2,3 and HAM3,4,5,6 into safe, I SWWD bypassed the SEI IOPs  and we restarted the models on h1susb123, h1sush34, h1sush56. All came back with no problems.

I cleared the SWWDs, did a DIAG_RESET and cleared the DAQ CRCs.

Handing over to Oli for IFO recovery.

CDS Overview after DIAG_RESET run on all front ends:

Time of OMC crash:

04:32:45 PDT

11:32:45 UTC

1396697583 GPS

FRS30939

SQZer lost lock and dropped us from observing at 04:22, will return once it relocks. Back into observing at 04:26UTC

This lockloss was due to the OPO PZT running out of range @40V, plot. There's already a checker in SQZ_MANGER to relock when IFOs unlocked and OPO PZT1 is below 50V but it was at 70V when the IFO locked.

Measured RF power at the

• Delay line input = 14.4 dBm
• Demod input = 11.2 dBm

The analog readback of the power detector was 5.89V at the front panel. This has been confirmed to be the same as the slow controls readback, which corresponds to 23.3dBm.

Seems like disconnecting and connecting the LO cable" fixed" the problem. Flaky cable and/or connector?

Un-paused at 16:01UTC, CO2s are back to 0W output.

Last done in 71400. 

Using Dan's /ligo/gitcommon/labutils/hws_absorption_fit/april2024/fit_absprtion_v2.py with lockloss time 1396105132, edited P_y  and P_x values to adjust the fit and old and new origin values (ours are correct, checked in 76385).

This is an interesting data set as you can see when the CO2's were turned back to 0W after an hour, ndscope attached.

The IFO had only been at full power for ~1hour,  this might explain the lower values than previously measured. Plot of fits attached. Fit of ITMY isn't very good. We could try using Cao's clean spherical power channels (single pass) or his 66155 fitting code. LLO also uses a different method LLO69930.

ITMX: 155mW absorbed = 430ppb (155mW / 361kW) 

ITMY: 120mW absorbed = 330ppb (120mW / 361kW)

Sorry team. There's a typo in the 65 kHz version of the DCPD channel in the PI model in both the above list, as well as in the diagram.

The channel list to accompany the diagram should be
    
    - H1:OMC-DCPD_A0_OUT (524 kHz, w/ digital anti-aliasing)                   [[NOT STORED IN THE FRAMES, ONLY LIVE AVAILABLE]]
    - H1:OMC-PI_DOWNCONV_SIG_OUT (524 kHz, w/o digital anti-aliasing           [[NOT STORED IN THE FRAMES, ONLY LIVE AVAILABLE]]
    - H1:OMC-PI_DCPD_64KHZ_AHF  (65 kHz, w/o digital anti-aliasing)     [[STORED IN FRAMES at 65 kHz as H1:OMC-PI_DCPD_64KHZ_AHF_DQ]]
    - H1:OMC-DCPD_A_IN1  (16 kHz, w/ digital anti-aliasing)                    [[STORED IN FRAMES at 16 kHz as H1:OMC-DCPD_A_OUT_DQ]]
 

Careful here: In O3, H1:OMC-DCPD_A_IN1 was NOT equivalent to H1:OMC-DCPD_A_OUT_DQ, since H1:OMC-DCPD_A_IN1 *used* to be the "raw" (down-sampled, and digital AA filtered) ADC 16 kHz channel, and then the DCPD_A bank applied all of the the calibration and frequency response compensation. Now, as of O4, with the 524 kHz system, that's done in the DCPD_A0 bank, and the DCPD_A bank is an "empty" gain of 1.0 "passthrough," so DCPD_A_IN1 is equal to DCPD_A_OUT. 

Further, a reminder that we've installed a "plug" that shorts the ADC inputs of channels 17 through 20 of this new 524 kHz system, so looking at the channels might also be interesting if we're looking for noise that might be present on the ADC channels alone (i.e. without any signals going into it).

See LHO:67465 for details, but in short, you want to look at the (live, not stored in the frames) 524 kHz channels, 
    - H1:IOP-OMC0_MADC0_EPICS_CH17
    - H1:IOP-OMC0_MADC0_EPICS_CH18
    - H1:IOP-OMC0_MADC0_EPICS_CH19
    - H1:IOP-OMC0_MADC0_EPICS_CH20
for a "shorted" version of the OMC DCPD ADC card channels.

This would be useful to, say, investigate how / why the DuoTone signal shows up in the DCPDs (see LHO:77579), and to compare and contrast against the L1 DCPDs which also see it (see LHO:70961), but they've not yet segregated their OMC ADC card, and (I think) have a different, older version of the Timing Interface card.