Displaying reports 3881-3900 of 83112.Go to page Start 191 192 193 194 195 196 197 198 199 End
Reports until 22:00, Monday 02 December 2024
LHO General
thomas.shaffer@LIGO.ORG - posted 22:00, Monday 02 December 2024 (81594)
Ops Eve Shift End

TITLE: 12/03 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY:
LOG: Quiet shift, been locked for just about 10 hours. DIAG_MAIN has been notifying "PSL ISS diffracted power is low" its around 2.8 right now.

X1 DTS
joshua.freed@LIGO.ORG - posted 18:55, Monday 02 December 2024 (81593)
Double Mixer Topology initial Test

J. Freed,

 

On Wednesday Nov 20th, the Double Mixer topology for SPI D2400315-x0 was taken, and it works how we intended as a way to gerenrate a 80MHz - 4096Hz signal it to but with alot of noise.

DMPrototype.png Is a diagram of the Double Mixer Design

DM_First_Test.png Is a diagram of the test done on the Double Mixer, this inital test was just to check that the Double Mixer produces the expected output signal frequency, as such, the amplifier was ignored. 

DM_FT_Result.png Shows the output on the scope.  Blue is the double mixer output. White is a reference of SRS SG382 (sync with 80 Mhz OCXO via 10 MHz Timing) with a frequency of 79,995,904 Hz and power of -0.91 dBm. The SRS signal, timed with the OCXO, and the double mixer correctly locks with eachother. This gives credance that this design will work for the goal of the double mixer; a 79,995,904 Hz signal frequency locked to a 80MHz OCXO. However there is a lot of noise in the double mixer signal. An ongoing investigation is currently underway to find and reduce this noise.

ZMSCQ_Wave_Shape.png Shows a possible source of the noise, the Double Mixer requires phase delayer for the Sin path, we used a MiniCircuts ZMSCQ-2-90B for this. I tested the ZMSCQ-2-90B by puggining the input of the signal and the signal from the 2 ports into osciloscope. I split off the input signal with a Minicircuts ZMSC-2-1BR+ (Summer/Splitter) and I had to normalize input power pickoff in postprocessing by a factor of 0.68 due to the power difference. The results show that the output of the ZMSCQ-2-90B has a sligtly different shape than what was plugged in. With the delay port (orange) having a slight "hump" on the rise. Will retake with a faster osciloscope, as the signal is very noisy.

The investigation is continuing with the next step of checking the double mixer output signal with a network anaylizer to check the frequencies around 79,995,904 Hz. A Phase noise measurement would also work with the caviot that the phase adjust to destructivly interfere the double mixer signal with the reference signal would have to be adjusted manually.

Images attached to this report
H1 ISC (SUS)
jim.warner@LIGO.ORG - posted 17:34, Monday 02 December 2024 (81589)
ETMX Glitch locklosses at around 1khz

Sheila and I were looking at one of the most recent ETMX glitch locklosses and found something interesting. About 150ms before this particular lockloss there is a glitch that saturates L3, which seems to be between a few hundred hz and 1khz. The glitch is big enough to propagate to L2 and L1 very quickly. The IFO rides out one glitch, but seems to lose lock during a similar glitch immediately after. There were also 4 other glitches that looked kind of similar during this lock, that didn't cause a lockloss. The open loop for the ESD is around 70 hz, so we think it might be possible to add some more low pass to reduce the drive on the ESD, and reduce the chance of saturating the dac. I'm looking at that.

While trying to understand the path to the dac on this SUS, Sheila and I had a hard time finding the custom screen for the parts added to the top of the ETMX sus model for the 32-bit (-ish?) DAC on that suspension. It lives on the WD tab on the sitemap, it's called DAC_TEST. Shown in the second image. There are calibration gains of 275.310 applied to top level filter banks on the output of the model, these filter screens can be opened by clicking on the rows of black OUT GAIN and OUT VAL epics readbacks on the bottom of the screen. I don't think clicking any of the 0|1 buttons in the middle of this screen is safe.

 

Images attached to this report
H1 General
oli.patane@LIGO.ORG - posted 16:36, Monday 02 December 2024 (81591)
Ops Day Shift End

TITLE: 12/03 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 157Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY:  Currently Observing at 157Mpc and have been Locked for 4.5 hours. Today we had some trouble getting DRMI to lock, and a lockloss from TRANSITION_FROM_ETMX, but nothing too difficult to fix and bypass.

LOG:

15:30 Observing at 157Mpc and have been Locked for over 2 hours

16:33 Out of Observing for Commissioning
16:58 Lockloss due to commissioning activities
    - During relocking, stopped at DRMI_LOCKED_CHECK_ASC because SRM M3 and M1 LF/RT were railed. Clearing SRCL1 history fixed M3, but not M1 LF/RT. We cleared the history on the M1 locking filters, leading to a lockloss and SRM trip. This issue happened because during the commissioning before the lockloss, SRM was accidentally moved so far out of alignment that during DRMI, ISC_LOCK thought that the lock it caught was DRMI when it was actually PRMI, which caused it to push super hard on SRM
    - Lockloss from LOWNOISE_ESD_ETMX
        - Next time we finished TRANSITION_FROM_ETMX, I waited 9 seconds after it completed before moving on to LOWNOISE_ESD_ETMX
    - Multiple locklosses from lower states like ALS and IR

20:02 NOMINAL_LOW_NOISE
20:08 Observing                                                                                                                                                                                                                                                                                                                                    

Start Time System Name Location Lazer_Haz Task Time End
16:16 FAC Karen OptLab/VacPrep n Tech clean 16:42
18:05 FAC Karen MY n Tech clean 18:58
18:54 VAC Jordan, Gerardo LVEA n Moving leak cart 19:33
22:34   RyanC OpticsLab n Testing blues 23:36
23:15 FAC Tyler Along XARM n Taking inventory 00:29
LHO General
thomas.shaffer@LIGO.ORG - posted 16:29, Monday 02 December 2024 (81590)
Ops Eve Shift Start

TITLE: 12/03 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 157Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 0mph Gusts, 0mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.34 μm/s
QUICK SUMMARY: Observing for over 4 hours, calm environment.

H1 SEI (SEI)
ryan.crouch@LIGO.ORG - posted 13:23, Monday 02 December 2024 (81585)
BRS Drift Trends - Monthly - FAMIS

Closes FAMIS26449 ,last checked in alog80350

BRS-Y temperature looks to be slowly trending upwards since ~10/22.

Images attached to this report
LHO VE
david.barker@LIGO.ORG - posted 11:24, Monday 02 December 2024 (81580)
Mon CP1 Fill

Mon Dec 02 10:12:17 2024 INFO: Fill completed in 12min 13secs

Gerardo confirmed a good fill curbside.

Images attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 11:22, Monday 02 December 2024 - last comment - 17:33, Monday 02 December 2024(81579)
cdslogin rebuild

WP12223 FRS32776

Jonathan, Erik, Dave:

cdslogin is currently down for a rebuild following a disk failure yesterday. Alarms and Alerts are currently offline. EDC has 58 disconnected channels (cdslogin epics_load_mon and raccess channels).

Comments related to this report
erik.vonreis@LIGO.ORG - 17:33, Monday 02 December 2024 (81592)

Rebuild is finished.  Alarms are working again.

H1 ISC
camilla.compton@LIGO.ORG - posted 09:40, Monday 02 December 2024 (81575)
SRCL offset changes FCC, started to move SRM to increase FCC but lost lock.

Sheila, Dripta, Camilla. Repeat of 78776

Turned off H1:LSC-SRCL1_OFFSET with ramp time at 10s. Offset off made the FCC drop ~2%. See attached plot. Left H1:LSC-SRCL1_OFFSET off.

Turned SRC1 ASC loops inputs off (would have quickly with ramptime 0.1s turned off offsets too but offsets were already off). Set the ramp to 10s, turn gain to 0, clear history, gain back to 4.

We then started stepping SRM Y in steps of 0.5. This was too big, we lost lock (sorry). It seems we actually moved 500+ urad rather than the expected 0.5urad and this caused a lockloss <0.5s latter, plot attached. Sorry. I moved the alignment slides back while Oli was locking as they are getting SRM saturations.

We would have aimed to increase H1:CAL-CS_TDEP_F_C_OUTPUT with SRM moved (SRC2 was left closed and would have moved SR2 to compensate). Then this SRM location could have been used as the SRSCL1 ASC offsets.  Then we could have taken a SQZ FIS dataset (eg 80318) to find the best SRCL offset.

Images attached to this report
H1 General (Lockloss)
oli.patane@LIGO.ORG - posted 09:00, Monday 02 December 2024 - last comment - 12:09, Monday 02 December 2024(81576)
Lockloss

Lockloss @ 12/02 16:58 UTC after 3:39 locked due to commissioning activities

Comments related to this report
oli.patane@LIGO.ORG - 12:09, Monday 02 December 2024 (81581)

Back to Observing as of 20:08UTC

H1 General
oli.patane@LIGO.ORG - posted 07:37, Monday 02 December 2024 - last comment - 12:47, Monday 02 December 2024(81574)
Ops Day Shift Start

TITLE: 12/02 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 157Mpc
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 4mph Gusts, 2mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.46 μm/s
QUICK SUMMARY:

Observing and have been Locked for over 2 hours. Secondary useism looks to be going up a bit in the past few minutes.

Comments related to this report
oli.patane@LIGO.ORG - 10:45, Monday 02 December 2024 (81578)Lockloss

Lockloss from last night - December 02 @ 11:48 UTC

Last night's lockloss has some interesting things happening right before the lockloss.

Images attached to this comment
LHO General
thomas.shaffer@LIGO.ORG - posted 22:00, Sunday 01 December 2024 - last comment - 14:26, Monday 02 December 2024(81569)
Ops Eve Shift End

TITLE: 12/02 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 142Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: A long relock today from DRMI locking struggles and lock losses at Transition_From_ETMX. Once back up to observing the range hasn't been very stable, hovering between 140-150Mpc. I was waiting for a drop in triple coincidence before trying to tune squeezing, but that didn't happen before the end of my shift. The 15-50Hz area in particular looks especially poor.
LOG:

Comments related to this report
camilla.compton@LIGO.ORG - 09:54, Monday 02 December 2024 (81577)

Plot of range and glitches attached.

It didn't look like the explicitly squeezing was the issue last night when the range was low as SQZ was stable, sqz plot. The range seemed to correct itself on it's own as we stayed in Observing. If it happens agin, we could have gone to NoSQZ or FIS to check it's not backscatter from SQZ of FC.

Oli and I ran a Bruco during the low range time, bruco website, but Shiela noted that the noise looks un-stationary like scatter so that a bruco isn't the best way of finding the cause.

Images attached to this comment
ryan.crouch@LIGO.ORG - 13:13, Monday 02 December 2024 (81584)ISC

I ran a range comparison using 50 minutes of data from a time in the middle of the bad range and a time after it stops with good range. Excess noise looks to be mostly below 100 Hz for sensmon, for DARM the inflection point looks to be at 60Hz and there is broadband noise but low frequency again seems larger.

I also checked these same times in my "Misaligned" GUI that compares SUS top mass osems, witness sensors, and OPLEVS avg motion to compare alignments for relocking and to look for drifts. It doesn't look all that useful here, the whole IFO is moving together throughout the lock. I ran it for seperate times within the good range block as well and it look pretty much the same.

Images attached to this comment
Non-image files attached to this comment
camilla.compton@LIGO.ORG - 13:32, Monday 02 December 2024 (81586)OpsInfo

As discussed in today's commissioning meeting, if this low range with glitches on Omicron at low frequency happens again, can the operator take SQZ_MANAGER to NO_SQUEEZING for 10 minutes so that we can check this isn't caused by backscatter from something in HAM7/8. Tagging OpsInfo.

derek.davis@LIGO.ORG - 13:41, Monday 02 December 2024 (81587)DetChar, SQZ

Runs of HVeto on this data stretch indicate extremely high correlations between strain glitches and glitches in SQZ FC channels. The strongest correlation was found with H1:SQZ-FC_LSC_DOF2_OUT_DQ.  

The full HVeto results can be seen here: https://ldas-jobs.ligo-wa.caltech.edu/~detchar/hveto/day/20241202/1417132818-1417190418/

An example of H1 strain data and the channel highlighted by HVeto can be seen in the following attached plots: 

Images attached to this comment
oli.patane@LIGO.ORG - 14:26, Monday 02 December 2024 (81588)DetChar, TCS

Derek also so kindly ran lasso for that time period (link to lasso run) and the top correlated channel is  H1:TCS-ITMX_CO2_ISS_CTRL2_OUT_DQ. Back in May we were seeing correlations between drops in range, FC alignment, and the values in this same TCS channel(78089). Here's a screenshot of the range vs that channel - the TCS channel matches with how it was looking back in May. As stated in that May alog thread, the cable for this channel was and is still unplugged :(

Images attached to this comment
H1 General (ISC)
thomas.shaffer@LIGO.ORG - posted 17:33, Sunday 01 December 2024 - last comment - 15:12, Tuesday 03 December 2024(81570)
A few lock losses from Transition_From_ETMX

We've now had two lock losses from the Transition from ETMX state or immediately after while trying to reacquire. Unlike back on Nov 22 (alog81430), SRCL seems fine. For the first one, the locklost tool 1417133960 shows the IMC-SERVO_SPLITMON channel is saturating ~5sec before lock loss, then there is some odd LSC signals 40msecs before the tool tagged the lock loss (attachment 1). This might just be the lock loss itself though. The second one (locklost tool 1417136668) hasn't tagged anything yet, but ETMY has a glitch 2.5 sec before lock loss and ETMX seems to move more from that point (attachment 2).

Images attached to this report
Comments related to this report
thomas.shaffer@LIGO.ORG - 19:33, Sunday 01 December 2024 (81571)

Another one while I was looking at the code for the Transition_From_ETMX state. We were there for a few minutes before I noticed CHARD & DHARD inputs ringing up. Unsure how to save it, I just requested it to move on but it lead to a lock loss.

Images attached to this comment
thomas.shaffer@LIGO.ORG - 20:08, Sunday 01 December 2024 (81573)

I ended up changing the SUS-ITMX_L3_LOCK_BIAS_TRAMP to 25 from its 30 to hopefully move to a safer place sooner. Since it was already changed from 60 a week ago, I didn't want to go too short. Worked this one time.

camilla.compton@LIGO.ORG - 15:04, Monday 02 December 2024 (81582)

Sheila, Camilla

We had another lockloss with an ETMX_L2 glitch beforehand this morning, plot, and it seems that even a successful transition this morning had a glitch too but it was smaller plot. We looked at the ISC_LOCK.py code and it's not yet obvious what's causing this glitch. The successful transition also had a DARM wobble up to 2e6 plot but when we have the locklosses, DARM goes to ~10e6.

While looking at all the filters, we found that ETMX_L2_LOCK_L ramp time in 20s screenshot although we only wait 10s in ISC_LOCK. We will edit this tomorrow  when we are not observing. We don't think this will effect the glitch as there is no input/output to this filter at the time of the glitch.

The only thing that seems like it could cause the glitch is the DARM1 FM1 being turned off, we don't yet understand how and had similar issues we thought we solved in  77640

Images attached to this comment
camilla.compton@LIGO.ORG - 15:12, Tuesday 03 December 2024 (81601)

This morning I edited ETMX_L2_LOCK_L FM1 ramp time down to 10s, reloaded coefficients. 

Displaying reports 3881-3900 of 83112.Go to page Start 191 192 193 194 195 196 197 198 199 End