Thu Oct 26 10:14:54 2023 INFO: Fill completed in 14min 49secs
Travis confirmed a good fill curbside.
Note that now the outside temperatures have dropped (and therefore also the thermocouple reference junctions) the TCs no longer drop down to -200C.
I increased the trip temperature from their summer setting of -130C to their winter setting of -100C this morning. The TCs min temps for today's fill were TCA=-125C, TCB=-119C.
The plot y-axis marker has been set to the new trip temp.
Lockloss @ 16:38 UTC due to earthquake
Holding in DOWN for a bit while the ground motion settles.
16:53 Started relocking
18:49UTC Observing
TITLE: 10/26 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 9mph Gusts, 6mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.12 μm/s
QUICK SUMMARY:
We've been Locked for 2.5 hours and are Observing
TITLE: 10/26 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 161Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY:
Since the Mid shift report relocking from that incoming earthquake went well. BUT
04:04 UTC:
IFO OUT saturations happned again During Prep_ASC_FOR_FULL_IFO. And usually that does not tend to happen. Thats the second lock in a row that this has happened, in the same ISC_LOCK State. So maybe it's a coinicidense because both locks happened on the same night, after the same initial alignment. I'd be interested in seeing if this happens again after another initial alignment.
3:48 UTC Lockloss
4:44 UTC Nominal_LOW_NOISE reached
5:05 UTC OBSERVING reached
6:02 UTC Incoming 5.5M Earthquake from Timor-Leste
6:57 UTC Seismic to CALM, we made it.
Current H1 Status: Locked in NOMINAL_LOW_NOISE and OBSERVING.
LOG:
None
Lockloss from 5.4M Earthquake from Tonga from ISC_LOCK STATE : INJECT SQUEEZING.
https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi?event=1382327323
Aquired H1 while it was in comissioning and had been locked for 20.5 hrs.
Comissioning finished at 23:32 UTC.
00:29 UTC Dropped out of observing and back in comissioning due to:
CAMERA_SERVO Guardian log has the following message:
USERMSG 0: ASC-CAM_PIT1_INMON is stuck! Going back to ADS
2023-10-26_00:34:24.014687Z
CAMERA_SERVO [TURN_CAMERA_SERVO_ON.run]
USERMSG 1: ASC-CAM_YAW1_INMON is stuck! Going back to ADS
Naioki Patrick and I got on to team speak to try and restart the camera service on h1digivideo2.
At first using the monit system h1digivideo2:2812/h1cam26
Which didn't seem to be benificial.
And again by opening a ssh console to h1digivideo2 and manually restarting it.
And also trying to Kill the process using top commands.
We are now trying to powercycle the camera via removal of POE on its port
Contacting Dave to power cycle switch sw-lvea-aux port 0/35
Lockloss at 01:51 UTC https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=73750
Dave was able to get the camera to reboot and I can now see a black camera image instead of blue screen. Link to his alog.
Relocking had ALS-Y arm alignment issues. Once that was taken care of by green arms manual and touchin up Y arm, I ended up in Check Mich Fringes twice and couldn't get DRMI locked.
So I started an Initial_Alignment. Which completed at 3:03 UTC.
3:19 UTC During Prep_ASC_FOR_FULL_IFO, there were saturations signaled by verbal's IFO out call out.
I dont usually hear saturations during this stage of locking. So I made a note of it.
3:22 UTC Incoming 5.4 Earthquake from Tonga...
Current status: Relocking at ISC_LOCK_STATE: MOVE_SPOTS.
Lockloss from NOMINAL_LOW_NOISE
https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi?event=1382320306
This happened while Dave , Patrick , And Nioki were trying to resolve the camera issue that was preventing H! from going into OBSERVING.
We did get a small Earthquake roll through at the time, though I'm not sure if the earthquake was what took us down, as the earthquake was very small and wind was mildly elevated as well.
Tony, Dave:
The EPICS channels for cam26 froze at their last values from 17:28 PDT onwards this evening. The camera was recovered by:
1. power cycling the camera via its POE port on sw-lvea-aux (port 0/35)
2. attempting to kill the camera server process on h1digivideo2 using monit, and when that did not work I killed the process by hand as root.
3. started the camera server process via monit, which did work.
Unfortunately H1 had lost lock, so I can only confirm the pixel sum channel went from its stuck value to zero. We will verify the camera is working when we get light back on it.
Sheila, Naoki, Camilla
We took FDS, Anti-SQZ and Mean SQZ data at different NLGs: 14, 17, 43, 82 and 123. We think we see evidence of frequency noise. We see less squeezing at high NLGs: around 4.5dB of SQZ at NLG < 43.1 but at NLG 81.9 and 122.8, squeezing at 1kHz reduced to 3.6 and 3.1dB. Attached Plot.
Each time we optimized SQZ angle around 1kHz. Because of this, the low frequency increased noise at high NLGs could be due to incorrect rotation, rather than phase noise.
Time (UTC)
|
Demod phase
|
DTT ref#
|
NLG |
SQZ dB at 900Hz
|
|
FDS
|
21:23:40-21:26:00
|
152.25
|
3
|
13.9
|
-4.3
|
FDAS
|
21:27:30- 21:32:30
|
228.10
|
6
|
13.9
|
15.2
|
Mean
|
21:33:47- 21:38:00
|
-
|
7
|
13.9
|
12.7
|
No SQZ
|
21:40:00 -21:44:50
|
-
|
0
|
-
|
|
FDS (not optimized)
|
21:51:20 -21:54:30
|
164.57
|
Deleted
|
43.1
|
-4
|
FDAS (Left ASC off)
|
21:56:00 -21:59:45
|
226.2
|
5
|
43.1
|
19.1
|
FDS (retake)
|
22:03:00 -22:06:13
|
167.42
|
4
|
43.1
|
-4.3
|
Mean
|
22:06:45 -22:09:52
|
-
|
8
|
43.1
|
16.9
|
FDS
|
22:37:50- 22:41:00
|
172.16
|
9
|
122.8
|
-3.1
|
FDAS
|
22:42:43-22:45:45
|
217.67
|
10
|
122.8
|
24.7
|
Mean
|
22:46:35 - 22:49:55
|
-
|
11
|
122.8
|
|
FDS
|
22:57:30- 22:59:40
|
169.31
|
12
|
81.9
|
-3.6
|
FDAS
|
23:01:20 - 23:02:55
|
219.56
|
13
|
81.9
|
22.7
|
Mean sqz
|
23:03:26 - 23:05:45
|
-
|
14
|
81.9
|
20
|
FDS (left IFO here)
|
23:19:38
|
154.14
|
15
|
17.1
|
-4.5
|
Data saved in /camilla.compton/Documents/sqz/templates/dtt/20231025_GDS_CALIB_STRAIN.xml
Time (UTC)
|
Unamplified OPO OPO_IR_PD_LF
(Scan Seed)
|
OPO trans (uW)
|
OPO Temp (degC)
|
Amplified (maxium) H1:OPO_IR_PD_LF
(Scan OPO PZT)
|
NLG
(Amplified / (Unamplified Peak Max - Unamplified Dark Offset))
|
|
Peak Maximum | Dark Offset | |||||
21:15
|
786e-6
|
-16e-6
|
80.54 uW
|
31.446
|
0.0112
|
13.9
|
21:44
|
|
|
100.52
|
31.414
|
0.0346
|
43.1
|
22:17
|
|
|
120.56
|
31.402
|
0.160
|
199.5 (SQZ loops went unstable)
|
22:30
|
|
|
110.5
|
31.407
|
0.06617
|
82 (didn't use)
|
22:36
|
|
|
115.46
|
31.405
|
0.09853
|
122.8
|
22:52
|
|
|
110.5
|
31.407
|
0.0657
|
81.9
|
22:09
|
769e-6
|
-15e-6
|
80.5
|
31.424
|
0.0137
|
17.1
|
Vicky and Naoki did an NLG sweep on the Homodyne in 73562.
Edits to NLG table in above alog: Last measurement was at 22:09 23:09 UTC. For measuring unamplified we scanned OPO PZT and for amplified we scanned SEED PZT.
Setup for each SQZ Measurement:
Attached are fits of squeezing loss, phase noise, and technical noise to this NLG sweep on DARM: we can infer 25-30% total SQZ losses, ~25 mrad rms phase noise, with technical noise almost -12 dB below shot noise.
Losses are tracked in the SQZ wiki and gsheet. Of the 30% total inferred loss, we expect 20%: that is 7.5% injection loss, and 13.7% readout loss.
Remaining ~10% mystery loss is compatible with mode-mismatch: in sqz-omc single bounce mode scans, LHO:73696, we estimate 8-15% mismatch, and we observe the frequency-dependence of the mismatch as we vary squeezer beam profile using PSAMS: 73400, 73621.
In the fits, [loss, phase noise, technical noise] are fit to the measured SQZ and Anti-SQZ, given the measured NLG, using equations from the aoki paper. "Loss from mean sqz" is the calculated loss from the measured NLG and measured mean-sqz dB; it is not a fit, but depends on the calibration from NLG to generated SQZ dB.
Some summary slides here show the progression of our loss hunting, which are so far lining up with Sheila's projections from 73395.
Famis 26063
In Lock charge measurements ran yesterday, and everything went smoothly up until the the line python3 coeffiencentplots.py . Ryan has an ALOG 73432 which Camilla pointed me to, This worked out well!
I made measurements of ringdown constants of the of this mechanical mode to get a measurement of the Q factor.
The measurements were admittendly quite ratty, and often the PLL would lock to some oscillation that it itself creates, giving many occasions where the oscillation vanishes immidiately as the injectoin ends.
This is largely due to the mechancial mode not being significantly larger than the noisefloor, causing PLL to lock to garbage.
Of the times I was able to excite the mechanical mode itself, I measured Q-factors of through the locked PLL amplitude signal:
So the Q-factor is approximately 1.7 million.
At the time of measurement, the frequency difference between the optical mode and the mechanical mode was 14.55 Hz.
Given the optical linewidth is roughly 1 Hz, this is "far" enough away to neglect optomechanical coupling and trust this as a true estimate of mechanical Q.
TITLE: 10/25 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 16mph Gusts, 11mph 5min avg
Primary useism: 0.04 μm/s
Secondary useism: 0.20 μm/s
QUICK SUMMARY:
H1 is in NOMINAL_LOW_NOISE, but ....
Comissioning is still in progress for a few more minutes so the SQueeZrs can do some Anti-SQZin with different Non Linear Gains(NLG).
TITLE: 10/25 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Now Locked for 20.5 hours. Had commissioning today starting at 19:07UTC and is ongoing but wrapping up soon.
LOG:
15:00UTC Detector Locked for 12.5hours
--Commissioning Start--
19:07 Out of Observing for Commissioning
19:09 To NLN_CAL_MEAS for Calibration measurements
- bb measurements: 1382296233 - 1382296559
- simulines measurements: 1382296585 - 1382297917
19:39 Back to NOMINAL_LOW_NOISE
19:44 - 20:05 DARM Boost
20:08 COMM Gain
12: 20:08:17 - 20:10:17
6: 20:10:29 - 20:12:29
12: 20:12:44 - 20:14:44
6: 20:14:58 - 20:16:58
20:20 - PRESENT SQZ ASQZ w/different NLG
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
15:04 | FAC | Karen | OpticLab/VacPrep | n | Tech clean | 15:32 |
15:09 | FAC | Randy | EY/EX | n | Moving boxes from EY to EX | 17:09 |
15:32 | FAC | Karen | MY | n | Tech clean | 16:48 |
19:10 | CAL | Louis, Oli | CR | n | Running calibration | 19:38 |
19:49 | OPT | Jason | OpticsLab | y(local) | Oplev work | 20:15 |
19:44 | ISC | Camilla, Sheila | CR | n | DARM Boost | 20:06 |
20:07 | ISC | Oli | CR | n | CARM gain | 20:17 |
19:10 | PI | Vlad, Naoki | CR | n | 80k PI work | 21:34 |
20:29 | FAC | Eric, Tyler | MX | n | Looking at air handler | 21:59 |
20:20 | SQZ | Sheila, Camilla | CR | n | SQZ ASQZ w/different NLG | ongoing |
21:23 | OPT | Jason, Austin | Optics Lab | n | Oplevs | 22:37 |
Ran a BB measurement followed by Simulines:
- bb measurements: 1382296233 - 1382296559 (2023-10-25 19:10:15 - 19:15:41)
- simulines measurements: 1382296585 - 1382297917 (2023-10-25 19:16:09 - 19:38:19)
Output files:
BB:
/ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20231025T191015Z.xml
Simulines:
/ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20231025T191609Z.hdf5
/ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20231025T191609Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20231025T191609Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20231025T191609Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20231025T191609Z.hdf5
Today we tested the effect on DARM of additional resonant gains at 2.8 and 3.4 Hz, as described in 73698.
DARM RMS was reduced as expected from 1.6e-9 to 1.2e-9.
Looking at DARM spectrograms, there is no evident difference in the level of non-stationary noise.
Comapring the DARM PSD during two times, there seems to be a small improvement, but that might be a fluctuation.
In summary: the resonant gains improve the DARM RMS, but we don't see a clear improvement in noise; they don't hurt though
I've created a low frequency boost that generally gives more gain at low freq, rather than just having the resGs. I turned it on starting at 23:11:00 UTC. Until 23:19:38, the squeezers were working. Then around 23:26:00 I changed the CARM gain. So, maybe this isn't such great 'quiet time' to evaluate whether we've improved our nonstationarity, but it certainly does seem fine, and it also does nicely reduce the low frequency DARM_IN1 and its RMS. The filter was back off around 23:31:00 UTC so we could go back to Obsering.
In the first plot, the blue filter is the one that Gabriele had created, and we tried early in the commissioning period today. Red is my new proposed filter.
In the second plot, the blue is DARM_IN1 under nominal circumstances (so, no resG or boost), and red is with my version of the boost filter. As noted in my 'timeline' above, there isn't really a lot of good quiet time to evaluate its effect on the nonstationarity, but the significant reduction in RMS seems like a good thing. If we want to leave this filter on, Louis will need to do some work to prepare the calibration pipeline, and we'll need to restart the GDS pipeline during the same commissioning window that we turn on the new boost.
EDIT: please disregard the y-axis label on the DARM_IN1 specra plot. I don't think that should be there.
In a follow-up to what TJ did yesterday(73685), I alternated the CARM gains (H1:LSC-REFL_SERVO_IN{1, 2}GAIN) between 6 (what it was nominally at) and 12 every two minutes.
Times when we were at each gain setting (in UTC):
12: 20:08:17 - 20:10:17
6: 20:10:29 - 20:12:29
12: 20:12:44 - 20:14:44
6: 20:14:58 - 20:16:58
Attached is an ndscope over this timeframe looking at the CARM gain and SQZ BLRMS channels (same as the channels that TJ and Camilla had been looking at yesterday(73682)).
Attached is our very high frequency monitor of the DCPDs. (Since this channel is not saved, I also upload the DTT file).
The red / pink traces are at our nominal CARM gains of 6dB on each slider (H1:LSC-REFL_SERVO_IN1GAIN and IN2GAIN), and the blue / teal traces are the higher values of 12dB on each slider. All data is 10 avgs at 1 Hz BW, 25th Oct 2023. Times of the data are in the legend for each trace.
It seems that increasing the CARM gain is beneficial to our noise between 6 kHz to about 25 kHz. From about 25 kHz to a little above 100 kHz it increase our noise a bit. Above 100 kHz we're limited by some other noise, and so not seeing the effect of frequency noise.
I think it seems fine to leave CARM with the higher gain.
I've just modified LASER_NOISE_SUPRESSION to increase the sliders to 12dB (it used to increase them up to the previous nominal of 6dB at the end of the state). I've just increased the sliders before we go back to Observe, so we'll have lower frequency noise for all our upcoming locks.
Summary:
It seems that the supply voltage for thermistors is oscillating, the frequency depends on whether or not the supply is loaded with thermistors (830mHz open to 1.66Hz fully connected to the in-chamber thermistors), the amplitude of the oscillation jumps seemingly randomly, and this is also happening for the unused Beckhoff module for the yet-to-be-installed second T-SAMS unit, all measured at the back of the Beckhoff chassis. (Can't we measure this from Beckhoff itself, without me going to the floor?)
Fil and Fernando quickly set up the same Beckhoff module in the lab and didn't observe this. Could we swap or maybe restart the modules in the chassis?
As of now, Beckhoff cable is disconnected from the back of the heater driver chassis. (I'm applying DetChar-Request tag just so people know, but we're just changing from one no-comb configuration to the other.)
Detaisls:
Since the past findings about OM2 and 1.66Hz comb (alogs 73367, 73233, 72967 72241 and 72061) didn't make sense, I went to the floor and remeasured the comb in the Beckhoff heater output (which goes to the heater driver input) as well as thermistor pins in the back of the heater driver chassis while Beckhoff connection was intact.
Turns out that all of these things share the same frequency but the voltage across thermistor pins was ~3 orders of magnitude larger than Beckhoff heater driver output pins (pin 9 and 19) (the latter were referenced from the driver board ground as it's common mode for both pins). I used a scope on battery and the thermistor voltage was like roughly 1Vpp 1.66Hz rectangular wave (1st pic). Yellow is the voltage across pin10 and 23 (across thermistor 1), blue is pin9 and 22 (thermistor 2) of the DB25 at the back of the driver chassis when the Beckhoff cable was still connected. Voltage difference seemed to have come from the temperature difference of the thermistors (I disconnected the Beckhoff cable and measured the thermistor 1 and 2 resistance incl. cables to be 7.41k and 4.08k, respectively). When I disconnected the cable from the chassis and just measured the pin10-23 and pin9-22 voltage coming from the cable (picture 2), they were both about 1.2V pp. This is supposed to be the source voltage for thermisters. The frequency slowed down by about a factor of 2 (832mHz) when the thermistors were disconnected.
For your convenience, below is a table of which pins are what (see e.g. E1100530 and D2000212). Note that thermistors themselves only have two pins, therefore supply and readback pins are bundled together in chamber as shown. Supply is presumably a reference voltage supplied through a reference resistor.
which thermistor? | DB25 pin | Beckhoff | in chamber |
1 | 10 | Temperature Supply 1A+ | thermistor 1 pin 1 (10&12 bundled together in chamber) |
12 | Temperature Readback 1A+ | ||
23 | Temperature Supply 1A- | thermistor 1 pin 2 (23&25 bundled together in chamber) |
|
25 | Temperature Readback 1A- | ||
2 | 9 | Temperature Supply 2A+ | thermistor 2 pin 1 (9&11 bundled together in chamber) |
11 | Temperature Readback 2A+ | ||
22 | Temperature Supply 2A- | thermistor 2 pin 2 (22&24 bundled together in chamber) |
|
24 | Temperature Readback 2A- |
Went to the CER, disconnected the cable from the back of the Beckhoff chassis and did the same measurement. Frequency didn't change but the amplitude was much smaller (~280mVpp instead of 1.2Vpp) for a while, but suddenly the amplitude of the thermistor 1 supply changed back to 1.2V (pic 3). Nuts. When the beckhoff cable was reconnected (and the connection to in-chamber thermistor was restored) the frequency went back to 1.66Hz (picture 4).
Picture 5 shows pin 10-23 (thermistor 1 supply) and pin12-25 (thermistor 1 readback, which is not connected to anything). Picture 6 is the same thing but for the unused Beckhoff unit for the second T-SAMS. It's strange that the same thing is happening in two independent units. Picture 7 is the thermistor 1 supply and pin 6-19 (voltage output for the heater driver). It really seems that this is a problem of the supply voltage.
I checked the 24V power strip for the Beckhoff chassis but it was good (pic 8 and 9).
Fil and Fernando set up EL3692, which is the Beckhoff unit used for Thermistors. They didn't observe this oscillation behavior.
I wanted to do some injections into thermistors to see how this couples to DARM but didn't have time.
Well, this seems to be a feature! The EL3692 terminal has 2 measurement inputs for resistance but only one ADC and current source. In alternating mode it switches between the 2 channels continuously. From the scope traces, the measurement time per channel looks like about ~400 ms. This is consistent with the data sheet. We expect about ~0.16 mA of current in the range between 10 Ω and 10 kΩ.
Fil, Marc, Keita, Daniel, Fernando Fil and I set a test bank in the lab and verified the square pulses found are part of the features of the EL3692 terminal when both channel reading is set. Then we implemented a configuration using a continuous reading over the channel 1 and one shot reading over the channel 2 (under request by a raising edge on the Start Conversion input in the module, that will be never used). Finally the scopes show the continuous signal in the channel 1 with some minor noise component that is still in analysis (basically 60Hz and 12Hz) however this virtually solves the main problem with the square pulses. One ECR should be open to double the quantity of EL3692 in the places where reading in both channels are necessary since just one channel provides continuous reading at this point. Note: the autorange feature was left intact so the new configuration will not cause any limitation in the resistor range to be measured and also will keep the same PDO to not break the Epics configuration. Attached: scopes and the EL3692, configuration applied to the EL3962 and spectral analysis for the noise signals.
WP 11501 Daniel Keita Fernando Today we configured the one channel reading on the two Beckhoff EL3692 modules for the PSL IO Chassis. After restarting the system Keita Daniel and I were to the rack to scope the thermistor channels we verified the absence of the square pulses reported initially. Finally the module R20 CH2 was rewired to R21 CH1 and configured in the system accordingly. Attached the picture including the R20 and R21 EL3692 modules for reference.
After having a solution for the issue duplicating the number of EL3692 modules, and ECR and FRS ticket have been created: ECR: https://dcc.ligo.org/E2300408-v1 FRS ticket: https://services1.ligo-la.caltech.edu/FRS/show_bug.cgi?id=29563
Daniel, Fernando
As part of the WP11506 a new configuration was loaded into the Beckhoff system which includes the 1-channel continuos reading for the EL3692 terminals. The change included the rewiring in the TCS Corner EtherCAT chassis TSAMS consisting of connecting the second channel in the EL3692 (R20) to the first channel in the terminal EL3692 (R21) to match the TwinCAT configuration added. The disconnected wires are not currently connected ot any thermistor on the floor.