40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 301 of 339 Not logged in
ID Date Author Type Category Subject
429   Sun Apr 20 18:23:27 2008 ranaSummaryLSClocking attempts
I noticed that the adaptive FF for the MC had stopped doing anything; this turned out
to be that the MC lost lock and the mcdown script turned off the FF path to MC1.

Although there's no elog, it looks like there was ~60 attempts at locking the IFO
between 12:38 and 4:27 on Saturday afternoon. I'm attaching here a plot showing
lock attempt durations and a histogram of lock times.
Attachment 1: quix.png
11513   Tue Aug 18 03:56:09 2015 ericqUpdateLSClocking efforts

Now that the updated ALS is stable, and the PRC angular FF is revived, I've been working on relocking PRFPMI. While the RMS arm fluctuations are surely smaller than they used to be, there is no noticible difference to the ears when buzzing around resonance, but this doesn't really mean much.

Frustratingly, I am not able to stably blend in any RF CARM error signal into the slow length control path (i.e. CARM_B). Bringing AS55 Q into DARM with the 20:0 integrator is working fine, but we really need to supress CARM to get anywhere. I'm not sure why this isn't working; poking around into the settings that were used when we were regularly locking didn't turn up any differences as far as I could tell. Investigations continue...

Some minor changes to the locking script were made, to account for the increased ALS displacement sensitivity from the longer delay line.

Since the ALS is now in a fairly stable state, I've updated the calibrated PSD template at /users/Templates/ALS/ALS_outOfLoop_Ref.xml, and added some coherence plots for some commonly coupled quantities (beat signal amplitude, IR error signal, green PDH error signal and green transmission).

Attachment 1: newALSref.pdf
Attachment 2: xCoh.pdf
Attachment 3: yCoh.pdf
4623   Wed May 4 13:45:56 2011 kiwamuUpdateLSClocking last night

Last night I was trying to calibrate the MICH error signal and the actuators on BS and ITMs.

However I gave up taking the data because the MC locking was unstable. MC3 drifted a lot.

6471   Fri Mar 30 10:20:51 2012 kiwamuUpdateLSClocking last night

I was trying to make the DRMI lock more robust.

Increasing the gains of the oplev on SRM helped a lot, but the lock is still not solid enough for measurements.

According to some line injection tests, the SRCL and MICH signals show up in AS55Q with almost the same amplitudes.

I tried to diagonalize the input matrix (particularly MICH-SRCL in AS55) based on the result of the line injection tests, but I ran out the time.

Work continues.

15045   Fri Nov 22 00:54:14 2019 gautamUpdateLSClocking notes

[KA, GV]

There was no shaking (that disturbed the locking) tonight!

1. REFL165 Demod phase was adjusted from -111deg to -125deg. To minimize coherence b/w MICH and PRCL.
2. MICH 3f loop gain changed to 0.3.
3. If the POP mode shape looks weird, it probably means that the PRM is sligntly misaligned. Tweaking the alignment improves PRMI stability and also makes the arm buildup higher.
4. Ditto for MICH - slightly touching up the BS alignment can lower ASDC.
5. Main finding tonight was that the ALS noise seems to get degraded as a function of the CARM offset! As a result of this, CARM goes through several linewidths, and the arm transmission fluctuates wildly.
• We suspect some scattered light shenanigans. It is not clear to me why this is happening. Possibilities:
• Scattered ETM transmission somehow makes it into the fiber coupler and degrades the ALS noise.
• Sacttered ETM transmission makes it onto the Green PDH photodiode and degrades the ALS noise.
• Backscatter into the PSL degrades the ALS noise.
• Shadow sensors of either the ITMs, ETMs, BS, or PRM don't have 1064nm filters and get scatterd light, making the cavity length noise worse.
• Other possibilities?

The problem is hard to debug because we are feeding back on the ETMs, BS and PRM, and at the low CARM offset (= high PRG), all the DoFs are cross coupled strongly so just by looking at error/control signals, I can't directly determine where the noise is originating. The fact that the ALS CARM spectrum shows a noise increase suggests that the problem has to do with the test masses, PSL, IMC, or end green PDH setups.

My plan is to do a systematic campaign and eliminate some of these possibilities - e.g. install some baffling around the fiber coupler and the end green PDH photodiodes and see if there is any improvement in the situation.

* In attachment #1, the "Ref" traces are when the CARM offset is 0, and the arms are buzzing in and out of resonance. The non-reference traces are for when the CARM offset is ~28kHz (so several linewidths away from resonance).

Attachment 1: ALSnoiseIncrease.pdf
4753   Fri May 20 03:01:17 2011 kiwamuUpdateLSClocking status

(PRMI locking)

Since REFL11 has gone I tried locking the PRMI with combination of REFL55 and AS55.

Without any pain the lock of PRMI was achieved successfully. AS55 was used to sense MICH and REFL55 was used for PRC.

(scripting)

Additionally I was modifying several scripts which are invoked from C1IFO_CONFIGURE.adl. Some details about the scripts will be uploaded on the wiki later.

An important thing is that now we are able to use the "restore" commands for the Y arm, X arm, Michelson and PRM locking.

The scripts will automatically acquire the lock of each DOF.  The image below is just a screen shot of the medm screen where you can call the scripts.

( Still to do)

* PRM actuator response measurement

* PRC noise budget

* MICH-PRC actuator decoupling

5040   Wed Jul 27 01:58:23 2011 kiwamuUpdateLSClocking status

Through some locking exercise I found that several things are degrading.

Remember the interferometer is like a cat, so we have to feed and take care of her everyday. (Otherwise the cat will be dead !)

Beam axis:

I guess that the beam axis has changed a lot to the horizontal direction.
The beam spots on the REFL and AS camera looked off-centered by a size of the spot.
The beam axis has to be well-aligned before the vent.

Locking of the Arms :

didn't lock at all. It could be a problem of the demodulation phase on AS55.
Also the TRY camera looked pretty much off-centered. The spot is already getting out from the field of view.
We have to fix this issue, otherwise we cannot align the beam axis.

Locking of PRM :

Sort of okay, I was able to lock both MICH and PRCL although I had to flip the sign of the MICH control gain due to the demod-phase change.
The suspensions don't look healthy. The beam spots on the REFL and AS camera move a lot even without any length feedback.
It means some of the suspensions are shaky.
5041   Wed Jul 27 08:59:10 2011 SureshUpdateLSClocking status

I had to realign PSL beam into the MC in order to reobtain the MC lock.  We lost lock at sometime around 8:30 AM on Tuesday.  See attached trend data for MC_RFPD_DCMON.

The is the second time this week that I had to do this when we were unable to obtain the MC lock.  On both occassions the zig-zag at the end of the PSL table was tweaked to minimise the MC_RFPD_DCMON.

We have been using the MC as a Beam Axis Reference.  And therefore we are adjusting the PSL beam to maximise coupling into MC.  However if MC's beam axis has shifted, then would it not be best to use the pzt's to re-obtain coupling into the arm cavities?

 Quote from #5040 Beam axis:  I guess that the beam axis has changed a lot to the horizontal direction. The beam spots on the REFL and AS camera looked off-centered by a size of the spot. The beam axis has to be well-aligned before the vent.

5043   Wed Jul 27 10:10:12 2011 steveUpdatePSLlocking status

80 days: PMC is drifting

Attachment 1: 80dpmcMC.jpg
5665   Fri Oct 14 04:35:45 2011 kiwamuUpdateLSClocking tonight

The lock of DRMI wasn't stable enough to measure the sensing matrix. Failed.

PRMI and SRMI were okay and in fact they could stay locked robustly for a long time.

I added a new option in the C1IFO_CONFIGURE screen so that one can choose Signal-Recycled Michelson in carrier resonant condition.

Additionally the orthogonalization of the I-Q signals on REFL55 should be done because it hasn't been done.

442   Thu Apr 24 14:10:26 2008 robUpdateLockinglocking work
Rob, Johnnie

We made some progress on locking last night (Wed night), namely that we were able to handoff (briefly) the CARM-MCL path the REFL-DC error signal. We tried this because we suspect that the reason the PO-DC is not a good CARM error signal is because at low powers, the dc light level in the recycling cavity is dominated by the +f2 RF sideband. Thus, REFL-DC should work a bit better at low powers, which it did. It wasn't super stable, though, so this will require a bit of work to make the transition reliable & stable. The next things to work on include setting the AO path gain properly and possibly going to higher arm powers before handing off (thus increasing the discriminant).

Another thing we found is that the alignment scripts are not working in an ideal fashion. Running the alignment scripts for the two arms (XARM & YARM) leaves the Michelson badly misaligned, making it impossible to get good DRM alignment. This will have to be fixed.
3773   Sun Oct 24 19:55:50 2010 kiwamuUpdateElectronicslonely RF amplifier on ITMX table
(Rana, Kiwamu)

Last Friday we found a lonely RF amplifier ZHL-3A on the ITMX table.
When we found him we were very sad because he's been setup unacceptably

For example, the signal input was disconnected although a 24V DC was still applied. So he has been making just a heat for a long time.
The power connector was a BNC style which is not official way.
The leg of a decoupling capacitor attached to the DC connector was apparently broken and etc,..

We salvaged him and then cleaned up those cables and the DC power supply.

We don't say like 'don't make a temporary setup', but please clean up them after finishing the work every time.
12385   Tue Aug 9 13:53:57 2016 babbottUpdateSEIlong Guralp EX cable repaired on the D-sub side

I checked out the cable that I took from you, and all of the connections looked right.  The only thing I did notice was that some of the soldered wires on the 37-pin connector had gotten hot enough to melt their insulation, and potentially short together.  I cut off that connector, and left it on your desk to check out.  I put on a new connector, and checked the pinout.  If the Guralps still doesn't work, we'll have to check out other possibilities.

685   Wed Jul 16 17:51:58 2008 MashaUpdateAuxiliary lockinglong measurement
I'm taking a measurement on the SR785 spectrum analyzer at low frequencies, so I'm going to leave it by the symmetric port table for a while. Please don't move it!
686   Wed Jul 16 22:29:05 2008 MashaUpdateAuxiliary lockinglong measurement

 Quote: I'm taking a measurement on the SR785 spectrum analyzer at low frequencies, so I'm going to leave it by the symmetric port table for a while. Please don't move it!

all done thanks.
2312   Mon Nov 23 10:11:03 2009 steveUpdatePEMlong term temp fluctuation of the 40m lab

 Quote: This first plot shows the RC temperature channels' performance from 40 days ago, before we disabled the MINCO PID controller. Although RCTEMP is supposed to be the out of loop sensor, what we really care about is the cavity length and so I've plotted the SLOW. To get the SLOW on the same scale, I've multiplied the channel by 10 and then adjusted the offset to get it on the same scale.  The second plot shows a period after that where there is no temperature control of the can at all. Same gain scaling has been applied to SLOW as above, so that instead of the usual 1 GHz/V this plot shows it in 0.1 GHz/V. The third plot shows it after the new PID was setup. Summary: Even though the PID loop has more gain, the true limit to the daily fluctuations in the cavity temperature and the laser frequency are due to the in-loop sensors measuring the wrong thing. i.e. the out-of-loop temperature is too different from the in-loop sensor. This can possibly be cured with better foam and better placement of the temperature sensors. Its possible that we're now just limited by the temperature gradients on the can.

Here is a 7 years plot of  of the 40m temperature variations.

Attachment 1: 7ytemp.jpg
4801   Thu Jun 9 18:25:22 2011 kiwamuHowToCDSlook back a channel which doesn' exist any more

For some purposes I looked back the data of some channels which don't exist any more.  Here I explain how to do it.

If this method is not listed on the wiki, I will put this instruction on a wiki page.

(How to)

(1) Edit an "ini" file which is not associated to the real-time control (e.g. IOP_SLOW.ini)

(2) In the file, write a channel name which you are interested in. The channel name should be bracketed like the other existing channels.

example:  [C1:LSC-REFL11_I_OUT_DAQ]

(3) Define the data rate. If you want to look at the full data, write

datarate = 2048

just blow each channel name.

Or if you want to look at only the trends, don't write anything.

(4) Save the ini file and restart fb. If necessary hit "DAQ Reload" button on a C1:AAA_GDS_TP.adl screen to make the indicators green.

(5) Now you should be able to look at the data for example by dataviewer.

(6) After you finish the job, don't forget to clean up the sentences that you put in the ini file because it will always show up on the channel list on dtt and is just confusing.

Also don't forget to restart fb to reflect the change.

8524   Thu May 2 19:59:34 2013 JamieUpdateComputer Scripts / Programslookback: new program to look at recent past testpoint data

To aid in lock-loss studies, I made a new program called 'lookback', similar to 'getdata', to look at past data.

When called with channel name arguments, it runs continuously, storing all channel data in a ring buffer.  When the user hits Ctrl-C, all the data in the ring buffer is displayed.  There is an option to store the data in the ring buffer to disk as well.

controls@rosalba:/opt/rtcds/caltech/c1/scripts/general 0$./lookback -h usage: lookback [-h] [-l LENGTH] [-o OUTDIR] channel [channel ...] Lookback on testpoint data. The specified amount of data is stored in a ring buffer. When Ctrl-C is hit, all data in the ring buffer is plotted. Both 'DQ' and 'online' test point data is available. Use NDSSERVER environment variable to specify host:port. positional arguments: channel Acquisition channel. Multiple channels may be specified and acquired at once. optional arguments: -h, --help show this help message and exit -l LENGTH, --lookback LENGTH Lookback time in seconds. This amount of data will be stored in a ring buffer, and plotted on Ctrl-C. Default is 10 seconds -o OUTDIR, --outdir OUTDIR Output directory to write data (will be created if it doesn't exist). Data from each channel stored as '<channel>.txt'. Any existing data files will be overwritten. controls@rosalba:/opt/rtcds/caltech/c1/scripts/general 0$

4692   Wed May 11 17:20:24 2011 kiwamuConfigurationIOOloop diabled on PZT2

[Valera / Kiwamu]

The pointing of the incident beam to the interferometer has been jumping frequently.

Due to this jump the lock of the Y arm didn't stay for more than 2 min.

We turned off the strain gauge loop of PZT2-YAW and PZT2-PITCH, then the spot motion became solid and the Y arm locking became much more robust.

2105   Fri Oct 16 16:08:00 2009 robConfigurationASCloop opened on PZT2 YAW at 3:40 pm

I pushed the "closed loop" button on PZT2 YAW around 3:40 pm today, then roughly recentered it using the DC Offset knob on the PiezoJena controller and the IP ANG QPD readbacks.  There was a large DC shift.    We'll watch and see how much it drifts in this state.

2107   Fri Oct 16 18:46:36 2009 ranaConfigurationASCloop opened on PZT2 YAW at 3:40 pm

 Quote: I pushed the "closed loop" button on PZT2 YAW around 3:40 pm today, then roughly recentered it using the DC Offset knob on the PiezoJena controller and the IP ANG QPD readbacks.  There was a large DC shift.    We'll watch and see how much it drifts in this state.

Here's the trend.

The transient at ~22:40 is Rob switching to 'Open Loop' on the Piezo Jena PZTs. I don't see any qualitative change in the drift after this event.

At 05:55 UTC, I removed an iris that was blocking the IP POS beam (the sum goes up from 2 to 6.5) without disturbing the mirrors who's oplev beam are on that table. Steve has conceded one sugar Napoleon after betting against my ninja-like iris skills.

We should recenter the beam on IP POS now that its unclipped - I'll let it sit this way overnight just to get more drift data.

Attachment 1: Untitled.png
2109   Sun Oct 18 16:09:34 2009 ranaConfigurationASCloop opened on PZT2 YAW at 3:40 pm

I wanted to see how long our IP POS beam has been badly clipped - turns out its since April 1, 2007.

Steve's April Fool's joke is chronicled then. The attached trend shows that the drop in IP POS is coincident with that event.

In trying to align IPPOS, I noticed that someone has placed a ND2.0 filter (factor of 100 attenuation) in front of it. This is kind of a waste - I have removed IPPOS to fix its resistors and avoid this bad optic. Also the beam coming onto the table is too big for the 1" diameter optics being used; we need to replace it with a 2" diamter optic (Y1-2037-45P).

IP ANG dropped by a factor of 2 back in early August of '08.

We need this guy on the investigation:

Attachment 1: a.png
4752   Fri May 20 01:02:50 2011 loose connection hunterUpdateSUSloose connection on ETMY rack

The UL signal of the shadow sensor on ETMY went to zero this evening.

This was due to a loose connection on the cross connection board on the 1Y4 rack.

In order to make them tighten, a combination of stand-offs and screws were installed on the connectors. They won't be loose any more.

14290   Mon Nov 12 13:53:20 2018 ranaUpdateIOOloss measurement: oscope vs CDS DAQ

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

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

35   Wed Oct 31 08:34:35 2007 ranaOtherIOOloss measurements
In the end, we were unable to get a good scatter measurement just because we ran out of steam. The idea was to get a frame
grab image of MC2 but that involves getting an unsaturated image.

In the end we settle for the ringdowns, Rob's (so far unlogged) cavity pole measurement, and the MC transmission numbers. They
all point to ~100-150 ppm scatter loss per mirror. We'll see what happens after wiping.
14243   Thu Oct 11 13:40:51 2018 yukiUpdateComputer Scripts / Programsloss measurements
 Quote: This is the procedure I follow when I take these measurements for the XARM (symmetric under XARM <-> YARM): Dither-align the interferometer with both arms locked. Freeze outputs when done. Misalign ETMY + ITMY. ITMY needs to be misaligned further. Moving the slider by at least +0.2 is plentiful to not have the other beam interfere with the measurement. Start the script, which does the following: Resume dithering of the XARM Check XARM dither error signal rms with CDS. If they're calm enough, proceed. Freeze dithering Start a new set of averages on the scope, wait T_WAIT (5 seconds) Read data (= ASDC power and MC2 trans) from scope and save Misalign ETMX and wait 5s Read data from scope and save Repeat desired amount of times Close the PSL shutter and measure the PD dark levels

Information for the armloss measurement:

• Script which gets the data:  /users/johannes/40m/armloss/scripts/armloss_scope/armloss_dcrefl_asdcpd_scope.py
• Script which calculates the loss: /users/johannes/40m/armloss/scripts/misc/armloss_AS_calc.py
• Before doing the procedure Johannes wrote you have to prepare as follows:
• put a PD in anti-symmetric beam path to get ASDC signal.
• put a PD in MC2 box to get tranmitted light of IMC. It is used to normalize the beam power.
• connect those 2 PDs to oscilloscope and insert an internet cable to it.
• Usage: python2 armloss_dcrefl_asdcpd_scope.py [IP address of Scope] [ScopeCH for AS] [ScopeCH for MC] [Num of iteration] [ArmMode]

Note: The scripts uses httplib2 module. You have to install it if you don't have.

The locked arms are needed to calculate armloss but the alignment of PMC is deadly bad now. So at first I will make it aligned. (Gautam aligned it and PMC is locked now.)

gautam: The PMC alignment was fine, the problem was that the c1psl slow machine had become unresponsive, which prevented the PMC length servo from functioning correctly. I rebooted the machine and undid the alignment changes Yuki had made on the PSL table.

14245   Fri Oct 12 12:29:34 2018 yukiUpdateComputer Scripts / Programsloss measurements

With Gautam's help, Y-arm was locked. Then I ran the script "armloss_dcrefl_asdcpd_scope.py" which gets the signals from oscilloscope. It ran and got data, but I found some problems.

1. It seemed that a process which makes arm cavity mislaigned in the script didn't work.
2. The script "armloss_dcrefl_asdcpd_scope.py" gets the signal and the another script "armloss_AS_calc.py" calculates the arm loss. But output file the former makes doesn't match with the type the latter requires. A script converts format is needed.

Anyway, I got the data needed so I will calculate the loss after converting the format.

14248   Fri Oct 12 20:20:29 2018 yukiUpdateComputer Scripts / Programsloss measurements

I ran the script for measuring arm-loss and calculated rough Y-arm round trip loss temporally. The result was 89.6ppm. (The error should be considered later.)

The measurement was done as follows:

1. install hardware
1. Put a PD (PDA520) in anti-symmetric beam path to get ASDC signal.
2. Use a PD (PDA255) in MC2 box to get tranmitted light of IMC. It is used to normalize the beam power.
3. Connect those 2 PDs to oscilloscope (IP: 192.168.113.25) and insert an internet cable to it.
2. measure DARK noise
1. Block beam going into PDs with dampers and turn off the room light.
2. Run the script "armloss_dcrefl_acdcpd_scope.py" using "DARK" mode.
3. measure the ASDC power when Y-arm locked and misaligned
1. Remove dampers and turn off the room light.
2. Dither-align the interferometer with both arms locked. Freeze outputs when done. (Click C1ASS.adl>!MoreScripts>ON and click C1ASS.adl>!MoreScripts>FreezeOutputs.)
3. Misalign ETMX + ITMX. (Just click "Misalign" button.)
4. Further misalign ITMX with the slider. (see previous study: ITMX needs to be misaligned further. Moving the slider by at least +0.2 is plentiful to not have the other beam interfere with the measurement.)
5. Start the script "armloss_dcrefl_acdcpd_scope.py" using "ETMY" mode, which does the following:
1. Resume dithering of the YARM.
2. Check YARM dither error signal rms with CDS. If they're calm enough, proceed. (In the previous study the rms threshold was 0.7. Now "ETM_YAW_L_DEMOD_I" signal was 15 (noisy), then the threshold was set 17.)
3. Freeze dithering.
4. Start a new set of averages on the scope, wait T_WAIT (5 seconds).
5. Read data (= ASDC power and MC2 trans) from scope and save.
6. Misalign ETMY and wait 5s. (I added a code which switchs LSC mode ON and OFF.)
7. Read data from scope and save.
8. Repeat desired amount of times.
4. calculate the arm loss
1. Start the script "armloss_AS_calc.py", whose content is follows:
• requires given parameters: Mode-Matching effeciency, modulation depth, transmissivity. I used the same value as Johannes did last year, which are (huga)
• reads datafile of beam power at ASDC and MC2 trans, which file is created by "armloss_dcrefl_acdcpd_scope.py".
• calculates arm loss from the equation (see 12528 and 12854).

Result:

YARM
('AS_DARK =', '0.0019517200000000003') #dark noise at ASDC
('MC_DARK =', '0.02792') #dark noise at MC2 trans
('AS_LOCKED =', '2.04293') #beam power at ASDC when the cavity was locked
('MC_LOCKED =', '2.6951620000000003')
('AS_MISALIGNED =', '2.0445439999999997') #beam power at ASDC when the cavity was misaligned
('MC_MISALIGNED =', '2.665312')

$\hat{P} = \frac{P_{AS}-P_{AS}^{DARK}}{P_{MC}-P_{MC}^{DARK}}$ #normalized beam power

$\hat{P}^{LOCKED}=0.765,\ \hat{P}^{MISALIGNED}=0.775,\ \mathcal{L}=89.6\ \mathrm{ppm}$

• "ETM_YAW_L_DEMOD_I_OUTPUT" was little noisy even when the arm was locked.
• The reflected beam power when locked was higher than when misaligned. It seemed strange for me at first. Johannes suggested that it was caused by over-coupling cavity. It is possible when r_{ETMY}>>r1_{ITMY}.
• My first (wrong) measurement said the arm loss was negative(!). That was caused by lack of enough misalignment of another arm mirrors. If you don't misalign ITMX enough then the beam or scattered light from X-arm would bring bad. The calculated negative loss would be appeared only when $\frac{\hat{P}^{LOCKED}}{\hat{P}^{MISALIGNED}} > 1 + T_{ITM}$
• Error should be considered.
• Parameters given this time should be measured again.
14251   Sat Oct 13 20:11:10 2018 yukiUpdateComputer Scripts / Programsloss measurements
 Quote: the script "armloss_AS_calc.py", "ETM_YAW_L_DEMOD_I_OUTPUT" was little noisy even when the arm was locked. The reflected beam power when locked was higher than when misaligned. It seemed strange for me at first. Johannes suggested that it was caused by over-coupling cavity. It is possible when r_{ETMY}>>r1_{ITMY}.

Some changes were made in the script for getting the signals of beam power:

• The script sees "C1:ASS-X(Y)ARM_ETM_PIT/YAW_L_DEMOD_I_OUTPUT" and stops running until the signals become small, however some offset could be on the signal. So I changed it into waiting until (DEMOD - OFFSET) becomes small. (Yesterday I wrote ETM_YAW_L_DEMOD_I_OUTPUT was about 15 and was little noisy. I was wrong. That was just a offset value.)
• I added a code which stops running the script when the power of transmitted IR beam is low. You can set this threshold. The nominal value of "C1:LSC-TRX(Y)_OUT16" is 1.2 (1.0), so the threshold is set 0.8 now.

In the yesterday measurement the beam power of ASDC is higher when locked than when misaligned and I wrote it maybe caused by over-coupled cavity. Then I did a calculation as following to explain this:

• assume power transmissivity of ITM and ETM are 1.4e-2 and 1.4e-5.
• assume loss-less mirror, you can calculate amplitude reflectivity of ITM and ETM.
• consider a cavity which consists two mirrors and is loss-less, then $\frac{E_{r}}{E_{in}} = \frac{-r_1+r_2e^{i\phi}}{1-r_1r_2e^{i\phi}}$ holds. r1 and r2 are amplitude reflectivity of ITM and ETM, and E is electric filed.
• Then you can calculate the power of reflected beam when resonated and when anti-resonated. The fraction of these value is $\frac{P_{RESONANT}}{P_{ANTI-RESO}} = 0.996$, which is smaller than 1.
• I found this calculation was wrong! Above calculatation only holds when cavity is aligned, not when misaligned. 99.04% of incident beam power reflects when locked, and (100-1.4)% reflects when misaligned. The proportion is P(locked)/P(misaligned)=1.004, higher than 1.

14254   Mon Oct 15 10:32:13 2018 yukiUpdateComputer Scripts / Programsloss measurements

I used these values for measuring armloss:

• Transmissivitity of ITM = 1.384e-2 * (1 +/- 1e-2)
• Transmissivitity of ETM = 13.7e-6 * (1 +/- 5e-2)
• Mode-Matching efficiency of XARM = 0.912 * (1 +/- 2e-2)
• Mode-Matching efficiency of YARM = 0.867 * (1 +/- 2e-2)
• modulation depth m1 (11MHz) = 0.179 * (1 +/- 2e-2)
• modulation depth m2 = 0.226 * (1 +/- 2e-2),

then the uncertainties reported by the individual measurements are on the order of 6 ppm (~6.2 for the XARM, ~6.3 for the YARM). This accounts for fluctuations of the data read from the scope and uncertainties in mode-matching and modulation depths in the EOM. I made histograms for the 20 datapoints taken for each arm: the standard deviation of the spread is over 6ppm. We end up with something like:

XARM: 123 +/- 50 ppm
YARM: 152+/- 50 ppm

This result has about 40% of uncertaintities in XARM and 33% in YARM (so big... ).

In the previous measurement, the fluctuation of each power was 0.1% and the fluctuation of P(Locked)/P(misaligned) was also 0.1%. Then the uncertainty was small. On the other hand in my measurement, the fluctuation of power is about 2% and the fluctuation of P(Locked)/P(misaligned) is 2%. That's why the uncertainty became big.

We want to measure tiny value of loss (~100ppm). So the fluctuation of P(Locked)/P(misaligned) must be smaller than 1.6%.

(Edit on 10/23)
I think the error is dominated by systematic error in scope. The data of beam power had only 3 degits. If P(Locked) and P(misaligned) have 2% error, then
$\frac{P_L}{P_M}\frac{1}{1+T_{\mathrm{ITM}}} = 0.99(3)$.
You have to check the configuration of scope.

Attachment 1: XARM_20181015_1500.pdf
Attachment 2: YARM_20181015_1500.pdf
14258   Tue Oct 16 00:44:29 2018 yukiUpdateComputer Scripts / Programsloss measurements

The scripts for measuring armloss are in the directory "/opt/rtcds/caltech/c1/scripts/lossmap_scripts/armloss_scope".

• armloss_derefl_asdcpd_scope.py: gets data and makes ascii file.
• armloss_AS_calc.py: calculates armloss from selected a set of files.
• armloss_calc_histogram.py: calculates armloss from selected files and makes histogram.
14269   Fri Nov 2 19:25:16 2018 gautamUpdateComputer Scripts / Programsloss measurements

Some facts which should be considered when doing this measurement and the associated uncertainty:

1. When Johannes did the measurement, there was no light from the AS port diverted to the OMC. This represents ~70% loss in the absolute amount of power available for this measurement. I estimate ~1W*Tprm * Ritm * Tbs * Rbs * Tsrm * OMCsplit ~ 300uW which should still be plenty, but the real parameter of interest is the difference in reflected power between locked/no cavity situations, and how that compares to the RMS of the scope readout. For comparison, the POX DC light level is expected to be ~20uW, assuming a 600ppm AR coating on the ITMs.
2. Even though the reflection from the arm not being measured may look like it's completely misaligned looking at the AS camera, the PDA520 which is used at the AS port has a large active area and so one must check on the oscilloscope that the other arm is truly misaligned and not hitting the photodiode to avoid interference effects artifically bloating the uncertainty.
3. The PDA255 monitoring the MC transmission has a tiny active area. I'm not sure the beam has been centered on it anytime recently. If the beam is not well centered on that PD, and you normalize the measurements by "MC Transmission", you're likely to end up with larger error.
 Quote: This result has about 40% of uncertaintities in XARM and 33% in YARM (so big... ).
12874   Wed Mar 8 18:18:51 2017 johannesUpdateComputer Scripts / Programsloss script

I started a loss script on Donatella that will scan the beam spot across ETMY, recording the reflected power from the arm via the networked scope at the AS port until later tonight (should be done by 9 pm). ITMX is currently strongly misaligned for this, but can be restored with the saved values. I mostly adapted the mapping scipts for the scope readout but still have to iron out a few kinks, which is why I'm running this test. In particular, I still need to calibrate how much the spot actually moves on the optic and control the ASS demodulation offsets to keep the beam stationary on ITMY.

12879   Thu Mar 9 22:28:11 2017 johannesUpdateComputer Scripts / Programsloss script

loss map script running on Rossa that moves the beam on ETMX. Yarm was misaligned for this, most recent PIT and YAW settings were saved beforehand. This will take until late at night, I estimate 2-3 am.

 Quote: I started a loss script on Donatella that will scan the beam spot across ETMY, recording the reflected power from the arm via the networked scope at the AS port until later tonight (should be done by 9 pm). ITMX is currently strongly misaligned for this, but can be restored with the saved values. I mostly adapted the mapping scipts for the scope readout but still have to iron out a few kinks, which is why I'm running this test. In particular, I still need to calibrate how much the spot actually moves on the optic and control the ASS demodulation offsets to keep the beam stationary on ITMY.

12880   Fri Mar 10 11:37:25 2017 gautamUpdateComputer Scripts / Programsloss script

This was still running at ~9.30am today morning, at which point I manually terminated it after confirming with Johannes that it was okay to do so. Judging by the StripTool traces in the control room, the mode cleaner remained locked for most of the night, there should be plenty of usable data...

Note that I re-aligned the Y-arm (to experiment further with photo-taking) at about 9.30am, so the data after this time should be disregarded...

 Quote: loss map script running on Rossa that moves the beam on ETMX. Yarm was misaligned for this, most recent PIT and YAW settings were saved beforehand. This will take until late at night, I estimate 2-3 am.

12882   Fri Mar 10 19:48:56 2017 johannesUpdateComputer Scripts / Programsloss script

Loss script running again, on Pianosa this time. Due to an oversight in the code the beam wasn't actually moved across ETMY last night. This time I confirmed that the correct offset value is written as a demodulation parameter to the correct mirror degree of freedom. Script will probably run through the night. Yarm is currently misaligned but previous alignment was saved.

12883   Sat Mar 11 20:11:58 2017 johannesUpdateComputer Scripts / Programsloss script

Yarm script running on Pianosa. Still working on visualization of the ETMX lossmap.

 Quote: Loss script running again, on Pianosa this time. Due to an oversight in the code the beam wasn't actually moved across ETMY last night. This time I confirmed that the correct offset value is written as a demodulation parameter to the correct mirror degree of freedom. Script will probably run through the night. Yarm is currently misaligned but previous alignment was saved.

13307   Mon Sep 11 12:56:40 2017 johannesUpdateComputer Scripts / Programslossmap attempts

I was trying to get a lossmap measurement over the weekend but had some trouble first with the IMC and then with the PMC.

For the IMC: It was a bit too misaligned to catch and maintain lock, but I had a hard time improving the alignment by hand. Fortunately, turning on the WFS quickly once it was locked restored the transmission to nominal levels and made it maintain the lock for longer, but only for several minutes, not enough for a lossmap scan (can take up to an hour). Using the WFS information I manually realigned the IMC, which made locking easier but wouldn't help with staying locked.

For the PMC: The PZT feedback signal had railed and the PMC had been unlocked for 8+ hours. The PMC medm screen controls were generally responsive (I could see the modes on the CCDs changing) but I just couldn't get it locked. c1psl was responding to ping but refusing telnet so I keyed the crate, followed by a burt restore and finally it worked.

After the PMC came back the IMC has already maintained lock for more than an hour, so I'm now running the first lossmap measurements.

239   Tue Jan 15 13:15:27 2008 tobinUpdateEnvironmentlots of noise
They're throwing concrete around at the construction site.
8083   Thu Feb 14 08:29:41 2013 SteveUpdateIOOlow MC1 OSEM voltage

MC1 -  LR, LL, UL & UR  OSEMs should be adjusted to get  1.2V

Attachment 1: Feb14_2013.png
8107   Tue Feb 19 09:37:23 2013 SteveUpdateIOOlow MC1 OSEM voltage

See TT DB25 pin swapping   elog#7869

Attachment 1: MC1_MC3.png
Attachment 2: MC1_MC3_.png
9473   Sat Dec 14 13:46:54 2013 DenUpdateIOOlow bandwidth MCL loop

Last time we designed MCL loop with UGF ~ 30 Hz and I think, it was hard to lock the arm because of large frequency noise injected to IFO.

This time I made a low bandwidth MCL loop with UGF=8 Hz. MCL error RMS is suppressed by factor of 10 and arms lock fine.

Attached plots show MCL OL, MCL error suppression and frequency noise injection to arms.

It is interesting that spectrum of arms increases below 1 Hz meaning that IMC sensing noise dominates in this range.

I did not include the loop into the IMC autolocker. I think it is necessary to turn it on only during day time activity and when beatnote is moving too much during arm stabilization.

Attachment 1: MCL_OL.pdf
Attachment 2: MCL_ERR.pdf
Attachment 3: MCL_ARMS.pdf
Attachment 4: MCL_MEDM.png
962   Thu Sep 18 09:30:12 2008 steveUpdateGenerallow noise metal film resistors are in
Low noise metal film resistor and capacitor kits from www.garrettelec.com are in.

manufacturer: Dale, 289 values, 25ea, surface mount,1206, 0.1% from 100 to 100K, 1/8 or 1/4W
additional values below 100 ohm and above 100K were purchased from Mouser with the same Dale specification

Ceramic capacitor kit from AVX
67 values, 25ea, surface mount, 1206 from 1.0 pF up

atm2: our new storage cabinet pick and put together by Jenni
Attachment 1: mfr&cap.png
Attachment 2: storcab.png
10112   Mon Jun 30 10:06:39 2014 SteveUpdateVAClow on pneumatic pressure of vacuum valves

This morning valve condition: V1, VM1, V4 and V5 valves were closed. IFO pressure rose to 1.3 mTorr

It was caused by low N2 pressure.  Our vacuum valves are moved-controlled by 60-70 PSI of nitrogen.

When this supply drops below 50-60 PSI the interlock closes V1 valve. This is the minimum pressure required to move the large valves.

It is our responsibility to check the N2 cylinder pressure supply.

The vacuum valve configuration is back to VAC. NORMAL,  CC1  4.8E-6 Torr

PS: Bob says that the second cylinder was full this morning, but the auto-switch over did not happen.

Attachment 1: runoutofN2.png
Attachment 2: lowN2.png
Attachment 3: N2d100.png
9580   Tue Jan 28 09:51:47 2014 SteveUpdateIOOlow power pointing

PSL output is stable.

Attachment 1: IOO4dlowpr.png
6750   Mon Jun 4 23:48:43 2012 jenneUpdateGreen Lockinglowered gain

We're trying to do a yarm measurement....before I forget, I want to write this down...

I changed the gain of each of the top 2 SR560's down, by a factor of 2.  This made the overload lights quit coming on.

2877   Tue May 4 13:14:43 2010 josephbUpdateCDSlsc.mdl and ifo.mdl to build (with caveats)

I got around to actually try building the LSC and IFO models on megatron.  Turns out "ifo" can't be used as a model name and breaks when trying to build it.  Has something to do with the find and replace routines I have a feeling (ifo is used for the C1, H1, etc type replacements throughout the code).  If you change the model name to something like ifa, it builds fine though.  This does mean we need a new name for the ifo model.

Also learned the model likes to have the cdsIPCx memory locations terminated on the inputs if its being used in a input role (I.e. its bringing the channel into the model).  However when the same part is being used in an output role (i.e. its transmitting from the model to some other model), if you terminate the output side, it gives errors when you try to make.

Its using the C1.ipc file (in /cvs/cds/caltech/chans/ipc/) just fine.  If you have missing memory locations in the C1.ipc file (i.e. you forgot to define something) it gives a readable error message at compile time, which is good.  The file seems to be being parsed properly, so the era of writing "0x20fc" for block names is officially over.

2885   Thu May 6 11:34:35 2010 robUpdateCDSlsc.mdl and ifo.mdl to build (with caveats)

 Quote: I got around to actually try building the LSC and IFO models on megatron.  Turns out "ifo" can't be used as a model name and breaks when trying to build it.  Has something to do with the find and replace routines I have a feeling (ifo is used for the C1, H1, etc type replacements throughout the code).  If you change the model name to something like ifa, it builds fine though.  This does mean we need a new name for the ifo model. Also learned the model likes to have the cdsIPCx memory locations terminated on the inputs if its being used in a input role (I.e. its bringing the channel into the model).  However when the same part is being used in an output role (i.e. its transmitting from the model to some other model), if you terminate the output side, it gives errors when you try to make. Its using the C1.ipc file (in /cvs/cds/caltech/chans/ipc/) just fine.  If you have missing memory locations in the C1.ipc file (i.e. you forgot to define something) it gives a readable error message at compile time, which is good.  The file seems to be being parsed properly, so the era of writing "0x20fc" for block names is officially over.

I suggest "ITF" for the model name.

6332   Tue Feb 28 16:12:59 2012 DenUpdateAdaptive Filteringlunch talk

Just to be clear what I said at the meeting, I write all this down here. Adaptive filtering of real signals (MC_F and GUR1_X) with all noises inside is

This is offline filtering but with real signals and with the C-code that is compiled at the 40m now. We can reduce the MC_F signal by ~100 below 10 Hz, but  the problem is that reducing the adaptation gain, the error increases. As a result when we move towards FxLMS algorithm with AA, AI and downsampling, we have to take the gain equal to ~1e-2 and we do not reduce any noise.

The second demonstration of this problem is static Wiener filtering. This is the result

We can see that adaptive filtering outperforms the "optimal" filtering. This is because an adaptive filter can follow the changes of coefficients immediately while the Wiener filter averages them. This is the mathematical formulation:

mcl_real = coeff _real* seismic_noise_real + other_noise

mcl_real - the real length of the MC,

coeff_real - real coefficients, that represent the transfer function between seismic noise and MC length,

other_noise - noise uncorrelated to the seismic noise seismic_noise_real

But in the world of our measured signals we have the equation

mcl_measured = coeff * seismic_noise_measured + other_noise

mcl_measured = TF_mcl * mcl_real

seismic_noise_measured = TF_seis * seismic_noise_real

where TF_mcl and TF_seis - transfer functions from the real world to measurements.

It seems to me that TF_mcl or TF_seis are not constants and for that reason the TF between measured seismic noise and mcl is not constant. But it is exactly what an adaptive or Wiener filter tries to define:

coeff(time) = average(coeff(time)) + delta(coeff(time))

The result of applying average(coeff) is the green line in the Figure 2 - error after applying the Wiener filtering.

delta(coeff) - the changing part of the transfer function is caught by the adaptive filtering. The lower the gain, the lower is the capability of adaptive filter to catch these changes. Theoretically. the error after applying adaptive filter can be presented like this:

E(error*error) = E(other_noises*other_noises) + 1/(2-mu)*mu*E(other_noises*other_noises)  + 1/ {mu*(2-mu)} * Tr(Q) * A

Q - covariance matrix of delta(coeff)

A - norm of the seismic signal

The first term in this equation is the dispersion of other noises, the second term is the error of the adaptive filter due to non-zero gain, the third term is due to the changes in the transfer function - we can see that it is proportional to 1/mu. This term explains why the error increases while mu decreases.

Now I'm looking for the part in the path of the signals where the transfer function can change. As I mentioned above, this is not a change in the real world, it is the change in the measured signlals. My first guess is the quantization error - we do not have not enough counts. If this is not the case, I'll move to other things of the signal path.

5008   Wed Jul 20 22:16:27 2011 Ishwita, ManuelUpdateElectronicslying seismometer cable and plugging it

We laid the cable along the cable keeper from the BACARDI seismometer to the rack 1X6, the excess cable has been coiled under the X arm.

We plugged the cable to the seismometer and to the seismometer electronics box in rack 1X6. We also plugged the AC power cable from the box to an outlet in rack 1X7 (because the 1X6 outlets are full)

With the help of a function generator we tested the following labeled channels of AA board...

2, 3, 11, 12, 14, 15, 16, 18, 19, 20 and 24

that are the channels that can be viewed by the dataviewer, also the channel 10 can be viewed but it's labeld BAD so we cannot use it.

We leveled the seismometer and unlocked it, and saw his X,Y,Z velocity signals with an oscilloscope.

ELOG V3.1.3-