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:                                                

https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi?event=1401508133

Wind was brutal today, so I was messing with the controls on the BSCs to try to help. Mostly just running RX/RY sensor correction from St1 to St2 on the BSCs. Sensor correction is focused on improving the ~.4hz motion and doesn't really affect the motion outside that. I don't think this really helped, winds calmed down after I left at 5:30 and Ryan is almost all the way NLN now, so I will leave the extra sensor correction running for tonight. I'll accept SDFs for tonight, then turn it back of during maintenance tomorrow.

Wind and lock losses make a comparison challenging, but the blrms trends show the (log scale) improvement ETMY sees when it's turned on over .3-1hz. Top trace is the St2 RX GS13 blrms, middle trace is the gain for the sensor correction, sc is on when it's 1, off at 0. Bottom trace are the .3-1hz ground blrms. For the las 3-ish hours the St2 RX motion is lower with the sensor correction on even when the ground is moving more in this frequency band.

I replaced the temporary covers on all viewports that I have opened with permanent covers.

TITLE: 06/03 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Wind
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Still working on relocking and at LOCKING_ALS. We recently had gotten up to CARM_OFFSET_REDUCTION.
LOG:

14:30 Detector Observing and Locked for 6 hours

15:27 Lockloss https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=78202
    - PSL ISS diffracted power low, so I moved REFSIGNAL up by 0.01
    - Having issues locking ALS because of the wind picking up
    - 10 locklosses from LOCKING_ALS
    - 1 lockloss from FIND_IR
16:18 Holding in DOWN for a bit
16:28 Starting to relock again
    - 3 locklosses from ALS
16:35 Back to DOWN - going to have to sit here for a while
    - Some maintenance tasks are going to be done
17:59 Trying relocking again again
    - Lockloss from CARM_150_PICOMETERS
    - Lockloss from POWER_10W
    - (many) locklosses from LOCKING_ALS
    - Lockloss from CARM_150_PICOMETERS
20:21 Put in DOWN
21:49 Retrying relocking
    - Lockloss from CARM_OFFSET_REDUCTION                                                                         

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

Jennie W, Sheila

Jeff reminded me that we should notch out the bounce mode from the ASC MICH loops wich also feedback to the beamsplitter if we are correcting its notch in the LSC loops as per this entry.

The filter module I used was FM9 in ASC-MICH_P and Y. This is the orginal contents for MICH_P and this is it for MICH_Y. I checked the guardian code and neither of these were used in ISC_DRMI or ISC_LOCK guradians currently.

I copied the filter design from the LSC loop but without the roll mode notch at 25Hz as this was not in the ASC MICH loop already and we might want to tune this later if we can see it in DARM.

I tuned the magnitude to make it 0dB at high and low frequency. The filter design is here and the plot is here for pitch. And the same filter design and plot for yaw.

I don't have an OLG measurement to verify this mode shows up in ASC-MICH but Sheila pointed out that the ASC MICH loops are lower bandwidth than the LSC MICH loops so we shouldn't lose too much phase margin with this filter.

These new filters are saved and loaded in the ASC model coefficients but we will not test them till our next commissioning period.

TITLE: 06/03 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Wind
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 29mph Gusts, 21mph 5min avg
    Primary useism: 0.06 μm/s
    Secondary useism: 0.21 μm/s 
QUICK SUMMARY:

• High winds have made relocking a struggle, we haven't been able to make it past 5W in POWER_10W
  • The wind is forecasted to calm down around 05:00 - 06:00  UTC, 10 - 11 pm local  
• 0.03 - 0.1 & 0-1 - 0.3 are both elevated