Preparations

- According to Diego's report, the MC WFS gains were too high. We'll fix this later by tweaking the servo shapes.
But for now, all of the WFS gains were reduced by 40%.
i.e. WFS(1|2)(PIT|YAW) gains from 5 to 3, MC2TRANS(PIT|YAW) gains from 50 to 30.

- Aligned IMC carefully and ran the offset nulling script. MC REFL became 0.435~0.445 and MC TRANS was ~16600.

- Locked the arms and ran ASS.

PRMI

- Started locking PRMI. I just used REFL33I&Q as suggested by the configure script. The PRMI locking was not so robust.
Particularly, the third violin mode of PRM and BS seemed to get excited and dominated the signals.
I modified Vio3 filter in the violin filter for BS and PRM to include zero at 1921Hz where the growing peak was seen.

- We probably want to start from the 1f signals for DRMI lock acquisition. So I wanted to check how REFL11s are.
Measured the demod phase and relative gain between 33I and 11I. (By the way, REFL11I whitening gain was lowered to 0dB).
REFL11I had about x10 gain and the same phase compared to REFL33I. The demod phase for REFL11 was +21deg.
Also checked REFL55 phase and gain. 55Q has almost the same gain as 33Q. And the adjusted phase was 25deg.
These were just rough adjustment of the demod phases.

- Then the servo configuration was transtioned to Configuration 1 (below), and then Configuration 2.

- This configuration was very stable and the PRMI stayed locked about ~1 hour. During this long lock, I could measure 
PSDs, sensing matrix, and etc. Also I could play with the PRM ASC. I wasn't sure if the POP is actually stabilized or not.
(I have no data)

- I noticed that something was ringinging up at 1883Hz. Another 3rd order viloin mode???

- The lock was lost due to too strong injection. But also it reacquired without touching.

- Precise demod phase adjustment has been done by elliminating PRCL from the Q signals.

REFL11 16.75
REFL33 133.0
REFL55 31.0
REFL165 -142 
AS55 -53

- Configiration1 (REFL11I&REFL55Q)

REFL11: WTN 0dB PHASE 21deg, REFL11I x0.1 -> PRCL
REFL33: WTN 30dB PHASE 145deg
REFL55: WTN 21dB PHASE 25deg, REFL55Q x1 -> MICH

PRCL: GAIN -0.04 FM4/5 ON, Triggered FM 2/3/6/9, Servo trigger: POP22I 50up 10down, No Normaization.
MICH: GAIN 10 FM4/5 ON, Triggered FM 2/3/6/9, Servo trigger: POP22I 50up 10down, No Normaization.

PRCL -> PRM +1
MICH -> PRM -0.2625, BS +0.50 BS

- Configuration 2 (REFL11I&Q)

Same as above except:
REFL11Q x-0.1 -> MICH

Calibration

Let's use these entries 

PRM: http://nodus.ligo.caltech.edu:8080/40m/8255
PRM:  (19.6 +/- 0.3) x 10^{-9} (Hz/f)^2 m/counts

BS/ITMs http://nodus.ligo.caltech.edu:8080/40m/8242
BS     = (20.7 +/- 0.1)    x 10 ^-9 / f²
ITMX = (4.70 +/- 0.02)  x 10 ^-9/ f²
ITMY = (4.66 +/- 0.02) x 10 ^-9/ f²

- PRCL Calibration

Lockin oscillator module 675.13Hz 100 -> +1 PRM

Measurement bandwidth 0.1Hz -> Signal power BW 0.471232 (FLATTOP window)

C1:SUS-PRM_LSC_IN1: 118.99 cnt/rtHz => 5.12pm/rtHz
REFL11I: 17.84  cnt/rtHz => 3.49e12 cnt/m
REFL33I:  2.28  cnt/rtHz => 4.46e11 cnt/m
REFL55I:  0.158 cnt/rtHz => 3.09e10 cnt/m
REFL165I: 1.63  cnt/rtHz => 3.19e11 cnt/m

- MICH Calibration

Lockin oscillator module 675.13Hz 100 -> -1 ITMX +1 ITMY

Measurement bandwidth 0.1Hz -> Signal power BW 0.471232 (FLATTOP window)

C1:SUS-ITMX_LSC_IN1: 121.79 cnt/rtHz => 1.26pm/rtHz
C1:SUS-ITMY_LSC_IN1: 121.79 cnt/rtHz => 1.25pm/rtHz
REFL11Q:  0.0329   cnt/rtHz => 1.32e10 cnt/m (PRCL/MICH ratio 265)
REFL33Q:  0.00773  cnt/rtHz => 3.09e9  cnt/m (144)
REFL55Q:  0.001645 cnt/rtHz => 6.58e8  cnt/m (47)
REFL165Q: 0.00374  cnt/rtHz => 1.50e9  cnt/m (213) !?
AS55Q:    0.0696   cnt/rtHz => 2.78e10 cnt/m

Openloop TF measurements
Servo filter TF measuremnts

The UGFs were ~250Hz for PRCL and ~120Hz for MICH, respectively.
The OLTF was modelled by the servo and violin filters TF from foton, estimated TF of the AA/AI filters, and the constant time delay.

Displacement spectra measurement

SELF NOTE: DON'T FORGET TO TURN ON the whitening of the unused signals! (USE MC DOF or manual switch)

- PRCL

The PRCL displacement was measured with REFL I signals. In the attachment 3, the in-loop and free-run equivalent displacements are shown (red and blue).
Other out-of-loop sensors (33/55/165) were also plotted together.

FIrst of all, the uncompensated displacement noise level of PRCL is around 1e-7 m/rtHz. This is a good indication that the calibration was not crazy.

The sensing noise of REFL11 seems to be 1e-15~1e-16 m/rtHz at high frequency which is enough for now.
As expected, REFL11I has the best noise level among the REFLs. At low frequency, it seemed that the noise level is limited by something at 1e-12 m/rtHz.
Of course, we can't say this is just the sensing noise of the other REFLs or the noise of the REFL11I. But this noise level is enough small for the locking of
the low finesse (F<100) PRCL cavity.

Remembering we had no trouble locking PRCL with REFL33/55/165, this plot indicates that the PRCL was suppressed too much below 2Hz.
And we want more supression between 5Hz to 30Hz. We have resonant gains in ther PRCL servo but not sure how effective they were.
If we consider the contamination of PRCL in MICH, we should try to optimize the PRCL servo.

- MICH

The MICH displacement was similary calibrated to PRCL. The signal sources were the REFL Qs and AS55Q.
In the attachment 4, the in-loop and free-run equivalent displacements are shown (red and blue).
Other out-of-loop sensors were also plotted together.

The problem here is that the out-of-loop levels (REFL33/55/165 and AS55) show almost the same levels
and thus it is likely that the actual (out-of-loop) stability of MICH is this kind of level. If we believe it, we only have
~1/100 supression between 1-10Hz and ~1/10Hz below 0.5Hz. The strong servo control does nothing to stablize
MICH. From the out-of-loop noise level of MICH, this comes for the contamination from leakage PRCL.
We really need to improve the signal quality of MICH.

The MICH servo filter has quite complicated shape, but is not necessary according to the estimated free-runing MICH.

The MICH free-running motion is quieter than the PRCL one between 1Hz to 30Hz. The reasonable explanation is
that it comes from poor vibration isolation of the tip-tilts. It means that SRCL also has the similar noise level to PRCL.

I have been playing with the IFO tonight.  Mostly, I wanted to make sure that all of the scripts for the carm_cm_up sequence were working, and they seem to all be fine. 

I also turned on all 4 UGF servos.  My big ah-ha moment for the night is that the excitation is multiplied by the gain multiplier.  This means that if the UGF servo is multiplying by a small number (less than 1), the excitation will get smaller, and could get small enough that it is lost in the noise.  Now the error signal for the UGF servo is very noisy, and can dip to zero.  Since we can't take the log of zero, there are limiters in the model, but they end up giving -80dB to the error point of the UGF servo.  This makes it all freak out, and often lose lock, although sometimes you just get a weird step in the UGF servo output. 

Anyhow, we need to be mindful of this, and offload the UGF servos regularly.  I think the better thing to do though will be to divide the excitation amplitude by the gain multiplier.  This will undo the fact that it is multiplied by that number, so that the number of counts that we put into the excitation amplitude box is what we expect. 

After some brainstorming with Jenne and Q, both the model and the medm screen have been modified: the entire block "Test1 - injection of the excitation - Test2" has been moved after the servo output. In this way we avoid completely the multiplication problem without having to perform divisions that could lead to division-by-zero problems. Because of how the logic is done now, one UnitDelay block had to be inserted before each one of Test1 and Test2.

Since the UGF Servo has been heavily modified lately, I'll post the current status of the model (as an attachment, as inpage images lose too much quality).

Elog from ~5am last night:

Tonight was just several trials of PRFPMI locking, while trying to pay more attention to the lockloss plots each time.

General notes: 

I tried once to acquire DRMI on 1f while the arms were held off resonance.  I wasn't catching lock, so I went back to PRMI+arms.  I aligned the PMC, which I noted in a separate elog.  

I was able to hold the PRMI on REFL33I&Q, and have ALS CARM and DARM at zero CARM offset.  The arm would "buzz" through the resonance regularly.  I use the word buzz because that's kind of what it sounded like.  This is the noise of the ALS system.

I think we want to add the transmission QPD angular signals to the frames.  Right now, we just keep the sums.  It would have been handy to glance at them, and see if they were wiggling in the same way that some other signal was waggling. 

All the data files are in /opt/rtcds/caltech/c1/scripts/LSC/LocklossData.  Each folder is one lockloss.  It includes text files for each trace, as well as any plots that I've made, and any notes taken.  The text files are several MB each, so I'm not going to bog the elog down with them.  There are a few folders that end in "_notInteresting".  These ones are, as one might guess, not interesting.  2 were MC locklosses (I'm not actuating on MC2, so I declared these independent from my work) and one was when I knew that my ALS was bad - the beatnotes weren't in good places, and so the ALS noise was high.

 Folder:  1100342268_POP22goesLow

Working notes:  Lost lock because POP22 went too low.  PRCL and MICH triggered off.  After this, changed PRCL and MICH "down" thresholds to 0.5, from 10.
 

Plots:

Conclusion:  Easy fix.  Changed the down thresholds for MICH and PRCL to be lower, although still low enough that they will trigger off for a true lockloss.  Why though do we lose so much sideband power when the arm transmission goes high?  POP22 dipped below 10 when TRX went above 29.  Does this happen on both sides of the CARM offset?  Quick simulation needed.

------------------------------------------------------------------------

Folder:  1100330534_maybePRCLangular

Working notes:  PRFPMI, reducing CARM offset to arm powers of 7.  CARM on sqrtInv, DARM on DCtrans. PRMI on REFL33 I&Q. Don't know why I lost lock.  Maybe angular stuff in PRC? I think POP spot was moving in yaw as it started to go bad.
Note, later:  regathered data to also get POP angular stuff. Don't think it's POP angular.  Not sure what it is.

Plots:

Conclusion:  I'm not sure what this lockloss was caused by, although it is not something that I can see in the POP QPD (which was my initial suspicion).  It is, like many of the rest of the cases, one where I see significant bounce and roll mode oscillations (error and control signals oscillating at 16 and 24 Hz).  I don't think those are causing the locklosses though.

--------------------------------------------------------------------

Folder:  1100334680_unknown_highArmPowers

Working notes:  PRFPMI, carm_up script finished, sitting at arm powers of 8.  CARM, DARM on DC trans.  PRMI on REFL33.   Don't know why lost lock.

Plots:

[Don't have any? - I'll make some]

Conclusion:  Again, I see 16 and 24 Hz oscillations, but I don't think those are causing the lockloss.

---------------------------------------------------------------------

Folder: 1100331950_unknown

Working notes: PRFPMI, arms about 8.  CARM, DARM on DC trans.  PRMI on REFL33.  Don't know why I lost lock.

Plots:

Conclusion: Don't have an answer.

--------------------------------------------------------

Folder: 1100345981_unknown

Working notes: Lockloss while going to arm powers of 7ish from 6ish.  Not POP angular, POP22 didn't go low.

Plots:

Conclusions:  This one wasn't from POP22 going too low, but again, I don't see anything other than 16 and 24Hz stuff.

I am still staring at / trying to figure out the latter 4 locklosses posted earlier.  But, I have just included the transmission QPD angular output signals to the frames, so we should be able to look at that with locklosses tonight. 

To get the lockloss plots:  in ..../scripts/LSC/LocklossData/ , first run ./FindLockloss.sh <gps time> .  This just pulls the TRX and TRY data, and doesn't save it, so it is pretty quick.  Adjust the gps time until you capture the lockloss in your plot window.  Then run ./LockLossAutoPlot.sh <gps time> to download and save the data.  Since it has become so many channels, it first makes a plot with all of the error and control signals, and then it makes a plot with the power levels and angular signals.  The data folder is just called <gps time>.  I have started also including a text file called notes inside of the folder, with things that I notice in the moment, when I lose lock.  Don't use .txt for the suffix of the notes file, since the ./PlotLockloss.py <folder name> script that will plot data after the fact tries to plot all .txt files.  I have also been appending the folder name with keywords, particularly _notInteresting or _unknown for either obvious lockloss causes or mysterious lockloss cases.

I had a handful of ~10 minute locks tonight. I intended to work on the 1f PRMI transition, but ended just familiarizing myself with the current scheme. 

Before touching anything, I committed the locking scripts to the svn. Unfortunately, the up script as I found it never worked for me tonight. I had to reintroduce the digitial crossover helper in CM_SLOW to get past the ramping up of the overall REFL11 gain. (With this is in place, there is some bad ringing around 200Hz for a time, but it goes away... or unlocks)

I did phase the PD formally known as REFL55 with an 800Hz PRM excitation while in full lock.42 to 102 degrees, ~30dB ratio between the I and Q peaks. However, come to think of it, how much does the CARM loop interfere with this?

The locklosses I had seemed to be due to a large fluctuation in all cavities' power. Maybe this will be helped by better PRC angular control, but we could maybe be helped by normalizing the digital part of the CARM loop by the arm transmissions once lock is acquired. 

Assuming the carrier mode in PRC is stable and the SB is the one moving, can we just use the POP DC QPD to control PRM?

Can we plot the arm power trend for multiple locks to see if it is associated with any thermal phenomenan in the IFO?
They should be able to fit with an exp + DC.

I'm currently more inclined to believe that the arm power trends have more to do with the arm alignments. Here's a 10 minute lock from last night, where the QPD servos were switched on about halfway through. I couldn't get Den's new servos to turn on without blowing the lock, so I reverted to my previous design, but still only actuated on the ETMs, with their oplevs still on. 

The most obvious feature is the reduction in power that seems to correspond to a ~10urad pitch deflection of ITMX when the lock begins. Is this optical spring action?

Also, it looks like the Y arm Yaw loop was badly tuned, and injecting noise. Ooops.

As of Den's QPD tuning, the QPD servos just actuate on the ETM. This next lock effectively had the QPD servos on the entire time, and we can see a similar drift in ITMX, and how ETMX then follows it to keep the QPD spot stationary. (Here, I'm plotting the QPD servo control signals, unlike above, so we can see X pitch servo output drift with the ITMX deflection)

Again, ITMX is moving in pitch by ~10urad when the interferometer starts resonating. If this is an optical spring, why does this just happen to ITMX? If it is digital shenanigans, how does it correlate with the lock, since there is nothing actuating on ITMX but oplevs and OSEM damping? Is light scattering into the ITMX OSEMs?

[Jenne, Megan, Frank]

We rebooted c1iovme, c1susvme1, and c1susvme2 during lunch.  Frank is going to write a thrilling elog about why c1iovme needed some attention.

C1susvme 1&2 have had their overflow numbers on the DAQ_RFMnetwork screen red at 16384 for the past few days.  While we were booting computers anyway, we booted the suses.  Unfortunately, they're still red.  I'm too hungry right now to deal with it....more to follow.

- I found that the cable for the AS55 LO signal had the shielding 90% broken. It was fixed.

- The Mon5 monitor in the control room was not functional for months. I found a small CRT down the east arm.
It is now set as MON5 showing the picture from cameras. Steve, do we need any safety measure for this CRT?

* Relocked IMC. I guess it was stuck somewhere in the autlocker loop. I disabled autolocker and locked it manually. Autolocker has been reenabled and seems to be running just fine.

* The X arm has been having trouble staying locked. There seemed to be some amount of gain peaking. I reduced the gain from 0.007 to 0.006.

*  I disabled the triggered BounceRG filter : FM8 in the Xarm filter module.  We already have a triggered Bounce filter: FM6 that takes care of the noise at bounce/roll frequencies. FM8 was just adding too much gain at 16.5Hz. Once this filter was disabled the X arm lock has been much more stable. 
Also, the Y arm doesn't use FM8 for locking either.

I changed the suspension library block to acquire the SUS_[optic]_LSC_OUT channels at 16k for sensing matrix investigations. We could save the FB some load by disabling these and oplev channels in the mode cleaner optic suspensions. 

I removed nonexistant PDs from c1cal, to try and speed it up from its constantly overflowing state. It's still pretty bad, but under 60us most of the time. 

I also cleaned out the unused IPCs for simulated plant stuff from c1scx and c1sus, to get rid of red blinkeys. 

 Since DRMI didn't get fully commissioned, I tried my hand at PRFPMI locking with the newly improved ALS performance. 

ALS seemed reliable, I think my main limiting factor was the PRMI locking. We should set up a restore script for PRFPMI that is a superset of the ALS CARM DARM, because the current restore script doesn't put all the vertex settings back, so I was trying to lock for a while without the FM boosts on PRCL and MICH, which really hurt my stability. 

Transitioning to SqrtInv works fine; a couple of times I've gotten to arm power of ~10, and have been able to sit there for a while as I set up excitation line comparisons with the CM board's REFLDC, but the PRC would always lose it before I did anything interesting. 

The PRMI locks with a reasonable MICH offset, I found that adding a offset of 20 to 40 makes the AS spot visibly dimmer, and ASDC falls to ~0.05 from .1-.2. 

I looked into adding a boost to the CARM loop after transitioning to sqrtInv, but we only have 30 degrees of margin, and the error signal is already fairly white, so there isn't much to do, really. 

The ALS locking script is sporadically hanging a fair while, as well, which is strange. Otherwise, not much to report...

Changed the BHD BS transmissivity to 0.56.

Demodulation Phases

As was noted before. The LO phase sensitivity plot vs LO phase from the previous elog shows the optimal sensitivity at each LO phase. That means that the optimal demodulation phase might change as a function of LO phase. Attachment 1 shows the previous plot and a plot showing the optimal modulation phase for some of the methods. When double demodulation is involved I optimize one modulation and show the optimal demodulation angle of the second. As can be seen, optimal audio demodulation angles don't change as a function of LO phase.

Additionally, as expected maybe, for the single RF sideband methods that nominally should not have worked at nominal LO phase (angle in which BHD Diff is most sensitive to MICH), the optimal demodulation angle changes quite a bit around the nominal LO phase.

Fixed demodulation angle

Attachment 2 shows the LO phase sensitivity in the single 55MHZ sideband method when we fix the demodulation angle. -23.88 is the demod angle optimal for nominal LO phase. 66.12 is 90 degrees away from that. -75.21 is the is the demod angle optimal for LO phase at the amplitude quadrature and 14.78 is 90 degrees away from that. It can be seen that fixing the demod angle can be mostly harmless.

Effect of MICH offset

The simulations were run with 0 MICH offset. Attachment 3 shows the LO phase sensitivity of the different methods when MICH offset is introduced together with the optimal demod angle. As expected the single RF SB methods are sensitive to this offset while the double demod methods are not since they are not relying on DC fields.

Fields at the BHD BS. More on this later.

Just a quick set of notes detailing changes so that there are no surprises, more details to follow.

1. Trek driver has been temporarily placed on top of the KEPCO supply east of the OMC electronics rack. Cabling to it has been laid out as well. I turned both off so neither should be energized now.
2. A new AI chassis (and associated cabling including the DAC SCSI cable and +/-24 V DC cable) has been installed in 1X2.
3. To map the DAC range to what the Trek driver wants, I've configured the inverting summing amplifier with gain of 1/8. The offset voltage is set to 5V DC instead of 10V as intended, because the DAC can only drive +/-5 V when connected to a single ended receiving/sending unit.
4. The LO delivery fiber was re-laid, and the interference between the IFO AS beam and LO beams were restored.

I briefly tried some LO PZT mirror dithering tonight, but didn't see the signal. Needs more troubleshooting.

Chris pointed out some information displaying scripts, that show if the DAQ network is working or not. I thought it would be nice to log this information here as well.

controls@fb1:/opt/mx/bin 0$ ./mx_info
MX Version: 1.2.16
MX Build: controls@fb1:/opt/src/mx-1.2.16 Mon Aug 14 11:06:09 PDT 2017
1 Myrinet board installed.
The MX driver is configured to support a maximum of:
    8 endpoints per NIC, 1024 NICs on the network, 32 NICs per host
===================================================================
Instance #0:  364.4 MHz LANai, PCI-E x8, 2 MB SRAM, on NUMA node 0
    Status:        Running, P0: Link Up
    Network:    Ethernet 10G

    MAC Address:    00:60:dd:45:37:86
    Product code:    10G-PCIE-8B-S
    Part number:    09-04228
    Serial number:    423340
    Mapper:        00:60:dd:45:37:86, version = 0x00000000, configured
    Mapped hosts:    3

                                                        ROUTE COUNT
INDEX    MAC ADDRESS     HOST NAME                        P0
-----    -----------     ---------                        ---
   0) 00:60:dd:45:37:86 fb1:0                             1,0
   1) 00:25:90:05:ab:47 c1bhd:0                           1,0
   2) 00:25:90:06:69:c3 c1sus2:0                          1,0

controls@c1bhd:~ 1$ /opt/open-mx/bin/omx_info
Open-MX version 1.5.4
 build: root@fb1:/opt/src/open-mx-1.5.4 Tue Aug 15 23:48:03 UTC 2017

Found 1 boards (32 max) supporting 32 endpoints each:
 c1bhd:0 (board #0 name eth1 addr 00:25:90:05:ab:47)
   managed by driver 'igb'

Peer table is ready, mapper is 00:60:dd:45:37:86
================================================
  0) 00:25:90:05:ab:47 c1bhd:0
  1) 00:60:dd:45:37:86 fb1:0
  2) 00:25:90:06:69:c3 c1sus2:0

controls@c1sus2:~ 0$ /opt/open-mx/bin/omx_info
Open-MX version 1.5.4
 build: root@fb1:/opt/src/open-mx-1.5.4 Tue Aug 15 23:48:03 UTC 2017

Found 1 boards (32 max) supporting 32 endpoints each:
 c1sus2:0 (board #0 name eth1 addr 00:25:90:06:69:c3)
   managed by driver 'igb'

Peer table is ready, mapper is 00:60:dd:45:37:86
================================================
  0) 00:25:90:06:69:c3 c1sus2:0
  1) 00:60:dd:45:37:86 fb1:0
  2) 00:25:90:05:ab:47 c1bhd:0

These outputs prove that the framebuilder and the FEs are able to see each other in teh DAQ network.

Further, the error that we see when IOP model is started which crashes the mx_stream service on the FE machines (see 40m/16391) :

isendxxx failed with status Remote Endpoint Unreachable

This has been seen earlier when Jamie was troubleshooting the current fb1 in martian network in 40m/11655 in Oct, 2015. Unfortunately, I could not find what Jamie did over a year to fix this issue.

[Larisa, Kiwamu, Steve and Suresh]

  We continued the labeling of video cables. All exiting cables which are going to be used used in the new scheme have been labeled.

We also labeled the cables running from the video mux to the TV monitors in the computer room. Some of these will be removed or reallocated.

We will continue next Wednesday (after the meeting) and will lay cables that are most urgently required. 

 i

[Den, Mirko]

We looked some more into the the OSEM signals and their coherence to the seismometer signals.

We were able to verify that the coherence OSEM sensor <-> seismometer signal goes down with increasing the OSEM gain. This seems to indicate that the OSEM FB add noise to the distance mirror <-> frame. We injected some noise into the OSEMs to see how the coherence behaves.

MC2 SUSPOS, 0.1Hz - 0.8Hz, 3mins each

Inj. amplitude   Time(UTC) Note

-                     21:35          Free swinging
-                     21:42          Big LF OSEM gain
-                     21:48          Small LF OSEM gain
150                     21:56          -"-
300                     22:00          -"-
900                     22:05          -"-

Free swinging:

High OSEM gain:

Low OSEM gain:

We left the filters that lower the OSEM gain below 0.3Hz on.

Summary:

I want to be able to run the dither alignment servo with the PRFPMI locked - I've been thinking about what the scheme should be, and I list here some questions I had while thinking about this.

Details:

1. ITM Oplev DC coupling
   • In the current scheme, I DC couple the ITM Oplev servos after the arms have been aligned to maximize POX/POY transmission.
   • However, looking back at data from when the CARM offset is reduced (e.g. Attachment #1), it looks like the ITMs are being torqued quite a bit during this process (ITMX PIT changes by ~20urad, ITMY YAW by ~10urad in this particular lock attempt). 
   • So the spots are not actually being centered on the test-masses? I guess the spot position on ITMX isn't actually controlled because we have only one actuator (BS) for the XARM beam axis. Is it unexpected that ITMY gets torqued so much? 
   • It is unclear what would happen if the ITM Oplev servos are not DC coupled. I wonder if I'd still be able to reach the high circulating powers and then rely solely on the TR QPDs for the arm cavity angular control.
   • Another possibility is to offload the DC part of the control signal to the optic's slow bias voltage slider, and then turn off the DC coupling. After that, the dither alignment can optimize the cavity alignment.
2. Dither alignment at high circulating power
   • I think that the system should work with the same settings as for the POX/POY locking, with the following changes:
     • Scale the overall loop gain by the arm transmission.
     • Change LSC2ASS matrix element from XARM/YARM ---> DARM.
       Does this sound right?
   • In light of the above, I was thinking that we should introduce a gain scaling field in the c1ass RTCDS model (like we have for the LSC power normalization matrix). Is it worth to go through the somewhat invasive process of model recompilation etc?
   • With the PRFPMI locked, I am wondering if I can simultaneously run the dither alignment loops for all the DoFs. Probably not, especially for MICH, since the actuator is the BS, which is also the actuator for the XARM loop?

Summary:

For a series resistance of 4.5 kohm, we are suffering from the noise-gain amplified voltage noise of the Op27 (2*3.2nV/rtHz), and the Johnson noise of the two 1 kohm input and feedback resistances. As a result, the current noise is ~2.7 pA/rtHz, instead of the 1.9 pA/rtHz we expect from just the Johnson noise of the series resistance. For the present EX coil driver configuration of 2.25 kohm, the Op27 voltage noise is actually the dominant noise source. Since we are modeling small amounts (<1dB) of measurable squeezing, such factors are important I think. 

Details:

[Attachment #1] --- Sketch of the fast signal path in the coil driver board, with resistors labelled as in the following LISO model plots. Note that as long as the resistance of the coil itself << the series resistance of the coil driver fast and slow paths, we can just add their individual current noise contributions, hence why I have chosen to model only this section of the overall network.

[Attachment #2] --- Noise breakdown per LISO model with top 5 noises for choice of Rseries = 2.25 kohm. The Johnson noise contributions of Rin and Rf exactly overlap, making the color of the resulting line a bit confusing, due to the unfortunate order of the matplotlib default color cycler. I don't want to make a custom plot, so I am leaving it like this.

[Attachment #3] --- Noise breakdown per LISO model with top 5 noises for choice of Rseries = 4.5 kohm. Same comments about color of trace representing Johnson noise of Rin and Rf. 

Possible mitigation strategies:

1. Use an OpAmp with lower voltage noise. I will look up some candidates. LT1028/LT1128? LISO library warns of a 400 kHz noise peak though...
2. Use lower Rin and Rf. The values of these are set by the current driving capability of the immediately preceeding stage, which is the output OpAmp of the De-Whitening board, which I believe is a TLE2027. These can source/sink 50 mA according to the datasheet . So for +/-10V, we could go to 400 ohm Ri and Rf, source/sink a maximum of 25mA, and reduce the Johnson noise contribution by 40%.

Other comments/remarks:

I've chosen to ignore the noise contribution of the high current buffer IC that is inside the feedback loop. Actually, it may be interesting to compare the noise measurements (on the electronics bench) of the circuit as drawn in Attachment #1, without and with the high current buffer, to see if there is any difference.

This study also informs about what level of electronics noise is tolerable from the De-Whitening stage (aim for ~factor of 5 below the Rseries Johnson noise).

Finally, in doing this model, I understand that the observation the voltage noise of the coil driver apparently decreased after increasing the series resistance, as reported in my previous elog. This is due to the network formed by the fast and slow paths (during the measurement, the series resistance in the slow path makes a voltage divider to ground), and is consistent with LISO modeling. If we really want to measure the noise of the fast path alone, we will have to isolate it by removing the series resistance of the slow bias path.

Comment about LISO breakdown plots: for the OpAmp noises, the index "0" corresponds to the Voltage noise, "1" and "2" correspond to the current noise from the "+" and "-" inputs of the OpAmp respectively. In future plots, I'll re-parse these...

Summary:

Using a heterodyne measurement setup to track both quadratures, I estimated the relative phase fluctuation between the LO field and the interferometer output field. It may be that a single PZT to control the homodyne phase provides insufficient actuation range. I'll also need to think about a good sensing scheme for controlling the homodyne phase, given that it goes through ~3 fringes/sec - I didn't have any success with the double demodulation scheme in my (admittedly limited) trials.

For everything in this elog, the system under study was a simple Michelson (PRM, SRM and ETMs misaligned) locked on the dark fringe.

Details:

​This work was mainly motivated by my observation of rapid fringing on the BHD photodiodes with MICH locked on the dark fringe. The seismic-y appearance of these fringes reminded me that there are two tip-tilt suspensions (SR2, SR3), one SOS (SRM) + various steering optics on seismic stacks (6+ steering mirrors) between the dark port of the beamsplitter and the AS table, where the BHD readout resides. These suspensions modulate the phase of the output field of course. So even though the Michelson phase is tightly controlled by our LSC feedback loop, the field seen by the homodyne readout has additional phase noise due to these optics (this will be a problem for in vacuum BHD too, the question is whether we have sufficient actuator range to compensate).

To get a feel for how much relative phase noise there is between the LO field and the interferometer output field (this is the metric of interest), I decided to set up a heterodyne readout so that I can simultaneously monitor two orthogonal quadratures.

• The idea is that with the Michelson locked, there is no DC carrier field from the interferometer.
• The field incident on the DCPD from the interferometer should be dominated by the 55 MHz sideband transmitted to the dark port given the Schnupp asymmetry. 
• The LO field is picked off before any RF sidebands are added to it (the PMC modulation sideband should be suppressed by the cavity transmission).
• Therefore, the LO field should be dominantly at the carrier frequency.
• By placing a broadband RFPD (PDA10CF) in place of one of the DCPDs, I can demodulate the optical beat between this 55 MHz sideband, which shares the same output path to the location of the DCPD as the audio-frequency sidebands on the carrier from the dark Michelson, to estimate the relative phase noise between the LO and IFO output fields.
• The point is that with the heterodyne readout, I can track the fringe wrapping, which is not an option for the BHD readout with two DCPDs, and uncontrolled LO phase.

Attachment #1 shows the detailed measurement setup. I hijacked the ADC channels normally used by the DCPDs (along with the front-end whitening) to record these time-series.

Attachments #2, #3 shows the results in the time domain. The demodulated signal isn't very strong despite my pre-amplification of the PDA10CF output by a ZFL-500-HLN, but I think for the purposes of this measurement, there is sufficient SNR.

This would suggest that there are pretty huge (~200um) relative phase excursions between the LO and IFO fields. I suppose, over minutes, it is reasonable that the fiber length changes by 100um or so? If true, we'd need some actuator that has much more range to control the homodyne phasethan the single PZT we have available right now. Maybe some kind of thermal actuator on the fiber length? If there is some pre-packaged product available, that'd be best, making one from scratch may be a whole project in itself. Attachment #3 is just a zoomed-in version of the time series, showing the fringing more clearly.

Attachment #4 has the same information as Attachment #2, except it is in the frequency domain. The FFT length was 30 seconds. The features between ~1-3 Hz support my hypothesis that the SR2/SR3 suspensions are a dominant source of relative phase noise between LO and IFO fields at those frequencies. I guess we could infer something about the acoustic pickup in the fibers from the other peaks.

Here is a plot of when the arm powers went pretty high from last night.  CARM and DARM were on ALS comm and diff, PRMI was on REFL33 I&Q.  I set the CARM offset so that I was getting some full arm resonances, and it goes back and forth over the resonance.

The Y axes aren't perfect when I zoom, but the maximum TRX value was 98 in this plot, while the max TRY value was 107. 

MICH_OUT was hitting its digital rails sometimes, and also it looks like PRCL and MICH occasionally lost lock for very brief periods of time. 

Glitch-like events in PRCL_OUT are at the edges of these mini-locklosses. I don't know why POPDC has glitch-y things, but we should see if that's real.

Okay, I've zoomed in a bit, and have found that, interestingly, I see that both POP22 and POP110 decrease, then increase, then decrease again as we pass through full resonance.  This happens in enough places that I'm pretty sure we're not just going back and forth on one side of the resonance, but that we're actually passing through it.  Q pointed out that maybe our demod phase angle is rotating, so I've made some zoom-in plots to see that that's not a significant effect.  I plot the I and Q phases individually, as well as the total=sqrt(I**2 + Q**2), along with TRY (since the increases and decreases are common to both arms, as seen in the plot above).

For POP 22:

For POP 110:

I also plot the MICH and PRCL error signals along with TRY and POP22 total.  You can see that both MICH and PRCL were triggered off about 0.1msec after POP22 total this it's first super low point.  Then, as soon as POP22 becomes large enough, they're triggered back on, which happens about 1.5msec later. (The triggering was actually on POP22I, not POP22tot, but the shapes are the same, and I didn't want to overcrowd my plots).

I am not sure if we consistently lose sideband signal in the PRC more on one side of the CARM resonance than the other, but at least POP22 and POP110 are both lower on the farther side of this particular peak.  I want to think about this more in relation to the simulations that we've done.  One of the more recent things that I see from Q is from September:  elog 10502, although this is looking specifically at the REFL signals at 3f, not the 2f circulating PRCL power as a function of CARM offset.

I made some model changes to c1lsc. To propagate the changes, I tried the usual rtcds make sequence. But I got an error about the model file not being in the path. This is down to my re-organization of the paths to cleanly get everything under git version control. So I had to run the following path modification. Where is this variable set and how can I add the new paths to it? The model compilation, installation and restart all went smooth after I made this change. 

For smooth reboot of the models, I used the reboot script. I had to restart the daqd processes on FB, but now all the CDS indicator lights are green.

I edited /diskless/root.jessie/home/controls/.bashrc so that I don't have to keep doing this every time I do a model recompile.

Nice and interesting plot.

I suppose slight decrease of the Schnupp asymmetry (in your model) adjusts the discrepancy in the high freq region.
At the same time, it will make the resonance narrower. So you need to put some loss at the recombination (=on the BS)?

...of course these depends on the flatness of the calibration.

1. Added rough cts2mW calibration filters to the quadrants, see Attachment #1. The number I used is:
             0.85 A/W         *       500 V/A            *          10 V/V                              *         1638.4 cts/V
   (InGaAs responsivity)     (RF transimpedance)  (IQ demod conversion gain)      (ADC calibration)
2. Recovered FPMI locking. Once the arms are locked on POX / POY, I lock MICH using AS55_Q as a sensor and BS as an actuator with ~80 Hz UGF.
3. Phased the digital demod phases such that while driving a sine wave in ETMX PIT, I saw it show up only in the "I" quadrant signals, see Attachment #2.

The idea is to use the FPMI config, which is more easily accessed than the PRFPMI, to set up some tests, measure some TFs etc, before trying to commission the more complicated optomechanical system.

Finally, some RF only CARM, see Attachment #1. During this time, DARM was also on a blend of IR and ALS control, but I couldn't turn the ALS path off in ~4-5 attempts tonight (mostly me pressing a wrong button). Attachment #2 shows the CARM OLTF, with ~2kHz UGF - for now, I didn't bother turning any boosts on. PRCL and MICH are still on 3f signals.

The recycling gain is ~7-8 (so losses >200ppm), but there may be some offset in some loop. I'll look at REFL DC tomorrow.

Can we please make an effort to keep the IFO in this state for the next week or two
- it really helped tonight I didn't have to spend 2 hours fixing some random stuff and could focus on the task at hand.

[Jenne, Sanjit]

It seems now that we are able to get the OAF system to do a pretty good job of approximating the MC_L signal, but we can't get it to actually do any subtracting.  I think that we're not correctly setting the phase delay between the witness and the MC_L channels or something (I'm not sure though why we get a good filter match if the delay is set incorrectly, but we do get a good filter match for very different delay settings: 1, 5, 100, 1000 all seem to do equally well at adjusting the filter to match MC_L). 

The Matt Evans document in elog 395 suggests measuring the phase at the Nyquist frequency, and calculating the appropriate delay from that.  The sticking point with this is that we can't get test points for any channel which starts with C1:ASS.  I've emailed Alex to see what he can do about this.  Elog 1982 has a few words about how we're perhaps using a different awgtpman on the ass machine than we used to, which may be part of the problem. 

The golden plan, which in my head will work perfectly, is as follows: Alex will fix the testpoint problem, then Sanjit and I will be able to measure the phase between our OAF signal and the incoming MC_L signal, we will be able to match them as prescribed in the Matt Evans document, and then suddenly the Adaptive Filtering system will do some actual subtracting!

The plot below shows the Reference MC_L without any OAF system (black), the output of the OAF (green), and the 'reduced' MC_L (red).  As you can see, the green trace is doing a pretty good job of matching the black one, but the red trace isn't getting reduced at all.

I have made a little bit of progress on the PEM channels.  I have begun writing up detailed instructions in the DAQ Wiki page on how to add a channel to the new DAQ system.  I have followed those instructions thus far, and can see my channels in the .ini file (and in the daqconfig gui thing), but I don't have any channels in Dataviewer or DTT. 

There are some tricky "gotchas" involved in creating new models and channels.  Some examples include:  No use of the characters "DUMMY" in any channel name.  The makefile is specifically hardcoded to fail if that string of characters is used.  Also, you must have at least 2 filter banks in every model.  Why? No one knows.  You just do.  The model won't compile unless you have 2 or more filter banks. 

My efforts today included ~3 reboots of the frame builder, and ~2 reboots of c1sus.  When Kiwamu and I rebooted c1sus, we burt restored to some time in the last 24 hrs.  Some of the SUS filters on some of the optics were not set correctly (things like the bounce roll filter), so we turned all of them on, and reset all of the input and output matricies to be the correct combination of +1 and -1's to make Pit, Pos and Yaw.  The tuning seems to happen now-a-days in the gains for each DOF, and the gains were set correctly by the burt restore for every optic except PRM.  We made some educated guesses for what the gains should be based on the other optics, and PRM is damping pretty well (these guesses included reducing the SIDE gain by ~10 from the BS SIDE value, since the analog gain of the PRM SIDE sensor is much higher than others).  We'll have to fine tune these gains using some Yuta-developed method soon.  Or find a burt snapshot that had some non-unity values in there.

Some questions came arise to me:

A. How the green injection system should be? How the handing off between 532 and 1064 should be?

This is not new, though. It would be worth reminding.

B. Do we still need PMC if we use 2W innolight?

Innolight has low intensity noise at the detection freq. Also the spacial mode is clean.

C. Do we still need frequency prestabilization by RC?

Is the stabilization of the laser freq by the MC not enough?
What is the relationship with the green?

Jenne made some suggestions for some plots that would be useful on our CARM offset reduction adventures, so I made some with my MIST model. 

First, here's a plot showing the transfer function of CARM to TRX, with logarithmically spaced offsets out to 3nm. While not a control signal, it shows us where the optical plant resonance stuff is happening. The peaks in this TF correspond to peaks in REFL11, REFL55, AS11, etc., as in the close-to-resonance TFs in ELOG 9785. 

[more to come, had a MATLAB issue]

I've found that a few of the screens still have Whited-Out fields due to naming changes (OL SUM and ALS-> TM OFFSET). I attach a screen shot of it.

The OL screens have the wrong SUM names and the IFO ALIGN screen is pointing to the wrong SUS screens.

The bad medm screens have been fixed. There are no blank fields and all the links are correct.

 Really? I found this one with ~15 seconds of clicking around.

[koji, gautam] 

Plots + interpretation tomorrow.

• CM_Slow path can be used to stabilize the arm powers somewhat but the AO crossover remains out of reach.
• The REFL11 (=CARM_B) path offset has to be manually determined - we found that it can change by ~20% depending on the alignment, which maybe isn't surprising given that the mode shapes seen at POP, REFL and AS look like Rorschach inkblots.
• We saw TRX/TRY regularly hit ~150, and at times even 200 (= recycling gain of ~10). Though any conclusive statement about the PRG can only be made once the lock is stabilized.
• I was able to take a few CARM loop TFs with an SR785 hooked up at 1Y2. Despite ramping up the AO gain, we saw no effect at high frequencies in the TF shape (the phase bubble continued to roll off at ~100 Hz and there was no visible phase lead even as the AO gain was increased). It has to be estimated what the expected crossover gain is from the experiment with the high BW POY locking (taking into account the net difference in optical gain between POY for single arm and REFL for the full IFO).
• The fact that I was able to hold the high BW POY lock makes me think that the IMC servo board's IN2 input (and indeed the rest of the IMC locking loop) is functioning as expected. But maybe this board will benefit from a detailed checkout like Koji did for the CM board.

Getting closer... To facilitate this work, I made some convenience scripts that can be run from the CM MEDM screen.

Small steps tonight, but all in the forward direction.

On one of my better locks, I saw a kind of weird phenomenon with the PRMI sideband powers versus the carrier powers:

For the last 100 seconds of this plot, I'm all 1f.  Alignment is being handled mostly by Q's DC coupled ITM oplevs, and the transmission QPD ASC loops, although I was trying to adjust the offsets in the ASC loops to improve transmission for a bit.

At the very end, the last 10 seconds or so, the POP110 power goes down, and sits at about half it's maximum value.  POP22 isn't quite as bad, in that it still touches the max, but the RIN is about 50%.  The carrier DC signals (TRX, TRY, POPDC) don't see this huge jump.  I don't think I was touching anything the last few tens of seconds.  I'm not sure yet how I can so significantly lose sideband power, without losing a similar amount of carrier power. 

The ring-ups at about -70sec in the CARM and DARM outs are the bounce mode. 

I tried looking at 2D histograms of different combinations of channels, for the time around -30 seconds where things looked pretty clean.  It looks like the offsets that Q put in last night (+1 for MICH_B and -3 for PRCL_B) are still about right.  The PRCL_IN1 and MICH_IN1 were centered around zero at the maximum power points.  CARM and DARM had small offsets, which I put into the DARM_B and CARM_B filter banks (0.0066 for DARM_B, and 0.027 for CARM_B), although these are small enough that I don't know that they really do anything.

As a break from locking for a little while, I tried to see if I could get the TT3 and TT4 DAC channels to work for me.  I had hoped it would be a quick and easy task, but I'm not seeing signal out.  Since it wasn't working, I decided to go back to locking for the night, and look into the DAC in the daytime.  I want to use one channel as the IN2 input of the CM board, and another as the external modulation input to the Marconi for transfer functions, so I need them to work. 

As a side note on the input to the Marconi situation, it occurred to me that instead of laying a new cable, I can borrow the POP55 heliax.  We don't have a POP55 diode right now, and the other end comes out across the hall from the Marconi, so it would be pretty easy to have a medium-length cable go from ITMX table to the Marconi.  Objections to this? 

I saw this same kind of behavior in my locklosses on Wednesday night; we should check out the 165 data, and see if the 3f PRCL error signal shows some drift away from zero.

Also, it's odd that CARM_IN1 and REFL11_I_ERR have different low frequency behavior in the plot you posted. I guess they have some difference in demodulation phase.  REFL11_I's bump at -40sec coincides with the dip in arm power and a rise in REFLDC, but ASDC seems pretty smooth, so maybe it is a real CARM fluctuation.

I set the REFL11 analog demodulation angle (via cable length) about a year ago (ELOG 9850), with some assumption about PRCL having the same demod angle as CARM, but this was probably set with the arms misaligned. We should recheck this; maybe we're coupling some other junk into CARM. 

[Sanjit, Jenne]

Sanjit and I are trying to put names to some signals which exist in SimuLink land, but which don't (yet) exist in EPICS land.  The deelio is that for each of the chosen SEIS signals in the ASS_TOP_PEM screen, the signal is split.  One part of the signal is used to decide how the adaptive filter should look, and the other part is actually used when doing the on-line subtraction.  Previously only the part of the signal which is used to decide on the Adaptive Filter could be seen on the screens, and had names. 

Before touching anything on the Simulink ASS.mdl, I did an svn check in, which put things at revision 36639. 

To try to make the desired signals exist, I put cdsFilt boxes (to create filter modules for each of these signals), and gave each of them a name (kind of like the Neverending Story....once they have a name, they'll exist).  My new names are C1:ASS-TOP_PEM_#_APPLY, which correspond to the previously-existing C1:ASS-TOP_PEM_#_ADPT (these are the ones that are along the top of the ASS_TOP_PEM matrix screen).  This version of the simulink model was checked in, and the svn is now at revision 36640.

We then did some "make clean", "make ass" and "make install-ass" action, and burt restored c1assepics, but nothing seems to be happening.  The screen doesn't have white boxes all over the place, and we didn't get any errors when we did the makes, and I'm sure we burt restored correctly (made sure the ASS GDS screen had a 1 in the lower left box etc), but all the values on the screen are still zero.  

When we ran the ass front end in terminal on the c1ass machine, we did see an error: "Invalid chan num found 2 = 30624" "DAQ init failed -- exiting".  I think this means that we need to have told some file somewhere that I was going to be adding 8 new channels. (maybe an .ini file?) Hopefully the Joe & Peter team can help us out with this, since they've been doing this kind of thing for the new system.

Moral of the story is, the new (non-working) simulink file has been svn checked in as revision 36640, and we're reverting to revision 36639, which was before I touched anything today.

Where do we want to install the interface and readout electronics for the AS port WFS? Options are:

• 1Y1 / 1Y3  (i.e. adjacent to the LSC rack) - advantage is that 55 MHz RF signal is readily available for demodulation. But space is limited (1Y2, where the RF signal is, is too full so at the very least, we'd have to run a short cable to an adjacent rack), and we'd have a whole bunch of IPC channels between c1lsc and c1ioo models.
• 1X1/1X2. There's much more space and we can directly digitize into the c1ioo model, but we'd have to route the 55 MHz signal back to this rack (kind of lame since the signal generation is happening here). I'm leaning towards this option though - thinking we can just open up the freq generation box and take a pickoff of the 55 MHz signal...

There isn't much difference in terms of cable length that will be required - I believe the AS WFS is going to go on the AP table even in the new optical layout and not on the ITMY in-air oplev table? 

The project requires a large number of new electronics modules. Here is a short update and some questions I had:

1. WFS head and housing. Need to finalize the RF transimpedance gain (i.e. the LC resonant part), and also decide which notches we want to stuff. Rich's advise was to not stuff any more than is absolutely necessary, so perhaps we can have at first just the 2f notch and add others as we deem necessary once we look at the spectrum with the interferometer locked. Need to also figure out a neat connector solution to get the signals from the SMP connectors on the circuit board to the housing - I'm thinking of using Front-Panel-Express to design a little patch board that we can use for this purpose, I'll post a more detailed note about the design once I have it.
2. WFS interface board + soft-start board (the latter provides a smooth ramp up of the PD bias voltage). These go in a chassis, the assembly is almost complete, just waiting on the soft-start board from JLCPCB. One question is how to power this board - Sorensens or linear? If we choose to install in 1X1/1X2, I guess Sorensen is the only option, unless we have a couple of linear power supplies lying around spare.
3. Demod board (quad chassis). Assembly is almost complete, need to install the 4 way RF splitter, some insulating shoulder washers. (to ensure the RF ground is isolated from the chassis), and better nuts for the D-sub connectors. A related question is how we want to supply the electrical LO signal for demodulation. The "nominal" level each demod board wants is 10 dBm. This signal will be sourced inside the chassis from a 4-way RF splitter (~7 dB insertion loss). So we'd need 17dBm going into the splitter. This is a little too high for a compact amplifier like the ZHL-500-HLN to drive (1dB compression point is 16 dBm), and the signal level available at the LSC rack is only ~2 dBm. So do we want a beefy amplifier outside the chassis amplifying the signal to this level? Or do we want to use the ZHL-500-HLN, and amplify the signal to, say 13 dBm, and drive each board with ~6 dBm LO? The Peregrine mixer on these boards (PE4140) are supposed to be pretty forgiving in terms of the LO level they want... In either case, I think we should avoid having an amplifier also inside the chassis, it is rather full in there with 4 demod boards, regulator board, all the cabling, and an RF splitter. It may be that heat dissipation becomes an issue if we stick an RF amplifier in there too...
4. Whitening chassis. Waiting for front panels to arrive, PCBs and interface board are in hand, stuffed and ready to go. A question here is how we want to control the whitening - it's going to be rather difficult to have fast switchable whitening. I think we can just fix the whitening state. Another option would be to control the whitening using Acromag BIO channels.
5. AI chassis - will go between whitening and ADC.
6. Large number of cables to interconnect all the above pieces. I've asked Chub to order the usual "Deluxe" shielded Dsub cables, and we will get some long SMA-SMA cables to transmit the RF signals from head to demod board from Pasternack (or similar), do we need to use Heliax or the Times Microwave alternative for this purpose? What about the LO signal? Do we want to use any special cable to route it from the LSC rack to the IOO rack, if we end up going that way? 

Approximately half of the assembly of the various electronics is now complete. The basic electrical testing of the interface chassis and demod chassis are also done (i.e. they get power, the LEDs light up, and are stable for a few minutes). Detailed noise and TF characterization will have to be done.

An 8 channel whitening chassis was prepared and tested. I measured:

1. TF from input to output - there are 7 switchable stages (3 dB, 6 dB, 12 dB and 24 dB flat whitening gain, and 3 stages of 15:150 Hz z:p whitening). I enabled one at a time and measured the TF. 
2. Noise with input terminated.

In summary,

1. All the TFs look good (I will post the plots later), except that the 3rd stage of whitening on both boards don't show the expected transfer function. The fact that it's there on both boards makes me suspect that the switching isn't happening correctly (I'm using a little breakout board). I'm inclined to not debug this because it's unlikely we will ever use 3 stages of 15:150 whitening for the AS WFS. 
2. The noise measurement displayed huge (x1000 above the surrounding broadband noise floor) 60 Hz harmonics out to several kHz. My hypothesis is that this has to do with some bad grounding. I found that the circuit ground is shorted to the chassis via the shell of the 9pin and 15pin Dsub connectors (but the two D37 connector shields are isolated). This seems very wierd, idk what to make of this. Is this expected? Looking at the schematic, it would appear that the shields of the connectors are shorted to ground which seems like a bad idea. afaik, we are using the same connectors as on the chassis at the sites - is this a problem there too? Any thoughts? 

Summary:

In ELOG 15368, I had claimed that the POP QPD based feedback servo actuating on the PRM stabilized the lock. I now believe this scheme of sensing using the POP QPD and feeding back to the PRM is not a good topology for stabilizing the PRC angular motion.

Details:

• I was never able to get a measurement of the OLTF of this loop that made sense 
  • the loop was initally commissioned with the PRMI locked on the carrier, and the settings hence inferred to give a ~5 Hz UGF loop were used in the PRFPMI lock.
  • In the PRFPMI configuration, however, the loop gain seemed way too low when I measured using the usual IN1/IN2 method.
  • So it is critical for the lock stability that the angular feedforward works well, which it kind of does now (not that I have changed anything, but the glitches in the seismometer have not resurfaced recently).
  • Hopefully, this becomes less of an issue once we replace the TTs with SOS and OSEM based damping.
• To get some more insight, I did some finesse modeling
  • Attachment #1 shows the sensing response at the QPDs we have available currently (POP and TR). 
  • I included the telescopes (propagation distances, in-air lenses) to these QPDs as best as I could.
  • A simplified model (3 mirror coupled cavity) is used, so there isn't really a common/differential mode in this picture, but we still get some insight I think.
  • Specifically, once the full lock is realized, the PRC optic motion isn't sensed well with our QPDs, and so it was some fluke that turning on these PRC angular feedback loops worked. 
  • Attachment #2 shows the same info as Attachment #1, but with the pendulum transfer functions (and radiation pressure effects) included. The SOS suspensions are modelled as f0=0.7/0.8 Hz (for P/Y), Q=5, while the tip-tilts have f0~5 Hz, Q~10. The high frequency phase is 0 degrees and not 180 as expected because of the pendulum complex pole pair because of the way the quantity is computed in Finesse.
• The current scheme I use is:
  • DC couple the ITM oplevs, using their individual Oplev QPDs.
  • Use the TR QPDs, mixed to actuate on the ETMs in a common/differential way.
  • I think the system is under-determined with the sensors we currently have - we wan't to sense the 10 angular modes - PIT and YAW for the PRC, Csoft, Chard, Dsoft and Dhard (using the terminology from Kate's thesis), but we only have 6 sensors of the same field (POP, TRX and TRY QPDs, PIT and YAW from each).
  • So we need more sensors?
• One thing that can easily be improved I think is to make the ASS system work at high power. 
  • I think this should be as simple as scaling the gain for the loops to work for the high power.
  • Then we can counteract the input pointing drift at least.
  • But the ITM Oplev DC coupling would need to be turned OFF and then ON again, I'm not sure if this will introduce some transient that will destroy the lock...

I would also like to bring up the topic of implementing some WFS for the interferometer fields again, there doesn't seem to be any mention of this in the procurement/planning for the BHD. It is not obvious to me yet that we need WFS and not just DC QPDs from a noise point of view, but at least we should discuss this.

[koji, gautam, jon, steve]

• We suspect analog voltage from N2 pressure gauge is connected to interfacing Omega controller with the 'wrong' polarity (i.e pressure is rising over ~4 days and then rapidly falling instead of the other way around). This should be fixed.
• N2 check script logic doesn't seem robust. Indeed, it has not been sending out warning emails (threshold is set to 60 psi, it has certainly gone below this threshold even with the "wrong" polarity pressure gauge hookup). Probably the 40m list is rejecting the email because controls isn't a part of the 40m group.
• Old frames have to be re-integrated from JETSTOR to the new FB in order to have long timescale lookback.
• N2 cylinder pressure gauges (at the cylinder end) need a power supply - @ Steve, has this been purchased? If not, perhaps @ Chub can order it.
• MEDM vacuum screen should be updated to have gate valves be a different color to the spring-loaded valves. Manual valve between TP1 and V1 should also be added.
• P2, P3 and P4 aren't returning sensible values (they should all be reading ~760torr as is P1). @ Steve, any idea if these gauges are broken?
• Hornet gauges (CC and Pirani) should be hooked up to the new vacuum system.
• add slow channels of   foreline pressures of TP2 & 3   and    C1:Vac-IG1_status_pressure

Some updates of the LSC screen

- Signal amplitude monitor for the PD signals (--> glows red for more than 1000)

- Kissel Buttons for the main matrices

- Trigger display at the output of the DOF filters

- Signal amplitude monitor for the SUS LSC output (--> glows red for more than 10000)

ADC Over flow monitor is showing some unknown numbers (as ADCs are handled by IOPs).
I asked Joe for the investigation (and consideration for the policies)

Some updates on the Y end green PDH lock

(Measurement of the Y arm fluctuation)

 

(Temporary servo setup)

(Sanity checks)

For the first time after the whirlwind vent, I managed to lock the PRMI.

• First, I did POX/POY locking, dither aligned the arms to maximize TRX and TRY.
• Next, I misaligned the ETM and tested the Michelson locking
  • Since we've lost ~70% of power on the AS55 PD, I set the whitening gain for AS55 I and Q channels to +6dB (old value was 0dB).
  • worked alright. In this new config, the peak-to-peak Michelson fringe count is ~80 cts, while I reported ~60cts-pp a couple of months ago, so all seems good on that front.
  • But the config script in the IFOconfigure MEDM screen somehow doesn't set the AS55_Q ----> MICH_A element in the LSC input matrix anymore.
  • I edited the .snap file for this configuration to set the relevant matrix element EPICS channel to +1.0.
  • I also edited the overall loop gain for this configuration from +30 to +2 (for bright fringe, use -2 for dark fringe).
• Feeling adventerous, I decided to try PRMI in the carrier resonant tuning (to be clear, PRCL on REFL11_I, MICH on AS55_Q).
  • Finding the REFL spot on the camera took a while since the PRM has been macroscopically misaligned for the mode-scanning
  • Went out to the table and centered the REFL beam onto REFL11 and REFL55 PDs - didn't need much tweaking, which is a good sign, since we shouldn't have screwed anything up on the symmetric side by any of the vent activities.
  • Restored PRMI locking using the IFOconfigure MEDM screen - lock caught almost immediately.
  • Ran the dither alignment servos for MICH and PRCL - BS needed a bit of encouragement to make the dark spot dark, but POP has been pretty stable over ~15mins.
  • I didn't take any loop transfer functions, to do.

I don't have the energy to make a DRMI attempt tonight - but the signs are encouraging. I'd like to use the IFO in the next few days to try and recover DRMI locking. The main concern is that the optical path on the AS beam has changed by ~0.3m I estimate. So the demod phase for AS55 may need to be adjusted, but the change due to optical path length only should be ~10degrees so the DRMI locking with the old settings should still work. Perhaps we also want to scan the PRC and SRC with the phase information from the Trans/Refl transfer functions as well.

Don't want to jinx it, but the c1lsc FE models have been stable. Tomorrow, I'd like to re-enable c1cal, since it has some useful channels for NBing. Could c1daf/c1oaf which have significant amounts of custom C code be the culprits?

1. In anticipation of installing the new fan on the PSL, I disconencted the old fan and finally removed the bench power supply from the top shelf.
2. Moved said bench supply to under the south-west corner of the PSL table.
3. Installed temporary Acromag crate, now with two ADC cards, under the PSL table and hooked it up to the bench suppy (+15 VDC). Also ran an ethernet cable from 1X3 to the box on over head cable tray and connected it.
4. Brought other end of 25-pin D-sub cable used to monitor the NPRO diagnostics channels from 1X4/1X5 to the PSL table. Rolled the excess length up and cable tied it, the excess is sitting on top of the PSL enclosure. Key parts of the setup are shown in Attachments #1-3. This is not an ideal setup and is only meant to get us through to the install of the new c1psl/c1ioo Acromag crate.
5. Edited the modbus config file at /cvs/cds/caltech/target/c1psl2/npro_config.cmd to add Jon's new ADC card to the list.
6. Edited EPICS database file at /cvs/cds/caltech/target/c1psl2/psl.db to add entries for the C1:PSL-FSS_RMTEMP and C1:PSL-PMC_PMCTRANSPD channels.
7. Hooked up said channels to the physical ADC inputs via a DB15 cable and breakout board on the PSL table.
   CH0 --- FSS_RMTEMP (Pins 5/18 of the DB25 connector on the interface box to pins 1/9 of the Acromag DB15 connector)
   CH1 --- PMC TRANS (BNC cable from PD to pomona minigrabber to pins 2/10 of the Acromag DB15 connector)
   CH2-6 are unsued currently and are available via the DB15 breakout board shown in Attachment #3. CH7 is not connected at the time of writing
   The pin-out for the temperature sensor interface box may be found here. Restarted the modbus process. The channels are now being recorded, see Attachment #4, although checking the status of the modbus process, I get some error message, not sure what that's about.

So now we can monitor both the temperature of the enclosure (as reported by the sensor on the PSL table) and the NPRO diagnostics channels. The new fan for the controller has not been installed yet, due to us not having a good mounting solution for the new fans, all of which have a bigger footprint than the installed fan. But since the laser isn't running right now, this is probably okay.

I took a look at the error being encountered by the modbusPSL service. The problem is that the /run/modbusPSL.pid file is not being generated by procServ, even though the -p flag controlling this is correctly set. I don't know the reason for this, but it was also a problem on c1vac and c1susaux. The solution is to remove the custom kill command (ExecStop=...) and just allow systemd to stop it via its default internal kill method.