Jenne made the 40m tour for the annual visit of 30-40 students.

c.f.

Tour 2009 http://nodus.ligo.caltech.edu:8080/40m/1717

Tour 2008 http://nodus.ligo.caltech.edu:8080/40m/737

No breakthroughs tonight. 

DRMI didn't want to lock with either the recipe that we used a year ago (elog 9116) or that was used in May (elog 9968).  Being lazy and sleepy, I chickened out and went back to PRFPMI locking. 

Many attempts, I'll highlight 2 here.

(1) I had done the CARM -> sqrtInvTrans transition, and reduced the CARM offset to arm powers of about 7, and lost lock.  I don't remember now if I was trying to transition DARM to AS55, or if I was just prepping (measuring error signal ratio and relative sign).

(2) I stopped the carm_cm_up script just before it wanted to do the CARM -> sqrtInvTrans transition, and stayed with CARM and DARM both on ALS.  I got to reasonably high powers, and was measuring the error signal ratios I needed for CARM -> REFL DC and DARM -> AS55.  Things were too noisy to get good coherence for the DARM coefficient, but I thought I was in good shape to transition CARM to REFL DC (which looks like REFL11I, since REFLDC goes to the CM board, and the OUT2 of that board is used to monitor the input to the board. )  Anyhow, I set the offset such that it matched my current CARM offset value, and started the transition, but lost lock about halfway through.  CARM started ringing up here, and I think that's what caused this lockloss.  Could have been the CARM peak, which I wasn't considering / remembering at the time.

Daytime activity for Thurs:  Lock DRMI, maybe first on 1f signals, but then also on 3f signals.

I was notified by Rob and Rana that there were many measurements of the MC abs length (i.e. modulation 
frequencies for the IFO.) between 2002 and now.

So, I dig the new and old e-logs and collected the measured values of the MC length, as shown below. 

I checked the presence of the vent for two big steps in the MC length. Each actually has a vent. 
The elog said that the tilt of the table was changed at the OMC installation in 2006 Oct.
It is told that the MC mirrors were moved a lot during the vent in 2007 Nov.

Note:
o The current modulation freq setting is the highest ever.
o Rob commented that the Marconi may drift in a long time.
o Apparently we need another measurement as we had the big earthquake.

My curiosity is now satified so far.

Local Time	3xFSR[MHz]	5xFSR[MHz]	MC round trip[m]	Measured by
----------------------------------------------------------------------------
2002/09/12	33.195400 	165.977000 	27.09343		Osamu
2002/10/16	33.194871 	165.974355 	27.09387		Osamu
2003/10/10	33.194929 	165.974645 	27.09382		Osamu
2004/12/14	33.194609 	165.973045 	27.09408		Osamu
2005/02/11	33.195123 	165.975615 	27.09366		Osamu
2005/02/14	33.195152 	165.975760 	27.09364		Osamu
2006/08/08	33.194700 	165.973500 	27.09401		Sam
2006/09/07	33.194490 	165.972450 	27.09418		Sam/Rana
2006/09/08	33.194550 	165.972750 	27.09413		Sam/Rana
----2006/10 VENT OMC installation	
2006/10/26	33.192985 	165.964925 	27.09541		Kirk/Sam
2006/10/27	33.192955 	165.964775 	27.09543		Kirk/Sam
2007/01/17	33.192833 	165.964165 	27.09553		Tobin/Kirk
2007/08/29	33.192120 	165.960600 	27.09611		Keita/Andrey/Rana
----2007/11 VENT Cleaning of the MC mirrors
2007/11/06	33.195439 	165.977195 	27.09340		Rob/Tobin
2008/07/29	33.196629 	165.983145 	27.09243		Rob/Yoichi

Koji and Manasa did some work on the PSL green situation today (Koji is still writing that log post up), but I just measured the Yarm out of loop sensitivity, and WOAH. 

The beat is -11.5dBm at 42.8 MHz.  Koji said the sweet spot is around 30 MHz.  The out of loop sensitivity is 400 Hz RMS!  Something to note is that the Y beatnote still has a 20dB amplifier before going to the beatbox, but the X does not.  We had been worried about saturation issues with the X, so we took out the amplifier.  However, I might put it back if we win big like this.

Recall from elog 10462 that I had saved a reference of the out of loop noise for both X and Y, but Y was much noisier than X.  The references below are from that elog, and the new Y is in dark blue. (Edit, 9:18pm, updated plot measuring down to 0.01Hz.  This is the new reference on the ALS_outOfLoop_Ref.xml template).

EDIT:  (Don't worry, I'm going to measure X too, but right now the beam overlap on the camera is not good, as if something drifted after Koji and Manasa closed up the PSL table)

Touched up the alignment for X on the PSL table.  Current beatnotes are:  [Y, -13.5 dBm, 74.1 MHz], [X, -22 dBm, 13.9 MHz].  Red is the current X out of loop, and I've saved it as the new X reference on the template.

I took a quick measurement of the ALS stability, using POX and POY as out of loop sensors, using a CARM calibration line to line POX and POY up to the calibrated PHASE_OUT channels at 503Hz. 

• X arm RMS ~1kHz
  • Could use more low frequency suppression
• Y arm RMS ~200Hz
  
  • 

If I understand correctly, the Mach-Zehnder readout port power is only a function of the differential phase accumulated between the two interfering light beams. In the homodyne setup, this phase difference can come about because of either fiber length change OR laser frequency change. We cannot directly separate the two effects. Can you help me understand what advantage, if any, the heterodyne setup offers in this regard? Or is the point of going to heterodyne mainly for the feedback control, as there is presumably some easy way to combine the I and Q outputs of the heterodyne measurement to always produce an error signal that is a linear function of the differential phase, as opposed to the sin^2 in the free-running homodyne setup? What is the scheme for doing this operation in a high bandwidth way (i.e. what is supposed to happen to the demodulated outputs in Attachment #3 of your elog)? What is the advantage of the heterodyne scheme over applying temperature feedback to the NPRO with 0.5 Hz tracking bandwidth so that we always stay in the linear regime of the homodyne readout?

Also, what is the functional form of the curve labelled "Theory" in Attachment #2? How did you convert from voltage units in Attachment #1 to frequency units in Attachment #2? Does it make sense that you're apparently measuring laser frequency noise above 10 Hz? i.e. where do the "Dark Current Noise" and "Shot Noise" traces for the experiment lie relative to the blue curve in Attachment #2? Can you point to where the data is stored, and also add a photo of the setup?

My understanding is that the main advantage in going to the heterodyne scheme is that we can extract the frequecy noise information without worrying about locking to the linear region of MZI. Arctan of the ratio of the inphase and quadrature component will give us phase as a function of time, with a frequency offset. We need to to correct for this frequency offset. Then the frequency noise can be deduced. But still the frequency noise value extracted would have the contribution from both the frequency noise of the laser as well as from fiber length fluctuation. I have not understood the method of giving temperature feedback to the NPRO.I would like to discuss the same.

The functional form used for the curve labeled as theory is 5x10⁴/f. The power spectral density (V²/Hz) of the the data in attachment #1 is found using the pwelch function in Matlab and square root of the same gives y axis in V/rtHz. From the experimental data, we get the value of V_max and V_min. To ride from V_max to V_min , the corrsponding phase change is pi. From this information, V/rad can be calculated. This value is then multiplied with 2*pi*time dealy to get the quantity in V/Hz. Dividing V/rtHz value with V/Hz value gives  y axis in Hz/rtHz. The calculated value of shot noise and dark current noise are way below (of the order of 10^-4 Hz/rtHz) in this frequency range. 

I forgor to take the picture of the setup at that time. Now Andrew has taken the fiber beam splitter back for his experiment. Attachment #1 shows the current view of the setup. The data from the previous trial is saved in /users/anjali/MZ/MZdata_20190417.hdf5

[Jenne, Kevin]

We opened up the MC chambers again, and successfully got the MC locked today!  Hooray!  This meant that we could start doing other stuff....

First, we clamped the Faraday.  I used the dog clamps that Zach left wrapped in foil on the clean cart.  I checked with a card, and we were still getting the 00 mode through, and I couldn't see any clipping.  2 thumbs up to that.

Then we removed the weight that was on the OMC table, in the way of where MMT2 needs to go.  We checked the alignment of the MC, and it still locks on TEM00, but the spot looks pretty high on MC2 (looking at the TV view). We're going to have to relevel the table when we've got the MMT2 optic in the correct place.

We were going to start moving the PZT steering mirror from the BS table to the IOO table, place MMT2 on the OMC table, and put in a flat mirror on the BS table to get the beam out to the BS oplev table, but Steve kicked us out of the chambers because the particle count got crazy high.  It was ~25,000 which is way too high to be working in the chambers (according to Steve).  So we closed up for the day, and we'll carry on tomorrow. 

Photos of the weight before we removed it from the OMC table, and a few pictures of the PZT connectors are on Picasa. 

Good! What was the key?

The MC2 spot looks very high, but don't believe the TV image. Believe the result of script/A2L/A2L_MC2. What you are looking at is the comparison of the spot at the front surface and the OSEMs behind the mirror.

[ericq, Gautam]

We gave DRFPMI locking a shot, with the ALS out-of-loop noises as attached. I figured the ALSX noise might be tolerable. 

After the usual alignment pains, we got to DRMI holding while buzzing around resonance. Recall that we have not locked since Koji's repair of the LO levels in the IMC loop, so the proper AO gains are a little up in the air right now. There were hopeful indications of arm powers stabilizing, but we were not able to make it stick yet. This is perhaps consistent with the ALSX noise making things harder, but not neccesarily impossible; we assuredly still want to fix the current situation but perhaps we can still lock.

On a brighter note, I've only noticed one brief EPICS freeze all night. In addition, the wall StripTools seem totally contiuous since ~4pm, whereas I'm used to seeing some blocky shapes particularly in the seismic rainbow. Could this possibly mean that the old WiFi router was somehow involved in all this? 

That's a good news. Only quantitative analysis will tell us if it is true or not.

Also we still want to analyze the traffic with the new switch.

I wired the six available BNC connectors on the front panel of the new XEND slow DAQ to physical Acromag channels. There were two unused ADC channels and eight DAC channels, of which I connected four. The following entries were added to /cvs/cds/caltech/target/c1auxex2/ETMXAUX2.db /caltech/target/c1auxex2/ETMXaux2.db

C1:Vac-CC1_HORNET_PRESSURE_VOLT is converted to the additional soft channel C1:Vac-CC1_HORNET_PRESSURE in units of torr using the conversion  stated in the manual. A quick check showed that the resulting number and the displayed pressure on the vacuum gauge itself agree to ~1e-8 torr. Gautam added the new EPICS calc channel to the C0EDCU and restarted FB, now the data is being recorded.

Three of the output channels do not have a purpose yet, so their epics records were created but remain inactive for the time being.

This is the new hot air station for the 40m lab.........

I've moved the OAF MC2 signal path to go directly from c1oaf to c1mcs, so that the LSC being ON/OFF doesn't interfere with the MC length seismic feedforward. Since the FB is currently down, I can't do a full test, but looking at monitor points in StripTool indicates it's working as intended. 

I also cleaned up some LSC medm stuff; exposing the existing SRCL UGF servo, and removing a misleading arrow. This reminds me that I need to get calibration lockins back up and running...

In prep to try some of these debugging steps, I did the following.

1. ndscope updated from 0.7.9 to 0.11.3 on rossa. I've been testing/assisting the development for a few months now and am happy with it, and like the new features (e.g. PDF export). v0.7.9 is still available on the system so we can revert whenever we want.
2. Arms locked on POX/POY, dither aligned to maximize TRX/TRY, normalization reset.
3. PRMI locked, dither aligned to maximize POPDC.
4. All vertex oplevs re-centered on their QPDs.

While working, I noticed that the annoying tip-tilt drift seems to be worse than it has been in the last few months. The IPPOS QPD is a good diagnostic to monitor stability of TT1/TT2. While trying to trend the data, I noticed that from ~31 Jan (Saturday night/Sunday morning local time), the IP-POS QPD segment data streams seem "frozen", see Attachment #1. This definitely predates the CDS crash on Feb 2. I confirmed that the beam was in fact incident on the IPPOS QPD, and at 1Y2/1Y3 that I was getting voltages going into the c1iscaux Acromag crate. All manner of soft reboots (eth1 network interface, modbusIOC service) didn't fix the problem, so I power cycled the acromag interface crate. This did the trick. I will take this opportunity to raise again the issue that we do not have a useful, reliable diagnsotic for the state of our Acromag systems. The problem seems to not have been with all the ADC cards inside the crate, as other slow ADC channels were reporting sensible numbers.

Anyways, now that the QPD is working again, you can see the drift in Attachment #2. I ran the dither alignment ~4 hours ago, and in the intervening time, the spot, which was previously centered on the AS camera CRT display, has almost drifted completely off (my rough calibration is that the spot has moved 5mm on the AS CCD camera). I was thinking we could try installing the two HAM-A coil drivers to control the TTs, this would allow us to rule out flaky electronics as the culprit, but I realize some custom cabling would be required, so maybe not worth the effort. The phenomenology of the drift make me suspect the electronics - hard for me to imagine that a mechanical creep would stop creeping after 3-4 hours? How would we explain the start of such a mechanical drift? On the other hand, the fact that the drift is almost solely in pitch lends support to the cause being mechanical. This would really hamper the locking efforts, the drift is on short enough timescales that I'd need to repeatedly go back and run the dither alignment between lock attempts - not the end of the world but costs ~5mins per lock attempt.

On to the actual tests: before testing the hardware, I locked the PRMI (no ETMs). In this configuration, I'm surprised to see that there is nearly perfect coherence between the MICH and PRCL error signals between 100Hz-1kHz 🤔 . When the AS55 demodulated signals are whitened prior to digitization (and then de-whitened digitally), the coherence structure changes. The electronics noise (measured with the PSL shutter closed) itself is uncorrelated (as it should be), and below the level of the two aforementioned spectra, so it is some actual signal I'm measuring there with the PRMI locked, and the coherence is on the light fields on the photodiode. So it would seem that I am just injecting a ton of AS55 sensing noise into the PRCL loop via the MICH->PRM LSC output matrix element. Weird. The light level on the AS55 photodiode has increased by ~2x after the September 2020 vent when we removed all the unused output optics and copper OMC. Nevertheless, the level isn't anywhere close to being high enough to saturate the ADC (confirmed by time domain signals in ndscope).

To get some insight into whether the whole RF system is messed up, I first locked the arm cavities with POX and POY as the error signals. Attachment #3 shows the spectra and coherence betweeen these two DoFs (and the dark noise levels for comparison). This is the kind of coherence profile I would expect - at frequencies where the loop gain isn't so high as to squish the cavity length noise (relative to laser frequency fluctuations), the coherence is high. Below 10 Hz, the coherence is lower than between 10-100 Hz because the OLG is high, and presumably, we are close to the sensing noise level. And above ~100 Hz, POX and POY photodiodes aren't sensing any actual relative frequency fluctuations between the arm length and laser frequency, so it's all just electronics noise, which should be incoherent.

The analogous plot for the PRMI lock is shown in Attachment #4. I guess this is telling me that the MICH sensing noise is getting injected into the PRCL error point between 100Hz-1kHz, where the REFL11 photodiode (=PRCL sensor) isn't dark noise limited, and so there is high coherence? I tuned the MICH-->PRM LSC output matrix element to minimize the height of a single frequency line driving the BS+PRM combo at ~313Hz in the PRCL error point. 

All the spectra are in-loop, the loop gain has not been undone to refer this to free-running noise. The OLGs themselves looked fine to me from the usual DTT swept sine measurements, with ~100 Hz UGF.

I'm curious to see if the demod phase for MICH in REFL & AS chamges between thi simple Mcihelson and PRMI. IF there's a change, it could point to a PRCL/f2 mismatch.

But I would still bet on demod chain funniness.

1. Beam pointing into PMC was tweaked to improve transmission.
2. AS110 photodiode was re-installed on the AS table - I picked off 30% of the light going to the AS WFS using a beamsplitter and put it on the AS110 photodiode.
3. Adjusted ASDC whitening gain - we have been running nominally with +18dB, but after Sept 2020 vent, there is ~x3 amount of light incident on the AS55 RFPD (from which the ASDC signal is derived). I want to run the dither alignment servos that use this PD using the same settings as before, hence this adjustment.
4. Adjusted digital demod phases of POP22, POP110 and AS110 signals with the PRMI locked (sideband resonant). I want these to be useful to debug the PRMI. the phases were adjusted so that AS110_Q, POP22_I and POP110_I contain the signal (= sideband buildup) when the PRMI is locked.
5. Ran the actuator calibration routine for BS, ITMX and ITMY - i'll try and do the PRM and ETMs as well later.
6. With the PRMI locked (sidebands resonant), looked at the sideband power buildup. POP22 and POP110 remain stable, but there is some low frequency variation in the AS110_Q channel (but not the I channel, so this is really a time varying transmission of the f2 sideband to the dark port). What's that about? Also unsure about those abrupt jumps in the POP22/POP110 signals, see Attachment #1 (admittedly these are slow channels). I don't see any correlation in the MICH control signal.
7. Measured the loop shapes of the MICH (UGF ~90 degrees, PM~30 degrees) and PRCL (UGF~110 Hz, PM~30 degreees) loops - stability margins and loop UGFs seem reasonable to me.
8. Tried nulling the MICH-->PRCL coupling by adjusting the MICH-->PRM matrix element - as has been the case for a while, unable to do any better, and I can't null that line as we expect to be able to.
9. Not expecting to get anything sensible, but ran some sensing matrix lines (at the correct frequencies this time).
10. Tried locking the PRMI with MICH actuation to an ITM instead of the BS - I can realize the lock but the loop OLTF I measure with this configuration is very weird, needs more investigation. I may look into this later today evening.

I was also reminded today of the poor reliability of the LSC whitening electronics. Basically, there may be hidden saturations in all the channels that have a large DC value (e.g. the photodiode DC mon channels) due to the poor design of the cascaded gain stages. I was thinking about using the REFL DC channel to estimate the mode-matching into the PRC, but this has a couple of problems. Electronically, there may be some signal distortion due to the aforementioned problem. But in addition, optically, the estimation of mode-matching into the PRC by comparing REFL DC levels in single bounce off the PRM and the PRMI locked has the problem that the mode-matching is degenerate with the intra-cavity loss, which is of the same order as the mode mismatch (a percent or two I claiM). If Koji or someone else can implement the fix suggested by Hartmut for all the LSC whitening channels, that'd give us more faith in the signals. It may be less work than just replacing all the whitening filters with a better design (e.g. the aLIGO ISC whitening filter which implements the cascaded gain stages using single OP27s and more importantly has a 1 kohm series resistance with the input to the op amp (so the preceeding stage never has to drive > 10V/1kohms ~10mA of DC current) would presumably reduce distortion.

[Paco, Deeksha, rana]

Quick elog for this evening:

• Rana disabled MC servo .
• Slow loop also got disengaged.
• AUX PSL beatnote is best taken with *free running lasers* since their relative frequency fluctuations are lowest than when locked to cavities.
• DFD may be better to get PZT transfer funcs, or get higher bandwidth phase meter.
• Multi instrument to be done with updated moku
• Deeksha will take care of updated moku

https://nodus.ligo.caltech.edu:30889/gw.swf

Problem:

Long before Yuta came along and deleted daqd, I had done something to prevent the framebuilder code from running at all.

Cause:

Alex pointed out via e-mail that the corresponded to the inability to access certain frame files due to their permissions being only for root. 

Turns out when I had run the code under the inittab, I forgot to make it use controls, instead of root (which is the default).  This later on caused problems for the code when it tried to access those files, resulting in the wierd errors we saw.

Solution:

Use chown to change the offending frame files back to controls.

Future:

Write a proper inittab script which uses "su controls" before running the daqd code.

 http://youtu.be/pEd7ru24Vx0

 B grade Nobel is awarded.

                                  If cables could dream?

This skill should be  mandatory for LIGOX graduates.

The Elog started crashing last night. It turns out I was the culprit, and whenever I tried to upload a certain 500kb .png picture, it would die. It has happened both when choosing "upload" of a picture, and when choosing "submit" after successfully uploading a picture. Both culprits were ~500kb .png files.

One terrible concern of mine is that the slow machines were rebooted at the power interruption.
Based on the elog entries, I assume they have not been burtrestored...

If this is true, they may cause some weird behaviors of the PSL/IOO electronics.

 Do you know how to burtrestore or restart slow machines?

Edit by Den: I did burtrestore of c1psl.snap from 2 days ago. Still slow machines behave not normal. For example, if I sweep C1:PSL-FSS_SLOWDC, SLOW monitor value does not change.

 Problems with Slow Machines?

Read ELOG

Medium.

Previous elog entries on this:

• The situation in 2014 w/ Diego Nov-2014
• Nic Smith, Andres, and Rana have a trialogue on the IMC WFS optical gain situation (Aug-2014)
• Rana comments on MC WFS demod board in 2011.

 When the IMC locks, we want the FAST OUT of the TTFSS box to be close to zero volts. We also want the control signal from the MC Servo board to be close to 0 V. How to set this up?

With the IMC locked, we just servo the FSS input offset to minimize the MC board output :

ezcaservo -r C1:IOO-MC_FAST_MON -g 0.1 -t 10 C1:PSL-FSS_INOFFSET

I would have used "CDSUTILS", but that seems to have some sort of ridiculous bug where we can't have prefixes on channel names, even on the command line. 

I was told that, as of last weekend, we now have the capability to save full data for a month, whereas before it was something like 3 days. However, my attempts to get the data from the accidentally-shorted EW2 channel in the Guralp box have all been epic failures. My other data is okay, despite my not saving it for several days after it was recorded. So, my question is, how long can the data actually be saved, and when did the saving capability change?

Clean cabinet S15 doors were left open. You have to lock it up!

This BNC cable is crying for help. Please do not do this to me.  It should be reported  to the  abused center.Throw this cable into the garbage now.

Koji could pull out easily 11 of the wires  from their socket.

Herein, I will describe the current settings and procedures used to achieve the DRFPMI lock, cobbled together from scripts, burts and such. 

Initial Alignment

1. With arms POX/POY locked, run dither alignment servos. Set transmon QPD offsets here
2. Restore "PRMI Carrier" configuration, run BS and PRM dither alignment servos simultaneously. (Note: this sacrifices some X arm alignment for better dark port alignment. In practice no appreciable loss of TRX is observed)
3. Misalign PRM, align SRM and tune SRM alignment by eye while looking at AS camera. 
4. Restore POX/POY arm lock, lock green to arms, check that powers are high enough and align if neccesary.

Initial Configuration

CARM, DARM

For CARM and DARM, the A channels are used for the ALS signals, whereas the B channels are used for blending the RF signals. 

ALS

• BEATX and BEATY, I and Q channels: +0dB Whitening Gain, Whitening Filters ON
• Green beatnotes somewhere between 20-80MHz, following sign convention of temperature slider UP makes beat freq go UP.  Check spectrum of PHASE_OUT_HZ vs references in ALS_outOfLoop_Ref.xml. The locking script automatically sets the correct phase tracker gain, so no need to adjust manually.
• CARM_A = -1.0 x ALSX + 1.0 x ALSY, G=1.0
• DARM_A = 1.0 x ALSX + 1.0 x ALSY, G=1.0

RF

• CM Board: REFL11 I daugher board output -> IN1, IN1 Enabled, -32dB input gain, 0.0V offset, all boosts off, AO polarity positive, AO gain +0dB
• MC Board: IN2 disabled, -32dB input gain
• CM_SLOW: +0dB Whitening Gain, Whitening ON, LSC-CM_SLOW_GAIN = -5e-4 (Though, it would be good to reallocate this gain to the input matrix element)
• CARM_B = 1.0 x CM_SLOW, FM4 FM10 ON, G=0 (FM4 = LP700 for AO crossover stability, FM10 = 120:5k for coupled cavity pole compensation)
• AS55: +9dB Whitening Gain, Whitening filters manual, Demod angle -37.0
• DARM_B = -1e-4 x AS55 Q, G=0

DRMI 3F

For the DRMI, the A channels are used for the 1F signals, whereas the B channels are used for the 3F signals. The settings for transitioning to 1F after locking the DRFPMI have not yet been determined. 

These settings are currently saved in the DRMI configurator, but the demod angles are set for DRFPMI lock, so the settings don't reliably work for misaligned arms. 

• REFL33: +30dB Whitening Gain, Whitening filters trigger on DRMI lock, Demod angle: 136.0
• REFL165: +24dB Whitening Gain, Whitening filters trigger on DRMI lock, Demod angle: -111.0
• POP22: +15dB Whitening Gain, Whitening filters OFF, Demod angle: -114.0
• AS110: +36dB Whitening Gain, Whitening filters OFF, Demod angle: -116.0
• POPDC: +0dB Whitening Gain, Whitening filters OFF (used as a supplemental trigger signal when CARM and DARM are buzzing and POP22 fluctuates wildly)
• MICH_B = 6.0 x REFL165Q, offset = 15.0
• PRCL_B = 5.0 x REFL33I, offset = 45.0
• SRCL_B = -0.6 x REFL165I + 0.24 x REFL33 I, offset=0

The REFL33 element in SRCL_B is to reduce the PRCL coupling, was found empirically by tuning the relative gains with the arms misaligned and looking at excitation line heights. The offsets were found by locking the DRMI on 1F signals with arms misaligned, and taking the average value of these 3F error signals.  

Servo filter configuration

The CARM and DARM ALS settings are largely scripted by scripts/ALS/Transition_IR_ALS.py, which takes you from arms POX/POY locked to CARM and DARM ALS locked. The DRMI settings are usually restored from the IFO_CONFIGURE screen. 

• CARM: FM[1, 2, 3, 5, 6] , G=4.5, Trigger forced on, no FM triggers, output limit 8k
• DARM: FM[1, 2, 3, 5, 6] , G=4.5, Trigger forced on, no FM triggers, output limit 8k
• MICH: FM[4, 5], G= -0.03, Trigger POP22 I x 1.0 [50, 10], FM[2, 3, 7] triggered [50, 10], output limit 20k
• PRCL: FM[4, 5], G= -0.003, Trigger POP22 I x 1.0 [50, 10], FM[1, 2, 8, 9] triggered [50, 10], output limit 8k
• SRCL: FM[4, 5], G= -0.4, Trigger AS110 Q x 1.0 [500, 100], FM[2, 7, 9] triggered [500, 100], output limit 15k

Actuation Output matrix

• MC2 = -1.0 x CARM
• ETMX = -1.0 x DARM
• ETMY = 1.0 x DARM
• BS = 0.5 x MICH
• PRM = 1.0 x PRCL - 0.2655 MICH
• SRM = 1.0 x SRCL + 0.25 MICH (The mich compensation is very roughly estimated)

Locking Procedure

When arms are POX/POY locked, and the green beatnotes are appropriately configured, calling scripts/DRFPMI/carm_cm_up.sh initiates the following sequence of events:

• Turn ON MC length feedforward and PRC angle feedforward
• Set ALS phase tracker UGFs by looking at I and Q magnitudes
• Set LSC-ALSX and LSC-ALSY offsets by averaging, ramp CARM+DARM gains up, XARM+YARM gains down, engage CARM+DARM boosts, now ALS locked
• Move CARM away from resonance, offset = -4.0 (DRMI locks quicker on this side for whatever reason)
• Restore PRM, SRM alignment. Set DRMI A FM gains to 0, B FM gains to 1.0. Enable LSC outputs for BS, PRM, SRM
• When DRMI has locked, add POPDC trigger elements to DRMI signals and transition SRCL triggering to POP22I. NB: In the c1lsc model, the POPDC signal incident on the trigger matrix has an abs() operator applied to it first. 
  • MICH Trig = 1.0 x POP22 I + 0.5 x POPDC, [50, 10]
  • PRCL Trig = 1.0 x POP22 I + 0.5 x POPDC, [50, 10]
  • SRCL Trig = 10.0 x POP22 I + 5 x POPDC, [500, 100]
• Reduce POX, POY whitening gains from their nominal +45dB to +0dB, so there aren't railing channels making noise in the whitening chassis and ADCs
• DC couple ITM oplevs (average spot position, set FM offset, turn on DC boost filter, let settle)
• With an 8 second ramp, reduce CARM offset to 0 counts. 
• MANUALLY adjust CARM_A and DARM_A offsets to where CARM_B_IN and DARM_B_IN are seen to fluctuate symetrically around their zero crossing.
  • Note: Last week, this adjustment tended to be roughly the same from lock to lock, unlike the PRFPMI which generally didn't need much adjustment. Also, by jumping from CARM offset of -0.4 to 0.4, it could be seen that the zero crossing in  CARM_B aka CM_SLOW aka REFL11 had some offset, so CARM_B_OFFSET was set to 0.005, but this may change. 

When CARM and DARM are buzzing around true zero, powers maximized:

• CARM and DARM FM1 (18,18:1,1 boosts) OFF
• CARM_B_GAIN 0.0 -> 1.0, FM7 ON (20:0 boost)
• DARM_B_GAIN 0.0 -> 0.015, FM7 ON (20:0 boost) 
• MC servo board IN2 ENABLE, IN2 gain -32dB -> -16dB
• Turn ALL MC2 violin filters OFF (smoothen out AO crossover)
• If stable, CM board IN1 gain -32dB -> -10dB (This is the overall CARM gain, the arm powers stabilize within the last few dB of this transition)
• CARM_A_GAIN 1.0 -> 0.7
• CARM_A FM9 ON (LP1k), sleep, FM 1 ON (1:20 deboost), sleep, FM 2 ON (1:20 deboost), HOLD OUPUT, CARM now RF only
• DARM_B_GAIN 0.015 -> 0.02, sleep, DARM_A_GAIN 1.0 -> 0.0 (This may not be the ideal final DARM_B gain, UGF hasn't been checked yet)

IFO is now RF only!

• Turn on transmon QPD servos.
• Adjust comm/diff QPD servo offsets to correct any problems evident on AS/REFL cameras. This usually brings powers from ~100-120 to ~130-140. 

This is as far as we've taken the DRFPMI so far, but the CARM bandwidth is still only at a few kHz. Based on PRFPMI locking, the next steps will be:

• CM BOARD +12dB or so additional IN1 gain, more AO gain may be needed to get crossover to final position of ~100Hz
• MC2 viollin filters back on
• CM boost(s) on
• AS55 whitening on
• Transition DRMI to 1F

Need to measure the length of the cable, but too lazy to use a measuring tape?

Then you too can become an expert cable length measurer by just using an RF signal generator and a scope:

1. Disconnect or short (not 50 Ohm term) the far side of the cable.
2. Put a T on the near side of the cable.
3. Drive the input of the T with your signal source.
4. Look at the output of the T with the scope while sweeping the signal source's frequency knob.

The T is kind of acting like a beamsplitter in an asymmetric length Michelson in this case. Just as we can use the RF phase shift between the arms to measure the Schnupp asymmetry, we can also use a T to measure the cable length. The speed of light in the cable is documented in the cable catalog, but in most cases its just 66% of the speed of light in the vacuum.

[Jenne, Sanjit]

We would like several channels from the OAF/ASS screen to be saved to frames, so that we can use the channels for our OAF model.  In theory, this should involve uncommenting the desired channels in the .ini file (.../caltech/chans/daq/C1ASS.ini), and restart the frame builder.  Since this .ini file was generated a long time ago, and things have been changed since then, the chnnums in the .ini file and the corresponding .par file don't match up.  We need to go through the .par file (/cvs/cds/gds/param/tpchn_c3.par), and look up the chnnums for our channels, and copy those numbers into the .ini file.  Figuring out what was going on involved many fb40m restarts, but on the last one of the night, I restarted the backup script, so it should (hopefully) run tonight, and get all of the frames that we've been missing.

Notes to self: 

*  When adding channels to other front ends, the end of the process is to click the blue button on the C0DAQ_DETAIL screen next to your computer.  C1ASS isn't on that screen.  Instead, in the C1ASS_GDS screen, click DAQ Reload.

*  The channel names for the Test Points and the .ini files must be different.  That's why there's a '_2048' suffix at the end of every channel in our .ini file.

*  tpchn_C1 is all of the old-style system test points.  tpchn_C2 is the C1OMC, and tpchn_C3 is for the C1ASS testpoints.

*  When uncommenting channels in the C1ASS.ini file, make sure acquire is set to 1 for every channel we want saved.  The default in this .ini file is set to acquire = 0.

The OMC input optics layout is attached

Checked the spot position on OMMT-FM1. It was off from the center. This was causing the spot on OMMT1 off-center. This was fixed by the steering mirror for the AUX laser.

The beam alignment onto the OMC was tweaked with OMC-SM1 and OMC-SM2. This was the painful part. We had to make a sensor card that could get in to the narrow space of the OMC. (Attachment 2 right)

Attachment 2 left shows the naming convention of the OMC mirrors.

For the alignment, we gave 5Vpp trig waves at 3.1Hz to the input of the PZT amp so that the cavity is kept scanned continuously. Firstly check the rough spot positions for OMC-CM1 and OMC-CM2. If you carefully use the card, you can check if the beam is returning to OMC-IC. This return beam should have roughtly same hight as the incident beam. This can be adjusted by either of the steering mirrors.

Once the beam is going around the mirrors multiple times, the spot alignment can be checked at OMC-CM1. Bring a card right in front of CM1. If the card is lifter slightly above the incident spot, this automatically allows for the outgoing beam to go through. Depending on the pitch alignment, the next roundtrip (1RT) will be seen on the card. As you lift the card up more, you will be able to see more round trip beams (e.g. 2RT, 3RT, in the figure). If the yaw alignment is perfect, these spots would be lined up vertically. So you can try to align the horizontal direction with the steering mirrors. Then the vertical alignment can be done with the pitch knobs.

At this point you should be able to see some super high-order transmission at the OMC trans. For today, we stopped here as we already ran out of the knob ranges at multiple knobs. This is because the beam height in the mode matching telescope was not right, and the steering mirrors had to work more than their range.

Differential misalignment of the OMCs

40m BHD will employ two OMCs on the BHD platform. We will have two SOSs for each of the LO and AS beams. The challenge here is that the input beam must optimally couple to the OMCs simultaneously. This is not easy as we won't have independent actuators for each OMC. e.g. The alignment of the LO beam can be optimally adjusted to the OMC1, but this, in general, does not mean the beam is optimally aligned to the OMC2.

Requirement

When a beam with the matched mode to an optical cavity has a misalignment, the power coupling C can be reduced from the unity as

where is the waist radius, is the divergence angle defined as , and are the beam lateral translation and rotation at the waist position.

The waist size of the OMC is 500um. Therefore = 500um and = 0.68 mrad. If we require C to be better than 0.995 according to the design requirement document (T1900761). This corresponds to (only) to be 35um and (only) to be 48urad. These numbers are quite tough to be realized without post-installation adjustment. Moreover, the OMCs themselves have individual differences in the beam axis. So no matter how we set the mechanical precision of the OMC installation, we will introduce a maximum of 1mm and ~5mrad uncertainty of the optical axis.

Adjustment

Suppose we adjust the incident beam to the OMC placed at the transmission side of the BHD BS. The reflected beam at the BS can be steered by picomotors. The distance from the BS to the OMC waist is 12.7" (322mm) according to the drawing.
So we can absorb the misalignment mode of (, ) = (0.322 , ). This is a bit unfortunate. 0.322m is about 1/2 of the rayleigh range. Therefore, this actuation is still angle-dominated but a bit of translation is still coupled.

If we enable to use the third picomotor on the BHD BS mount, we can introduce the translation of the beam in the horiz direction. This is not too huge therefore we still want to prepare the method to align the OMC in the horiz direction.

The difficult problem is the vertical alignment. This requires the vertical displacement of the OMC. And we will not have the option to lower the OMC. Therefore if the OMC2 is too high, we have to raise the OMC1 so that the resulting beam is aligned to the OMC2. i.e. we need to maintain the method to raise both OMCs. (... or swap the OMCs). From the images of the OMC beam spots, we'll probably be able to analyze the intracavity axes of the OMCs. So we can always place the OMC with a higher optical axis at the transmission side of the BHD BS.

How to calculate the accumulated round-trip Gouy phase (and namely the transverse mode spacing) of a general cavity
only from the round-trip ABCD matrix

T1300189

Article from EE Times, describing why metal foil (NOT metal film) resistors are really better than wirewound when it comes to everything except high power dissipation.

Need to do some diggin to see if we can find ~1k metal foil resistors which can handle ~1W of heat.

Steve: here it is

scp Particle.st username@lhocds.ligo-wa.caltech.edu:/cvs/cds/lho/target/t0sandbox0

ssh username@lhocds.ligo-wa.caltech.edu

ssh ops@control0

cd /cvs/cds/lho/target/t0sandbox0

setup epics

make Particle.o

scp Particle.o controls@nodus.ligo.caltech.edu:/cvs/cds/caltech/target/c1psl/

In order to do online static IIR Wiener filtering one needs to do the following,

1) Get data for FIR Wiener filter witnesses and target.

2) Measure the transfer function (needs to be highly coherent, ~ 0.95 for all points) from the actuactor to the control signal of interest (ie. from MC2_OUT to MC_L).

3) Invert the actuator transfer function.

4) Use Vectfit or (LISO) to find a ZPK model for the actuator transfer and inverse transfer functions.

5) Prefilter your witness data with the actuator transfer function, to take into account the actuator to control transfer function when designing the offline Wiener FIR filter.

6) Calculate the frequency response for each witness from the FIR coefficients.

7) Vectfit the frequency reponses to a ZPK model, this is the FIR to IIR Wiener conversion step.

8) Now, either, divide the IIR transfer function by the actuator transfer function or more preferably, multiply by the inverse transfer function.

9) Use Quack to make SOS model of the IIR Wiener filter and inverse transfer function product that goes into foton for online implementation.

10) Load it into the system.

The block diagram below summarizes the steps above.

How to get your own web page running on Nodus

1. On any martian machine, put your stuff in /users/public_html/$MYPAGE/
2. On Nodus, run: ln -s /users/public_html/$MYPAGE /export/home/
3. Your site is now available at https://nodus.ligo.caltech.edu:30889/$MYPAGE/
4. If you want to allow straight up directory listing to the entire internet, on Nodus run: sudoedit /etc/sites-available/nodus, and add the following lines towards the bottom:

LLO Operator Tips:

koji.arai@cr9:/opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignment$ cat autostart_strips.sh 
 

#!/bin/bash

# Baffle window setup 1500x480

StripTool -xrm 'StripTool.StripGraph.geometry:1500x470+0+24' /opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignment/baffle_pd.stp &
sleep 1

# DC signals setup

StripTool -xrm 'StripTool.StripGraph.geometry:1500x470+0+470' /opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignment/dc_signals.stp &
sleep 1

# WFS prx mich sry setup

StripTool -xrm 'StripTool.StripGraph.geometry:1500x470+0-24' /opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignment/wfs_prx_mich_sry.stp &
sleep 1

exit

Awhile ago I wrote several scripts for reading in medm screen matrix settings and then writing them out.  It was meant as kind of a mini-burt just for matrices for switching between a couple of different setups quickly.

Yuta has expressed interest in having this instruction available.

In /cvs/cds/caltech/scripts/matrix/ there are 4 python scripts:

saveMatrix.py, oldSaveMatrix.py, loadMatrix.py, oldLoadMatrix.py

The saveMatrix.py and loadMatrix.py are for use with the current front end codes (which start counting from 1), where as the old*.py files are for the old system.

To use saveMatrix.py you need to specify the number of inputs, outputs, and the base name of the matrix (i.e. C1:LSP-DOF2PD_MTRX is the base of C1:LSP-DOF2PD_MTRX_0_0_GAIN for example), as well as an ouptut file where the values are stored.

So to save the BS in_matrix setting you could do (from /cvs/cds/caltech/scripts/matrix/)

./saveMatrix.py -i 4 -o 5 -n "C1:SUS-BS_TO_COIL_MTRX" -f -d ./to_coil_mtrx.txt

The -i 4 indicates 4 inputs, the -o 5 indicates 5 outputs, -n "blah blah" indicates the base channel name, -f indicates a matrix bank of filters (if its just a normal matrix with no filters, drop the -f flag), and -d ./to_coil_mtrx.txt indicates the destination file.

To write the matrix, you do virtually the same thing:

./loadMatrix.py -n "C1:SUS-PRM_TO_COIL_MTRX" -f -d ./to_coil_mtrx.txt

In this case, you're writing the saved values of the BS, to the PRM.  This method might be faster if you're trying to fill in a bunch of new matrices that are identical rather than typing 1's and -1's 20 times for each matrix.

I'll have Yuta add his how-to of this to the wiki.

Let me remind you how to lock and align the IMC

To lock

1. Open the doors for the IMC/OMC chambers. Open the manual shutter of the PSL just in front of the optical window

2. Run scripts/MC/mcloopson

3. Set the MC length path gain 0.3 / Set the MC total gain "+20"

4. If you want to avoid excitation of the mirrors by air turbulence, put a big plastic film and put three posters on the top and both the sides on the floor to block the wind go into the chamber.

To shut down

1. Run scripts/MC/mcloopsoff

2. Close the manual shutter, Remove the wind blockers, and the light door of the chambers

To align the MC

1. Tweak MC2 and MC3 to get maximum transmittion and/or minimum reflection.