Displaying reports 12641-12660 of 84373.Go to page Start 629 630 631 632 633 634 635 636 637 End
Reports until 08:01, Wednesday 01 November 2023
H1 General
ryan.crouch@LIGO.ORG - posted 08:01, Wednesday 01 November 2023 - last comment - 09:51, Wednesday 01 November 2023(73893)
OPS Monday day shift start

TITLE: 11/01 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Aquisition
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 2mph Gusts, 0mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.28 μm/s
QUICK SUMMARY:

Comments related to this report
ryan.crouch@LIGO.ORG - 08:11, Wednesday 01 November 2023 (73894)

The violins are looking pretty rung up on DARM as we're in ENGAGE_ASC_FOR_FULL_IFO

ryan.crouch@LIGO.ORG - 08:43, Wednesday 01 November 2023 (73895)

We're waiting in OMC_WHITENING damping violins and will be for maybe a half hour? Hopefully less

ryan.crouch@LIGO.ORG - 09:15, Wednesday 01 November 2023 (73897)

We've reaquired NLN at 16:10UTC but the SQZ FC is struggling to lock.

victoriaa.xu@LIGO.ORG - 09:51, Wednesday 01 November 2023 (73899)SQZ

FC was quite misaligned and not able to find a TEM00 mode for locking; I had to walk FC2 quite far to find resonance, and I also touched ZM3, see slider screenshots accepted into SDF here: ZM3 / FC2 slider diffs to relock. I probably didn't need to move ZM3. Not sure how this will fit into our recent SQZ ASC issues 73855.

Other than sliders, accepted the folllowing FDS SQZ SDFs in Observe (after LHO:73876 accepted SDF's in safe). Includes SQZ+FC ASC ON switches, and FC + LO servo locking settings.

I tweaked up sqz angle and opo temp ; in particular sqz angle seemed off by 10+ degrees even if opo temp was the same. The sqz angle may need to be adjusted later today in commissioning, since I set it for squeezing pretty early on (~30min) into lock, so expect IFO was unthermalized.

Images attached to this comment
H1 General
anthony.sanchez@LIGO.ORG - posted 04:28, Wednesday 01 November 2023 - last comment - 08:05, Wednesday 01 November 2023(73891)
Wednesday Morning OWL Shift Mid shift Update.

TITLE: 11/01 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Aligning
INCOMING OPERATOR: TJ
SHIFT SUMMARY:
Inherited H1 during Initial Alignment, stuck on ACQUIRE_XARM_IR.

Tried locking the IFO just to see where H1 will stumble.
Tried Initial Alignment and got stuck  at Acquire_XARM_IR.
Tried Man Alignment and got stuck in the same spot.

Found my own alog about a very similar situation:
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=69497

Started reading Troubleshooting Docs-
Checked TRX OPD , Trending PR2.
reverting PR2 to GPS time : 1382733517
reverted xarm to  gps time 1382733517
Retouched up ALS x arm in green arms manual tried to do an initial alignment again and got stuck at
ACUIRE_XARM_IR again

~ 9:47 UTC Reverted the PRC PRM, PR1,PR2,PR3 to 1382733517
Success!! INITIAL ALIGNMENT moved forward!!!
INITIAL ALIGNMENT completed!
Locking Got Stuck at ALS and Find IR. So running Another initial Alignment. Perhaps moving PR Cavity sliders half way though Initial alignment leads to a bad Alignment, with ALS? Perhaps my movement of PR3 was too much?
 
Still Cant get past Find IR After another IA.

Jenne had popped in to Matter most and Given me a clue to take notes on where PR3 was.
and PR3 and what I was setting it to.
Notes:
PR3P After: -117.4
PR3Y After: 155.3
PR3P before: -116.2
PR3Y Before : 152.1

I'm exausted and spinning my wheels. I think this might still be a PR Cavity issue. But I can no longer think clearly and feel like I'd make irratic changes at this time in the morning. I've gotta step away and get some sleep.

 




LOG:
No log

Comments related to this report
jenne.driggers@LIGO.ORG - 08:05, Wednesday 01 November 2023 (73892)

Apologies for the scattered notes; I'm on a meeting working on the IFO in parallel.

ISC_LOCK reset - including prep_for_locking and sdf_revert.

Locked and aligned green arms. 

Set XarmIR part of Align_IFO to Input_align, so that when I move PR3 then PR2 and IM4 will have to follow along.  Moved PR3 in the direction of where the oplevs were ~14 days ago, although didn't go all the way since the COMM beatnote went past a peak and started getting less good.  Had ALS_XARM at Locked_slow_no_wfs, so could see that the comm beatnote improved from -16dB to about -10dB.  (I could move PR3 to get up to about -8dB, but that isn't back in the direction of where it had been 2 weeks ago).

Offloaded Input_align.

Going through the rest of initial alignment .  PRC align went without intervention, MICH bright align went without intervention.  SRC needed help, so I asked it to do SR2_align.  SRC still wouldn't catch, so I touched SRM in yaw and it caught and finished initial alignment.

Locking:

ISC_LOCK automatically went through PRMI_ASC.  Automatically went back to DRMI and caught lock after that.  Locking going smoothly so far, so handing back to daytime operator.

H1 General
oli.patane@LIGO.ORG - posted 00:48, Wednesday 01 November 2023 (73890)
Ops EVE Shift End

TITLE: 11/01 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Aligning
INCOMING OPERATOR: Tony
SHIFT SUMMARY:

I eventually was able to get the IMC locked (73887) and adjust PR3, but for the past 2.5 hours the detector has been trying to complete an initial alignment.

Trying to lock detector:

- Started initial alignment

    - Got stuck at ACQUIRE_XARM_IR, which I assumed was because it was "Waiting for sus to settle", and it stayed there for almost 30 minutes.

- Took the detector to DOWN and restarted the initial alignment. This time the DCPD values were going down, but very slowly.

- Tony and I left initial alignment and tried to move through normal locking but lost lock at FIND_IR

- Tried going back into initial alignment again, but got stuck at ACQUIRE_XARM_IR again

- Tony and I still troubleshooting - I think it's maybe possible that although I got the IMC locked and aligned within itself, it might not be aligned with respect to the rest of the detector.


LOG:

23:00UTC Maintenance finishing up

23:15 Starting to try to fix the IMC Locking issue

02:11 After messing with pitch and yaw on MC1 and the IMC PZT for a while, I wasn't able to get them back to the values that they were at at 15:11UTC this morning, which is when the IMC was last in the unlocked state. I got them all as close as they could and then I am now trying to get flashes on MC trans by going to the acquire state on IMC_LOCK

03:56 IMC Locked

04:53 Adjusting PR3 pitch and yaw based on 73854
    - Got pitch within range from ~1 week ago and yaw is much closer but not within range. COMM beatnote is ~-17 before initial alignment

05:21 Started Initial Alignment

05:55 After about 10 minutes in initial alignment, ALIGN_IFO had gotten stuck at ACQUIRE_XARM_IR, so I took the detector to DOWN and restarted the initial alignment

06:11 Got stuck again at the same spot

07:13 Took detector out of initial alignment and attempted to lock normally - failed at FIND_IR

H1 ISC
oli.patane@LIGO.ORG - posted 20:29, Tuesday 31 October 2023 - last comment - 20:37, Tuesday 31 October 2023(73887)
Ops EVE Midshift Update

I am still working on getting the IMC to lock following today's power supply replacement (73871). Based on Jenne's instructions, I tried to get the IMC-WFS_{A,B}_{PIT,YAW}_OUT16 values back to their values from around 10/31 15:11UTC, which was before the restart and when the IMC was offline, by adjusting the offset on the IMC PZT and MC1, and was able to get much closer, but not great.

I then took IMC_LOCK to ACQUIRE and tried adjusting MC2 and MC3 for the best output, but wasn't able to get the beam to look better (or worse), so with Keita's help I lowered the IMC WFS trigger threshold in an attempt to use the WFS to better the alignment. It has worked a bit (we went from locking on the 00 mode at 30counts on IMC-IMC_TRIGGER_INMON to locking at 62 counts).

Comments related to this report
oli.patane@LIGO.ORG - 20:37, Tuesday 31 October 2023 (73888)

As soon as this is posted the IMC catches and lockes, although the amount of light on MC Trans and Refl are not correct yet.

H1 CDS (OpsInfo)
david.barker@LIGO.ORG - posted 16:40, Tuesday 31 October 2023 (73885)
ETMY HWS off, will restart it tomorrow

Camilla, Jonathan, Erik, Dave:

Currently the HWS ETMY computer is down for unknown reasons. Camilla says it is OK to leave it like this overnight and we will go to EY tomorrow to troubleshoot.

In the mean time, the EDC will run with disconnected_channels = 86

H1 General
camilla.compton@LIGO.ORG - posted 16:24, Tuesday 31 October 2023 (73884)
LVEA Swept

LVEA Swept following T1500386. Lights, paging system and WAP off. Noticed nothing other than what Oli noted in 73244.

H1 General
oli.patane@LIGO.ORG - posted 16:23, Tuesday 31 October 2023 (73883)
Ops EVE Shift Start

TITLE: 10/31 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Aligning
OUTGOING OPERATOR: Austin
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 1mph Gusts, 0mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.27 μm/s
QUICK SUMMARY:

Maintenance has wrapped up for the day and I am now starting to fix the issues with the IMC alignment and then going on to remedy the other issues from today before we lock.

LHO General
austin.jennings@LIGO.ORG - posted 15:59, Tuesday 31 October 2023 (73864)
Tuesday Shift Summary

TITLE: 10/31 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:

- 15:14 UTC - ISI ETMX ST1/2 trip on T240, most likely due to high motion from EQs - plot attached

- 16:08 UTC - ISI H7 trip on CPS, cause unknown - plot attached

- 16:37 - ISI H6 trip on GS13, cause unknown - plot attached

- Fire alarm test in OSB - 16:37 - 16:42

- Airhandler alert for CS ~16:45 - H0:FMC-CS_LVEA_REHEAT_2A/3A/3B_DEGF - attached scope, looks like there is a swing, informed Tyler

- ~16:46 - DM alerts for PSL 102ptics Lab/VAC prep alert @ 18:14/19:57 DM 1 @ EX

- Sometime this morning, the Kepco power supply, supplying power to the LSC/ASC IO chassis started making a loud noise, and after further investigation it appears one of the actual fans broke off causing the rattling

LOG:                                                                                                                                                                                                                                                                                                                                                                                                                                     

Start Time System Name Location Lazer_Haz Task Time End
14:58 FAC Randy EX N Installing clean room curtains 16:40
14:59 FAC Kim/Karen LVEA N Tech clean 17:30
15:04 PSL Jeff CR N PMC sweep 15:54
15:07 VAC Jordan LVEA N Install ion pump (Gerardo in @ 15:27) 22:09
15:18 FAC Cindi FCES N Tech clean 17:10
15:25 HWS TJ/Camilla EY YES Replace HWS laser 18:55
15:30 PCAL Tony PCAL lab Y (LOCAL) PCAL work 18:44
15:54 PSL Jenne CR N Refcav alignment 16:26
15:59 SEI Jim Remote N HAM transfer functions 18:25
16:04 SQZ Daniel SQZ tables Y (LOCAL) SQZ alignment/photos 18:29
16:23 FAC Mitch LVEA N Looking for parts 16:53
16:29 CDS Jonathan OSB N GC switch work 17:26
17:30 FAC Karen EY YES Tech clean 18:24
17:31 FAC Kim EX N Tech clean ??
17:32 FAC Cindi LVEA N Move boxes 17:42
17:54 ISC Jenne CR N BS coil driver switching 18:52
18:59 EE Marc/Fernando CER N Investigate rubbing powersupply fan 19:22
19:15 PCAL Tony PCAL Lab Y PCAL work 20:00
19:45 EE Fil CER N Swap Kepco power supply 20:11
19:50 FAC Randy EY N Cleanroom vent prep 22:12
20:02 PCAL Tony/Rick EX YES PCAL measurement 22:44
20:08 VAC Janos/Travis LVEA N Install filters for pumps ??
20:41 ISC Keita HAM 6 N Measure coupling from thermistor current to DARM 21:38
21:02 PSL Fernando OSB N Beckhoff ISC work 22:01
21:11 VAC Janos/Travis MY N Swap scoll pump 22:30
21:21 TOUR Louis/Marc + Co LVEA N LVEA tour 22:30
21:52 HWS TJ/Camilla EX Y HWS work 22:58
22:30 VAC Janos/Jordan FCES N Cross beam installation ??
Images attached to this report
LHO EPO
eric.otterman@LIGO.ORG - posted 15:14, Tuesday 31 October 2023 - last comment - 09:02, Wednesday 01 November 2023(73881)
Chiller 1 trip at Mid Y
Chiller 1 had tripped its main breaker due to a bad condenser motor, which also took out a 30 amp fuse. Bad motor will be replaced when a replacement is available. Chiller 2 is currently in lead position. 
Comments related to this report
tyler.guidry@LIGO.ORG - 09:02, Wednesday 01 November 2023 (73896)
attached trends since the chiller swap (courtesy of D. Barker):
Images attached to this comment
H1 TCS
camilla.compton@LIGO.ORG - posted 14:48, Tuesday 31 October 2023 (73878)
Reverted ETMY HWS to old LED Source

TJ, CamillaWP #11483. Completed at EX last week: 73717 

Uninstalled the "new" S&K HWS laser (TSOP M1900163) from the ALS table with it's 50:50 fiber splitter, will store it in the LVEA TCS cabinets. Removed fiber, SM1FCA fiber launcher and LA1134-A F-60mm PLCX lens. This was installed in 2019 (525005251352551).

Reinstalled the "old"  diode source M530F2 (eye safe). Using M92L02 200um multi-mode fiber and D1800125 fiber launcher with F=125mm BN7 lens. the remote on/off power supply wasn't working so we plugged this eye-safe laser directly into wall power, this means H1:TCS-HWS_ETMX_SLEDSHUTDOWN will not be reporting what the laser is doing. Struggled to get to postioning of 125mm lens to give us a good size beam into the periscope, beam remains too big. 

There was alot of clipping on this path so we removed the two 1" pico mirrors and replaced with 2" non-pico mirrors (M1 and M2 from D1400241), as we have done at EX table. M1A,B,C Dog leg was removed previously. Realigned the path but didn't find the retro-reflected beam off ETMY, ISI was down so we aligned as best we could into vacuum and left it. Temporarily added a mirror after the ALS beamsplitter (ALS-M11) to retroreflect the beam to the CCD camera and check how Gaussian it was (repeat of 63019 EX work) but the beam was much too big at the camera. Again showing our mode matching isn't correct. 

Photos before and after attached. Decision made to swap back to original source in T2300336. Will update FRS 14310 with Aidan. 

Images attached to this report
LHO VE (VE)
travis.sadecki@LIGO.ORG - posted 14:03, Tuesday 31 October 2023 - last comment - 14:45, Tuesday 31 October 2023(73877)
MY and EY Turbo functionality test

FAMIS tasks 24916 and 24940

Procedure checklist for both stations completed.  No issues were identified at this time.

MY: Scroll pump hours: 11395.3

       Turbo pump hours: 206

       Crash bearings: 100%

EY: Scroll pump hours: 205.8

       Turbo pump hours: 1274

       Crash bearings: 100%

Comments related to this report
travis.sadecki@LIGO.ORG - 14:45, Tuesday 31 October 2023 (73879)

The MY turbo station scroll pump was swapped with a newer pump with only 73.2 hours.  The pump with 11395.3 hours will be rebuilt for future deployment.

H1 CDS
david.barker@LIGO.ORG - posted 12:41, Tuesday 31 October 2023 - last comment - 17:34, Friday 03 November 2023(73871)
h1lsc0 h1asc0 powered down for IO Chassis +24V DC power supply replacement

Fil, Dave, control room:

In preparation for Fil's replacement of the +24V DC Power Supply which is powering h1lsc0 and h1asc0's IO Chassis, I have powered down these two front end computers.

Process was:

IPMI Reports:

Comments related to this report
filiberto.clara@LIGO.ORG - 13:16, Tuesday 31 October 2023 (73874)

WP 11502

Kepco power supply replaced. Both IO chassis and FE computers powered on.

david.barker@LIGO.ORG - 13:45, Tuesday 31 October 2023 (73875)

Tue31Oct2023
LOC TIME HOSTNAME     MODEL/REBOOT
12:59:06 h1lsc0       ***REBOOT***
12:59:07 h1asc0       ***REBOOT***
13:00:42 h1asc0       h1iopasc0   
13:00:42 h1lsc0       h1ioplsc0   
13:00:55 h1asc0       h1asc       
13:00:55 h1lsc0       h1lsc       
13:01:08 h1asc0       h1ascimc    
13:01:08 h1lsc0       h1lscaux    
13:01:21 h1asc0       h1ascsqzifo 
13:01:21 h1lsc0       h1sqz       
13:01:34 h1lsc0       h1ascsqzfc  
 

camilla.compton@LIGO.ORG - 13:50, Tuesday 31 October 2023 (73876)

Attached sqz sdfs that Naoki and I set so that SQZ would come back in a good (with FC DOWN) state. Lots of these will need to be re-accepted later when SQZ is relocked as some of our sfae.snap and observe.snaps are linked files.

Jenne checked sdfs for h1asc, h1ascimc, h1lsc, h1lscaux.

Images attached to this comment
jenne.driggers@LIGO.ORG - 14:58, Tuesday 31 October 2023 (73880)

Attached are SDF tables for h1lsc, h1lscaux, and h1asc.  There were no diffs for h1ascimc. 

The tables have the mask set to ALL, so that it was showing also differences that are not monitored, since *everything* gets reverted to the safe value when we boot a computer.

For h1lsc, I only accepted the TR QPD B offsets, to keep them roughly close to how they are when we've been locking.  These do get reset every lock (which is why they are not monitored), but if we don't accept them then we'll struggle more than usual with finding IR when we're ready to relock.  Everything else is either guardian controlled, or otherwise not so important.

For h1lscaux, I don't really know why those values of 500 were saved to have those oscillators on, but the scope shows that we don't usually actually use them.  This sdf table is not reverted upon each relock (but would have been when we rebooted), so that's likely why we never noticed / cared about these values.  Anyhow, we don't want random oscillators on (even if the output matrix is zeros so those don't go anywhere), so I accepted them to zeros.

For h1asc, I didn't accept any changes, but just in case we have confusion later, I took a screenshot of the diffs that we have.

There were no diffs at all for h1ascimc, so I didn't bother taking a screenshot of an empty SDF table.

Images attached to this comment
jenne.driggers@LIGO.ORG - 15:54, Tuesday 31 October 2023 (73882)

Austin is working on bringing the IMC back online, and the alignment looks quite poor.  In retrospect, I should have (and forgot to do) offloaded the IMC WFS to the suspensions, since the reboot will have lost the integrated alignment offsets that we were sending to the IMC suspensions.  Austin is going to revert the IMC sus to their earlier top mass osem values as a way of hand-offloading the WFS, and hopefully the IMC will lock and behave after that.

marc.pirello@LIGO.ORG - 17:34, Friday 03 November 2023 (73973)

H1-ISC-C1 IO ASC & LSC power supply was replaced on Tuesday.  Supply location H1-VDC-C2 slot 22A (left side).

Outgoing Supply S1201935 Incoming supply (blank)  New supply has ball bearing fan.

Outgoing supply had sleeve bearing fan that failed due to being worn out.  Will replace with ball bearing fan and put back into spares inventory when parts are available.

F. Mera, F. Clara, M. Pirello

 

H1 AWC (AWC, CDS, ISC)
keita.kawabe@LIGO.ORG - posted 12:30, Tuesday 31 October 2023 - last comment - 22:55, Tuesday 31 October 2023(73853)
OM2 thermistor comb visible in OMC QPDs and AS RF45 WFS

References: alog 73706, 73367

Attached is the comparison of Oct/18/2023 22:30 UTC (current traces, no comb, thermistors cut off from Beckhoff but the heater is still driven by Beckhoff) and Oct/17/2023 22:33:40 (references, with 1.66Hz comb plus 1.235Hz SB to the 1.66Hz comb, thermistors and the heater connected to Beckhoff).

Red circles show 1.66Hz harmonics while blue ones show 1.235Hz harmonics or 1.235Hz SB to the 1.66Hz comb.

1.66Hz comb is visible in OMC QPDs (middle row, though only A is shown here, B is similar) at around 270-280 Hz as well as 177-180Hz, but only in PIT and YAW and NOT in NSUM (which I normalized by the DC value). This strongly suggests that this is either alignment or mode shape change.

We don't see anything at the fundamental 1.66Hz though, maybe the SNR is not enough. OTOH 1.235Hz appears in the current traces as well as references in the middle column. I haven't observed anything like 1.235Hz on the floor in Beckhoff, so I assume that this is NOT from the Beckhoff heater driver DAC. It's unclear if 1.235Hz is length-like (i.e. AM) signal coming from the IFO or if it's also alignment/modal shape change as the signal appears in PIT, YAW and NSUM.

In the second attachment, ASC-AS_A and AS_B DC don't see much except AS_A_DC_YAW sees something at 270.76Hz (top blue). The light power on these should be similar to OMC QPDs but WFS DC doesn't have the ISC whitening filter. ASC-AS_C doesn't see anything (2nd attachment bottom). This is what as AS_C is upstream of OM2 and the imprinting of the noise via the DARM loop shouldn't be strong at 270-280Hz, but note that it only receives 10 times smaller power than OMC QPDs, so the SNR is not as good anyway.

To measure the coupling TF from thermistor current to DARM, I'll route OMCD-DCPD_TEST_EXC to one of the thermistors (hot one at first, as it's mounted on the thermal compression ring which is closer to the electrical loop formed by the heater circuit).

(Sheila mentioned that when OM2 heater was off while the full connection to Beckhoff was still maintained, we didn't see the comb even though 1.66Hz thermistor switching should have been going on. It could be a magnetic coupling (e.g. the single loop electric circuit formed around the compression plate by the heater and its wires generates magnetic field that will push floppy thermistor wires that carry 1.66Hz current?) or maybe dependent on the tightness of the compression ring itself. We can easily distinguish the two by injecting into thermistors and turn off the heating . If the coupling change is instantaneous, it's probably the magnetic field.)

Images attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 22:55, Tuesday 31 October 2023 (73889)

During the maintenance, I disconnected the H1:OMC-TEST_DCPD_EXC Lemo cable from the dual DB9 breakout panel in ISC R5 by HAM6 (so that it won't injected into the DCPD whitening), and used the TNC connector above LEMO to reroute the signal to the Thermistor 2 input at the back of the OM2 heater driver.

I used the breakout board at the back of the OM2 heater driver chassis as follows:

pin 9&11 (Thermistor 2 pin A and B) -> positive out (center conductor of TNC) of H1:OMC-TEST_DCPD_EXC.

pin 22&24 (Thermistor 2 pin C and D) -> negative out (isolated shell of TNC) of H1:OMC-TEST_DCPD_EXC.

pin 10&12 (Thermistor 1 pin A and B) -> bundled together on the breakout board but not connected to anywhere else.

pin 23&25 (Thermistor 1 pin C and D) -> bundled together on the breakout board but not connected to anywhere else.

pin 6&19 (Heater Driver voltage input) -> Beckhoff driver voltage.

(Before connecting it to the thermistors, I roughly measured the voltage across the H1:OMC-TEST_DCPD_EXC pins using a scope on a battery and it had ~15mV DC and maybe 5 to 10mV RMS.)

Max power rating of the thermistor is 18mW at 25C, it's substantially hotter than 25C for Thermistor 2, so I'll make sure NOT to exceed 5mW or so out of caution. Thermistor 2 resistance is more than 4kOhm but less than 5k when hot, so the maximum voltage would be something like sqrt(5mW*4kOhm)~4.5VRMS or ~12Vpp.

I didn't have time to do any measurement today so I'll use commissioning window.

H1 AWC (AWC, CDS, DetChar-Request, ISC)
keita.kawabe@LIGO.ORG - posted 17:20, Tuesday 24 October 2023 - last comment - 10:51, Wednesday 08 November 2023(73706)
OM2 thermistor sensor voltage supplies are oscillating (Fil, Fernando, Keita)

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.

Images attached to this report
Comments related to this report
daniel.sigg@LIGO.ORG - 00:46, Thursday 26 October 2023 (73754)

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Ω.

fernando.mera@LIGO.ORG - 16:07, Friday 27 October 2023 (73782)
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.
Images attached to this comment
fernando.mera@LIGO.ORG - 17:00, Tuesday 31 October 2023 (73886)
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.
Images attached to this comment
fernando.mera@LIGO.ORG - 17:17, Thursday 02 November 2023 (73940)
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
fernando.mera@LIGO.ORG - 10:51, Wednesday 08 November 2023 (74092)

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.

H1 ISC
sheila.dwyer@LIGO.ORG - posted 10:38, Tuesday 27 June 2023 - last comment - 15:42, Tuesday 31 October 2023(70866)
OMC scan and visibility with hot OM2

It seems that the OMC single bounce mode matching is better with hot OM2 than it was with the similar measurement 70409

Daniel turned off the sidebands and manually aligned the locked OMC. 

 

Images attached to this report
Comments related to this report
jennifer.wright@LIGO.ORG - 07:15, Thursday 06 July 2023 (71100)

I used an adpated version of the OMCscan class to fit the spectrum up to 20/02 carrier modes. The scan went through two free spectral ranges so I just used the first 60s to make the analysis easier, and assuming that within this 60s of data the third smallest clear peak was 20, and the fourth one was 10 mode.

The fitted spectra is attached.

Then I used an adapted version of fit_two_peaks.py to fit a sum of two lorentzians to the 20 and 02 carrier modes, the fit is shown in the second graph.

We expect the HOM spacing to be 0.588 MHz as per this entry and DCC T1500060 Table 25.

The spacing for the modes measured is  0.549 MHz.

From the heights of the two peaks this suggests mode-mismatch of the OMC to be C02+C20/C00 = (0.457mA+0.629mA)/(16.39mA+0.457mA+0.629mA) = 6.2% mode mis-match.

From the locked/unlocked powers on the OMC REFL PD the visibility on resonance is 1-(1.84mW/22.6mW) = 92% visibility.

If the total loss is 8%, this implies that the other non-mode-matching losses are roughly 1.4%.

 


To run the OMC scan code go to 

/ligo/gitcommon/labutils/omc_scan/ and run 

python OMCscan_nosidebands2.py 1371921531 60 "Sidebands off, 10W input, hot OM2" "single bounce" --verbose --make_plot -o 2

in the labutils conda environment and on git branch dev.

To do the double peak fitting run:

python fit_two_peaks_no_sidebands2.py  
in the labutils conda environment and on git branch dev.

Images attached to this comment
Non-image files attached to this comment
sheila.dwyer@LIGO.ORG - 10:32, Tuesday 11 July 2023 (71228)

This was a single bounce scan off ITMX, with 0.44W on the ring heater upper and lower segments, and no CO2.

sheila.dwyer@LIGO.ORG - 16:10, Wednesday 19 July 2023 (71519)

Using Jennie's mode mismatch of 6.2%, we can use the ratio of locked vs unlocked reflected power to estimate the OMC losses, finesse and transmission for a perfectly mode matched beam. 

I've used a time when the fast shutter was blocked from 70409 to subtract the dark offset the refl diodes, this gives reflected power on resonance of 22.61mW, reflected power off resonance of 1.85mW.

The power in the mode mismatch is reflected_power_off_resonance * 6.2% = P_mm 1.4mW

Visibility for the 00 mode is (refl_on_resonance - P_mm)/(refl_off_resonance - P_mm) = 2.1%

The attached script uses this visibility to find the loss using:

def Refl_fraction(r_loss):
    on_res = (r1 - (t1**2 * r1 * r_loss)/(1-r1**2*r_loss))**2
    off_res = (r1 + (t1**2 * r1 * r_loss)/(1+r1**2*r_loss) )**2
    return on_res/off_res

with r1 = sqrt(reflectivity of the input output mirrors) = sqrt(1-7690e-6) from T1500060 page 143, and r_loss = sqrt(1-round trip losses).  With a visibilty of 2.1% this gives us a round trip loss of 2616ppm.  If true this level of loss would imply a finesse of 351, well lower than previous measurements: 69707.  This would imply that the transmission of the OMC cavity for a 00 mode is 73%.  

Non-image files attached to this comment
sheila.dwyer@LIGO.ORG - 15:42, Tuesday 31 October 2023 (73873)

Koji pointed out that infering losses from the visibility as I did above is very sensitive to the HOM content, and including the first order modes above would have resulted in a different value of OMC losses. 

As an alternative approach, I adapted a mathematica notebook that Koji shared to use the transmitted power along with the visibility, and infer higher order mode content and cavity transmission by making an assumption about the DCPD QE. 

One confusing point about using these reflected power measurements is that we have to correctly take into account that the beam which arrives at the OMC REFL path has reflected twice off the QPD pick off beamsplitter.  (So, the incident power on the REFL diode = incident power on OMC breadboard/ R_pick_off^2)  

The results we get for cavity losses (and higher order mode content) depend on what we assume for DCPD QE with this method.  Below are the results of the attached script run with a QE of 1 and a QE of 96%, this only makes a small change in the higher order mode content we infer, and that small change in HOM also causes a small change in what we infer for the total efficiency of the OMC breadboard in the two cases. 

Power on refl diode when cavity is off resonance: 22.612 mW
Incident power on OMC breadboard (before QPD pickoff): 23.052 mW
Power on refl diode on resonance: 1.848 mW
Measured effiency (DCPD current/responsivity if QE=1)/ incident power on OMC breadboard: 81.6 %

assumed QE: 96.0 %
power in transmission (for this QE) 19.598 mW
HOM content infered: 8.069 %
Cavity transmission infered: 93.376 %
predicted efficiency () (R_inputBS * mode_matching * cavity_transmission * QE): 81.616 %
omc efficency for 00 mode (including pick off BS, cavity transmission, and QE): 88.780 %
round trip loss: 540 (ppm)
Finesse: 396.346


assumed QE: 100 %
power in transmission (for this QE) 18.814 mW
HOM content infered: 7.903 %
Cavity transmission infered: 89.479 %
predicted efficiency () (R_inputBS * mode_matching * cavity_transmission * QE): 81.616 %
omc efficency for 00 mode (including pick off BS, cavity transmission, and QE): 88.620 %
round trip loss: 886 (ppm)
Finesse: 388.021

Images attached to this comment
Non-image files attached to this comment
Displaying reports 12641-12660 of 84373.Go to page Start 629 630 631 632 633 634 635 636 637 End