Last week Artem, Louis and I copied the new DARM filter into ITMX 76685. This week we got through the ETMX to ITMX ESD DARM transition but lost lock 12 seconds into the 20 second ITMX to ETMX transition. Plot attached. The EX signal looks much noisier than IX, I need to check all filters are correct.
Again, as seen last week 76637, although both ETM excitations ran fine, neither ITM excitation ran. It's the same guardian code and logs that it's sending the excitations but they are not seen on the H1:SUS-ITMY_L3_LOCK_BIAS_EXCMON and H1:SUS-ITMX_L3_DRIVEALIGN_L2L_EXCMON channels. Will get help from cds team.
J. Kissel ECRs E1700387 and E2400116 IIETs 9392 and 30863 WPs 11743 and 11797 With Dave's help we installed all of the front-end model changes described in LHO:76850, and I've followed up behind the model changes with upgrades to the MEDM screens to show the new infrastructure -- then filled in the infrastructure with EPICs values, settings, and filters. So, as of now, - As with the rest of the BSC Quads, Triples, Doubles, and HAM Triples, the the HAM doubles and single suspensions now are ll using a fully functional, sensible BLRMS system, calibrated into microns_RMS. - The thresholds have been generically set to 150 [um_RMS] for starters, since we have little history of understanding how the SUS behave in this 0.1 to 10 Hz band in a physically meaningful way. Please tune as you see fit if it's troublesome at this starting value. - The OMC ASC that's fed to the OMC SUS is now routed through the SUS-OMC_M1_LOCK_[LPY] bank, now has proper 2k to 16k AI filtering in all of those DOFs, and the LOCK_[LPY] output goes through the DRIVEALIGN matrix. - However, in an effort to make the least changes to the existing functionality, I've turned OFF the P2L and Y2L gains that were in place but not used for the time being. Will commission the drivealign gains again later, but for now the OSC ASC path should behave exactly as it had before, just with a proper 2k to 16kHz AI filter that should not impact the control stability. - The channels that are stored in the frames that record the history of the control signal have changed from H1:SUS-OMC_M1_ASC_[LTVRPY]_IN1_DQ to H1:SUS-OMC_M1_LOCK_[LPY]_IN1_DQ which includes H1:SUS-OMC_M1_ASC_[PY]_IN1_DQ which were (for some reason) in the GDS Broadcaster frame list, so they should now be mapped one-to-one to H1:SUS-OMC_M1_LOCK_[PY]_IN1_DQ. @DetChar -- Maybe these were used in the summary pages or something? - All model, MEDM, and filter changes have been committed to the userapps repo. - All new EPICs settings have been save in every impacted SUS's SDF system. More details to come tomorrow.
TITLE: 04/02 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
SEI_ENV state: SEISMON_ALERT
Wind: 29mph Gusts, 24mph 5min avg
Primary useism: 0.06 μm/s
Secondary useism: 0.20 μm/s
QUICK SUMMARY:
Currently relocking and in ENGAGE_ASC_FOR_FULL_IFO. Wind picking up and maxing out at 35mph
TITLE: 04/02 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
INCOMING OPERATOR: Oli
SHIFT SUMMARY:
LOG:
Jennie W, Camilla
We set up this measurement by mis-aligning ITMX, ITMY, BS, PRM and SRM during the maintenance period (after the PSL and IM suspensions came back up).
NB. PSL was at 2W but ISS was off.
Then we adjusted IM3 till we were centred in pitch and yaw on IM4 TRANS.
Then we searched each direction of IM1 and 2 that gave us clipping on IM4 TRAns - IE. THE nsum DROPPEED.
Then we went back to a point near clipping on IM 2 and mpved IM1 in that DOF to try and bring back the NSUM since we managed to do this for all DOFs (up and down in pitch and yaw)we assume no translation oft he beam improves NSUM so we are probably not clipping through OFI.
First image is starting sliders.
Second is sliders after we aligned IM3.
This is ndscope trends throughout our tests. By far the largest improvement to IM4 Trans was moving IM3 and nothing we did with IM1 or 2 really improved this.
Attached is how much we had to move IM2 from it's nominal (20257,-4177) before the IM4 TRANS NSUM started drop, at which piont we're asumming we are clipping the faraday. It's closet (1000-200 counts) from clipping in one direction in Yaw, but centered in Pit.
Translating the beam through the faraday in Pit and Yaw didn't give us any better NSUM values. As Jennie explains we did this by moving IM2 (Tried IM2 Pitch to 19057 and 22057 (nominal 20257) and Yaw to -5577 and -3477 (nominal -4177) and using IM1 to correcting back towards the center of the IM4_TRANS QPD.
We conulde clipping the faraday is not an issue.
This morning I tweaked up the PSL PMC alignment remotely using the picomotor-controlled mirrors with the ISS off. I was only able to get about 60mW of power increase out of the PMC, but I decreased reflected power by about 200mW, so perhaps there's some mode-matching that could be optimized in the future.
After that, I recalibrated the rotation stage using the following process:
Power in (W) | D | B (Minimum power angle) | C (Minimum power) | |
Old Values | 103.151 | 1.990 | -24.823 | 0.000 |
New Values | 102.287 | 1.990 | -24.825 |
0.000 |
J. Oberling, R. Crouch, T. Guidry
Since the last update we have tried a couple of things.
First, we attempted to align the FARO to the BSC2 chamber directly. We placed the FARO in the biergarten and shot the chamber-side door flanges. We used the SMR to sweep along the outside of the +X side of the +Y door flange, and the +Y side of the +X door flange. The shots were done as circles, which we could then place a point at circle center to represent the center of the door flange. The hope was we could then project lines to represent the X and Y axes, and use that to align to our origin using a Plane/Axis/Center Point alignment routine. I won't go into much detail, as it didn't work. We used this alignment to look at PSI-6 in the biergarten, and it was off by over 1cm; we then looked at LV-35 and that one was off by even more. I don't remember exact values as we didn't save screenshots since the devaiations were so large. Let's say that if these deviations were true, I'm not sure how we would have a functioning, aligned, and alignable IFO. So, that experiment didn't work, moving on.
Today we decided to try using height marks 901, 902, and 903 to set our Z axis alignment. We looked at marks 901 and 902 with an autolevel and compared them to our BSC2 door flange scribe average we had used the water tube level to measure (alog 75974) and the listed local Z coordinate from T1100187. Results:
Not bad, and definitely not the almost +4mm the FARO was measuring for these marks w.r.t. BTVE-1. If we use our differential height survey from alog 75771 we can also calculate the local Z axis coordinate for mark 903, which comes out to -79.8 mm (versus the listed coordinate of -79.9 mm from T1100187), and again not the almost +4mm reported by the FARO when measured w.r.t. BTVE-1. It's looking more and more like there was some error in the Z axis position of BTVE-1; whether that error was in setting the monument itself or in setting BSC2 w.r.t. to BTVE-1 we cannot say. The fact of the matter is that when compared to BSC2 as it sits right now based on our water level survey, the height marks we've looked at are pretty close to their listed coordinates and BTVE-1 is definitely not. We also happened to do the same differential height survey with BTVE-1 (also in alog 75771), so we can calculate a local Z coordinate for BTVE-1 based on our height mark 903 (which we have now tied to BSC2 Z=0). Doing so gives a local Z axis coordinate for BTVE-1 of -1060.3 mm (Z903 - deltaZBTVE-1/903 = -79.8 - 980.5); this becomes -1060.9 mm once we convert to our global coordinate frame (which is decidedly not the -1057.2 mm all of the old documentation lists it as).
Now that we have local Z coordinates for 901, 902, 903, and BTVE-1 that have all been tied to BSC2 Z=0, we used these to set a new alignment. First, we need global Z coordiantes for our 3 height marks. We got these by using a autolevel to set a magnetic nest inline with the height mark to be measured. The FARO was put into an intial alignment using BTVE-1, PSI-1, PSI-2, and PSI-6 (X and Y are generally pretty good, Z is off but we don't care yet), and we then placed the SMR on the nest we placed inline with 903. From this we got an X/Y coordinate for the nest that we could use to calculate our global Z. Once this was done we added 903 into the alignment routine, and removed PSI-1, PSI-2, and PSI-6 for the Z axis fit. we then moved the FARO to a position where we could see 901 and 902 and shot them in the same way we did 903. Ultimately, we ended up with an alignment using BTVE-1, PSI-1, PSI-2, and PSI-6 for X and Y and 901, 902. and 903 for Z. The coordinates used for the height marks were (format is [X,Y,Z]):
Tyler has a screenshot of the results of the alignment that he'll post as a comment to this alog. One thing to note here: We were not using the new BTVE-1 Z as part of the Z axis alignment, only marks 901, 902, and 903. It's somewhat comforting to see the Z axis coordinate of BTVE-1 as calculated by the alignment routine as close as it is to what we think the nominal shoud be based on our water level survey of BSC2. The PSI monuments are all out, especially PSI-2. I'm not sure how concerning this is, as we don't trust the Z coordinates of the PSI monuments anyway.
One caveat here, all of the height marks we used are almost in a line down the Y axis, with very little deviation in the X axis coordinate (a deltaX of less than 7mm across ~25m of the Y axis). I'm not entirely confident we're picking up the global tilt of our X axis with this configuration. We want to take this alignment and test and refine it; first thing we can do is get some more height marks spread along the X axis to hopefully catch the global X axis tilt. More to come!
The BRSX remote mass adjust pico motor was finally connected to the EX pico controller this morning. This was done with the pigtail D2400020 that Fil made, to allow the BRS to use channel 5 on the controller. Channel 5 is then sent to a DB9 that goes into the box, and connects to a DB9 soldered to the pins on a feedthru on BRSX vacuum vessel.
I tested that we are able to run the motor from the MEDM, and made an adjustment to the mass on the BRSX to try to get us better centered. I can now recenter the BRS from my office, nice.
The pico controller screen is accessed through LSC->Picmotors->End X (X PICO A) screen. To recenter push "Enabled", push the wait for the err codes to clear, set the step size and speed. "Sprint" is fine for the speed, for the BRS at least. The motor is, I think, 10k steps per revolution, when UW was here, we used 1250 steps per move. Today, I went +2250 steps, saw that was the wrong direction, then -5000 steps from and then a final +1000 steps to disengage the mass adjuster drive yoke. The net move was -1750 steps. This is recorded in epics as H1:SYS-MOTION_X_PICO_A_CURRENT_X_POSITION, but that seems to depend on the channels selected on the chassis.
The buttons on the pico motor screen are kind of confusing " < " makes positive steps, and " > " is negative. This moved the BRSX driftmon channel about -20k counts, and it just barely on the bottom edge of it's readout range. I've turned the voltage on the heater down to bring it back to center, but that will take a day or two to settle out, so I've taken the BRS out of loop for now.
Summary (highlights) of findings during the DQ Shift -Engineering run with ongoing commissioning -Numerous lock-losses due to earthquakes/seismic activity -BNS range averages between 145 and 150 Mpc. Sometimes there are fluctuations to 130 Mpc. -Glitchgrams show a reoccuring glitch around 40 Hz that occurs a few times a day. -The h(t) spectrogram showed sporatatic increases of amplitude relative to the median in low-frequency range. Anomalies can be associated with drops in BNS range. -Fscans are unavailable at this time. -A few pyCBC triggers with new SNR > 10 (short) occured 2 out of 7 days. -PEM, ASC and LSC type channels showed often as round winners in Hveto associated with low-frequency noise around 40 Hz and 50 Hz respectively. -New channels of interest include IMC and HPI. Channel activity can be linked to sustained winds. Also could be round winners because of shorter observation runs. DQ Shift Report: https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20240318
Attachment 1 - Unsqueezed (left) vs. squeezed (right) DARMs in ER16, with respect to O4a. Like Gabriele's plots, the ratios on the bottom show a given trace / O4a reference, so ratio > 1 means more noise now than O4a.
Colors: Rainbow colors are ordered past to present: e.g. Red = O4a, ... Purple = now.
Attachment 2 - SQZ dBs after subtracting non-quantum noise, with various recent PSAMS settings. Upper subplot: Anti-SQZ, Lower subplot: SQZ. Lines are a moving average of the data. Some caveats for the subtraction: here I am using the same H1 unsqueezed quantum noise model for all subtractions; this may not be the most accurate, but I think it should be fairly close.
Reference alogs wth times that I used to grab GDS_STRAIN_CLEAN:
Adding FDS times from the DARM comparison in 76955, and only including times with sqz/no-sqz comparable to those recent darm comparisons.
Attachment 1 - Unsqueezed (left) vs. squeezed (right) DARMs in ER16, with respect to O4a. Like Gabriele's plots, the ratios are trace / O4a reference, so ratio > 1 means more noise now than O4a.
Attachment 2 - SQZ dBs after subtracting non-quantum noise. Analysis with non-quantum noise subtraction for this week's PSAMS data in 76925 and 76949 ongoing.
Attachment 3 - Comparison to a very basic gwinc noise model (pulled from H1 NB) for squeezed darm. For example the dashed purple "Unsqueezed QN model" is (almost) what I am using for subtracting non-quantum noises.
Colors are rainbow-ordered time-wise. Red = O4a reference. Purple = 4/4 times from 76955 for FDS DARM comparisons.
Note: here the PSAMS settings are referenced in terms of strain voltages. Just pointing out that LLO has a guardian to servo PSAMS voltage to meet the "_TARGET" strain gauge voltage LLO:63403.
Reference alogs wth times used to grab GDS_STRAIN_CLEAN:
This could be a bad readback, or real, we are not sure. The signal should be 23dB, but the readback is showing 16.8dB on NDSCOPE and has been trending down for a while, it is throwing an error flag in beckhoff. This signal is located in ISC-R1 slot U16 on the left side. The LO signal is 9MHz and is fed through a delay line chassis, there are also baluns, cabling, etc... We were not able to determine the source of the readback error before noon, so this will have to wait until a maintenance window.
M. Pirello, F. Mera, D. Sigg
Measured RF power at the
The analog readback of the power detector was 5.89V at the front panel. This has been confirmed to be the same as the slow controls readback, which corresponds to 23.3dBm.
Seems like disconnecting and connecting the LO cable" fixed" the problem. Flaky cable and/or connector?
This morning I flipped the sign (after talking to the Operator) of the ETMX ESD lock bias voltage from -450V to +450V for 3hrs to reduce the charge build up in the optic.
After 3hrs I reversed the sign and set it to nominal.
ndscope trends are attached below.
Per WP11795 I looked at the EX Accelerometer Power Conditioner based on what Robert said about one of the channels not functioning. Visually, there is no power on channel 8, the power good light is off. We moved the signal to channel 9 and will go back to fix channel 8 when time permits. This channel was working when the chassis was installed.
Lights off, paging system unplugged, WAP stayed off. Some unused extension cords unplugged, genie lift charging block unplugged. Turned off SQZ laptop and monitor.
All else looked good, followed T1500386
WP 11799. Patrick T., Ryan S. The PSL Beckhoff PLC has been updated to match the changes made at LLO to add a watchdog channel. This is the code from 'TwinCAT Projekt_LIGO_240124.zip' in https://dcc.ligo.org/E2100235. The now running version is in git at https://git.ligo.org/cds/ifo/beckhoff/lho-psl and commit 9b6ad86cb26660b136242b334bd4831a683f1c5b. It appears there was also a change to fix a bug where toggling the noise eater tripped the NPRO. Ryan verified that this now appears to be fixed. I also removed the ${IFO}.PSL.LASER.MAIN.SHUTTER alias of the bEnable_Shutter2 variable, which according to LLO is not being used. The channel was not being exported to EPICS. There were two minor issues. The first was that the version of a couple of the terminals found from a scan of the EtherCAT bus did not match what was in the IO configuration, and this appeared to be the cause of an INIT error for a couple of terminals (presumably those) when the system was put into run mode. This was fixed by changing the IO configured versions to match the scanned versions. The other was that I forgot to comment out the inversion of the signal from laser PD1, which was not realized until we started everything and were wondering why the power was reading as negative for that PD. I fixed that in a new commit and restarted the code again.
The new pump diode watchdog will trip off the system in the event any of the diodes drops below a set percentage, much like the already existing watchdogs on the output of the NPRO and both amplifiers. I've set this trip level at 80% and enabled the WD. I also added an indicator to the PSL overview medm screen showing the WD is enabled (H1:PSL-LASER_PDWD).
Tue Apr 02 10:06:37 2024 INFO: Fill completed in 6min 34secs
Jordan confirmed a good fill curbside
Picket Fence was updated. The only major change is that one channel "HLID" was dropped for another, "HWUT".
FAMIS 20022
The main chiller alarm was active last night, so this morning I added 100mL of water to stope the low-level alarm.
We plan on doing a remote PMC alignment tomorrow during maintenance to address the recent rise in PMC reflected power.