FAMIS 26243

Laser Status:
    NPRO output power is 1.819W (nominal ~2W)
    AMP1 output power is 66.92W (nominal ~70W)
    AMP2 output power is 138.6W (nominal 135-140W)
    NPRO watchdog is GREEN
    AMP1 watchdog is GREEN
    AMP2 watchdog is GREEN
    PDWD watchdog is GREEN

PMC:
    It has been locked 37 days, 21 hr 50 minutes
    Reflected power = 18.77W
    Transmitted power = 108.1W
    PowerSum = 126.8W

FSS:
    It has been locked for 0 days 7 hr and 12 min
    TPD[V] = 0.8582V

ISS:
    The diffracted power is around 2.3%
    Last saturation event was 0 days 7 hours and 12 minutes ago

Possible Issues:
    PMC reflected power is high (this is known, pending further alignment plans)

H1 was out of observing from 14:53 to 15:36 UTC to fix some issues with the SQZ system as we were seeing last night.

After Sheila adjusted the fiber polarization (alog77754), I reverted Corey's changes to the SQZ Guardians' nominal states (listed in his alog77740), then optimized the SQZ angle by running SQZ_MANAGER through 'SCAN_ALIGNMENT_FDS' and 'SCAN_SQZANG,' increasing BNS range by ~10Mpc.

Vicky pointed out that we have picos to adjust the fiber polarization for the new TTFSS fiber beatnote.  Adjusting that did bring our beatnote back to a similar level to what it was before the box was swapped on Tuesday, just below 8dBm.

There were many SQZ SDFs, I think related to going to OBSERVE with no squeezing.  I think it would be better to ignore these SDF files from the checks when we are in no sqz than to accept many new settings into the OBSERVE.snap, which kind of defeats the purpose of SDF. 

The RF Scanner resides in the MSR and its antenna is located on the LVEA roof, close to the GPS receivers. It scans for RF signals in the MHz range, producing a time-freq png plot every 10 minutes.

The freq plots are now available via the DTS web server, URL is  https://badger.ligo-wa.caltech.edu/rfscan/pngs/ (one directory per UTC day).

I converted the 144 daily plots into a mp4 movie for the days May 01-08, for example  03 May MP4 Movie. Note that there are some 700-800MHz bursts in the second half, which represents LHO business hours on site (5am - 5pm PDT Friday 3rd May).

TITLE: 05/10 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 131Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 4mph Gusts, 3mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.12 μm/s
QUICK SUMMARY: H1 has been locked and observing (without SQZ) for almost 5 hours.

• Wind and microseism low
• All other systems nominal

I finally got round to comparing the visibility measurements we took in this entry and comparing them with the mode scan taken on April 16th before our mysterious drop in optical gain possibly due to the OFI.

April 16th Measurement:

HOM mis-match from scan = 0.09825 = 9.83% calculated using inferred height of carrier 02 and carrier 20 modes and the measured height of the carrier 00 mode.

HOM mis-match from visibility =  9.763 %

round trip loss: 3504 ppm

Measurement taken on April 30th - old alignment 

HOM mis-match from scan = 0.08454 = 8.45% calculated using inferred height of carrier 02 and carrier 20 modes and the measured height of the carrier 00 mode.

HOM mis-match from visibility = 19.870 %

round trip loss = 3289 ppm

Measurement taken on April 30th - new SR2 and SR3 alignment:

HOM mis-match from scan = 0.09954 = 9.95% calculated using inferred height of carrier 02 and carrier 20 modes and the measured height of the carrier 00 mode.

HOM mis-match from visibility = 14.415 %

round trip loss = 3495 ppm

The round trip loss seems to have been worse after the OFI problems started but I can't reconcile the two methods of measuring mode mis-match. In any case it seems like out current alignment has brought our current OMC round trip loss and the mode mis-match (as inferred from mode scans) back to the April 16th values.

TITLE: 05/09 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY:

H1 is in No-Squeezing configuration (see procedure).  These SQZ nodes will need their nominal states  changed in their python files to return to Observing WITH-Squeezing: 

• MANAGER (back to FREQ_DEP_SQZ)
• OPO_LR (back to LOCKED_CLF_DUAL)
• LR (back to LOCKED)
• LO_LR (back to LOCKED_OMC)
• FC (back to IR_LOCKED)
• SHG (back to LOCKED)
• PMC (back to LOCKED)

LOG:

• 0158 H1 dropped out of Observing due to SQZ TTFSS nosediving since the box was re-installed in the afternoon.  Adjusted threshold to get another 1-2hrs of observing, but then ISS Pump and SHG locking issues bumped H1 out of Observing again.
• 0409 Lockloss
• 0441-0501 Initial Alignment
• 0650 NLN but no squeezing
• 0707 Back to Observing

Unfortunately, the Squeezer was not able to lock this evening.  In addition to the TTFSS issue from this week, the SHG could only stay locked for a few seconds at a time this evening (see attached screenshot), and we have the SQZ ISS Pump off as well.

• DIAG_MAIN gives this message:  "SQUEEZING:  ISS Pump is off.  See alog 70050."
  • Tried following the steps in this alog, but had no luck getting 
• So, to get us through the night, ended up transitioning H1 to the No-Squeezing configuration.  But even with that, had an issue with getting the SQZ Manager & SQZ LO_LR nodes to their NOMINAL states.  Luckily Vicky checked in on me and was able to ultimately find the issue (I believe she said a checker for SQZ_LO_LR was getting a FALSE due to the issue with the TTFSS.  So she edited the script to output a true and H1 was finally able to get to Observing at NLN +No Squeezing.
• Attached are SDF diffs from this round of taking H1 to No Squeezing.

The pump ISS would not lock, it seems that the pump rejected polarization in HAM7 has been trending upward for 10days.  I adjusted the half and quarter wave plates at the input of the fiber and got the rejected power down to 23 uW, with 22mW launched into the fiber.  This probably could have been better adjusted, but each time I moved the pico I was having to wait for the PMC and SHG to relock so I decided this is good enough for tonight.

The second attached screenshot shows some trends related to the beatnote dropping.  The powers into the box all say they have been stable, and the power on the beatnote PD also seems stable,  so I'm not sure why the reported beatnote strength is falling.  The current beatnote level does seem like it's enough for the TTFSS to lock without an issue.  I've reset the lower limit to -50, and right now the beatnote strength is increasing again to -7dBm. 

It seem like if the IFO get relocked the squeezer should work, so this would be better than no squeezing for tonight.

The TTFSS beatnote continued a nosedive this afternoon/evening.  Fearing the remedy for this was a hardware fix tomorrow, I opted to prepare to take H1 to a No-Squeezing state, but during my preparations, H1 was dropped out of Observing for a different SQZ reason.  At this point, I stayed out of observing and focused on following the procedure for No-Squeezing operations.  I mostly was there, but there were still issues with the SQZ MANAGER and SQZ LO LR nodes not making it to their "No Squeezing" nominal states (i.e. they had orange boxes).  At this point I phoned TJ (per No-Squeezing wiki instructions), but Sheila also connecting with me via mattermost.  

Sheila has thinks Squeezing should work and is working on that.  

I am currently working on H1 because at 409utc (909pmPDT), H1 lost lock.

H1 was taken out of Observing due to SQZ TTFSS Beatnote continuing to drop (even after the TTFSS box was swapped this afternoon [alog77734]).  Lowered the Beatnoe RF Minimum from -12 to -20 to give us a few hours.

SDF with new minimum accepted (see screenshot of SDF, trend of beatnote since the Tues & today TTFSS swaps, and TTFSS medm).

The annual dewar jacket pumpdown - which is now part of the annual LN2 maintenance FAMIS task - is now complete, the pressures, and the pumpdown completion dates are the following:

- CP1 (corner): 04/24: 8 mTorr
- CP2 (corner): 05/26: 5 mTorr
- CP7 (EY): 04/30: 4 mTorr
- CP8 (EX): 04/26: 6 mTorr
- CP3 (MY): 05/03: 4 mTorr
- CP4 (MY): N/A (decommissioned)
- CP5 (MX): 05/08: 4 mTorr
- CP6 (MX): 05/08: 4 mTorr

The SQZ fiber beatnote has been dropping since the new box was installed this past Tuesday. It dropped below threshold and the autolocker turned off, but held lock. Sheila bumped this min dB to -14 for now, but we will talk with Fil about replacing that box soon since it doesn't look OK. See second attachment.

Since the A2L script that measures a transfer function isn't quite minimizing our ASC noise in DARM, Sheila suggested re-finding the old A2L script that we used to use, which just looks at the height of the peak in DARM.

I think I've found it, in /opt/rtcds/userapps/release/isc/common/scripts/decoup/al2_min_LHO.py .  I made sure that it, and other scripts in that directory, were checked in to svn (they were last modified somewhere between 2018 and 2019, depending on the script).

The script (as wrtitten) uses the ADS to actuate each of the quads, and uses the demods to find the size of the signal (it does a sum of the squares of the I and Q of the demodulated signal).  The script just guess-and-checks several A2L gain values for each optic, makes a step, and checks again.  Once it's finished, it does a linear fit to find the A2L value at which the peak height is expected to be zero.  The script runs 8 dither lines (pit and yaw from each quad) around 20 Hz, so that it can do this guess-and-check for all the optics at the same time. 

The values in the script are out of date (we've slightly modified the frequencies we use for ADS while locking), so those values and the filter numbers for the matching bandpasses need to be checked.  Also, the excitation amplitude in the script is probably higher than we need (they are set to be 300 counts, but we use 30 counts at full power right now, but we may want a little better SNR so we might want to find a value that is between those two.

Also, we may find that we want to instead do the optics one at a time, at 30 Hz, where the coupling of ASC to DARM is more important to our range.

We can try this out during one of our commissioning windows later this week, to see how it goes.

Jennie W, Sheila

Today we took OMC scans to help diagnose what is going on with our alignment through the OFI - that is, what is the mode-matching at our the old alignment (as of Monday 22nd) and our new alignment (as of this morning).

Sheila turned off the sidebands before the test and we had the ETMs and the ITMX mis-aligned initially for single bounce configuration.

Old alignment: SR3 M1 YAW OFFSET = -125 microradians

SR3 M1 PIT OFFSET = -437 microradians

SR2 M1 YAW OFFSET = -421 microradians

SR2 M1 PIT OFFSET = -64 microradians

Due to PEM measurements we switched from single bounce off ITMY to single bounce off ITMX.

Locked time = 1 minute from GPS 1398534847

Unlocked time = 1 minute from GPS 1398534984

Scan = 200 s starting at 1398535070 GPS

New alignment: SR3 M1 YAW OFFSET =  120.2 microradians

SR3 M1 PIT OFFSET = 437.9 microradians

SR2 M1 YAW OFFSET = 2061.7 microradians

SR2 M1 PIT OFFSET = -5.5 microradians

Locked time = 1 minute from 1398538330 GPS

Unlocked time = 1 minute from 1398538461 GPS

Scan = 200 s starting at 1398537927 GPS

Dark time with IMC offline and fast shutter closed = 1398538774 GPS

Mode mis-match measurments pending...

I went to FCES this morning to try to troubleshoot the sort of busted H1 GS13 on HAM8. I suspect there is something going on with the cable or interface chassis, but it's not something I think I've seen before. I tried swapping cables at both the rack and the chamber, and whenever the corner 1 chassis was connected to the H1 sensor, the transfer function from the H1 CPS to the H1 sensor would be half the magnitude of the other two sensor pairs. ASDs also show the H1 GS13 has half gain when the corner 1 sensors are connected to the corner 1 chassis. However, when the H1 sensor was plugged into the corner 2 or 3 chassis, all three sensor pair tfs would have the same amplitude. I could repeat this consistently, didn't matter how I swapped the cables around, as long as the H1 sensor wasn't plugged into the correct chassis all the l2l sensor tfs would look normal.

Attached plot shows two sets of data I took during this period, red blue and light green are the normal config, dark green, pink and light blue are with the H1 sensor on the corner 3 chassis, H3 sensor on the corner 1 chassis.

I will talk to Fil, but maybe in a couple weeks we can try running a temp cable from the FC mezzanine to the chamber, and see if that changes anything.

J. Kissel

As we continue to investigate both ADC noise (both broadband, in-general behavior) as well as down-converted aliasing noise in the new fast 524 kHz OMC DCPD signal chain, I needed to wrap my head around all the available channels in order to begin thinking about how to compare / take advantage of the differences between the channels.

I don't understand anything until I diagram it, so here's my diagram of the existing OMC DCPD signal chain as I understand it, hoping it helps others.

As mentioned in each of the previous aLOGs where I've started the investigation (LHO:67552, LHO:67530, LHO:67465, LHO:67297, LHO:67439), studies of the 524 kHz portion of the system are severely limited in that 
    (a) no 524 kHz channel stored in the frames,
    (b) one can only look at 3 test points at a time,
    (c) we don't have any analog measure of the noise between 524 kHz and 102.4 kHz (the upper limit of the SR785) to compare against

But, we'll do what we can!
Hopefully this visual aide will help understand future studies.

For example, because we *don't* have any digital anti-aliasing filters in the OMC-PI SIG filter bank, we can compare these test point channels, 
    - H1:OMC-DCPD_A0_OUT (524 kHz, w/ digital anti-aliasing)
    - H1:OMC-PI_DOWNCONV_SIG_OUT (524 kHz, w/o digital anti-aliasing)
    - H1:OMC-PI_DPCD_64KHZ_AHF  (65 kHz, w/o digital anti-aliasing)
    - H1:OMC-DCPD_A_IN1  (16 kHz, w/ digital anti-aliasing)
to explore the effectiveness of the digital anti-aliasing filters to better understand the aliasing that Evan Hall found in LHO:67328.


Note -- and this is something that I'm still learning (via conversations with Erik von Ries and Daniel Sigg and their aLOGs, including but not limited to LHO:67587, LHO:67560, LHO:67291) -- the h1iopomc0 model actually runs at 65 kHz (really, 2^16 kHz). In order to achieve a pseudo-524 kHz data stream, there's a for loop within the h1iopomc0 model that's able to complete 8 iterations (thus 2^16 kHz * 8 = 2^19 kHz = 524 kHz) during any given 65 kHz clock cycle.