40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 159 of 344  Not logged in ELOG logo
ID Date Author Type Category Subject
  9323   Thu Oct 31 20:05:48 2013 RANAUpdateIOOMode Cleaner Tune-UP

Quote:

Steve, can you please put 2 mounted  razor dumps near the WFS for this purpose??    

            Tuesday: Razor dumps are waiting for you.

 I couldn't find any dumps near the WFS. Koji looked. I looked twice. Maybe they are spooky and absorbing all of the light?

The MC alignment was bad and the WFS were making it drift. Koji aligned the beam into the PMC. I then restored the MC suspensions to where they were 8 days ago (back when the transmission and reflection were good). With the WFS OFF, this gave us a MC trans ~ 16000. With WFS ON it goes to 17500 which is about as good as its been over the last 80 days.

I centered the beam on the WFS with the MC unlocked and also centered the beam on the whole WFS path (it was near clipping between WFS 1 & 2). Also for some reason that beamsplitter which steers the beam onto WFS1 is a R=33% (!? why is this not a R=50% ??).

Steve, please swap this out to a BS1-1064-50-1025-45S if we have one sitting around. If not, we want to add this to the CVI purchase list, but not buy until we get a bigger list together.

I also centered this newly aligned beam into the IMC onto the PSL QPDs. We should now use these as a pointing reference for the beam into the IMC.

While doing this I noticed that the beam was almost clipping on the Uniblitz shutter used to block the PSL beam. That shutter is mounted too short and was also not centered horizontally. I removed it for now so that Steve can find a more adjustable mount for it and put it back into play. The beam going into the IMC is BIG, so you have to very careful when centering the shutter. Might be that we cannot leave it at 45 deg and still get a big enough aperture.

Note #3 for Steve: please also replace the mount for last steering mirror into the IMC with a Polanski or a Superman, that black Ultima is no good. Also the dogs must be steel - no aluminum dogs for our sensitive places.

Attachment 1: drifty.png
drifty.png
  9322   Thu Oct 31 15:34:28 2013 manasaUpdateIOOMC not happy since yesterday

Quote:

 

8 day minute trend of some of the IMC alignment signals.

That step ~2 days ago in the WFS2 yaw control signal shows that I didn't do such a good job on yaw.

Nic is going to come over some time and give us a new Gouy telescope that let's us have bigger beams on the WFS. At LLO, Hartmut demonstrated recently how bigger beams can reduce offsets somehow...mechanism TBD.

Also, we must angle the WFS and figure out how to dump the reflections at the same time that we rework the table for the telescope.

Steve, can you please put 2 mounted  razor dumps near the WFS for this purpose??    

            Tuesday: Razor dumps are waiting for you.

 

The MC has not been able to hold lock for over a couple of hours since yesterday. I aligned the MC yesterday (elog 9320) and it lost lock in a couple of hours. I realigned the MC again around noon today only to see it drifting and lose lock again.

I have attached the MC trend for the 2 hours when the MC drifted slowly from its happy to sad state.

 

 

Attachment 1: MC_drift.png
MC_drift.png
  9321   Thu Oct 31 00:06:45 2013 masayukiUpdateComputer Scripts / Programscds fft,tf,offsets

I wrote the scripts for cdsutils.

1. fft

usage: fft.py [-h] [-c N_CYCL] [-a N_AVG] freq channel [channel ...]

Measures the frequency content of one or more NDS channels
at the specified frequecy.
    The measurement results are  magnitude, phase, real part imaginary part, and the standard deviation of the real and imaginary parts.

positional arguments:
  freq        measurement frequency
  channel     list of measurement channel

optional arguments:
  -h, --help  show this help message and exit
  -c N_CYCL   define number of cycles. Default is 10
  -a N_AVG    define number of average. Default is 100

2. tf

usage: tf.py [-h] [-c N_CYCL] [-a N_AVG] [--dB] freq input output

Measures the transfer funtion of one NDS channels pair  at the specified frequecy.
    The measurement results are the coherence, magnitude, phase, real part, imaginary part, and the standard deviation of the real and imaginary parts.

positional arguments:
  freq        measurement frequency
  input       list of measurement input channel
  output      list of measurement output channel

optional arguments:
  -h, --help  show this help message and exit
  -c N_CYCL   define number of cycles. Default is 10
  -a N_AVG    define number of average. Default is 100
  --dB        print the amplitude in dB

 

3.offsets

usage: offset.py [-h] [-t SECONDS] filterbank [filterbank ...]

Zero the offset of one or more filterbank. Take average of OUT16 channel, and put (-1 * average / gain) into offset.  After change offsets, it will turn on the offset.
    example usage) offset -d 25 C1:LSC-AS55_Q C1:LSC-AS55_I

positional arguments:
  filterbank  list of filterbank to zero offset

optional arguments:
  -h, --help  show this help message and exit
  -t SECONDS  define the averaging time. default value is 10

I put these scripts in /opt/rtcds/cdsutils/trunk/lib/cdsutils.
I couldn't put them into cds library, but I will left tomorrow to Japan...

So please help me Jamie or Joe !!

 

 

By the way,

I modified the LSCoffset script  (script)/LSC/LSCoffsets.py.

usage: LSCoffsets.py [-h] [-d SECONDS] [--PDlist]

 Zero the offsets of LSC PDs. During taking average, we will close the PSL and green shutter. After zeroing, it will turn on the offsets switch.
    example usgae) LSCoffset2.py -d 20    

optional arguments:
  -h, --help  show this help message and exit
  -d SECONDS  define the averaging time. default value is 10
  --PDlist    print PD list for LSC and exit

i made new directory 'offset_backup' for old offset script. I move all old offset script into there.

But unfortunately that cannot use right now, because cds offsets script is not available yet...

  9320   Wed Oct 30 16:46:17 2013 manasaUpdateIOOMC aligned

MC has not been very happy since last night. 

What I did to fix this:

1. Disabled autolocker and WFS and aligned the MC to bring MC REFL down to <0.50

2. When I re-enabled autolocker, MC was losing lock everytime WFS turned ON.

3. I relocked MC, measured the spot positions and moved MC spot positions by running /opt/rtcds/caltech/c1/scripts/ASS/MC/mcassMCdecenter 
and 
/opt/rtcds/caltech/c1/scripts/MC/moveMC2/

4. I reset the WFS offsets by running /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets

5. MC is locked and looks happy right now with REFL DCMON at ~0.5

 

  9319   Wed Oct 30 14:58:44 2013 SteveHowToGeneralshutting down a computer

 

 We have tried to ssh into c1iscey yesterday morning. It just did not work. We have just tried it again (now) and it did work.

Lesson learned: always shut down the computer from a TERMINAL Do not turn it off by the manual power switch.

  9318   Wed Oct 30 08:32:55 2013 EvanHowToComputer Scripts / Programsmatplotlibrc

FYI, you can trick out matplotlib by creating a matplotlibrc config file. This allows you to set defaults for plot size, trace color, fonts, grids, etc., analogous to what is achieved in ATF:1840 for Matlab.

Note also that matplotlib supports LaTeX by default (if you have LaTeX installed), which means, for example, that you can include true square roots on your spectral densities:

plt.ylabel('Voltage spectral density (V/$\\sqrt{\\mathrm{Hz}}$)')

Since the backslash is used for escape characters in python, you must escape LaTeX backslashes.

For maximum effect, you can set the following lines in your matplotlibrc file:

text.usetex = True

text.latex.preamble = \usepackage{txfonts}

Then all text and mathematics in your plot will be sent through LaTeX for processing and will appear in Times.

Also, why is the conversion from watts to volts V = 50 * sqrt(W) and not V = sqrt(50 * W)?

  9317   Wed Oct 30 03:36:51 2013 JenneUpdateLSCMICH and PRCL UGFs change with ALS enabled

Masayuki was able to hold both arms off-resonance with ALS long enough for me to lock the PRMI (arms still held off resonance), and take a set of transfer functions.

MICH gain is still -2.0, PRCL gain is still 0.070, which, with the ETMs misaligned, gave me UGFs of 70 for MICH and 180 for PRCL.

Now, however, with the ETMs aligned, but arms held off resonance with ALS, the UGFs have been lowered by a factor of 2 in frequency!  What is doing this??  MICH is now 40 Hz, and PRCL is now 80 Hz.

We measured the MICH and PRCL loops for several arm powers, and there was no change, at least until the arms were both resonating with powers of ~4 . 

After misaligning the ETMs, I remeasured the loops, and the UGFs went back up to where they started.

  9316   Wed Oct 30 03:33:17 2013 RanaUpdateLSCLSC demod boards need some thought

 

 0309.png

I worked on the script SPAG4395A.py tonight with Masayuki's help. This sets up the parameters on the Agilent 4395A and then acquires the spectrum data. It had a couple of bugs before: no matter what channel you requested, you always got channel R. It also would disobey any requests to reduce the attenuation and left the Auto Atten ON. The version now in the SVN allows you to choose the channel and the attenuation.

It then makes this plot using matplotlib. The attached image is from the REFL165 pickoff at a time tonight when the arm powers were ~5-10. I have converted the spectrum from RF electrical Watts into Volts (V = 50*sqrt(W)). To go from the analyzer input to the demod board input we should scale this spectrum by a factor of ~15 (to account for the 20 dB from the coupler and the 3 dB of the splitter and a little more for losses). On the oscilloscope we see Vpp ~5 mV, so that's ~75 mVpp at the output of the BBPD which we're using for REFL165. Perhaps we can handle another factor of ~2-3 ? I'm not sure what we have in terms of linearity measurements on this thing.

EDIT: Evan is right, its V = sqrt(50*W), not V = 50*sqrt(W). ignore y-axis above

  9315   Wed Oct 30 01:53:52 2013 JenneUpdateIOOMode Cleaner relocked

The MC (mostly MC2) decided a few minutes ago to move, so I put the SUSPIT and SUSYAW numbers back where they were, and the tweaked up the alignment from there to get a low MC REFL DC number.  Now the MC is staying locked again, after 20 minutes of not.

  9314   Wed Oct 30 01:44:13 2013 JenneUpdateLSCMICH and PRCL gains adjusted (Config file saved)

Quote:

I am now taking transfer functions of the MICH and PRCL loops to make sure that we have the gains about right.

 I have set the PRCL UGF to be about 180Hz, and the MICH UGF to be about 70 Hz. 

This is with locking on REFL165 I&Q, with MICH gain of -2.0 and PRCL gain of 0.70 . 

The PRCL loop only has about 30 degrees of phase margin, and is not near the top of its phase bubble.  During the day, I need to look at why we don't have more phase near 200 Hz.

  9313   Wed Oct 30 01:22:56 2013 JenneUpdateLSCREFL 165 demod phase adjusted

Quote:

For tonight, Rana has put a coax 100 MHz highpass filter on the input to the REFL165 demod board.

 This of course changes our demod phase.  Rana plotted a 4th order elliptic filter in Matlab, and from the plot determined that we should expect around 60 degrees of difference in our phase. 

To actually set the phase, I locked PRMI on AS55Q and REFL33I (MICH gain = -8.0, PRCL gain = +0.05, with 1's in the matrix elements).  I then turned on the PRCL oscillation notch (564 Hz), and turned on the sensing matrix's drive at that frequency, and looked at the spectrum of REFL165. 

The previous REFL165 demod phase was 96 degrees, so I was looking around either 36 degrees or 156 degrees.  The phase that minimized the peak in the Q signal while driving PRCL was 37.5 degrees.  Good work Matlab/Rana.

I then looked at the transfer functions between REFL33 and AS55 and REFL165, to see if there were any sign flips that happened.  There were not.  As expected, it was just a little extra phase delay.

I was able to lock PRMI with REFL 165 again after this phasing, and I am now taking transfer functions of the MICH and PRCL loops to make sure that we have the gains about right.

  9312   Wed Oct 30 00:02:25 2013 JenneUpdateLSCLSC demod boards need some thought

As we are meditating on things to look at for PRMI + 2 arms, Rana brought up the question of the demod board situation. 

We then found this table on the wiki (LSC demod boards) that indicates that all of the demod boards were originally given lowpass filters, no matter the demodulation frequency.  Back in September, I switched out the low pass filter for a bandpass filter in POP110, and put in the same bandpass when putting together AS110 (elog 9100).  So, the 11MHz diodes are probably okay with lowpasses, and the 110 diodes are okay, but we need to think about all the other ones. 

We should probably do a first guess by putting in a bandpass filter, but then simulate and measure to figure out what our requirements are for attenuation at the non-demodulation frequencies for each board.

The SXBPs from Minicircuits look pretty good, but there are lots of options on their website.

 

For tonight, Rana has put a coax 100 MHz highpass filter on the input to the REFL165 demod board.

  9311   Tue Oct 29 22:33:57 2013 ranaUpdateSUSETMY sensors compared to ETMX

Quote:

I've stopped the process of c1tst again to make it get better. At 9:20, I also went and opened the front rack door (the back one was already open). One reason its hot may be that the exhaust vents on the top of c1iscey are blocked by one of the custom multi-pin adaptor boxes. In the morning, we should drop the computer down by 1 or 2 notches in the rack so that it can air cool itself better. Make sure to poweroff the computer from the terminal before moving it though.

 After some torture Masayuki admitted that he and Steve ignored this elog and just turned off the power button. He blames Steve entirely.

to keep from damaging our computers and our data, NEVER DO THAT.

Scratch-n-SniffStinkyDooBabyShowerGame1.jpg

  9310   Tue Oct 29 18:54:36 2013 JamieConfigurationComputer Scripts / Programsfixing python-matplotlib from LSCSOFT

Quote:
controls@pianosa:~ 0$ cat /etc/apt/preferences.d/pin_python-matplotlib
Package: python-matplotlib
Pin: release a=lucid
Pin-Priority: 1000 

I forgot that there were a couple of different matplotlib packages that all needed to be pinned.  To be safe I decided to just pin all packages to the lucid versions.  This will still allow us to install lscsoft packages that are not ubuntu, but it will always prefer packages from lucid instead.  Here's the new pinning file:

controls@pianosa:~ 0$ cat /etc/apt/preferences.d/pinning 
Package: *
Pin: release a=lucid
Pin-Priority: 1000
controls@pianosa:~ 0$ 

  9309   Tue Oct 29 18:14:52 2013 JamieConfigurationComputer Scripts / Programsfixing python-matplotlib from LSCSOFT

Jenne just discovered an issue with the python-matplotlib package that I knew was coming but forgot about.

We pull packages from the LSCSOFT Debian "squeeze" archive, which is a convenient way for us to install LIGO data analysis software.  There are no LSCSOFT archives for Ubuntu, and Debian "squeeze" is the closest supported distribution to Ubuntu 10.04 "lucid", which is what we are using.

DASWG recently added python-matplotlib to the LSCSOFT squeeze archive.  The version they added (1.0.1-3) supersedes the version in lucid, so by default apt wants to install it.  However, the LSCSOFT version is compiled against a newer version of some standard libraries, so it won't function on our system and seg faults.

The solution (a solution) is to use apt "pinning" to pin the package to the lucid version that works.  I've added the following file on all the 10.04 workstations to prevent the package from upgrading to the LSCSOFT version:

controls@pianosa:~ 0$ cat /etc/apt/preferences.d/pin_python-matplotlib
Package: python-matplotlib
Pin: release a=lucid
Pin-Priority: 1000

 

  9308   Tue Oct 29 16:51:31 2013 JenneUpdateCDSLSC test points were used up

Masayuki was concerned that some LSC channels were giving him all zeros.  After seeing the error in the terminal window running dataviewer (it said something like 'daqd overloaded'), I checked the lsc model, and sure enough, all the test points were used.

So, I found an entry by Jamie (elog 8431) where he reminds us how to clear the test points.  I followed the instructions, and now we're seeing real data (not digital zeros) again.

  9307   Tue Oct 29 10:51:16 2013 MasayukiUpdateSUSETMY sensors compared to ETMX

[Steve, Masayuki]

We lowered the c1iscey machine to make space upside of the computer for heat flow. 

First we turned off the computer. And then we droped the computer down by 1  notches in the rack. Now the upside and downside spaces are almost same. We restarted the computer after that and we leave the door open.

 


  9306   Mon Oct 28 21:33:55 2013 RANAUpdateIOOMode Cleaner Tune-UP

 

8 day minute trend of some of the IMC alignment signals.

That step ~2 days ago in the WFS2 yaw control signal shows that I didn't do such a good job on yaw.

Nic is going to come over some time and give us a new Gouy telescope that let's us have bigger beams on the WFS. At LLO, Hartmut demonstrated recently how bigger beams can reduce offsets somehow...mechanism TBD.

Also, we must angle the WFS and figure out how to dump the reflections at the same time that we rework the table for the telescope.

Steve, can you please put 2 mounted  razor dumps near the WFS for this purpose??    

            Tuesday: Razor dumps are waiting for you.

 

Attachment 1: Untitled.png
Untitled.png
  9305   Mon Oct 28 18:57:27 2013 MasayukiHowToLSCread 'scope and spectrum analyser datas

 

The command to get the data from spectrum analyzer right now

From command line, put ./netgpibdata -i 192.168.113.108 -d AG4395A -a 17 -f meas01

(EDIT JCD:  You must first be in the correct folder:  /opt/rtcds/caltech/c1/scripts/general/netgpibdata/)

(EDIT JCD again: "meas01" in the command line instruction will be the name of the filename.  Also, the output file meas01.dat has a comment in the first line that must be deleted before you can plot the data.  This sucks, and we should write a script to strip that line, then make nice plots.)

Please take notice that although IP address of AG4395A is same as written in the help of netgpibdata, the GPIB address is not same. It's 17.

 

How to use  'scope from control room.

Open the browser. Put the IP adress of 'scope (192.168.113.25) into adrress bar of the browser. If it's on the network, below screen will open.

You can control 'scope, get the data, and so on from control room.

Please take notice that Google Chrome cannot connect the 'scope. So you have to use the Firefox or other browser.

  9304   Mon Oct 28 14:24:01 2013 MasayukiUpdateLSC'scope and spectrum analyser for REFL165

 

 I connected the 'scope between REFL165 output and demod board input. I split the signal from coupler using the splitter (Mini-Circuits ZFSC-2-5). One signal is going to 'scope CH1 and the other is going to spectrum analyzer. I connected the 'scope to 40MARS. The IP adress is 192.168.113.25. I connected that by cabling from 1X2.

 

  9303   Mon Oct 28 14:12:48 2013 manasaUpdateIOOMode Cleaner relocked

Quote:

 The MC had been unlocked for the last 4 hours and was crying out to me so I gave it some attention. Its happier now.

From the trend (AtM #1), I saw that the MC2 suspension has moved by ~10 microradians. Since the MC cavity divergence angle is lambda/(pi*w0) ~ 200 microradians, this isn't so much, but enough to cause it to lock on bad modes sometimes. Attackmint too shows that there's not much in monotonic drift over the last 40 nights.

I moved back MC2 to its old alignment with these commands:

ezcaservo -r C1:SUS-MC2_SUSPIT_INMON -s -1017 -g 0.0009 C1:SUS-MC2_PIT_COMM -t 300

ezcaservo -r C1:SUS-MC2_SUSYAW_INMON -s 490 -g 0.0009 C1:SUS-MC2_YAW_COMM -t 332

Then I went out to the table and aligned the beam into MC using the last two steering mirrors good enough so that the WFS coming on doesn't make the visibility any better. In this nominal state, I unlocked the MC and then aligned the reflected beam onto the center of the LSC PD as well as the WFS. The beam on the first WFS is a little small - next time someone wants to improve our Gouy phase telescope, we might try to make it bigger there. On the LSC PD, the beam was off-center by a few hundred microns.

Masayuki was running LAN cables near the MC2 chamber. This caused the MC2 suspension to move and unlocked the MC. I looked at the long term (2 days) and short term (2 hours) trend of the MC suspensions. I restored the old alignment as described above using ezcaservo.

C1:SUS-MC2_SUSPIT_INMON was restored to 1020 and C1:SUS-MC2_SUSYAW_INMON was restored to 490.

Attachment: Dataviewer trend (2 hours)

Attachment 1: Screenshot-Untitled_Window-3.png
Screenshot-Untitled_Window-3.png
  9302   Mon Oct 28 12:53:23 2013 JenneUpdateCDSFarfalla and Asia added to Host Table in Wiki

Quote:

I have updated the hostable on linux1 to give farfalla the 230 IP address and let 'asia' keep 225.

 Neither of these computers were listed in the Martian Host Table in the wiki, so I put them on there.  It's handy to keep this updated, so that we know what IP addresses are available.

  9301   Sun Oct 27 23:26:44 2013 ranaUpdatePEMSeismometer status

 It would be nice if we could use the existing seismometer cable and place a 2-terminal temperature sensor within the stainless-steel can. A device like the AD590/592 can drive current over a long cable run without pickup issues since its a current source. Inside of the seismometer breakout box we should make a circuit to scale the signal to be close to zero at 25 C and have a slope of 1 V/deg. There are example circuits in the application note - we can just make them on a piece of vector board and glue to the inside of the breakout box (where we connect to the regulated power).

  9300   Sun Oct 27 19:19:42 2013 DenUpdatePEMSeismometer status

Quote:

 

Is there anything else that I'm forgetting??  Please reply with thoughts.

 

 I attach the drawings for Guralp and T-240/STS-2 connector plates. Drawings contain all information about the screws, O-rings and connectors.

Basically, box mounting receptacle for seismometer cable is attached to the connector plate with 6-32 screws. Inside cable should be ~ 1m long and connect the plate with seismometer.

For T-240 realization we have an additional LEMO connector for temperature and pressure monitoring inside the station. We should buy sensors and plug them into some machine with slow controls.

LEMO connector has 9 pins. 4 will be used for temperature and pressure sensors and spare 5 can be used for future ideas.

Also I think it might be better to put two T-240 into isolation stations.

TrilliumPlate.PDF

GuralpPlate-1_final.pdf

 

  9299   Sun Oct 27 03:41:06 2013 ranaUpdateSUSETMX violin mode

  I thought it would be enough to notch the fundamental and the first harmonic, but sometime tonight the 2nd harmonic at 1892.88 Hz also got rung up.

I made a "Violin3" stopband filter for it and measured its Q using the ole DTT heterodyne secret handshake. Seems much too high to me - it would be nice if someone else would look at this plot and estimate the Q from it.

Turned the PSL HEPA switch back ON - I think its been off for at least a week. I turned the HEPA's variac to 20 after finishing the alignment on the table.

Attachment 1: ETMX-Vio3-Ring.png
ETMX-Vio3-Ring.png
  9298   Sun Oct 27 00:15:35 2013 RANAUpdateSUSc1auxex

 At some point tonight we lost our CA connection to c1auxex (which is actually the computer at the X End and controls the ETMX, but has a Y sticker). We could telnet to it, but its puny RAM must have been overloaded with too many EPICS connections that bypassed the CArepeater. I went around and booted some machines and it seems to be back and allowing damping now. Along the way I keyed off the crate to c1auxex a couple of times.

When trying to close the rack door I saw that Charlie/Steve had illegally connected the power cable for the illuminator through the door so that it couldn't close, so I disconnected it so that they can run it properly and feel better about themselves.

Disclaimer: Steve had nothing to do with this connection. I rerouted the cable the correct way. 10-28-2013

** what does this coherence tell us about the noise in the arms ?

Attachment 1: arms.pdf
arms.pdf
Attachment 2: arm-mc2-dewhite.pdf
arm-mc2-dewhite.pdf
  9297   Sat Oct 26 22:48:55 2013 ranaUpdateCDSNew/old CDS laptop for X-End

  I made the Yoichi laptop into a CDS laptop called 'asia' a few months ago. Somehow I mistakenly gave it the IP address of our little Acer laptop which is called 'farfalla'. This makes farfalla's network not work. I put the old Dell Aldabella by the PMC where farfalla was and am now upgrading farfalla from CentOS to Ubuntu 10.04 LTS 32-bit. I have updated the hostable on linux1 to give farfalla the 230 IP address and let 'asia' keep 225.

  9296   Sat Oct 26 21:46:33 2013 RANAUpdateIOOMode Cleaner Tune-UP

 The MC had been unlocked for the last 4 hours and was crying out to me so I gave it some attention. Its happier now.

From the trend (AtM #1), I saw that the MC2 suspension has moved by ~10 microradians. Since the MC cavity divergence angle is lambda/(pi*w0) ~ 200 microradians, this isn't so much, but enough to cause it to lock on bad modes sometimes. Attackmint too shows that there's not much in monotonic drift over the last 40 nights.

I moved back MC2 to its old alignment with these commands:

ezcaservo -r C1:SUS-MC2_SUSPIT_INMON -s -1017 -g 0.0009 C1:SUS-MC2_PIT_COMM -t 300

ezcaservo -r C1:SUS-MC2_SUSYAW_INMON -s 490 -g 0.0009 C1:SUS-MC2_YAW_COMM -t 332

Then I went out to the table and aligned the beam into MC using the last two steering mirrors good enough so that the WFS coming on doesn't make the visibility any better. In this nominal state, I unlocked the MC and then aligned the reflected beam onto the center of the LSC PD as well as the WFS. The beam on the first WFS is a little small - next time someone wants to improve our Gouy phase telescope, we might try to make it bigger there. On the LSC PD, the beam was off-center by a few hundred microns.

Attachment 1: MCtrend.pdf
MCtrend.pdf
Attachment 2: MC40days.png
MC40days.png
  9295   Fri Oct 25 21:36:51 2013 MasayukiUpdateLSC'scope and spectrum analyser for REFL165

Quote:

As Jenne's Elog we want to see Spectrum and time series of REFL 165 (our PRMI LSC locking PD) to see if the signal is saturated while bring the arms into resonance.
I started to connect the spectrum analyser and the 'scope to REFL165 output.

Directional coupler (Mini=-circuits ZMDC-10-2 ZMDC-20-3) was connected just before the dimod boad input. The main output of coupler is plugged into demod board's input.The other output of the coupler is connected to AG4395A using BNC cable.

The spectrum analyser output can be read using netgpibdata in control room. The IP address is 192.168.113.108 and the GPIB address is 17. For this I dissconected the network hub from another AG4395A, which is at the front of 1X2 lack.

I didn't connected the 300 MHz 'scope right now, but tomorrow it will be connected using power splitter and also be able to get data by internet. For connect 'scope to network, I disconected the network hub from SR785.

[Jenne, Masayuki]

We changed the Directional coupler from ZMDC-20-3 to ZMDC-20-5-S+ because that coupler seemed to introduce some high frequency noise.

  9294   Fri Oct 25 21:28:49 2013 MasayukiUpdateLSCREFL PDs spectrum

 I measured the spectrum of the REFL165 output using AG4395A. As this entry we put the directional coupler between REFL165 output and demod board input, so I measure the signal from the coupler during the PRMI was locked.

 After measure REFL165, I also measured REFL55 output in order to make sure that the signal is not smaller than noise because of coupler. I terminated the couple output of coupler on the REFL165, and take signal from REFL55 output port directly. Both plots seems same except for around the resonant frequency of each PDs. From this plot we cannot say that the coupler reduce signal to spectrum analyser too much.

 After this measurement I reconnected the REFL165 to analyser and reconnected the REFL55 output to demod board.

Attachment 1: REFL.png
REFL.png
Attachment 2: REFLspe.zip
  9293   Fri Oct 25 20:11:08 2013 JenneUpdateLSCMICH gain in PRMI lowered by factor of 2

We were locking the PRMI, but it is very rumbly today.  I reduced the MICH servo gain from -0.8 to -0.4 , and things seem to be better.  Now my MICH UGF is about 60Hz.

  9292   Fri Oct 25 19:56:58 2013 ranaUpdatePSLlaser drift monitor set up

 

 I went to re-align the beam into the PMC just now. I also tapped all the components between the laser and the PMC; nothing seems suspicious or loose.

The only problem was that someone (probably Steve or Valera) had closed down the iris just downstream of the AOM to ~1-2 mm diameter. This is much too tight! Don't leave irises closed down after aligning. An iris is not to b used as a beam dump. Getting it within a factor of 5-10 of the beam size will certainly make extra noise from clipping/scattering. After opening the iris, the reflected beam onto the PMC REFL camera is notably changed.

Not sure if this will have any effect on our worsening transmission drift, but let's see over the weekend.

I took pictures of this clipping as well as the beam position on Steve's new Retro Position Sensor, but I can't find the cable for the Olympus 570UZ. Steve, please buy a couple more USB data cables of this particular kind so that we don't have to hunt so much if one of the cryo (?) people borrows a cable.

Attachment shows PMC power levels before and after alignment. After alignment, you can see spikes from where I was tapping the mounts in the beamline. We ought to replace the U-100 mount ahead of the AOM with a Polanski

EDIT: Cryo team returns cable - receives punishments. Picture added.

Attachment 1: PMC-IRSISSS.png
PMC-IRSISSS.png
Attachment 2: PA250052.JPG
PA250052.JPG
Attachment 3: PA280044.JPG
PA280044.JPG
  9291   Fri Oct 25 10:45:16 2013 SteveUpdatePSLlaser drift monitor set up

Quote:

Quote:

I wonder what's drifting between the laser and the PMC? And why is it getting worse lately?

 The PMC refl is bad in pitch today, and the transmission is only 0.76, rather than our usual 0.83ish.

I did a quick, rough tweak-up of the alignment, and now we're at 0.825 in transmission.

 The PMC transmission continuously degrades. In order to see what is really drifting the laser output after PBS was sampled as shown.

Attachment 1: laserDriftMon.jpg
laserDriftMon.jpg
Attachment 2: PMCT_120d.png
PMCT_120d.png
Attachment 3: PMCT_1000d.png
PMCT_1000d.png
  9290   Fri Oct 25 04:54:21 2013 MasayukiUpdateSUSETM violin mode

Summary

When PRMI + 2arms are locked yesterday, we heard the noise from suspension violin mode. For attenuation of that noise, we should design the resonant filter at that frequency and put into the ALS servo. I tried to measure the violin mode of ETMs SUS.

What I did

 1.The arms were locked by IR PDH. I used awggui to excite the suspention. I injected the Normal waveform, 10 Hz of bandwidth wave into C1:SUS-ETMs_ULCOIL_EXC. I put cheby filter in the FIlter of awggui. The order of that filter was 4, that has same bandwidth as that of injection wave and ripple was 4dB. I increase the injection gain with some ramp time(5sec). I swept from 600 Hz to 700 Hz. During that injection I saw the PDH error signal (POX11I and POY11I) in order to find resonance peak of violin mode.
 In ETMX resonances were easily found. That were at 631 Hz and 691 Hz. the 631 Hz peak was seen ALS error signal yesterday. On the other hand, I couldn't find ETMY violin mode. No peaks appeared any frequency.

2. For find the ETMY violin mode, I used dtt swept sine measurement. The excitation channel was C1:SUS-ETMs_ULCOIL_EXC. I measured the TF from excitation channel to POX11I and POY11I error signal. The measurement range was above 400 Hz and below 1000Hz,. The number of point is 600. I attached that result.
In ETMX curve, the coherence become bad near the resonant frequency of violin mode and also the TF is large. Although ETMX violin modes are obvious, ETMY violin modes are not visible. At 660 Hz, 780 Hz, 900 Hz the coherence is not good. That is because 60 Hz comb noise.

Discussion

 I attached the spectrum of the POX and POY error signal. Black and red curve is measured different time. I didn't inject any signal in both measurement, but the violin mode excitation has huge difference. Also there are peaks at beat frequency between violin mode and bounce mode(16 Hz), yaw motion(3 Hz). In ALS in-loop noise or XARM in-loop measurement, sometimes this region had big spikes. That was because of this resonance. And also that resonance peak couples to POY11I.

 I will measure the Q and design the resonant filter for ALS.

Attachment 1: violin1.pdf
violin1.pdf
Attachment 2: violin2.pdf
violin2.pdf
  9289   Fri Oct 25 04:03:40 2013 MasayukiUpdateLSC'scope and spectrum analyser for REFL165

As Jenne's Elog we want to see Spectrum and time series of REFL 165 (our PRMI LSC locking PD) to see if the signal is saturated while bring the arms into resonance.
I started to connect the spectrum analyser and the 'scope to REFL165 output.

Directional coupler (Mini=-circuits ZMDC-10-2 ZMDC-20-3) was connected just before the dimod boad input. The main output of coupler is plugged into demod board's input.The other output of the coupler is connected to AG4395A using BNC cable.

The spectrum analyser output can be read using netgpibdata in control room. The IP address is 192.168.113.108 and the GPIB address is 17. For this I dissconected the network hub from another AG4395A, which is at the front of 1X2 lack.

I didn't connected the 300 MHz 'scope right now, but tomorrow it will be connected using power splitter and also be able to get data by internet. For connect 'scope to network, I disconected the network hub from SR785.

  9288   Fri Oct 25 01:46:33 2013 ranaUpdateCDSfb acquisition of slow channels

Rather than limp along with a broken SLOW channel system, I fixed it so that the EDCU files made during the RCG build actually get used and added to the channel list (and thereby available in DV and trends).

I first started by adding all of the EDCU files. This completely fails; daqd just doesn't start and gives some weird exceptions.

So I removed a bunch of them and it runs OK now with ~15000 channels. Previously we had ~1500 slow channels.

An in-between config tonight had ~58000 channels and was also running fine, but the connection to the FB would time out when using DV after several minutes. Possibly we can fix this by adding some more RAM to the FB (the DAQD process uses up 45% of the CPU and 39% of the 8 GB of RAM).

Another issue in getting this to work was that there were a bunch of channel name conflicts between the old C0EDCU.ini and the sub-system EDCU files that I was trying to add. I went through by hand and deleted all of the duplicates from the old file. The new frame files are 80 MB, the old ones were 66 MB.

I hope that /frames doesn't become full - not sure how that is wiped...

  9287   Thu Oct 24 23:30:57 2013 jamieUpdateCDSnew dataviewer installed; no longer works on Ubuntu 10 workstations

Quote:

Quote:

I installed a new version of dataviewer (2.3.2), and at the same time fixed the NDSSERVER issue we were having with cdsutils.  They should both be working now.

The problem turned out to be that I had setup our dataviewer to use the NDSSERVER environment, whereas by default it uses the LIGONDSIP variable.  Why we have two different environment variables that mean basically exactly the same thing, who knows.

 Dataviewer seems to run fine on Chiara (Ubuntu 12), but not on Rossa or Pianosa (Ubuntu 10), or Megatron, which I assume is also something medium-old.

We get the error:

controls@megatron:~ 0$ dataviewer
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Error in obtaining chan info.
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1

Sadface :(   We also get the popup saying "Couldn't connect to fb:8088"

Sorry, that was a goof on my part.  It should be working now.

  9286   Thu Oct 24 23:25:37 2013 JenneUpdateLSCEnd transmission triggering

Quote:

Software (schmidt triggering) for end transmission QPDs.

 I have modified the ETM suspension models to include a schmidt triggering block, so that we can choose between using the high gain low power Thorlabs PD and the low gain high power QPD. 

The Thorlabs high gain PD signal is used as the signal to trigger on, so we need to put appropriate thresholds in.

If things are "triggered", that will imply that the Thorlabs PD is seeing a lot of power, so we should be using the QPD SUM channel instead.  There is a "choice" block after the trigger block, to do this switching.

Since the LSC model will only see the output of this choice block, the gain that is currently in C1:LSC-TR[X or Y]_GAIN should be moved to the end SUS model.  We also need to find the correct gain for the QPD sum channels so that they are also normalized to "1" for single arm full power so that we can smoothly go between the 2 diodes.

Rana has promised to make screens, and write scripts for the switching stuff.

  9285   Thu Oct 24 23:12:21 2013 jamieUpdateCDSnew dataviewer installed; no longer works on Ubuntu 10 workstations

Quote:

I installed a new version of dataviewer (2.3.2), and at the same time fixed the NDSSERVER issue we were having with cdsutils.  They should both be working now.

The problem turned out to be that I had setup our dataviewer to use the NDSSERVER environment, whereas by default it uses the LIGONDSIP variable.  Why we have two different environment variables that mean basically exactly the same thing, who knows.

 Dataviewer seems to run fine on Chiara (Ubuntu 12), but not on Rossa or Pianosa (Ubuntu 10), or Megatron, which I assume is also something medium-old.

We get the error:

controls@megatron:~ 0$ dataviewer
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Error in obtaining chan info.
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1

Sadface :(   We also get the popup saying "Couldn't connect to fb:8088"

  9284   Thu Oct 24 21:46:18 2013 KojiUpdateGreen LockingALS OFFSETTER calibration

Quote:

I calibrated the ALS-OFFSETTER output.
I measured the FSR of cavity in unit of counts. That was 395 counts. Our cavity FSR is 3.8 MHz, so 1 count of the OFFSETTER output is 9.7 kHz.

 Really? What cavity length did you use in the calculation?

  9283   Thu Oct 24 19:12:45 2013 MasayukiUpdateGreen LockingALS OFFSETTER calibration

I calibrated the ALS-OFFSETTER output.
I measured the FSR of cavity in unit of counts. That was 395 counts. Our cavity FSR is 3.8 MHz, so 1 count of the OFFSETTER output is 9.7 kHz.

  9282   Thu Oct 24 17:26:35 2013 jamieUpdateCDSnew dataviewer installed; 'cdsutils avg' now working.

I installed a new version of dataviewer (2.3.2), and at the same time fixed the NDSSERVER issue we were having with cdsutils.  They should both be working now.

The problem turned out to be that I had setup our dataviewer to use the NDSSERVER environment, whereas by default it uses the LIGONDSIP variable.  Why we have two different environment variables that mean basically exactly the same thing, who knows.

  9281   Thu Oct 24 17:18:44 2013 SteveUpdateSUSETMY oplev error signals are still bad

Quote:

 Just plot.

RA: I'm not sure how to interperet this; I think that the SUM channel is divided by the SUM so that this is supposed to be RIN, but not sure. Can someone please take a look into the SUS model and then explain in the elog what the SUM normalization algorithm is?

 

Attachment 1: ETMY_OPLEV_ERRORS.png
ETMY_OPLEV_ERRORS.png
  9280   Thu Oct 24 15:19:58 2013 KojiUpdateLSCPRMI + 2 ALS arms

all of complications of handing off

That involves:

- ALS error signals transfered to the LSC input matrix.

- Handing off from the ALS to the 1/sqrt(TRX)+offset signal

- Handing off to the RF signal

- And, of course, CM servo.

  9279   Thu Oct 24 14:14:18 2013 ranaUpdateLSCPRMI + 2 ALS arms

 Just in case people were confused, although the PRMI + 2 ALS arms were controlled, we weren't able to bring them in to resonance. They were in some unknown off-resonant state.

We can try to calculate the expected recycling gain (ignoring losses in the PRM) following section F.2.1 of my Manifesto:

T_PRM = 5.6%, R_ARMS ~ 98%, G_PRC ~38.

So the full TRX/TRY powers should be G_PRC/T_PRM = 690.

In our stable configuration, we were sitting at TRX/Y powers of ~5-10. Once in awhile we could get a state where the power was saturating the detectors at ~50 and possibly would have gone up to 100, but it was all oscillation at that point. (we've got to find and notch the ETM violin mode frequencies in the ALS feedback servos.

As we move in towards resonance, we have to now consider all of complications of handing off to various error signals and CARM optical spring compensation and RF saturation that have been discussed in Rob's thesis and Lisa's lock acquisition modeling.

  9278   Thu Oct 24 12:00:11 2013 jamieUpdateCDSfb acquisition of slow channels

Quote:

 

 While that would be good - it doesn't address the EDCU problem at hand. After some verbal emailing, Jamie and I find that the master file in target/fb/ actually doesn't point to any of the EDCU files created by any of the FE machines. It is only using the C0EDCU.ini as well as the *_SLOW.ini files that were last edited in 2011 !!!

So....we have not been adding SLOW channels via the RCG build process for a couple years. Tomorrow morning, Jamie will edit the master file and fix this unless I get to it tonight. There a bunch of old .ini files in the daq/ dir that can be deleted too.

I took a look at the situation here so I think I have a better idea of what's going on (it's a mess, as usual):

The framebuilder looks at the "master" file

    /opt/rtcds/caltech/c1/target/fb/master

which lists a bunch of other files that contain lists of channels to acquire.  It looks like there might have been some notion to just use 

    /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini

as the master slow channels file.  Slow channels from all over the place have been added to this file, presumably by hand.  Maybe the idea was to just add slow channels manually as needed, instead of recording them all by default.  The full slow channels lists are in the

    /opt/rtcds/caltech/c1/chans/daq/C1EDCU_<model>.ini

files, none of which are listed in the fb master file.

There are also these old slow channel files, like

    /opt/rtcds/caltech/c1/chans/daq/SUS_SLOW.ini

There's a perplexing breakdown of channels spread out between these files and C1EDCU.ini:

controls@fb ~ 0$ grep MC3_URS /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini
[C1:SUS-MC3_URSEN_OVERFLOW]
[C1:SUS-MC3_URSEN_OUTPUT]
controls@fb ~ 0$ grep MC3_URS /opt/rtcds/caltech/c1/chans/daq/MCS_SLOW.ini
[C1:SUS-MC3_URSEN_INMON]
[C1:SUS-MC3_URSEN_OUT16]
[C1:SUS-MC3_URSEN_EXCMON]
controls@fb ~ 0$

why some of these channels are in one file and some in the other I have no idea.  If the fb finds multiple of the same channel if will fail to start, so at least we've been diligent about keeping disparate lists in the different files.

So I guess the question is if we want to automatically record all slow channels by default, in which case we add in the C1EDCU_<model>.ini files, or if we want to keep just adding them in by hand, in which case we keep the status quo.  In either case we should probably get rid of the *_SLOW.ini files (by maybe integrating their channels in C0EDCU.ini), since they're old and just confusing things.

In the mean time, I added C1:FEC-45_CPU_METER to C0EDCU.ini, so that we can keep track of the load there.

 

  9277   Thu Oct 24 10:31:25 2013 SteveUpdateSUSETMY sensors compared to ETMX

Atm1,  The strong glitches are back.

Atm2,  SUS-ETMX & Y_SENSOR_LL Damping OFF at (ref0 & ref1). damping ON (red & blue)

ETMY sus looks OK

 

Attachment 1: 24h_glitching.png
24h_glitching.png
Attachment 2: dampingOffref.png
dampingOffref.png
  9276   Thu Oct 24 09:08:27 2013 jamie.UpdateLSCPRMI + 2 ALS arms

nice.

  9275   Thu Oct 24 08:04:54 2013 SteveUpdateLSCPRMI + 2 ALS arms

 

 Nice work. Congratulation

  9274   Thu Oct 24 04:13:15 2013 JenneUpdateLSCPRMI + 2 ALS arms

[Masayuki, Jenne, Rana]

We have, for the past hour and a few minutes, had PRMI + 2 arms locked.  Yup, that's right, we did it! (We never gave control of the arms to the IR LSC system, so it's kind of cheating, but it was still cool.)

A little after midnight, we felt that the Yarm was behaving well enough that we could give PRMI + 2 arms a try.  So we did.  Probably around 1am-ish, or maybe a little bit before, we had the system locked. 

How did we do it?

* Locked arms in IR to help find green beatnotes.

* Misalign ETMs, lock and align PRMI.

* Misalign PRM.

* Restore ETMs, find arm resonances, then step away (I did +3 counts, which is 29 kHz).

* Restore PRM, lock PRMI.

* Brought Xarm back close to resonance using ALS (-3 counts). It seems like this may not actually have gotten us back to perfect resonance, but that actually made bringing in the other arm easier.

* Brought Yarm back close to resonance using ALS (-3 counts). 

* Turned on Sensing Matrix notches and oscillators (10,000 counts for MICH, actuating on BS and PRM at 562.01 Hz, 200 counts for PRCL actuating on PRM at 564.01 Hz). 

* Stepped arms back and forth to see how things responded.

Notes:

During this process, particularly during the various arm steps, the PRMI lost lock many times.  However, the ALS system never lost lock for either arm, for an hour and a half or so.  Good work, ALS team!!  The PRMI would reaquire lock (sometimes we'd have to undo whatever arm step we just took, to get farther away from resonance) without any intervention.  It seemed that as we came closer to full arm resonance, we were never able to hold PRMI locked.  This is what is instigating some of our investigations for tomorrow.

Also, Rana reported to me that he turned the c1tst model back off, and opened the door(s?) to the ETMY rack to allow more air flow sometime before midnight, which seems to have reduced the rate of the CPU going over 61 microseconds, as well as reduced the number of times the ETMY suspension glitches.  We definitely need to make some changes so that we're not so close to the edge.  This may have been one of the big things that allowed our success tonight.

The transmission PDs at the ends of the arms are saturating around 50 counts (they have gains of 2e-3 so that they are roughly normalized to 1 being the max power in a single arm).  We need to commission the end transmission QPDs. 

All of the signals looked a little ratty, and we heard lots of noise - Rana suggests that we recommission our CARM servo.

ALS beat info:  [Xarm  40.9 MHz,  -11.4 dB], [Yarm  50.5 MHz,  -17.7 dB]

Things to look at tomorrow:

Data!  I should be able to extract sensing matrix information, even though my sensing matrix software isn't totally ready yet.  I know what the oscillators were doing, and I can look at the PD error signals.  We also save the Offsetter numbers, so I can kind of tell what the PRMI+arms situation was. 

Can we tell by looking at the end laser PZT feedback signals whether we're making our arms longer or shorter?  So that we can tell if we're putting on DARM or CARM offsets.

Spectrum and time series of REFL 165 (our PRMI LSC locking PD) to see if we're saturating while we bring the arms into resonance.  Basically, does anything bad happen, particularly since the PD is not a resonant PD, so there are some 1f signals floating around in addition to the 3f signals.  We want to put in a directional coupler after the PD, before the demod board, and send that signal to a spectrum analyzer and a 'scope.  Hopefully we can use the power of the internet to not need to sit in the IFO room saving data as we move the arms around.  Do we need to put bandpass filters on the PD signal before it goes to the demod board?

Optickle model of 1f vs. 3f signals in the different ports, as the CARM offset is reduced.

Violin notches for the arms - should be put into ALS and LSC models.  It looks like the modes are around 631 Hz, but we should check. 

Hardware for end low gain transmission QPDs.

Software (schmidt triggering) for end transmission QPDs.

Modifying / preparing a matrix in the ALS system so that we can give CARM and DARM offsets conveniently.

ELOG V3.1.3-