I restarted the LSC models in the usual way via the c1lsc reboot script. After doing this I was able to lock the YARM configuration for more noise coupling scripting.

The IMC has been misbehaving for the last 5 hours. Why? I turned the WFS servos off. afaik, aaron was the last person to work on the IFO, so i'm not taking any further debugging steps so as to not disturb his setup.

That was likely me. I had recentered the beam on the PD I'm using for the armloss measurements, and I probably moved the wrong steering mirror. The transmission from MC2 is sent to a steering mirror that directs it to the MC2 transmission QPD; the transmission from this steering mirror I direct to the armloss MC QPD (the second is what I was trying to adjust).

Note: The MC2 trans QPD goes out to a cable that is labelled MC2 op lev. This confusion should be fixed.

I realigned the MC and recentered the beam on the QPD. Indeed the beam on MC2 QPD was up and left, and the lock was lost pretty quickly, possibly because the beam wasn't centered. Lock was unstable for a while, and I rebooted C1PSL once during this process because the slow machine was unresponsive.

When tweaking the alignment near MC2, take care not to bump the table, as this also chang es the MC2 alignment.

Once the MC was stably locked, I was able to maximize MC transmission at ~15,400 counts. I then centered the spot on the MC2 trans QPD, and transmission dropped to ~14800 counts. After tweaking the alignment again, it was recovered to ~15,000 counts. Gautam then engaged the WFS servo and the beam was centered on MC2 trans QPD, transmission level dropped to ~14,900.

This problem resurfaced. I'm doing the debugging.

6:30pm - "Solved" using the same procedure of stepping through the whitening gains with a small (10 DAC cts pk) signal applied. Simply stepping through the gains with input grounded doesn't seem to do the trick.

Gautam was doing some DRMI locking, so I replaced the photodiode at the AS port to begin loss measurements again.

I increased the resolution on the scope by selecting Average (512) mode. I was a bit confused by this, since Yuki was correct that I had only 4 digits recorded over ethernet, which made me think this was an i/o setting. However the sample acquisition setting was the only thing I could find on the tektronix scope or in its manual about improving vertical resolution. This didn't change the saved file, but I found the more extensive programming manual for the scope, which confirms that using average mode does increase the resolution... from 9 to 14 bits! I'm not even getting that many.

There's another setting for DATa:WIDth, that is the number of bytes per data point transferred from the scope.

I tried using the *.25 scope instead, no better results. Changing the vertical resolution directly doesn't change this either. I've also tried changing most of the ethernet settings. I don't think it's something on the scripts side, because I'm using the same scripts that apparently generated the most recent of Johannes' and Yuki's files; I did look through for eg tds3014b.py, and didn't see the resolution explicitly set. Indeed, I get 7 bits of resolution as that function specifies, but most of them aren't filled by the scope. This makes me think the problem is on the scope settings.

sstop using the ssscope, and just put the ssssignal into the DAQ with sssssome whitening. You'll get 16 bitsśšß.

I ran a BNC from the PD on the AS table along the cable rack to a free ADC channel on the LSC whitening board. I lay the BNC on top of the other cables in the rack, so as not to disturb anything. I also was careful not to touch the other cables on the LSC whitening board when I plugged in my BNC. The PD now reads out to... a mystery channel. The mystery channel goes then to c1lsc ADC0 channels 9-16 (since the BNC goes to input 8, it should be #16). To find the channel, I opened the c1lsc model and found that adc0 channel 15 (0-indexed in the model) goes to a terminator.

Rather than mess with the LSC model, Gautam freed up C1:ALS-BEATY_FINE_I, and I'm reading out the AS signal there.

I misaligned the x-arm then re-installed the AS PO PD, using the scope to center the beam then connecting it to the BNC to (first the mystery channel, then BEATY). I turned off all the lights.

I went to misalign the x-arms, but the some of the control channels are white boxed. The only working screen is on pianosa.

The noise on the AS signal is much larger than that on the MC trans signal, and the DC difference for misaligned vs locked states is much less than the RMS (spectrum attached); the coherence between MC trans and AS is low. However, after estimating that for ~30ppm the locked vs misaligned states should only be ~0.3-0.4% different, and double checking that we are well above ADC and dark noise (blocked the beam, took another spectrum) and not saturating the PD, these observations started to make more sense.

To make the measurement in cds, I also made the following changes to a copy opf Johannes' assess_armloss_refl.py that I placed in /opt/rtcds/caltech/c1/scripts/lossmap_scripts/armloss_cds/   :

• function now takes as argument the number of averages, averaging time, channel of the AS PD, and YARM|XARM|DARK.
• made the data save to my directory, in /users/aaron/40m/data/armloss/

I started taking a measurement, but quickly realized that the mode cleaner has been locked to a higher order mode for about an hour, so I spend some time moving the MC. It would repeatedly lock on the 00 mode, but the alignment must be bad because the transmission fluctuates between 300 and 1400, and the lock only lasts about 5 minutes.

Back to loss measurements.

I replaced the PD I've been using for the AS beam.

I misaligned the x arm.

I tried to lock the y arm, but PRC was locked so I could was unable. Gautam reminded me where the config scripts are.

The armloss measurement script needed two additional modifications:

• It was setting the initial offset of the PIT and YAW demod signals to 0, but due to the clipping on the heater we are operating at an offset. I commented out these lines.
• When the script ran UNFREEZE_DITHER, it was running it using medmrun. The scope script hadn't been using this, and it seemed that when it ran UNFREEZE_DITHER in this way the YARM_ASS servo was passing only '0'. I don't really know why this was, but when I removed the call to medmrun it worked.

I ran successfully the loss measurement script for the x and y arms. I'm getting losses of ~100ppm from the first estimates.

I made the following changes to the lossmap script:

• make the averaging time an input to the script, so we can exceed 2 second averages
• remove anything about getting data from the scope, replace it with the correct analogues to save the averages for POX/POY refl, MC trans, op lev P/Y, and ASDC signal.
• record the GPS time in the file with the cds averages (this way I can grab the full data)
• Added a step in the lossmap script to misalign the optic, so we can continue getting data for the 'misaligned' state, both for the centered and not-centered measurements (that is, for every position on the lossmap).

When the optic aligns itself not at the ideal position, I'm noticing that it often locks on a 01. When the cavity is then misaligned and restored, it can no longer obtain lock. To fix this, I've moved my 'save' commands to just before the loop begins. This means the script may take longer to run, but as long as the cavity is initially locked and well aligned, this should make it more robust against wandering off and never reacquiring lock.

I left the lossmap script running for the x-arm. Next would be to run it for the y arm, but I see that after stepping to a few positions the lock is again lost. It's still trying to run, but if you want to stop it no data already taken will be lost. To stop it, go to the remaining terminal open on rossa and ctrl+c

the analysis needs:

• Windowing
• Filter, don't average
• detrend to get rid of the linear drifts in lock that we see.
  • Is this the right thing?

I made additional measurements on the x and y arms, at 5 offset positions for each arm (along with 6 measurements at the "zeroed" position).

need to vary start/stop times in fit to test for systematics

• Power just before PSL shutter on PSL table = 97 +/- 1 mW. Systematic error unknown.
• Power from IFO REFL on AP table = 40 +/- 1 mW. Systematic error unknown.

Both were measured using the FieldMate power meter. I was hesitant to use the Ophir power meter as there is a label on it that warns against exceeding 100 mW. I can't find anything in the elog/wiki about the measured inesrtion loss / isolation of the input faraday, but this seems like a pretty low amount of light to get back from PRM. The IMC visibility using the MC_REFL DC values is ~87%. Assuming perfect transmission of the 87% of the 97mW that's coupled into the IMC, and assuming a further 5% loss between the Faraday rejected port and the AP table, the Faraday insertion loss would be ~30%. Realistically, the IMC transmission is lower. There is also some part of the light picked off for IPPOS. Judging by the shape of the REFL spot on the camera, it doesn't look clipped to me.

Either way, seems like we are only getting ~half of the 1W we send in on the back of PRM. So maybe it's worth it to investigate the situation in the IOO chamber during this vent.

c1psl, c1susaux,c1iool0,caux  crates were keyed. Also, the physical shutter on the PSL NPRO, which was closed last Monday for the Sundance crew filming, was opened and the PMC was locked. PMC remains locked, but there is no light going into the IMC.

In order to see the AS beam a bit more clearly in our low-power config, I swapped out the ND=1.0 filter on the AS camera for ND=0.5.

I'm running a script that moves TT1 and TT2 randomly in some restricted P/Y space to try and find an alignment that gets some light onto the TRY PD. Test started at gpstime 1228967990, should be done in a few hours. The IMC has to remain locked for the duration of this test. I will close the PSL shutter once the test is done. Not sure if the light level transmitted through the ITM, which I estimate to be ~30uW, will be enough to show up on the TRY PD, but worth a shot I figure.

Test was completed and PSL shutter was closed at 1228977122.

I removed the ND filter from the ETMYT camera to facilitate searching for a TRY beam. This should be replaced before we go back to high power.

I've suspected that the TTs are drifting significantly over the course of the last couple of days, because despite repeated alignment efforts, the AS beam spot has drifted off the center of the camera view. I tried looking at IPPOS, but found that there was no data. Looking at the table, the QPD was turned backwards, and the DAQ cable wasn't connected (neither at the PD end, nor at 1Y2, where instead, a cable labelled "Spare QPD" was plugged in). Fortunately, the beam was making it out of the vacuum. So as to have a quantitative diagnostic, I reconnected the QPD, turned it the right way round, and adjusted the steering onto it such that with the AS spot on the center of the CCD monitor, the beam is also centered on the QPD. The calibration is uncertain, but at least we will be able to see how much the spot drifts on the QPD over some days. Also, we only have 16 Hz readback of this stuff.

I leave it to Chub to take the high-res photo and update the wiki, which was last done in 2012.

Already, in the last ~1 hour, there has been considerable drift - see Attachment #2. The spot, which started at the center of the CCD monitor, has now nearly drifted off the top end. The ITMX and BS Oplev spots have been pretty constant over the same timescale, so it has to be the TTs?

To debug the issue of the suspected drifting TTs further, I temporarily hijacked CH0-CH8 of ADC1 in the c1lsc expansion chassis, and connected the "MON" outputs of the coil drivers (D010001) to them via some DB9 breakouts. The idea is to see if the problem is electrical. We should see some  slow drift in the voltage to the TTs correlated with the spot walking off the IPPOS QPD. From the wiring diagram, it doesn't look like there is any monitoring (slow or fast) of the control voltages to the TT coils, this should be factored into the Acromag upgrade of c1iscaux/c1iscaux2. EPICS monitoring should be sufficient for this purpose so I didn't setup any new DQ channels, I'll just look at the EPICS from the IOP model.

IMC was not locked for the past several hours. Turned out MC autolocker was stuck, and I could not ssh into megatron because it was in some unresponsive state. I had to hard-reboot megatron, and once it came back up, I restarted the MCautolocker, FSS slow servo and nds2 processes. IMC re-locked immediately.

I was pulling long stretches of OSEM data from the NDS2 server (megatron) last night, I wonder if this flakiness is connected. Megatron is still running Ubuntu12.

Can we get some panel mount FC/APC connectors and put them on a box?   Then we could have the whole setup inside of a box that is filled with foam and sits outside the PSL hut. 

Steve had showed me some stock of long fibers a while back - they are from Oz Optics, and are 50m long, and are already spooled - so barring objections, we will try the MZ setup with the spooled fiber and see if there is any improvement in the fringing rate of the MZ. Then we can evaluate what additional stabilization of the fiber length is required. Anjali will upload a photo of the spooled fiber.

• Attchment #1,2,3 and 4 shows the results with frequency modulation of 32 Hz, 140 Hz , 300 Hz and without frequency modulation. I am trying to understand these results better.
• A lot of fringing is there even when no modulation is applied. We hope to improve this by spooling the fiber and then encasing it in a box. 
• As mentioned by Gautam, we have got a 50 m spooled fiber. Attachment #5 shows the photo of the same

At ~4pm, the main volume pressure (CC1) was reported to be ~5e-5 torr. So I replaced the HR mirror in the MC REFL path with the usual 10% beamsplitter, and aligned the beam onto MCREFL photodiode. I also replaced the ND filter on the AS port camera, and in front of the IPPOS QPD.

Then I turned up the power by HWP rotation - at the input to the IMC, I now measured 960 mW with the Coherent power meter, so the NPRO power has certainly decayed by ~10% from 2018 July. Normal high-power IMC autolocker script was re-enabled on megatron (and the slow servo enable threshold raised from 1000 cts to 8000cts). IMC was readily locked, after some hand alignment, I got a maximum of 14500 cts transmission. I was then able to lock the Y-arm. The dither alignment servo did not work with the nominal settings, but by hand alignment, I was able to get TRY up to 0.6 (I didn't try too hard to optimize this in any systematic way). X arm was also locked.

AUX drypump valved off and shutdown at ~610pm. I also switched both TP2 and TP3 to their lower rotation "standby" mode. So overall no major mishaps this time around. I am leaving the PSL shutter open over the long weekend. For in-air vs vacuum suspension spectra comparison, I kicked the ETMY optic at Fri May 24 18:26:10 PDT 2019.

Since ~ 2 hours ago, the IMC autolocker has not been able to keep the IMC locked. I don't see any obvious trends in the wall StripTool that may point to what's going on. For the brief periods in which a TEM00 mode is locked, the PC Drive RMS level is ~5x what the nominal level is, and while the autolocker is trying to lock the IMC, the PC drive RMS level is hovering around 4V DC, which is high. The PMC Error and Control signal spectra show huge 60 Hz (and harmonics) peaks, and indeed this is visible in the time domain signals as well (on ndscope or on the oscilloscope on the PSL table), but this is not a new feature in the last two hours. Usually, this kind of problem signals that either/both the c1psl or c1iool0 slow machines need to be power-cycled, but I confirmed that both machines are online and telnet-able. Possibilities: (i) some card in the c1psl / c1ioo crates have failed or (ii) something in the MC/FSS electronics chain has failed or (iii) there is a huge amount of excess high-frequency noise from the NPRO.

I am leaving the PSL shutter closed.

I briefly managed to lock the IMC today - it stayed locked for ~10 minutes. Attachment #1 shows spectra of a few error and control signals for today's lock, and from a stretch yesterday before the problems surfaced*. The 60 Hz lines are much bigger, and MC_F signals broadband excess noise above a few Hz. I suspect a problem somewhere in the electronics.

*I confess the comparison isn't entirely valid because I had to tweak the FSS FAST gain from its nominal value of 22 to 25 in order to get the PC drive RMS down to the ~1.5V level. At the nominal gain setting, with the laser frequency locked to the cavity length, the PC Drive RMS was ~4 V. Still, indicative of something being off in the electronics.

As per Gautam's request, I looked at the IMC situation.

Locking path

• Acquisition: IMC IN1 Gain +4 (nominal), Boost 0, VCO Gain (-32), FSS Common +6 (nominal), FSS FAST +20
  This is too low gain. So oscillate VCO Gain between -32 and ~0 until TEM00 lock is acquired
• Once lock is acquired, bring the VCO gain to +11 (new nominal), and increase the FSS FAST to +23 (new nominal). Change the IMC BOOST to 3 (nominal)

Diagnosis

• The PMC servo gain was checked. The control signal monitor for the PMC actuation was hooked up to SR785. The nominal gain was +18dB. Increasing the gain to 20dB made the servo oscillating. So the nominal gain of +18dB seems still reasonable.
• The status of NOISE EATER was checked. Both the PMC REFL and TRANS were looked at by AG4395A. The power spectrum of them did not change much around the kHz~MHz region. It made the PSD slightly (x2~3) improved below 1kHz. I also did not recognize the relaxation oscillation peak. So I could not figure out where to see. NOISE EATSER was on and is still on.
• IFO Modulation Freq: I took this chance to look at the IMC absolute length using the peak at 3.6MHz. The TP1A output of the IMC servo board was hooked up to AG4395A.
  The new FSR of the IMC (and thus the modulation frequency for the IFO) is 11.066275MHz (instead of the previous 11.066209MHz).
  This corresponds to 0.16mm difference in the roundtrip length.
• (*Still working) IMC SERVO configuration:
  • FAST 25 (nominal) sometimes invoke the oscilattion. 24 has gain peaking ~30kHz. There is a big line peak at 35kHz so wanted to avoid the servo bump (PZT-EOM cross over). So decided to use 23dB. (This is not optimal for the CM servo as we need as much as bandwidth for CM servo.)
  • IMC VCO GAIN (bad name. this is actually overall output gain for IMC) was increased from the nominal 7 to 11. Increasing this above 11 makes the servo oscillating at ~200kHz.
• (*Still working) Measured power spectrum of the error signal. Too many line peaks.
• (*Still working) Single trigger observation: Oscilloscope monitoring started from 35kHz going up and ~20kHz oscillation +/-6V of the IMC servo output was observed. Could not capture good data for this. Try the other day.

I'll complete the entry later.

Continuing this investigation of the IMC, today I am getting familiar with the PMC and FSS. I'd like to measure the frequency noise of the PSL referenced to the PMC.

I checked that the PSL shutter is off, so no light reaches the IMC.

I'm not really sure what I'm looking for on the FSS boxes. I found a few documents to guide:

• On the tabletop testing of FSS for LIGO
• 40m wiki

I ran the FSS autolock script from C1PSL_FSS, nothing obvious changes when I do so. The FSS error signal (which I think is PSL-FSS_MIXERM) is flatlined, and the RC-RF_PD has no LO (PSL-FSS_LOCALC is nan).

SURFS want some locking of IMC for camera adjustment.

So I left the IMC with intermediate gains so that it keeps locking and unlocking.

VCO (overall) iMC gain of -32, FSS common gain 3, and the FAST gain 20. I believe MC2tickle is ON too.

The circuit diagram for the PMC servo card is D980352. From this diagram, I see that I can send an excitation from the network analyzer to FP2TEST (9.09 kOhm input impedance) where it is added to the PMC error signal before going to the loop filters.

I hook up the following

• Agilent 4395A output to SR560 (300 Hz HP, gain of 1)
• SR560 to FP2TEST and to Agilent's channel R
• PMC error signal IF (mixer box mounted to rack, I noticed the IF BNC->SMA were a bit loose/stressed by a hanging LP RF filter) to SR560 (also 300 Hz HP, gain of 2)
• SR560 to Agilent channel A

I 'Enable' Test 2 on the PSL screen, so FP2TEST gets added to the error signal.

PDH signal

• TDS 3034B with four channels
  • 1. PMC servo box external drive (split off from the function generator)
  • 2. PMC servo box output monitor (mirrors the drive, shows when drive is saturating)
  • 3. IF signal (split off after the mixer)
  • 4. PMC Trans (long BNC from the PSL table)
• SRS DS345 function generator (into the PMC servo box' external drive)
  • 100 Hz signal (there's a 10 Hz pole on the PZT drive, so any faster than this and I can't see both sidebands without the HV output mon clipping)
  • 3.19 Vpp amplitude (smallest amplitude at 100 Hz such that both sidebands are well resolved)
  • 1.52 V offset (center the carrier's PDH error signal at pi/2 out of phase with the drive)

I was able to see the carrier and both sidebands.

I tried to grab this data from the scope via ethernet, but was unsuccessful (timeout errors, I'm using the scripts from scripts/tektronix/tek-dump, and the GPIB box that Kruthi had been using for the GigE cam; I also tried plugging in directly scope->ethernet. Never got anything but timeout errors, so maybe I'm not specifying the port correctly. Anyway the trace is frozen on the scope for later use, or I can easily repeat this now that I know how).

Spectrum

Next, I locked the PMC (Test1 is off, tune DC output adjust until I get some transmission, turn on the loop at Test1, increase the gain to before the loop goes unstable). I'm sending the following channels to SR560 (gain = 2, no filtering, high dynamic reserve, 50 Ohm outputs), and reading spectra from the Agilent 4395A:

• R-- PMC TRANS PD
• A-- PDH IF
• B-- PMC PZT HV MON

The HV mon was always saturating the preamp, so I disconnected it; I added a 50 Hz (6db) high pass to the Trans PD signal, since it has a DC component.

I got to take a look at the traces on the spectrum analyzer front panel, but too tired to do the GPIB for now. There are peaks, things look reasonable.

Grabbed the PMC data

I went to set up the spectrum analyzer measurements through GPIB, but inadvertently deleted the contents of ~/Agilent/netgpibdata/ (made a soft link in my folder, decided I wanted it gone but rm'ed instead of unlink). I copied what I think was in that folder back (from /opt/rtcds/caltech/c1/scripts/general/labutils/netgpibdata).

Again, the spectra are:

• R-- PMC TRANS PD into SR560 with G=2 DC coupled, no filtering
• A-- PDH IF into SR560 with G=2, DC coupled, no filtering
• B-- PMC PZT HV MON into SR560 with G=2, AC coupled, no filtering

I recorded the three spectra with the following parameters:

• Three separate spans:
  • 10 Hz to 150 kHz
  • 100 to 550 kHz
  • 500 kHz to 2.5 MHz
• bwSpanRatio = 0.1 %
• averages: 10
• number of points: 801
• spec type: noise (PSD units)

I then ran AGmeasure with the above parameters in the yaml, with the rest following the defaults in AgilentTemplate.yaml. I saved the data in /users/aaron/40m/data/PMC/190617/

Looks like the header contains all of the parameters, so I shouldn't have trouble distinguishing the spectra. I didn't get the instant plotting working, but the data seem to be there.

I'm still having trouble getting the data from the oscilloscope. I'm not sure why the tektronix scrips I've used before aren't working, I'm checking it now.

update: Grabbed the data, the issue was just using the wrong IP address. 

I made a script (/users/aaron/40m/GPIB/tds_dump.py) that grabs data from a Tektronix scope and packages into a pickled dict with the following structure:

1. ch1
   1. times ("ts")
   2. values ("vals")
   3. channel info ("info")
2. ch2
   1. ""
3. etc

I made a python notebook that does the following:

1. Grab the data from the pickle above
2. Fit a triangle wave to the drive signal
3. Determine the (change in Volts) / second from the triangle wave, as well as define the times of a single sweep of the PDH error signal
4. Trim the error signal data to contain the PDH signal from the carrier and two sidebands only (the original trace was for three periods).
5. Fit the functional form of the PDH signal to the trimmed error signal. 
   1. The sideband frequency is fixed at 35.5 MHz, and the scaling of Volts-to-Hz is left free, so this fit gives the calibration of IF volts to Hz.
6. Grab the spectra (already saved from the Agilent with the netgpib scripts) and apply this V-to-Hz scaling
7. Plot the spectra

The fit in step (5) is still looking quite bad, despite the fitted values being close to the expected. Since we really just want a calibrated spectrum, I'll instead fit a line to the linear portion of the PDH error signal for the carrier and both sidebands, then determine the scaling from that.

Here are the results from the fit. Data can be found on nodus in /users/aaron/40m/data/PMC/190617/. I've put a jupyter notebook with the analysis in /users/aaron/40m/analysis/PDH_calibrate.ipynb (might be some filename issues due to different directory structure on my laptop).

Here's a summary of the current measurement. I'll be referencing the diagram for the PMC servo card.

1. With the PMC servo loop open, sweep the PMC PZT by sending a triangle wave in to J5 (external drive on the servo card).
   1. I used a 100Hz drive, but should use something slower so my drive isn't filtered out by the 100Hz pole on the servo card and the 10Hz pole on the PZT.
2. Monitor the voltage at the HV drive, as well as at "mixer out" (J8 on the servo board)
   1. Note that I took this PDH error signal from FP2TEST rather than "mixer out", which means my error signal was not low pass filtered.
3. Calibrate the HV mon in units of Hz by fitting the PDH signal. The sidebands should be 35.5Mhz away from the carrier peak.
   1. This part needs to be done differently to account for thermal locking in the PMC.
4. You now have the PDH error signal as a function of PMC resonance in Hz, and can use that to calibrate the PDH error spectrum.
   1. The spectrum is taken when the PMC is locked, so the Hz/V scaling is the slope of the PDH error signal.

In the figures below, I obesrved that for fast (100Hz) drives, the PDH error signal had a pi/2 phase shift relative to the triangle wave, which means even though the resonance appears near the turnaround of the triangle, it is actually occuring near the center of the range.

There are several problems with this data:

• PMC error signal spectrum is not properly calibrated, even according to the process described above
• The drive was faster than the response of the PZT.
• I was driving with a ~1V excitation, so I've lost a factor of 10 somewhere on the way to the external drive curve. Probably just a problem with how I've read the data dump from the scope.

The IMC REFL error signal was measured to compare it with the other spectra (if we have).

The blue curve is the in-loop IMC error and the red is the dark noise. So they are not an apple-to-apple comparison. But the red noise is going to be suppressed by the loop, and still the red is below blue. This means that the blue curve is the measured noise rather than the readout noise.

We suspect that the current issue is the PC drive saturation (as usual). Does this indicate that the laser freq noise is actually increased?

----

Another suspect was that the degradation of the LO level. We used to have the issue of slowly dying ERA-5 (ERA-5SM indeed). The RF levels on the demod board were measured using an active probe.

The LO input: 0dBm, ERA-5 input: -2.7dBm and -2.1dBm for I and Q. I found that the outputs of the ERA-5SM were +10.5dBm and +10.6dBm.
This lead me to replace the chips but the situation was not changed. Then I realized that the LO levels should have been measured with the load replaced from the mixers to a 50Ohm load. Somehow these mixers lower the apparent LO levels. So I decided to say this is OK.

Summary:

Over the last few days, I've been doing some (complementary) measurements to what Aaron and Koji have been looking at. The motivation was to identify if the problems we are seeing are optical (i.e. imprinted on the PSL light) or electronic. My findings:

1. 60 Hz line noise in PMC REFL and PMC TRANS is heavily dependent on whether I connect cables between the measuring PDs and Acromag ADC or not - but even with the Acromag cable disconnected, the 60 Hz RIN is HUGE - 10 mVpp out of 670 mV DC, and lines are much dirtier if you have connections to the SLOW ADCs. Measurement was made by looking at the time-domain signals on a battery powered Tektronix oscilloscope. See Attachment #1. I believe this line noise is higher it was. Cause is unknown to me at this point.
2. The NPRO noise eater seems to function as advertised. The measured RIN with the noise eater enabled (our nominal operating condition) is in line with what the manual tells us it should be. See Attachment #2.
3. There isn't strong evidence of excess frequency noise (measured with PLL) out to 100 kHz. I didn't measure the high-frequency part yet, but maybe I'm doing something wrong with the PLL setup which should be first corrected. See Attachments #3, #4.
4. The beat note frequency between the free-running PSL and EX NPRO's is definitely slewing more than the quadrature sum of the advertised 1 MHz/min slewing per the manual.

Evidence:

Attachment #1: Time domain look at PMC Refl and Trans signals under various operating conditions. During this work, I took the chance to remove ~4 BNC T connectors that were connected on the PMC TRANS photodiode (Thorlabs). Now, there is one cable going to the Acromag ADC, and one going to the Oscilloscope used to monitor these signals. Any further T-ing can be done at the oscilloscope.

Attachment #2: RIN measurement of the NPRO light. I opted to place a Thorlabs PDA55 in the IR ALS pickoff light path. This is before the light sees the PMC. A DC block was inserted between the PDA55 and the AG4395 used to make the measurement. DC level of the PD output was 3.1 V into high-Z and I used half this value to normalize the measurement made by the 50-ohm input AG4395 into RIN units. The measurement was made with the PZT and slow temperature controls to the NPRO connected/disconnected, but I saw no significant difference. 

Attachment #3: Frequency noise measurement via PLL. This shows the loop transfer funtion for the PLL. Some details of the setup:

• The beat note for locking the PLL was made between the PSL NPRO and the EX NPRO (output of the IR ALS BeatMouth). ~4dBm beatnote.
• Local oscillator was sourced by a Marconi, f_carrier=33 MHz, RF level = +10dBm.
• Level 7 Mixer and LB1005 controller from the mode-spectroscopy PLL setup.
• PLL control signal routed to EX NPRO PZT via Heliax cable running along south arm. 
• Why EX and not PSL or Marconi FM? Latter has limited range, ~1/10th of that offered by NPRO PZT. PSL PZT has a 2.9 Hz corner freq Pomona box. I could disconnect this for the purpose of PLL locking, but I thought it may be interesting to see if there’s any hints of the problem being electrical, by looking at PLL spectra with / without Pomona box. The expected delay due to cabling is only 400 ns, so not really a limiting factor for the PLL bandwidth.
• LB 1005 settings:
  • PI corner = 3 kHz.
  • G = 2.30 (I could not increase this further - with the PSL+Lightwave NPRO PLL, we could achieve a UGF of ~60 kHz, but in this setup, I can't do much better than ~7kHz before the loop starts oscillating, not sure if the fact that the PZT actuation coefficient for the Innolight is ~5x lower than for the Lightwave is enough to explain this?).
  • LFGL = 90 dB.
• Mixer output had a maximum value of 800 mVpp => PLL discriminant is 400 mV/rad.
• The "eye fit" is just the transfer function of two poles at DC (one for frequency to phase conversion in the PLL and one for the LB1005 integrator), and a zero at 3kHz (PI corner). I scaled the gain till the "fit" and measurement lined up, and then used this model to undo the loop suppression of the error signal to extract the frequency noise without worrying about the frequency vector of the measurement being limited.
• Once again, slow temperature control and PZT controls to the PSL NPRO were disconnected so this measurement was made with two free-running NPROs.

Attachment #4: Frequency noise measurement via PLL. This shows the frequency noise. I've overlaid the expected frequency noise between 2 free-running NPROs, model used is in the text box in the plot. There isn't strong evidence of excess high frequency noise in this measurement. The fact that the "LB 1005 input terminated" trace is below all the others supports the hypothesis that I'm measuring real frequency noise. The bump around a few kHz could indicate some gain peaking?

However, I'm unable to find good agreement between the measured frequency noise using the error point and the control point. For the former, I used the PLL discriminant mentioned above of 400 mV/rad, and undid the loop suppression, and for the latter I used a PZT discriminant of 1.7 MHz/V. However, there is still a constant scale difference between these two traces. So I'm doing something wrong?

Next steps:

1. More interpretation of the PLL measurement results required.
2. Measure the PLL error signal spectrum to higher frequencies using the AG4395. 
3. ???

I've not disturbed the PLL setup in case anyone else wants to repeat these measurements, but I have restored the normal electrical connections to the PSL PZT and temperature control.

Some other activity:

1. Alignment into the PMC was tweaked.
2. NPRO laser pump current was increased from 1.9 A to 2.0 A.
3. PMC servo gain was changed from +18 to +17 to prevent the servo from oscillating.

After typing up the elog, I decided to try locking the IMC again - now it locks again with the "OLD" gain settings. I tested it ~5 times, the autolocker brings the lock back and the PC drive levels are normal. IMC transmission and MC REFL DC light levels in lock are normal. The PC Drive RMS voltage is <1V. What's more, there is no longer any evidence of 60 Hz line harmonics any more in the PMC diagnostics channels. Compare attachment #1 to this elog.

WTF.

I undid the changes Koji made to the autolocker gains, and am trying the old settings again. Let' see how stable or otherwise the config is. I must've jiggled some poor cable connection back into a good spot while working on the PSL table?

Anyway, this helps Kruthi and Milind.

Note that I have removed an SR785, an oscilloscope, some SRS instruments from the PSL and PMC last night.

But they (and RF Network Analyzer) were not there when the problem started.

We should record the IMC error (at test point monitor) too? If the IMC locks on Monday too, I'll do it.

Over the last 24 hours, the IMC autolocker was able to keep the MC locked ~60% of the time. This is not particularly good, but is an improvement on ~2 weeks ago when the IMC couldn't be locked.

There are two periods, which I've indicated by vertical cursors, between which the autolocker was doing something strange - usually this kind of trend is caused by one or more of the VME crates being unresponsive and the autolocker gets stuck, but I confirmed that both c1psl and c1iool0 are telnet-able. So I conclude that the stability and reliability of the IMC loop is still not as good as it used to be.

Note also that while the PC drive RMS level mostly hovers around 1 V, there are several excursions above that level. This in itself isn't a new phenomenon. I will do some more characterization by measuring the in-loop error signal spectrum and maybe the OLTF of the IMC locking loop.

Attachment #1 - In loop error spectra, measured as Koji posted end of last week.

• Main difference is that the line noise seems much lower.
• For the "dark" measurement, I set the IN1 gain of the servo board to the value of +4 dB, which is what it is in lock.
• As Koji mentioned, this isn't an apple-to-apple comparison as the IMC loop will squish the plotted orange trace.
• Nevertheless, the fact that the blue trace is above orange everywhere gives confidence that we are in fact measuring frequency noise.
• For the higher frequency measurement, I used the AG4395 analyzer, which has 50 ohm input impedance. So to get the measurements with the SR785 to line up, I multiplied these by x2.
• For the frequency axis calibration, I used the value of 13 kHz/V for the PDH discriminant, which was what I measured it to be last year (but I didn't check again today).
• Note that the IMC locking loop OLTF has not been undone, so this isn't the actual laser frequency noise on the transmitted beam. In order to measure the latter, we'd have to use (for example) an arm cavity as an analyzer.

Attachment #2 - OLTF of the IMC loop.

• Measurement was made using the IN1/IN2 method, injection was done at the "A EXC" front panel BNC input.
• For comparison, I've overlaid a measurement from the 2017 IMC loop investigations. Doesn't seem to be significantly different.
• UGF and phase margin are in the ballpark of what they were reported to be in the past.

Attachment #3 - Photo courtesy Koji showing the bank of BNC connectors used for these measurements.

Clearly, these measurements were taken in a time when the IMC was "well behaved". How to characterize what's happening when this isn't the case?

aI went to repeat these measurements using the mixer out channel from the servo box, and with a slower sweep for the PDH calibration.

I had trouble getting the PDH signal, here are some notes:

• I added a 50 Ohm terminator to BNC T on the mixer box. This had been terminated before I started, but I noticed no terminator today.
• Noticed some distortion of my driving triangle wave if I measured it on ch3 and 4 of the tektronix scope, not present on ch 1/2
• Initially wasn't finding a signal because I was opening the loop by turning off the Test 1 switch, but this meant the mixer mon on the servo box also did not receive the PDH signal. Instead, I cut the loop with the "BLANK" switch on the PMC screen, which instead blanks out the op amp between the mixer mon and the PMC drive conditioning (so the external drive still reaches the PZT).

attachment 1 is the configuration of the PMC screen when I was trying to get some PDH signal; I did move the DC output adjust to 0V, but found that this led to the output being railed; this makes sense, the op amp at U9 has a negative bias at GND.

Rana came by and gave me some tips.

• I'd been using the wrong servo board diagram, it should be in D1400221
• We removed the LP filter from the mixer output (before going to FP1TEST on the servo board), since the board itself already is filtering the IF.
• We might have observed the thermal locking? See for yourself, the trans and refl signals while sweeping the PZT drive at 5 Hz and 30 Hz respectively are in attachments 2 and 3.
• Rather than using an SR560, I should use an RF coupler between the mixer and FP1TEST to measure the error signal spectrum. I found a ZFDC-20-5-S+ (0.1-2000 MHz) and sent an SMA cable from the coupled port to channel R of the Agilent 4395.

We finally got the PDH signal again, and I recorded the PDH signal while driving with the following settings on the Siglent function generator.

• 1.1 Hz triangle wave, 6Vpp, -7Vdc offset, high impedance mode

I tried getting a spectrum using the coupler, the mixer mon is seeing a DC offset though and causing the PZT to rail. Will try to understand why, but in the meantime removing the coupler (still no LP filter) lets us lock the PMC again.

RXA: Kruthi thinks all of our subsequent IMC locking problems are Aaron's fault (she was quick to give him up as soon as the thumb screws were tightened...)

Aaron complained to me earlier that the PMC could not be locked. Turned out to be a classic sticky slider problem, I keyed the c1psl VME crate, and did the usual burtrestore trick. After that, I could immediately lock the PMC and IMC with the nominal gain settings.

I also looked at the wiring at the rack. An SLP250 was installed at the mixer IF output, in parallel with a 50 ohm terminator to ground. I removed this, because as Aaron pointed out, the PMC servo card "FP1 TEST" input is already 50 ohm, and has two cascaded LC filter stages immediately after to filter out the 2f component, so the extra low-pass filtering is superfluous (in any case, 250 MHz is much too high a cutoff to be using for cutting out the 2f component which will be at ~70 MHz).

Finally, in the last ~2 weeks, we have been running with the PMC servo gain of +17 (as opposed to +18 from before). The old gain is too high, as noted by Milind. But the MEDM field for this gain goes RED unless the gain is +18. I adjusted the value of the  C1:PSL-STAT_PMC_NOM_GAIN channel to +17, so that this is no longer the case. I also edited the PMC MEDM screen to get rid of my comment that the "SLOW ADC IS DEAD" for the PMC TRANS field, since I have now hooked up the PMC trans photodiode to our temporary Acromag box.

The PMC was locking again after Gautam's steps above. However, after I added the directional coupler between the mixer I and the servo card (coupled to the Agilent analyzer), the PMC was again not locking, except occasionally with gain of -10 dB.

I removed the coupler (so the mixer I goes directly to the PMC servo card, as Gautam had it), and the PMC was still not locking. While checking connections, I noticed that one of the SMA cables between the LO and the mixer was not even finger tight, so I tightened them to approximately the right torque with a non-torque wrench.

This did not lead to the PMC locking, so Millind helped me key the c1psl VME crate. I burt restored the latest snapshot. Now, the PMC locks up until gain of -5. I try burt restoring the previous snapshot, which was from when the PMC was locking, and now it locks. Adding in the directional coupler again leads to the PMC not locking, though this time removing the coupler restores the normal behavior. I also tried using the coupler with the coupling port connected to a 50 Ohm terminator, and this configuration also did not lock.

I had been using a ZFDC-20-5-S+ (0.1-2000 MHz) with SMA ports and SMA-to-BNC on the input and output ports (since the mixer has BNC connectors). To reduce the number of potentially flaky connections, I am trying the ZFDC-20-4 (1-1000 MHz) that I found with BNC ports. The PMC still doesn't lock.

To get some spectrum, I've connected the PMC servo card's 'mixer out' to the Agilent's A channel, and collected a spectra from [10 Hz, 75 kHz], [75 kHz, 750 kHz], and [750 kHz, 2 MHz].

Wed Jun 26 15:23:37 2019

After the lab cleaning, I added a BNC T on the mixer I port, so now the configuration is:

Mixer I -> BNC T

-> PMC Servo card FP1TEST

-> directional coupler -> coupled to the spectrum analyzer, out port is terminated with 50 Ohms.

I thought maybe the issue was that the TF from in->out on the directional coupler is not what I expect (and Gautam suggested the in-out port might block DC), but the PMC still does not lock in the above configuration, in which the coupler is not between the mixer and the servo board--so only reflections from the coupler should matter, I think.

However, even when I plug the mixer directly into the servo board, the PMC is not locking (again) with gain above -8 dB or so. I did a burt restore again, and this fixed the problem. I wasn't sure why this burt restore is working, because all I am changing is the DC output adjust voltage and the gain, and switching on/off FP1TEST. However, I observed that after running the PMC autolocking script, observing that the autolocker did not achieve lock as it swept through resonance, and cancelling the autolocker, the PMC again cannot be locked for high gains. When I let the autolocker complete, this doesn't happen, so probably I'm just not letting some channel return to its nominal value after being changed by the autolocker.

Now after another burt restore, I'm avoiding using the autolocker and am still having trouble locking with the BNC T + directional coupler configuration above. However, now I'm noticing that the PZT control mon is always railed, as long as FP1TEST is in the loop (and independent of the output adjust voltage). I try returning to the 'baseline' configuration (mixer -> PMC servo card directly), and the PMC locks but with only 0.68 V transmission (was >0.7 V before).

Per Gautam's earlier suggestion, I switched to using the Agilent 41800A probe instead of the directional coupler. I was able to lock the OMC with this probe on a BNC T coming out of the mixer (transmission is 0.71 V). I recorded the spectra of the PMC servo board's "Mixer Out" channel, and the mixer's I as seen by the probe. I recorded spectra from 10 Hz to 100 MHz. The soft linked netgpibdata folder I had in my users directory is no longer soft linked--presumably intentional so I don't tamper with it?

I'm a bit skeptical that I've used the probe correctly, so I'm checking out the manual.

Indeed, I needed to pull back the sheath; I also noticed that the GPIB script I've been using doesn't save the data from both channels when I take a spectrum in dual mode, so I'm taking the spectra again one at a time (lights are on, IMC is locked).

After helping Aaron key the crate and do a burt restore, I realized that it would probably be best to record the steps that Koji showed me to do a burt restore as a reference for (anyone) the future

Commands (in terminal):

1. burttoday: changes to the directory with snapshots for the day (/opt/rtcds/caltech/c1/burt/autoburt/today)
2. burtgooey: opens a new window with several buttons of which "Restore" needs to be selected. This opens up a second window as shown in Attachment #1. Click on Snapshot files and navigate to the snapshot you wish to restore (these are present at /opt/rtcds/caltech/c1/burt/autoburt/snapshots) and select that. A green "OK" button indicates if the Restore can be performed without a hitch. Hit "Restore" to perform the burtrestore.

Also Gautam explained today that the sticky slider problem is a hardware issue. That it basically means that the signal (voltage output for instance) that you request from the medm screen is not what the hardware delivers. Twice now, we have got around that with a burtrestore. My understanding of a burt restore is that it is a restoration of values from a certain time to the EPICS channels. Therefore, I don't understand why a restoration at the software level should fix how the hardware responds? Why does this happen?

a useful piece of code that we should ask one of this summer's SURFs to write:

1. read in a BURT .req file which is usually used to make the autosnap / restore.
2. change ALL of the values to some value (slightly different from its current value)
3. restore it to its current value

this will solve the sticky slider problem and do it in a systematic way. We can run it from the command line: e.g. 'unsticky.py c1psl c1ioo c1lsc'

we are thinking of doing a sprucing up of the input mode cleaner WFS (sensors + electronics + feedback loops)

1. WFS Heads
   1. it has been known since ~2002 that the RF circuits in the heads oscillate. 
   2. in the attached PDF you can see that 2 opamps (U3 & U4; MAX4106) are used to amplify the tank circuit made up of the photodiode capacitance and L6.
   3. due to poor PCB layout (the output of U4 runs close to the input of U3) the opamps oscillate if the if the Reed relay (RY2) is left open (not attenuating)
   4. we need to remove/disable the relay
   5. also remove U3 for each quadrant so that it has a fixed gain of (TBD) and a 50 Ohm output
   6. also check that all the resonances are tuned to 1f, 2f, & 3f respectively
2. Demod boards
3. DC quadrant readouts
4. Whitening
5. Noise budget of sensors, including electronics chain
6. diagonalization of sensors / actuators
7. Requirements -
8. Optical Layout
9. What does the future hold ?

1. what is our preferred pin-for-pin replacement for the MAX4106/MAX4107? internet suggests AD9632. Anyone have any experience with it? The Rabbott uses LMH6642 in the aLIGO WFSs. It has a lower slew rate than 9632, but they both have the same distortion of ~ -60 dB for 29.5 MHz.
2. the whole DC current readout is weird. Should have a load resistor and go into the + input of the opamp, so as to decouple it from the RF stuff. Also why such a fast part? Should have used a OP27 equivalent or LT1124.
3. LEMO connectors for RF are bad. Wonder if we could remove them and put SMA panel mount on there.
4. as usual, makes me feel like replacing with better heads...and downstream electronics...

Wrote the script. It currently lives at /users/milind/NonlinearControl/milind/unstick/unstick.py. Also pushed it to the repo here. It does the following:

1. When run as python unstick.py c1aux (for instance) from the terminal, it parses the autoBurt.req file at /cvs/cds/caltech/target/c1aux/autoBurt.req and obtains the channels.
2. Iterates through the channels and changes it to "some value"
   1. For channels corresponding to buttons on MEDM screen (Enable/Disable etc.) toggles between 0 and 1
   2. For channels corresponding to continuous values (such as say exposure time or the like) changes to abs(1+current_value)
3. Resets to original value and then moves to the next channel

I tried print statements instead of actually writing to the channels as Gautam asked me to do that with supervision. Is this good enough?

> For channels corresponding to continuous values (such as say exposure time or the like) changes to abs(1+current_value)

Why abs? Is the current_value is like -5.4321 (for example for the alignment slider), this returns +4.4321 and the suspension will suffer from huge motion (well it will be returned to the original value soon though). 

Made changes as discussed in this issue. Further, I need to add signal handling capabilities to the code. I belive Jon has pointed me to some code. I will take a look at that ASAP.

The latest in my fling with the PMC. Though PMC trans is back to nominal levels (~0.713 V), we'd still like to understand the PMC noise.

Last time, I took some spectra with the RF probe (Agilent 41800A). I had already measured the PDH error signal by sweeping the PZT at ~1 Hz. The notebook I used for analysis has been updated in /users/aaron/analysis/PDH_calibrate.ipynb. The analysis was the following:

• fit the PDH error signal, assuming a 35.5MHz modulation frequency. Here are the (approximate) fit parameters:
  • Mapping of PZT mon voltage to Hz: 5.92 Hz/V_{PZT_mon}
  • P_carrier*P_signal: 0.193 W^2
  • HV mon voltage on resonance: 0.910 V
  • Error signal far off resonance: 0.249 V
  • Transmission: 0.00238
    • ​yikes. The nominal transmission is T=0.003. I let this parameter be free as a check, and to avoid overconstraining the data; is this consistent with measurements of the PMC optics' transmission?
  • Length: 0.0210 m
    • This is consistent with the nominal PMC length
• Using the fit of the full PDH error signal, I am able to plot error signal vs frequency, and fit the linear portion of the carrier PDH signal. The results of this fit are:
  • -9.75e-7 V_PDH per Hz
  • 0.105 V error signal at DC
• I then divide the power spectra by the squared slope of the linear fit above (V_PDH^2/Hz^2) to get the spectra in Hz^2/rtHz
  • I've plotted both the spectrum I took directly at the mixer I using the agilent probe, as well as the spectrum taken by sending the PMC servo card's mixer mon to an SR560 (G=2) then to the spectrum analyzer

There are a few problems remaining:

• There should be a gain of 100 between the mixer I and the servo board's mixer out. It's not clear to me that this is reflected in the spectra. Moreover, the header files on the spectra I grabbed from the Agilent say that the R (mixer I) channel has 20dB of input attenuation, which is also not reflected. If I have swapped the two spectra and not accounted for either the gain of the servo card or the attenuation of the spectrum analyzer, these two gains would cancel, but I'm not confident that's what's going on.

Today, Gautam keyed the C1PSL crate and we got to test my unstick.py code. It seems to be working fine. Remarks:

1. Gautam moved the unstick.py code to /opt/rtcds/caltech/c1/scripts/cds. Therefore, the steps to run this code are now:
   1. cd /opt/rtcds/caltech/c1/scripts/cds
   2. python unstick.py c1psl (for the c1psl machine)
2. There is now a sleepTime global variable in the code which defines the amount of delay between successive channel toggles. We set this to 1ms and it took the code around 3s to run.
3. Gautam was curious to see if this would work even if we set the sleepTime parameter to 0 but decided that that could be tested the next time something was keyed.
4. I still need to add the signal handling thing to this code.

Following this, we tested my PMC autolocker code. The code ran for about a minute before achieveing lock. Remarks:

1. Gautam moved my code (pmc_autolocker.py and autolocker_config.yaml) to /cvs/cds/rtcds/caltech/c1/scripts/PSL/PMC/ . Therefore, the steps to run this code are now:
   1. cd /cvs/cds/rtcds/caltech/c1/scripts/PSL/PMC/
   2. python pmc_autolocker.py (check code or use --help to see what the command line arguments do which is only for when you wanna override the details in the .yaml file)
2. Gautam suggested that I add some delay between succesive steps of DC output adjust so that it locks quickly. I'll do that ASAP. For now, it works.

Mode cleaner was not locked today. Koji came in and concluded that PSL had died. So we keyed it. Then we ran my unstick.py code. Mode cleaner is locked now.

[koji, gautam]

In addition to c1psl needing a reboot, megatron was un-ssh-able (although it was responding to ping). Clue was that the NPRO PZT control voltage was drifting a lot on the StripTool trace. Koji hard-rebooted the machine. Now IMC is locked, and FSS slow servo is also running.

I found the MC2 face camera disabled(?) and the MC servo board input turned off. I turned the MC locking back on but I don't see any camera image yet.