TITLE: 03/20 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Wind
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 36mph Gusts, 22mph 3min avg
    Primary useism: 0.06 μm/s
    Secondary useism: 0.38 μm/s
QUICK SUMMARY:

• We've been down for the WIND for the majority of the day
  • The forecast doesn't look good, there might be a small lull around 8 to 11pm from windy.com

J. Kissel

Oli and I are beginning the process for designing damping loops for the A+ O5 BBSS. We're running through the same process that I've been running through for over a decade designing suspension damping loops, in which I build up a noise budget for the optic displacement in all DOFs using input noises for seismic noise, DAC noise, and OSEM sensor noise filtered through said damping loops, all propagated thru the matlab dynamical model of the suspension.
 
The first step along that journey is revisiting all the input noise sources, and making sure we have good model for those. 
OSEM noise and DAC noise models have recently been validated and updated when I revisited the HLTS damping loop design (see LHO:65687).
However, I haven't worked on damping loops for suspensions suspended from a BSC-ISI since 2013, see G1300537 for the QUAD, G1300561 for the BSFM, and G1300621 for the TMTS.
In those, I used the 2015 update to the 2005 requirement curve from T1500122 as the input motion.
Now, after a decade worth of commissioning and improvements, I figure it's time to show that work here and use it in modeling future SUS damping loops where the SUS is mounted from a BSC-ISI.

One of the biggest things we've learned over the decades is that the seismic noise input to the suspension at its "Suspension Point" motion for a given suspension can be the (quadrature) sum of many of the ISI's cartesian degrees of freedom, and depends on where and in what orientation it is on the optical table (see T1100617). As such, we installed front-end infrastructure to calculate the calibrate the lowest stage sensors -- the GS13 inertial sensors -- into both the Cartesian and Euler basis (see E1600028). In this aLOG, I do as I did for the HAM-ISI LHO:65639, I show the Cartesian contributions to each of the Beam Splitter's SUS point motion, by multiplying the Cartesian channels by the coefficients in the CART2EUL matrix for the beam splitter.

The time I used for this performance of the H1 ISI BS was 0.01 Hz binwidth (128 sec FFT), 10 average, 50% overlap data set starting at 2025-03-19 14:00 UTC.
    - This was a late night local set, with no wind and 0.1 [um_BLRMS] level microseism (between 0.1-0.3 Hz)
    - GND to ST1 Sensor correction is ON, including the DIFF and COMM inputs.
        - Here at H1, the corner station does NOT have beam rotation sensors to improve the GND T240 sensor correction signal. But, both end stations have a BRS.
        - The wind was low at this measurement time, but it's worth saying that each end-stations wind fences are in dis-repair at the moment, too be fixed soon.
    - ST1 Z drive to ST1 RZ T240 decoupling is ON with a "pele_rz" filter
    - Off diagonal ST1 dispalign matrices are in play, 
         X to RX & RY = -1e-4 & 1e-4, 
         Y to RX = -7e-4, 
         Z to RX & RY = 3.5e-3 & 2.5e-3 
    - ST1 Blend Filters:
        - X & Y = nol4cQuite_250
        - Z = 45mHz_cps
        - RX & RY = Quite_250_cps
        - RZ = nol4cQuite_250.
    - As far as I can tell, there's NO ST1 to ST2 sensor correction on the ST2 CPS, nor is there and ST1 to ST2 FF to the ST2 actuators.
    - ST2 Blend Filters:
        - X & Y = 250mhz
        - Z = 250mhz
        - RX & RY = tilt_800b
        - RZ = 250mhz

These will be used to make updates to 
    /ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/
        seisBSC.m or 
        seisBSC2.m
which are toy models of the BSC-ISI performance, used so you don't have to carry around some giant .mat file of performance and you can per-interpolate on to an arbitrary frequency vector, much like I did for seisHAM.m in CSWG:11236.

I've committed the .xmls and .pngs in the following SeiSVN directory:
/ligo/svncommon/SeiSVN/seismic/BSC-ISI/H1/BS/Data/Spectra/Isolated/ASD_20250319/

J. Kissel

I've been tasked with using the analog voltage input to the OMC DCPD transimpedance amplifiers (LHO:83466) to drive a sine wave around 10 kHz, in order to try to replicate a recent PI ring up which apparently caused broad-band low frequency noise LHO:83335.

There is a remote excitation channel that typically drives the this analog input excitation path is running at 16 kHz: the H1:OMC-TEST_DCPD_EXC channel's filter module lives in the h1lsc.mdl model in a top_names OMC block at the top level of the model, and the output of that filter bank is connected to the lsc0 IO chassis' DAC_0's 11th / 12th digital/analog channel. That DAC's AI channel goes through quite an adventure before arriving at the OMC whitening chassis input -- following D19000511,
    - AI chassis for lsc0 IO chassis DAC_0 lives in ISC-C1 U7, port OUT8-11 D9M spigot (page 2, component C15), connected to cable ISC_406
    - The long ISC_406 DB9 cable connects to a LEMO Patch Panel (D1201450) on the other end in ISC-R5 U12 (page 22, component C210).
    - Funky LEMO to D9M cable D2200106 ISC_444 connects from the patch panel to the whitening chassis,
    - ISC_444 D9F end of the cable to lands at the  J4 D9M port labeled "From AI/DAC / Test Inputs" of OMC DCPD whitening chassis in U24 of ISC-R5 rack.

... but this won't work: this channel is driven at 16 kHz sampling frequency. So, we can't drive anything technically above 8192 Hz, but realistically above ~5-6 kHz.
I digress.

I'm going with SR785 excitation via DB9 breakout.

Anyways -- I attach here an ASD of the OMC DCPDs sampled at 524 kHz during nominal low noise this morning (taking advantage of the live-only 524 kHz channels), low-passed at 1 Hz, without any digital AA filters; the channel H1:OMC-DCPD_524K_A1 filter banks channels from LHO:82686. The OMC DCPD z:p=1:10 Hz whitening is ON during nominal low noise.

The top panels show a zoomed in, and zoomed out version of the DCPDA ASD calibrated into photocurrent on the PDs (H1:OMC-DCPD_524K_A1_OUT channel, * 0.001 [A/mA], all the rest of the calibration is built in to the front-end filter bank; see OUT DTT Calibration).
The bottom panels show a zoomed in, and zoomed out version of the DCPD ASD calibrated into ADC input voltage, with what whitening that was ON divided out, and the 2x ~11 kHz poles of the TIA divided out. (H1:OMC-DCPD-524K_A1_IN channel, * 1/4 [four-channel copy sum to avg conversion] * 0.0001526 [V/ct for 40 Vpp range over an 18 bit ADC] * z:p = (10):(1) inverse whitening filter * z:p = (11k,10k):([]) inverse HF TIA response )

In the zoomed in version of the plots, you can clearly see the mess of acoustic modes at 10.4 kHz. 
One can also see relatively noise free region at 10.3 kHz that looks clean enough for me to target with my analog excitation.

I plot the de-whitened ADC voltage because the transfer function between the TEST DAC input and the TIA's output voltage is designed to the 1.0 in the GW band, from ~50 to 5 kHz, given that in that band, the transimpedance is 100e3 [V/A] and the series resistor that turns the voltage injection of the TEST input into current is 100e3 [V/A] (see ). So "nominally" un-whitened ADC counts should be a one-to-one map to DAC voltage input. At 10 kHz, however, the 2x ~11 kHz poles of the TIA, which drop the TEST input voltage by a factor of 5x at 10 kHz (see, e.g. plots from LHO:78372)

So, that's why in the lower panels of the above mentioned plot of OMC DCPD A's ADC voltage calibrated in the way mentioned above. This should be a one-to-one map to the equivalent DAC voltage to drive.

I looks like the non-rung-up 10.4 kHz PI modes today were of-order 1e-2 V = 10 mV, and the surrounding noise floor is around 1e-5 V = 10uV = 0.01 mV of equivalent DAC drive.

The lower limit of the SR785 SRC amplitude is 0.1 mVp = 0.2 mVpp (single ended).
Also, using the SR785 in a FFT measurement mode, where you can drive the source at a single frequency, there is no ramp. It's just ON and/or OFF.
(I should also say that a SR DS340 function generator also doesn't have a ramp on its output. I considered using that too.)

So -- hopefully, suddenly turning on a noisy 10.3 kHz line at 0.1 mVp into the IFO with a noise floor of 0.01 mV/rtHz at 10kHz won't cause problems, but ... I'm nervous.

TITLE: 03/20 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 47mph Gusts, 31mph 3min avg
    Primary useism: 0.09 μm/s
    Secondary useism: 0.41 μm/s
QUICK SUMMARY:

H1 had reached Nominal_LOW_NOISE [600] at 16:09 UTC
Commissioning had started.
A button pusher accidentally pressed the NLN_ETMY[710] button on the ISC_LOCK screen.
There was enough time to pause and Look at the ISC_LOCK graph, to look for a way back to NOMINAL_LOW_NOISE[600].
The Graph has a path out of NLN_ETMY[710] to NEW_DARM[711], then to RETURN_TO_ETMY[712], then to DARM_RECOVER[713]. 
But since DARM_RECOVER[713] didn't have a path back o NLN[600] I thought we would still be stuck.
So I held us in NLN_ETMY for a few more moments while I checked the alog and found Ryan Short's alog76320 .
I then quickly pulled up an Ndscope to find that Ryan and company had lost lock and not returned back to NLN[600].
Other alogs that mention NLN_ETMY all mention locklosses. so that was our last well documented path out of NLN_ETMY.

There was some confidence building amongst the wealth of knowledge within the Control Room that we should manuel from NLN_ETMY[710] to BACK_TO_ETMX[561].
Since that was the intuition and consensus of the room full of knowledgable people we tried it.
This led us to be stuck in BACK_TO_ETMX and a LOG that said:
2025-03-20_16:25:29.616860Z ISC_LOCK [BACK_TO_ETMX.run] USERMSG 0: EX ESD bias is off.
2025-03-20_16:25:29.617144Z ISC_LOCK [BACK_TO_ETMX.run] USERMSG 1: EX ESD must be off. DARM not transitioned. HELP ME!!!!
And we then lost lock due to high winds.

In the Future, If you find your self in NLN_ETMY, maybe try DARM_RECOVER instead.
Relocking as been abismal.

Thu Mar 20 10:06:49 2025 INFO: Fill completed in 6min 46secs

J. Kissel

Recall there is an analog TEST voltage input to the OMC DCPD in-vacuum transimpedance amplifier TIA (D2000592), whose in-air interface is through the OMC DCPD Whitening Chassis' (D2200215) J4 D9M port labeled "From AI/DAC / Test Inputs." This whitening chassis lives in U24 of ISC-R5 by HAM6.
 port. This port usually connected to a DAC via cable ISC_444, and the DAC channels can be used to test the response of the TIA / Whitening / AA / ADC chain entirely remotely.

However, these test inputs are not always engaged and functional; they are governed by analog relay switches. These relay switches themselves are governed by digital binary input, generated by the Beckhoff slow-controls system.

This is aLOG is about how to find and use these relay switches.

It's been a while since I used this screen (July 2023; LHO:71225), and it looked different than I remember and can't find an aLOG about the change, so I document it here.

See attached screenshot.
What's shown as "A_Relayset & B_Relayset" are the settings channels H1:OMC-DCPD_A_RELAYSET and H1:OMC-DCPD_B_RELAYSET.
Setting these to "On" or "1.0" turns ON the relay enabling the test input excitation.
Setting these to "Off" or "0.0" turns OFF the relay disabling the test input excitation.
In the screenshot, the A channel relayset is called out with a deep purple arrow.

What's shown as "A_Relaytoggle" & "B_Relaytoggle" are momentary channels H1:OMC-DCPD_A_RELAYTOGGLE and H1:OMC-DCPD_B_RELAYTOGGLE.
These are momentary channels, that if set to "On" or "1.0," it toggles the RELAYSET to the opposite setting it's currently in, and then self-restores to "Off" or "0.0." 
So, on the screen, hitting "On" changes the relay state, and hitting "Off" does nothing.
In the screenshot, the A channel relaytoggle is called out with a dark green arrow.

Note -- there is only one differential test input from the J4 D9M, "From AI/DAC" port of the whitening chassis. So if you turn on BOTH A and B test input relays, it drives BOTH A and B's test inputs simultaneously with signal identical to the input. If you want, or only need to, drive one DCPD's TIA path at time, then turn on only that corresponding relay.

Back by popular demand, the "TP CLEAR" button on the CDS overview which clears all open test points with the exception of these normally kept open when in Observe.

The CDS Overview now permits one testpoint to be kept open on h1calinj, h1calcs and h1iopomc0. As before, h1calinj's TP is expected to be an EXC. I've removed h1lsc's permitted two TPs. Attachment shows MEDM snippet for these models.

To make space to add the "TP CLEAR" button I've modified the CDS section to position the command buttons immediately following the related-display buttons (see attachment).

TITLE: 03/20 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Aligning
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 37mph Gusts, 25mph 3min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.44 μm/s
QUICK SUMMARY:
H1 was locked for 12.5 hours but lost lock due to High Winds at 13:39 UTC .
When I arrived H1 was still struggling to lock while the winds howled aross the the roof of the CS.
So far I have run an Initial_Alignment, and taken ISC_LOCK to IDLE, & Observatory mode to Wind.
When the tumbleweeds stop running across the road we will be ready to lock!

The hourly forcast is leaning less toward Compact Binary Collisions and more toward Tumbleweed Traffic Collisions, so watch out for those tumbleweeds.

TITLE: 03/20 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

IFO is in NLN and OBSERVING as of 01:00 UTC (4 hr lock)

Extremely calm shift with one lockloss (alog 83460). Re-acquisition was fully automatic.

We also rode out a 5.6 EQ from Alaska in which Guardian correctly went into EQ mode before the waves hit.

LOG:

None

Ibrahim A, Jeff K

Re-measurement of the BBSS Bounce and Roll modes following changes to the BBSS parameters. Measurements show that these still closely match the new model.

The differences from the original BBSS FDR are:

• d0=+3.0mm - height change to account for new spacer
• l1 = -3.0mm
• m2 = +0.3kg
• FDR, d1 = +3.5mm (which is equivalent to BP = -4mm) 

• Bounce: 19.55 Hz (New model prediction: 19.47 Hz)

  • BW: 0.01 (128s/avg)
  • Averages: 25
  • Excitation Waveform: Uniform Noise, 19-20 Hz

• Roll: 31.67 Hz (New model prediction: 31.94 Hz)

  • BW: 0.01 (128/avg)
  • Averages: 25
  • Excitation Waveform: Uniform Noise, 31-35 Hz
• Confirmation ASD (exponential avg) Excitation:
  • BW: 0.02 (64s)
  • Excitation Waveform: Sine
  • Averages (exp): 5

TITLE: 03/19 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 6mph Gusts, 3mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.42 μm/s
SHIFT SUMMARY:
H1 had been locked since before I got on shift.

Tyler went to start "Big Red" the forklift while it was parked at the water tank. He did not move it just starteded the motor and let it idle.
I asked him to please note the time the motor was started and when it was shut off just incase it's important to detchar folks.
17:43 UTC time Big Red's motor turned on.
17:49 UTC time turned off.

GRB-Short candidate E565397 19:19:39 UTC

Fell from Observing to Commissioning at 21:20 UTC because the SQZr unlocked , it is relocking it's self, no intervention from me.
back to Observing at 21:23UTC

@ 23:28:53 UTC! Lockloss from unkown cause. Sorry Ibrahim :(

LOG:                                                                                                                                            

Lockloss that killed our 15hr lock. No immediate causes.

TITLE: 03/19 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 8mph Gusts, 4mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.47 μm/s
QUICK SUMMARY:

IFO is in NLN and OBSERVING as of 08:09 UTC (~15 hr lock!).

Plan is to stay observing for as long as we can, though the microseism is on the rise.

Dropped from Observing to Commissioning at 17:22:53 UTC

TJ and I ran the A2L Script Multi Pretty script on All Quads.

Python3 /opt/rtcds/userapps/release/isc/h1/scripts/a2l/a2l_min_multi_pretty.py -a

['ETMX', 'ETMY', 'ITMX', 'ITMY'] ['P', 'Y'] a2l script done!
All complete.

*************************************************
RESULTS

| OPTIC|P/Y| Initial | Final |  Diff |
| ETMX | P |   3.23  |  3.31 |  0.08 |
| ETMX | Y |    4.9  |  4.96 |  0.06 |
| ETMY | P |   5.52  |  5.57 |  0.05 |
| ETMY | Y |   1.35  |  1.37 |  0.02 |
| ITMX | P |  -0.53  | -0.54 | -0.01 |
| ITMX | Y |   3.21  |  3.23 |  0.02 |
| ITMY | P |   0.06  |  0.04 | -0.02 |
| ITMY | Y |  -2.74  | -2.76 | -0.02 |

While also watching this ndscope to ensure that they crossed 0 using this ndscope templat: 
ndscope /opt/rtcds/userapps/release/asc/h1/templates/ndscope/A2L_script_ADS.yaml

Returned to Observing at 17:47:22 UTC

Wed Mar 19 10:11:18 2025 INFO: Fill completed in 11min 14secs

Today's fill has a winter look to it, OAT 5C 42F and overnight min -3C 26F

I was able to take 2 SQZ DARM Coherence Double Precision checks, once with 30 averages, and once with 70 averages.
Larger than 70 averages was giving me a "gap in data error".

To repeat this in the future:
Measurement settings I used to get the 70 averages to run.
Input settings i used to get the 70 Averages to run with out crashing.
The epoch time being too far in the past might be the reason diaggui was crashing unexpectedly, more testing is needed. -tagging CDS because  unexpected crashes of diaggui_test. 

Patrick, Jonathan, Sheila, TJ

During locking following maintenance Tue 18mar2025 we tried to move the BS camera from its old server (h1digivideo2) to its new server (h1digivideo5) for a second time. We had tried this the previous week but ran into locking issues with h1asc's use of this camera's centroid values and so had to move this, along with the ITM cameras back to h1digivideo2.

The plan was to just move one camera, h1cam26, to the new server and make the gain changes on h1asc's camera centering to compensate for the new video IOC, as was done when the ETM cameras were moved last year.

It became quickly apparent that the centroid values were more noisy with the new code in addition to being offset (plot shows CAM26_X, new code on left, old code on right).

We suspect the issue may be due image masking. The old code applied an image mask before calculating the centroids, the new code takes the image as a whole. The image snapshot shows that the edge of the optic is visible to the right, an issue the ETM images do not have.

We reverted CAM26 back to the old server at 17:00 PDT.