Added 300 mL H2O to the H1 PSL crystal chiller. There were no fault alerts on either chiller. Both canister filters appear clear.
Gerardo, Chandra Adjusted the potentiometers of the following pirani gauges (3-8 turns in CW direction) to calibrate pressure reading to ~5e-4 Torr. PT-100 PT-110 PT-114 PT-134 PT-210
I replaced the razor blade beam dump that was being used to dump the p-pol beam (rejected beam in the MCR path) with two steering mirrors and a Kentek Trap-it.
The p-pol beam will be a minimum of 1.2W at 50W input power, and about 0.8W at 30W input power.
Removed: IO_MCR_BD6 razor blade dump
Added: steering mirrors IO_MCR_M14 and IO_MCR_M15:
Added: IO_MCR_BD6 high-power beam dump
With this upgrade completed, I've modified the IOT2L layout drawing to include the new components, and updated the version to D1300357-v3.
Attached:
15 days trend data for the 3 IFO storage containers attached.
New today is the the SEI_CONF Guardian node that will manage all of the other configuration nodes that we have made the past few weeks. This will hopefully make it much easier to choose a configuration for all of SEI. Sensor Correction for the entire SEI can be turned OFF from here, and then be brought back, of course.
The states and their names are very likely to change in the near future. So keep an eye out for updates, and we will also try to keep documentation up to date.
I also move the GUARD_OVERVIEW.adl around a bit since it was getting crowded in spots.
I changed the Blend_PAGE_MAIN.adl to include all of the config nodes and removed the SC ON/OFF switches. I have also included a guide to help choose states, but take it lightly because I'm sure it will change again soon. The right corner shows if the MATCH bank gains are 1 (green) to allow for sensor correction (Enabled) in that chamber.
Modified the PUM Chassis by connecting pin 2 and pin 18 on the binary input DB37 connector. This was to address the issue of the binary RMS reset not working. See alog 27633. We confirmed this modification was already done at EY. Next Tuesday we will need to verify the ITM units have this modification.
We also confirmed that R111 had the correct value of 100K on all four channels.
David.M, Jenne.D, Jeff.B
This morning we set up 6 L4Cs in the 'beer garden' area of the LVEA. They are positioned close to the STS-2 there, with three on the concrete and three on the linoleum surface (see attached photo). This should enable us to determine the effect of the linoleum coating on the L4C output spectrum.
I've attached a screenshot from Diagnostic Test Tools plotting the power spectrum of all 30 L4C channels. Only the 7th L4C channel (H1:NGN-CS_L4C_Z_7_OUT) shows a seismic response. The other channels only show ADC noise, however there should be 6 sensors connected. Early tomorrow morning I'll perform some checks to try and diagnose where the problem is.
I looked at last night's increase power lockloss, and can see that the lock broke right when the IMC common mode board gain slider moved. (plot attached). For now I've changed the gain adjust function in the IMC guardian to make 2dB steps instead of 1dB.
J. Kissel Charge measurements are complete for this week. As predicted last week, we're now ready to start the trial period of regular requested ESD bias voltage flipping. I'll work on the script later today after maintenance has died down.
Ross, Terra, Carl, Tega, Jim, Dave, Matt, Ed, Daniel.
In this alog we report on some of the simulink model changes made in relation to PI work carried out at LHO during the period spanning April to 10th of June.
We currently have two possible error signals for PI damping: the trans-QPDs and the OMC DCPD signals. The trans-QPD signal is more readily available to drive the ETMs, whereas the OMC DCPD signal is more readily available to the ITMs. Since the OMC DCPD signal has a better SNR compared to the trans-QPDs, it can be used to monitor the modes lines before they ring up. The main limitation of the OMC error signal lies with fact that its fidelity may change with better alignment of the X- and Y-arms.
There are currently three different strategies for PI damping in the suspi models, all of which have been implemented in the end station suspi models (h1susetmxpi and h1susetmypi).
The first takes data from the trans-QPDs, processes the data using a band-pass filter and a PLL (iWave) and sends the output to the ESD driver. This is the top-left block in the suspi models called "ETMX_PI_DAMP". It comprises 8 modes blocks each one of which contains an IWave PLL block for dynamic line tracking. The down-conversion block immediately below the trans-QPD mode block provides the means for sending the trans-QPD signals to the corner station (the data transfer for this has not been implemented yet).
We have also adapted the iWave line tracker to PI damping. The simulink model shown below provides the means for the user to enter a threshold value above which the we maximally damp and below which we damp proportionally. There is also a modified IWAVE_AMPCTRL block (in userapps/sys/common/models/IWAVE.mdl) that damps the mode to a manageable level that is again specified by the user so that we can continuously monitor the mode power in the error signal. This block is not currently deployed but should be amongst several variations of PI damping to be tested in the future in order to down-select to the best configuration.
The computation block with 4 outputs is only used in the corner station pi model (h1susitmpi), where we have control of the four ESD quadrants.
The most recent test of this system shows that updating the parameters (SINGAIN, COSGAIN, frequency) of the remote oscillator introduced considerable noise. A short term solution---aimed at demonstrating the viability of the system---is the reduction of the rate at which we update the oscillators. This is the role of the sample-and-hold block in the monitor block below. Whilst the system has been shown to work successfully with this modification, further work is required to realise the full potential of this scheme. For example, some of the amplitude noise in the I and Q values can be eliminated by the constraining them with the tracked amplitude from iWave. This would be particularly useful should the I and Q values suffer the same distortion from the update of the fixed oscillators frequency in the omcpi model (h1omcpi).
To get the signal parameters (I, Q, frequency), we use a modified version of the iWave block that incorporates a fixed phase oscillator. Here, the oscillator serves two main functions: extraction of the I and Q values and providing a dynamic band-pass filter around the mode line of interest.
At the end station, we have companion oscillators whose parameters (SINGAIN, COSGAIN, frequency) we update via EPICs for proof of concept. We note that the first mode uses a slightly different architecture. This was part of the debug process intended to test whether an indirect update of the I and Q values of the oscillators reduces the noise at the output. So far this does not seem to be the case. Although this system currently uses EPICs, this does not have to be the case. The low bandwidth nature of the update means it can be readily added to the existing PI channel for moving the data between the corner and the end stations.
We have also adopted the MIN_MAX_CALC CDS library part for monitoring power build-up of PI modes over a wide range of frequencies and should be deployed shortly. The monitor block resides in userapps/sus/common/PI_MASTER.mdl.
Presently, there is no mechanism for dealing with multiple lines that are separated by less than 1Hz, so we have adapted iWave to function as a user configurable static and dynamic notch filter. These blocks reside in userapps/sys/common/IWAVE.mdl. The idea is to place at least one notch filter in series with iWave in the PI mode block and have it operate in static mode by default. Although preliminary work done on the test stand shows that this does not impact on the performance of the mode block in the absence of any nearby lines and stabilises the behaviour of the iWave PLL in their presence, further work is required to fully stress test this system against wandering lines that cross one another in the frequency domain before deployment.
Evan, Sheila
Earlier today we had several locklosses while trying to engage the soft loops which may have been because SRM was uncontrolled and the POP90 power increased.
We searched for a better error signal for a while tonight, we looked at dither SRM and demodulating DARM (low SNR), demodulating SRCL (good signal but a large offset), POPX, some REFL WFS.
Finally we decided to try AS45I, where we had a reasonable signal with a zero crossing that gave us good sideband buildups for both pit and yaw. For pit we are using 1*ASA45I +0.76*ASB45I, while for yaw we are using ASA45I+ASB45I. The guardian is engaging these with a gain of -300 in SRC_ASC, which has worked once. It allowed us to turn on the soft loops and corrected the sideband buildups.
Overall violin modes situation improved by a little more than an order of magnitude. Currently the modes with highest magnitudes are 501.092 (IX Mode3, lost lock before I could find the damp setting), 501.606 (IY, damp setting found but didn't have much time to damp), and 507.194 (EX, no damp setting yet).
Modes with newly discovered damp settings:
505.71 & 505.707: EX Mode3: FM1, FM2, FM4, FM5 +20 gain seems to work for both lines. After I noticed the filter stopped damping I turned off Mode 3 gain and turned on Mode2 gain based on Sheila's configuration here. This configuration will damp the modes even further. We lost lock before I could confirm that it won't blow either .71 or .707 up.
505.587: EX Mode1: FM1, FM4 +50 gain
507.159: EX Mode6:FM1, FM4 +gain (forgot to write down how much gain exactly. Probably no more than 100)
507.391: EX Mode8: FM1, FM4 +50 gain
500.05: IX Mode1: FM1, FM4, +50 gain. +100 gain will damp the mode but later will blow it up. +50 gain seems to have worked pretty well.
502.744: IX Mode8: FM1, FM3, FM4, +10 gain (BP, +60deg, 100dB)
502.621: IX Mode7:FM1, FM4 +50 gain (BP, 240dB)
501.606: IY Mode1: FM1, FM2, FM4, +150 gain
All these information has been updated to the new violin mode table but haven't been implemented into the guardian.
Tonight I also confirmed all the filters that VIOLIN_MODE_DAMPING Guardian turns on (I didn't confirm the exact gain, but I did confirm the filter configuration and gain signs). They should be safe to turn on.
[Sheila, Jenne]
While looking at our locklosses today, Sheila noticed that we are using up way more DAC range than is appropriate for the SRM while we are locked using the 3f signals. Looking at a spectrum, it's all high frequency sensor noise.
I lowered the frequency of the cutoff from 300 Hz to 200 Hz. This eats 4 deg of phase at the 40 Hz UGF, so should be plenty fine according to an old OLG measurement Sheila found. We could / should improve this even more, but (a) it's better than it was before, (b) this is only really a problem while we're on our noisy 3f sensor, and (c) we don't want to get too much more crazy without taking a fresh loop measurement, which we don't want to spend commissioning time on right now.
Attached is a set of spectra showing the old SRM output (blue) and the new (red). Don't mind the bounce mode in the red spectrum - damping wasn't on yet during this measurement.
Today, H1 was primarily in the hands of commissioners working on high power. At the end of the shift, H1 was passed over to the SEI team so they could do BRS work (mainly because H1 was starting to break lock quite a bit); this happened as the wind gusts were approaching 40mph.
Guardian was updated (Violin & Bounce mode damping separated). I tried restarting nuc4 to show the updated ISC_LOCK Guardian, but had trouble with bringing it back up (the TV stayed OFF).
Day's Activities
0945 - 1000 hrs local -> To and from Y-mid Opened check-valve bypass valve, opened LLCV bypass valve 1/2 turn -> LN2 at exhaust after 1 minute 10 seconds -> Returned valves to as found Next manual overfill to be Wednesday, June 15th.
Group Status:
Maintenance:
Outreach:
respit from outreach visits. School group on Fri.
On-Off-On-Off-On.... PT100A back and forth across 5x10-3?
It does not appear to be the interlock. It is still forced on in Beckhoff, and trending it (attached) shows no change while the cold cathode drops in and out.
Bounce damping setting was changed for IY and EX so they damp at all. Don't know why the old settings don't work.
For EX I just flipped the sign.
For IY, I rotated the phase by 210 degrees in effect and increased the gain significantly. Gain increase might be unnecessary but I leave it like that because it seems to work faster.
| Old | NEW | |
| EX |
Gain= -0.03 (negative), FM1 (+60dg), FM4 (bp) |
Gain=+0.03, FM1 (+60dg), FM4 (bp) |
| IY |
Gain= -0.03 (negative), FM1 (+60dg), FM3 (BP), FM6 (+30dg) negative sign + 60 deg + 30deg = -90 deg total |
Gain= -0.15 (negative), FM2 (-60dg), FM3 (BP) negative sign -60 deg = +120 deg total |
ISC_Lock was changed but not loaded.
Travis and I added a filter with negative gain to IY bounce (and EX) damping, so the gains for all bounce and roll damping filters will be positive from now on. The guardian is updated for this.
We found that in the state DARM offset, we got good damping for ETMX with a positive gain and -60 degrees of phase. This worked better than the settings that Keita described in the DARM offset state, but we also used Keita's settings sucsesfully in DHARD WFS.
TJ and I saw that with the Keita settings at DARM_OFFSET we were ringing up the bounce mode for ETMX. So, now in the Resonance state the bounce damping gets set to the Sheila settings. Unclear why this one needs a 120 deg phase change but no others do. Perhaps related to why the settings needed changing in the first place? When the bounce damping is first turned on in DHARD_WFS, it goes back to the Keita settings.
We have been using a bandpass filter for ETMX bounce mode damping that is designed for the ETMY bounce frequency. For the other optics we use a broad bandpass, so I've now set the gaurdian to do that for ETMX as well. The new settings are:
FM3 (broad BP), and FM8 (gain -1). These are in the guardian for now, to be used in all states, so I've commented out the filter change in RESONANCE.
When we have the notches in the ASC off, we can damp the bounce modes as seen in the DARM spectrum. However, even when they appear to be reduced in the DARM spectrum they seem to be increasing in the MICH ASC signals.
I copied quad bounce and roll notches to the BS ASC loops as well.
I looked at a 1 mHz spectrum of the bounce modes from last nights lock, and the frequencies are consistent with what we reported one year ago:
| ETMY | 9.731 Hz |
| ETMX | 9.776 Hz |
| ITMY | 9.831 Hz |
| ITMX | not rung up last night but should be 9.847 Hz |
The confusion about the ITMY mode frequency (corrected by Evan in the comment) was unfortunately propagated to our monitoring filters. I've corrected the monitor bandpass for ITMY and made all of the bandpasses 10 mHz wide (before they were all 30 mHz wide, meaning that the monitors could not distinguish between the ITMs).
Carl, Terra, Ross, Tega
Tonight we used the freshly installed LVLN ITMX ESD driver to ring up and damp two mechanical modes of ITMX, 15063 Hz and 15077 Hz.
After sorting out some phase settings, we drove the ITMX ESD close to saturation in a differential drumhead pattern. Negative gain rang up 15063 Hz. Flipping the gain sign to postive then damped this mode and rang up 15077 Hz. The amplitude plateaued as a the saturated drive signal approched a square wave. Figure below tracks amplitude of 15063 Hz and 15077 Hz (seen in OMC trans), with gain sign flip occuring around the 0.15 time mark.
Also attached is a spectrum of H1:OMC-PI_DCPD_64KHZ_A_DQ during no gain, negative gain, and positive gain times, i.e. on either side of the 0.15 time mark from the plot above.
At about 0.23 hours the gain was turned off and the mode rangdown. The fit to this ringdown indicates the mode has a Q factor of (omega_o)/(2alpha) = 1.2 million.
Settings: Power 1.9 W, DC bias 100k, butterworth BP filter, iWave bypassed, -60deg damp filter, damp gain 300,000.
Such a wonderful conclusion to the installation and commissioning of this system. Much thanks for the great support I received from all involved.
I suspect that 15077 Hz mode is an aliased 48923 Hz mechanical mode (64 - 15.077) kHz. The FEA gives an interesting mode at 48944 Hz (mode shape attached). Observation of the analog channel PSD on transmission is required to confirm if this is a case. The 15077 Hz mode is only 14 Hz above known 15063 Hz mode. I am not very familiar with linetracking filter but I assume that the two resonant lines 15063 HZ and 15077 Hz cannot be sufficiently separated and the signal with higher resonant peak will be eventuality phase-locked. It may be interesting to observe the transition from one mode to another. If this all is true you measured the Q-factor of one of the modes in the range were PI may also show up at higher circulating power than during O1. It looks to me that the 48923 Hz mode is very sensitive to off-center position of optical TEM00 (that's probably why can be seen on OMC) and can be used for centering of TEM00 on ITMs.
In the Q estimate 'f' was used in place of 'omega_o' introducing a 2 pi error. The corrected estimate of the Q factor of the 15077Hz mode is 7.4million.
ETMX Mode3: FM1, FM2, FM4, +10 gain (BP, -60deg, 100dB) seems to have worked quite well. No need to turn on a damping for 505.707 (which should be checked again with 0.0001 BW to see if it's really exists). 505.707 should be watched while damping 505.710 just in case.
The new violin mode table is being uplated slowly. The modes with Damp Setting column filled out are the one that's been sucessfully damped by the filter settings indicated in the table.
Jenne, Sheila
With the long lock tonight we got to do some more violin damping. I haven't updated the wiki or guardian.
At first we thought the largest mode was the 505.71 mode that Nutsinee logged about, and tried to damp it without sucsess using the settings she described. After getting a 0.002 Hz spectrum we could see that it was really 505.706Hz. (on the wiki there is a note asking if this mode really exists, looks like it does) I tried to damp this with ETMX MODE 2, which has a narrower filter, and in the last 5 minutes of the lock it looked like a phase of -60 and gain of 30 was working, with the 505.71 notch engaged, but we unlocked before we could be really sure it was working.
We damped the mode at 506.922 (ETMX mode5) using a phase of 0 degrees and a gain of 30. FM1 and FM4. (This is different from what is on the old wiki) the new wiki has this mode not damped.
We also damped a 500.062Hz mode (ITMX mode 1, 0 degrees gain +30, also different from the wiki) With higher gain and the same filter settings we rang the mode up.
The top panel shows the fundamental violin mode forest at the begining of the lock in blue, and the end in red. (There is a tiny improvement in 505.707Hz) The bottom panel shows the 0.002 Hz spectrum with cursors at 505.71 and 505.707Hz.
A negative gain for the 505.707 mode worked for me (although it's not clear whether it damped 505.707 or 505.710).
The setting I had seems to work on both 505.707 and 505.71.
