Hoping for a light Maintenance (since many activities done yesterday) & aiming for ending at noon. Cheryl handed over a locked H1 & it stayed locked for quite a while into Maintenance before dropping out....
H1 PSL appeared to trip (causing lockloss). Peter & Jeff B addressed and are looking into why it dropped out.
I have added MEDM overview screens for H1 SUS ETMX, ETMY to the CDS web screen shots pages.
This morning when the interferometer was down, I went to the ISCT6 table and removed the temporary digital camera or CAM17 (that was for the SRC Gouy phase measurement, see for example 29389). The beam for this camera is currently dumped by an additional razor blade dump on the table. The ethernet cable was re-routed and plugged to the OMCR camera which is the nominal cabling configuration. Additionally, I have left the base plate for the camera untouched in case we want to revisit the same measurement.
State of H1: locked in NLN in Observe
Commissioners: Sheila, Jenne (early in the shift)
Activities:
Violin Mode Damping:
Noise Tunings:
a2l:
Observe:
Because we are probably not going to be able to close the pop beam diverter right away, I removed it from the CLOSE beam diverters state and added this state back into the normal path to nominal low noise, so that at least the AS and REFL beam diverters will be nominally closed for the start of the run.
State of H1: Initial Alignment just completed, working to lock full IFO
Commissioners: Jenne, Sheila
Activities:
Kiwamu and I installed the new piezo mirror mount. The frequency of the peak in quad diodes increased and was damped as expected, but the final arbitrator is DARM and we havent locked yet. I will put in a log with details when we do.
Jenne, Sheila Keita
We had another instance of a jump in POP90, in which both the I and Q phases increased. We think this is a problem with the readback, similar to what is described in 31181.
We were acquiring lock, and had no ASC running on the SRC. We looked at witness sensors for all the interferometer optics, and it looks like none of them moved at the time. We also don't see changes in other RF sensors, like AS36, AS90, or POP18. We looked at both quadratures of POP90 before rotation and it seems to have both a phase shift and a 3.5 dB increase in the sum of I+Q. The RFmon and LO mon on the demod don't have any jumps nearly that large, so if it is a problem in the demod it is probably downstream of the directional coupler for the RFmon.
This seems not to be the same as the jumps in SRC alingment that started after last tuesday's maintence, (31804 31865 and other alogs), but since the symptom is very similar it would make debugging the other problem easier if this issue could be fixed. Since we use POP90 for a dither lock of the SRM angle durring lock acquisition, this can cause a lockloss if it happens while we are trying to lock.
I tested the chassis that was pulled out (S1000977). During the testing I did not see any level changes
or glitches in either the I or Q channel outputs, except when a pair of cables to attached to the front
panels via a BNC tee were strongly wiggled. Removal of the tee and wiggling the cables directly didn't
induce any changes. Attached is an oscilloscope trace of the I&Q monitor output for the POP90 channel.
It is fuzzy because of an RF amplitude modulation I was applying, however the distortion discontinuities
are present with the modulation off.
Daniel pointed out to me that the distortion is due to my not looking at the signal
differentially on the oscilloscope. Sure enough it looks a lot cleaner when processed differentially.
I did however notice that if the RF input is more than -11 dBm, the monitor signals on the rear panel are
saturated/distorted.
The only other output level changed that was observed was when the chassis was turned off in the
evening and back on again the following morning.
The chassis (strictly) failed the following tests:
- front panel monitor coupling factors (all channels at 100 MHz, failed by less than 1 dB)
- IF beat note amplitude versus frequency (all channels, I & Q, at 100 kHz, failed by as little as 50 mV
and as much as 360 mV)
- IF output noise level (channel 3, I & Q, failed by as little as 3 dB and as much as 4 dB). Channel 3
is labelled as REFLAIR_27.
By any chance when the chassis was in the rack, was there more than one cable attached to the (one)
front panel BNC connector?
With our slight pre-O2 changes to the control room displays, Sheila has added the new darmBlrms.stp StripTool that Anamaria made while she was here to Video0.
The BLRMS frequencies are not part of the channel names, so I list them here. To double-check, or change them, open the auto-generated screens at /opt/rtcds/lho/h1/medm/h1oaf/H1OAF_RANGE_RBP_#.adl, where # is 1-10. All of these also have a matching /opt/rtcds/lho/h1/medm/h1oaf/H1OAF_RANGE_RLP_#.adl with a 240dB gain and 0.1Hz lowpass.
Right now, we just have #s 1-5 in use:
[JimW, JeffK, Jenne]
Several times today we've had to hand-request the OMC guardian to go to ReadyForHandoff, after it fails to find the carrier during the PZT scan. I'm a little unsure why it sometimes works, and sometimes doesn't, since the scans look quite similar.
In the two attached screenshots, once the OMC scan worked, and once it didn't. The one that includes "succeed" in the filename starts at a slightly lower DCPD value (below 2mA), whereas the "failed" time the DCPD value starts at around 5mA, so maybe that's the difference in it recognizing that the first peak on the left is one of the 45MHz sidebands? I'll have to look at the OMC scan code, but if that's not it, then I'm certainly confused.
Okay, fixed.
Since the first 45MHz peak is so close to the start of the scan, the "pzt_diff" value that the OMC guardian is looking for isn't super accurate, so it's failing a test and returning the OMC to its Down state.
What the scan is doing is chunking the data into 7 pieces, and then finding the max value in that piece. It then compares the max DCPD value from each of those 7 chunks. It decides that it has found a pair of 45MHz peaks if the peaks are within 25% of the same height and are within 18V (where V are from the PZT2_MON_DC_OUT channel). Since we're at the beginning of a ramp, and it's the soft CDS ramp and not a sharp triangle ramp, I think that the peak location is maybe not getting mapped exactly correctly to the PZT value, so sometimes it looks like the 45MHz peaks are 18.03V apart, which causes the test to fail. However in some cases, like the "succeed" case from the parent comment, the difference is found to be something like 17.95V, which barely passes the test.
I have increased the acceptable peak difference to 20V. As you can see in the screenshots in the parent comment, the 45MHz peaks that are not a matching pair are more than 30V apart.
Upon our first try after this change, the pzt difference that it found was 18.05V, but kept locking happily since this is lower than the new threshold of 20V.
Robert, Kiwamu,
This is a summary of the recovery of the IMC alignment after the PSL PZT mirror mount swap today (for which I think Robert will make a separate report).
Synopsis-
IMC seems to have shifted its waist location horizontally by 0.25 mm based on the change seen by the suspension witness sensors. This apparently was large enough to reduce the amount of light at IMC-TRANS by a factor of two presumably due to a worse in-vac clipping in HAM2. Nevertheless, as of now, we seem to be able to lock the interferometer on DC readout without new issues.
Recovery process-
We temporarily placed an iris after the top periscope mirror and before the beam tubing. After the swap, we checked two existing irises that had been on the table and the new one at the top of the periscope to coarsely recover the alignment. Then checking the spot on the PSL wall coming out from the light pipe between the PSL and HAM1, we did a fine alignment. This was good enough to put us back to a position where we see the main light on IMC REFL camera. A final alignment was then done by engaging IMC ASC which automatically servoed the alignment to an optimum. The temporary iris was removed before we left the PSL.
After the successful lock of IMC and successful engagement of IMC ASC, we noticed that the IMC TRANS is smaller by a factor of two. This seems to be due to a slight change in the horizontal direction in the uncontrolled degree of freedom. Here is a table listing several changes in some relevant sensors.
| before | after | diff | |
| MC1 PIT witness | -3 | -2 | +1 urad |
| MC2 PIT witness | 510 | 507 | 0 |
| MC3 PIT witness | -841 | -842 | -1 urad |
| IM4 PIT | -0.33 | -0.34 | almost 0 |
| MC1 YAW witness | -1035 | -1043 | -8 urad |
| MC2 YAW witness | -672 | -672 | 0 |
| MC3 YAW witness | -996 | -987 | +9 urad |
| IM4 YAW | 0.25 | -0.08 | - 0.33 cnts |
As shown above, the only appreciable change is that in DOF2 of IMC YAW (highlighted by red texts). Using Kawazoe's formula (P1000135), one can find that this amounts to a lateral shift of the spot position by 0.25 mm toward HAM3 or away from PSL. [EDIT] Keita pointed out that the direction of the move that I initially reported was wrong. So the correct statement is that the beam shifted by 0.25 mm toward the PSL or away from HAM3.
Things we didn't optimize-
Two addenda.
Firstly, to cope with the fact that IMC TRANS decreased by a factor of two, I have edited the IMC_LOCK guardian and lowered all the FM_TRIG_THRESH_ON and _OFF values by a factor of two. In addition, I manually changed the IMC-MCL_TRIG_THRESH_ON and _OFF values by a factor of two as well. They don't seem to under control of any guardians. IMC locks fine with these new settings. The guardian is then checked into SVN.
Secondly, the spot positions on the PSL wall seem to have shifted by 1-2 mm towards the West. No obvious change was found in the vertical direction. See the attached picture. The new positions are recorded with black 'X' marks as shown in the picture.
Jenne and I did a repeat of what we tried a few weeks ago after different PSL work: (30918) we restored the optics to their old values using the witness sensors, then moved the piezo to maximize build up without turning on the IMC WFS. This brought the spot back to its before position on IM4 trans, although the MC2 trans sum was low, so we think that as expected only the input beam has moved, not the mode cleaner optics or IMs. However, we can't fix the input beam change simply by moving the PZT.
We let the MCWFS run to increase the mode cleaner transmission, and watched the spots on both the ISS QPD and IM4 trans. We walked IM3 and IM2 in yaw to bring both QPDs back to the spot positions before this morning's PSL work, and now Cheryl is doing inital alingment.
To move this degree of freedom, we moved IM2 1.284 urad in yaw for every urad that we moved IM3. Since this is a degree of freedom that our inital alingment and ASC don't control, it may be a good idea to try moving this degree of freedom in full lock to see what impact it has on our noise and recycling gain. For the record, today we moved IM3 -2390 urad, and IM2 -3030 urad.
Following up on the DetChar report of ETMx oplev laser glitching causing problems, I confirmed (using the DetChar summary pages) that the laser was indeed showing signs of glitching. I also noticed the ETMy laser was also showing signs of glitching. I increased the power for both lasers to hopefully get them into a thermal state they are happy with. I used the Current Monitor (outputs a voltage to monitor the current delivered to the laser diode) port on the back of each laser as a guide. The changes were:
Seeing as I had to open the cooler for both lasers they will both need 4-6 hours to return to thermal equilibrium. At that point a determination can be made as to whether or not this helped at all. The attached 3 hour trend of the oplev SUM for both optical levers gives hope; after the power increase the SUM signal is quieter for both oplevs. I will leave WP 6348 open for now as more adjustment may be necessary to fix the glitching.
Further power adjustment for both lasers this morning as both were still showing signs of glitching (better than yesterday morning, but not gone). Changes are:
As before these lasers will need ~4 hours to return to thermal equillibrium before I can assess whether or not this latest tweak helped.
Keita, Sheila
At 11 am pacific time (19:00 UTC Nov 22nd), there was a sudden shift in alignment in the SRC that caused bad noise in DARM. The first attached screenshot shows the noise in DARM changing.
At this time, there is a shift in the alingment of SRM and SR2 in both pit and yaw, and other interferometer optics don't move significantly. The OMs and OMC suspensions move as well, but that appears to be a result of the feedback. There is also an increase in POP90, a small drop in AS_A DC, and a small increase in AS90. The signals on all 4 quadrants of ASA36 I change (the in loop signal, where we are using a funny matrix to take care of an offset). On AS36 B, we see pitch signals, but not much signal in yaw. Also, the RF levels on all quadrants of AS36 WFS change by 5 to 8dB, which could be the result of the alignment shift.
We looked at conlog for any changes at the time, there were only PI settings changing, we don't think there was anyone in the LVEA or CER at the time.
The most obvious sign for an operator that this has happened would be that POP90 jumps suddenly in the middle of a lock stretch. If this happens again, people could (go out of observe) open the SRC1 ASC loops by ramping the gains to zero, then try moving SRM to bring POP90 back to a normal level.
Do we get to see POP90 when the Beam Diverters are closed?
When the POP beam diverter is closed we won't see POP90.
On Thursday we (Sheila, Daniel & I) increased the Thresholds on the TIDAL RED TRIGGER when the very low value kept the ISC driving the HEPI too long. It would appear there was only one long lock stretch with these settings before Sheila reported that the tidal was not coming on, in some locks. Beam diverters?... When Nutsinee reverted the values of the RED TRIGGER Thresholds, things seemed to start working properly again. I don't pretend to understand this and it is pretty clear that reverting the values solved the problem. See attached four days trend, when lowering the THRESH_ON value started the TIDAL running (I did not zoom in but it looks correlated.) But also seen is the REDTRIG_INMON has dropped to 153000 from the previous 165000. If this level (Power?) change was enough to disable the 8000 count THRESH_ON setting, clearly something else must be in play. I need to understand the triggering better to really understand this. We don't want the ISI to trip as it can be several minutes for the T240s to settle and be ready for complete ISI isolation but obviously we need the TIDAL relief to engage.
It might be that the threshold wasn't exceeded, when it tried to engage REDLOCK. The fundamental problem is that neither the arm power nor the trigger thresholds are getting scaled with the power up, so the threshold needs to be set low enough to catch the lock at low power. Once you power up, the arm powers will then be far above threshold. Too much it seems. Probably best to figure out how to scale the NSUM value with the inverse of the input power. Alternatively, one could rewrite the trigger so that it scales automatically.
Opened FRS Ticket 6787. This has happened a few more times this evening.
14:31UTC: H1 is in Observe
Manually put IMC_LOCK in ISS_DC_DECOUPLED, then H1 into Observe
Noise Tunings attachments: