FranciscoL, [Remote: RickS]

After one week of moving the inner beam down by 5 mm on the Rx sensor (alog 78107), on June 4, we moved the beam back to center of the target.

The ETM was missaligned during the procedure. It will be interesting to see any effects from this state of the interferometer on making changes to the position of the inner beam.

Attachment 'AlignedTarget' shows the alignment with the beam height gauge. Attachment 'BothBeamsBefore' shows the beams before making any changes. The pdf 'EndStationLog.pdf' lists the voltage values after each significant step of procedure T2400163. The steps represent writing down a voltage value after a particular change to the beam position. Some steps were recorded multiple times after minor changes.

• (2) Only inner beam at Rx detector. (see image 'InnerBeamBefore')
  • The beam voltage was maximized before moving it to center. The first value is before attempting to move anything. The second value comes from attempting to maximize by making a vertical move. There was an increase of about 0.01 V (1.63 %) from this move. The third value is from moving the beam on the horizontal axis. There was no increase from the previous move.
• (3) Finalized beam movement. (see image'InnerBeamAfter')
  • First value after making the beam move to center. Second value from attempting to maximize on both axes.
• (8) Target off. The measurement was recorded after placing the pcal enclosures.

The 'Initial' measurement is *equal* to the last voltage measurement from the previous movement, done on May 21 (alog 78107). The initial and final voltage measuremed during todays procedure decreased by 2 mV (6 HOPs). The digital thermometer had a temperature of 21.1 at the beginning of the procedure and increased by 0.6 C. Will record temperature more carefully on following procedures.

With the movement made today, we expect that the X/Y comparison to return to 1.

IFO is still DOWN due to wind.

However, wind gust speeds have started to come down in the last 30 minutes and I will begin locking shortly.

Monthly TCS HWS and CO2 Plots Attached

Of note:

• TCS-ITMY CO2 Laser Power PD has been decreasing with two notable steps, one 3.5 days ago and another 18 dats ago.
• TCS-ITMX and ITMY HWS Probe Spherical Power flatlined at around 65 7 days ago. TJ told me this is due to recent SR3 moves so is not unsurprising

Last checked in alog 77725 Closes FAMIS 28449

TITLE: 06/04 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Wind
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: Maintenance day went smoothly this morning, but the high winds made locking afterwards impossible. Main activities for the maintenance period included spot moves on the OFI (which have been reverted), HAM7 CPS tests, vacuum turbopump checks, and more FARO surveying. I attempted an initial alignment shortly after noon, but ALS would not stay locked long enough for it to work, so I stopped trying and left H1 down until the wind hopefully dies down this evening.

LOG:

TITLE: 06/04 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 33mph Gusts, 23mph 5min avg
    Primary useism: 0.07 μm/s
    Secondary useism: 0.28 μm/s
QUICK SUMMARY:

IFO is in INITIAL_ALIGNMENT IDLE due to ENVIRONMENT (high wind gusts over 40mph)

We've had 3 SRM trips in the last week during the LOCK_SRY inital alignment state in the ALIGN_IFO node. I've made two changes to help with this:

1. During locking of this state, we use AS_C for our triggers, but AS_A as our error signal for SRCL. So if OM1 or OM2 are misaligned, then we could be trying to move off of a bad signal. We have the AS_Centering series of states that will center AS_A using OM1 and OM2. I've added this in the path for automated inital alignment after SR2 alignment and before SRY locking. In theory this should help, but when trying to test it out today by heavily misaligning OM2, I wasn't able to get it catch on a wrong mode. Even though I couldn't reproduce it this way, this state is fast enough that I'll leave it in for now to see how it works. If anyone is running a manual initial alignment, they can choose to do this step or not.
2. The other reason it was locking on the wrong mode is that the triggering thresholds were maybe set too low. Back in mid April I moved the triggering of this state from POP_A to AS_C (alog77113), and back then I just trended and made a good guess of the threshold values. I've bumped them up a bit to help avoid catching on the wrong mode and we'll see if this works over the next week or so.

Functionality test was done on the corner station turbo pumps, see notes below:

Output mode cleaner tube turbo station;
     Scroll pump hours: 5906.9
     Turbo pump hours: 5968
     Crash bearing life is at 100%

X beam manifold turbo station;
     Scroll pump hours: 1949.7
     Turbo pump hours: 1954
     Crash bearing life is at 100%

Y beam manifold turbo station;
     Scroll pump hours: 2282.5
     Turbo pump hours: 955
     Crash bearing life is at 100%

FAMIS tasks 23603, 23531and 23651.

(Isaiah V., Gerardo M.)

J. Kissel, D. Barker, E. von Ries, R. McCarthy

Continuing investigations of the OMC0 DuoTone coupling to the ADC0 card (see LHO:77579 and LHO:78218), Erik installed some software this morning (LHO:78237) giving us the ability to turn off the DuoTone signal in the h1omc0 IO chassis in two different ways:
    (1) Change the output of the Timing Card from the standard 960 and 961 Hz DuoTone signal to a constant 2.5 [V].
    (2) Triggering the ADC DuoTone relay in the backplane interface adapter card for the low-noise 524 kHz ADC (D2100491) to turn OFF the DuoTone input to the last channel (H1:IOP-OMC0_MADCO_TP_CH31, or the 32nd channel)

The first attachment is a screen grab of the h1omc0 page of the recently updated as-built drawings of the IO chassis D1301004. This serves as a visual aide for where things are.

As such, I measured the same differentially-shorted channel I had in LHO:78218, H1:IOP-OMC0_MADCO_TP_CH17, in the following three different configurations because (again according to LHO:78218) it sees the DuoTone signal just as loudly as H1:IOP-OMC0_MADCO_TP_CHCH0, one of the channels that informs the average of four, the OMC0-DCPD_A0 gravitational wave channel. This way, we're not confused by the OMC DCPD signal chains' electronics noise.
    (a) BLACK The nominal configuration, with the standard DuoTone signal coming out of the timing card, and the interface card relay set to "ON" allowing the DuoTone into CH31.
    (b) MAGENTA Switching the timing card out to a constant 2.5 V, but leaving the interface card relay set to "ON," and
    (c) RED The standard DuoTone signal coming out of the timing card, but the interface card relay set to "OFF."

Attached is the ASD comparing the three different configurations. 

Both "OFF" configurations show no DuoTone signal. This rules out three of the suspect coupling paths -- 
    (i) direct coupling of the timing card to the ADC channels via the Adneco mother board they both reside on or 
    (ii) the ribbon cable that connects the timing card to the interface card somehow radiating the DuoTone signals to the rest of the chain
    (iii) The backplane itself (D2000297) mixing the timing signal in with interface cards that it houses . 

This differentiates between which two things that LLO did in (LLO:71315) that mitigated the issue. Remember, with the LLO the arrangement of their non-segregated h1lsc0 IO chassis, they both 
    - moved the channels off the card *and* 
    - migrated the card off the same Adneco board as the timing card . 
Because we did NOT see and DuoTone on ACD0 CH17 in configuration (c), with the timing signal ON, but the relay piping it into ADC0 CH32, that means indirect coupling across the Adneco board is ruled out, and moving the monitor channel off the card that was their real solution.

That leaves the following suggested coupling sites:
    (iv) The flat, non-twisted pair ribbon cable that connects the interface card to the ADC (less likely, given that we've proven that the same type ribbon cable from the timing card to the backplane doesn't radiate)
    (v) On the ADC card itself, direct coupling from CH31 to all its other channels

Given that (v) seems most likely, the options forward that seem most promising are:
    (I) Reduce the amplitude of the DuoTone timing signal (hopefully easy software change)
    (II) Trust that the timing system hasn't failed us, and won't fail us again, and turn off the DuoTone signal all together (dubious)
    (III) Do as LLO has done, and move the DuoTone Monitor signal OFF of this ADC by installing another ADC card, and moving the low-noise ADC to another slot on the Adneco board (expensive)

My vote (if it's not clear from my parenthetical assessment of each) is (I) because it's "the easiest." However, the CW and Stochastic groups are in the business of integrating forever, so it'll merely reduce the problem for them rather than eliminate.
The discussion will continue ... 

I've left the system in nominal configuration (a), with the DuoTone ON at it's full 5 [V_pp] amplitude, and the backplane interface card relay ON, allowing that DuoTone signal to flow into ADC0's CH31

LVEA was swept with everything looking good (except some PEM things, but that is expected since Robert is still running tests)

Maintenance activities have finished for the morning and the LVEA has been swept. I'm trying to start an initial alignment now, although the >40mph winds are preventing ALS from staying locked for too long.

The LVEA is currently laser SAFE, but we'll transition it back to HAZARD this afternoon for more commissioning work over the coming days.

J. Kissel, D. Barker, E. von Ries, R. McCarthy

We're trying to follow-up with LHO:77579, where it's reported that DuoTone signals are seen in the detector's sensitivity suring nominal low noise, as well as in the OMC DCPDs when there's no light on them (LHO:77696). In doing so, we're trying to decide which linear combinations of actions that LLO took with their IO chassis (see LHO:71308 and subsequent comments) are possible with LHO's segregated OMC DCPD IO chassis. 

To investigate, in this aLOG, I quantify the voltage amplitude of the various signals in question in the current nominal configuration. LLO's measurement of the low-noise 524 kHz ADC with the AA chassis disconnected LHO:71190 indicates this is clearly an issue within the IO chassis, so we know we don't have to look at channels outside of there.

As such, I've looked at four relevant 524 kHz channels from H1's segregated OMC DCPD IO chassis:
    - H1:OMC-DCPD_A0_IN1 :: One of the same DCPD channels that Joe looked at except at 524 kHz sample rate rather than 16 kHz, and either way, it's actually the sum of four of this low-noise 524 kHz ADC's channels, ADC0_0, ADC_0_4, ADC_8, and ADC_12
    - H1:IOP-OMC0_MADC0_TP_CH0 :: The first channel on the low-noise 524 kHz ADC, containing the first copy of the OMC DCPD signal chain voltage.
    - H1:IOP-OMC0_MADC0_TP_CH17 :: One of the four low-noise 524 kHz ADC channels I've shorted at the input to the AA chassis (see LHO:67465)
    - H1:IOP-OMC0_ADC_DT_OUT :: the last ADC channel of this low-noise 524 kHz ADC (31st if you start counting at zero; 32nd if you start counting at one) which is a readback of the DuoTone timing signal itself

Unfortunately, exhaustive, fast studies are not possible because 
    (a) reading a 524 kHz channel requires 2 MB/sec of data, which is taxing on the RCG, so much so that one can only look at three 524 kHz channels at a time, and 
    (b) it's taxing on the data storage system, we we've only saved a bare minimum in the frames for all time. So, one has to make due with looking at these 524 kHz channels in real time, three at a time.

The calibration for these channels back into voltage is relatively simple, given that the low-noise 524 kHz ADC has 18 bits spread across the usual 40 [V] differential, peak to peak. The only trick is the OMC DCPD channel that one must divide by 4 again, because it's sum of four copies of the same voltage (see LHO:67439):

    - H1:OMC-DCPD_A0_IN1 :: 40 [V_pp] / 2^18 [ct] *  (1 / 4 [copies]) = 3.8147e-5 [V/ct]
    - H1:IOP-OMC0_MADC0_TP_CH0 :: 40 [V_pp] / 2^18 [ct] = 1.5259e-4 [V/ct]
    - H1:IOP-OMC0_MADC0_TP_CH17 :: 40 [V_pp] / 2^18 [ct] = 1.5259e-4 [V/ct]
    - H1:IOP-OMC0_ADC_DT_OUT :: 40 [V_pp] / 2^18 [ct] = 1.5259e-4 [V/ct]


The first plot shows the time-series of the DuoTone readback channel (H1:IOP-OMC0_ADC_DT_OUT) in ndscope. 
The amplitude of the DuoTone signal -- this beatnote between 960 and 961 Hz -- is 32000 [cts_pp], which is 
    32000 [ct_pp] * 1.5259e-4 [V/ct] = 4.8828 [V_pp] 
        = 4.8828 [V_pp] / (2*sqrt(2) [_pp / _rms]) 
        = 1.723 [V_rms]
A 4.88 [V_pp] DuoTone signal seems quite unnecessarily loud, given that the noise floor of this low-noise 524 kHz ADC is 0.5e-6 [V_rms] = 0.5 [uV_rms] = 500 [nV_rms] in this frequency region.

Taking an ASD of the same DuoTone channel, the cumulative RMS at 955 Hz from the ASD is 1.2275 [V_rms], and we see lots of 1 Hz sidebands surrounding the excitation.

Taking an ASD of the shorted channel, the cumulative RMS at 955 Hz from the ASD is 2.10e-5 [V_rms], and it very coherent with the DuoTone channel at the DuotTone frequencies and their sidebands.

Taking an ASD of the OMC DCPDA (the average of CH0, CH4, CH8, CH12) and CH0 alone, with the DCPDs still connected to their entire signal chain, but there's no light on the DCPDs and I've turned the whitening switch OFF. In this configuration, I see a cumulative RMS at 955 Hz of 1.39e-4 [V_rms]. But the RMS is less interesting, because the RMS is not dominated by the DuoTone signal. However, we do see,
    - OMC0_MADC0_TP_CH0 has comparable ASD of DuoTone lines as CH17, if not a bit louder, and
    - OMC0_DCPD_A0_IN1 has *less* amplitude of DuoTone lines. 

Quantitatively, the transfer function of MADC0_CH0 / DCPD_A0 at 960 Hz is 4.63 [V/V] and 961 Hz is 4.88 [V/V]. Very interesting / surprising that this transfer function ratio not exactly 4.0. 

Next up == we're looking into various ways to turn OFF the timing signal temporarily to test how the timing signal is coupling into the ADC channels.

[Dave, Jeff, Erik]

In support of efforts to eliminate noise caused by duotone, a new version of the "gpstime" driver was installed that enables control of the duotone output from the timing card and of the duotone relay on the ADC adapter board.

When the relay is opened, the duotone channel reads near zero volts, with some bit noise. 

When the duotone output is turned off, the timing card outputs a steady -16768 counts.

To control these features you must be logged in as root on h1omc0

the command 'dt_output' controls the duotone output from the timing card.

the command 'dt_relay' controls the relay. 

turn either on or off like so

'dt_relay on'

'dt_relay off'

to get the current state, run the command without an argument.

For both commands, 'on' means duotone is on.

Both have to be on for duotone to work.

Tue Jun 04 10:10:51 2024 INFO: Fill completed in 10min 47secs

Travis confirmed a good fill curbside.

FAMIS 19974

pH of PSL chiller water was measured to be just above 10.0 according to the color of the test strip.

TITLE: 06/04 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 24mph Gusts, 18mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.23 μm/s
QUICK SUMMARY: H1 had lost lock at 13:53 and was relocking when I came in, but was not having success with DRMI. I've taken ISC_LOCK to IDLE so maintenance activities this morning can begin.

• Wind still elevated on site, gusts up to 40mph in the past hour
• Microseism trending slightly down, currently around the 50th percentile

Workstations were updated and rebooted.  This was an OS package update.  Conda packages were not updated.

TITLE: 06/04 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Observing at 136Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY: The wind has calmed down enough for us to relock finally, microseism is rising. The range is a little lower than usual, SQZing doesn't look amazing.

00:10 & 00:12 UTC ITMY ST2 wd trip from sei testing

00:18 UTC HEPI HAM1 trip potentially from Robert dropping a viewport cover by HAM3

Viewports are all covered, and we are ready to return to LASER SAFE tomorrow alog78225

Lots of EX saturations during CARM_OFFSET_REDUCTION

I had to hold in OMC_WHITENING to damp violins for 20 minutes

03: 09 UTC back to Observing

03:48 UTC lockloss

05:19UTC back to Observing

LOG:                                                

Captured spectra for ranges at 140Mpc to 155Mpc, as well as the spectra after SR3 aligment changed to 83 from 438.

Reference point are labeled. The file is saved at /ligo/home/karmeng.kwan/DARM_trace.xml

DARM spectra was captured from H1:CAL-DELTAL_EXTERNAL_DQ

Jenne D, Ryan S, Camilla C, TJ S

Today in a single bounce 10W configuration we set SR2 to center AS_C with the SRC2 ASC loops via the ALIGN_IFO guardian in the SR2_ALIGN state, then moved SR3 in steps to see how our AS_C power would change in different positions. We found that there is an area, or spot, that we lose significant throughput to AS_C, but moving around this spot in any direction recovers our nominal single bounce power. This is followup from Jenne Driggers SR3/2 move (alog77388) to bring back our power at the AS port on April 24th, and Jennie Wright, Minhyo, and Sheila's efforts searching in yaw to find where we are losing the power (alog77513). This time we went further than Jennie W and team went and managed to get back almost all of the AS_C sum back. Almost all because just before we got there we starting running into a different, perhaps clipping, issue that changed the shape of the AS air camera in a much different way than when around this spot.

More details:

We started out by reverting the alignment to a time during DRMI locking from the Tuesday morning of April 23. We then brought up tried to move SR2 and SR3 as was done previously, then Jenne suggested that we turn on SRC2 to have SR2 follow our SR3 moves and keep AS_C centered. This worked great along with a little extra SRC2 gain to help move things along faster. Moving in pitch in either direction yielded fairly quick power gains (trends SR3 -P move & SR3 +P move). Jenne suggested that we try to go further in yaw than the Jennie W. team did to see if it ever improves, and we were able to get AS_C almost back after ~550urad in SR3 (trend SR3 -Y move today, and SR3 +Y move April 24 ). If I had the time I'd love to make a nice graphic to show where we can't go but we'll have to deal with this table for now.