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.
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:
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:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
19:13 | SAF | - | LVEA | YES | HAZARD | 15:21 |
15:00 | SAF | TJ | LVEA | - | Transition to Laser SAFE | 15:21 |
15:02 | CAL | Jeff | CR | N | OMC DCPD data | 16:58 |
15:06 | FAC | Karen | EY | N | Technical cleaning | 16:10 |
15:07 | FAC | Kim, Nelly | EX | N | Technical cleaning | 16:44 |
15:22 | VAC | Gerardo | LVEA | N | Turbopump testing | 19:12 |
15:31 | IAS | Jason, TJ O., Tyler | LVEA | N | FARO surveying | 19:03 |
15:34 | PEM | Robert | LVEA | N | Setting up magnetometer | 16:22 |
15:39 | VAC | Travis | LVEA | N | Checking valves on turbo stands | 15:57 |
15:48 | CDS | Fil | LVEA | N | Checking on cabling | 19:41 |
15:51 | SEI | Mitchell, Jim | EX, EY | N | Checking wind fences | 16:46 |
15:52 | VAC | Isaiah | LVEA | N | Joining Gerardo | 18:07 |
16:27 | FAC | Chris, Pest Control | LVEA, MY, EY | N | Pest control checks | 18:44 |
16:30 | ISC | Sheila, Jennie | CR | N | Single-bounce OFI (corner SC on) | 18:55 |
16:38 | PEM | Robert | LVEA | N | Checking magnetometer | 17:10 |
16:41 | VAC | Travis | MY | N | Picking up parts | 17:17 |
16:44 | FAC | Kim, Karen, Nelly | FCES | N | Technical cleaning | 17:42 |
16:50 | SEI | Jim | LVEA | N | Replacing HAM7 CPSs | 19:12 |
17:07 | CAL | Francisco | EX | YES | PCal spot measurement | 18:53 |
17:30 | SAF | Travis, Oli, Corey | LVEA | N | Laser hazard training | 18:15 |
17:42 | FAC | Kim, Karen, Nelly | LVEA | N | Technical cleaning | 18:58 |
18:40 | AOS | Betsy, Mitchell, Travis, others | LVEA | N | HAM6 feedthrough checks | 19:12 |
19:16 | OPS | Oli | LVEA | N | LVEA sweep | 19:40 |
19:36 | CAL | Francisco | PCal Lab | Local | Measurements | 20:30 |
19:52 | SQZ | Terry, Kar Meng | Opt Lab | Local | SHG work | 22:56 |
20:43 | SAF | Oli | LVEA | YES | Transitioning to Laser HAZARD | 21:13 |
21:02 | SEI | Jim | LVEA | - | HAM7 CPSs | 21:12 |
21:03 | SAF | HAZARD | LVEA | YES | LVEA is Laser HAZARD | Ongoing |
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:
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
I find it surprising that the measured DuoTone crosstalk at 959Hz and 962Hz is nearly as large as the lines at the actual DuoTone frequencies of 960Hz and 961Hz. Futhermore, lines at 958Hz and below, and at 963Hz and above are much weaker. This in contrast to the spectrum of the DuoTone signal where the 960Hz and 961Hz lines are more than 5 orders of magnitude stronger than the 1Hz comb around it.
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.
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:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
19:13 | SAF | - | LVEA | YES | HAZARD | 05:53 |
23:00 | PEM | Robert | LVEA | yes | Mounting an accelerometer | 23:51 |
23:55 | CAL | Francisco | PCAL lab | LOCAL | pcal work | 00:24 |
00:00 | PEM | Robert | LVEA | Y | Disassembling stuff | 00:24 |
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
No clear differences seen between the spectra before and after the SR3 alignment change.
The comparison of the spectra shows the excess noise at 20-25Hz regime contributes to range drop, for both the original alignment and after SR3 alignment change.
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.
Pre April 24 | May 07 10:39 | May 07 11:03 | May 07 11:39 | Post April 24 | |
Start | -P move | +P move | -Y move | +Y move | |
SR3 P slider value | 438 | 81.9 | 798 | 438 | 438 |
SR3 Y slider value | -148.8 | -148.8 | -148.8 | -686.3 | 120 |
Here's a screenshot of the AS air camera when we were at the edge of our SR3 -Y move. The beam spot began to squish and spread across the screen a bit more.
Here are some trends with SR2 and SR3 M1 osems during these moves.
EDIT: Added a revamped table with the SR2 and SR3 OSEM changes. The deltas from these could all be found by subtracting the "Pre April 24" value from each column for each move. These values are the final position when AS_C power was recovered to nominal values.
Pre April 24 | May 07 10:39 | May 07 11:03 | May 07 11:39 | Post April 24 | |
Start | -P move | +P move | -Y move | +Y move | |
SR3 P slider value | 438 | 81.9 | 798 | 438 | 438 |
SR3 Y slider value | -148.8 | -148.8 | -148.8 | -686.3 | 120 |
SR3 P M1 osem | -290 |
-674 |
112 | -263 | -292 |
SR3 Y M1 osem | -616 | -592 | -640 | -1018 | -405 |
SR2 P M1 osem | -570 | 3040 | -1955 | 503 | 596 |
SR2 Y M1 osem | 11 | 34 | 28 | -2164 |
1160 |
Sheila, Jennie, Alena
Alena realised during her calculations of the spot positions on the OFI at different SR2 and SR3 alignments, that the osem value quoted in the table above for SR2 P M1 osem should be +570.
Sheila alos saw this when looking at osem trends.