40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 306 of 335  Not logged in ELOG logo
ID Date Author Type Category Subject
  1480   Tue Apr 14 02:59:02 2009 YoichiUpdateLockingPower up until 26
Yoichi, Peter,

With careful adjustments of the common mode gains, we were able to go up to arm power = 26, sort of robustly (more 50% chance).
At this arm power level, the common mode loop shape still looks good. But the interferometer loses lock easily.
I have to check other DOFs, but the interferometer does not stay locked long enough.
Today, lock losses of the IFO were associated with the lock loss of the PMC whereas the FSS stayed locked.
Probably the AO path got large kicks, which could not be handled by the PMC PZT.

The cause for the IFO lock loss is under investigation.
  1479   Mon Apr 13 18:57:03 2009 AlbertoFrogsComputersGPIB/ETH Interface Troubles

I really don't understand why my programs that I used to use to get data from the HP Spectrum Analyzer and the Marconi frequency generator don't work anymore.

I spent hours trying to debug the code but I can't sort the problem out.

The main problem seem to be with the function recv from the socket library. Somehow it can't anymore get any data from the instruments. The thing I can't understand, though, is that if called directly from the python terminal it works fine!

In particular the problem is with the following lines in my code:

netSock.send("mkpk;mka?\n")
netSock.send("++read eoi\n")
tmp = netSock.recv(1024)

Tried a lot of tickering but it didn't work.

I attach the two scripts I've been using. One (sweepfrequencyPRC.py) calls the other (HP4395PRC.py).

They worked egregiously for weeks in the past. Don't know what happened since then.

Attachment 1: sweepfrequencyPRC.py
## sweepfrequency.py [-f filename] [-i ip_address] [-a startFreq] [-z endFreq] [-s stepFreq] [-m numAvg]
#
## This script sweeps the frequency of a Marconi local oscillator, within the range
## delimited by startFreq and endFreq, with a step set by stepFreq. An arbitary
## signal is monitored on a HP8590 spectrum analyzer and the scripts records the
## amplitude of the spectrum at the frequency injected by the Marconi at the moment.

## The GPIB address of the Marconi is assumed to be 17, that of the HP Spectrum Analyzer to be 18

## Alberto Stochino, October 2008
... 53 more lines ...
Attachment 2: HP8590PRC.py
# This function provides the measuremeent of the peak amplitude on the spectrum analyzer
# HP8590 analyzer while sweeping the excitation frequency on the function generator.
#
# Alberto Stochino 2008

import re
import sys
import math
from optparse import OptionParser
from socket import *
... 70 more lines ...
  1478   Mon Apr 13 17:55:37 2009 JenneUpdatePSLPMC LO Mon Calibration

I have calibrated the PMC LO Mon (C1:PSL-PMC_LODET) on the PMC's EPICS screen, by inputting different RF LO levels into the LO input of the PMC servo board.

 

Since the RF output adjust slider on the PMC's Phase Shifter screen doesn't do a whole lot (see elog 1471), I used a combination of attenuators and the slider to achieve different LO levels. I measured the level of the attenuated RF out of the LO board using the 4395A in spectrum analyzer mode, with the units in dBm, with 50dB attenuation to make it stop complaining about being overloaded.  For each row in the table I measured the RF level using the 4395, then plugged the cable back into the PMC servo board to get the EPICS screen's reading.

The last 2 columns of the table below are the 'settings' I used to get the given RF LO level. 

RF LO Input to PMC Servo Board [dBm] LO Mon on EPICS Screen [no units] RF Output Adjust Slider [V] Attenuators used [dB]
16.004 +- 0.008 0.1200 +- 0.0003 0 0
15.001 +- 0.004 0.0708 +- 0.0008 0 1
14.079 +- 0.008 0.0318 +- 0.0001 8 1
13.002 +- 0.006 0.0126 +- 0.0004 0 3
11.992 +- 0.010 0.0024 +- 0.0008 0 4
10.994 +- 0.010 -0.0024 +- 0.0003 0 4+1=5
9.993 +- 0.008 -0.0047 +- 0.0007 0 3+3=6

 

When the new mixers that Steve ordered come in (tomorrow hopefully), I'll put in a Level 13 mixer in place of the current Level 23 mixer that we have.  Also, Rana suggested increasing the gain on the op-amp which is read out as the LO Mon so that 13dBm looks like 1V.  To do this, it looks like I'll need to increase the gain by ~80.  

Attachment 1: LOmonCalibration.png
LOmonCalibration.png
  1477   Mon Apr 13 08:59:57 2009 steveUpdatePSLmixers on order

Quote:

Quote:

I then changed the RF Output Adjust slider in increments of 0.5, and measured the peak-to-peak values on the scope. In the table and on the plots, I've taken into account the 12dB attenuation. i.e I actually measured 964mV, so 964mV*10^.6 = 3838mV.


3.8Vpp is about 16dBm.
The mixer for the PMC demodulator is level 23. So 16dBm is insufficient.
What is the level of the new mixer Steve ordered ? 13 ?



I ordered mixers level 13, 17 on Friday and level 23 now.
They should be here Tuesday

NOTE: level 23 power is illegal to use in the 40m lab
They get hot
  1476   Sun Apr 12 19:31:43 2009 ranaSummaryElectronicsAmphony 2500 Headphones
We bought the Amphony 2500 Digital Wireless headphones recently. The other cheapo headphones we have are OK for control room use, but have a lot of noise
and are, therefore, not useful for noise hunting.

The new digital ones are pretty much noise-free. With the transmitter next to rosalba, you can walk halfway down the east arm and all around the MC area
before the reception goes bad. For real noise hunting, we will want to put the transmitter next to the BS chamber and take an analog pickoff from the DC PDs.

In the OMC diagram, we should put an AUDIO filterbank and wire it to the DAC so that we can do arbitrary IIR filtering on the audio signal.
  1475   Sun Apr 12 19:27:20 2009 ranaUpdatePSLPMC LO Calibration

Quote:

3.8Vpp is about 16dBm.
The mixer for the PMC demodulator is level 23. So 16dBm is insufficient.
What is the level of the new mixer Steve ordered ? 13 ?


Since Steve and Jenne were on it, I'm sure they ordered the optimum values...

From the table, it looks like the drive level adjuster is busted. Its not supposed to just give a
1-2 dB change over the full range. We'll have to think about what exactly to do, but we should
probably install the level 13 mixer and put in the right attenuation to make the LO be ~13.5 dBm
including the filter. Also need to calibrate the LO readback on the board like what Peter did for
the FSS.
  1474   Sun Apr 12 01:19:30 2009 YoichiConfigurationComputersNew FE codes for suspensions not successful
Alex recompiled the suspension FE codes for c1susvme1 and c1susvme2 to fix the denormalization problem.
The new modules are in
/cvs/cds/caltech/users/alex/cds/rts/src/fe/40m/losLinux1.o
/cvs/cds/caltech/users/alex/cds/rts/src/fe/40m/losLinux2.o

I tried them today, but c1susvme1 did not work with the new code while c1susvme2 seemed to run ok.
So I reverted the modules (losLinux1.o and losLinux2.o) to the original ones.
The original modules are also backed up as losLinux1.o.11Apr09 and losLinux2.o.11Apr09 in the corresponding target directories.

I reported the problem to Alex.
  1473   Sat Apr 11 00:45:41 2009 YoichiUpdatePSLPMC LO Calibration

Quote:

I then changed the RF Output Adjust slider in increments of 0.5, and measured the peak-to-peak values on the scope. In the table and on the plots, I've taken into account the 12dB attenuation. i.e I actually measured 964mV, so 964mV*10^.6 = 3838mV.


3.8Vpp is about 16dBm.
The mixer for the PMC demodulator is level 23. So 16dBm is insufficient.
What is the level of the new mixer Steve ordered ? 13 ?
  1472   Fri Apr 10 19:10:53 2009 JenneUpdateGeneralXarm locked?

I don't know who left the X arm locked, but I just ran the Align Full IFO script, so everything is good in case Yoichi/someone comes in to lock the IFO this weekend.

  1471   Fri Apr 10 19:09:48 2009 JenneUpdatePSLPMC LO Calibration
I measured the RF LO output level from the PMC's LO board which goes directly into the LO input on the PMC Servo board. This goes hand-in-hand with Rana's thoughts
that we might be giving the PMC mixer a too-low LO value, and we might need to switch out the mixer. Steve ordered some new mixers today to try out.

The RF Output Adjust slider (on the C1:PSL_PMC_PS screen) goes from 0-10V; The nominal value (or at least the value I found it at today) is 2.014V.

To measure the RF level: I unlocked the Mode Cleaner and turned off the ISS servo per Yoichi's suggestion. I then unplugged the input to the PMC servo board's LO input,
and put that cable into a 300MHz 'scope, with 12dB attenuation. The 'scope was AC coupled, with the input set to 50Ohms.

I then changed the RF Output Adjust slider in increments of 0.5, and measured the peak-to-peak values on the scope. In the table and on the plots, I've taken into account
the 12dB attenuation. i.e I actually measured 964mV, so 964mV*10^.6 = 3838mV.


RF Output AdjustOutput measured on scopeOscillator Output Monitor
[V]
[Vpp]
[no units given on MEDM screen]
All \pm 0.0159 all of this column is NEGATIVE
0.00003.8380.007
0.50003.8540.007
1.00003.8380.006
1.50003.8380.007
2.00003.8380.006
2.50003.8380.007
3.00003.8380.007
3.50003.8380.007
4.00003.8380.007
4.50003.8220.007
5.00003.8220.012
5.50003.7900.076
6.00003.7580.257
6.50003.6940.555
7.00003.6150.931
7.50003.5351.277
8.00003.4561.532
8.50003.3921.709
9.00003.3441.829
9.50003.3121.908
10.00003.2961.966


I think it's kind of funky that it's so flat for ~half the slider. Also, the third column includes the Oscillator Output Monitor value from the MEDM screen at various RF Adjust slider values. All of these should be negative (i.e. -0.007), but the TABLE function doesn't like "-" signs. I don't know if this information is degenerate with the 'scope measurements, or if it's an indicator of what (might be) wrong.

After finishing, I plugged the cable back into the PMC servo board as it was, turned back on the ISS and relocked the PMC and the MC.
Attachment 1: RFSliderAdjustCalib.png
RFSliderAdjustCalib.png
Attachment 2: RFSliderAdjustCalibWithOsc.png
RFSliderAdjustCalibWithOsc.png
  1470   Fri Apr 10 18:11:18 2009 JenneUpdatePSLISS has a bad cable?

[Rob, Jenne]

I noticed that the ISS Mean Value and CS Saturation were both RED and unhappy. (The alarms were going off, and they were both red on the MEDM screen).  None of the MEDM settings seemed off kilter, so we went out to take a look at the PSL table. 

Rob checked that light is indeed going to both of the ISS photodiodes (Morag and Siobhan).  Next we checked that all the cables were good, and that the power to the ISS box was plugged in. In this process, Rob wiggled all the cables to check that they were plugged in.  Just after doing this, the Mean Value and CS Sat were happy again.  Rob thinks the current shunt connection might be bad, but we don't really know which one it was since all of the cables were jiggled between our checking the screens. 

Right now, everything is happy again, but as with all bad-cabling-problems, we'll probably see this one again.

 

 

I don't know why in particular the connection decided to spaz out this afternoon...I don't think anyone opened the PSL table before Rob and I went to investigate.  I was working on the PMC servo (checking the LO levels...to be posted in a couple minutes), but didn't have anything to do with the ISS. After I was done, I put everything back, and locked the PMC and the MC, and everything was good, until some time later when the ISS started flipping out.

  1469   Fri Apr 10 04:54:24 2009 YoichiUpdateLockingREFL_DC for CARM
Suggested by Rob and Rana's simulation works, I tried to use REFL_DC for the CARM error signal.

My current guess for the cause of the 3.8kHz peak is the following.
The AF sidebands created by the laser frequency drive are reflected by the IFO to the symmetric port if the arms are perfectly symmetric.
However, if there is asymmetry in the arm cavities (such as loss imbalance, ITM transmission difference etc) the sidebands are scattered from the common mode to the differential mode. If our CARM error signal has a large response also to the differential mode (i.e. DARM), the loop is closed. At the DARM RSE frequency, the AF sideband in the differential mode is enhanced and creates a peak in the CARM response.
What Rob's plots show is that PO_DC has a larger response to DARM than REFL_DC has. You can see this from the curves of CARM offset = 0 (black ones).
When the CARM offset is zero, the CARM signal should go to zero. Therefore, the black curves show the residual DARM response. In the case of PO_DC, the black curve is very large suggesting a large DARM coupling.

Now I changed the cabling at the LSC rack to put REFL_DC into the REFL2 input of the CM board.
The REFL_DC signal is put through a 160kHz RC LPF and split to the ADC and the CM board (AC coupled by a large capacitor).
I modified the cm_step script to use PD4_DC as CARM error signal. (The old script is saved as cm_step.podc).
Since the polarity of the REFL_DC signal is opposite to the PO_DC, I flipped the polarity switch of the CM board.
This will flip the sign of the RF CARM signal because this switch flips the polarity of the both inputs.
We have to flip the sign of the RF CARM signal with the SR560 sitting on the LSC rack, which I haven't done yet.

With some tweaks of the gains and addition of two lag-lead filters to PD4_DC, I was able to completely hand off the CARM error signal to REFL_DC.
The attached plot shows the AO path loop gain at arm power = 7. The 3.8kHz is gone, although there is some phase ripple around 3.8kHz.

Since the gain behavior of the REFL_DC is different from the PO_DC, I'm now working on the power up part of the script, adjusting the gains as the power goes up.
Attachment 1: AO-loop-gain-CARM-REFL_DC.png
AO-loop-gain-CARM-REFL_DC.png
  1468   Fri Apr 10 03:10:08 2009 ranaSummaryLockingLaser PM to REFL-DC transfer functions at multiple CARM offsets

I hereby award the previous rainbow transfer functions the plot innovation of the month award for its use of optical frequency to denote CARM offset.

The attached movie here shows the sensing matrix (minus MICH) as a function of CARM offset. There are 3 CARM signals plotted:

GREEN - tonights starting CARM signal - REFL_DC

RED - my favorite CARM signal - REFL 166 I

CYAN - runner up CARM signal - POX 33 I

  1467   Fri Apr 10 01:24:08 2009 ranaUpdateComputersallegra update (sort of)

I tried to play an .avi file on allegra. In a normal universe this would be easy, but because its linux I was foiled.

The default video player (Totem) doesn't play .avi or .wmv format. The patches for this work in Suse but not Fedora. Kubuntu but not CentOS, etc.I also tried installing Kplayer, Kaffeine, mplayer, xine, Aktion, Realplay, Helix, etc. They all had compatibility issues with various things but usuallylibdvdread or some gstreamer plugin.So I pressed the BIG update button. This has now started and allegra may never recover. The auto update wouldn't work in default mode becauseof the libdvdread and gstreamer-ugly plugins, so I unchecked those boxes. I think we're going to have this problem as long as we used any kind ofadvanced gstreamer stuff for the GigE cameras (which is unavoidable).

 

  1466   Thu Apr 9 23:20:35 2009 robSummaryLockingLaser PM to REFL-DC transfer functions at multiple CARM offsets

Quote:

I've plotted some transfer functions showing the response at POB DC to laser frequency (phase) noise.  There are transfer functions for multiple CARM offsets.  Basically, the transfer function looks like the DARM transfer function when the CARM is at zero offset, and is super-wonky elsewhere.  POB-DC is not a good CARM signal for intermediate stages of lock acquisition in a dual-recycled interferometer.  We should look into switching back to REFL-DC.

 

 Here are the corresponding transfer functions for REFL-DC.

Attachment 1: CARMoffs1_r.png
CARMoffs1_r.png
Attachment 2: CARMoffs2_r.png
CARMoffs2_r.png
Attachment 3: CARMcarpet_r.png
CARMcarpet_r.png
  1465   Thu Apr 9 23:11:27 2009 robSummaryLockingLaser PM to PO-DC transfer functions at multiple CARM offsets

I've plotted some transfer functions showing the response at POB DC to laser frequency (phase) noise.  There are transfer functions for multiple CARM offsets.  Basically, the transfer function looks like the DARM transfer function when the CARM is at zero offset, and is super-wonky elsewhere.  POB-DC is not a good CARM signal for intermediate stages of lock acquisition in a dual-recycled interferometer.  We should look into switching back to REFL-DC.

 

Attachment 1: CARMoffs1.png
CARMoffs1.png
Attachment 2: CARMoffs2.png
CARMoffs2.png
Attachment 3: CARMcarpet.png
CARMcarpet.png
  1464   Thu Apr 9 20:56:12 2009 YoichiHowToGeneralRestore the alignment. Write elog entries.
I often find that the mirrors are left mis-aligned (like in X-arm mode) when I come in for the locking, including tonight.
As Rob stated repeatedly in the past elog, leaving the mirrors mis-aligned for a long time without a reason is an abomination.
It will cause a slow drift of the mirrors and the lock acquisition work is severely slowed down as I have to run the alignment script many times.

I also found that the GPIB-Ethernet box (named teofila) was taken away from the SR785 hooked up to the CM board.
I found it connected to Alberto's setup. Instead, another GPIB box was left on the SR785 but not connected.
I couldn't find any elog entry about this.
This is totally unacceptable.
The SR785 has been used as a very important tool for monitoring the AO path loop gain during the power up.
You can use it if you need, but you have to note it in elog.

The other GPIB box left on the SR785 had a wrong name labeled on it. It had a name "ERMINIA", but the IP address written next to the name was actually assigned to "crocetta" in the DNS server on linux1. I don't know who made the label. I put a new and correct label on it.
Now I'm using crocetta for the SR785 so Alberto can keep using teofila.

Anyway, I think recently people are lazy about elog.
Whatever work you did, please put it in the elog even if you think it is trivial.
I also would like to see more detailed elog entries from people. Many of the recent elog entries are too simple or superficial that it is hard for other people to figure out what was really done.
  1463   Thu Apr 9 12:23:49 2009 peteUpdateLockingtuning ETM common mode

Pete, Yoichi

Last night, we put the IFO in FP Michelson configuration.  We took transfer functions of CARM and DARM, first using CM excitations directly on the ETMs, and then using modulations of the laser frequency via MC excitation.  We found that there was basically no coupling into DARM using the MC excitation, but that there was coherence in DARM using the ETM excitation.  Therefore, I tuned the ETM common mode in the output matrix.  I did this by taking transfer functions of PD1_Q with PD2_I (see attached plot).  I changed the  drdown_bang script to set C1:LSC-BTMTRX_14 0.98 and C1:LSC-BTMTRX_24 1.02.

Attachment 1: FPMI-DARM-CARM-ETM-fineScan.pdf
FPMI-DARM-CARM-ETM-fineScan.pdf
  1462   Thu Apr 9 11:27:19 2009 steveUpdateVACvac gauge reading problem

Cold cathode gauge CC4  is reading normal.

CC1 is glitching, it is probably dirty.

CC2 is fluctuating too much and it is cutting out for 6-7 minutes. It must be insulated by deposits and there is no emission current.

I think the same goes for P1

They will have to be replaced at the next vent

Attachment 1: vacgflsec.jpg
vacgflsec.jpg
Attachment 2: vacgflmin.jpg
vacgflmin.jpg
  1461   Wed Apr 8 18:46:50 2009 ranaConfigurationGeneralDMF, SVN, x2mc, and matlab

While waiting for the installation of the 32-bit Matlab 2009a to finish, I tried updating our seisBLRMS.m code.

Although DMF is in SVN, we forgot to check it out and so the directory where we have been doing our mods is not a working copy and our changes have not been captured: Shame.

We will probably have to wipe out the existing SVN trunk of DMF and re-import the directory after checking with Yoichi for SVN compliance.

Also wrote a script: LSC/x2mc, which will transition from regular ETM based X Arm locking to the MC2 based locking. It ran once OK, but I get a segfault on the 'trianglewave' which was trying to run the 'ezcastep' perl script which was calling 'ezcastep.bin'.

I also restarted the seisBLRMS.m on a terminal on Mafalda in the new Matlab 2009a to see if it loses its NDS connection like it did with 2007a. I also reduced the 'delay' parameter to 4 minutes and the 'interval' to 1 minute. This should be so that the total delay is now 5 minutes between seismic noise and seismic trend.

  1460   Wed Apr 8 18:18:33 2009 ranaConfigurationComputersLSC code recompiled with a fix for denormalization problem
Below is the link to the anti-denormalization technique that Rolf and Alex implemented at the sites,
that was pointed out by Chris Wipf from MIT:

http://www.musicdsp.org/files/denormal.pdf
  1459   Wed Apr 8 09:36:20 2009 steveConfigurationVAC valve condition changed to BG to calibrate the RGA

Vacuum normal valve condition was changed to accommodate SRS-RGA calibration.

 

The annulus valves were closed to free TP3 to pump on the RGA
VM1 was closed to isolate the RGA from the IFO.
 
 
VM3 opened to TP3.
 
This condition is called back ground (BG) mode. It is where we can calibrate and see the RGA background without the IFO.
  1458   Wed Apr 8 02:47:42 2009 YoichiUpdateLockingLocking status
This is a summary of activities in the last few nights, although there is not much progress.

The attachment 1 and 2 show the CARM and DARM responses around 3.8kHz at different arm power levels.
The CARM error signal was PO_DC and the DARM error signal was AS2Q.
The excitations were both applied to the ETMs (I temporarily modified the output matrix so that the unsed XARM filter bank can be used to excite CARM and DARM).
DARM and CARM show very similar behavior as the power goes up.

The third attachment shows transfer functions to various signals from CARM and DARM excitations (ETMs).
Though the plot contains many curves, look at PO_DC curves (green and black).
PO_DC is used as CARM error signal but it has a larger response to DARM than CARM (by 10dB or so).
This is not good.

Although the 3.8kHz problem still exists, tonight I was able to go up to arm power = 80 a couple of times, where we are ready to hand off from PO_DC to the RF CARM signal. The hand off failed. I'm now optimizing the hand off gain, but it is difficult because the interferometer is unstable at this power level.
Attachment 1: CARM_TFs.pdf
CARM_TFs.pdf
Attachment 2: DARM_TFs.pdf
DARM_TFs.pdf
Attachment 3: DARM-CARM-Coupling.pdf
DARM-CARM-Coupling.pdf
  1457   Tue Apr 7 21:39:57 2009 YoichiConfigurationComputersLSC code recompiled with a fix for denormalization problem
This is not my work but I will put it for the record.

A few days ago, Rob recompiled the LSC code with the fix of the denormalization problem provided by Alex.
Since then, the LSC code has been working fine. I recognize that c1lsc is now less loaded.

I believe Rob only recompiled the LSC code, so there could still be the problem in the suspension controllers.
  1456   Mon Apr 6 21:50:43 2009 ranaUpdateLSCArm Locking via pushing MC2
Inspired by our 'No Refcav' scheme here, I was inspired to re-explore the idea of locking the
CARM DOF using only feedback to the MC/laser. Last week I got this to work on the single arm and
full IFO at Livingston.
I also estimate the MC noise there.

Today I found the settings to allow X-arm locking here without any feedback to the ETM or ITM:

- Set the LSC Output Matrix to feed the XARM signal to MC2.
- Turn OFF the input of the LSC-ETMX filter bank (this does not disable tickling).
- Turn OFF FM7 (0.1:10) in MC2-MCL.
- Turn ON MC2-LSC with a gain of 0.2 and FM3 FM4 FM5.

That's enough to lock the arm - its pretty stable. This also assumes that the LSC-MC2 bank has its nominal gain of -0.178.

To determine the gain of +0.2 in the MC2-LSC filter bank, I measured the TF from MC2->PD3_I and from ETMX->PD3_I. I adjusted
the gain to be equal at 150 Hz for acquisition and the sign to be opposite to account for the (-) in LSC-MC2. The TF is
attached.

After locking, I type a zero into the MC2-MCL filter bank and that shuts off the feedback from the MC servo to MC2. This is
now topologically similar to the standard CM servo configuration.

The second attachment has the trends of this locking. You can see that the MC_F goes off into the weeds, but the MCL signal
does not so much. I think maybe the MC length is drifting a lot - not the arm.

The third attachment shows the spectra.
Attachment 1: mc2-xarm.pdf
mc2-xarm.pdf
Attachment 2: Untitled.png
Untitled.png
Attachment 3: nohands.pdf
nohands.pdf
  1455   Mon Apr 6 19:09:15 2009 JenneUpdatePEMOld Guralp is hooked back up to the ADC

Old Guralp is hooked back up, the new one is sitting next to it, disconnected for now.

  1454   Fri Apr 3 17:20:05 2009 YoichiUpdateLockingThe 3.8kHz peak seems like the DARM RSE (not 100% sure though)
Yoichi, Kentaro,

Last night, we took several measurements of the AO path loop TFs with various offsets/demod. phases tweaked.
The first attachment shows the AO path loop TF as a function of the offset (in counts) added to the DARM error signal.
Though it is a bit crowded plot, you can see a general tendency that the peak becomes lower in height and higher in frequency as
the DARM offset goes from negative to positive. Since the peak height also depends on the arm power and it fluctuates during the measurements,
the change is not monotonic function of the offset though.

Being suspicious of the demodulation phase of the DARM error signal (AS166), we scanned it (see the second attachement).
But there is no significant change.
Note that the phase of the TF is 180 degrees different from the first attachment. This is because I changed the measurement point of the returning signal
on the CM board from TP2A to OUT2 to see POX_1I signal as well. These points should give the same signal for PO_DC except for the sign.

We also took the AO path TFs by changing the MICH offset (the third attachment). Again, there is no big change.

With the CARM locked with the PO_DC signal, we took the transfer function from the AO path actuation signal to the response of the POX_1I (4th attachment).
There is a huge 3.8kHz peak.

Finally, we measured the DARM response by exciting the ETMs differentially (the PDF attachment).
The shape of the 3.8kHz resonance looks like the DARM RSE peak.

It is speculated that somehow the DARM RSE resonance is coupled into the CARM loop. Don't know how though.
I'm now working on an Optickle simulation to get an insight into this issue.
Attachment 1: AO-TF-DARM-OFFSET.png
AO-TF-DARM-OFFSET.png
Attachment 2: AO-TF-DARM-DEMOD-PHASE.png
AO-TF-DARM-DEMOD-PHASE.png
Attachment 3: AO-TF-MICH-OFFSET.png
AO-TF-MICH-OFFSET.png
Attachment 4: POX_1I.png
POX_1I.png
Attachment 5: DARM-Loop.pdf
DARM-Loop.pdf
  1453   Fri Apr 3 14:52:38 2009 JenneOmnistructurePEMGuralp is finally back!

After many, many "it'll be there in 2 weeks" from the Guralp people, our seismometer is finally back!

I have it plugged into the Guralp breakout box's Channel 1xyz (so I have unplugged the other Guralp).  Both of the Guralp's are currently sitting under the MC1/MC3 chamber.

Before we can have both Guralps up and running, I need to stuff the next 3 channels of the breakout box (back in the fall, I only had Caryn do 1x, 1y, 1z, and now I need 2x, 2y and 2z done with the fancy low-noise resistors), so all the gains match between the 2 sets of channels.

I'm leaving the new Guralp plugged in so we can see how it behaves for the next couple days, until I take out the breakout box for stuffing.

  1452   Fri Apr 3 10:01:50 2009 steveUpdateVACrgascan with temp plot

Rga scan of day 231 since pumpdown pd66-m-d231

m stands for maglev pumping speed, vacuum normal condition of valves,

cc4 cold cathode gauge at the rga location,

cc1 is real ifo pressure from the 24" tube at the pumpspool,

PEM-count temp: vac envelope temp at the top of IOO chamber

 

 

Attachment 1: pd66tempow.jpg
pd66tempow.jpg
Attachment 2: rga-090403scan.png
rga-090403scan.png
  1451   Wed Apr 1 23:18:07 2009 rana, kojiSummaryIOONo Reference Cavity Required
Koji sent us a note about our "No Reference Cavity Required" entry. I thought that it nicely summarizes the
whole shebang and so I post it here for its pedagogical value.

Generally, frequency stabilization is a comparison of the two
frequency references.

1. In the conventional case you are comparing the NPRO stability with
the RC stability. The NPRO cavity is short and probably placed in a
less stable environment than that of the RC. Therefore, the PDH
signal only feels the frequency fluctuation of the NPRO, resulting
in the laser PZT fast feedback dominated by the NPRO stability. As
the MC length at low frequency is controlled by the mass feedback,
the resulting laser stability through the MC is virtually limited
by the RC stability.

2. On the other hand, you are comparing the stabilities of the NPRO
crystal and the MC cavity in the direct control configuration. The
stability of the MC at high frequency is better than that of the
NPRO. It is opposite at low frequency, of course, because of the
pendulum motion. The resulting laser stability through the MC is
limited by the MC stability.

3. In the CM servo, the length of the MC is stabilized such that the
arm stability is duplicated to the MC. As a result, your MC servo
compares the stability between the NPRO and the arm cavity. Again
at around 1Hz, the arm cavity is noisier than the NPRO. (This is
true at least TAMA case. I am quite unsure about it in the LIGO
long arm cases.)

One useful consequence is that in those configurations, the laser PZT
feedback at around 1Hz represents the stability of the NPRO, the MC,
and (possibly) the arm cavity, respectively. It was clearly seen
Yoichi's e-log entry 1432. At TAMA we call this signal as "MCPZTfb"
and use this for the diagnostic purposes of the suspended cavities. As
the laser fast PZT is rarely replaced and considered as a stable
actuator, this signal is considered as a good reference at low
frequency which is consistent across various configurations
(e.g. before/after replacement of the suspensions etc). Once the
response and the coefficient are calibrated you can easily convert
this signal to the length displacement.

Another remark: In the direct configuration, the frequency stability
of the beam goes through the MC is determined by the MC stablity. It
means that the beam to the arm has essentially worse stability than
the arm stability by factor of L_arm/L_MC. In the 40m case this factor
is just 3 or so. This is ok. However, for the LIGO 4km arm, the factor
becomes something like 300. This means that if you have 1um_rms of the
MC length fluctuation, the arm PDH feels 300um_rms. (Maybe some extent
less because of the common mode rejection of the MC suspensions.)

Yes, the actuator to the MC length is very strong this time, and
should be able to stop this amount of fluctuation easily... if the
things are all linear. I am not certain whether you can acquire the
lock even by this strong actuator when the arm is crazily swinging,
the PDH signals are ringing all the way, etc, etc...Particularly in
the recycling case!

One possible remedy is a technique developed by the German
necromancers, as always. They used the NPRO cavity as a reference
cavity. They actuate the MC length at low frequency. But I don't know
the exact configuration and how they accomplished the CM hand-off. We
have to ask Hartmut.

The other possibility is your adaptive stabilization of the MC by the
FIR technique. So far I don't know how much stability you can improve
in the LIGO 4km case.

There would be many possibilities like feedforward injection from the
green arm locking signal to the MC length, etc, etc.
  1450   Wed Apr 1 16:14:36 2009 YoichiUpdateLocking3.8kHz peak does not change with SRC offset
Yoichi, Peter

We suspected that maybe the 3.8kHz peak is the DARM RSE somehow coupled to the CARM.
So we added an offset to the SRC error signal to see if the peak moves by changing the offset.
It didn't (at least by changing the SRC offset by +/-1000).
(I had a nice plot showing this, but dtt corrupted the data when I saved it. So no plot attached.)

I also played with the PRC, DARM offsets which did not have any effect on the peak.
The only thing, I could find so far, having some effect on the peak is the arm power. As the arm power is increased, the peak height goes up and the frequency shifts slightly towards lower frequencies.
  1449   Wed Apr 1 15:47:48 2009 YoichiUpdateLocking3.8kHz peak looks like a real optical response of the interferometer
Yoichi, Peter

To see where the 3.8kHz peak comes from, we locked the interferometer with the CARM fed back only to ETM and increased the arm power to 4.
The CARM error signal was taken from the transmission DC (not PO_DC).
The attached plots show the CARM transfer functions taken in this state (called ETM lock in the legends) compared with the ones taken when the CARM is locked by the feedback to the laser frequency (called "Frequency lock").
The first attachment is the TFs from the CARM excitation (i.e. the ETMs were actuated) to the TR_DC and PO_DC signals.

The second attachment is the AO path loop TFs. This is basically the TF from the frequency actuator to the PO_DC error signal.
I injected a signal into the B-excitation channel of the common mode board (with SR785) and measured the TF from TP2B to TP2A of the board.
For the ETM lock case, the AO loop was not closed because I disabled the switch between TP2A and TP1B.

The observation here is that even with no feedback to the laser frequency, the 3.8kHz peak is still present.
This strongly suggests that the peak is a real optical response of the interferometer.

To realize the ETM lock with arm_power=4, I had to tweak the CM loop shape.
I wrote a script to do this (/cvs/cds/caltech/scripts/CM/ETM_CARM_PowerUp).
You can run this script after drstep_bang has finished.
Attachment 1: CARM-ETM-EXC.png
CARM-ETM-EXC.png
Attachment 2: AOpath-TFs.png
AOpath-TFs.png
  1448   Wed Apr 1 10:22:13 2009 steveUpdateVACRGA logging is working

Thanks to Joe B who made the SRS RGA working with linux

Last data file logged at 2008 Oct 24 with old Dycor unit

First data file logged at  2009 Feb 10 with SRS

 

Attachment 1: rga-090401.png
rga-090401.png
  1447   Tue Mar 31 09:42:32 2009 steveUpdatePEMETMY sus damping restored again

The Caltech gasoline storage tank is being upgraded.

They are jack hammering and digging with bulldozer 50 yards south of  ETMY

  1446   Mon Mar 30 17:02:46 2009 YoichiConfigurationGeneralAP OSA aligned
I aligned the AP OSA, which had been mis-aligned for a while.
  1445   Mon Mar 30 15:51:27 2009 steveUpdateElectronicsHP4291A left the lab to be repaired

Eric Gustafson is handling the old HP4291A rehabilitation. Tarac picked both units up today.

March of 2008 Tucker Electronics failed to fix it's intermittent ~25MHz 0.5V oscillation at the swept sine output

See 40m-elog id:398 on 3-24-2008 by Rob Ward

 

  1444   Mon Mar 30 13:29:40 2009 YoichiUpdateSUSMC1 drift investigation continued

Quote:
Maybe we can temporarily just disconnect the bias and just use the SUS sliders for bias if there's enough range?


We could do this, but I'm suspicious of the cables between the coil driver and the coils (including the satellite box). In this case, disabling the bias won't help.
Since the MC1 has been quiet recently, I will just lock the MC and resume the locking.
  1443   Mon Mar 30 12:46:36 2009 YoichiConfigurationIOOIOO QPDs were missing the beam
When I re-locked the MC, I wanted to check the trend of the IOO QPDs to see if the input beam pointing has changed.
Then I found that the QPDs were not receiving light.
The attached trend plots show that the QPDs missed the beam on March 23rd.
The IOO-QPD_ANG was installed on Mar 11th by Kiwamu and Kakeru. Since then, they were serving as a reference of the PSL beam pointing.
But there is no record of the past week. This is very bad because then I cannot tell if I should relieve the MC WFS to make the mirrors follow the input beam or not.
I found that someone has moved the beam splitter which picks up the beam going to those QPDs. But there is no elog entry on this around March 23rd.
I re-centered the beam on the QPDs.

Since the X-arm locked to TEM00 with the MC WFS on (i.e. the MC beam axis is following the input beam axis), I guessed that the input beam has not drifted that much. So I relieved the WFS and centered the WFS QPDs.
Attachment 1: IOO-QPDs.pdf
IOO-QPDs.pdf
  1442   Mon Mar 30 12:29:17 2009 YoichiConfiguration MC1 glitches not seen during the weekend
The attached is the MC trend for the past 12 hours.
There is no MC1 glitches in the OSEM signals. Moreover, the total amplitude of the drift is smaller than it used to be (now the amplitude is less than 100 but it used to be a few hundreds).
There still is a small step in the OSEM signals at around 6AM this morning, but the amount of the jump is very insignificant.
The cause of the glitch in the TMP1, DRUM1 and APTEMP (LL, UL and UR coils respectively) at 7AM is not known.
Since the MC1 has been behaving OK during the weekend, I removed the probes from the MC1 coil driver board and locked the MC.
Hopefully the replacement of the broken connector fixed the problem, but I'm not sure.
Attachment 1: MC_drift.pdf
MC_drift.pdf
  1441   Mon Mar 30 09:07:22 2009 ranaUpdateSUSMC1 drift investigation continued
Maybe we can temporarily just disconnect the bias and just use the SUS sliders for bias if there's enough range?
  1440   Sun Mar 29 17:54:41 2009 YoichiUpdateSUSMC1 drift investigation continued
The attached plots show the trend of the MC OSEM signals along with the voltages across the output resistors of the bias current buffers.
The channel assignments are:
MC_TMP1 = LL coil
MC_DRUM1 = UL coil
OSA_APTEMP = UR coil
OSA_SPTEMP = LR coil

Although the amplitude of the drift of MC1 is much larger than that of MC2 and MC3, the shape of the drift looks like a daily cycle (temperature ?).
This time, I reduced the MC1 bias currents to avoid saturation of the ADCs for the channels measuring the voltages across the output resistors.
This may be the reason the MC1 has been non-glitchy for the last day.

OSA_APTEMP (UR Coil) shows a step function like behavior, although it did not show up in the OSEM signals.
This, of course, should not happen.

Today, I went to the MC1 satellite box and found that the 64-pin IDE like connector was broken.
The connector is supposed to sandwich the ribbon cable, but the top piece was loose.
The connector is on the cable connecting the satellite box and the SUS rack.
I replaced the broken connector with a new one. I also swapped the MC1 and MC3 satellite boxes to see if the glitches show up in the MC3.

I restored the bias currents of the MC1 to the original values.

The probes to monitor the voltages across the output resistors are still there. For OSA_SPTEMP, which was saturating the ADC, I put a voltage divider before the ADC. Other channels were very close to saturation but still within the ADC range.

Please leave the MC unlocked at least until the Monday morning.
Also please do not touch the Pomona box hanging in front of the IOO rack. It is the voltage divider. The case is connected to the coil side of the output resistor. If you touch it, the MC1 bias current will change.

Attachment 1: Drift1.pdf
Drift1.pdf
  1439   Sun Mar 29 13:44:27 2009 steveUpdateSUSETMY sus damping restored

ETMY sus damping was found to be tripped.

It was retored.

All fluorecent light were turned off. Please try to conserve some energy.

  1438   Fri Mar 27 17:52:16 2009 YoichiUpdateIOOMC glitch investigation
Per Rob's suggestion, I put the probes across the output resistors of the bias current buffers instead of measuring the output voltage with respect to the ground.
This way, we can measure the current flowing the resistor. The change was made around 17:30.

Quote:
Attached plots are the result of the MC1 trend measurement.
See the attachment #1. The first two plots show the drift of the MC1 alignment as seen by the OSEMs. It is terrible. Other MC mirrors also drifted but the scale is smaller than the MC1.
From the VMon channels, you can see that the control voltages were quiet.
 
The monitor channels we added were:
 
MC_TMP1 = UL coil bias. Input to the coil driver board.
MC_DRUM1 = UL coil bias. Output of the current buffer.
OSA_APTEMP = LR coil bias. Input to the coil driver board.
OSA_SPTEMP = LR coil bias. Output of the current buffer.
 
The bias voltages show no drift except for a glitch around 7AM. This glitch did not show up in the SPTEMP channel (LR coil bias output). This was because the probe was connected to the coil side of the output resistor by mistake.
 
The second attachment shows a zoomed plot of MC1 OSEM signals along with the bias monitor channels (signals were appropriately scaled so that they all fit in +/-1).
There is no correlation between the OSEM signals and the bias voltages.
 
Since we were only monitoring UL and LR coils, I changed the monitor points as follows.
 
MC_TMP1 = LL coil bias. Output of the current buffer.
MC_DRUM1 = UL coil bias. Output of the current buffer.
OSA_APTEMP = UR coil bias. Output of the current buffer.
OSA_SPTEMP = LR coil bias. Output of the current buffer.
 
I will leave the MC unlocked for a while.

 

 

 

  1437   Fri Mar 27 15:05:42 2009 YoichiUpdateIOOMC glitch investigation
Attached plots are the result of the MC1 trend measurement.
See the attachment #1. The first two plots show the drift of the MC1 alignment as seen by the OSEMs. It is terrible. Other MC mirrors also drifted but the scale is smaller than the MC1.
From the VMon channels, you can see that the control voltages were quiet.
 
The monitor channels we added were:
 
MC_TMP1 = UL coil bias. Input to the coil driver board.
MC_DRUM1 = UL coil bias. Output of the current buffer.
OSA_APTEMP = LR coil bias. Input to the coil driver board.
OSA_SPTEMP = LR coil bias. Output of the current buffer.
 
The bias voltages show no drift except for a glitch around 7AM. This glitch did not show up in the SPTEMP channel (LR coil bias output). This was because the probe was connected to the coil side of the output resistor by mistake.
 
The second attachment shows a zoomed plot of MC1 OSEM signals along with the bias monitor channels (signals were appropriately scaled so that they all fit in +/-1).
There is no correlation between the OSEM signals and the bias voltages.
 
Since we were only monitoring UL and LR coils, I changed the monitor points as follows.
 
MC_TMP1 = LL coil bias. Output of the current buffer.
MC_DRUM1 = UL coil bias. Output of the current buffer.
OSA_APTEMP = UR coil bias. Output of the current buffer.
OSA_SPTEMP = LR coil bias. Output of the current buffer.
 
I will leave the MC unlocked for a while.

Quote:

Yoichi, Pete

The MC loses lock due to glitches in the MC1 coils. 
We do not know which coil for sure, and we do not know if it is a problem going into the board, or a problem on the board. 
We suspect either the UL or LR coil bias circuits (Pete would bet on UL).  If you look at the bottom 4 plots in the attached file, you can see a relatively large 3 minute dip in the UL OSEM output, with a corresponding bump in the LR (and smaller dips in the other diagonal).  
These bumps do not show up in the VMONS which is why we are suspicious of the bias.
To test we are monitoring 4 points in test channels, for UL and UR, both going into the bias driver circuit, and coming out of the current buffer before going into the coils. 
 

We ran cable from the suspension rack to the IOO rack to record the signals with DAQ channels.

The test channels:

UL coil      C1:IOO-MC_DRUM1  (Caryn was using, we will replace when we are done)

UL input   C1:IOO-MC_TMP1 (Caryn was using, we will replace when we are done)

LR coil      C1:PEM-OSA_SPTEMP

LR input   C1:PEM-OSA_APTEMP

We will leave these overnight; we intend to remove them tomorrow or Monday.

We closed the PSL shutter and killed the MC autolocker.

 

Attachment 1: MC1_Drift.pdf
MC1_Drift.pdf
Attachment 2: MC2_Drift.pdf
MC2_Drift.pdf
  1436   Fri Mar 27 02:50:54 2009 YoichiUpdateLockingDD demodulation phase suspicious
I noticed that the gain of PD6_Q (before the phase rotation) was 0 whereas PD6_I gain was 15.
This means the demodulation phase of the PD6 had no meaning other than changing the gain.
According to the conlog, it has been zero since March 2nd. I don't know how it happened.

While I was re-adjusting the DD phase, the MC started to unlock frequently (every 10 minutes or so).
MC1 is again drifting a lot (it is getting step-function like alignment changes intermittently).
This practically made it impossible to work on locking. So I decided to fix the MC first.
See Peter's elog entry for the MC work.
  1435   Fri Mar 27 02:40:06 2009 peteSummaryIOOMC glitch investigation

Yoichi, Pete

The MC loses lock due to glitches in the MC1 coils. 
We do not know which coil for sure, and we do not know if it is a problem going into the board, or a problem on the board. 
We suspect either the UL or LR coil bias circuits (Pete would bet on UL).  If you look at the bottom 4 plots in the attached file, you can see a relatively large 3 minute dip in the UL OSEM output, with a corresponding bump in the LR (and smaller dips in the other diagonal).  
These bumps do not show up in the VMONS which is why we are suspicious of the bias.
To test we are monitoring 4 points in test channels, for UL and UR, both going into the bias driver circuit, and coming out of the current buffer before going into the coils. 
 

We ran cable from the suspension rack to the IOO rack to record the signals with DAQ channels.

The test channels:

UL coil      C1:IOO-MC_DRUM1  (Caryn was using, we will replace when we are done)

UL input   C1:IOO-MC_TMP1 (Caryn was using, we will replace when we are done)

LR coil      C1:PEM-OSA_SPTEMP

LR input   C1:PEM-OSA_APTEMP

We will leave these overnight; we intend to remove them tomorrow or Monday.

We closed the PSL shutter and killed the MC autolocker.

Attachment 1: MC1_Drift.png
MC1_Drift.png
  1434   Thu Mar 26 09:08:18 2009 KakeruUpdateoplevsarm cavity oplev calibration
I uploaded a document about my oplev calibration.
/cvs/cds/caltech/users/kakeru/oplev_calibration/oplev.pdf

At same place I put my matlab codes for calibration.
/cvs/cds/caltech/users/kakeru/oplev_calibration/oplev_calibration.m
  1433   Thu Mar 26 04:27:26 2009 YoichiUpdateLocking3.8kHz peak as a function of the arm power
During the power ramp-up, I actuated CARM using ETMs and measured the transfer functions to the PO_DC at several arm powers.
The peak grows rapidly with the power. It also seems like the frequency shifts slightly as the power goes up, but not much.

Some sort of an RSE peak ? An offset in the PRC lock point ?
Attachment 1: CARM-PODC.pdf
CARM-PODC.pdf
  1432   Thu Mar 26 04:09:38 2009 YoichiUpdateIOOSingle X arm lock spectra with different MC lock schemes
The attached plots show MC_F, FSS_FAST_F and XARM IN/OUT spectra with different MC locking modes.
The conventional locking means the FSS is used. The direct frequency lock is the new way.
You can see that at low frequencies, the frequency actuator is working hard to suppress the MC pendulum motions.
The X-arm also sees a lot of frequency noise at low frequencies because of this.
The transmitted power of the X-arm fluctuates a lot making it difficult to align the mirrors.

The zoomed plots show that the structures in the kHz band are also present in the case of the direct frequency lock, although the frequencies are somewhat different.
Attachment 1: XarmSpectra.pdf
XarmSpectra.pdf
Attachment 2: XarmSpectraZoom.pdf
XarmSpectraZoom.pdf
  1431   Thu Mar 26 04:01:24 2009 YoichiUpdatePSLFSS Open Loop Gain
Yoichi, Peter, Jenne

Attached is the open loop transfer function of the FSS as of today with the common gain = 12dB and the fast gain = 16dB.
The UGF is only 250kHz. If we increase the common gain, the PC goes crazy. Exactly the same symptom as before I fixed the oscillating op-amp.

I wanted to check the cross over frequency but there is no excitation point in the fast path nor PC path. Therefore, it is not easy.
Attachment 1: OpenLoopTF.png
OpenLoopTF.png
ELOG V3.1.3-