Started observing at 23:08 UTC

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

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.

Attached are the averaged squeezing and anti-squeezing DARM spectra for each PSAM value we've measured so far.  Based on the course scan, we see that our initial PSAM values (strain voltages of 7.22/-0.71 for ZM4/ZM5) appear to be roughly optimal, giving roughly -5.2 dB of squeezing and 15.6 dB antisqueezing at 2 kHz.  So far we've noticed that any significant movement of the PSAM setting for ZM5 seems to de-optimize things and we are relatively insensitive to changes in ZM4 when ZM5 is held fixed at its initial value.    

Values from yesterday afternoon are also included.

On April 9th, we took one more PSAMS data. This PSAMS setting might be better than the nominal 170/95 (strain voltage 8.8/-0.66) as reported in 77074. We may come back to this setting later.

asqz 125/136 (strain voltage 7.5/0.5) (5 min)

PDT: 2024-04-09 15:36:49 PDT
UTC: 2024-04-09 22:36:49 UTC
GPS: 1396737427

sqz 125/136 (5 min)

PDT: 2024-04-09 15:43:59 PDT
UTC: 2024-04-09 22:43:59 UTC
GPS: 1396737857

Subtracted SQZ dB's for the various PSAMS settings last week: course trial #1: 76925, and course trial #2: 76949, and the previous optimzations in LHO:76507, which used SQZ ASC to hold alignments when moving PSAMS before ZM alignment scripts 76757.

I sorted the PSAMS tests by positive and negative ZM5 strain gauge voltages.

Some takeaways: hard to interpret what's happening. Could be interesting to try ZM5 strains around 0 - 0.5 V, and scan with e.g. ~0.1 V steps. I wonder if reviving the psams scanning scripts, and doing fine optimizations, would be productive at this point. I'm not sure if there's a tension between good squeezing at 1 kHz vs. 100 Hz. But some settings that give the most kHz squeezing (negative ZM5 strain) don't necessarily show the best 100 Hz squeezing (positive ZM5 strain), and vice-versa. It may just be that the optimal point is narrow, and we're taking big steps?

• For best SQZ at 1 kHz - we seem to more reliably see this with ZM5 strains between (-0.7 , 0.5) V across a large range of ZM4 settings, even when settings are varied on the same day/lock.
• For best SQZ at 200 Hz - a bit hard to say, but possibly ZM5 > 0 (positive) gives better 200 Hz SQZ.  
  • Several negative ZM5 traces suggest freq-dep losses below the DARM pole.
  • For positive ZM5 traces, very hard to tell. SQZ looks lossier for ZM5 > 2V.  

Attachment 1 - positive ZM5 strain - potentially more SQZ at 100 Hz, and less sqz at 1 kHz?

• Some of these traces have flatter SQZ, but this is hard to disentangle from just loss, since many positive ZM5 settings have both less SQZ and less ASQZ.
  • Like as an example, if SQZ-OMC mode-matching was very bad for those settings, squeezing would just look lossier across the whole band, which might cause it look flatter too.
  • But I think the blue (7.2, 0.3) trace is an interesting counter-example: we could infer that there's less generated squeezing (b/c anti-sqz is lower), but the decrease in anti-sqz is not due to loss b/c squeezing is the same.
  • Comparing the blue 4/4 to the pink 3/17 is also interesting - PSAMS settings are very similar, and shape of SQZ is very similar (blue / pink nearly parallel). But, anti-sqz (= NLG + loss) is less on 4/4 than on 3/17, while sqz (~ loss) is basically the same. This could suggest less generated squeezing on 4/4 than 3/17.
• Higher ZM5 settings far above 1V are not obviously good. In this range, both asqz+sqz look worse.

Attachment 2 - negative ZM5 strain - more kHz SQZ, but kinda looks lossier below the DARM pole at e.g. 100 Hz.

• Mostly, ZM5 strain is at -0.7V, and ZM4 is varying. 
• This looks consistent with the FD-SQZ data set on 20 March LHO:76540, which used PSAMS at ZM4/ZM5 = 150 / 90 (8.46V, -1.26 V).
  • Fitting a common sqz model to that 3/20 data suggested there were freq-dep losses below the DARM pole at those settings (plot). There's also evidence for the freq-dep losses at 100 Hz in this 4/4 data.

Linking LHO:75749 with the in-chamber beam profiles at various PSAMS settings, as we continue working to reconcile the models and measurements.

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.