ENDX Station Measurement:
During the Tuesday maintenace, the PCAL team(Rick Savage & Tony Sanchez) went to ENDX with Working Standard Hanford aka WSH(PS4) and took an End station measurement.
The ENDX Station Measurement was carried out according to the procedure outlined in Document LIGO-T1500062-v15, Pcal End Station Power Sensor Responsivity Ratio Measurements: Procedures and Log, and was started by 1pm & completed by 3:30 pm. There were complications caused by some work being done on the Beckhoff systems, which certainly made this measurement take longer. I would argue that the troubleshooting of the laser turning off forced us to take the enclosure coveres off which increased the light on the TxPD which likely had some effect on the Tx Background. Also might have made our laser less thermally stable with the laser coming up and down a handfull of times.
The First beam spot was not taken.
Martel:
We started by setting up a Martel Voltage source to apply some voltage into the PCAL Chassis's Input 1 channel and we record the times that a -4.000V, -2.000V and a 0.000V signal was sent to the Chassis. The analysis code that we run after we return, uses the GPS times, grabs the data and created the Martel_Voltage_Test.png graph. We also did a measurement of the Martel's voltages in the PCAL lab to calculate the ADC conversion factor, which is included on the document.
After the Martel measurement, the procedure walks us through the steps required to make a series of plots while the Working Standard(PS4) is in the Transmitter Module. These plots are shown in WS_at3_TX.png.
Note: It was the second measurement WS in the Outer beam in the TX module, that our laser stopped working. We DID notice this when it happened, and we got better data the second try. But the laser has already been turned off and the TX enclosure had already been opened.
Next steps include: The WS in the Receiver Module, These plots are shown in WS_at_RX.png.
NOTE: The same thing happened again at the start of these 3 measurements as well.
Followed by TX_RX.png which are plots of the Tranmitter module and the receiver module operation without the WS in the beam path at all.
The last picture is of the Beam spot after we had finished the measurement.
All of this data is then used to generate LHO_ENDX_PD_ReportV2.pdf which is attached, and a work in progress in the form of a living document.
Special Notes: Line 10 in the pcal_params.py needs to be changed from:
PCALPARAMS['WHG'] = 0.916985 # PS4_PS5 as of 2023/04/18
To:
PCALPARAMS['WHG'] = 0.9159 #PS4_PS5 as of 2023-08-22
This change would reflect the changes we have observed in the measurements of PS4_PS5 responsivity ratio measurements taken in the lab which affect the plots of Rx Calibration in sections 14 and 22 of the LHO_ENDX_PD_ReportV2.pdf.
Investigations have shown that PS4 has changed but not PS5 OR Rx Calibration. There may also be another location where this change needs to be made to accuraetely depict the changes found in PS4.
All data and Analysis has been commited to the SVN.
https://svn.ligo.caltech.edu/svn/aligocalibration/trunk/Projects/PhotonCalibrator/measurements/LHO_ENDX/tD20230926/
PCAL Lab Responsivity Ratio Measurement:
A WSH/GSHL (PS4/PS5)FrontBack Responsivity Ratio Measurement was ran, analyzed, and pushed to the SVN.
The analysis of this measurement produces 4 PDF files which we use to vet the data for problems.
raw_voltages.pdf
avg_voltages.pdf
raw_ratios.pdf
avg_ratios.pdf
All data and Analysis has been commited to the SVN.
https://svn.ligo.caltech.edu/svn/aligocalibration/trunk/Projects/PhotonCalibrator/measurements/LabData/PS4_PS5/
BackFront configuration PS4/PS5 Responsivity Ratio.
PCAL Lab Responsivity Ratio Measurement:
A WSH/GSHL (PS4/PS5)BF Responsivity Ratio measurement was ran, analyzed, and pushed to the SVN.
The analysis of this measurement produces 4 PDF files which we use to vet the data for problems.
BFraw_voltages.pdf
BFavg_voltages.pdf
BFraw_ratios.pdf
BFavg_ratios.pdf
PS4PS5_AlphaTrends .PDF shows a trand of lab Responsivity Ratio Measurements done with PS4 over PS5.
This adventure has been brought to you by Rick Savage & Tony Sanchez.
TITLE: 11/02 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 3mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.23 μm/s
QUICK SUMMARY: Locked for 15 hours, violins still going down.
TITLE: 11/02 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: We are Observing and have been Locked for 7hours 15mins. Quiet night overall.
LOG:
23:00UTC Relocking
23:15 While at PREP_ASC_FOR_FULL_IFO and ENGAGE_ASC_FOR_FULL_IFO, got lots of IFO_OUT alarms (first seen when locking Oct 25th)
23:47 NOMINAL_LOW_NOISE
00:00 One node not ready - LOCKLOSS_SHUTTER_CHECK stuck in CHECK_SHUTTER (nominal is HIGH_ARM_POWER) (referenced 72784 to fix)
00:05 Observing
00:23 Started damping ITMY 5/6
- FM6, 8, 10 already enabled with gain set to 0
- I set gain to -0.025 in three increments
Observing at 159Mpc and have been Locked for almost four hours.
Closes FAMIS#26259, last checked 73653
** I'm looking back 10 days instead of 7 since the last check was completed on October 23rdUTC (my fault)
Corner Station Fans (attachment1)
All fans are looking normal and within range.
- MR_FAN5 2 has gotten slightly noisier since the 10/24 maintenance day but is still well within acceptable range.
Outbuilding Fans (attachment2)
All fans are looking normal and within range.
TITLE: 11/01 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Oli
SHIFT SUMMARY: Two lock losses and some commissioning time today. After a long bit of downtime for the IFO, it was recovered this morning, though violin modes were elevated. The lock was not long though and there might be some hints to the reason for the lock loss. Acquisition was straight forward. During commissioning time today we had another lock loss that doesn't appear to be caused by commissioning activities. We are powering up in the relocking process and haven't run into any major issues yet.
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 15:10 | FAC | Tyler | MidY | N | Find eric | 15:40 |
| 16:11 | FAC | Karen | Optics lab, vap prep | N | Tech clean, sweep | 16:35 |
| 16:18 | TCS | Erik | EY | N | HWS checks | 16:50 |
| 16:18 | FAC | Kim | MidX | N | Tech clean | 17:42 |
| 16:35 | EE | Fil | MidY | N | Pickup chassis, bring to recieving | 17:52 |
| 16:35 | FAC | Karen | Wood shop, firepump room | N | Tech clean | 18:02 |
| 17:08 | FAC | Tyler | MidY, EY | N | Site walkthrough | 18:08 |
| 17:48 | FAC | Kim | H2 | N | Tech clean | 18:05 |
| 18:25 | FAC | Tyler, Eric | EndX | N | Change airhandler flow | 19:15 |
| 19:15 | PEM | Robert | LVEA | n | Setup for measurements | 19:38 |
| 19:15 | ISC | Jenne | CR | n | BS coil switching | 19:35 |
| 19:43 | CDS | Erik | EY | n | Check out h1hwsey | 20:45 |
| 19:46 | ISC | Sheila | CR | n | ESD bias test | 20:16 |
| 19:47 | PEM | Robert | CR | n | Acoustic inj | 20:47 |
| 21:12 | PEM | Robert | EX | n | Pickup speaker | 21:48 |
| 21:38 | FAC | Randy | Garb room | n | Look for C3 covers | 21:48 |
| 21:40 | ISC | Keita | LVEA | n | OM2 heater adjustment | 21:50 |
| 21:56 | PEM | Robert | LVEA, CER | n | Setup inj | 22:56 |
TITLE: 11/01 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 1mph Gusts, 0mph 5min avg
Primary useism: 0.04 μm/s
Secondary useism: 0.21 μm/s
QUICK SUMMARY:
Looks like the detector lost lock a bit ago and is relocking. It couldn't find IR but TJ just tapped it a couple times and it caught.
23:47 NOMINAL_LOW_NOISE
11/02 00:00UTC LOCKLOSS_SHUTTER_CHECK was stuck in CHECK_SHUTTER (nominally HIGH_ARM_POWER) and gave the user message "USERMSG 0: run shutter check, then manually take to low power". I referenced my alog 72784 to fix:
00:05 Into Observing
I ran the script attached to alog 73869 to switch the BS M2 coil driver to the high noise state, and it worked and we didn't lose lock! Hooray. Transitioning back to the low noise state also worked! Hooray!
The times that I tried the switching were very near the beginning of the lock, so the IFO was changing rapidly enough that it was challenging to actually see any subtle effects from this. We lost lock during our commissioning time before I was able to come back to this, so hopefully soon we'll be able to give it a try with a thermalized IFO.
Seemed quick. Even though we were in commissioning, no activity at the time seems to account for the lock loss just yet.
Following up on the nonstationary noise (and DARM bicoherence) reported in 73662, which motivated the addition of a DARM boost/resG in 73740 (still in place, but hasn't reduced the nonstationarity).
I increased the EX ESD bias from it's normal value of +126V to +409V, and compensated with the gain in L3 L2L drivealign, the settings I used resulted in a DARM gain 1.2% lower than the nominal. In the first test, there were many glitches during the high bias time, we repeated the test a second time and didn't see glitches the second time. A comparison of spectra at these times doesn't show much difference other than the normal breathing of the low frequency DARM spectra. An inital look at spectragrams also doesn't show anything obvious.
quiet times:
commands I used:
ezca['SUS-ETMX_L3_DRIVEALIGN_L2L_TRAMP'] = 60
ezca['SUS-ETMX_L3_LOCK_BIAS_TRAMP'] = 60
#go to positive half bias
ezca['SUS-ETMX_L3_DRIVEALIGN_L2L_GAIN'] = 74.982 #71.892
ezca['SUS-ETMX_L3_LOCK_BIAS_GAIN'] = 2
#go to positive full bias
ezca['SUS-ETMX_L3_DRIVEALIGN_L2L_GAIN'] = 48.6366 #47.22
ezca['SUS-ETMX_L3_LOCK_BIAS_GAIN'] = 2.85
#go to nominal settings (+126V bias) Nov 2023
ezca['SUS-ETMX_L3_DRIVEALIGN_L2L_GAIN'] = 184.65
ezca['SUS-ETMX_L3_LOCK_BIAS_GAIN'] = 1
Here's a first analysis of the effetc oof the ESD bias.
The attached PSD confirms that, in this particular time, a bias of 409V give better DARM below 30 Hz, but worse DARM above 30Hz, compared to a bias of 126V
To see if this is chance, one can look at a spectrogram. Even better, at a spectrogram whitened with the median spectrum of DARM when the bias is at 409V. Two observations:
So my conclusion would be that the worse spectrum above 30 Hz when the bias is 409V is real, but at the same time the non-stationarity is larger when the bias is at 126V.
One can look at the bicoherence of DARM with itself at 126V and at 409V. There is a striking difference: at 126V one sees the usual bicoherence of noise between 15 and 25 Hz with low frequency DARM, while at 409V this bicoherence is gone.
In conclusion, we should do a couple of repeated swithing tests to be sure, but for now: a bias of 409V seems to worsen slightly the noise above 30 Hz, but it reduces the non-stationary noise below 30 Hz.
The observation that the non-staationarity changes with the bias is interesting. It seems to indicate that the non-linearity that modulates high freqeuncy noise with low frequency motion is in the DARM actuation, namely in the ESD.
It is also consistent with the observation that tthe non-stationariity does not depend on the DARM low frequency gain, as shown by the boost experiment. This is because incrreasing the DARM low frequency gain changes the error signal, but the cntrol signal is almost exactly the same.
We should try to reduce the low frequency (<4 Hz) control signal to the ESD by reworking the DARM offloading to L2 and upper stages.
I've done some injections today but I'll alog about that later.
After I was done with the injections, the breakout board was removed from the back of the OM2 heater driver and the Beckhoff cable was fully connected again. This happened at around 21:40 UTC today.
Yesterday during the maintenance, Fernando and Daniel changed the Beckhoff configuration such that the Beckhoff terminal won't switch between thermistor 1 and thermistor 2 (alog 73886). Now it's only reading thermistor 1 (cold one) w/o switching. Thermistor 2 (hot one) is not read out. Detchar, please see if you can see the comb.
Good news- no sign of the 1.66 Hz comb in Fscan daily spectra after Nov 1 (checked the 2nd-4th).
Further change: Beckhoff was rewired to use 2 separate terminals to measure the 2 thermistors.
J. Kissel (with help/advice from J. Driggers, S. Dwyer, J. Oberling) WP 11493 Why am I doing this PRIMER We're yak-shaving again; this time in support of better understanding what the eventual frequency / phase noise will be incoming from a PSL pick-off (at the point of RefCav reflection much like SQZ or ALS fiber pickoffs, see D1300348) for the current design of SPI L (see G2301177; the longitudinal, or "L" DOF of future seismic platform interferemeters "SPI"), corroborating current estimates shown in SWG:12112. The idea is to establish a "[Hz / V]" linear calibration for the PMC length control PZT, such that once established, we can measure the PSL "frequency noise" in various configurations of the detector (e.g. "only RefCav locked," "only IMC + RefCav," "full IFO CARM + IMC + RefCav"). Critically, for the planned frequency-band in which we plan to use SPI L for ISI platform control -- we care about "frequency noise" delivered on the fiber in the 0.01 to 5 Hz region; this *not* a frequency region typically plotted -- from 10 to 10000 Hz, since that's where the main interferometer (IFO), or frequency-dependent squeezer (FDS or SQZ), or arm length stabilization (ALS), systems care about frequency noise (see e.g. chapter of 3 of P1800022 or chapter 6 of P2200287) -- so it's been a struggle to find plot of this noise in the frequency band we need. Notice that I put "frequency noise" in quotes. This is because, for a single fabry perot cavity (be it linear, triangular, or bowtie) on resonance, 1 lambda0 1. lambda0 ---- df = ------- df = ---- dL = ------- dphi f0 c L0 2*pi*L0 where df = actual frequency noise of the laser, whose frequency is f0 lambda0 = wavelength of the laser c = speed of light = lambda0 * f0 dL = actual cavity length / acoustic noise L0 = the roundtrip length of the cavity dphi = phase noise of the laser which means that (a) all of these noises can be re-cast as version of each other if you know the laser wavelength and cavity length, and (b) that *sources* of these noise can all get confused together when you're just measuring one thing, e.g. the typical error signal -- the reflected light from the cavity. This fact, (b), is why I but "frequency noise" in quotes, or call it *effective* frequency noise. Now -- the PMC itself is a cavity that is in-air, relatively short, and relatively low finesse. As such, the PSL PMC will never measure the *actual* full IFO CARM + IMC + RefCav *actual* frequency noise, since that frequency (or length, or phase) noise is established with the full 4 km arm cavities, suspended on a BSC+ISI+QUAD system in vacuum. What we'll end up measuring with the PMC are the *other* noises which are "artifacts" of the measurement -- cavity length noise (sometimes called "acoustic" noise), shot noise of the PMC REFL sensor, etc. BUT -- this "frequency noise" is still relevant because it serves as an upper limit on the *effective* frequency noise on the PSL table. Further, one of the open questions for the SPI L is how we'll use it operationally; only when the full IFO is locked or "at 'all' times, or at least when the PMC + ISS + FSS is locked"? So, we also want to see if the PMC "frequency noise" measures anything different in the three configurations of the IFO -- and again, we want this information between 0.01 to 5 Hz. Eventually, we'll *also* use the FDS system -- which similarly receives fiber-delivered PSL light -- to *then* establish how much *additional* effective frequency noise is added by the fiber as it traverses across the LVEA via the standard LIGO fiber delivery system. OK. That sets the scene, now on to the actual attempt at creating the linear "[Hz/V]" calibration for the PSL PMC PZT. Measurement PRIMER The principle of the measurement is relatively standard: (0) Understand the *modeled* cavity parameters, including length of the cavity, and frequency "light houses" and a function of cavity length -- :: the HG00 modes (the mode at which the cavity is designed to resonate, and thus cause the highest signal on the transmission PD) :: the distance between the HG00 models -- the free-spectral-range :: and the frequencies of other, non-HG00 modes in relation to the HG00 mode, or :: if there are Pound-Drever-Hall control-side bands on the HG00 carrier light. (1) With the cavity unlocked, drive the length of the cavity using the length actuator in a smooth linear ramp and watch some photodiode in transmission as the cavity flashes through its various resonant modes. Ensure that ramp pushes the cavity length through at least one full free-spectral range. This ramp through the length of the cavity is often called a cavity "sweep," and sometimes also called a "mode scan." Typically, the drive signal is a triangular or saw-tooth wave-form, such that one gets a repeated linear ramp. (2) While doing so, record the time series of both the driver value -- in this case a PZT voltage, [V] -- and the transmitted light. The units of the transmitted light actually don't matter, but it's always nice to have a timeseries plotted in physical units, so if you can calibrate the PD into Watts of transmitted power [W]. With the repeated ramp, you can even gather statistics as the cavity sweeps through the same FSR multiple times. We expect to see the HG00 "carrier" peak to have the highest transmission; and thus these are the standard candle "goal posts" that are the most obvious feature. (3) Then, map the frequencies of "peaks" in the transmitted light time series to a frequency vector, by assigning the modeled frequency of each feature (the two HG00, any clearly identified control side bands, any clearly identified non-HG00 modes, etc. from step 0 ). (4) Now, map the frequency vector on to the PZT voltage vector to obtain a frequency as a function of voltage. Here's the kicker: a PZT is a non-linear actuator. So, in order to obtain a *linear* calibration, in [Hz/V], one needs to fit the function from (4) to a polynomial (depending on the number of modeled and identified features in the "cavity sweep," and the personal preference of the data analyst, this can be quadratic, cubic, quartic, etc.) and then take the linear coefficient of that fit as the "[Hz/V]" for a known, typical value for the operating voltage of the PZT. Another point -- because the PZT is non-linear: (a) The answer may depend on the maximum and minimum amplitude of the ramp / sweep, (b) The answer may depend on the rate (or frequency) at which the ramp repeats (i.e. the sweep frequency). (c) One may get a different answer from a ramp with a positive slope vs. a ramp with a negative slope. (d) It has hysteresis; even though one might request the same position by requesting the same voltage, the physical position where the PZT lands may be slightly different each time your request the same voltage, or said differently, there's no guarantee that a requested triangle wave with fixed amplitude will push the cavity to the same starting length on each cycle Also, because there's no a priori clear map of HG00 mode to voltage ahead of time, there's no guarantee that the cavity's free-spectral range is lined up with 0V, i.e. no guarantee that a ramp from +7V to -7V drive will *get* you two HG00 modes and one FSR. It's these additional points, the kicker, and step (3) that I hadn't remembered, and/or didn't re-appreciate before I got started. Ah well. Hopefully these things can be done offline. Measurement Technique 2023-10-31_MeasurePMCSweep_Notes.txt are more detailed notes of the "procedure," but the summary of the specifics: - With the IFO unlocked, the IMC unlocked, the FSS and ISS OFF, and the PMC unlocked, - I used the user-controlled excitation "PSL-PMC_ALIGNRAMP" that feeds into the H1:PSL-PMC_TF_IN filterbank in order to drive a triangle wave (i.e. successive linear ramps, one positive sloped and one negative sloped) into the PMC's PZT - In order :: to combat the suspicions of non-linearity, and :: because we didn't know what triangle wave frequency would be best as a compromise between "much less than the PMC cavity pole," and "faster than we expect the free-running PSL alignment, intensity, and frequency to drift" I recorded 6 different measurements with two amplitudes and three ramp rates (triangle wave frequency; time spacing between voltage maximums): H1:PSL-PMC_ALIGNRAMP _FREQ [Hz] _MIN [V] _MAX [V] Trial 1 0.5 -5.0 +5.0 Trial 2 1.0 -5.0 +5.0 Trial 3 10. -5.0 +5.0 Trial 4 0.1 -7.0 +7.0 Trial 5 0.5 -7.0 +7.0 Trial 6 10. -7.0 +7.0 I also show a screenshot of the three FSS, ISS, and PMC MEDM screens, with highlights of what to click to get started in the above configuration after the operator holds the IFO ISC_LOCK guardian state in DOWN, and the IMC_LOCK guardian in OFFLINE. Further, I show a trend of the relevant channels during the the whol series of measurements. Since none of the relevant fast channels are stored in the frames (namely, H1:PSL-PMC_TF_IN_IN1 [the ramp] H1:PSL-PWR_PMC_TRANS_IN1 [the PMC trans PD]), I captured the time series of the ramps using the "triggered time response" feature of DTT. These templates live in /ligo/home/jeffrey.kissel/2023-10-31 2023-10-31_1521UTC_H1PSL_PMC_TRANS_pm5Volts_0p5Hzramp.xml 2023-10-31_1521UTC_H1PSL_PMC_TRANS_pm5Volts_10Hzramp.xml 2023-10-31_1521UTC_H1PSL_PMC_TRANS_pm5Volts_1Hzramp.xml 2023-10-31_1521UTC_H1PSL_PMC_TRANS_pm7Volts_0p1Hzramp.xml 2023-10-31_1521UTC_H1PSL_PMC_TRANS_pm7Volts_0p5Hzramp.xml 2023-10-31_1521UTC_H1PSL_PMC_TRANS_pm7Volts_10Hzramp.xml where the file name indicates which amplitude and ramp rate. I then exported these timeseries and plotted the results in matlab, see first attachment, 2023-10-31_1521UTC_H1PSL_PMC_rawData.pdf. The top panel is the PZT voltage triangle wave with the wave maxima highlighted in red, and minima highlighted in green; each traverse from red to green is a "negative slope" ramp, and the traverse from green to red is a "positive slope" ramp. The bottom panel shows the PMC TRANS PD during the triangle wave, where times of maxima and minima of the ramp's triangle wave are highlighted. Don't squint too hard -- I make better plots shown in the "Results" section below. First Results After a ton of timeseries parsing, and array index juggling, I took the above raw data and stacked the 6 trials into groups -- every time a negative slope ramp was traversed :: 2023-10-31_1521UTC_H1PSL_PMC_negSlope.pdf, and every time a positive slope ramp was traversed :: 2023-10-31_1521UTC_H1PSL_PMC_posSlope.pdf. For each page, which is each trial, Top panel :: I show every PZT voltage ramp stacked on top of each other. These all look like a very boring single line, but this indicates that I've done my timeseries stacking and index juggling correctly. Bottom panel :: I show the PMC TRANS PD for each of these ramps. These are only synchronized in time by the MAX and MIN requested ramp voltage, and show some spread. *This* is indicative that the PZT is an imperfect actuator that has hysteresis, as discussed above under (d). First Impressions from these Results (I) Positive slope ramps show clear non-linearity around the HG00 mode, especially for the 0.1 Hz and 0.5 Hz data at both excitation amplitudes. So, with this in mind, only the negative slope data is really useful. (II) From the negative slope ramps are much cleaner, and indeed it looks like the from +7 to -7 [V] ramps were enough voltage to traverse 2 HG00 modes. (III) Given the alignment of the HG00 modes, we can get the most use out of the +7 to -7 [V] 0.5 [Hz] ramp rate data, but maybe also the +5 to -5 [V] 10 [Hz] ramp rate data. (IV) What's ODD is that we don't seem to see evidence for the 35.5 MHz sidebands that are imposed on the PSL light incident on the PMC. We would expect, visually, that the sidebands would be symmertric about the HG00. We see no symmetric features. Maybe the modulation index is really low? Dunno. (V) We guess that everything seen in this "mode scan" is higher order modes. Next Steps From T0900616: PMC Parameter Modeled Value Measured Value L (roundtrip) 2.02 m 2.02 m +/- 0.008 m) Finesse 124.708 (124.536 +/- 5.091) 120.44 +/- 0.6 FWHM 1.19 MHz (1.195 MHz +/- 0.0488 MHz) 1.19 MHz +/- 0.06 MHz Free Spectral Range 148.532 MHz +/- 0.585 MHz 148.32 MHz +/- 0.742 MHz So we at least know two points on the voltage to frequency map (ie step 3 from above). But, because we know the PZT in nonlinear in so many different ways, we need to make sure we identify some of the other non-HG00 resonances. We did *not* record camera images during this sweep, so doing so will have to rely on guesses from modeling the cavity (or maybe there's some other characterization documentation DCC that we can find). Then we can do step 3 and 4. I note that when we eventually get to the "linearization" step, we need to know the typical operating voltage. The 2023-10-31_H1PSL_PMC_PZT_Voltage_TypicalOperatingVoltage.png attachment shows the typical operating voltage is ~0.77 [V] -- in the same voltage units as the user-defined ramp. Note -- this voltage is *not* the final voltage applied to the PZT. We have to do some further research, but I think this voltage and the ramp voltage units are DAC voltage (which I presume has the standard LIGO general standards DAC range of +/- 10 [V_peak] or 20 [V_pp]). The MEDM screen indicates that there's a -24 dB gain drop, and then I suspect that the voltage is amplified in analog by somehting like a D060283 board. We'll see.
The raw .txt file exported data lives in
/ligo/svncommon/SeiSVN/seismic/Common/SPI/Results/
2023-10-31_1521UTC_H1PSL_PMC_pm5Volts_0p5Hzramp_ts.txt
2023-10-31_1521UTC_H1PSL_PMC_pm5Volts_10Hzramp_ts.txt
2023-10-31_1521UTC_H1PSL_PMC_pm5Volts_1Hzramp_ts.txt
2023-10-31_1521UTC_H1PSL_PMC_pm7Volts_0p1Hzramp_ts.txt
2023-10-31_1521UTC_H1PSL_PMC_pm7Volts_0p5Hzramp_ts.txt
2023-10-31_1521UTC_H1PSL_PMC_pm7Volts_10Hzramp_ts.txt
The script to process the data and get it at least to a post-processed form shown in the plots in the main entry lives here:
/ligo/svncommon/SeiSVN/seismic/Common/SPI/Scripts/
process_PMC_sweep_20231031.m
To further model the expected frequency separation of higher order modes in the PMC mode scan, I've found a few more resources: In addition to the aLIGO PMC Design Documentation, T0900616, circa 2017 Liu Jian and Kentaro Mogushi worked with Rick Savage and Peter King to improve the design of the PMC -- namely to change the design from gluing the mirrors on the rigid body of the PMC to bolting the mirrors to the body. The best presentation I can find on that upgrade is G1701481. Some loss measurements were made of the glued PMCs, and the documentation of those measurements contains some juicy design details of the PMC -- see T1600204. During that design process, as Liu was learning about the details of the PMC, he put together a tech note, E1700340 that hints at further details of the *new* PMC design, which is now installed in the H1 PSL (though I can't find an explicit aLOG documenting when exactly).
Sheila and I used this data to get a rough calibration of the PZT HV channel: 0.0236 V/MHz, as in alog 81385.
Since last weekend ITMY mode05/06 were rung up and the nominal settings were not able to damp them. During that time the microseism and ground motion was higher than nominal, also LVEA temperature was slightly elevated. On Monday I found a new setting which worked all day and during evening shift (as confirmed by Ryan C). However it stopped working this morning. Hence, I again tried the nominal settings and it seems to be working for now. Given below are the details,
Settings working today (Nov 01 2023): FM6 + FM8 + FM10 Gain -0.01 (will slightly ramp it up later, although we lost lock while I was writing this alog, nevertheless I will try again) - see plot attached.
Settings which seems to be working on Monday (Oct 30 2023): FM6 + FM10 Gain 0.01
I will keep a watch on them before committing it in the lscparams.
This afternoon during the 2nd lock of the day I've had continued success damping ITMY mode5/6 with FM6+FM8+FM10, G= -0.025 (I upped the gain in 3 steps).
It may have been the earthquake that rang up the violins but there was a large gap in the DCPD data from us being down. But during a time that we were in IA the DCPD signals were larger (by almost a factor of 2, DCPD Min/Max difference of 25k vs 40k) than what they usually are.
We were only locked for 1:08, lockloss at 19:29UTC. ITMX was the first suspension to saturate right before the LL and there was a 500Hz oscillation in LSC-DARM which was probably the violin modes.
Recovered NLN at 18:22uTC, back into observing from 18:42 till 19:14
I'm beginning to think that this may have been caused by the SOFT Yaw loops. The quads see some type of deflection in their master out before the LSC DARM channel sees anything, and I tracked it down to SOFT Y so far. I'll do some more digging on this tomorrow and see if I can keep following this thread.
TJ, Camilla. WP #11483.
Uninstalled the "new" S&K HWS laser (TSOP M1900163) from the ALS table, stored it in it's case in the LVEA TCS cabinets. Removed fiber and fiber launcher. This was installed in 62089.
Reinstalled the "old" diode source M530F2 (eye safe). Using M92L02 20um multi-mode fiber and original D1800125 fiber launcher. Reduced length of the tube of D1800125 fiber launcher as we thought we need to bring the F=125mm lens closer to the launcher.
Realigned the path to get a retro-reflected beam off ETMX and checked this by mis-aligning ETMX. Took new references on EX, and ITMs at 00:08UTC.
Photos before and after attached. Decision made to swap back to original source in T2300336. Will update FRS 14310 with Aidan.
We are getting data, see attached, but the TOTAL_PIXEL_VALUE is changing as we thermalize, which we don't want. There is some clipping happening which we can work to minimize on table.
TJ and I repeated the laser swap EY 73878 but struggled to get an unclipped beam. We went back to EX ~3pm Oct 31st to understand if the EX beam was clipping somewhere to get the bad HWS data above. We saw the beam was clipping on the edges of BS2 and M2 and then after clipping L1 (1" optic), the beam appears round again. Layout D1800270.
In 42171 and T1000717 there is mode matching solutions of this path showing the beam should remain under 10mm diameter until the Transmon telescope. We don't remember this ever being the case. The beam starts around 10mm and then diverges to >1" after L3, rather than converging.
We think we should revisit this mode matching to understand what our input optics should be and check all the lenses are correct (they are labeled as in D1800270).