Continued from LHO alog 84128.

RM1 (Tip Tilt suspension)

Last week Daniel and I replaced the original TT bosem cable (with a new 25in long, D2100049 S/N 2200358) since the original cable was having issues with grounding. However, Betsy informed us that the new cable might have pin 1 missing (and should be sent back to CIT for repair). I inspected the cable in-chamber and found pin1 missing.

Hence, I replaced the 25in long D2100049 S/N 2200358 (missing pin 1) with 54in long D2100049 s/n S2100426 cable. However, the ground loop issues has now returned (shorting with the chamber itself) and it looks like the culprit is not the cable but the bosem itself (despite having kapton tape for shielding, clearly its not enough). I am still considering to slide a kapton sheet underneath RM1.

Also, I measured the Open light counts of all four bosems for RM1 and they are listed below,

RM2 (Tip Tilt suspension)

Kissel, Betsy, Rahul

Here, Jeff suspects that the bosem magnet polarity is incorrect (i.e is not as per E1400316) which was recorded in his LHO alog from 2018. To verify Jeff's claim we went back into the chamber to check the polarity of RM2 magnets. However we faced two problems over here. At first I looked into the Tip Tilt assembly drawing and then the Tip Tilt PEEK flags in Triples lab to locate the magnet inside the flag. It turns out that the magnet is buried deep inside the PEEK flag, such that my polarity tester cannot detect its presence. Hence, I took another strong magnet to check if its pulling or repelling it - which worked fine. The second problem we faced was that the PEEK flag are a very tight fit inside the TT mirror holder (in-chamber) and despite our best efforts (both Betsy and I tried unscrewing it) we couldn't remove it for checking. Hence, we were unsuccessful in measuring the magnet polarity and after some discussion we decided to move ahead and reset RM2 (digitally) to how it was before this vent. Jeff will file an FRS ticket regarding this issue.

The Open light counts for RM2 is given below,

I have accepted the SDFs for both RM1 and RM2 and three screenshots are attached below.

Today, Dave and I did the final bit of WP 12467.  We connected a monitor and keyboard and configured the networking on h1hpipumpctrlcs, which is the new hpi beckhoff controller for the corner station.  Filiberto had done the physical link to the CDS switch earlier.  We were able to share the monitor with the old control computer as the new and old systems had different video connectors, but there is a new keyboard for the new computer.  If anyone needs to work on it, we need to get a usb mouse out there as well.

Now that it is on the network Patrick can remotely access and start programming the new controller.

At this point there is nothing hooked up for it to control.

Gerardo, Camilla, WP 12491

Also fixed the LSC POP helicoil so all diodes are now cabled, details in 84174

The monthly fire pump test was conducted this morning. Water was only churned per NFPA requirements. Each pump was run for ten minutes. The jockey pump and fire pump 1 were started via simulated pressure drop on the supply line, fire pump 2 was manually started. 

Edgard, Oli.

Follow up to the work summarized in 84012 and 84041.

TL;DR: Oli tested the estimator on Friday and found the ISI state affects the stability of the scheme, plus a gain error in my fits from 84041. The two issues were corrected and the intended estimator drives look normal (promising, even) now. The official test will happen later, depending on HAM1 suspension work.

____

Oli tested the OSEM estimator damping on SR3 on Friday and immediately found two issues to debug:

1) [See first attachment] The ISI state for the first test that Oli ran was DAMPED. Since the estimator was created with the ISI in ISOLATED (and it is intended to be used in that state), the system went unstable. This issue is exacerbated by point 2) below. This means that we need to properly manage the interaction of the estimator with guardian and any watchdogs to ensure the estimator is never engaged if the ISI trips.

2) [See second attachment] There was a miscalibration of the fits I originally imported to the front-end. This resulted in large drives when using the estimator path. In the second figure, there are three conditions for the yaw damping of SR3:
           ( t < -6 min )          OSEM damping with gain of -0.1.
    ( -6 min<  t  < -2 min)   OSEM damping with a gain of -0.5, split between the usual damping path and the estimator path.
     ( -2 min < t < 0 min)     OSEM + Estimator damping.

The top left corner plot shows the observed motion from every path. It can be seen that M1_YAW_DAMP_EST_IN1 (the input to the estimator damping filters) is orders of magnitude larger than M1_DAMP_IN1 (the imput to the regular OSEM damping filters).

The issue was that I fit and exported the transfer functions in SI units, [m/m] for the suspoint to M1, and [m/N] for M1 to M1. I didn't export the calibration factors to convert to [um/nm] and [um/drive_cts], respectively.

____

I fixed this issue on Friday. Updated the files in /sus/trunk/HLTS/Common/FilterDesign/Estimator/  to add a calibration filter module to the two estimator paths (a factor of 0.001 for suspoint to M1, and 1.5404 for M1 to M1). The changes are current as of revision 12288 of the sus svn.

The third attachment shows the intended drives from the estimator and OSEM-only paths. They look similar enough that we believe the miscalibration issue has been resolved. For now we stand by until there is a chance to test the scheme again.

Morning dry air skid checks, water pump, kobelco, drying towers all nominal.

Dew point measurement at HAM1 , approx. -43C

Tue Apr 29 10:04:37 2025 INFO: Fill completed in 4min 34secs

Closes FAMIS26501

2025-04-29 08:05:53.258718

There are 13 T240 proof masses out of range ( > 0.3 [V] )!
ETMX T240 2 DOF X/U = -1.18 [V]
ETMX T240 2 DOF Y/V = -1.115 [V]
ETMX T240 2 DOF Z/W = -0.803 [V]
ITMX T240 1 DOF X/U = -1.733 [V]
ITMX T240 2 DOF Z/W = 0.355 [V]
ITMX T240 3 DOF X/U = -2.292 [V]
ITMY T240 3 DOF X/U = -0.976 [V]
ITMY T240 3 DOF Z/W = -2.401 [V]
BS T240 2 DOF Y/V = -0.318 [V]
BS T240 3 DOF X/U = -0.604 [V]
BS T240 3 DOF Z/W = -0.365 [V]
HAM8 1 DOF Y/V = -0.478 [V]
HAM8 1 DOF Z/W = -0.764 [V]

All other proof masses are within range ( < 0.3 [V] ):
ETMX T240 1 DOF X/U = -0.1 [V]
ETMX T240 1 DOF Y/V = -0.082 [V]
ETMX T240 1 DOF Z/W = -0.092 [V]
ETMX T240 3 DOF X/U = -0.035 [V]
ETMX T240 3 DOF Y/V = -0.154 [V]
ETMX T240 3 DOF Z/W = -0.063 [V]
ETMY T240 1 DOF X/U = 0.011 [V]
ETMY T240 1 DOF Y/V = 0.083 [V]
ETMY T240 1 DOF Z/W = 0.149 [V]
ETMY T240 2 DOF X/U = -0.134 [V]
ETMY T240 2 DOF Y/V = 0.152 [V]
ETMY T240 2 DOF Z/W = 0.046 [V]
ETMY T240 3 DOF X/U = 0.158 [V]
ETMY T240 3 DOF Y/V = 0.031 [V]
ETMY T240 3 DOF Z/W = 0.058 [V]
ITMX T240 1 DOF Y/V = 0.22 [V]
ITMX T240 1 DOF Z/W = 0.14 [V]
ITMX T240 2 DOF X/U = 0.155 [V]
ITMX T240 2 DOF Y/V = -0.054 [V]
ITMX T240 3 DOF Y/V = 0.253 [V]
ITMX T240 3 DOF Z/W = 0.139 [V]
ITMY T240 1 DOF X/U = -0.059 [V]
ITMY T240 1 DOF Y/V = 0.018 [V]
ITMY T240 1 DOF Z/W = -0.067 [V]
ITMY T240 2 DOF X/U = 0.008 [V]
ITMY T240 2 DOF Y/V = 0.211 [V]
ITMY T240 2 DOF Z/W = -0.046 [V]
ITMY T240 3 DOF Y/V = -0.056 [V]
BS T240 1 DOF X/U = 0.176 [V]
BS T240 1 DOF Y/V = -0.272 [V]
BS T240 1 DOF Z/W = -0.278 [V]
BS T240 2 DOF X/U = 0.094 [V]
BS T240 2 DOF Z/W = 0.221 [V]
BS T240 3 DOF Y/V = -0.039 [V]
HAM8 1 DOF X/U = -0.297 [V]

FRS33974

Following this morning's reboot of x1dtslogin, the EPICS IOC reporting the H2 building DTS environment channels froze with its last values instead of crashing. After 10 minutes this was reported on the main DTS MEDM with a red banner showing a stuck GPS time, but this was not reflected on the CDS Overview.

I have modified DTS.adl, which is used by the CDS overview, to show a red flag if the GPS time stops updating. Attachment shows the new flag and a trend of the DTS air flow channel showing the freeze which started at 07:33 Tue 29apr2025

TITLE: 04/29 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 5mph Gusts, 3mph 3min avg
    Primary useism: 0.50 μm/s
    Secondary useism: 0.13 μm/s
QUICK SUMMARY:

• Some of the work today includes
  • EY wind fence work
  • HAM1 cable work
  • Ground checks of LSC/ASC diode boxes now fully cabled
  • HAM1 - RM finish SUS troubleshooting - get suspended with good TFs
  • HAM1 RM1 troubleshooting ground - alog missing pin 1 ?
  • VAC - HAM1 Top flange Gauge work table side
  • PCAL
  • HAM4/5 cable trays
  • When all SUS, SEI, PSL seem in good order, transition to Laser Haz and perform 200mW lockout power into HAMs
  • Model work, DAQ restart
  • Clean room moves, BSC8

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

1. Beckhoff computer and terminals in Mechanical Room
2. Beckhoff terminals in LVEA (BSC2)
3. Connected to switch: sw-mech-aux port 5

Oli, Camilla.

Following work done in 84115 to repopulate HAM1 with some optical components, today Oli and I placed the SLED in position and placed all the diodes, most (not LSC POP A ) are cabled. Photos taken from -Y side and +Y side attached.

Apart from LSC POP A, they are all cabled up according to the cables in D1000313 BOM googlesheet. LSC POP A has a heli-coil that needs replacing before we can install the RF cable so neither cable are currently installed. ASC REFL A and B are in the incorrect position to allow for beam profiling before moving the the final position. LSC REFL A and B may need to be moved slightly but we need more of the correct size dog clamps to allow that. 

Jonathan, Dave:

The DAQ detail MEDM has been updated to show FW2's progress within the 64 second cycle for full frames, 600 second cycle for second trends and 3600 second cycle for minute frames.

When each progress bar reaches the end, the next data accumulation phase starts and the frame file writing begins.

A new run_number column has been added, along with a LED stack checking these all agree with each other.

The retransmission column has been removed.

Summary

Q: What is the relationship between the strength of violin mode ring-ups and the number of narrow spectral artifacts around the violin modes? Is there a clear cut-off at which the contamination begins?

A: The answer depends on the time period analyzed. There was an unusual time period spanning from mid-June 2023 through (very approximately) August 2023. During this time period, the number lines during ring-ups was much greater than in the rest of O4, and the appearance of the contamination may have begun at lower violin mode amplitudes.

What to keep in mind when looking at the plots.

1. These plots use the Fscan line count in a 200-Hz band around each violin mode region, which is a pretty rough metric, and not good for picking up small variations in the line count. It's the best we've got at the moment, and it can show big-picture changes. But on some days, contamination is present, but only in the form of ~10 narrow lines symmetrically arranged around a high violin mode peak. (Example in the last figure, fig 7) This small jump in the line count may not show up above the usual fluctuations. However, in aggregate (over all of O4) this phenomenon does become an issue for CW data quality. These "slight contamination" cases are also particularly important for answering the question "at what violin mode amplitude does the contamination just start to emerge?" In short, we shouldn't put too much faith in this method for locating a cut-off problematic violin mode height.

2. The violin modes may not be the only factor in play, so we shouldn't necessarily expect a very clear trend. For example, consider alog 79825 . This alog showed that at least some of the contamination lines are violin mode + calibration line intermodulations. Some of them (the weaker ones) disappeared below the rest of the noise when the violin mode amplitude decreased. Others (the stronger ones) remained visible at reduced amplitude. Both clusters vanished when the temporary calibration lines were off. If we asked the question "How high do the violin modes need to be...?" using just these two clusters, we'd get different apparent answers depending on (a) which cluster we chose to track (weak or strong), and (b) which time period we selected (calibration lines on or off). This is because at least some of the contamination is dependent on the presence & strength of a second line, not a violin mode.

Looking at the data

First, let's take a look at a simple scatter plot of the violin mode height vs the number of lines identified. This is figure 1. It's essentially an updated version of the scatter plots in alog 71501. It looks like there's a change around 1e-39 on the horizontal axis (which corresponds to peak violin mode height).

However, when we add color-coding by date (figure 2), new features can be seen. There's a shift at the left side of the plot, and an unusual group of high-line-count points in early O4.

The shift at the left side of the plot is likely due to an unrelated data quality issue: combs in the band of interest. In particular, the 9.5 Hz comb, which was identified and removed mid O4, contributes to the line count. Once we subtract out the number of lines which were identified as being part of a comb, this shift disappears (figure 3).

With the distracting factor of comb counts removed, we still need to understand the high-line-count time period. This is more interesting. I've broken the data down into three epochs: start of O4 - June 21, 2023 (figure 4); June 21, 2023 - Sept 1 2023 (figure 5); and Sept 1 2023 - present (figure 6). As shown in the plots, the middle epoch seems notably different from the others.

These dates are highly approximate. The violin mode ring-ups are intermittent, so it's not possible to pinpoint the changes sharply. The Sept 1 date is just the month boundary that seemed to best differentiate between the unusual time period and the rest of O4. The June 21 date is somewhat less arbitrary; it's the date on which the input power was brought back to 60W (alog 70648), which seems a bit suspicious. Note that, with this data set, I can't actually differentiate between a change on June 21 and a change (say) on June 15th, so please don't be misled by the specificity of the selected boundary.