Transfer functions measured after circuit modifications made to the injection locking field box. The gain voltage setting behaviour does not appear to be correct.
probably oscillating for gains <0V, ie., >20dB.
TITLE: 11/02 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Lcok Acquisition
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: Bad. All locklosses tonight were caused by PI 18043Hz (Mode27). See alog31111 and comments therein. There were 6 locklosses total. I didn't keep track of all the lockloss times. None of the modes were PLL locked but only one or two casued trouble. Mode 26 also rung up but was able to damp once I get the BP filter to match the peak frequency. Not as straight forward for Mode 27.
LOG:
08:50 Lockloss
12:06 CO2X 0.2W --> 0.4W
12:09 Intent bit set
12:25 Intent bit dropped. CO2X Guardian finds lock point
12:32 Intent bit dropped. CO2X Guardian finds lock point
12:37 Lockloss
13:05 NLN. CO2X 0.2W --> 0.4W
13:39 Lockloss. Peter wants to make some measurement with the PSL so I kept the IFO down.
14:34 Peter out
Note:
Measured transfer functions after yesterday's circuit board modifications. The MEDM gain slider was increased from 0 in increments of 3.
I noticed this before, where the gain slider is miscalibrated by a factor of 2. 0dB to 40dB is mapped into +/-10V, but it looks like you only need +/-5V for the full range.
Started yesterday evening. Doesn't seems to be equally spaced.
It could be pickup through the unshielded part of the RTD cable (where it comes out of the laser), but it's strange that it started in X and Y at the same time. Can you check the FLIR cameras are turned off on the MEDM screen.
Apparently there is a "glitch" in the laser power of both X and Y TCS systems every time the Laser power meter sees a request for a power change. (see 1 day trend with additional channels to correlate with). However, this did not just start yesterday, it has been going for at least a month (see second plot of the last 3 days). I spot checked back a month and the behavior is the same. Note, there are a few extra spikes on these channels but this doesn't seem to be new behavior.
Update: I looked closer at these glitches.
Characteristic:
A single glitch spans across multiple sample points, lasted a little less than half a second. Almost everyone of these glitches lead by one smaller glitch that's roughly 1.5 second apart, followed by an even smaller glitch and immediately followed by a larger glitch.
Timeline:
I looked back several months and it seems like these glitches started to show up much more frequently on May 13th this year (started at 16:28 UTC to be precise). I looked back on the alog and didn't find any invasive work with the TCS on May12th or 13th.
I checked to make sure the line and the BP matches. Changing the phase both on the main PI medm screen and on the damping filter doesn't make a different. The PLL green light is on but Shelia mentioned that PLL is not actually locked and I don't know how to make it locked (some other modes with PLL green light indicator also have red PLL lock status). I also tried to zero the gain as Sheila suggested.
Then I found that until Maintenance morning (1 Nov 18:26 UTC to be precise) this mode has been using OMC DCPD as its input signal. It was magically switched to be using TRY QPD. I put the gain back to where it was in the matrices. We'll see how it goes.
Okay doing that somehow kill the input signal alltogether. I let through the signal from TRY QPD again but zero the damping gain.
Nevermind. Reverted it. Things became bad real fast as soon as I let through signal from TRY QPD for Mode27.
And PI broke the lock. This is the 4th lockloss caused by PI tonight.
And 5th time. The time constant is about the same as previous locklosses so I guess switching input from TRY QPD to OMC DCPD doesn't matter. In fact I couldn't get any signal from OMC DCPD so that's even worse since I have zero chance of damping it. I'm going to try the original setting again but this time alter the gain (which I have also tried).
And 6th time.
TITLE: 11/02 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Nominal Low Noise/Commission
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT: Wind: 16mph Gusts, 13mph 5min avg Primary useism: 0.03 μm/s Secondary useism: 0.29 μm/s
QUICK SUMMARY: Before Stefan left he asked me to make some TF measurement. So I'm going to spend some time doing that before setting the intent bit. Locking went smoothly.
After today's changes to the PMC servo, which included increasing the loop gain, we noticed a familiar bump around 4.2kHz in DARM. Lowering the PMC gain from 16dB to 0dB made the bump smaller in DARM (see images). Given the coherence with REFL9, it seems that this is coupling through frequency noise.
We also made a small exploration around the already good PMC input beam alignment. This didn't have much impact, but it revealed that small changes in the alignment can change the input offset to the PMC servo. That is, the offset which maximizes the PMC throughput can be changed with small alignment tweaks. Using this effect, we made a 0mV input close to optimal (see second image).
Tagging PSL and ISC.
J. Kissel In order to improve the uncertainty on the parameters the lines are measuring, I've adjusted the line heights of a good fraction of the calibration lines. I'll leave them in like this overnight, and see if we get the expected improvement in the uncertainty (especially as reported by the front-end). Line Freq Former New PCALY 36.7 750 500 331.9 2900 5000 7.9 20000 5000 ETMY UIM 33.7 60 180 ETMY PUM 34.7 27 81 Note the reduction of the 7.9 and 36.7 Hz modes. We don't always increase line heights ;-).
23:03 Fil out of LVEA WP6292
23:05 Dick G into CER
23:15 Dick back
23:34 Robert and Ansel out to EY, then EX
Since the cdsutil avg function kept failing, we replaced it by the average of 20 ezcareads - 0.2sec apart.
This was done in a separate state - PREP_TR_QPD_SUM_OFFSET.
Admittedly not the most aestetic fix, but it seems to work reliably.
Notes:
0) A2L gains of order two are getting suspicious, because it essentially means some coils are shut off.
1) ITMY_Y2L was always large (~-2) , but since 10/29 7UTC it is even bigger.
2) ITMX_Y2L also got big (~2) on 10/29 7UTC
Not sure what to make of this...
Tagging SUS.We should check functionality of coils.EDIT: Checked the functionality of the coils by taking a quick transfer function between COILOUT_EXC channels (OSEM basis excitation channels closest to the DAC output), and the various coil driver monitor channels. Though I've not taken the time to calibrate or understand the signals, I see no differences between the quadrants, and plenty of coherence between all drives and responses. I don't think there's anything wrong with the ITM L2 actuators. Note to self -- next time include OSEM sensors and optical levers in your template for those who don't trust the functionality of the coil driver monitor channels. The templates (attached) live here: /ligo/home/jeffrey.kissel/2016-11-02/ (apologies for my laziness -- I figured it would be faster to just create new templates than to find the one's Ed used to characterize the monitor signals that are likely committed to the SusSVN. #slapsownwrist) Also note that - The IFO was DOWN during this measurement. - I turned off the PIT optical lever damping during the measurement so as to not confuse anything.