For some reasons the big offset that had been observed at ASC_ADC_1_7 [1][2] disappeared at around 11:24 AM this morning and never came back. I think this corresponds to the time when I was unplugging the SCSI cable of the AA board. I was trying to look at the raw voltage coming out from the AA board and so for the reason I was attaching a SCSI break out board. I didn't see any raw offset at the time, put the cable back to place and realized that the offset had been magically gone. This is strange because yesterday it came back after I unplugged and plugged the SCSI. This doesn't mean the issue is solved, but anyway we will keep our eyes on this particular ADC channel and AA board.
After the offset was gone, I checked the signal chain from the inputs of the QPD interface box through the whitening filter and ADC to the digitized numbers by injecting analog excitation signal (0.01 Vpp at 3 Hz with DS345). This was a part of the QPD check. The digitized value agreed with an expected count of +/-550 counts with the whitening off. So I conclude that the ADC and AA board are healthy at this moment.
Note :
one of the QPD interface box [3] in the ISC R4 rack doesn't have a frequency response. It is documented in [3]. The rest of two guys do have a frequency response as designed.
[1] LHO alog 5371 "offset at ASC_ADC_1_7 seem from the AA board"
[2] LHO alog 5373 "Maintenance summary"
[3] S1102815-v3 "ISC Dual QPD Transimpedance Amplifier Chassis"
Commencing Matlab TFs on the BS.
Completed the Leveling of the final corner's L4Cs on HAM3. I'm still crunching the IPS readings to go from the starting locked position to floating to after leveling work floating to current locked position. I expect these to be a few mils & urads at the worst but I'll go through the motions and report, just not now. HAM3 HEPI is ***Locked*** but try to avoid the Crossbeams anyway.
With the EY envelope vented, both doors removed on BSC10, and the downstream nozzle leading to the new spool and to BSC6 dammed, we deinstalled H1 ETMY (final iLIGO test mass on the project). We made an inspection and photo survey for particulate of the chamber, nozzles, optic and SUS, with not much out of the ordinary observed, save what looks like a tan epoxy-like residue on one chamber wall (sample preserved - the in-chamber cleaning crew has seen a variety of residues before, that have typically FTIR'd clean). We then clamped the optic with EQ stops and teflon, extracted OSEMs, removed DLC mount/black glass etc from the optics table, and un-dogged/lowered the SUS to the flooring. We then removed it from the chamber. It will be set in the EY TMS lab for optic extraction from the SUS. This test mass is bound for KAGRA. Next up is passive stack removal. (Fauver/Landry/Gateley/Layne/Z. Haux/Healis)
We also aligned the HR and AR BS elliptical baffles. The spec for baffle alignment is ±0.5 mm both laterally and vertically. The AR elliptical baffle was aligned with a lateral error of 0.47 mm to the right (facing the baffle from the AR side) and a vertical error of 0.05 mm up. The HR elliptical baffle was aligned with a lateral error of 0.25 mm to the left (facing the baffle from the HR side) and a vertical error of 0.0 mm. This closes out the BS cartidge alignment.
Betsy, Travis
Further notes on the elliptical baffle:
1) We did not encounter the issue that the alignment pins on the target would not fit in the baffle as seen at LLO in this alog - https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=4425. Our pins fit fine into the baffle.
2) However, we DID run into the problem they mentioned where one of the press-fit pins was too tight of a fit in the target. At LLO they apparently reamed out the hole, again mentioned in their alog cited just above. However, since I read that log too late, we forced the pin into one of the targets and broke it off. (Phlltt!) We weren't given much of a hint to assembling/using these, however we were given a spare! Lesson-learned the hard way and we more-carefully assembled the second AOS baffle target.
3) I don't see how the baffle alignment is captured in the mechanics of the baffle if it gets removed. We've been working under the impression that the baffle cannot come off once aligned, which does make installation a bit trickier. Baffle RODA's assure us the baffle is supposed to be "removeable" so we'll pursue how to maintain the alignment with AOS as we haven't stumbled on that in an LLO log.
4) The method of how we aligned the baffle today seems to be the same as what LLO reported in the cited alog above.
4) Lastly, it seems strange to me that the optic height tolerance is 1mm, while the baffle tolerance is 0.5mm.
I restarted and burtrestored the dust monitor and weather station IOCs on h0epics2 that lost communication after the work on the network.
For the 35W laser
In investigating the ISS noise, I tried unlocking the FSS so the mode cleaner had no input to the PSL and took a spectrum. The noise is still there, so I think this rules it out as a noise source, unless they installed some hardware in the outside racks which is loudly humming at 60 Hz. I tried disabling the heater on the PMC which did help clear up the noise around 50 Hz but did not affect the peaks (iss_rpn-005). However, the noise does appear in the HV signal of the PMC when it's unlocked and locked. The peak around 4 kHz shows up in this signal as well, although its position moves by 1-2 kHz. So it looks like it is not the mode cleaner but the PMC causing this noise, maybe in the HV signal.
On the DBB: Rick and I several months back adjusted the lenses in the box to improve the mode matching, using the medm interface. However, we did not save these settings to the safe.snap file and when the DBB was burtrestored it moved the lenses to their old positions. I've updated the values and wrote a new safe.snap file.
It looks like it is the HV that is carrying the 60 Hz noise. I unlocked the PMC again and disabled the ramp input and temperature loop so there was (I believe) no input to the high voltage, and took a time series plot. There is a clear 60 Hz signal present on this channel I haven't seen before. I do not know where this could be coming from, but I will check with IO/ISC people to see if they installed anything near the rack.
[Max and Kiwamu]
A few days ago, we found that there was almost no light coming out from the ALS-PSL fiber [1]. This was thought to be a misalignment in the launcher setup on the PSL table.
Today we entered the PSL room and realigned the setup. Although we screwed up the previous alignment at the beginning due to the lack of a right measurement device, at the end we became able to couple 40% of the incident light (Pin ~ 4.6 mW) into the fiber. Note that the best coupling efficiency in the past was 60% and therefore we maybe able to squeeze some more power from it, but we are satisfied with this number at the moment.
[1] LHO alog 4721 "PSL reference cavity transmission picked-off and launched into ALS fiber"
The network switch firmware updates scheduled for today under work permit #3697 are complete. The following switches/updates were applied: sw-msr-core: Sup7E upgraded to latest maintenance train release IOS-XE 3.4.0 from 3.2.0 (deferred). Rommon upgraded from 15.0(1r)SG2 to 15.0(1r)SG7. sw-msr-ops: Upgraded to IOS 15.0(2)SE1 from 12.2(53)SE2, (includes ucode update). sw-msr-gc: Upgraded to IOS 15.0(2)SE1 from 12.2.(55)SE3, (includes ucode update). sw-lvea-aux0: Upgraded to IOS 15.0(2)SE1 from 12.2.(55)SE3, (includes ucode update). sw-msr-servers: Switch installed, (v 15.0(2)SE1).
WP3698: change of h1iopseib6 model to permit up to 10 IPC errors per second from h1susb6. Completed, required restart of h1hpietmy and h1isietmy as well as h1iopseib6.
DAQ was restarted. This caused some 0x2bad mx_stream errors which resulted in a restart of mx_stream on h1sush34, h1susauxh2,h1seib1 and h1susauxb6. h1psl0 data was seen to go bad during these restarts.
The DAQ restart allowed the configuring of the new H1EDCU_ASCIMC.ini file which has the duplicate GAIN channels removed.
Investigation of DC offset to chan adc_1_7 on h1ascimc is proceding.
In order to help investigate / model the recent problems with IMC closed loop TF changes (see LHO aLOGs 5279, 5294, and 5367), I've copied over the foton file for H1SUSMC2 into the userapps repo and committed, /opt/rtcds/userapps/release/sus/h1/filterfiles/H1SUSMC2.txt Note, though it's been verbally agreed upon during a few CDS software calls, most of these filter files are *not* hard links to the userapps repo. We should really get this decision in a CDS requirements document, and make sure all sub-systems obey -- because now we're in an awkward state where the chans folder is full of original files, soft links, hard links, and it's not clear at any point if the repository or the chans folders is the right place to go for currently-in-use filter files.
LVEA laser safe all day Doug C and Jason working on alignment in LVEA Apollo crew working at EY most of the morning. 0800 - PSL diode chiller water refilled by Michael and Justin 0845 - Carolyn P working at both MX and MY 0915-1115 - Michael R working on FSS in HI PSL 0945 - Hugh working on HAM3 L4C leveling; will coordinate with IMC folks (not currently locked) 1100 - Dale escorting tour group of middle school educators around site, including control room and LVEA. 1245 - Betsy to LVEA working on BS, Dale photographing 1400 - Vincent taking measurements on BSC6.
During the QPD connection check, I found that the segment #4 of the MC2_TRANS showed a big offset of approximately 4300 counts. According to the 10 min trend, this offset has been there from the beginning (Jan. 16th [1]). I disconnected the signal chain at various points to find out which electronics is causing the offset. It seems that the AA board [1][2] is the one. I disconnected the SCSI (which connects the AA board and ADC) to see if it removes the offset and indeed the offset went to zero with the SCSI off. I will have a close look at the AA board tomorrow and hence may need to pull the chassis out of the rack if necessary. Note that because of this investigation the IMC was intentionaly unlocked from approximately 8PM to 9PM.
[1] LHO alog 5127
[2] D0902783
[3] S1102790
Travis, Betsy, Jason, Doug
After the jinxing at the morning meeting regarding how easy the Beamsplitter alignment was going, we proceeded to walk the pitch and yaw DOFs all over the place for most of the day. LIGO Lesson #239: Never assume that things are going well. Lesson #240: Never announce that things are going well in a meeting.
Yesterday, we had the pitch and yaw alignment close albiet at the ends of adjustment ranges in both DOFs. We had a bit of a differential pitch between the top mass and the optic which meant we were unable to center the BOSEMs once pitch and yaw had been aligned. So, after chasing tails a bit, we bit (!) the bullet and used the pushers to adjust the yaw, while keeping the BOSEMs all in range.
We left with yaw and pitch back to being close, but need to finish OSEM alignment in the morning. Then, on to a quick TF set, followed by baffle alignment, as was the plan today.
Attached are plots of dust counts > .3 microns and > .5 microns in particles per cubic foot requested from 5 PM Feb. 3 to 5 PM Feb 4. Also attached are plots of the modes to show when they were running/acquiring data. Michael R. swapped out the dust monitor in the H1 PSL enclosure (location 10 in the LVEA), but the one I gave him to replace it with has stopped counting. Data taken from h1nds1. 660 seconds worth of data was unavailable on this server 1440.0 minutes of trend displayed Dataviewer gave a 'No data output.' message retrieving the data for the counts > .5 microns.
Somehow the hypothesis has been that the peak in the MC OLTF is the structure in FSS and we should be able to mitigate that guy if we retune the FSS notch.
That was attempted today, but the problem is that the peaks the FSS notch is notching out are at about 780 kHz, and MC "peak" we're talking about is a rather broad thing at around 710 kHz. We could move the FSS notch to there, but if we do that the FSS structures are almost totally out of the notch. See attached. Note that the MC OLTF was measured without Evans Notch (TM).
It's clear that the "peak" we're talking about is not the FSS peak per se, it's either a simple gain peaking or something that is not there in FSS. Keeping Evans Notch (TM) sounds fine to me, but if somebody feels the need to put move it out on the option board in the common mode board, please feel free.
Correction: Both the OLTF of MC without (middle) and with (bottom) the notch in the MC path are in the plot.