J. Kissel, F. Clara
ECR E1700123

More yak shaving, but at the end of today's kLog series you'll understand how to execute Daniel's implicit plan in D0902810-v10 for moving cables around to make room for an incoming tip-tilt, aka HTTS, to eventually be named "PM1," i.e. Pop wfs steering Mirror 1.

In this kLog: There're 2x cables DB9 available for the cable run from SUS-R1 to SUS-C4 to cover the needs of that run for PM1, we may not need to buy new cables.

In 2022, I inventoried all optical lever whitening chasses in LHO:63844. In that aLOG I confirmed that the never-existed / now-officially decommissioned HAM2 and HAM3 ISI optical levers were disconnected from their respective optical lever piers.

Today, while poking around the racks, I identified that 
    - The last version of a wiring diagram that had any record of these HAM ISI optical levers was 
        :: HAM3 D1000599-v7 (it's now at -v8, and in O5 D1000599 will be superceded by D2300383). 
        :: HAM2 D0902810-v7 (it's not at -v10).
    - These diagrams disagree with how H1 started cable up the ISI optical levers, which have both the HAM3 and HAM2 ISI optical levers routed to the Oplev Whitening Chassis in U9 (ish) of SUS-R1.
        :: According to the above -v7 drawings, the intent was to have the HAM3 ISI optical lever readout by the Oplev whitening chassis in SUS-R2 over by HAM3.
    - The wiring diagrams specified the 2x long DB9 cable run between the whitening chassis (in the field rack) and the AA chassis (in the CER) to be called
        :: (IFO):OPLEV-HAM2_AA
        :: (IFO):OPLEV-HAM3_AA
    - As H1 labeled them, they're also (respectively)
        :: H1:SUS_HAM2_78
        :: H1:SUS_HAM3_161
    - These HAM2 and HAM3 Whitening-to-AA cables *are pulled* from SUS-R1 to SUS-C4 and SUS-C1, respectively, but they're dangling unconnected to any AA.

In short -- the Oplev whitening chassis S1101555 in SUS-R1 U9 *looks* full populated and in use, but every "other end" of the cables plugged into it are disconnected. This chassis, S1101555 in SUS-R1 U9 can *absolutely* be powered down and removed from the rack, pushed to our spares supply.

So, interestingly to our mission, there's two D9M (at SUS-R1 end) to D9F (at CER end) available to be repurposed.
Coincidentally, according to Daniel's design in D0902810-v10, PM1 needs two D9 cables... sort of.
    - SENSOR CABLE: The OSEM PD output of the SUS-R1 U38 Dual, 8ch satamp, D1002818 is mapped from the "PD Outputs to AA" D9F directly to the SUS-C4 U11 "IN25-28" D0902783 8x D9M input AA chassis.
        :: one of the above ISI oplev cables will meet this need perfectly.

    - DRIVE CABLE: The D1100687-v1 or v2 HAM-A coil driver, which uses the driver board D080276, sends out the four coil drive outputs on a D15F on J4. But, the 4x differential channels can absolutely fit on a DB9, as is evident by the Dual, 8ch satamp, D1002818 which accepts the Coil Drive Inputs at J1 as a D9M. In A+ circa 2021-2022, when we started regularly using this HAM-A coil driver + 8ch Dual Satamp combo, Luis drew up the cable solution to this problem, a custom D15M to D9F cable, D2200034.

        :: So, we "just" need to make a short version of this oft-used custom D15 to D9 cable, D2200034, and then we can use the other cable.

That being said -- Daniel says he's "already ordered the cables." 
Ah HA! But -- I worry that the wrong cable has been ordered -- because in D0902810-v10 page 8, Daniel did the sensible thing and copied and pasted the RM1 and RM2 wiring chains from D0902810-v9 page 8 to create the PM1, and JM1-3 chains on -v10 page 9. But alas, there was a typo on the label of this DRIVE CABLE, citing that it should be D2100747, a D15M to D15F cable. It should be the D2200034 D15M to D9F mentioned above.
So -- if we did end up ordering the wrong cable, here's the solution: With only one short adapter made, we can reuse these D9M to D9F cables for the OSEM PD and Coil Drive cables of PM1, if we want or need. Or anything else future that needs a long from from SUS-R1 to the SUS racks in the CER.

(Future readers beware -- the plan may be to fix the typo D2100747 > D2200034 cable label typo in the D0902810-v10 drawing by keeping the same version number in the DCC but sneakily replacing the files -- so if you're reading this in 2026, the comments about the typos in -v10 may not be there...)

I swept the LVEA following the conclusion of most maintenance activities, the last group in will double check their area and get the lights on their way out. Nothing really of note.

WP 12366

Started installation of the required electronics (ISI Interface/AA/AA/ISI Coil Drivers/Binary Chassis) for the HAM1 ISI upgrade. IO chassis will need to be updated.

All existing electronics need to be powered down to move power cables to lower ports on the ±18V DC power strip. New electronics are installed in the upper U slots of the rack and standard power cables are not long enough. Work will be coordinated with the IO chassis upgrade.

Waiting on the in-rack and field cables to be delivered onsite.

J. Kissel, F. Clara

I'm yak shaving, but at the end of today's kLog series you'll understand how to execute Daniel's implicit plan in D0902810-v10 for moving cables around to make room for an incoming tip-tilt, aka HTTS, to eventually be named "PM1," i.e. Pop wfs steering Mirror 1.

In this kLog: I've labeled the U heights of SUS-R1.

SUS-R1 is an old iLIGO rack that was never labelled, but repurposed in aLIGO to house (mostly) HAM2 SUS satellite amps, i.e. the triples MC1, MC3, PRM, PR3, and the singles IM1, IM2, IM3, and IM4. (It also houses a CDS network switch, a PEM test panel, and a deprecated  / never used HAM2 and HAM3 ISI optical lever whitening chassis.)

In aLIGO, all U-slots in U42-ish height racks were "converted" to being labeled by industry standard with the top being U42, and the bottom being U1. These iLIGO racks don't have enough slots to populate all 42 U-height slots, so the compromise is to *draw* 42 U-heights, but "never use" U1.

The last bit of the story: the drawing that governs the content of these racks is D0902810. However, when the aLIGO field racks were populated with stuff, 
    (a) The sites made a custom non-standard 3.25-ish U-height "craddle" to hold the non-rack-mountable UK satamps.
    (b) that drawing did not cover the layout of the field racks, so each sites kinda "did what they wanted."
The issue (b) was been rectified by 2023 as Louis Sanchez and I brought D0902810 up to -v9, see IIET:5097.

So, that's why the U-height labels don't awesomely line up with the chassis that are installed.

See 
- Screenshot of depiction of the rack in page 13 D0902810-v10, with the rack labeled "top down" from U42 at the top and U41 at the bottom (even though the H1 "as-built" version of this design doesn't have a U1).
- single "before" picture
- The rest of the attachment: pictures of the labels.

In order to help narrow the cause of on-going but rare timing comparator discrepency with the CNS clock at EY, I installed a rubidium clock on port 4 of the same comparitor.

The clock is on the floor under the computer rack.  A BNC cable runs from the clock under the roll up door, and over the racks in the CER to the comparator.

Port 7 of the comparator didn't work.

LVEA WAP is now working.  When either the LVEA WAP or the CER WAP is toggled on or off, the toggled WAP must be pinged from the 'wap-control' server before it will reconnect and show up on MEDMs. 

Other WAPs are working normally.  This seems to be a networking issue and not a problem with the WAPs themselves.

I talked to Sheila this morning about turning on the ETMX glitch limiters from this alog, so I've edited ISC_LOCK to turn this back on. This will cause SDF diffs on ETMX when we get to NLN, but otherwise shouldn't interfere with locking. If it's necessary to turn this off, just comment out lines 5462-5464:

            log('turning on esd limits to reduce ETMX glitches')
            for limits in ['UL','UR','LL','LR']:
                ezca.get_LIGOFilter('SUS-ETMX_L3_ESD_%s'%limits).switch_on('LIMIT')

Still unclear if this is helping, but we turned it off ~Feb 12 after running it for almost 2 weeks.

[Erik v.R., Dave]

h1susex models were re-built with the same version of the RCG as h1omc models.

git tag is 'H1_rollback_2025_01_14'

Dolphin started reporting errors while shutting down the models.  We tried to reboot the front end, but it crashed, so we hard reset it.

Following T2500040-v1 the phase delays were measured for LSC REFL_A, LSC POP_A, ASC REFL_A, ASC REFL_B, and ASC POP_X. Results in the attached pdf.

After replacing the chiller pump seal, I switched the lead unit to enable to chiller to run, but it failed on water flow. After troubleshooting the chiller, I found that the wiring harness for the flow switch had been chewed on by an animal. I will see about splicing the damaged wiring back together, but until that is done we are down one chiller at End X.

Tue Mar 04 10:11:57 2025 INFO: Fill completed in 11min 54secs

FAMIS 24832

pH of PSL chiller water was measured to be between 10.0 and 10.5 according to the color of the test strip.

WP 12364

The battery for the LY Vacuum Rack UPS system was replaced this morning. Unit stayed powered on during the battery replacement. Nothing had to be powered down. Noted a low memory pop window on the h0valy machine. Patrick logged in and closed visual studio and medm.

All vacuum rack UPS systems have batteries with an install date of March 2021. Manufacturer recommends batteries be replaced. Replacement batteries will be ordered.

F. Clara, G. Moreno

FAMIS 31075

Jason made a few tweaks last Tuesday, including a PMC alignment tweak and recalibration of amplifier pump diode monitors (alog83035), which is clearly seen in trends here. Since then, things have looked quite stable.

TITLE: 03/04 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 5mph Gusts, 2mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.41 μm/s
QUICK SUMMARY:

• We lost lock at 14:49 UTC, at DRMI as I'm coming in
• 2ndary microseism has risen quickly over the past 9 hours

Workstations were updated and rebooted.  This was an os packages update.  Conda packages were not updated.

Famis 26364

Fan Vibrometer trends.
There was a small bump in the MR_FAN_3_170 about 2 and a half days ago.

TITLE: 03/04 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 13mph Gusts, 9mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.20 μm/s
QUICK SUMMARY:

H1 Has been Locked for 5 Hours and 45 minutes.
All Systems seem to be running smoothly with the Exception of the LVEA WAP.
 

Our range is lower than usual, and it appears that the overall DARM noise changed somewhat coincident with the calibration update (see log 83088). The calibration update has improved the calibration accuracy at some frequencies and worsened it in others, namely, calibration error below 40 Hz has reduced from +-4% to within 1%, but calibration error above 50 Hz has increased from within 1% to 2-3% (I am eyeballing these values off the plot in the linked alog).

I took Jeff's calibration transfer functions from the linked alog and I applied them to the GDS-CALIB_STRAIN_NOLINES channel from a time just before the calibration update and a time after. I used our new range difference calculation method to compare the range from before the calibration change to the range after.

Method:

I chose a "before" time, when the GDS CLEAN range appeared to be around 160 Mpc and an "after" time from this past weekend. I used times that started after 3 hours of lock to ensure we were thermalized. I was careful to look for times with no large glitches, and used median averaging to calculate the PSDs.

before time = 1423272193 (Feb 10 12:22:55 PST)

after time = 142495718 (Mar 2 05:26:08 PST)

I exported the transfer functions shown in this plot (**when exporting, I noticed that the refs used for the phase got mixed up, I believe the blue phase trace corresponds to the black magnitude trace and vice versa**). For the "before" time, I used the black trace labeled "Pre-calibration change" and for the "after" time I used the red trace labeled "Post GDS TDCF Burn-in".

I pulled 30 minutes of data from the times listed above, and used GDS-CALIB_STRAIN_NOLINES for my calculations.

The "uncorrected" data is simply GDS-CALIB_STRAIN_NOLINES * 4000 m (that is, calibrated strain converted into meters with no Pcal correction)

The "corrected" data is (GDS-CALIB_STRAIN_NOLINES * 4000 m) / pcal transfer function, where the pcal transfer function is the R_model / R_true exported from the DTT template above.

The PCAL transfer function is only well-measured from about 9 Hz to 450 Hz, so I cropped the PSDs to those frequencies. Finally, I used the normalized range difference method to calculate the cumulative range difference between the before and after calibration update times for both the "uncorrected" and "corrected" data.

Results:

I believe these results indicate that there is excess noise present in DARM that is unrelated to the calibration change, see first attached plot. I converted the result into a percent difference, because the overall Mpc units refer to the integrated range from only 9-450 Hz, so it's not really comparable with our sensemon range calculation. This plot shows that the range increased about 0.5% between 30-50 Hz, which is present in both the uncorrected and corrected calibrated strain. However, above 50 Hz, the range is worse, and it's here where the difference in the old and new calibration is also evident. Without applying the pcal correction, the range is lower is by nearly 2%, but only about 1% with the pcal correction.

Since this is a frequency dependent effect, it is difficult to say what our overall sensmon range would be if we still had the old calibration and/or we didn't have this excess noise. However, I think it is fair to say that our excess noise has reduced our range by about 1% and the new calibration by another 1%.

I also added a plot that compares these two times, the first is GDS-CALIB_STRAIN_NOLINES * 4000 m and the second is (GDS-CALIB_STRAIN_NOLINES * 4000 m) / pcal transfer function.