40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 122 of 344 Not logged in
ID Date Author Type Category Subject
15491   Fri Jul 17 00:18:13 2020 gautamUpdateGeneralLocking updat
1. I found that an EPICS channel wasn't reset to the correct value by burtrestore after the FE bootfest yesterday.
• This cost me the whole of last night, found it finally tonight.
• I'll try and modify the locking scripts to better capture such errors, but ideally, we should just use Guardian or something since it's made for this purpose already.
• Anyways, tonight I was able to re-acquire the PRFPMI lock in a completely scripted way.
2. Locking CARM on POX remains out of reach.
• I think this has to do with the fact that the zero-crossing of the CARM and REFL error signals are dependent on the 3f PRCL/MICH error point offsets.
• So even if the DC gain is right, the fact that we use POX for the digital AO path and REFL for the analog AO path is leading to some conflict I think.
• Ran out of energy tonight, I'll try again tomorrow.

The DQ channels of the ETM coils were active tonight, so I'll make the coil driver actuation budget over the next couple of days.

1399   Fri Mar 13 05:16:21 2009 YoichiUpdateLockingLocking update
Yoichi, Osamu,

With adjustments of the loop gains during the CARM offset reduction, the IFO reaches arm_power = 25 sort of robustly unless the 3.8kHz oscillation rings up.
At arm_power = 25, the CARM and DARM start to oscillate at around 400Hz. Probably I need more gain tweaks.
Annoying thing is that the 3.8kHz oscillation sometimes rings up suddenly and kills the lock.
This can happen anywhere above arm_power = 6 or so.
Because of a strange structure in the CARM loop gain around 3.8kHz, we cannot increase the CARM UGF beyond 1kHz.
The attached plots are the AO path open loop transfer function (attm2 is the zoom of attm1) measured at arm_power = 13.

Tomorrow, I will lock the X-arm and measure the transfer function from the AO path input to the X-arm error signal to see
if there is the same structure at 3.8kHz (X-arm error signal has the 3.8kHz peak).
Attachment 1: AOTF2.png
Attachment 2: AOTF2-zoom.png
10814   Thu Dec 18 02:23:34 2014 ericqUpdateLSCLocking update

[ericq, Diego]

Some locking efforts tonight; many locklosses due to PRC angular motion. Furthest progress was arm powers of 15, and I've stared at the corresponding lockloss plot, with little insight into what went wrong. (BTW, lastlock.sh seems to catch the lock loss reliably in the window)

CARM and DARM loops were measured not long before this lock loss, and had nominal UGFs (~120Hz, ~20deg PM). However, there was a reasonably clear 01 mode shape at the AS camera, which I did nothing to correct. Here's a spectrum from *just* before the lockloss, recovered via nds. Nothing stands out to me, other than a possible loss of DARM optical gain. (I believe the references are the error signal spectra taken in ALS arms held away + PRMI on 3F configuration)

The shape in the DARM OLTF that we had previously observed and hypothesized as possible DARM optical spring was not ever observed tonight. I didn't induce a DARM offset to try and look for it either, though.

Looking into some of the times when I was measuring OLTFs, the AS55 signals do show coherence with the live DARM error signal at the excitation frequencies, but little to no coherence under 30Hz, which probably means we weren't close enough to swap DARM error signals yet. This arm power regime is where the AS55 sign flip has been modeled to be...

A fair amount of time was spent in pre-locking prep, including:

• The usual X green beat alignment tweak, to make the X ALS control not terrible
• Both ITM oplevs were centered
• For some reason, I had to flip the signs of the REFL165 matrix elements for the PRMI...
• "Restore PRMI SB" has ASC automatically enabled, which results in unexpected kicks even with LSC off, which caused a few minutes head-scratching
14983   Tue Oct 22 00:52:27 2019 gautamUpdateLSCLocking updates
1. Transition of arms from POX/POY to CARM/DARM was much smoother today - a change was made at the EX PDH setup, see here.
2. Reliable settings for 3f locking with arms held off resonance seem to have been found.
3. Took sensing matrix in this condition, measured loop TFs.
4. Reduced CARM offset - reached arm powers ~50 at which point the PRMI lost lock. Reacquisition was quick though.
• The POP22_I level seemed to decay as I reduced the CARM offset.
• This would suggest that somehow the PRCL lock point is getting shifted as I reduce the CARM offset.
• Tonight, I will investigate this more.
Attachment 1: PRMI3f_ALS_Oct21sensMat.pdf
15014   Wed Nov 6 02:08:48 2019 gautamUpdateLSCLocking updates

Summary:

There seems to be stronger-than-expected coupling between CARM and the 3f sensors.

Details:

Full analysis tomorrow, but I collected sensing matrix measurements with lines driven in PRCL,MICH and CARM at a couple of CARM offsets. I also wanted to calibrate the CARM offset to physical units so I ran some scans of the CARM offset and collected the data so I can use the arm cavity FSR to calibrate CARM. Koji suggested using REFL165_I for PRCL and REFL165_Q for MICH control - this would allow us to see if the problem was with the 1f sideband only. While the lock could be established, we still couldn't push the arm powers above 10 without breaking the PRMI lock. While changing the CARM offset, we saw a significant shift in the DC offset level of the out-of-loop REFL33_I signal. Need to think about what this means...

15185   Tue Feb 4 02:13:02 2020 gautamUpdateLSCLocking updates

Summary:

The CARM-->RF transition remains out of reach. No systematic diagnosis scheme comes to mind.

Details:

• Config is PRFPMI, SRM is misaligned macroscopically.
• PRMI can easily be locked with 3f signals while CARM is offset from resonance. Aided by DAFI, I turned on the PR violin filter in the BS output section to prevent it from ringing up, making the lock much more robust.
• When the CARM offset is reduced
• POP22 level dips and sometimes goes negative - i don't see this in my simple simulations. POP22 is the trigger signal for MICH/PRCL loops, so to prevent the PRMI lockloss, I mix in some POPDC into the trigger matrix element.
• Once the circulating power exceeds ~10, the ALS noise apparently increases.
• The arms "buzz" through resonance, but the power fluctuation is nearly 0-200 in TRX/TRY, corresponding to several CARM linewidths, but all the out-of-loop ALS noise measurements have me believe that we are close to the CARM linewidth in noise. So we should only see ~factor of 2 fluctuation in power.
• The RF error signal for CARM (=REFL 11) doesn't show any features that i can use to aid the transition / diagnose what is going on systematically.
• Koji suggested changing the actuation for CARM from MC2 to the ETMs, and check if the MC OSEMs witness the excess motion at small CARM offsets
• The ALS transition is scripted, so I had to make a modified version that accommodates this changed actuation scheme.
• The usual CARM-->MC2 matrix element is -1.
• The frequency actuation strength of MC2 is ~3x that of the ETMs. Additionally, ETMX has 5x the series resistance of ETMY. So I used the output matrix elements shown in Attachment #1 so as to get the same loop UGF with the same loop gains elsewhere in the chain. Confirmed the actuation strength is the same using the sensing matrix infrastructure and comparing line heights.
• Attachment #2 shows the measured UGF - both CARM and DARM look okay to me.
• With this new ALS output matrix actuation scheme, I was able to make it to PRMI + arms on zero offset a couple of times tonight, but the drifting input alignment makes the PRMI lock not so robust anymore.

TBC. Mercifully at least the shaker stayed still tonight.

Attachment 1: modifiedOutMat.png
Attachment 2: OLTFs.pdf
15192   Thu Feb 6 01:25:50 2020 gautamUpdateLSCLocking updates

Summary:

I managed to partially stabilize the arm citculating powers - they stay in a region in which the REFL 11 signal is hopefully approximately linear and so I can now measure some loop TFs and tweak the transition appropriately.

Procedure:

The main change I made tonight was to look at the REFL11 signal as I swept the ALS CARM offset through 0. I found that the maximum arm powers coincided with a non-zero REFL11 signal value (i.e. a small CARM offset was required at the input to the CARM_B filter bank). Not so long ago, I had measured the PM/AM ratio for 11 MHz to be ~10^5 - so it's not entirely clear to me where this offset is coming from. Then, I was able to turn on the integrator (z:p = 20:0) in the CARM_B filter bank while maintaining high POP_DC. At this point, I ramped up the IN2 gain on the IMC servo board (= AO path), and was able to further stabilize the power.

Attachment #shows this sequence from earlier in the evening. Note that in this state, both ALS and IR control of CARM is in effect. The circulating power is fluctuating wildly - partly this is probably the noisy ALS control path, but there is also the issue of the (lack of) angular control - although looking at the transmon QPDs and the POP QPD signals, they seem pretty stable.

The next step will be to try and turn off the ALS control path. Eventually, I hope to transition DARM control to AS55 as well. But at this point, I can at least begin to make sense of some of the time series signals, and get some insight into how to improve the lock.

 Quote: No systematic diagnosis scheme comes to mind.
Attachment 1: semiStableArms.png
Attachment 2: armAngStability.png
15278   Tue Mar 17 01:22:03 2020 gautamUpdateLSCLocking updates

Summary:

No real progress tonight - I made it a bunch of times to the point where CARM was RF only, but I never got to run a measurement to determine what the DARM_B loop gain should be to make the control fully RF.

Details:

• Touched up PMC alignment.
• There were very few BNC cables available at the rack near SW corner of the PSL table - the short BNC cables are NOT meant to be daisy chained to make long cables to run along the arm, I removed all those.
• Restored SR785 at LSC rack for CARM TF measurements.
• I was able to get the CARM UGF ~5 kHz, but everytime I was trying to run a DTT swept sine to measure the ratio of DARM_B_IN1 / DARM_A_IN1, the lock was lost - not sure if this is because of the excitation injected or something else.
• I'll probably give this another shot Wednesday eve.
373   Thu Mar 13 02:52:06 2008 LisaConfigurationLSCLocking with 3f
Today we have tried to use the reflected signal demodulated at 3*f1 ~ 99 MHz (REFL31) for length control.
This signal is cool because it is generated by the beating of sidebands, so it is not very sensitive to what the carrier does inside the IFO.
In particular, its gain and the demodulation phase shouldn't change much while changing the CARM offset during the locking sequence.
The idea is therefore to use REFL31_I and REFL31_Q for controlling MICH and PRCL, with the goal of making the lock acquisition sequence more robust.

We minimized hardware changes by using the 199MHz demodulation board, changing the local oscillator to 99.586317 MHz, with an amplitude of +10 dbm (the 3f signals are therefore acquired as LSC-PD6_I and LSC-PD6-Q).

We locked both the PRM and the DRM in a stable way using the REFL31_I and REFL31_Q, after tuning the demodulation phase (50) and removing their offsets.
On the other hand, we weren't able to acquire the lock in the DRM configuration directly by using the 3f signals. We needed instead to use the f signals first, and switch to the 3f signals once the lock was already acquired, otherwise ending up locking DRM at a different working point.
One explanation for that might be the fact that the beam impinging upon the 3f diode is too big compared with the diode size (only 1 mm, half of the size of the f1 diode).
For these reason, in presence of misalignments, some of the reflected light goes in high order modes, which can be partially (or all) off the diode, thereby generating multi-zero crossing in the demodulated error signal.

The next step before making the test with the whole IFO is therefore to modify the telescope in front of the 3f diode in order to reduce the beam size and repeat the tests we did tonight in DRM configuration.

P.S.: We made a test by changing the frequency of the local oscillator by a little bit and then coming back to the original value. We observed that the phase of the signal can change, so every time this frequency is moved the 3f demod phase need to be retuned.

John, Rob, Rana, Lisa
8508   Mon Apr 29 22:13:41 2013 KojiUpdateLSCLocking with ASDC

Today the locking was not as easy as that was last Friday.
So I tried something new. Today Rana talked about the ASDC locking with POPDC normalization.
This technique was tried. (This is somewhat similar to DC readout.)

PRCL
Signal source: REFL33I / Normalization POP110I x 0.04 / Trigger POP110I 20up 3down, otherwise  untouched from Friday locking
Servo: input matrix 1.00 -> PRCL Servo FM3/4/5/6 Always ON G=+0.06
Actuator: output matrix 1.00 -> PRM

MICH
Signal source: ASDC Offset -109.5 (nominal of the day -49.5) / Normalization POPDC x 1.00 / Trigger POP110I 20up 3down
Servo: input matrix 1.00 -> MICH Servo FM5 Always On G=+10000
ActuaroL output matrix -1.00 -> ITMX / +1.00 -> ITMY

Observation

- POP110I was ~120 during the lock (cf 170 on Friday). So there is some small leakage from the dark port.

- Lock was easier when FM4 of the MICH loop was turned off.

- During the lock horizontal motion of the intracavity mode was visible as usual.

15476   Tue Jul 14 00:06:09 2020 gautamUpdateLSCLocking with POX for CARM

I tried using the POX_I error signal for the DC CARM_B path today a couple of times. Got to a point where the AO path could be engaged and the arm powers stabilized somewhat, but I couldn't turn the CARM_A path off without blowing the lock. Now the IMC has entered a temperemental state, so I'm abandoning efforts for tonight, but things to try tomorrow are:

1. Check that the demod phase is set correctly
2. With the CARM_B path engaged, measure some CARM OLTFs. Tonight, I was a bit over-optimistic I think, by expecting the scripted transition to take me all the way, but I think I'll have to fiddle around with the gains a bit.
3. Check for offsets. The AO path should be AC coupled, but maybe the POX signal has some offset?

I have some data from a couple of days ago when the PRFPMI was locked as usual (CARM_B on REFL for both DC and AO paths), and the sensing lines were on, so I can measure the relative strength of the sensing lines in POX/REFL and get an estimate of what the correct digital gain should be.

The motivation here is to see if the sensing matrix looks any different with a modified locking scheme.

15477   Tue Jul 14 01:55:03 2020 KojiUpdateLSCLocking with POX for CARM

The usual technique is that keeping the IFO locked with the old set of the signals and the relative gain/TF between the conventional and new signals are measured in-lock so that you can calibrate the new gain/demod-phase setting.

15481   Tue Jul 14 17:28:29 2020 gautamUpdateLSCLocking with POX for CARM

From Attachment #1, looks like the phasing and gain for CARM on POX11 is nearly the same as CARM of REFL11, which is probably why I was able to execute a partial transition last night. The response in POY11 is ~10 times greater than POX11, as expected - though the two photodiodes have similar RF transimpedance, there is a ZFL-500-HLN at the POY11 output. The actual numerical values are 2.5e10 cts/m for CARM-->REFL11_I, 2.6e10 cts/m for CARM-->POX11_I, and 3.2e11 cts/m for CARM-->POY11_I.

So I think I'll just have to fiddle around with the transition settings a little more tonight.

One possible concern is that the POX and POY signals are digitized without preamplificatio, maybe this explains the larger uncertainty ellipse for the POX and POY photodiodes relative to the REFL11 photodiode? Maybe the high frequency noise is worse and is injecting junk in the AO path? I think it's valid to directly compare the POX and REFL spectra in Attachment #2, without correcting for any loops, because this signal is digitized from the LSC demodulator board output (not the preamplified one, which is what goes to the CM board, and hence, is suppressed by the CARM loop). Hard to be sure though, because while the heads are supposed to have similar transimpedance, and the POX photodiode has +12dB more whitening gain than REFL11, and I don't know what the relative light levels on these photodiodes are in lock.

 Quote: I have some data from a couple of days ago when the PRFPMI was locked as usual (CARM_B on REFL for both DC and AO paths), and the sensing lines were on, so I can measure the relative strength of the sensing lines in POX/REFL and get an estimate of what the correct digital gain should be
Attachment 1: PRFPMI_2020712sensMat.pdf
Attachment 2: LSCerrSigs.pdf
1509   Thu Apr 23 16:27:24 2009 YoichiUpdateLockingLocking with the cryo-pump
The last night, the IFO was unstabler than usual and the locking script often failed before reaching the power up stage.
The failure happened at random points.
I'm not sure if this is related to the operation of the cryo-pump.
The mode cleaner reflection image seemed to move around more than usual. Maybe it was just a high seismic night.
9846   Thu Apr 24 02:12:05 2014 JenneUpdateLSCLocking without TRY

I tried some locking anyway tonight, even though we don't have TRY.

The biggest conclusion is that I miss the auto-resonance-finding.  I've been roughly scanning the Y-ALS offset to find the POY zero crossing when I see the resonance on the test mass face cameras.

The next-biggest conclusion, is that I can hold the PRFPMI close to resonance, using ALS for CARM and DARM.  I was trying to transition DARM to AS55, but I couldn't get the last bit of the way.  That is, I couldn't turn off the ALS control.  So, I think that AS55 wasn't actually holding DARM, until maybe the last moment or so.

Anyhow, here are some time series.  My average TRX value is around 40 counts, and POPDC is maybe 250 counts (just PRMI, POPDC is about 75 counts).  Obviously this is noisy as hell, but I'm not using any IR signals for the arms.  Near the end of this first time series, I am trying to switch to AS55 for DARM.

Zooming in, my real lockloss is due to PRCL oscillating at ~350 Hz:

However, I also saw ~25Hz peaks in CARM and DARM on the spectra starting to show up, and I see a ~25 Hz oscillation in DARM a few moments after the PRCL lockloss.  (Plot #2 is a zoom of the ~1.1 second mark on Plot #3.)

The locking parameters:

CARM:

Input:  Using the new CESAR matrix, -1*ALSX, +1*ALSY.  Beatnotes both move up in freq if temp sliders move up.

Servo: gain = 6, FMs 1, 2, 3, 5, 6, 7, 9 on.  Offset = 0 counts.

Output = -1*MC2

DARM:

Input:  +1*ALSX, +1*ALSY

Servo:  gain = 4.  FMs 1, 2, 3, 5, 6, 7, 9 on.  Offset = 0 counts.

Output = -1*ETMX, +1*ETMY

PRCL:

Input:  +1*REFL33_I, Norm = +0.01*POPDC, sqrt engaged.

Servo:  acquisition easier with -0.04 or -0.06, less gain peaking at -0.02   FMs 4, 5 on; 2, 3, 6, 9 triggered with 0.5 sec delay.  Servo trigger = POPDC, up 100, down 10.  FM trigger = POPDC, up 300, down 20.

Output = +1*PRM

PRCL ASC off, PRM oplev on.

MICH:

Input:  +1*REFL33_Q, Norm = +0.01*POPDC, sqrt engaged.

Servo:  gain = 2, FMs 4, 5 on; 2, 3 triggered with 0.2 sec delay.  Servo trigger = POPDC, up 100, down 10.  FM trigger = POPDC, up 300, down 20.

Output = +0.5*BS, -0.2625*PRM

PDs:

REFL33 analog gain set to 30 dB for both I&Q.

AS55 set to 0 dB for both I&Q.  AS55 had DC normalization of 80 counts (which was the measured number for PRFPMI when TRX was about 0.1 count this evening)

9847   Thu Apr 24 11:19:50 2014 KojiUpdateLSCLocking without TRY

This seems the ever best stability at the zero offset PRFPMI.

Can you look at REFLDC in this data stream too? How was it promising?

9848   Thu Apr 24 14:00:42 2014 JenneUpdateLSCLocking without TRY

Here is 1 second of data, with REFLDC, POPDC and TRX:

Here is a zoom of the first 3 big peaks in TRX.  The weird jumps at the beginning of each TRX peak are due to the triggered switching between the Thorlabs trans PD and the QPD trans PD.  Clearly we need to work on their relative normalizations.  There are also little jumps after each peak as the triggering sends the signal back to the Thorlabs PD.

Here is a zoom of the single big peak about halfway through the 1 second of data:

And here is a zoom of the tail of that peak.  It looks to me like we want to start thinking about using REFL DC when our transmitted powers are around 2 counts.  We could do as soon as 1 count, but 2 is a little farther into the dip.

11099   Thu Mar 5 04:29:13 2015 ericqUpdateLSCLocking work tonight

Brief elog of my activities tonight:

I was able to transition the digitial CARM control to REFL11 through the common mode board a total of one time, lock broke after a few seconds.

My suspicion was that when we did this on Monday, we unintentionally had a reasonable DARM offset, which reduced the finesse enough to let us take linear transfer functions and hop over. So, tonight, I intentionally looked at transitioning to CM_SLOW at some DARM offset. Using DARM offset of a few times 0.1 really calms the "buzzing" down, and makes it fairly straightforward to measure linear CARM sensing TFs. However, the CARM optical plant seems to change a fair amount depending on the DARM offset, in such a way that I was not able to compensate well enough to repeatedly transition.

Before I did anything else tonight, I measured the ALS noise down to 0.1 Hz, as a benchmark of how things are behaving.

With the arms locked on POX/POY, the HZ calibrated ALS channels reported

• ALSX : 471Hz RMS
• ALSY: 298 Hz RMS

Then, with the arms CARM/DARM locked on ALS, the PDH signals reported (using a line and the HZ channels for conversion)

• Xarm : 552 Hz RMS
• Yarm : 264 Hz RMS

Not bad! I roughly estimate this to mean ~90pm RMS CARM/DARM motion. (If X was as good as Y, it would be ~50pm...)

Some things I feel are worth noting:

• In an effort to avoid the ETMX issues that Jenne had last night. I used MC2 to actuate CARM, and 2xETMY to actuate DARM. None of my locklosses appeared to be due to saturation of DARM, so I think it worked fine. The main drawback seems to be that if you have a violent lock loss, you may have to wait a bit for the IMC to relock; this only happened once tonight.
• After the IR resonance finding scripts, I would run a z servo to try and get the PDH signal to cross zero. This made the ALS CARM and DARM zeros closer to the real resonating zeros than I usually see.
• It is lately possible to sit at higher powers (albeit with very high RIN) for sizable amounts of time. In my last lock, I was in the range of 10-60x single arm power for around 30 minutes before I blew it with a failed transition attempt.
• The set points for the QPD servos don't change much from lock to lock. I didn't have any problem using them tonight.

Tomorrow, I'll post some transfer functions of the difference between the ALS and CARM plants that I measured.

1382   Tue Mar 10 04:55:41 2009 YoichiUpdateLockingLocking: 3.7kHz large oscillation
Yoichi, Jenne, Alberto,

As I reported on the last Thursday, there is a large oscillation in CARM and DARM error signals (attm1).
I put notch filters (3.75kHz, Q=10, 30dB) in the CARM and DARM loops. This let us go up to the arm power of more than 20 and stay there for a while.
The dashed curves in the attm1 are the spectra when the notches are off, and the solid curves are when the notches are used.
We could somewhat suppress the DARM peaks but not CARM.
Of course this is clearly not a good solution. We should find the cause of the oscillation and kill it.

Attm2 is the spectrum of the PO_DC signal flowing in the CM board measured by the SR785. More specifically, CH1 is TP1A and CH2 is TP2A of the CM board.
This was taken right after the AO path was engaged. At this stage, the AO path gain is very low. But you can already see a seed of the oscillation in the spectrum.

Attm3 shows the same spectra taken after the arm power is increased to 4 but before the PO_DC hand off. You can see large peaks around 3.75kHz.
After this, the peaks grow as the power goes up.

Attm4 is the loop gain of the AO path after the PO_DC hand off (arm power = 4).
Attm5 is the zoom of the same TF around 3.7kHz. Clearly there is something wrong at this frequency. We should check the CM board and the MC board as well as the SPOB PD.

One time I was able to go up to arm power = 27 or so. At this power level, the DARM loop started to oscillate, probably, around the UGF.
However because of the 3.7kHz problem, we can't stay at this power level long enough to make diagnostic measurements (like open loop TF).
We should tackle the 3.7kHz issue first.
Attachment 1: CARM_DARM_Spectra.pdf
Attachment 2: PODC_Spe_AOPath_Engaged.png
Attachment 3: PODC_Spe_before_PODC_handoff.png
Attachment 4: AOGain3.png
Attachment 5: AOGain2.png
4415   Fri Mar 18 17:25:21 2011 josephbUpdateCDSLockins in c1sus update, suspension screens updated

I updated our lockin simulink pieces to use the newer, more streamlined lockin piece that is currently in CDS_PARTS (with new documentation block!).  It means we are no longer passing clock signals through three levels of boxes.

In order to use the piece, you need to right click on it after copying from CDS_PARTS and go to Link Options->Disable Link.  This forces the .mdl to save all the relevant information about the block rather than just a pointer to the library.  I talked with Rolf and Alex today and we discussed setting up another model file, non-library format for putting generically useful user blocks into, rather than using the CDS_PARTS library .mdl.

The BS, ITMX, ITMY, PRM, SRM, ETMX, ETMY now have working lockins, with the input matrix to them having the 2nd input coming from LSC_IN, the 3rd from the oplev pitch, and the 4th from oplev yaw.

This necessitated a few name changes in the medm screens.  I also changed the lockin clock on/off switch to a direct amplitude entry, which turns green when a non-zero value is entered.

Currently, the Mode cleaner optic suspension screens have white lockins on them.  I started modifying a new set of screens just for them, and will modify the generate_master_screens.  Unfortunately, this requires modifying two sets of suspension screens going forward - the main interferometer optics and the MC optics.

10818   Fri Dec 19 15:59:49 2014 JenneUpdateLSCLockloss from Wed

I swapped out one of the channels on Q's lockloss plotter - we don't need POP22Q, but I do want the PC drive.

So, we still need to look into why the PC drive goes crazy, and if it is related to the buildup in the arms or just something intrinsic in the current FSS setup, but it looks like that was the cause of the lockloss that Q and Diego had on Wednesday.

10783   Thu Dec 11 17:45:54 2014 ericqUpdateComputer Scripts / ProgramsLockloss plotting

With some advice from Jamie, I've gotten the lock loss plotting script that is used at LHO working on our machines. The other night, I modified the ALSwatch.py script to log lockloss times. Tying it together, I've written a small wrapper script that grabs the last time from the lockloss log, and plots it.

It is: scripts/LSC/LocklossData/lastlock.sh

Jamie's going to make an adjustment to the pydv codebase that will let me implement the auto y-scaling that we like. We also will need to get a feel for the right timing window, once we see what kind of delay in the ALSwatch script is typical.

Here's an example of the output, with the window of [-10,+2] seconds from the logged GPS time:

10929   Thu Jan 22 03:21:24 2015 JenneUpdateLSCLocks with large MICH offsets

[Jenne, Diego, EricQ]

Tonight we worked on the acquisition sequence (including re-re-re-commissioning the UGF servos, hopefully for the last time...) for the PRFPMI with large MICH offsets.

The procedure is all in the carm_up script, as far as things work.

We had some locklosses, but they were mostly due to non-carefulness on my part during the transitions between error signals, or the UGF servos getting upset because the oscillator peaks had gotten lost in the noise.  The one that I show here is our very last one of the night, where we are hitting the rails for the MICH signal, which is then causing the other loops to have to do weird things to try to compensate, and they lose lock.

Here also is a StripTool shot during that lock stretch.  I was in the middle of increasing the MICH offset to 75% of the fringe.  The yellow trace (called MICH_B_MON) is ASDC/POPDC normalized so that it always goes 0-1.  I was pleased to see that perhaps REFL11I and AS55Q are turning over, although as Q will tell us in a more detailed elog tomorrow, having a large MICH offset does weird things and moves the DARM zero-point.  So, maybe we aren't actually anywhere awesome yet.

After some MICH offset, the maximum arm power is always going to be about 50, so arm powers of 8 or 10 equates to 100 pm.  We didn't get there tonight while on IR signals.

The locking sequence is now something like this:

• Lock carm and darm on ALS, find resonances, move to 3 counts (roughly 3nm) offset.
• Set PRMI up to acquire on REFL33I and ASDC/POPDC at 25% MICH fringe.  (After a while, I assume perhaps because the alignment is no longer tip-top, I have been by-hand reducing the MICH offset from -700counts which is 25% to -200counts, and then immediately putting it back to -700 after the PRMI acquires.)
• Engage all 4 UGF servos
• Reduce the CARM offset a bit, to 1.0 count, which gives arm powers of about 0.4 (with 50 being the max possible)
• Transition CARM from ALS to sqrtInvTrans
• Transition DARM from ALS to DC trans:  (TRY-TRX)/(TRX+TRY)
• Reduce the oscillator amplitudes of the UGF servos
• Reduce the CARM offset to powers of about 1
• Ramp to 50% MICH fringe

After this, we tried a few times to lower the CARM offset, but kept losing lock, I think because the UGF servos went crazy.  The final lock, shown above, we lost because the MICH output was hitting the rails.

The problem with the MICH servo right now is the low SNR of the POPDC being used to normalize ASDC.  The control output is enormous, even if we have the 400Hz lowpass on.  We need to rethink our MICH servo, starting with a lower UGF, so that we're not injecting all this sensing noise all over the place.

For tomorrow:

• Re-look at MICH loop, to prevent sensing noise injection.
• How does the large MICH offset affect our zero points for CARM and DARM?  Can we stay on DC transmission signals through 30 or 100 pm?
• What to do next?  One or two of the locklosses were because the CARM detuned double cavity pole wasn't de-Q-ed enough, so still hit 0dB and created an unstable unity gain point.  Can we go to higher MICH offset, maybe 75%?
• Still need to figure out where our missing phase is for our LSC loops.  CARM and DARM are short on phase, and we could definitely use some more.  So, I will work on trying to give us filters that don't eat too much phase, but we still need to find that missing ~14 deg.
14374   Thu Dec 20 17:17:41 2018 gautamUpdateCDSLogging of new Vacuum channels

Added the following channels to C0EDCU.ini:

[C1:Vac-P1b_pressure] units=torr [C1:Vac-PRP_pressure] units=torr [C1:Vac-PTP2_pressure] units=torr [C1:Vac-PTP3_pressure] units=torr [C1:Vac-TP2_rot] units=kRPM [C1:Vac-TP3_rot] units=kRPM

Also modified the old P1 channel to

[C1:Vac-P1a_pressure] units=torr

Unfortunately, we realized too late that we don't have these channels in the frames, so we don't have the data from this test pumpdown logged, but we will have future stuff. I say we should also log diagnostics from the pumps, such as temperature, current etc. After making the changes, I restarted the daqd processes.

Things to add to ASA wiki page once the wiki comes back online:

1. What is the safe way to clean the cryo pump if we want to use it again?
2. What are safe conditions to turn the RGA on?
14376   Fri Dec 21 11:11:51 2018 gautamUpdateCDSLogging of new Vacuum channels

The N2 pressure channel name was also wrong in C0EDCU.ini, so I updated it this morning to the correct name and units:

[C1:Vac-N2_pressure] units=psi

Now it too is being recorded to frames.

1908   Fri Aug 14 23:45:14 2009 ChrisUpdateGeneralLong Range Readout

The EUCLID-style Michelson readout is on the SP table now and is aligned.  See image below.  I took several power spectra with the plotter attached to the HP3563 (not sure if there's another way to get the data out) and I'm still waiting to calibrate (since dP/dL isn't constant as it isn't locked, this is taking a bit longer).  When put into XY mode on the oscilliscope (plotting Voltage at PD2 on the x and Voltage at PD3 on the y), a Lissajous figure as in the first plot below.  It's offset and elliptical due to imperfections (noise, dc offset, etc) but can ideally be used to calculate the L_ target mirror movement.  By rotating the first quarter wave plate by ~80.5deg counter-clockwise (fast axis was originally at Pi/8, now at 103deg), I was able to turn the Lissajous figure from an ellipse into a more circular shape, which would ideally allow for us to use a circular approximation (much simpler) in our displacement calculations.

Attachment 1: Table_Setup.png
Attachment 2: Ellipse.jpg
Attachment 3: Circle.jpg
7208   Thu Aug 16 19:12:30 2012 JenneUpdateLockingLong arm lock stretches

After Rana and Yoichi tweaked the arm locking filters, we have had some pretty awesome lock stretches. 5-day minute trend.

13327   Thu Sep 21 15:23:04 2017 gautamOmnistructureALSLong cable from LSC->IOO

[steve,gautam]

We laid out a 45m long BNC cable from the LSC rack to the IOO rack via overhead cable trays. There is ~5m excess length on either side, which have been coiled up and cable-tied for now. The ends are labelled "TO LSC RACK" and "TO IOO RACK" on the appropriate ends. This is to facilitate hooking up the output of the DFD for making a PM measurement of the AUX X laser. There is already a long cable that runs from the IOO rack to the X end.

11751   Wed Nov 11 11:41:42 2015 gautamUpdateGeneralLong cable laid out for 1pps signal

In order to synchronise the FS725 Rb clock with our GPS timing signals, I laid out a longish cable running from 1X7 to the IOO rack via the overhead cable guide. There was a T-connector attached to the 1pps output of the GPS timing unit, with one of the outputs unused - I have connected one end of the cable I laid out to this output, with the other end going to the 1pps input of the FS725. I am now waiting for the FS725 to sync to the external reference, before running the calibration of the phase tracker once again using the same method detailed here, using the 10MHz output from the FS725 to serve as a reference for the Fluke RF signal generator...

1894   Wed Aug 12 23:45:03 2009 ChrisUpdateGeneralLong range michelson

Today I set up the EUCLID long range michelson design on the SP table; It's the same as the setup posted earlier, but without the pickoff (at PD1), which can be added later, and a few other minor changes (moved lenses, mirrors, PDs - nothing major).  I hooked up the two PD's to the oscilliscope and got a readout that pointed to more power hitting PD2 than PD3.

Attachment 1: Actual_Sensor.png
11698   Mon Oct 19 15:23:22 2015 ericqUpdateLSCLonger DRFPMI lock

Here is a longer lock, about 100 seconds RF only, from later that same night. The in-loop CARM and DARM error signals have the order of magnitude of 1nm per count.

From ~-150 to -103, we were fine tuning the ALS offsets to try and get close to the real CARM/DARM zero points then blending the RF CARM signal.

At -100, the CARM bandwidth increases to a few kHz and stabilizes the arm powers. By -81, the error signals are all RF. At -70, I turned on the transmon QPD servos, which brought the power up a bit.

If I recall correctly, lock was lost because I put waaaay too big of an excitation on DARM with the goal of running its UGF servo for a bit. The number I entered was appropriate for ALS, but most certainly too huge for AS55...

13898   Wed May 30 16:12:30 2018 Jonathan HanksSummaryCDSLooking at c1oaf issues

When c1oaf starts up there are 446 gain channels that should be set to 0.0 but which end up at 1.0.  An example channel is C1:OAF-ADAPT_CARM_ADPT_ACC1_GAIN.  The safe.snap file states that it should be set to 0.  After model start up it is at 1.0.

We ran some tests, including modifying the safe.snap to make sure it was reading the snap file we were expecting.  For this I set the setpoint to 0.5.  After restart of the model we saw that the setpoint went to 0.5 but the epics value remained at 1.0.  I then set the snap file back to its original setting.  I ran the epics sequencer by hand in a gdb session and verified that the sequencer was setting the field to 0.  I also built a custom sequencer that would catch writes by the sdf system to the channel.  I only saw one write, the initial write that pushed a 0.  I have reverted my changes to the sequencer.

The gain channel can be caput to the correct value and it is not pushed back to 1.0.  So there does not appear to be a process actively pushing the value to 1.0.  On Rolfs sugestion we ran the sequencer w/o the kernel object loaded, and saw the same behavior.

This will take some thought.

5864   Thu Nov 10 16:44:54 2011 MirkoUpdateAdaptive FilteringLooking into MC_F & PSL misalignment

[Den, Mirko]

While doing the things below we accidentally misaligned the PSL laser. Thanks to Suresh and Jenne for realigning!!

There are a lot of strange features in MC_F (see for example http://nodus.ligo.caltech.edu:8080/40m/5738 )
To get some better understanding of the signals in the control loop we looked some more into what happens to the MC feedback signal after it exits the MC servo board (D040180 see DCC).

The MC_F signal is actually the servo signal: http://nodus.ligo.caltech.edu:8080/40m/5695
The Thorlabs temperature controller is actually used in the PZT path!

We measured the LP filter in the PZT path (that is kind of mislabeled as temp.)

5867   Thu Nov 10 22:00:38 2011 MirkoUpdateAdaptive FilteringLooking into MC_F & PSL misalignment

 Quote: [Den, Mirko] While doing the things below we accidentally misaligned the PSL laser. Thanks to Suresh and Jenne for realigning!! There are a lot of strange features in MC_F (see for example http://nodus.ligo.caltech.edu:8080/40m/5738 ) To get some better understanding of the signals in the control loop we looked some more into what happens to the MC feedback signal after it exits the MC servo board (D040180 see DCC). The MC_F signal is actually the servo signal: http://nodus.ligo.caltech.edu:8080/40m/5695 The Thorlabs temperature controller is actually used in the PZT path!  We measured the LP filter in the PZT path (that is kind of mislabeled as temp.)

### We looked into the signal from the MC servo board at different position at the PSL table.

We looked into the FB going into the temp. and PZT parts of the FB.
Temp.:

PZT:

We also looked at the signal in just in front of the FSS box No idea why the elog doesn't preview these pdfs.

Lots of extra noise there. We will check out where that comes from.

15276   Fri Mar 13 20:00:50 2020 JonUpdateComputersLoopback monitoring for slow machines

### Summary

Today I finished implementing loopback monitors of the up/down state of the slow controls machines. They are visible on a new MEDM screen accessible from Sitemap > CDS > Slow Machine Status (pictured in attachment 1). Each monitor is a single EPICS binary channel hosted by the slow machine, which toggles its state at 1 Hz (an alive "blinker"). For each machine, the monitor is defined by a separate database file named c1[machine]_state.db located in the target directory.

This is implemented for all upgraded machines, which includes every slow machine except for c1auxey. This is the next and final one slated for replacement.

### Implementation

The blinkers are currently implemented as soft channels, but I'd like to ultimately convert them to hard channels using two sinking/sourcing BIO units. This will require new wiring inside each Acromag chassis, however. For now, as soft channels, the monitors are sensitive to a failure of the host machine or a failure of the EPICS IOC. As hard channels, they will additionally be sensitive to a failure of the secondary network interface, as has been known to happen.

Each slow machine's IOC had to be restarted this afternoon to pick up the new channels. The IOCs were restarted according to the following procedure.

c1auxex

• Disabled OPLEV servos on ETMX
• Zeroed slow biases
• Disabled watchdog
• Restarted IOC
• Reverted 1-3

​c1vac

• Closed V1, VM1
• Restarted IOC
• Returned valves to original state

c1psl

• Disabled IMC autolocker
• Closed PSL shutter
• Restarted IOC
• Reverted 1-2

c1iscaux

• ​Restarted IOC

c1susaux

• Disabled IMC autolocker
• Closed shutter
• Disabled OPLEV servos on: MC1, MC2, MC3, BS, ITMX, ITMX, PRM, SRM
• Zeroed slow biases
• Disabled watchdogs
• Restarted IOC
• Reverted 1-5

The intial recovery of c1susaux did not succeed. Most visibly, the alignment state of the IFO was not restored. After some debugging, we found that the restart of the modbus service was partially failing at the final burt-restore stage. The latest snapshot file /opt/rtcds/caltech/c1/burt/autoburt/latest/c1susaux.snap was not found. I manually restored a known good snapshot from earlier in the day (15:19) and we were able to relock the IMC and XARM. GV and I were just talking earlier today about eliminating these burt-restores from the systemd files. I think we should.

Attachment 1: Screen_Shot_2020-03-13_at_7.59.55_PM.png
718   Tue Jul 22 22:25:31 2008 ranaUpdateLSCLooptickle for existing 40m
John and I have adapted the Stefan-Looptickle model of the 40m upgrade to have the parameters of the old one.
(old one = what we have had for the last 4 years).

Its in the /cvs/cds/caltech/iscmodeling directory on the CDS computers but you can also check it out from the
MIT CVS repo; its part of the whole shebang.

It makes the attached theoretical NB. Feel free to modify it.
Attachment 1: nb.png
14307   Mon Nov 19 22:01:50 2018 gautamUpdateVACLoose nut on valve

As I was turning off the lights in the VEA, I heard a rattling sound from near the PSL enclosure. I followed it to a valve - I couldn't see a label on this valve in my brief effort to find one, but it is on the south-west corner of the IMC table, so maybe VABSSCI or VABSSCO? The power cable is somehow spliced with an attachment that looks to be bringing gas in/out of the valve (See Attachment #1), and the nut on the bottom was loose, the whole power cable + mettal attachment was responsible for the rattling. I finger-tightened the nut and the sound went away.

Attachment 1: IMG_7171.JPG
11876   Fri Dec 11 23:12:09 2015 KojiSummaryCOCLoss map measurement document

Yutaro left detailed slides for his loss map measurement

https://dcc.ligo.org/LIGO-G1501547

11776   Tue Nov 17 20:40:08 2015 yutaroSummaryASCLoss maps of arm cavities

In preparation for the measurement of loss maps of arm cavities, I measured the relationship between:

the offset just after the demodulation of dithering loop (C1:ASS-YARM_ETM_PIT_L_DEMOD_I_OFFSET and C1:ASS-YARM_ETM_YAW_L_DEMOD_I_OFFSET)

and

the angle of ETMY measured with oplev (C1:SUS-ETMY_OL_PIT_INMONC1:SUS-ETMY_OL_PIT_INMON and C1:SUS-ETMY_OL_PIT_INMONC1:SUS-ETMY_OL_PIT_INMON)

while the dithering script is running. With the angle of ETMY, we can calculate the beam spot on the ETMY assuming that the beam spot on the ITMY is not changed thanks to the dithering. What we have to do is to check the calbration of oplev with another way to measure the angle, to see if the results are reliable or not.

I will report the results later.

11779   Wed Nov 18 11:22:13 2015 yutaroUpdateASCLoss maps of arm cavities

I got linear relation between these. The results and method are below.

 Quote: In preparation for the measurement of loss maps of arm cavities, I measured the relationship between: the offset just after the demodulation of dithering loop (C1:ASS-YARM_ETM_PIT_L_DEMOD_I_OFFSET and C1:ASS-YARM_ETM_YAW_L_DEMOD_I_OFFSET) and the angle of ETMY measured with oplev (C1:SUS-ETMY_OL_PIT_INMONC1:SUS-ETMY_OL_PIT_INMON and C1:SUS-ETMY_OL_PIT_INMONC1:SUS-ETMY_OL_PIT_INMON) while the dithering script is running. With the angle of ETMY, we can calculate the beam spot on the ETMY assuming that the beam spot on the ITMY is not changed thanks to the dithering. What we have to do is to check the calbration of oplev with another way to measure the angle, to see if the results are reliable or not. I will report the results later.

RESULTS

METHOD

I added offset (C1:ASS-YARM_ETM_PIT_L_DEMOD_I_OFFSET and C1:ASS-YARM_ETM_YAW_L_DEMOD_I_OFFSET) to shift the beam spot on ETMY. For each data point, I measured the difference in angle of ETMY with oplev before and after adding offset. The precedure for each measurement I employed is following:

-- run dither

-- wait until error signals of dithering settle down

-- freeze dither

-- measure angle (10s avg)

-- wait until error signals of dithering settle down

-- freeze dither

-- measure angle (10s avg)

The reason why I measured the angle without offset for each measurement is that the angle which oplev shows changed with time (~several tens of minutes or something).

DISCUSSION

At the maximum values of offsets, the arm transmission power started to degrade, so the range where I can do this measurement is limited by these values as for now. However, we have to shift the beam spot more in order to make loss maps of sufficiently broad area on the mirror (the beam width (w) on ETM; w ~ 5 mm). Then, we have to find out how to shift the beam spot more.

Attachment 1: ETM_PIT_up.png
16253   Wed Jul 21 18:08:35 2021 yehonathanUpdateLoss MeasurementLoss measurement

{Gautam, Yehonathan, Anchal, Paco}

We prepared for the loss measurement using DC reflection method. We did the following changes:

1. REFL55_Q was disconnected and replaced with MC_T cable coming from the PD on the MC2 table. The cable has a red tag on it. Consequently we lost the AS beam. We realigned the optics and regained arm locks. The spot on the AS QPD had to be corrected.

2. We tried using AS55 as the PD for the DC measurement but we got ratios of ~ 0.97 which implies losses of more than 100 ppm. We decided to go with the traditional PD520 used for these measurements in the past.

3. We placed the PD520 used for loss measurements in front of the AS55 PD and optimized its position.

4. AS110 cable was disconnected from the PD and connected to PD520 to be used as the loss measurement cable.

5. In 1Y2 rack, AS110 PD cable was disconnected, REFL55_I was disconnected and AS110 cable was connected to REFL55_I channel.

So for the test, the MC transmission was measured at REFL55_Q and the AS DC was measured at REFL55_I.

We used the scripts/lossmap_scripts/armLoss/measArmLoss.py script. Note that this script assumes that you begin with the arm locked.

We are leaving the IFO in the configuration described above overnight and we plan to measure the XARM loss early AM. After which we shall restore the affected electrical and optical paths.

We ran the /scripts/lossmap_scripts/armLoss/measureArmLoss.py script in pianosa with 25 repetitions and a 30 s "duty cycle" (wait time) for the Y arm. Preliminary results give an estimated individual arm loss of ~ 30 ppm (on both X/Y arms) but we will provide a better estimate with this measurement.

16254   Thu Jul 22 16:06:10 2021 PacoUpdateLoss MeasurementLoss measurement

[yehonathan, anchal, paco, gautam]

We concluded estimating the XARM and YARM losses. The hardware configuration from yesterday remains, but we repeated the measurements because we realized our REFL55_I_ERR and REFL55_Q_ERR signals representing the PD520 and MC_TRANS were scaled, offset, and rotated in a way that wasn't trivially undone by our postprocessing scripts... Another caveat that we encountered today was the need to add a "macroscopic" misalignment to the ITMs when doing the measurement to avoid any accidental resonances.

The final measurements were done with 16 repetitions, 30 second duration, and the logfiles are under scripts/lossmap_scripts/armLoss/logs/20210722_1423.txt and scripts/lossmap_scripts/armLoss/logs/20210722_1513.txt

Finally, the estimated YARM loss is 39$\pm$7 ppm, while the estimated XARM loss is 38$\pm$8 ppm. This is consistent with the inferred PRC gain from Monday and a PRM loss of ~ 2%.

Future measurements may want to look into slow drift of the locked vs misaligned traces (systematic errors?) and a better way of estimating the statistical uncertainty (e.g. by splitting the raw time traces into short segments)

16256   Sun Jul 25 20:41:47 2021 ranaUpdateLoss MeasurementLoss measurement

What are the quantitative root causes for why the statistical uncertainty is so large? Its larger than 1/sqrt(N)

16257   Mon Jul 26 17:34:23 2021 PacoUpdateLoss MeasurementLoss measurement

[gautam, yehonathan, paco]

We went back to the loss data from last week and more carefully estimated the ARM loss uncertainties.

Before we simply stitched all N=16 repetitions into a single time-series and computed the loss: e.g. see Attachment 1 for such a YARM loss data. The mean and stdev for this long time series give the quoted loss from last time. We knew that the uncertainty was most certainly overestimated, as different realizations need not sample similar alignment conditions and are sensitive to different imperfections (e.g. beam angular motion, unnormalizable power fluctuations, etc...).

Today we analyzed the individual locked/misaligned cycles individually. From each cycle, it is possible to obtain a mean value of the loss as well as a std dev *across the duration of the trace*, but because we have a measurement ensemble, it is also possible to obtain an ensemble averaged mean and a statistical uncertainty estimate *across the independent cycle realizations*. While the mean values don't change much, in the latter estimate we find a much smaller statistical uncertainty. We obtain an XARM loss of 37.6 $\pm$ 2.6 ppm and a YARM loss of 38.9 $\pm$ 0.6 ppm. To make the distinction more clear, Attachment 2 and  Attachment 3 the YARM and XARM loss measurement ensembles respectively with single realization (time-series) standard deviations as vertical error bars, and the 1 sigma statistical uncertainty estimate filled color band. Note that the XARM loss drifts across different realizations (which happen to be ordered in time), which we think arise from inconsistent ASS dither alignment convergence. This is yet to be tested.

For budgeting the excessive uncertainties from a single locked/misaligned cycle, we could look at beam pointing, angular drift, power, and systematic differences in the paths from both reflection signals. We should be able to estimate the power fluctuations by looking at the recorded arm transmissions, the recorded MC transmission, PD technical noise, etc... and we might be able to correlate recorded oplev signals with the reflection data to identify angular drift. We have not done this yet.

Attachment 1: LossMeasurement_RawData.pdf
Attachment 2: YARM_loss_stats.pdf
Attachment 3: XARM_loss_stats.pdf
14815   Mon Jul 29 13:32:56 2019 gautamUpdateLoss MeasurementLoss measurement PD installed in AS path

[yehonathan, gautam]

• we placed a PDA520 photodiode in the AS beampath, so AS110 and AS55 no longer see any light.
• ITMX and ETMX were misaligned (since the plan is to measure the Y arm loss).
• The PDA520 and MC2 transmission are currently going to the Y arm ALS beat channels in the DAQ system. Unfortunately, we have no control over the whitening gains for these channels because of the c1iscaux2 situation.
14448   Mon Feb 11 19:53:59 2019 gautamSummaryLoss MeasurementLoss measurement setup

To measure the Y-arm loss, I decided to start with the classic reflectivity method. To prepare for this measurement, I did the following:

1. Placed a PDA 520 in the AS beam path on the AS table.
2. Centered AS beam on above PDA 520.
3. Monitored signal from PDA520 and the MC transmission simultaneously in the single-bounce from ITMY config (i.e. all other optics were misaligned). Convinced myself that variations in the two signals were correlated, thus ruling out in this rough test any interference from ghost beams from ITMX / PRM etc.
4. For the DAQ, I decided to use the two ALS Y arm channels in 1Y4, mainly because we have some whitening electronics available there - the OMC model would've been ideal but we don't have free whitening channels available there. So I ran long BNCs to the rack, labelled them.
5. It'd be nice to have these signals logged to frames, so I added DQ-channels for the IN1 points of the BEATY_FINE filters, recording at 2048 Hz for now. Of course this necessitated restart of the c1lsc model, which caused all the vertex FEs to crash, but the reboot script brought everything back smoothly.
6. Not sure what to make of the shape of the spectrum of the AS photodiode, see Attachment #1 - looks like some kind of scattering shelf but I checked the centering on the PD itself, looks good. In any case, with the whitening gains I'm using, seems like both channels are measuring above ADC noise.
7. Found that the existing misalignment to the ETMY does not eliminate signatures of cavity flash in the AS photodiode. So I increased the amount of misalignment until I saw no evidence of flashes in the reflected photodiode.
8. Johannes' old scripts didn't work out of the box - so I massaged it into a form that works.
9. Re-centered Oplevs to try and keep them as well centered in the linear range as possible, maybe the DC position info from the Oplevs is useful in the analysis.

I'm running a measurement tonight, starting now (~1130PM), should be done in ~1hour, may need to do more data-quality improvements to get a realistic loss number, but I figured I'd give this a whirl.

I'm rather pleased with an initial look at the first align/misalign cycle, at least there is discernable contrast between the two states - Attachment #2. The data is normalized by MC transmission, and then sig.decimated by x512 (8**3).

Attachment 1: DQcheck.pdf
Attachment 2: initialData.pdf
14449   Tue Feb 12 18:00:32 2019 gautamSummaryLoss MeasurementLoss measurement setup

Another arm loss measurement started at 6pm.

13235   Mon Aug 21 20:11:25 2017 johannesSummaryGeneralLoss measurements plan

There are three methods we (will soon) have available to evaluate the round-trip dissipative losses in the arms that do not suffer from the ITM loss dominance:

• DC reflection method:
• Compare reflected light levels from [ITM only] vs [arm cavity on resonance]
• Basler CCDs:
• Infer large (or small) angle scatter loss with calibrated CCDs
• Reflection ringdowns:
• Need AS port light injection, principle is similar to DC method but better (?)

### DCREFL

The DC method comparing reflectivities has been used in the past and is relatively easy to do. After the recent vacuum troubles the first step should be to re-perform these as CDS permits (needs some ASS functionality and of course the MC to behave). It wouldn't hurt to know the parameters this depends on, aka mode overlap and modulation depths with better certainty. Maybe the SURF scripts for mode-spectroscopy can be applied?

### CCDs

With the new CCD cameras calibrated, pre-vent we can determine the magnitude of the large-angle scatter loss (assuming isotropic scatter) of ETMX and possibly ETMY. Can we look past ETMX/ETMY from the viewports? Then we can probably also look at the small angle scatter of ITMX and ITMY. If not, once we open one of the chambers there's the option of installing mirrors as close as possible to the main beam path. The easiest is probably to look at ITMX, since there is plenty of space in the XEND chamber, and the camera is already installed.

### ASPORT

This requires a lot of up-front work. We decided to use the spare 200mW NPRO. It will be placed on the PSL table and injected into an optical fiber, which terminates on the AS table. The again free space beam there needs to be sort-of mode-matched into the SRC ("sort-of" because mode-spectroscopy). We want to be able to phaselock this secondary beam to the PSL with at least a couple kHz bandwidth and also completely extinguish the beam on time-scales of a few microseconds. We will likely need to purchase a few components that we can salvage from other labs, I'm still going through the inventory and will know more soon (more detailed post to follow). We need to settle for the polarization we want to send in from the back.

## Tentative Schedule (aggressive)

#### Week Aug 21 - Aug 27:

• Update mode-overlap estimates
• Obtain current DC refl estimates
• Spatial profile of auxiliary NPRO
• CCD software prep work

#### Week Aug 28 - Sep 3:

• Re-evaluate modulation indices if necessary
• Optical beat AS Port Auxiliary Laser (ASAL) - PSL
• PLL setup
• CCD large angle prep work

#### Week Sep 4 - Sep 10:

• PLL CDS integration
• Amplitude-modulation preparation
• CCD large angles

#### Week Sep 11 - Sep 17:

• Fiber-injection
• AS table preliminary mode-matching
• CCD small angle prep work

#### Week Sep 18 - Sep 24:

• ASAL amplitude switching
• CCD small angles

#### Week Sep 25 - Oct 1:

• AS port ringdowns

13236   Mon Aug 21 21:26:41 2017 gautamSummaryGeneralLoss measurements plan

In case you want to use it, I had profiled the Lightwave NPRO sometime back, and we were even using it as the AUX X laser for a short period of time.

As for using the AS laser for mode spectroscopy: don't we want to match the beam into the cavity as best as possible, and then use some technique to disturb the input mode (like the dental tooth scraper technique from Chris Mueller's thesis)?

Johannes and I did an arm scan of the X arm today (arm controlled with ALS, monitoring IR transmission) - only 2 IR FSRs were scanned, but there should be sufficient information in there to extract the modulation depth and mode matching - can we use Kaustubh's/Naomi's code?. The Y arm ALS needs to be touched up so I don't have a Y arm scan yet. Note that to get a good arm scan measurement, the High Gain Thorlabs PD should be used as the transmission PD.

Quote:

#### Week Aug 21 - Aug 27:

• Update mode-overlap estimates
• Obtain current DC refl estimates
• Spatial profile of auxiliary NPRO
• CCD software prep work

9014   Thu Aug 15 12:30:17 2013 manasaUpdateGreen LockingLost beat notes

[Koji, Nic, Manasa]

Update from last night.

Koji and I realigned the green optics on the PSL to start working on the ALS.

We set on a beat note search. We couldn't find the beat note between any of the arm green transmission and the PSL green. All we could see was the beat between the X arm and the Y arm green leakage.

Since we had the beatnote between the 2 green transmission beams, we decided to scan the PSl temperature. We scanned the SLOW actuator adjust of PSL; but couldn't locate any beat note. The search will continue again today.

ELOG V3.1.3-