Displaying reports 1641-1660 of 80668.Go to page Start 79 80 81 82 83 84 85 86 87 End
Reports until 12:36, Wednesday 20 November 2024
H1 PSL (ISC)
elenna.capote@LIGO.ORG - posted 12:36, Wednesday 20 November 2024 - last comment - 16:36, Thursday 21 November 2024(81385)
PMC Calibration

Sheila and I spent some time today trying to calibrate the PMC channels into units of frequency so we can compare the glitches seen by the PMC with other channels. Peter's alog comment last night (81375) leads us to understand the glitches are around 2 kHz in frequency, so above the PMC bandwidth. Therefore, we want to calibrate the PMC error signal.

Luckily for us, Jeff Kissel recently did some PMC scans to determine the PMC PZT Hz/V calibration for a different purpose, alog 73905 (thanks Jeff!). We used his DTTs to determine the time it took to scan one FSR, see screenshot. We determined that it took 0.52 seconds to scan one FSR, and the scan rate is approximately 6.75 V/s (we know the PZT is nonlinear, but we figure this estimate is good enough for our purposes). This gives us 3.51 V/FSR on the PZT, or 0.0236 V/MHz, using the FSR = 148.532 MHz from T0900616.

We are still thinking about how to calibrate the PMC mixer signal.

Images attached to this report
Comments related to this report
victoriaa.xu@LIGO.ORG - 16:36, Thursday 21 November 2024 (81408)

Daniel calibrated the PMC mixer signal using the PMC PDH signal, lho81390.

H1:PSL-PMC_MIXER_OUT_DQ calibration is  1.25 Vpp / 1.19 MHz (fwhm) = 1.05 V / MHz. 

See his note about H1:PSL-PMC_MIXER_OUT_DQ: "the channel recorded by the DAQ has a lot of gain and clips around +/-80mV, but it is calibrated correctly" compared to live traces on an oscilloscope.

LHO VE
david.barker@LIGO.ORG - posted 10:47, Wednesday 20 November 2024 (81384)
Wed CP1 Fill

Wed Nov 20 10:11:17 2024 INFO: Fill completed in 11min 13secs

 

Images attached to this report
H1 AOS
sheila.dwyer@LIGO.ORG - posted 10:17, Wednesday 20 November 2024 (81383)
SQZ TTFSS error check changes, PSL FSS off

Vicky, Sheila

Last night the squeezer FSS was off during our test of running the PMC with the FSS unlocked and unplugged.  This is because of some error checking that was written when the squeezer (and ALS) pick offs were from the reference cavity transmission, so there were too check on the reference cavity transmitted power, and an error check on the reference cavity transmission PD.   Since the reference cavity was unlocked the automation had an error overnight and didn't lock the SQZ TTFSS.

This morning we changed the H1:PSL-REFCAV_TRANS_DC_LOW from 0.3 to -0.1, and changed H1:SQZ-FIBR_LOCK_REFCAV_TRANSLIM to -0.1, so that the squeezer FSS will stay locked.

The PSL FSS has been powered down with the squeezer FSS on since 17:45 UTC Nov 20th.

H1 CDS
david.barker@LIGO.ORG - posted 08:43, Wednesday 20 November 2024 (81380)
More EY CNS-II 1PPS jumps to -0.8uS

For about 50 minutes starting at 01:45 PST this morning we had another jump of the EY CNS-II reference GPS 1PPS compared with the LIGO timing. Previous jump was Mon 18nov2024 05:55. Prior to that no jumps for 3 weeks since the power supply was replaced.

Images attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 08:05, Wednesday 20 November 2024 (81376)
Power glitch 07:00:26 PST

We had a slight mains power glitch at 07:00:26 PST this morning, the GC UPS reported being on battery power for 4 seconds.

Attached plot shows all three phases in the corner station CER.

Images attached to this report
H1 PSL
ryan.crouch@LIGO.ORG - posted 07:36, Wednesday 20 November 2024 (81374)
FSS high voltage restored

Richard turned back on the high voltage and plugged back in the DB37 cable that was unplugged yesterday afternoon.

H1 General
ryan.crouch@LIGO.ORG - posted 07:30, Wednesday 20 November 2024 - last comment - 08:53, Wednesday 20 November 2024(81373)
OPS Wednesday DAY shift start

TITLE: 11/20 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Microseism
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM_EARTHQUAKE
    Wind: 17mph Gusts, 11mph 3min avg
    Primary useism: 0.40 μm/s
    Secondary useism: 1.56 μm/s
QUICK SUMMARY:

Comments related to this report
ryan.crouch@LIGO.ORG - 08:53, Wednesday 20 November 2024 (81377)PSL

The minor frequency power glitch earlier this morning 07:00:26 tripped off the NPRO, 50ms after the glitch started the NPRO tripped.

Images attached to this comment
H1 PSL (ISC)
ryan.short@LIGO.ORG - posted 22:13, Tuesday 19 November 2024 - last comment - 18:39, Wednesday 20 November 2024(81371)
PMC Glitch Testing

Since the secondary microseism has been very high this evening and preventing H1 from locking, we decided to leave just the PMC locked (no FSS, ISS, or IMC) for an extended time and watch for any glitches. At around 23:45 UTC, we unlocked the FSS, Richard turned off the high voltage supply for the FSS, and Jason and I unplugged the DB37 cable from the FSS fieldbox in the PSL-R1 rack in order to ensure no feedback from the FSS made it to the NPRO. Pictures of the DB37 cable's location are attached.

The first attachment shows the changes seen when the FSS was unlocked. Since then, I've seen several instances of groups of glitches come through, such as those shown in the second and third attachments. These glitches in the PMC_MIXER channel are smaller than ones seen previously that have unlocked the IMC (like in alog81228). There have also been times where the PMC_MIXER channel gets "fuzzier" for a bit and then calms down, shown in the fourth attachment; it's possible this is due to the NPRO frequency not being controlled so the PMC sees some frequency changes? Finally, I only recall one instance of the NPRO jumping in power like in the final attachment; the PMC doesn't seem to care much about this, only having one very small glitch at this time.

I'll leave the PSL in this configuration to collect more data overnight as the secondary microseism is still much too high for H1 to successfully lock.

Images attached to this report
Comments related to this report
peter.fritschel@LIGO.ORG - 07:46, Wednesday 20 November 2024 (81375)

A zoom-in on some of the glitches from the third figure above.

Images attached to this comment
sheila.dwyer@LIGO.ORG - 08:55, Wednesday 20 November 2024 (81379)

After Ryan's shift ended last night, there were some larger glitches, with a similar amplitude in the PMC mixer channel to the ones that we saw unlocking the reference cavity 81356 (and IMC in 81228)

The first plot shows one of these times with larger glitches, the second one zooms in for 60ms when the glitches were frequent, this looks fairly similar to Peter's plot above. 

The period of large glitches started around 2 am (7:37 UTC on Nov 20th), and ended when a power glitch turned off the laser at 7 am (15 UTC) 81376.  Some of the small glitches in that time frame time seem to be at the same time that the reference cavity was resonanting (with low transmission), but many of the large glitches do not line up with times when the reference cavity was resonanting. 

I've zoomed in on most of the times when the PMC mixer glitches reached 0.1, and see that there are usually small jumps in NPRO power at the time of these glitches, although the times don't always line up well and the small power glitches are happening very often so this might be a coincidence.

 

 

Images attached to this comment
victoriaa.xu@LIGO.ORG - 09:47, Wednesday 20 November 2024 (81381)

Sheila, Jason, Vicky - Compared the PSL + PMC mixer glitches between last night (Nov 22, 2024, no FSS no ISS) and the emergency vent (Aug 2024, PSL+PMC+FSS+ISS), as in 81354.

  • Previously 80999, the IMC could not stay locked for long periods of time: "IMC losses lock when it's locked by itself, with PMC, FSS, and ISS."
  • Fixed a bunch of things last week, but then still had many fast "IMC"-tagged locklosses over the weekend. Hard to tell the cause.
  • Start removing stuff again this week, to isolate problem upstream of the IMC.
  • Laser + PMC + FSS (no ISS)   = bad still glitchy 81356.  Rules out ISS and likely IMC as cause of glitches.
  • Laser + PMC (no FSS no ISS) = bad still glitchy 81371.  FSS depowered and HV off to really turn FSS "off".  Rules out FSS as cause of glitches.

As a reference, "before" during the emergency vent in August 2024, the Laser + PMC + FSS + ISS were all locked with no PMC mixer glitches for >1 month.

 

Updating our matrix of tests to isolate the problem, and thinking things through:

Before (vent Aug 2024) Now (Nov 2024)
laser + PMC + FSS + ISS good = no glitches laser + PMC + FSS bad = glitches 81356
laser + PMC ??? (presumably good) laser + PMC bad = same PMC mixer glitches 81371

1) Are these +/-0.1 V PMC mixer glitches the problem? Yes, probably.

2) Are these big PMC mixer glitches caused or worsened by the FSS? No. PMC mixer glitches basically same with FSS on 81356 and off 81371

3) Are the laser + PMC mixer glitches new? Yes, probably.  If these PMC glitches always there, could it be that we were previously able to ride them out before, and not now? But this would imply that in addition to the new glitches, the FSS secondarily degraded. Seems very unlikely: already several problems (bad amp, new eom needed new notch, etc) have been fixed with FSS, and the FSS OLTFs and in-loop spectra look good. FSS on/off does not change the PMC mixer glitches, so the problem seems most likely laser or PMC.

Images attached to this comment
victoriaa.xu@LIGO.ORG - 18:39, Wednesday 20 November 2024 (81391)ISC, PSL

Sheila, Daniel, Jason, Ryan S, many others

We think the problem is not the PMC, and likely the laser.

Daniel looked at PMC mixer gliches on the remote scope: 81390. If PMC mixer glitches are indicative of the problem, we can try to track down the origin of the glitches.

  • What can cause PMC mixer glitches?     
    1. NPRO Laser frequency glitches .... seems likely
    2. PMC cavity length glitches (e.g. servo electronics or PZT) ....  most likely no  81390.
    3. Likely PDH is optically sensing real glitches, as we have already switched the 35.5 MHz LO to the Marconi 81277, that made no difference ...... rule out the 35.5 MHz LO.
       
  • Unlikely PMC, because the PMC mixer glitches on the scope seem too fast for the PMC locking electronics.
    1. Daniel found that the "PMC servo drives the PZT with a 3.3K series resistor forming a ~1kHz low pass with the PZT capacitance of ~45nF. This yields a chracteristic time constant of ~150us. The glitches as seen by the PMC mixer are at least a few times faster than this." 81390
      • Daniel's scope photo here shows "a train of PMC mixer glitches, going as high as ~70mVpk (or ~70kHz)", similar to the zoomed-in glitches Peter showed above.
    2. So, this means that glitches originating in the PMC locking servo or PZT electronics would change the PMC cavity length too slowly to create the fast PMC mixer glitches we observe. Seems unlikely that PMC servo locking electronics are the issue.
    3. Unlikely mechanical / PZT issues given the very nice PMC cavity scans - optically, the cavity scans don't show glitches or issues as a function of the PZT drive (remote scope traces + sheila pmc pzt scan photo).
       
  • Biggest change to the glitches came from swapping the original O4 laser to now the O3 laser. Glitches changed when lasers changed: see Camilla lho:81386. Seems like a clue that the glitches are related to the specific lasers themselves.

 

Talking with Jason and RyanS, some summary of the NPROs available:

  • (S/N 1661) The O3 NPRO was swapped in recently. Potentially we now see the same problems with 1661 was seen in the end of O3b.
    • Camilla's 81386 shows that the FSS oscillations with this laser in O4 look a lot like its issues at the end of O3b.
    • In 2020, these FSS issues originally prompted Camilla to create the FSS_OSCILLATION tags. These FSS_OSCILLATION tags started to be flagged regularly again in mid-Sept 2024, but with the original O4 laser, the FSS oscillations looked totally different: see her log 81386.
       
  • (S/N 7974) The original O4 NPRO was in use Sept 2017 - June 2018, when it was uninstalled (42652) seemingly due to similar fast FSS glitches, leading to a broken noise eater. Jason looked at alogs from time of removing this NPRO in 2018, and the 2018 glitches look like the original Sept 2024 glitches.  7974 was then sent back to Coherent for repair + refurbished. This is the newest NPRO bought in 2015, and the only one that Coherent will service.  Then 7974 was installed for O4. 
     
  • (S/N 1639F) The "third" NPRO is from O1, and was in use for many years 2011-2017. It was wearing out its lifetime and running out of power, then removed and refurbished. Since, was only used a few times in the optics lab. Will try this 3rd NRPO.
Images attached to this comment
LHO General
ryan.short@LIGO.ORG - posted 22:10, Tuesday 19 November 2024 (81372)
Ops Eve Shift Summary

TITLE: 11/20 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Microseism
INCOMING OPERATOR: None
SHIFT SUMMARY: H1 remained unlocked the whole evening due to very high secondary microseismic motion, and there is no plan to attempt locking overnight. In the meantime, we took the opportunity to leave just the PMC locked to look for glitches (more details in alog81371). Very quiet evening otherwise with nothing else to report.

Images attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 21:28, Tuesday 19 November 2024 (81370)
BSC3 vacuum gauge glitch, vacstat reset

At 17:52:10 PST Tue 19 Nov 2024 we had another sharp positive glitch in the BSC3  vacuum gauge signal (PT132_MOD2). VACSTAT did not alarm because no other gauge tripped around this time. The glitch was a 2 second wide square wave, and as before it was the delta-P which tripped.

vacstat was reset at 18:39 to restore it to its monitoring state.

Images attached to this report
H1 DAQ (CAL, CDS, GRD)
anthony.sanchez@LIGO.ORG - posted 17:18, Tuesday 19 November 2024 (81368)
PCALX_STAT Guardian Node

I startedtesting the PCALX_STAT Guardian node today.

/opt/rtcds/userapps/release/cal/h1/guardian/PCALX_STAT.py

It created a new ini file, But the DAQ was not restarted after this new ini file creation.
As it currently stands this is a draft of the final product that will be tested for a week and further refined.
This Guardian node, does not make any changes to the IFO, it's only job is to determine if PCALX arm is broken or not. TJ has already added it to the Guardian Ignore list. 
 

H1 General (Laser Transition)
ryan.crouch@LIGO.ORG - posted 16:35, Tuesday 19 November 2024 (81349)
OPS Tuesday day shift summary

TITLE: 11/19 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: 2ndary microseism has been consistently high (above the 90th percentile) for the whole day and has risen even more in the last few hours of the shift and has reached the top of the plot. It will likely will get even worse tomorrow as the storm off the pacific coast closes in. Wind has been pretty low today. ITMY5/6 is still kind of high.

As of 23:30 UTC we're back to sitting in idle, we unlocked the FSS, ISS, and IMC just leaving the PMC locked.
LOG:

Start Time System Name Location Lazer_Haz Task Time End
21:41 SAF Laser LVEA YES LVEA is laser HAZARD 17:55
16:08 FAC Eric EndX N Glycol piping famis task, upright fallen portapotty by FCES 16:50
16:14 TCS TJ, Camilla LVEA Y CO2Y table cable jiggling 17:01
16:17 FAC Kim & Karen FCES N Tech clean 16:31
16:19 FAC Tyler LVEA N Verify strobes in H2/PSL area 16:28
16:20 FAC Tyler + Cascade Fire OSB, Ends N Fire alarm testing 18:54
16:27 FAC Tyler, Tristan EndX N Fire alarm testing 18:47
16:30 FAC Kim EndX N Tech clean 17:19
16:31 FAC Karen EndY N Tech clean 17:35
17:00 ISC Sheila LVEA Y Unplug ISS Feed forward 17:08
16:34 VAC Jordan LVEA Y->N Prep new scroll pumps, gauge swap 20:04
16:41 FAC Chris + Fire LVEA Y Check fire ext. 17:10
16:59 VAC Gerardo LVEA Y->N Join Jordan, Scroll pumps 20:04
17:03 OPS Camilla LVEA Y -> N LASER HAZARD transition 17:20
17:08 FAC Chris + Cascade fire EndY N Fire checks, End then mid 18:54
17:10 VAC Janos LVEA Y Join VAC team 17:53
17:20 CDS Marc, Fil EndX N DAC swap 18:12
16:45 EPO Corey+1 EndY N Pictures 17:15
17:30 FAC Kim FCES N Tech clean 18:00
17:32 VAC Janos LVEA N Pump/Gauge work 18:35
17:36 FAC Karen FCES N Tech clean 18:00
17:42 OPS Oli LVEA N Grab power meter 17:47
17:47 SEI Jim CR N BS and ITM sei tests 18:22
17:00 ISC Daniel LVEA Y Investigations, scope installation 17:52
17:56 SAF LASER LVEA N LVEA is LASER SAFE 20:46
17:57 ALS Camilla, Oli EndY Y Beam profiling 19:54
18:01 FAC Richard LVEA N Walk around 18:21
18:02 ISC Keita LVEA N Cable checks 18:29
18:16 ISC Sheila CER N Plug and unplug FF cable 18:40
18:22 VAC Janos EndX then EndY N Scroll pumps 19:25
18:22 SEI Jim LVEA Biergarten / CR N working on Seismic sub systems 19:55
17:30 EPO Corey+1 LVEA N B-Roll 18:25
18:37 FAC Kim & Karen LVEA N Tech clean, Kim out 19:37 19:53
18:54 FAC Tyler+Cascade Mids N Fire checks 20:20
19:25 VAC Janos LVEA N Join VAC team 20:04
19:56 SEI Jim LVEA N Take pictures 20:06
20:03 OPS Oli LVEA N Return power meter 20:11
20:11 CAL Tony PCAL lab Y Make it laser safe 21:07
20:40 CAL Francisco PCAL lab Y PCAL work 22:28
20:43 OPS/TCS TJ LVEA N-> Y -> N HAZARD TRANSITION then CO2Y table adjustment, back to safe 21:13
20:48 TCS Camilla LVEA Y Join TJ, CO2Y table 21:13
21:17 SAF LVEA LASER SAFE LVEA N LVEA IS LASER SAFE 01:17
21:31 ISC Keita LVEA N AS_B SEG3 testing 21:49
21:47 OPS Oli LVEA N Sweep 22:13
23:37 PSL RyanS, Jason CER, PSL racks N Pull cable  

IFO/Locking:

Some of the maintenance work completed includes:

We did not do a DAQ restart

Images attached to this report
H1 PSL
victoriaa.xu@LIGO.ORG - posted 11:42, Tuesday 19 November 2024 - last comment - 17:53, Tuesday 19 November 2024(81354)
PSL PMC + FSS was continuously locked over emergency vent

It looks like usually the PSL PMC + FSS can stay locked for long periods of time, for example >1 month over the emergency vent in August. See the attached trends of the # of locked days and hours in the last few months (ndscope saved as /ligo/home/victoriaa.xu/ndscope/PSL/pmc_fss_can_stay_locked_over_emergency_o4b_vent.yaml).

The last time the PMC was locked for almost a month ended on Sept 23, 2024. Since then the PSL PMC has not stayed locked for over 5 days, but this is most likely due to commissioning tests and debugging which started around then.

Images attached to this report
Comments related to this report
victoriaa.xu@LIGO.ORG - 13:20, Tuesday 19 November 2024 (81357)

Some trends showing several PSL signals over O4b, and the end of O4a.

Key points- PMC + FSS stayed locked continuously during both the O4a/b break (Feb 2024), and the emergency vent (Aug 2024), with minimal glitching in PMC TRANS and Ref Cav Trans PD (FSS-TPD).

Images attached to this comment
victoriaa.xu@LIGO.ORG - 17:53, Tuesday 19 November 2024 (81369)

Trying to compare PSL-related spectra between the original O4 NPRO and the current NPRO using DTT is kinda confusing.

Comparing times with before O4 NPRO from 21 Oct 2024 04:55 UTC (blue, 169 Mpc), and now with O3 NPRO at 16 Nov 2024 08:20 UTC (red, 169.9 Mpc).

For the fast mon spectra in the top left plot, FSS FAST MON OUT looks 2-5x noisier now than before. H1:PSL-FSS_FAST_MON_OUT_DQ calibrated into Hz/rtHz using zpk = ([], [10], [1.3e6])  (see 81251, this makes H1 and L1 spectra into comparable Hz/rtHz units 81210).

But for FSS-TPD (ref cav trans), it looks like there's some extra 1-10Hz noise, but otherwise the trans spectra might be quieter? Similarly confusing, the ISS AOM control signal looks quieter. Not a clear takeaway from just these spectra on how to compare O3/O4 NPROs.

Images attached to this comment
H1 CDS
david.barker@LIGO.ORG - posted 09:33, Tuesday 19 November 2024 - last comment - 09:45, Wednesday 20 November 2024(81350)
h1susex powered down for DAC change

WP12201

Marc, Fil, Dave, Ryan

h1susex is powered down to restore cabling from the new 28bit LIGO-DAC to the original 20bit General Standards DACs.

Procedure:

Put h1iopseiex SWWD into long bypass

Safe the h1susetmx, h1sustmsx and h1susetmxpi models

Stop all models on h1susex

Fence h1susex from the Dolphin fabric

Power down h1susex.

Comments related to this report
marc.pirello@LIGO.ORG - 11:01, Tuesday 19 November 2024 (81353)

WP12201

D. Barker, F. Clara, M. Pirello

Swap to original 20 bit DAC complete.  Here are the steps we took to revert from LD32 to GS20

  1. Power off IO-SUS-ETMX with Dave's help, suspension set to safe.
  2. Move PI DB9 cable from new PI AI chassis (S1500301) to old PI AI chassis (S1500299).  This is on the front of the chassis (channels 6 and 7)
  3. Unplugged ESD-LD32 cable from the old PI AI chassis.(S1500299) on the back, DAC adapter 0.
  4. Unplugged ESD-LD32 cable from IO-SUS-ETMX slot 8 (LD32 bank 0)
  5. Move ETMX-86 from the new PI AI chassis (S1500301) to old PI AI chassis (S1500299) on the back DAC adapter 0  
  6. Removed WD-Bypass-Cable from slot 5 of the IO-SUS-ETMX and DAC adpater 1 of old PI AI chassis (S1500299) on the back. 
  7. Move ETMX-42 from IO-SUS-ETMX slot 10 (LD32 bank 2) to IO-SUS-ETMX slot 5 (GS 20 bit DAC).
  8. Power on IO-SUS-ETMX and verify watchdogs reapplied.

Included images of front and rear of rack prior to changes.

 

Images attached to this comment
david.barker@LIGO.ORG - 09:45, Wednesday 20 November 2024 (81382)

Tue19Nov2024
LOC TIME HOSTNAME     MODEL/REBOOT
09:59:38 h1susex      h1iopsusex  
09:59:51 h1susex      h1susetmx   
10:00:04 h1susex      h1sustmsx   
10:00:17 h1susex      h1susetmxpi 
 

H1 AOS
neil.doerksen@LIGO.ORG - posted 15:37, Wednesday 13 November 2024 - last comment - 08:12, Friday 22 November 2024(81257)
NN Seismic Array HS-1 Install

2024 Nov 12

Neil, Fil, and Jim installed an HS-1 geophone in the biergarten (image attached). HS-1 is threaded to plate and plate is double-sided taped to the floor. Signal given was non-existent. Must install pre-amplifier to boost signal.

2024 Nov 13

Neil and Jim installed an amplifier (SR560) to boost HS-1 signal (images attached). Circuitry checked to ensure signal makes it to the racks. However, when left alone there is no signal coming through (image attached, see blue line labelled ADC_5_29). We suspect the HS-1 is dead. HS-1 and amplifier are now out of LVEA, HS-1's baseplate is still installed. We can check one or two more things, or wait for more HS-1s to compare.

Images attached to this report
Comments related to this report
jim.warner@LIGO.ORG - 16:45, Tuesday 19 November 2024 (81367)SEI

Fil and I tried again today, we couldn't get this sensor to work. We started from the PEM rack in the CER, plugging the HS1 through the SR560 into the L4C interface chassis, confirming the HS1 would see something when we tapped it. We then moved out to the PEM bulkhead by HAM4, again confirmed the HS1/SR560 combo still showed signal when tapping the HS1. Then we moved to the biergaren and plugged in the HS1/SR560 right next to the other seismometers. While watching the readout in the DAQ of the HS1 and one of the Guralps I have connected to the PEM AA, we could see that both sensors could see when I slapped the ground near the seismometers, but the signal was barely above what looks like electronics noise on the HS1, while the Guralp showed lots of signal that looked like ground motion. We tried gains from 50-200 on the SR560, none of them really seemed to improve the snr of the HS1. The HS1 is still plugged in over night, but I don't think this particular sensor is going to measure much ground motion.

brian.lantz@LIGO.ORG - 08:12, Friday 22 November 2024 (81413)

One check for broken sensors - A useful check is to be sure you can feel the mass moving when the HS-1 is in the correct orientation. A gentle shake in the vertical, inverted, and horizontal orientations will quickly reveal which orientation is correct.

H1 PSL (CSWG, ISC, SEI)
jeffrey.kissel@LIGO.ORG - posted 14:23, Wednesday 01 November 2023 - last comment - 12:37, Wednesday 20 November 2024(73905)
(My) First Attempt at Measuring H1 PSL PMC Cavity Sweep (Process and Raw Data)
J. Kissel (with help/advice from J. Driggers, S. Dwyer, J. Oberling)
WP 11493

Why am I doing this PRIMER
We're yak-shaving again; this time in support of better understanding what the eventual frequency / phase noise will be incoming from a PSL pick-off (at the point of RefCav reflection much like SQZ or ALS fiber pickoffs, see D1300348) for the current design of SPI L (see G2301177; the longitudinal, or "L" DOF of future seismic platform interferemeters "SPI"), corroborating current estimates shown in SWG:12112. 

The idea is to establish a "[Hz / V]" linear calibration for the PMC length control PZT, such that once established, we can measure the PSL "frequency noise" in various configurations of the detector (e.g. "only RefCav locked," "only IMC + RefCav," "full IFO CARM + IMC + RefCav"). Critically, for the planned frequency-band in which we plan to use SPI L for ISI platform control -- we care about "frequency noise" delivered on the fiber in the 0.01 to 5 Hz region; this *not* a frequency region typically plotted -- from 10 to 10000 Hz, since that's where the main interferometer (IFO), or frequency-dependent squeezer (FDS or SQZ), or arm length stabilization (ALS), systems care about frequency noise (see e.g. chapter of 3 of P1800022 or chapter 6 of P2200287) -- so it's been a struggle to find plot of this noise in the frequency band we need.

Notice that I put "frequency noise" in quotes. This is because, for a single fabry perot cavity (be it linear, triangular, or bowtie) on resonance,
     1        lambda0       1.       lambda0  
    ---- df = ------- df = ---- dL = ------- dphi
     f0          c          L0       2*pi*L0

where 
    df = actual frequency noise of the laser, whose frequency is f0
        lambda0 = wavelength of the laser
        c = speed of light = lambda0 * f0
    dL = actual cavity length / acoustic noise
        L0 = the roundtrip length of the cavity
    dphi = phase noise of the laser

which means that (a) all of these noises can be re-cast as version of each other if you know the laser wavelength and cavity length, and (b) that *sources* of these noise can all get confused together when you're just measuring one thing, e.g. the typical error signal -- the reflected light from the cavity. This fact, (b), is why I but "frequency noise" in quotes, or call it *effective* frequency noise. 

Now -- the PMC itself is a cavity that is in-air, relatively short, and relatively low finesse. As such, the PSL PMC will never measure the *actual* full IFO CARM + IMC + RefCav *actual* frequency noise, since that frequency (or length, or phase) noise is established with the full 4 km arm cavities, suspended on a BSC+ISI+QUAD system in vacuum. What we'll end up measuring with the PMC are the *other* noises which are "artifacts" of the measurement -- cavity length noise (sometimes called "acoustic" noise), shot noise of the PMC REFL sensor, etc. BUT -- this "frequency noise" is still relevant because it serves as an upper limit on the *effective* frequency noise on the PSL table. Further, one of the open questions for the SPI L is how we'll use it operationally; only when the full IFO is locked or "at 'all' times, or at least when the PMC + ISS + FSS is locked"? So, we also want to see if the PMC "frequency noise" measures anything different in the three configurations of the IFO -- and again, we want this information between 0.01 to 5 Hz.

Eventually, we'll *also* use the FDS system -- which similarly receives fiber-delivered PSL light -- to *then* establish how much *additional* effective frequency noise is added by the fiber as it traverses across the LVEA via the standard LIGO fiber delivery system. 

OK. That sets the scene, now on to the actual attempt at creating the linear "[Hz/V]" calibration for the PSL PMC PZT.

Measurement PRIMER
The principle of the measurement is relatively standard: 
    (0) Understand the *modeled* cavity parameters, including length of the cavity, and frequency "light houses" and a function of cavity length -- 
        :: the HG00 modes (the mode at which the cavity is designed to resonate, and thus cause the highest signal on the transmission PD) 
        :: the distance between the HG00 models -- the free-spectral-range 
        :: and the frequencies of other, non-HG00 modes in relation to the HG00 mode, or 
        :: if there are Pound-Drever-Hall control-side bands on the HG00 carrier light.
    (1) With the cavity unlocked, drive the length of the cavity using the length actuator in a smooth linear ramp and watch some photodiode in transmission as the cavity flashes through its various resonant modes. Ensure that ramp pushes the cavity length through at least one full free-spectral range. This ramp through the length of the cavity is often called a cavity "sweep," and sometimes also called a "mode scan." Typically, the drive signal is a triangular or saw-tooth wave-form, such that one gets a repeated linear ramp.
    (2) While doing so, record the time series of both the driver value -- in this case a PZT voltage, [V] -- and the transmitted light. The units of the transmitted light actually don't matter, but it's always nice to have a timeseries plotted in physical units, so if you can calibrate the PD into Watts of transmitted power [W]. With the repeated ramp, you can even gather statistics as the cavity sweeps through the same FSR multiple times. We expect to see the HG00 "carrier" peak to have the highest transmission; and thus these are the standard candle "goal posts" that are the most obvious feature. 
    (3) Then, map the frequencies of "peaks" in the transmitted light time series to a frequency vector, by assigning the modeled frequency of each feature (the two HG00, any clearly identified control side bands, any clearly identified non-HG00 modes, etc. from step 0 ).
    (4) Now, map the frequency vector on to the PZT voltage vector to obtain a frequency as a function of voltage.

Here's the kicker: a PZT is a non-linear actuator. So, in order to obtain a *linear* calibration, in [Hz/V], one needs to fit the function from (4) to a polynomial (depending on the number of modeled and identified features in the "cavity sweep," and the personal preference of the data analyst, this can be quadratic, cubic, quartic, etc.) and then take the linear coefficient of that fit as the "[Hz/V]" for a known, typical value for the operating voltage of the PZT.

Another point -- because the PZT is non-linear:
    (a) The answer may depend on the maximum and minimum amplitude of the ramp / sweep,
    (b) The answer may depend on the rate (or frequency) at which the ramp repeats (i.e. the sweep frequency).
    (c) One may get a different answer from a ramp with a positive slope vs. a ramp with a negative slope.
    (d) It has hysteresis; even though one might request the same position by requesting the same voltage, the physical position where the PZT lands may be slightly different each time your request the same voltage, or said differently, there's no guarantee that a requested triangle wave with fixed amplitude will push the cavity to the same starting length on each cycle

Also, because there's no a priori clear map of HG00 mode to voltage ahead of time, there's no guarantee that the cavity's free-spectral range is lined up with 0V, i.e. no guarantee that a ramp from +7V to -7V drive will *get* you two HG00 modes and one FSR. 

It's these additional points, the kicker, and step (3) that I hadn't remembered, and/or didn't re-appreciate before I got started. Ah well.
Hopefully these things can be done offline.

Measurement Technique
2023-10-31_MeasurePMCSweep_Notes.txt are more detailed notes of the "procedure," but the summary of the specifics:
   - With the IFO unlocked, the IMC unlocked, the FSS and ISS OFF, and the PMC unlocked,
   - I used the user-controlled excitation "PSL-PMC_ALIGNRAMP" that feeds into the H1:PSL-PMC_TF_IN filterbank in order to drive a triangle wave (i.e. successive linear ramps, one positive sloped and one negative sloped) into the PMC's PZT
   - In order 
       :: to combat the suspicions of non-linearity, and 
       :: because we didn't know what triangle wave frequency would be best as a compromise between "much less than the PMC cavity pole," and "faster than we expect the free-running PSL alignment, intensity, and frequency to drift" 
     I recorded 6 different measurements with two amplitudes and three ramp rates (triangle wave frequency; time spacing between voltage maximums):
       H1:PSL-PMC_ALIGNRAMP  _FREQ [Hz]    _MIN [V]       _MAX [V]
              Trial 1        0.5           -5.0           +5.0
              Trial 2        1.0           -5.0           +5.0
              Trial 3        10.           -5.0           +5.0
 
              Trial 4        0.1           -7.0           +7.0
              Trial 5        0.5           -7.0           +7.0
              Trial 6        10.           -7.0           +7.0
I also show a screenshot of the three FSS, ISS, and PMC MEDM screens, with highlights of what to click to get started in the above configuration after the operator holds the IFO ISC_LOCK guardian state in DOWN, and the IMC_LOCK guardian in OFFLINE.
Further, I show a trend of the relevant channels during the the whol series of measurements.

Since none of the relevant fast channels are stored in the frames (namely, H1:PSL-PMC_TF_IN_IN1 [the ramp] H1:PSL-PWR_PMC_TRANS_IN1 [the PMC trans PD]), I captured the time series of the ramps using the "triggered time response" feature of DTT. These templates live in 
    /ligo/home/jeffrey.kissel/2023-10-31
        2023-10-31_1521UTC_H1PSL_PMC_TRANS_pm5Volts_0p5Hzramp.xml
        2023-10-31_1521UTC_H1PSL_PMC_TRANS_pm5Volts_10Hzramp.xml
        2023-10-31_1521UTC_H1PSL_PMC_TRANS_pm5Volts_1Hzramp.xml

        2023-10-31_1521UTC_H1PSL_PMC_TRANS_pm7Volts_0p1Hzramp.xml
        2023-10-31_1521UTC_H1PSL_PMC_TRANS_pm7Volts_0p5Hzramp.xml
        2023-10-31_1521UTC_H1PSL_PMC_TRANS_pm7Volts_10Hzramp.xml
where the file name indicates which amplitude and ramp rate. I then exported these timeseries and plotted the results in matlab, see first attachment, 
2023-10-31_1521UTC_H1PSL_PMC_rawData.pdf. The top panel is the PZT voltage triangle wave with the wave maxima highlighted in red, and minima highlighted in green; each traverse from red to green is a "negative slope" ramp, and the traverse from green to red is a "positive slope" ramp. The bottom panel shows the PMC TRANS PD during the triangle wave, where times of maxima and minima of the ramp's triangle wave are highlighted. Don't squint too hard -- I make better plots shown in the "Results" section below.

First Results
After a ton of timeseries parsing, and array index juggling, I took the above raw data and stacked the 6 trials into groups -- 
    every time a negative slope ramp was traversed :: 2023-10-31_1521UTC_H1PSL_PMC_negSlope.pdf, and 
    every time a positive slope ramp was traversed :: 2023-10-31_1521UTC_H1PSL_PMC_posSlope.pdf.
For each page, which is each trial, 
    Top panel :: I show every PZT voltage ramp stacked on top of each other. These all look like a very boring single line, but this indicates that I've done my timeseries stacking and index juggling correctly.
    Bottom panel :: I show the PMC TRANS PD for each of these ramps. These are only synchronized in time by the MAX and MIN requested ramp voltage, and show some spread. *This* is indicative that the PZT is an imperfect actuator that has hysteresis, as discussed above under (d).

First Impressions from these Results
    (I) Positive slope ramps show clear non-linearity around the HG00 mode, especially for the 0.1 Hz and 0.5 Hz data at both excitation amplitudes. So, with this in mind, only the negative slope data is really useful.
    (II) From the negative slope ramps are much cleaner, and indeed it looks like the from +7 to -7 [V] ramps were enough voltage to traverse 2 HG00 modes. 
    (III) Given the alignment of the HG00 modes, we can get the most use out of the +7 to -7 [V] 0.5 [Hz] ramp rate data, but maybe also the +5 to -5 [V] 10 [Hz] ramp rate data.
    (IV) What's ODD is that we don't seem to see evidence for the 35.5 MHz sidebands that are imposed on the PSL light incident on the PMC. We would expect, visually, that the sidebands would be symmertric about the HG00. We see no symmetric features. Maybe the modulation index is really low? Dunno.
    (V) We guess that everything seen in this "mode scan" is higher order modes.

Next Steps
From T0900616:
    PMC Parameter         Modeled Value                        Measured Value
    L (roundtrip)         2.02 m                               2.02 m +/- 0.008 m)
    Finesse               124.708 (124.536 +/- 5.091)          120.44 +/- 0.6
    FWHM                  1.19 MHz (1.195 MHz +/- 0.0488 MHz)  1.19 MHz +/-  0.06 MHz 
    Free Spectral Range   148.532 MHz +/- 0.585 MHz            148.32 MHz +/- 0.742 MHz

So we at least know two points on the voltage to frequency map (ie step 3 from above). But, because we know the PZT in nonlinear in so many different ways, we need to make sure we identify some of the other non-HG00 resonances. 
We did *not* record camera images during this sweep, so doing so will have to rely on guesses from modeling the cavity (or maybe there's some other characterization documentation DCC that we can find).
Then we can do step 3 and 4.

I note that when we eventually get to the "linearization" step, we need to know the typical operating voltage. The 2023-10-31_H1PSL_PMC_PZT_Voltage_TypicalOperatingVoltage.png attachment shows the typical operating voltage is ~0.77 [V] -- in the same voltage units as the user-defined ramp.

Note -- this voltage is *not* the final voltage applied to the PZT. We have to do some further research, but I think this voltage and the ramp voltage units are DAC voltage (which I presume has the standard LIGO general standards DAC range of +/- 10 [V_peak] or 20 [V_pp]). The MEDM screen indicates that there's a -24 dB gain drop, and then I suspect that the voltage is amplified in analog by somehting like a D060283 board. We'll see.

 

Images attached to this report
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 14:30, Wednesday 01 November 2023 (73916)CSWG, ISC, SEI
The raw .txt file exported data lives in
    /ligo/svncommon/SeiSVN/seismic/Common/SPI/Results/
        2023-10-31_1521UTC_H1PSL_PMC_pm5Volts_0p5Hzramp_ts.txt
        2023-10-31_1521UTC_H1PSL_PMC_pm5Volts_10Hzramp_ts.txt
        2023-10-31_1521UTC_H1PSL_PMC_pm5Volts_1Hzramp_ts.txt
        2023-10-31_1521UTC_H1PSL_PMC_pm7Volts_0p1Hzramp_ts.txt
        2023-10-31_1521UTC_H1PSL_PMC_pm7Volts_0p5Hzramp_ts.txt
        2023-10-31_1521UTC_H1PSL_PMC_pm7Volts_10Hzramp_ts.txt

The script to process the data and get it at least to a post-processed form shown in the plots in the main entry lives here:
    /ligo/svncommon/SeiSVN/seismic/Common/SPI/Scripts/
        process_PMC_sweep_20231031.m

jeffrey.kissel@LIGO.ORG - 15:27, Thursday 02 November 2023 (73936)
To further model the expected frequency separation of higher order modes in the PMC mode scan, I've found a few more resources:

In addition to the aLIGO PMC Design Documentation, T0900616, circa 2017 Liu Jian and Kentaro Mogushi worked with Rick Savage and Peter King to improve the design of the PMC -- namely to change the design from gluing the mirrors on the rigid body of the PMC to bolting the mirrors to the body. The best presentation I can find on that upgrade is G1701481.

Some loss measurements were made of the glued PMCs, and the documentation of those measurements contains some juicy design details of the PMC -- see T1600204.

During that design process, as Liu was learning about the details of the PMC, he put together a tech note, E1700340 that hints at further details of the *new* PMC design, which is now installed in the H1 PSL (though I can't find an explicit aLOG documenting when exactly).
elenna.capote@LIGO.ORG - 12:37, Wednesday 20 November 2024 (81387)

Sheila and I used this data to get a rough calibration of the PZT HV channel: 0.0236 V/MHz, as in alog 81385.

Displaying reports 1641-1660 of 80668.Go to page Start 79 80 81 82 83 84 85 86 87 End