RM1 still needs a cable table bracket.

The first set of transfer function measurement results for both RM1 and RM2 are shown in the attachments below (screenshots for all three L, P, Y degrees of freedom). I am not happy with the coherence in RM1 and still working on improving it. I am also planning on taking osem spectra to analyze the noise levels in bosems (considering that their OLC have degraded considerably).

RM1 Transfer function templates:-

/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/RM1/SAGM1/Data

2025-04-29_2330_H1SUSRM1_M1_WhiteNoise_L_0p01to50Hz.xml
2025-04-29_2330_H1SUSRM1_M1_WhiteNoise_P_0p01to50Hz.xml
2025-04-29_2330_H1SUSRM1_M1_WhiteNoise_Y_0p01to50Hz.xml

RM2 Transfer function templates:-

/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/RM2/SAGM1/Data

2025-04-29_2300_H1SUSRM2_M1_WhiteNoise_L_0p01to50Hz.xml
2025-04-29_2300_H1SUSRM2_M1_WhiteNoise_P_0p01to50Hz.xml
2025-04-29_2300_H1SUSRM2_M1_WhiteNoise_Y_0p01to50Hz.xml

Here's an ndscope of April 24th, the first day that we put RM1 and RM2 back in, to hopefully make stuff slightly less confusing.

After installation, we had checked the open light values for RM1 and updated the OFFSETs (green) before realizing that the ADC count signs on (almost) all the OSEMs had been flipped to positive, whereas previously they had been negative (a result of changing the In-Air to SatAmp cable for both RMs: 84027). We flipped them after realizing this, which then fixed the OSEMINF OUT values (cyan). Throughout this, we also had just left RM1's UL OSEM as it was since it was behaving strangely and was the only OSEM to still be reading in negative ADC counts. At the point of the pink cursor, troubleshooting was started for RM1 UL.

Some additions to this aLOG:
- D2100049 is an in-vac quadrapus cable. So the swaps that he's talking about in the above aLOG are *seperate* from the in-air cable swap for RM1 and RM2 that's discussed in LHO:84027

- It's LHO:40853 (indeed, Mar 2018) where I identify that RM2 alone, out of all the remaining tip-tilts in the IFO has it's magnet polarities flipped. I had guessed this was true because the damping loops required a different sign that the other tip-tilts if I had the COILOUTF settings per T1200015 convention.

I've finished the set of test measurements for this latest set of filter files (where we now have the calibration filters in)
These tests were done with HAM5 in ISOLATED

Test 1: Baseline; classic damping w/ gain of Y to -0.1(I took this measurement after the other two tests)
start: 04/29/2025 19:22:05 UTC
end: 04/29/2025 20:31:00 UTC

Test 2: Classic damping w/ gain of Y to -0.1, OSEM Damp Y -0.4
start: 04/29/2025 17:16:00 UTC
end: 04/29/2025 18:18:00 UTC

Test 3: Classic damping w/ gain of Y to -0.1, EST Damp Y -0.4
start: 04/29/2025 18:18:05 UTC
end: 04/29/2025 19:22:00 UTC

Now that we have the calibration in, it looks like there is a decrease in the noise seen between damping with the osems vs using the estimator.

In the plot I've attached, the first half shows Test 2 and the second half shows Test 3

I analyzed the output of the tests for us to compare.

1) First attachment shows the damping of the Yaw modes as seen by the optical lever in SR3. We can see that the estimator is reducing the motion of the 2 Hz and 3 Hz frequency modes. This is most easily seen by flicking through pages 8-10 of the .pdf attached. The first mode's Q factor is higher than OSEM only damping at -0.5 gain, but it is lower than if we kept a -0.1 gain.

2) The second attachment shows that we get this by adding less noise at higher frequencies. From 5 Hz onwards, we have less drive going to the M1 Yaw actuators, which is a good sign. There is a weird bump around 5 Hz that I cannot explain. It could be an artifact of the complementary filters that I'm not understanding, or it could be an artifact of using a 16Hz channel to observe these transfer functions.

Considering that the fits were made on Friday while the chamber was being evacuated and that the suspension had not thermalized, I think this is a success. The Optical lever is seeing less motion in the 1-5 Hz band consistent with expectations (see, for example some of the error plots in 84004), with the exception of the 1Hz resonance. We expect this error to be mitigated by performing a fit with the suspension thermalized.

Some things of note:

- We could perform an "active" measurement of the estimator's performance by driving the ISI during the next round of measurements. We don't even have to use it in loop, just observe M1_YAW_EST_DAMP_IN1_DQ, and compare it with M1_DAMP_IN1_DQ.
The benefit would be to get a measurement of the 'goodness of fit' that we can use as part of a noise budget.

- We should investigate the 5 Hz 'bump' in the drive. While the total drive does not exceed the value for OSEM-only damping, I want to rule out the presence of any weird poles or zeros that could interact negatively with other loops.

Attached you can see a comparison between predicted and measured drives for two of the conditions of this test. The theoretical predictions are entirely made using the MATLAB model for the suspension and assume that the OSEM noise is the main contributor to the drive spectrum. Therefore, they are hand-fit to the correct scale, and they might miss effects related to the gain miscalibration of the SR3 OSEMs shown in the fit in 84041 [note that the gain of the ISI to M1 transfer function asymptotes to 0.75 OSEM m/ GS13 m, as opposed to 1 m/m].

In the figure we can see that the theoretical prediction for the OSEM-only damping (with a gain of -0.5) is fairly accurate at predicting the observed drive for this condition. The observed feature at 5 Hz is related to the shape of the controller, which is well captured by our model for the normal M1 damping loops (classic loop).

In the same figure, we can see that the expected estimator drive is similarly well captured (at least in shape) by the theoretical prediction. Unfortunately, we predict the controller-related peaking to be at 4 Hz instead of the observed 5 Hz. Brian and I are wary that it could mean we are sensitive to small changes in the plant. The leading hypothesis right now is that it is related to the phase loss we have in the M1 to M1 transfer function that is not captured by the model.

The next step is to test this hypothesis by using a semi-empirical model instead of a fully theoretical one.

We were able to explain the drive observed in the tests after accounting for two differences not included in the modelling:

1) The gain of the damping loop loaded into Foton is different from the most recent ones documented in the sus SVN:
sus/trunk/HLTS/Common/FilterDesign/MatFiles/dampingfilters_HLTS_H1SR3_20bitDACs_H1HAM5ISI_nosqrtLever_2022-10-31.mat
They differ by a factor of 28 or so, which does not seem consistent with a calibration error of any sort. But since it is not documented into the .mat files makes it difficult to analyze without ourtright having the filters currently in foton.

2) There was spurious factor of 12.3 on the measured M1 to M1 transfer function due to gains in the SR3_M1_TEST filter bank ( documented in 84259 ). This factor means that our SR3 M1 to M1 fit was wrong by the same factor, the real transfer function is 12 times smaller than the measured one, and in turn, than our fit.

After we account for those two erroneous factors, our expected drive matches the observed drive [see attached figure]. The low frequency discrepancy is entirely because we overestimate the OSEM sensor noise at low frequencies [see G2002065 for an HSTS example of the same thing]. Therefore, we have succeeded at modelling the observed drives, and can move on to trying the estimator for real.

_____

Next steps:
- Recalibrate the SR3 OSEMs (remembering to compensate the gain of the M1_DAMP and the estimator damping loops)
- Remeasure the ISI and M1 Yaw to M1 Yaw transfer functions
- Fit and try the estimator for real

dts_tunnel.service and dts_env.service were restarted on cdsioc0 at 08:04 to clear this error.

Tagging EPO for HAM1 table photos.

Rahul, Gerado, Camilla 

We pulled the old helicoil and installed a new shorter helicoil into LSC POP A. All diode cables are now connected.

As we were running low on dog clamps, I swapped the bases of L2, M10 nd M12 to longer D1200683 mounting bases so that we can use the dog clamps where needed. Photos attached.

"Yes, and..."
- It makes sense to zero the ALIGNMENT offsets for RM1, RM2, and PM1. They're physically aligning the optics in chamber this week, so we don't want to get confused by having digital offsets driven out to the coils.

- Daniel says "Changed the signs of the coil outputs for RM1 and RM2. This should account for the sign change of the OSEM voltages."
Here, "the change in sign of the OSEM voltages" means the fixing of the "has been like that forever as far as we can tell" issue that the RM1 and RM2 OSEM PD sensor readback's ADC voltage had been negative when under light. The fix was in the in-air DB25 feedthru to satamp cable; see LHO:84027 and subsequent comment about the differences in satellite amplifiers.

He acknowledges that this fix will disrupt the overall sign of the damping loops, so he just *picked* a place to flip the sign. 
He chose the COILOUTF banks, but
    . we use these banks to explicitly compensate for the magnet polarity, and 
    . RM1 and RM2 have already confirmed to be different in this regard in Mar 2018; see LHO:40853 -- and in that aLOG we concluded it was RM2 that was abnormal because RM2 required a different damping loop gain than RM1, OM1, OM2, and OM3 when all *settings* were otherwise the same.
    . HOWEVER given that the OSEM sensor readback itself had a negative in it, I'm no longer convinced it's RM2 that's the problem. But at least we know they're different.
    . I tried to have Betsy/Rahul go in chamber to confirm magnet polarity but these HTTS magnets are particularly hard to get at / measure, given that they're buried within the flag and the PEEK flag can no longer be unscrewed from the aluminum optic holder; see LHO:84178
So, since we're left stuck not understanding the coil actuator magnet polarity, I *don't* want to fix the *sensor* sign here. 
We've reverted the above change of COILOUTF signs. They're now restored to 

 $ caget H1:SUS-RM1_M1_COILOUTF_UL_GAIN H1:SUS-RM1_M1_COILOUTF_LL_GAIN H1:SUS-RM1_M1_COILOUTF_UR_GAIN H1:SUS-RM1_M1_COILOUTF_LR_GAIN
H1:SUS-RM1_M1_COILOUTF_UL_GAIN 1
H1:SUS-RM1_M1_COILOUTF_LL_GAIN -1
H1:SUS-RM1_M1_COILOUTF_UR_GAIN -1
H1:SUS-RM1_M1_COILOUTF_LR_GAIN 1

$ caget H1:SUS-RM2_M1_COILOUTF_UL_GAIN H1:SUS-RM2_M1_COILOUTF_LL_GAIN H1:SUS-RM2_M1_COILOUTF_UR_GAIN H1:SUS-RM2_M1_COILOUTF_LR_GAIN
H1:SUS-RM2_M1_COILOUTF_UL_GAIN -1
H1:SUS-RM2_M1_COILOUTF_LL_GAIN 1
H1:SUS-RM2_M1_COILOUTF_UR_GAIN 1
H1:SUS-RM2_M1_COILOUTF_LR_GAIN -1

- He's confirming our work on PM1 from LHO:83293

- 2025-04-29, Daniel has made the model changes in h1sushtts, but they've not yet been installed as this is a trivial top-level model change that has been there forever, and is blocked from reaching the DAC by just turning of the SUS-RM*_ISCINF_L bank inputs.

- We'll re-address the damping loop signs once the dust settles with chamber work.

J. Kissel

First, supporting Daniel's findings that the RM1 and RM2 HTTS OSEM sensor readbacks have been incorrectly negative for ages, I attach a trend of the OSEM ADC input values (and OSEMINF OFFSETS and GAINs) back to 2017.

Not said explicitly in the above aLOG -- Daniel / Fil / Marc installed fresh new DB25 Sat Amp to Vac Feedthru cables (D2100464) just after this aLOG as a part of cabling up the new signal chain for PM1. These cables are one-to-one pin-for-pin cables so it *should* have played no role in the sign of the sensors or how they're connected. 

However, it's now obvious that RM1 and RM2 have had the ADC input voltages as negative for a *very* long time. 

I reviewed the signal chains for the OSEM PDs; see G2500980.

The RMs are using a US 8CH satamps D1002818 / D080276.

I attach a screen-cap of page 4, which highlights that 
    - UK 4CH satamps D0900900 / D0901284 use 
        . a negative reverse bias configuration, with
        . anode connected to bias and cathode connected to the negative input of the TIA, and
        . an inverting differential amplifier stage
    - US 8CH satamps D1002818 / D080276 use 
        . a positive reverse bias configuration, with 
        . cathode connected to the bias and anode connected to the negative input of the TIA, and [hence the apparent "pin-flip" from the other two satamp types]
        . a non-inverting differential amplifier stage
    - US 4CH satamps D1900089 / D1900217use 
        . a negative reverse bias configuration, with
        . cathode connected to the bias and anode connected to the negative input of the TIA, and
        . a non-inverting differential amplifier stage [hence the overall "sign flip" from the other two]

I disagree with Daniel that "the polarity of the PD" i.e. how the anode and cathode are connected to the transimpedance amplifier.
All versions of the PD pinout + SatAmp configure the system in a reverse bias, be it negative or positive. 
In these configurations, even in a zero bias configuration, photocurrent always flows from from cathode to anode as light impinges on the PD. 
So if the anode is hooked up to the negative input of the transimpedance amp (as in D1002818), that signal will have a different sign than if the cathode is hooked up to the negative input (as in D0900900 and D1900089).

The RMs should have their *positive* bias from the D080276 circuit applied.
In 2011, we'd agreed in G1100856 to jumper all OSEM satamps to the "L" position, a.k.a. the LIGO OSEM a.k.a. AOSEM position, which uses a bias voltage and is thus in photo conductive or pc mode. This is mostly because we wanted to not have to think about keeping track of which satamps are jumpered and which are not, but also because the BOSEM PD didn't mind have a bias, even though it was designed to have no bias.

Given the "thought of 2nd to last, last, and never" history of the RMs as they traversed subsystem from ISC to SUS circa O1, moving from the ASC front-end to a SUS front-end circa O2, then never really appearing in wiring diagrams until O3, etc. it wouldn't surprise me if the RMs didn't get the memo to put the bias jumper in the "L" position jumpering pins 2 and 3.

I disagree with Daniel: only the US 4CH satamp D1900089 / D1900217 should read negative with light on it.

So, my guess is that that someone "in 2013" (i.e. during aLIGO install prior to O1) didn't understand these subtleties between the UK 4CH and US 8CH satamp, saw the "different from UK 4CH satamp" and tried fixing the pins of the in-air D25 from satamp to vacuum flange.

Regardless, the new cable has cleared up the issue, and ADC voltage from RM1 and RM2 is now positive.

Kiet, Sheila

We recently started looking into the whether nonlinearity of the ADC can contribute to this by looking at the ADC range that we were using in O4a. 

They are showed in the H1:OMC-DCPD_A_WINDOW_{MAX,MIN} that sum the 4 DC photodiodes (DCPD). They are 18 bits DCPD, so that channel should saturate at 4* 2^17 ~520,000 counts. 

Now there are instances that agree with Ansel report when there are violin mode ring up that we can see a shift in the count baseline.

Jun 29 - Jun 30, 2023 when the baseline seems to shift up and stay there for >1 months, Detchar summary page show significant higher violin mode ring up in the usual 500-520Hz region as well as the nearby region (480-500 Hz) 

Oct 9, 2023 is when the temporary calibration lines are turned off 72096, the down shift happened right after the lines are off (after 16:40 UTC)

During this period, we were using a~5% of the ADC range (difference between max and min channel divided by the total range - 500,000 to 500,000 counts), and it went down to ~2.5 % once the shift happenned on Oct 9, 2023. We want to do something similar with Livingston, using the L1:IOP-LSC0_SAT_CHECK_DCPD_{A,B}_{MAX,MIN} channels to see the ADC range and the typical count values of those channels.

Another thing for us to maybe take a closer look is the baseline count value increase around May 03 2023. There was a change to the DCPC total photocurrent during that time (69358). Maybe worth checking if there is violin mode contaimination during the period before that. 

Kiet, Sheila

More updates related to the ADC range investigation: 

• ADC ranges comparison between Hanford and Livingston: 
  • At Livingston we are using the L1:IOP-LSC0_SAT_CHECK_DCPD_{A,B}_{MAX,MIN} channels, which were not turned on until 1398035799; these channels saturate at 2^17 counts. 
  • At Hanford we are using the H1:OMC-DCPD_A_WINDOW_{MAX, MIN}, these channels saturate at 4 * 2^17 counts as they are sum over 4 DCPD
  • We looked through the data in Feb 2025 when the violin modes at Livingston were somewhat higher than usual. 
  • The range being used in compatible with Hanford (2-4%), and the count values are also similar as LHO counts/4 and LLO counts are in +- 5000 counts of each others.
• Comparing the comtaimination before the DARM offset change in ER15:
  • We saw hint of contaimination even before the change (Using Fscan spectrum of May 2nd) 

Further points + investigations:

• Ansel pointed out that it was odd to have a significant shift in the baseline count value + range when the temporary calibration lines turned off as these calibration lines were not that different in height than other calibration lines (see plot in the Alog 83997)
• Joseph from LLO gave us a spectrum comparison between H1, L1 raw ADC count, there is a notable difference in the higher order violin modes
  • To do: looking to periods of when the both (1st and 2nd) violin modes ring up and periods of only the first violin mode ring up to see the contaimination caused by the 2nd mode or higher down mixing
• Evan pointed out that during the period of high contaimination (June 30th - Aug 9th; 2023), the range stayed between 7 - 20%; and LHO in general seemed to have higher rate of saturation + intermitten increase of the ADC range than LLO. 
  • To do: Selecting the periods of stable ADC range in LHO data, and run the average spectrum over those periods to see the level of contaimination, assessing the contribution of the periods with increase ADC range. 
    
     

Kiet, Sheila

Following up on the investigation into potential intermixing between higher-order violin modes down to the ~500 Hz region:

The Fscan team compiled a detailed summary of the daily maximum peak height (log10 of peak height above noise in the first violin mode region) for the violin modes near 500 Hz (v1) and 1000 Hz (v2). They also tracked line counts in the corresponding frequency bands: 400–600 Hz for v1 and 900–1000 Hz for v2. This data is available in the Google spreadsheet (LIGO credentials required).

• We identified dates when both violin modes were elevated (n1_height > 7; n2_height > 8) and when only the fundamental mode was elevated (n1_height > 7; n2_height < 8). For each case, we computed average PSDs using an FFT length of 1800 s. The study period spans from August 10, 2023, to January 14, 2025, starting when ADC counts stabilized after the temporary calibration lines at 24.4 and 24.5 Hz were turned off (see alog  72096)
  • The psds comparisons is shown in vmodes_psds_comparison.png.
    • Note that the number of averages differs between the cases; there are significantly fewer days with only v1 elevated, which explains why the [v1 high, v2 low] spectrum appears noisier in some regions. However, similar features are still present in the [v1 high, v2 high] case.
    • Notably, there appears to be more spectral content in the 450–550 Hz range when both modes are elevated, with certain lines showing significant power (highlighted in green).

• Daily Fscan data around the violin modes is summarized in Pairwise_scatter_plots.png , where n1_height and n2_height are the max peak heights of v1 and v2, and n1_count and n2_count are the corresponding line counts. There appears to be a threshold in violin mode amplitude beyond which line counts increase (based on {n1_height, n2_height} vs. {n1_count, n2_count} trends).
• We also ploted how n1_count varies with n2_height when n1_height is high in n1_count_vs_n2_height_when_v1_high.png. 

Next: We plan to further investigate the lines that appear when both modes are high, the goal is to identify possible intermodulation products using the recorded peak frequencies of the violin modes.