After the DACs were upgraded at EndY alog88274, I've updated SATMON.adl for ETMY (M0, L1, L2, L3), and TMSY (M0). I had to add a new item to the legend on the bottom right for the 28bit levels. 

Closes FAMIS#27537, last checked 88075
This is being compared to two weeks ago (FAMIS#27534) since it didn't run correctly last week.

Observations
- All HAMs except HAM7, and all CS BSCs ST1 - V1/V2/V3 all look a bit extra noisy between 6.5-9 Hz, but it's not the worst and I assume is probably due to local ground motion. 

- Nothing else looks weird

J. Kissel, E. Capote, J. Betzwieser

Today, I turned OFF the 1153.2 Hz PCALY Calibration Line by changing the frequency and amplitude to 0.0, and turning off the corresponding element in the OSC SUM matrix. 
    $ caput H1:CAL-PCALY_PCALOSC9_OSC_FREQ 0.0
    $ caput H1:CAL-PCALY_PCALOSC9_OSC_SINGAIN 0.0
    $ caput H1:CAL-PCALY_OSC_SUM_MATRIX_1_9 0.0

I've saved those settings in the OBSERVE / safe.snap SDF files to make that stick (they're the same file, soft-linked together).

Context
This line has been on consistently throughout O4, at the same frequency with no change in amplitude -- but never used for any science; t'was just eating up PCAL range. And now the REST of the story... In O3, the PCAL team began prototyping a constant comparison between PCALX and PCALY in order to determine \chi_{XY} . On Sep 11 2019, we turned on a line at 1153.1 Hz
at both end-stations with opposite sign forming a "canceling line" (LHO:51915). Realizing that a truly canceled line has no SNR above the DARM noise to make any statistically significant statement, they moved to 395.1 Hz for a minute (LHO:53259). Then, they finally tried separating them near the end of O3 at 1153.1 and 1153.2 Hz lines on PCALX and PCALY respectively (LHO:54876). Finding they still needed more SNR, they moved the comparison briefly down to 530.2 and 530.1 Hz (LHO:54868); this became the final measurement for P2000113), and then returned them to former frequencies of LHO:54868 on 2023-03-03 (LHO:55386)... and then we just never turned off the PCALY portion #globalpandemicwhoops. The corresponding PCALX portion, at 1153.1 Hz, was unceremoniously turned off without aLOG on a Thursday afternoon between O3 and O4, at 2022-12-08 22:29 UTC (14:29 PDT).

The RefCav reflected spot looked off this morning and the trends Ryan posted yesterday showed a large drop in RefCav TPD, so I tweaked the beam alignment into the RefCav from the Control Room; this was done with the ISS ON and the IMC unlocked.  When I started the TPD was ~0.473 V, and when I finished the TPD is ~0.518 V.  This isn't as high as we have been (~0.55 V), so this is an indication of another misalignment on the PSL table (most likely the double-pass AOM, which is our usual culprit for on-table alignment work).  We're not too far down right now and we are not consistently observing, so we will continue to monitor as usual and will do an on-table alignment should the TPD continue to drop.

Closes FAMIS#37211, last checked 87059
 
HPI-PUMP_L0_CONTROL_VOUT has been trending up for the past ~2 weeks.
All other HEPI pump trends looking as expected.

J. Kissel
ECRs: E2400409 and E2500296
IIET: 35739 and 35706, respectively
WP: 12901
DWG: D1002741

This morning, I updated the front-end user models for the X end station -- h1susetmx, h1susetmxpi, and h1sustmsx -- leveraging all the work and gotchas from yesterday's 32CH DAC upgrade of the Y-end station front end models (Primary models LHO:88280, Inconsequentially Updating Libraries LHO:88283, and Adding DAC compensation filters to the ETM PI library part LHO:88285). The good thing about having the end-stations use identical wiring diagrams means that I can literally copy and paste the digital representations of the DAC connections and cards. I've confirmed that the library part change to the ETM PI library correctly updated in the h1susetmxpi model without effort. The only "difference" was that the top level of the ETMX QUAD model, h1susetmx, had all of the messy prototyping pick-off infrastructure for the early 32CH DAC testing which can now all be ripped out and made to look clean and simple like ETMY's. 

I attach before vs. after screenshots for posterity. 

The revisions of the models that have been successfully compiled:
    /opt/rtcds/userapps/release/sus/h1/models/
        h1susetmx.mdl         r28431 --> r34046        BEFORE vs AFTER
            sus/common/models/ESD_LINEARIZATION_WITH_CHARGE_MASTER.mdl : r16336 --> r30316
        h1susetmxpi.mdl       r27215 --> r34048        BEFORE vs AFTER
            sus/common/models/PI_MASTER_V2.mdl : r26600 --> r34033
        h1sustmsx.mdl         r27182 --> r34050        BEFORE vs AFTER

And as before, I also attach a screenshot of the usage of DAC0 and DAC1 across front-end models. Today I decided to be a little more color-coded with my notes on channel usage; red for consumed/reserved in other models, orange for actually physically unused.

It was time to update the leap seconds file on some infrastructure systems, our famis task came due.

Debian 11 hasn't updated the tzdata package yet, and it expires end of this month.

I updated the leapseconds database on

h1daqdc0
h1daqfw0
h1daqnds0
h1daqtw0
h1daqgds0
h1daqdc1
h1daqfw1
h1daqnds1
h1daqtw1
h1daqgds1
h1fs0
h1fs1
h1hwinj1
h1hwsmsr
h1hwsex
h1hwsey
h1fescript0
h1guardian
h1vmboot5-5 (and its diskless root)
cdsfs0
cdsfs1
cdsfs2
cdsfs3
cdsfs4
cdsfs5
h1digivideo2

Link to the last time we did this: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=85270

TITLE: 12/02 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 2mph Gusts, 1mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.30 μm/s 
QUICK SUMMARY:

H1's been locked 13.5+hrs with a range hovering around132Mpc and no squeezing.  There was a minor optics dust alarm at around 534amPDT (cleared in 10min).

[RyanS, Oli, Jenne, Jeff]

Locking went well, and we're currently at NomLowNoise (no squeezing though).  We're good to go for swapping the Xend DACs tomorrow.  

SRC1 during DRMI ASC seems to pull things away at the last little bit rather than converging, so we've been turning it off by hand.  If it's still being problematic when we next try to lock (tomorrow? or Wed?), then we should set it to False in the DRMI guardian. 

We also turned SRC1 off in full ASC during our first lock attempt, since it seemed to be wandering off.  But, we lost lock in MOVE_SPOTS, probably because we weren't by-hand making the SRM follow along (since the beam diverters were closed so we didn't really have anything to track with).  Second lock I left SRC1 on in full ASC, and things went fine and we got all the way to NLN.

The squeezer guardian is stuck in LOCK_OPO.  I tried once setting the SQZ_MANAGER to DOWN and again to FREQ_DEP_SQZ, but it's still not happy.  Since this is not what we were trying to test today (we were just seeing if the Yend DAC swaps worked), I'm just leaving the SQZ_MANAGER in DOWN.

We did, at Jeff's suggestion, have the VIOLIN_DAMPING guardian paused, since we didn't want to do bad things to violin modes if there was a big phase change with the new DAC.  However Daniel estimates that we should see about a 10 degree phase shift at 1kHz, and a much smaller shift at 500 Hz, so I've just unpaused that guardian and the modes seem to be damping fine. 

I am leaving the IFO locked, but requested ISC_LOCK to DOWN, so that if it does lose lock, it won't try to re-lock.  This, and the lack of squeezing, means that I am not setting the Observing bit.

[Jenne, Oli]

I'm intermittently, while we're locking, seeing some fuzziness on the ETMY oplev (first 2 attachments, with 'fuzzy'). Oli did a brief check, and while they find a different behavior that is present 4 days ago and today (3rd and 4th attachments, with 'drop'), at least a quick glance isn't finding the fuzziness that I'm seeing. We haven't looked at enough past data to say whether this is new, but it doesn't seem to be hindering our ability to lock, so I think we're fine to go forward with ETMX tomorrow.

J. Freed,

I took Phase noise measurements of the 2 channel Keysight 33600A waveform generator for its use in building SPI Pathfinder in the optics lab before install. Going only off of the phase noise graphs, it is sufficient as it shows comparable results to the SRS which had a phase noise considered to be good enough for SPI pathfinder.

Key.png Shows the phase noise results. C1, C2 are the phase noise results for Channel 1 and Channel 2 on the Keysight, respectively. (Set up shown below). Shown for comparison the SRS SG392, which was suggested as a possible frequency source for SPI. The last measurement shown is the direct measurement of phase noise between the 2 channels of the Keysight. This measurement reflects the intended use case of the Keysight for SPI. As we need 2 frequencies at slightly different frequencies locked to each other and SPI will be measuring the output phase difference. Note the 60Hz peak; most likely caused by unclean AC power. This is why we are not using an AC powered device in the final installation. 

Screenshot2025-12-01at50150 PM.png Shows the setup for C1, and C2. measurements. The SRS value was found with the same set up, just replacing the Keysight 33600A with a SRS. The C1-C2 is a direct measurement by plugging both channels into the BluePhase 1000. There is no 10MHz Ext back attachment in this measurment in order to best represent Keysight's theoretical performance in the optics lab.

TITLE: 12/02 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY: Busy day upgrading DAC cards at EY. After suspensions were recovered, we wanted to relock the IFO to ensure the new DACs haven't introduced a problem, so I started an initial alignment. Unsurprisingly, ETMY and TMSY needed quite a bit of adjustment, but otherwise alignment went smoothly. Locking the IFO presented a couple of issues; after DRMI locked, I needed to turn of the SRC1_P loop as it appeared to be pulling alignment away. I turned this off again during ENGAGE_ASC_FOR_FULL_IFO as it appeared to be misbehaving for the second time. Eventually H1 lost lock during MOVE_SPOTS, but we're unsure as of yet what the cause was. H1 is attempting to lock again under the supervision of a few folks still here in the control room.
LOG:

Richard, Jonathan, Fil, Marc, Daniel, EJ, Jeff, Oli, Ryan S, Dave:

h1susey was upgraded from Gen Std DACs (3x18bit, 2x20bit) to 2 LIGO-DACs.

Fil upgraded the three AI chassis to use the new SCSI interface board.

We removed the old Gen Std DACs and installed the two new LIGO-DACs.

The first LIGO-DAC drives the first standard AI, which in turn daisy-chain drives the second standard AI.

The second LIGO-DAC drives the special PI AI chassis.

After the hardware was changed the new h1iopsusey, h1susetmy, h1sustmsy and h1susetmypi models were rev-lock built and installed. A common model change for h1susetmy was accepted for its build.

EJ did a custom build for h1iopsusey due to rev-update issues found for watchdog source files. The user models were built with the production RCG-5.5.2

Following the model starts, the DAQ was restarted for new INI files due to removed DACs in h1iopsusey and h1susetmy.

I made plots of anti-symmetric power P_AS vs. power at reflected port of OMC P_OMC_REFL during the DARM offset step measurement on September 4th, (see LHO alog #86785 and 87629).

I had to use the Beckhoff reported power for this (H1:OMC-REFL_A_DC_POWER) as the front-end channel is calibrated wrongly (see LHO alog #87648).

I also plotted the P_OMC_REFL vs.  P_DCPD, ie. reflected vs. transmitted power for the OMC.

The plots for our two measurements taken at different times during IFO thermalisation are below, both were taken when OM2 was hot.