Lockloss @ 23:01 UTC - link to online lockloss tool
No immediately obvious cause; DARM1 saw the first motion as usual.
I've added a parameter into the CHECK_VIOLINS_BEFORE_POWERUP state which engages 2W damping settings if the saturation checker flags that it's not safe to power up. Once someone requests ISC_LOCK to a higher state to continue locking and the saturation check passes, all damping will be turned back off before continuing.
Speaking of 2W damping settings, I've edited the VIOLIN_DAMPING Guardian to now allow 2W damping for all four quads (previously settings were only enabled for ITMX and ETMX). For modes which have dedicated settings for 2W damping, the Guardian will use those, and for those that don't, the otherwise nominal settings will be used. We had the opportunity to test these 2W damping settings earlier in the week when violins were rung up, and all of them appear to work well, motivating these improvements to our automated damping.
J. Kissel [with support from L. Dartez, F. Llamas, and D. Schaetzl] Executive Summary In Feb 2024, we identified that both the DCPDA and DCPDB channels of the in-vacuum OMC DCPD transimpedance amplifier (TIA) frequency response dropped by 0.3% below ~25 Hz (LHO:75986) and that the frequency-dependent balance of the DCPDs changed in a different way at the 0.2 dB or 10^(0.2/20) = 2.5% level (LHO:76232). Since then, with what limited person power we had, we've been scrapping together ~2 hours of time during maintenance days to try to re-characterize the response of the TIA in order to fit and re-compensate the response, and then re-re-balance the DCPDs. We've also done a lot of thinking in between. This aLOG covers the saga since then, and executive summary is that we don't have good enough measurements of the TIA response yet, we have broken the functionality of the TIA monitor path in the S2300003 D2200215 whitening chassis, and it needs to be replaced in order to move forward with characterizing the in-vacuum TIA. Timeline Editorial note: You'll find that the story is fraught with missing institutional knowledge due to lack of person power and interferometer time. It would pay for us to have had a spare TIA system *out* of vacuum to test our characterization methods and train new staff. . 2024-02-26: In LHO:75986 after measuring twice to ensure we weren't being fooled by vacuum pressure and thermalization, we use the remote, DAC driven characterization setup -- measuring the product of the TIA, the whitening, the whitening compensation, and the TIA compensation -- we conclude that the response of the TIAs has changed, and is no longer as flat as it was the last time we measured it, which was Jul 2023 (LHO:71225). . 2024-02-26: That same day, we measured the TIA response "alone" using the same remote, DAC driven measurement, but instead turning OFF the analog whitening, and the compensation for both -- as the first attempt to "just get the data we need quickly in order to get the job done." We never processed this data because (a) we didn't have the person power, and (b) we later remember that it's not good enough to use for updating the compensation because this measurement doesn't contain the TIA response "alone," but instead also - several computational delays, - the anti-imaging chassis from the DAC, and it's limited by the 16 kHz sampling frequency of the DAC system so we can't characterize everything we need for the TIA, given that there are - 2x 10kHz poles in the TIA itself, and - 1x 44kHz pole in the whitening chassis, even with the z:p = 1:10 Hz whitening filter turned OFF. . From 2024-02-26 thru 2024-04-29: I worked offline with Dean to try to understand the electrical grounding paths in the OMC DCPD signal chain, because it's the only think I can imagine that could cause a *common* change in frequency response to both channels. I now have a much better understanding of the electrical grounding in the OMC signal chain, have produced G2400755, and Dean has made an update to the O4 OMC DCPD wiring diagram accordingly D2100716-v3. However, I conclude that any potential change in the in-vacuum electrical grounding during the OMC swap just is not possible, and the DCPDs are tied to earth ground by and at the in-air whitening chassis, so this is likely NOT the source of the frequency dependent change. . 2024-04-02: Louis and Francisco finally muster up the person power to go out to the HAM6 ISC-R5 rack to repeat the long, arduous, measurement needed. However, they misinterpret my diagrams from the 2023-03-06 and 2023-03-10 measurements (LHO:67801 and LHO:68167) against the reality of the D2200215-style whitening chassis, and drive 1 [V_pk] source voltage backwards against the monitor path's buffer amplifiers. The first attachment shows - page 1: how one should characterize the TIA response, buffer amplifiers, and measurement setup - page 2: how one should characterize the measurement setup and buffer amplifiers in order to divide it out of the page 1 measurement, and - page 3: how the measurement setup and buffer amplifier characterization was misinterpreted on 2024-04-02. Further, as is standard practice, they took SR785 setup notes from "the most recent good measurement available in the SVN," which was the 2023-03-10 data set where Hsiang-yu and I were exploring options. Thus, they used some settings that were meant for testing rather than those which get the best results out of the measurement. More on this later. . 2024-04-09: With Louis and Francisco away for the Solar Eclipse, I head out to the floor to take another crack at it. While I get the measurement setup right, I don't know yet, but I still use bad SR785 settings from the 2023-03-10 date. As such, I get results that are too noisy below 50 Hz to make fits. In the second attachment, I show a quad bode-plot of the DCPDA (page 1) and DCPDB (page 2) where I divide - the Last Best Good measurement -- the 2023-03-06 data and - the 2024-04-09 data against the model fit from that data (see poles and zeros listed in LHO:67809). While one can see hints of the ~0.3% change, it's just too noisy to be confident that we can get a good fit from it. . from 2024-04-09 thru 2024-04-23: With review from Louis, we think hard about why the measurement is noisy. I get a hunch about the SR785 parameters' settle time and settle cycles vs. step (or impulse) response of the TIA response itself, insisting that the settle time of 100 [msec] we've been using since 2022 is not long enough for what the impulse response of the TIA circuit is (because we're perpetually trying cut corners and speed up this measurement). I make a bunch of plots that show the step response of the TIA compared with the bad 2023-03-10 settle settings, but while looking back through my notes I also discover that a difference between the 2023-03-06 and 2023-03-10 measurements is that I had decreased the SR785 source voltage from 4 V_pk to 1 V_pk. The third attachment shows plots that show the good vs. bad SR785 settings and why. - page 1: this compares the settle parameters, visually showing the crossover frequency where, as the swept sine measurement sweeps down in frequency, the SR785 switches over from using settle time to settle cycles, given that it takes the larger of (settle time) vs. (settle cycles / frequency). The dashed lines are the *bad* too little settle time or cycle parameters, and the solid lines are the good, just long enough, settle parameters. Turns out the cross-over frequency isn't that different, but it's important to understand *where* it is, so that you understand *where* in the frequency response this switch happens so you know which parameter to increase when you see noise in the TIA response at a certain frequency. - page 2: Now thinking about the *amplitude* of the excitation vs. the step response of the circuit, I show the magnitude of the modeled response of the TIA with a few points highlighted. Note that, rather than displaying the TIA response magnitude in its "fundamental" units of [Volts output / Amps of current from DCPDs] = [V/A], I display it in the units of this characterization measurement, which is through the 100e3 [V/A] series resistance of the "test" input. Given the intellegent design of the circuit, that means than this measurement of the TIA -- which has transimpedance of 100e3 [V/A] in the gravitational wave band -- has a magnitude of 1 [V/V] in the gravitational wave band. :: the blue "x" and yellow "o" are the cross-over frequencies of the "too little" BAD and the "just enough" GOOD settle params. Good to know that these are *not* in the middle of the 25 Hz resonance feature. But, these cross-over frequency that are the lower bound of a region where we must compare the "desired response" amplitude with the "step response" amplitude after the chosen amount of settle time -- if the "step response" amplitude is still a large fraction of the "desired response" amplitude after (settle cycles/frequency) amount of time, then the data is going to be incoherent (since the circuit is still "ringing" from the incoherent "excitation" that is the step-change in frequency). :: the red square, at 102.4 kHz represents the lowest magnitude point in the "settle time" regime. This is where, again we'll need to make sure that amplitude of the "desired response" amplitude at that frequency is larger than the step response amplitude after the total settle time is complete. :: the black triangle, at "DC," in this case 0.1 Hz, shows the magnitude of the TIA response at low frequency, at 0.002 [V/V]. This is relevant because the step response will asymptote to this value. Also it's the lowest magnitude point of the whole transfer function, but it still needs to be extremely well resolved -- just as much as the ~1.2 [V/V] region around 25 Hz. So one needs to be conscious of the excitation amplitude (be it 1V, or 4V), filtered through this circuit (thus 0.002 [V_pk] or 0.008 [V_pk]) with respect to the ADC noise of the SR785 at the given input range. Note, the input "range" (which really the amount of attenuation of the input) for the A and B inputs of CH2 has been auto-ranged in the past with 4 [V_pk] source (and locked as static during the measurement once found) to be +16 [dBVpk] == 6.3 [V_pk]. The noise floor at the range setting, at this low of frequency is ~0.1 [mV] (see e.g. figure B3 of Hoffman 2009), so a non-negligible fraction of 0.002 [V_pk] response to 1 [V_pk] source, which is why increasing the source amplitude by a factor of 4 is necessary. - Page 3: This shows the full step response of the TIA circuit as a function of time. One can see, as expected, since the maximum gain of the circuit is ~ 1 [V/V], the maximum amplitude of the step response roughly hits the value of the source input within ~100 [usec] of the step. However, we can see that the step response doesn't appreciable attenuate until 0.1 [sec], or 100 [msec]! - Page 4: Here, I zoom in on the amplitude and time of the step response, and compare the BAD SR785 settings with the good SR785 settings. Namely, at the two interesting frequency points from page 2 -- the settle time/settle cycle crossover, and the lowest magnitude point in the settle time region. With 1 V input (page 4), at the bad 101 [msec] settle time, and (1/crossover freq) = 101 [msec] crossover frequency cycle duration, the "desired response" amplitude of circuit is comparable to step response at 100 [msec]. This is why the ~25 Hz region of the measurement has been "noisy" all these years we've been measuring the TIA, and why we need to increase the settle time to 250 [msec]. The 102.4 kHz region was still OK, because there's upwards of 10e3 cycles in 100 [msec], oodles of averages to get good SNR. - Page 5: This shows the same plot, but with 4 [V_pk] source voltage step input and settle time of 250 [msec] and 2 settle cycles. Here, we see that it's not an awesome amount of margin between the step response and the desired circuit response at the interesting frequencies, but it's *definitely* better than 100 [msec] and 1 cycle. . 2024-04-23: So -- we're good right? We take the hit in patience / IFO time, and increase the settle time from 101 [msec] to 250 [ms], settle cycles from 1 to 2, and increase the excitation amplitude from 1 to 4 [V_pk], and we'll get the bet measurement ever, right? No. The fourth attachment shows my utter dismay in that -- yes, while the measurement is much less noisy after having improved the SR785 settings -- BUT the magnitude and frequency response of the 2024-04-23 is subtlety different than the 2023-04-09 and 2023-03-06 measurements at the 0.5 [%] / 1 [deg] level. And that one can trace that difference down to that the measurement setup characterization has a non-linear response to excitation voltage. - Pages 1 and 3 show the quad bode the same quad bode plot, but now it shows the 2023-03-06, 2024-04-09, and the 2024-04-23 measurement all together. See the ~1% magnitude discrepancy? - Pages 2 and 4 show a regular bode plot showing the measurement setup response for all three 2023-03-06, 2024-04-09, and the 2024-04-23 measurements. See the overall magnitude discrepancy, the high-frequency response discrepancy? Maddening. As long as we're going insane, Louis and I convince ourselves (via the data sheet) that the AD8672 op amps in this monitor path on the front-interface board, D2200043 of the D2200215 whitening chassis assembly (which are the same used in the main gravitational wave path on the primary functional board, D2200044) that "there's no way this op-amp can drive +/-4V with an input range of +/- 2.5V and an output drive of +/-3.7V!" ... but we were looking at the table for +/-5V operational state, rather than the +/-15 V operational state, which can happily receive +/-12V and drive +/-13V. But that's what drove me to the EE lab... . 2024-04-24 and 2024-04-25: Since we have spares of these OMC Whitening Chassis in the EE lab, I repeated this "measurement setup" characterization on both channels of spare chassis serial numbers S2300002 and S2300004. - The fifth attachment shows the results the results of these 2x chassis, each with 2x channels, measurements as a function of input voltage. The spare chassis show no evidence of non-linearity in scale, or frequency-dependent magnitude or phase from 0.5 [V_pk] to 5 [V_pk], to the level of the ratio of the 0.5 [V_pk] to all other amplitude excitations being noisy around the 1.0 +/- 0.0001 (or 0.01 [%] or 1 [HOP]) magnitude and 0 +/- 0.02 [deg] in phase across a 10 Hz to 102.4 kHz span. - The sixth attachment compares across all four of these channels at 4.0 [V_pk] source amplitude. All four instantiations of this monitor path in spare chassis show no difference from each other at the same level, using S2300002 CHA as the reference, the ratio of the other channels to it is within 1 +/- 0.0001 in magnitude and 0.1 [deg] in phase. . 2024-04-30: To put the nail in the coffin, I go out and measure the S2300003 chassis' monitor path as a function of input voltage. - The seventh attachment shows the damning evidence -- that the frequency response and scale of this monitor path on the S2300003 chassis changes with input voltage, where the other two instantiations do not. - The eigth attachment shows that the response to 1 [V_pk] source has changed over time, as I compare the 2023-03-10 measurement setup characterization to the 2024-04-30 results. And, while I can't definitely say that the incorrect measurement setup from 2024-04-02 borked the op-amps in the monitor path, it's the only smoking gun I have. "OK, Jeff. You're lost. Why do we care so much about measuring 1.0 from the monitor path of this whitening Chassis?" I hear you, I feel lost. But, in the world where we're trying to update the TIA compensation at the 0.3% level, and the scale and frequency dependence of the measurement tools you're using are non-linear and frequency dependent at the 0.5 [%] / 1.0 [deg] level in the 1 to 100 kHz region, and you're trying to fit for poles at ~10 kHz, then you're gunna get the wrong answer. As such, to restate the executive summary we need to replace the S2300003 D2200215 OMC whitening chassis with one of the spares, in order to get a re-characterization of the OMC TIA after the OMC swap. *sigh*
The scripts used to analyze the data and create the plots from the above aLOG live in /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/ DCPDTransimpedanceAmp/OMCA/S2100832_SN02/20240423/Data/ quick_compare_data_20240423.m (rev 12938) DCPDWhitening/OMCA/S2300002/20240424/ quick_plot_data_20240424.m (rev 12940) Even though the name and location indicates that the script should only be a "quick plot/comparison of the data" from that measurement date, it does in fact contain the measurement-date- and whitening-chassis-serial-number- spanning analysis from this aLOG. Similarly, the data used in the above aLOG lives scattered across the folder structure, /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/ DCPDTransimpedanceAmp/OMCA/S2100832_SN02/ 20230306/Data/ # Pre-OMC-swap data that was used for fitting. Does not have "measurement setup" data to divide out of measurement 20230310/Data/ # Pre-OMC-swap data where we tried to gather the measurement setup characterization, and also explored the excitation amplitude parameter space. 20240402/Data/ # Diagrams of bad measurement setup, and some notes about it (no data was saved) 20240409/Data/ # Noisy data and measurement notes with bad SR785 parameters from 20230310, and suspect TIA pickoff monitor path response in whitening chassis 20240423/Data/ # Good Data/SR8785 params, measurement notes, analysis scripts and suspect TIA pickoff monitor path response in whitening chassis DCPDWhitening/ S2300002/20240424/Data/ # EE Shop, benchtop measurement to show TIA monitor pickoff path response is excitation amplitude independent S2300003/20240430/Data/ # With chassis still installed, in-situ measurement to show TIA pickoff path response depends on excitation amplitude S2300004/20240425/Data/ # EE Shop, benchtop measurement to show TIA monitor pickoff path response is excitation amplitude independent Apologies for the mess.
Supply Fan 1 at EX had faulty bearing(s) which was causing excessive noise. Macdonald Miller was on site this week to carry out the repairs. The work began Monday (5/6) and was completed Tuesday (5/7). The duration of the work was approximately the same on both days (8am-4:30pm) with brief lunch breaks around noon. All of the work was contained to the mechanical space of the end station. T. Guidry
Lockloss @ 18:35 UTC - link to online lockloss tool
No immediately obvious cause; ETMX saw the first erratic movement as usual.
H1 back to observing at 19:56 UTC.
Fri May 10 10:10:49 2024 INFO: Fill completed in 10min 45secs
Travis confirmed a good fill curbside. Note we are now in "summer mode" with TC-mins railing at -200C.
I made a quick plot of low noise % vs wind speed for O4a and thought it was interesting enough to share. This is by no means an analysis, just a quick look. Someone should probably do something similar to what Laurence and Sheila made for O3 for O4a (alog49682), but that someone is not me at the moment. Unlike on Figure 6 of Sheila's similar ER7 plot (T1500368), there isn't a clear drop off at a particular speed. This could be due to directional impacts and the wind fence, or a plethora of other factors. Figure 19 on this paper (<a href="https://dcc.ligo.org/DocDB/0150/P1800038/005/BRSLIGOCQG.pdf">P1800038</a> is again similar with O1 and O2 data, but in m/s. I'm very curious about looking around times of lock losses or failed acquisitions, but I'm not making promises if I'll ever get to those.
This is minute trends of the max wind, binned in integers, then taking the percent of time we were in ISC_LOCK states of >=600.
FAMIS 26243
Laser Status:
NPRO output power is 1.819W (nominal ~2W)
AMP1 output power is 66.92W (nominal ~70W)
AMP2 output power is 138.6W (nominal 135-140W)
NPRO watchdog is GREEN
AMP1 watchdog is GREEN
AMP2 watchdog is GREEN
PDWD watchdog is GREEN
PMC:
It has been locked 37 days, 21 hr 50 minutes
Reflected power = 18.77W
Transmitted power = 108.1W
PowerSum = 126.8W
FSS:
It has been locked for 0 days 7 hr and 12 min
TPD[V] = 0.8582V
ISS:
The diffracted power is around 2.3%
Last saturation event was 0 days 7 hours and 12 minutes ago
Possible Issues:
PMC reflected power is high (this is known, pending further alignment plans)
H1 was out of observing from 14:53 to 15:36 UTC to fix some issues with the SQZ system as we were seeing last night.
After Sheila adjusted the fiber polarization (alog77754), I reverted Corey's changes to the SQZ Guardians' nominal states (listed in his alog77740), then optimized the SQZ angle by running SQZ_MANAGER through 'SCAN_ALIGNMENT_FDS' and 'SCAN_SQZANG,' increasing BNS range by ~10Mpc.
Vicky pointed out that we have picos to adjust the fiber polarization for the new TTFSS fiber beatnote. Adjusting that did bring our beatnote back to a similar level to what it was before the box was swapped on Tuesday, just below 8dBm.
There were many SQZ SDFs, I think related to going to OBSERVE with no squeezing. I think it would be better to ignore these SDF files from the checks when we are in no sqz than to accept many new settings into the OBSERVE.snap, which kind of defeats the purpose of SDF.
The RF Scanner resides in the MSR and its antenna is located on the LVEA roof, close to the GPS receivers. It scans for RF signals in the MHz range, producing a time-freq png plot every 10 minutes.
The freq plots are now available via the DTS web server, URL is https://badger.ligo-wa.caltech.edu/rfscan/pngs/ (one directory per UTC day).
I converted the 144 daily plots into a mp4 movie for the days May 01-08, for example 03 May MP4 Movie. Note that there are some 700-800MHz bursts in the second half, which represents LHO business hours on site (5am - 5pm PDT Friday 3rd May).
TITLE: 05/10 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 131Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 3mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.12 μm/s
QUICK SUMMARY: H1 has been locked and observing (without SQZ) for almost 5 hours.
Lockloss overnight (08:39 UTC) appears to be from a M5.8 EQ out of Taiwan; earthquake mode activated 40 seconds prior. H1 relocked itself without issue and resumed observing at 09:46 UTC.
Since the A2L script that measures a transfer function isn't quite minimizing our ASC noise in DARM, Sheila suggested re-finding the old A2L script that we used to use, which just looks at the height of the peak in DARM.
I think I've found it, in /opt/rtcds/userapps/release/isc/common/scripts/decoup/al2_min_LHO.py . I made sure that it, and other scripts in that directory, were checked in to svn (they were last modified somewhere between 2018 and 2019, depending on the script).
The script (as wrtitten) uses the ADS to actuate each of the quads, and uses the demods to find the size of the signal (it does a sum of the squares of the I and Q of the demodulated signal). The script just guess-and-checks several A2L gain values for each optic, makes a step, and checks again. Once it's finished, it does a linear fit to find the A2L value at which the peak height is expected to be zero. The script runs 8 dither lines (pit and yaw from each quad) around 20 Hz, so that it can do this guess-and-check for all the optics at the same time.
The values in the script are out of date (we've slightly modified the frequencies we use for ADS while locking), so those values and the filter numbers for the matching bandpasses need to be checked. Also, the excitation amplitude in the script is probably higher than we need (they are set to be 300 counts, but we use 30 counts at full power right now, but we may want a little better SNR so we might want to find a value that is between those two.
Also, we may find that we want to instead do the optics one at a time, at 30 Hz, where the coupling of ASC to DARM is more important to our range.
We can try this out during one of our commissioning windows later this week, to see how it goes.
Hey Jenne, I did a total rework of the A2L scirpt for LLO [70246, 69555, 70219].
We never did all of the quads at the same time. We only ran 1 QUAD at a time.
Despite that, the biggest issue I found was that running 2 lines (pitch and yaw) at the same time was a big no-no because the sideband noise they create bleeds into eachother's demod bandwidhts, making the data rubbish and consequently the result rubbish.
My new script that now lives in, and is up to date in the svn:
/opt/rtcds/userapps/release/isc/common/scripts/decoup/a2l_min_generic.py
Warning: despite the script living in a common directory, it is infact only for LLO, because it makes calls to our Calibration Guardian to turn off all of the calibration lines, since we chose to run the demod line at the worst decoupled frequency (exactly where our calibration lines are).
Feel free to draw upon my hours of testing this approach :)
I pulled Vlad's LLO script via the svn (thanks!!), and made a copy /opt/rtcds/userapps/release/isc/common/scripts/decoup/a2l_min_generic_LHO.py . The name is not so good, but at least by knowing that it's the most recently modified file in the folder, we might have some memory of it being the latest.
I lowered the amplitude of excitation to be 30 counts (the same as what we use for ADS after Lownoise_ASC), and when the A2L gains are at the extremal values that the script measures (+/-0.3 from nominal) the line is clear in DARM but not scary-big. I am using the same 30 Hz that Sheila had been using, so this 30 count amplitude is actually a bit smaller in meters than 30 counts at ~20 Hz for ADS.
I set up filters in PIT7 / YAW7 and changed the script to use #7 rather than LLO's #2 set of ADS infrastructure, since #7 was unused for us. I used the same 0.1 Hz half-width for the bandpass that I think Vlad has in place at LLO.
I commented out the "setting the matrices" section and just did those steps by hand today, since I need to import the correct guardian matrices and double-check the indices, and doing it by hand got me going faster to actually trying the script.
I added _SPOT to the test mass drivealign channel names, since we use those here.
I added a few measurement steps so that it's not just jumping by an A2L gain of 0.3. The IFO can handle it, and I may take these extra steps back out (where I pause at a value of 0.15 from nominal before finishing to the 0.3 step), but for testing I didn't want to be too risky.
I also added a calculation to Vlad's script (and this is what could easily be the source of the error that I'll talk about next has come from), to take the sqrt of the sum of the squares of the I and Q demod signals, so that I don't have to worry about setting the demod phase of the ADS demodulator.
However, the answer from the linear fit doesn't seem to make much sense at all. Again, this could be due to my modification of Vlad's script, so I'll need to come back to this and make sure I'm doing what I think I'm doing, before testing again on the IFO. I was only testing on ETMX P so far, and it's clear by watching the line height in DARM and watching the I and Q demod outputs that the current nominal that Sheila has set of 3.35 P2L gain for ETMX is about as good as we can do. However, after trying values between 3.05 and 3.65, somehow the fitting function seems to think that it should be set to 1.76(!!). Thankfully I had forgotten to add the _SPOT to the line that would have written the value and jumped the gain straight to there, so that value didn't actually get written to the IFO. I've commented out the writing of the value from the script for now, until I figure out what's going on with the fitting.
Next up is to see if I can understand why the fit tried to send me to such a strange A2L gain, then check that this amplitude is okay for other quads both pit and yaw, then actually run it to see it minimize coupling.
Below here is just notes to self, for figuring out what's going on with the fitting. I should have had the script print out more so I could double check it's sqrt-sum-squares, but I can at least check for the last value. The two long arrays are what are being fit to. Reminder to self that I got the same gain it wanted to send me to of 1.7-ish, even before I changed / added more steps and re-measuring some values. But, that was after I added in the summing of the squares. I didn't ever run the script with just looking at the I output of the demod.
Result in terminal from (lines 279-282 in the script)
print(gainList)
print(meanI)
print(meanQ)
print(meanList)
is
[3.2 3.05 3.2 3.35 3.5 3.65 3.5 3.35]
0.0004724146701240291
2.2764012343638282e-05
[0.00614473 0.01331277 0.0065377 0.00075812 0.00755947 0.01463074
0.00760131 0.00047296]
Want to change gain from 3.35 to 1.779, rounded to 2 decimal places. St.Div is 0.054
take the sqrt of the sum of the squares of the I and Q demod signals, so that I don't have to worry about setting the demod phase of the ADS demodulator.
I only take the I; I am not sure if the sqrt of I and Q might confise signs: and therefore break the linear fit of the function. Might make it non-linear; which breaks things. I quickly plotted (attachment) what you wrote, and it looks like it isnt going negative because sqrt will only give positive results. It tries to solve for zero crossing, but here zero looks to be near 3.35, but then goes back up.
Actually the reason I only look the I-phase is because I dont want go rephasing the demodulation, and just assume there is some signal in I. Then just solving for zero crossing should not care about actual amplitudes.
However, after trying values between 3.05 and 3.65, somehow the fitting function seems to think that it should be set to 1.76(!!)
Do not trust this! After fixing it such that you preserve sign (so that linear fit solves for zero crossing), always check the output to make sure it is not extrapolating a linear result far away, because at far distances you can't comepletly trust that it is linear.
Want to change gain from 3.35 to 1.779, rounded to 2 decimal places. St.Div is 0.054
For reference: the fitted zero crossing st.div for us is about 0.003. Adjust amplitudes accordingly, after you are getting logical results.
Sheila asked a good question the other day of, Did SR2 alignment change between the beginning of O4b (when things were still good) and when we had the bad losses through the OFI (when things were bad, before the big shift). The answer: no, I don't think SR2 moved very much (according to its top mass osems) when the the losses through the OFI showed up. It did move about 10 urad in yaw (see table below), which I plan to look into further.
I looked at several times throughout the last few weeks when ALIGN_IFO guardian had just finished up state 58, SR2_ALIGN at 10 W, which it now does every time initial alignment is automatically run. These should all be single bounce off of ITMY, with the beam centered on AS_C by adjusting the SR2 sliders, for some given SR3 slider position (nothing automatic touches the SR3 sliders).
In the table, I summarize the SR3 and SR2 top mass osems. I've got 3 categories of times for the IFO situation:
Note that this table is not chronological, since I've grouped rows by IFO situation rather than time. The SR2 and SR3 osem values that are in bold are the ones to compare amongst each other. There does seem to be a 10 urad shift in SR2 yaw between the April 21st and April 23rd times. There are no other run-throughs of the SR2_ALIGN state of ALIGN_IFO between these times to check. This SR2 yaw shift (which is consistent even when we revert sliders to the 'pre shift' values and run SR2_ALIGN) is notable, but not nearly as large as what we ended up using for steering around the spot in the OFI.
IFO 'situation' | Date / time [UTC] | AS_C NSUM value | SR3 Pit [M1_DAMP_P_INMON] | SR3 Yaw [M1_DAMP_Y_INMON] | SR2 Pit [M1_DAMP_P_INMON] | SR2 Yaw [M1_DAMP_Y_INMON] |
(1) before EQ, before loss, before alignment shift | 17 Apr 2024 00:19:00 | 0.0227 | -281.5 | -612.2 | 569.8 | 35.3 |
(1) after EQ, before loss, before alignment shift | 21 Apr 2024 20:08:30 | 0.0227 | -281.5 | -611.9 | 571.9 | 35.3 |
(2) after EQ, after loss, before alignment shift | 23 Apr 2024 23:10:00 | 0.0193 | -281.9 | -612.2 | 572.7 | 26.7 |
(2) after EQ, after loss, shift temporarily reverted to check | 7 May 2024 18:10:00 | 0.0187 | -282.3 | -616.0 | 558.5 | 23.2 |
(3) after EQ, after loss, after alignment shift | 25 Apr 2024 12:18:20 | 0.0226 | -291.7 | -411.1 | 599.6 | 1150.0 |
(3) after EQ, after loss, after alignment shift | 7 May 2024 19:11:15 | 0.0226 | -292.4 | -408.8 | 597.6 | 1149.9 |
After a quick re-look, that 10 urad move in SR2 yaw seems to have come during maintenance, or sometime later than the time that the loss showed up.
In the attachment, the vertical t-cursors are at the times from the table in the parent comment on April 21st and 23rd. The top row is SR2 pitch and yaw, and the bottom row is SR3. The middle row shows our guardian state (i.e. when we were locked), and kappa_c which is indiciative of when we started to see loss. In particular, there are 3 locks right after the first t-cursor, and they all have quite similar OSEM values for SR2 yaw (also the times between locks are similar-ish). Those three locks are the last one with no loss, one with middling-bad loss, and one with the full loss. So, it wasn't until after we had our full amount of loss that SR2 moved in yaw. I haven't double-checked sliders yet, but probably this is a move that happened during maintenance day.
I'm using Jenne's times above to do a similar check, but looking at times when ALIGN_IFO was in state 65 (SRY align) because in that state the AS WFS centering servos are on. This state is run shortly after state 58, so I'll reuse Jenne's numbers to refer to times and the IFO situation.
This table indicates that changes in AS power are consistent between AS_C and the AS WFS, so the beam transmitted by OM1 and reflected by OM1 see similar losses. This makes it seem less likely that a bad spot on OM1 is the problem (and points to probably being an issue with the OFI), although it's not impossible that a loss on OM1 is seen in the same way for transmission and reflection.
AS_C sum | AS_C normalized to first row | AS_A sum | AS_A normalized to first row | AS_B sum | AS_B normalized to first row | ||
1 | April 17 00:20:15 UTC | 0.0626 | 1 | 5264 | 5104 | ||
1 | April 21 20:09:43 UTC | 0.0629 | 1.005 | 5283 | 1.004 | 5114 | 1.002 |
2 | April 23 23:34:15 UTC | 0.0534 | 0.853 | 4595 | 0.873 | 4359 | 0.854 |
2 | AS centering was not run this time | ||||||
3 | April 25 12:19:36 UTC | 0.0622 | 0.993 | 5209 | 0.989 | 5083 | 0.996 |
3 | May 7 19:12:30 UTC | 0.0624 | 0.997 | 5241 | 0.996 | 5118 | 1.003 |
Sheila, Jenne, Tony, Camilla
We've had locklosses in DRMI because the PRCL gain has been to high when locked on REFL1F. Tony looked and thinks that this started on 77583, the day of our big shift in the output alignment.
Today we acquired DRMI with half the gain in the PRCL input matrix for 1F, this one acquisition was fast. I've attached the OLG measurements for PRCL and MICH after the change.
Tony is working on making histograms of the DRMI acquisition times, before the 23rd, from the 23rd to today, and eventually a histogram from today for the next few weeks to evaluate if this change has an impact on the DRMI acquisition times.
Jenne also found that it seems out POP18 build up seems higher in DRMI since the 23rd.
I'm no longer quite so sure about the conclusion that Pop18 is higher, or at least enough to really matter.
Here are 2 screenshots that I made extremely quickly, so they are not very awesome, but they can be a placeholder until Tony's much more awesome version arrives. They both have the same data, displayed 2 ways.
The first plot is pop18 and kappaC versus time. The x-axis is gpstime, but that's hard to interpret, so I made a note on the screenshot that it ranges from about April 20th (before The Big Shift) to today. Certainly during times when the optical gain was low, Pop18 was also low. But, Pop18 is sometimes high even before the drop in optical gain. So, probably it's unrelated to The Big Shift. That means that the big shift in the output arm is not responsible for the change in PRCL gain (which makes sense, since they should be largely separate).
The second plot is just one value versus the other, to see that there does seem to be a bit of a trend that if kappaC is low, then definitely Pop18 is low. But the opposite is not true - if pop18 is low kappaC isn't necessarily low.
The last attachment is the jupyter notebook (you'd have to download it and fix up the suffix to remove .txt and make it again a .ipynb), with my hand-typed data and the plots.
I actually didn't load the guardian at the time of this change, so it didn't take effect until today.
So, we'd like histograms of DRMI acquitisiton times from before April 23rd, from April 23rd until today, and for a few weeks from today.
Using the Summary pages I was able to get a quick google sheet to give me before and after Histograms of how long ISC_LOCK was in DRMI 1F.
First Sheet's data is before Nov 18th 2024, consisting of 100 gpstimes and durations where ISC_LOCK was in AQUIRE_DRMI_1F.
Second Sheet's data is After Nov 18th 2024. Consisting of 100 gpstimes and durations where ISC_LOCK was in AQUIRE_DRMI_1F
Interesting notes about ISC_LOCK.
ISC_Lock will request PRMI or Check MITCH Fringes some where between 180 seconds and 600 seconds, depending on how much light is seen on AS_AIR.
If AS_AIR sees flashes above 80 then ISC_LOCK will not kick us out of DRMI until 600 seconds.
So it looks like one of the changes that happened on or around Nov18th made the Flashes on AS_Air higher but we are still not actually locking DRMI.
We had fewer Aquire DRMI durations, over 180 Seconds before Nov 18th's changes.
I went to FCES this morning to try to troubleshoot the sort of busted H1 GS13 on HAM8. I suspect there is something going on with the cable or interface chassis, but it's not something I think I've seen before. I tried swapping cables at both the rack and the chamber, and whenever the corner 1 chassis was connected to the H1 sensor, the transfer function from the H1 CPS to the H1 sensor would be half the magnitude of the other two sensor pairs. ASDs also show the H1 GS13 has half gain when the corner 1 sensors are connected to the corner 1 chassis. However, when the H1 sensor was plugged into the corner 2 or 3 chassis, all three sensor pair tfs would have the same amplitude. I could repeat this consistently, didn't matter how I swapped the cables around, as long as the H1 sensor wasn't plugged into the correct chassis all the l2l sensor tfs would look normal.
Attached plot shows two sets of data I took during this period, red blue and light green are the normal config, dark green, pink and light blue are with the H1 sensor on the corner 3 chassis, H3 sensor on the corner 1 chassis.
I will talk to Fil, but maybe in a couple weeks we can try running a temp cable from the FC mezzanine to the chamber, and see if that changes anything.
Issue is tracked in FRS 31005
J. Kissel As we continue to investigate both ADC noise (both broadband, in-general behavior) as well as down-converted aliasing noise in the new fast 524 kHz OMC DCPD signal chain, I needed to wrap my head around all the available channels in order to begin thinking about how to compare / take advantage of the differences between the channels. I don't understand anything until I diagram it, so here's my diagram of the existing OMC DCPD signal chain as I understand it, hoping it helps others. As mentioned in each of the previous aLOGs where I've started the investigation (LHO:67552, LHO:67530, LHO:67465, LHO:67297, LHO:67439), studies of the 524 kHz portion of the system are severely limited in that (a) no 524 kHz channel stored in the frames, (b) one can only look at 3 test points at a time, (c) we don't have any analog measure of the noise between 524 kHz and 102.4 kHz (the upper limit of the SR785) to compare against But, we'll do what we can! Hopefully this visual aide will help understand future studies. For example, because we *don't* have any digital anti-aliasing filters in the OMC-PI SIG filter bank, we can compare these test point channels, - H1:OMC-DCPD_A0_OUT (524 kHz, w/ digital anti-aliasing) - H1:OMC-PI_DOWNCONV_SIG_OUT (524 kHz, w/o digital anti-aliasing) - H1:OMC-PI_DPCD_64KHZ_AHF (65 kHz, w/o digital anti-aliasing) - H1:OMC-DCPD_A_IN1 (16 kHz, w/ digital anti-aliasing) to explore the effectiveness of the digital anti-aliasing filters to better understand the aliasing that Evan Hall found in LHO:67328. Note -- and this is something that I'm still learning (via conversations with Erik von Ries and Daniel Sigg and their aLOGs, including but not limited to LHO:67587, LHO:67560, LHO:67291) -- the h1iopomc0 model actually runs at 65 kHz (really, 2^16 kHz). In order to achieve a pseudo-524 kHz data stream, there's a for loop within the h1iopomc0 model that's able to complete 8 iterations (thus 2^16 kHz * 8 = 2^19 kHz = 524 kHz) during any given 65 kHz clock cycle.
Sorry team. There's a typo in the 65 kHz version of the DCPD channel in the PI model in both the above list, as well as in the diagram. The channel list to accompany the diagram should be - H1:OMC-DCPD_A0_OUT (524 kHz, w/ digital anti-aliasing) [[NOT STORED IN THE FRAMES, ONLY LIVE AVAILABLE]] - H1:OMC-PI_DOWNCONV_SIG_OUT (524 kHz, w/o digital anti-aliasing [[NOT STORED IN THE FRAMES, ONLY LIVE AVAILABLE]] - H1:OMC-PI_DCPD_64KHZ_AHF (65 kHz, w/o digital anti-aliasing) [[STORED IN FRAMES at 65 kHz as H1:OMC-PI_DCPD_64KHZ_AHF_DQ]] - H1:OMC-DCPD_A_IN1 (16 kHz, w/ digital anti-aliasing) [[STORED IN FRAMES at 16 kHz as H1:OMC-DCPD_A_OUT_DQ]] Careful here: In O3, H1:OMC-DCPD_A_IN1 was NOT equivalent to H1:OMC-DCPD_A_OUT_DQ, since H1:OMC-DCPD_A_IN1 *used* to be the "raw" (down-sampled, and digital AA filtered) ADC 16 kHz channel, and then the DCPD_A bank applied all of the the calibration and frequency response compensation. Now, as of O4, with the 524 kHz system, that's done in the DCPD_A0 bank, and the DCPD_A bank is an "empty" gain of 1.0 "passthrough," so DCPD_A_IN1 is equal to DCPD_A_OUT.
Further, a reminder that we've installed a "plug" that shorts the ADC inputs of channels 17 through 20 of this new 524 kHz system, so looking at the channels might also be interesting if we're looking for noise that might be present on the ADC channels alone (i.e. without any signals going into it). See LHO:67465 for details, but in short, you want to look at the (live, not stored in the frames) 524 kHz channels, - H1:IOP-OMC0_MADC0_EPICS_CH17 - H1:IOP-OMC0_MADC0_EPICS_CH18 - H1:IOP-OMC0_MADC0_EPICS_CH19 - H1:IOP-OMC0_MADC0_EPICS_CH20 for a "shorted" version of the OMC DCPD ADC card channels. This would be useful to, say, investigate how / why the DuoTone signal shows up in the DCPDs (see LHO:77579), and to compare and contrast against the L1 DCPDs which also see it (see LHO:70961), but they've not yet segregated their OMC ADC card, and (I think) have a different, older version of the Timing Interface card.
00:18 UTC Observing