40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 283 of 349  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  361   Wed Mar 5 17:35:24 2008 ranaUpdateIOORFAM during MC lock
I used an ezcaservo command to adjust the offsets for Alberto's StochMon channels. They are all
at +2 V with no light
on the RFAM PD (MC unlocked).

Then I looked at 5 minutes of second trend around when the MC locks. Since Alberto has chosen
to use +2V to indicate zero RF and a negative gain, there is a large RF signal when the StochMon
channels approach zero
.

From the plot one can see that the RFAM for the 133 & 199 MHz channels is much worse than for the 33 and 166.
Its also clear that the turn on of the WFS (when the RFAMPD's DC light level goes up) makes the single demod
signals get better but the double demod get worse.
  363   Fri Mar 7 00:47:54 2008 ranaConfigurationPEMRanger SS-1
Yesterday evening around 7:30 PM, I changed the Ranger seismometer from a
vertical to a horizontal seismometer. To do this I followed the instructions
in the manual.
1) Lock it down.
2) Turn it sideways. Use the leveling screws to center the bubble level.
3) Carefully loosen the hanger rod and release slowly the tension to allow
   the mass to recenter.
4) Look through the little viewhole next to the rod to make the white lines
   line up. This means the mass is centered.
5) Look at the output on a scope. It should be freely moving with a ~1 sec.
   period.

The attached plot shows the before and after spectra.
  368   Tue Mar 11 23:14:01 2008 ranaConfigurationPEMAccelerometer and Seismometer movements
Steve and Matt moved the accelerometers and seismometers today.
The accelerometers are now placed around the MC and the seismometer is in-between MC1 & MC2.

We have changed the names of the acc channels to reflect whether they are close to MC1/MC3
or MC2. We tested the accelerometer to channel name mapping by switching gains at the wilcoxon
breakout box and also by tapping. It seems now that the previous setup near the ITMX/ETMX had
some few channels mislabeled which would have given some confusing results.

Alex, Jay, and Rolf came over today and installed, then de-installed some of the hardware for
sending the PEM channels over to the C1ASS machine where the adaptive filter front end will go.
Everything should be back to the way it was...hopefully, the guys will modify the ADCU PEM
code to send the signals to the new FE over the reflective memory net and then send them to the
MCL inputs of the suspensions. So the first incarnation should use the accelerometers and seismometer
to drive MC1 and/or MC3.
  369   Wed Mar 12 00:36:52 2008 ranaConfigurationPEMAccelerometer and Seismometer movements
I used the MISO FIR Wiener matlab code to see how well we might do in principle.

The attached 3 page PDF file shows the MC_L control signal (force on MC2) and the residual
after subtracting off the accelerometer and seismometer using a 32 Hz sample rate and
512 taps (page 1), 1024 taps (page 2), and 2048 taps (page 3). As Matt smarmily points out,
there's not a lot to win by going beyond 512; maybe a factor of sqrt(2) for a factor of 4
tap number.
  370   Wed Mar 12 00:40:35 2008 ranaConfigurationPEMAccelerometer and Seismometer movements
Same as above but with 2048 taps and a 128 Hz sample rate. Does much better at the 16 Hz bounce mode.
  371   Wed Mar 12 00:47:26 2008 ranaConfigurationPEMAccelerometer and Seismometer movements
And this is a cool snapshot showing how this operation used 16 cores on menkar !
  372   Wed Mar 12 23:05:44 2008 ranaUpdateIOOMC WFS
they are bad, somewhat

please fix
  387   Thu Mar 20 17:45:36 2008 ranaSummaryASSAdaptive Filtering in the ASS system
Over the past couple weeks we (Matt, Alex, Rob, me) have worked on getting an adaptive filter
system working. We wanted to load this system into c1ass to use this processor. The dither alignment
system hasn't been employed here for awhile and so we have just used this box.

The signals are acquired in the PEM ADCU. Alex modified the code there to send the signals over to
the new system. We also get the SUS-LSC_OUT signals from each of the suspensions so that we can
try to minimize them.

The outputs of the adaptive filter go into the unused SUS-MCL inputs of all the suspensions (except
for MC2). In the current setup, we have 6 accelerometers and 1 seismometer around the MC to be used
to demonstrate the principle of the whole thing.

Much more documentation and description of everything is necessary. We'll try to get Matt, Rob, and Alex
to use the elog.
  390   Fri Mar 21 17:01:21 2008 ranaConfigurationDMFLocale change on Mafalda & seisBLRMS restart
Ever since we moved the accelerometers to be around the MC and changed their names, the seisBLRMS
has not been working. I tried to restart it today after fixing the channel names in the par file
but I ran into a PERL / UBUNTU bug.
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LC_TIME = "en_US.ISO8859-1",
        LC_MONETARY = "en_US.ISO8859-1",
        LC_CTYPE = "en_US.ISO8859-1",
        LC_COLLATE = "en_US.ISO8859-1",
        LC_MESSAGES = "C",
        LC_NUMERIC = "en_US.ISO8859-1",
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

I don't know how this crept up or when it started. There were a bunch of fixes on the Ubuntu
forums which didn't work.

In the end I just set the 'unset' environment variables via our cshrc.40m file and this seemed
to make ligotools/perl happy. Lets hope this lasts...I love Linux.
  391   Fri Mar 21 23:15:11 2008 ranaConfigurationPEMRanger SS-1: New Setup
The Ranger seismometer has been in a bad state. Its output had been sent into a SR560 without any termination.

The seismometer is, internally, just a mass on a flexure with a magnet and a pickup coil for readout.
The damping of the system depends on the resistor hooked up across the coil. With the SR560 this is
the 1 Meg input impedance of it and so the mass is undamped.

I installed a 4300 Ohm resistor in there which seems to nearly critically damp it. However, this will not
allow us to reach the ultimate quantum noise limited performance. We will have to analyze the thermal, voltage,
and current noise to get that.

I then also increased the gain from 10 to 100 on the SR560. This should now make the front end noise of the
seismometer/SR560 close to equal to the noise of the PEM ADC.
  392   Fri Mar 21 23:17:47 2008 ranaConfigurationDMFseisBLRMS restarted
I updated the seisBLRMS par file with the new channel names of the accelerometers and the seismometer and then
recompiled the code and restarted it according to Rob's elog entry. It went fine and the seisBLRMS is now back in
action
.
  416   Mon Apr 7 16:42:56 2008 ranaUpdateComputerseLog intermittent
Phil Ehrens restarted Dziban again this morning. Looks like its still crashing each Monday around 8 AM.

Here is the latest suspect:

http://open.itworld.com/5040/reboot-unix-nlsunix-071225/page_1.html
  419   Tue Apr 15 18:44:25 2008 ranaConfigurationComputersRosalba
There is a new computer in the control room -- its called Rosalba,
in keeping with our naming convention. Its a quad-core machine that
Dmass found for cheap somewhere; we've installed the CentOS on it
that Alex recommended.

Its a 64-bit Linux and so that's going to cause some problems. Alex has done this
before and so we have some confidence that we can get our regular tools (DTT, Dataviewer)
to run on it.

I have made a new apps tree for all of our future 64-bit Linux machines. So far, there is
a 64-bit firefox and a 64-bit matlab in there. As we start using this machine some more, we
will be forced to install more 64-bit Linux stuff.

We also didn't have enough network cables to run to both linux3 and rosalba. Andrey has decided that we
should not ditch linux3 and so he will run another cable for it tomorrow.
  422   Wed Apr 16 21:11:12 2008 ranaSummaryDAQAA/AI Filters for the DAQ & FE systems
I used Foton to make up some new filters which will be used all over the project in order to downsample/upsample.

There will be 2 flavors:

  • The first one will be a downsampling filter for use in the DAQ system.
    Whenever you specify a sampling rate in the .ini files below the natural rate of the ADC,
    the data will be downsampled using this filter (called ULYAW_0 in the plot). This one was
    designed for flat bandpass and a 'good' bandstop but no care given to the phase shift.

  • The second one will be used in the FE systems to downsample the ADC signal which is often
    sampled at 64 kHz down to something manageable like 2k or 16k. This one was tweaked for
    getting less phase lag in the 'control' band (usually 3x or so below Nyquist).

Here is the associated filter file:
# SAMPLING ULYAW 16384
# DESIGN   ULYAW 0 zpk([0.512+i*1024;0.512-i*1024;2.048+i*2048;2.048-i*2048], \
#                      [515.838+i*403.653;515.838-i*403.653;318.182+i*623.506;318.182-i*623.506;59.2857+i*827.88; \
#                      59.2857-i*827.88],0.988553,"n")
# DESIGN   ULYAW 1 zpk([0.512513+i*1024;0.512513-i*1024;1.53754+i*2048;1.53754-i*2048], \
#                      [200+i*346.41;200-i*346.41;45+i*718.592;45-i*718.592],1,"n")
# DESIGN   ULYAW 2 zpk([0.768769+i*1024;0.768769-i*1024;1.53754+i*2048;1.53754-i*2048], \
#                      [194.913-i*331.349;194.913+i*331.349;53.1611+i*682.119;53.1611-i*682.119],1,"n")
###                                                                          ###
ULYAW    0 21 3      0      0 DAQAA         0.00091455950698073    -1.62010355523604     0.67259370084279    -1.84740554170818     0.99961738977942
                                                                   -1.72089534598832     0.78482029284220    -1.41321371411946     0.99858678588255
                                                                   -1.85800352005967     0.95626992044093     2.00000000000000     1.00000000000000
ULYAW    1 21 2      0      0 FEAA            0.018236566955641    -1.83622978049494     0.85804776530302    -1.84740518752455     0.99961700649533
                                                                   -1.89200532023258     0.96649324616546    -1.41346289594856     0.99893883979950
ULYAW    2 21 2      0      0 ELP             0.015203943102927    -1.84117829296043     0.86136943504058    -1.84722827171918     0.99942556512240
                                                                   -1.89339022414279     0.96048849609619    -1.41346289594856     0.99893883979950
  428   Fri Apr 18 19:46:08 2008 ranaUpdateASScheck adaptive
I restarted the adaptive code today using 'startass' and 'upass'.
I moved them into the scripts/ASS/ subdirectory.

Things seem OK. With a MU=0.03 and a TAU=0.00001, there is a still
a good factor of 10 reduction of the 3 Hz stack peak from the MC2
drive by doing FF into MC1.

I edited the ASS-TOP screen so that we could see such small numbers. I
also re-aligned the MC SUS to match the input beam (mainly MC3). The
cavity was locking on a TEM10 mode mostly -- we should look in the SUS
OSEM trends to see if MC3 has moved a lot in the last month or so.

Caryn Palatchi (a Caltech undergrad who just started working with us)
illustrated to me today that using even 1000 FIR taps is not very effective
for low frequency noise cancellation if you have a 2048 Hz sample rate. More
precisely, the asymptotic Wiener filter which our 'LMS' algorithm converges
to, can often amplify the noise at frequencies below f_sample/N_taps.

A less obvious thing that she also noticed is that there is almost no cancellation
of the 16.25 Hz bounce mode when using such a short filter. That's because that
mode is fairly high Q: the transfer function from the Z-ACC to the cavity signal
goes through the high-Q vertical suspension resonance; the FF signal we send back
goes through the low-Q horizontal pendulum response only. Therefore the filter
needs to be able to simulate ~100 cycles at 16.25 Hz in order to cancel that peak.

Duh.

The message here is: we need to find a computationally efficient way to do FIR filtering
or its not going to ever be cool enough to help us find the Crab.
  429   Sun Apr 20 18:23:27 2008 ranaSummaryLSClocking attempts
I noticed that the adaptive FF for the MC had stopped doing anything; this turned out
to be that the MC lost lock and the mcdown script turned off the FF path to MC1.

Although there's no elog, it looks like there was ~60 attempts at locking the IFO
between 12:38 and 4:27 on Saturday afternoon. I'm attaching here a plot showing
lock attempt durations and a histogram of lock times.
  430   Sun Apr 20 20:29:46 2008 ranaUpdateComputer Scripts / Programstdsread bugs
There seems to be a problem with reading the C1:IOO-MASTER_OVERFLOW field
when it is read in as part of an array. The only way for me to describe it
is to just attach the terminal output in this entry...this is mainly for
Matt and Rob
.


I first noticed that the output of the MC-WFS sensing matrix was different than
the outputs from a year ago, namely that the excitation channel was not being
processed and outputted to the file. This made the output matrix diagonalization
scripts fail.

I noticed that there are several different copies of tdsread.cc sitting around.
Looks like they have been hacked in the last year but I am not sure if this
excitation channel readback is an intentional change; email has been sent to the
authors to find out -- they will probably post some kind of response in the log
to resolve what's up.


My guess is that the problem with the IOO channel is not related, but I'm not sure:
op440m:WFS>set ioo_head = "${ifo}:IOO-"
op440m:WFS>set sus_head = "${ifo}:SUS-"
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3
_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${ioo_head}MAS
TER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3_MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0 0 0
op440m:WFS>echo `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
0
op440m:WFS>echo "tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW"
tdsread C1:SUS-MC1_MASTER_OVERFLOW C1:IOO-MASTER_OVERFLOW C1:SUS-MC2_MASTER_OVERFLOW
op440m:WFS>
  431   Sun Apr 20 23:39:57 2008 ranaSummarySUSMC1 electronics busted
I spent some time trying to fix the utter programming fiasco which was our MCWFS diagonalization script.

However, it still didn't work. Loops unstable. Using the matrix in the screen snapshot is OK, however.

Finally, I realized from looking at the imaginary part of the output matrix that there was something
wrong with the MC1 drive. The attached JPG shows TFs from pit-drives of the MC mirrors to WFS1.

MC1 & MC3 are supposed to have 28 elliptic low pass filters in hardware for dewhitening. The MC2
hardware is different and so we have given it a software 28 Hz ELP to compensate. But it looks like
MC1 doesn't have the low pass (no phase lag). I tried switching its COIL FM10 filters to make it
switch but no luck.

We'll have to engage the filters to make the McWFS work right and to get the MC noise down. This
needs someone to go check out the hardware I think.

I have turned the gain way down and this has stabilized the MC REFL signal as you can see from the StripTool screen.
  439   Tue Apr 22 22:51:30 2008 ranaConfigurationIOOMcWFS Status
I've been working a little on the MC WFS in the last few days. I have made many
changes to the sensing matrix script and also to the MCWFSanalyze.m script.

The output matrix, as it was, was not bad at low frequencies but was making noise in
the ~1 Hz band. Turning the gain way down made it do good things at DC and not make
things work higher.

The output matrix generating script now works after Rob fixed the XYCOM issue. Not sure
what was up there. As Caryn mentioned the SUS2.ini channels were all zero after Andrey's
PEM power cycle a few days ago. Rob booted c1susvme to get the SUS1 channels back and
today we did c1susvme2 to get the IOO-MC_L et. al. back.

Even after doing the matrix inversion there is some bad stuff in the output matrix. I
checked that the sensing matrix measurement has good coherence and I measured and set the
MC WFS RF phases (they were off by ~20-30 deg.). Still no luck.

My best guess now is that the RG filters I've used for POS damping and the movement of the
beam on the MC mirror faces has made a POS<->YAW instability at low frequencies. My next
move is to revert to velocity damping and see if things get better. Should also try redoing
the A2L on the MC1-3.
  445   Thu Apr 24 23:27:48 2008 ranaUpdatePEMacoustic noise in MC_F
I looked at the coherence between the Microphone in the PSL (PEM-AS_MIC) and the MC_F channel.

We want to use a microphone to do Wiener/Adaptive noise cancellation on the MC and so we need to
have a coherence of more than ~0.1 in order for that to have any useful effect.

The attached plot shows the spectrum and coherence with and without the HEPA turned up. As you can
see, the HEPA noise is just barely noticeable in this microphone. Mad

We will need to get something with at least 20 dB more sensitivity.:P
  446   Thu Apr 24 23:50:10 2008 ranaUpdateGeneralSyringes in George the Freezer
There are some packets of syringes in the freezer which are labeled as belonging to an S. Waldman.
Thu Apr 24 23:48:55 2008

Be careful of them, don't give them out to the undergrads, and just generally leave them alone. I
will consult with the proper authorities about it.
  451   Fri Apr 25 20:53:02 2008 ranaConfigurationIOOMC WFS with more gain
Quick update: we found that the reason for the MC WFS instability was that the digital anti-whitening was one but not the analog whitening.

We turned off the digital filters and were able to increase the gain by a factor of ~30. It is left like this, but if it hampers IFO locking then best to just turn it back down to an overall gain of 0.1 or 0.05.
  454   Sun Apr 27 02:11:11 2008 ranaConfigurationIOOMC WFS Notes
As noted in the elog from Friday, the WFS has been bad ever since someone switched on the digital whitening filters (FM1 & FM2)
in the MC WFS I&Q filter banks.

On Friday evening, John, Alan, and I went to the rack and verified that although the drawing shows a hookup for the whitening
filters, there is actually no such thing and so we can't have the whitening. So the anti-whitening turns on two lag filters
(2 poles at 4 Hz) and without the hardware this makes the servos unstable by adding 90 deg of phase lag at 4 Hz.

There are still several problems in this system:
- AD797 is used after the mixer. This is an unreliable, noisy part. We need to change this out
  with some OP27s so that this becomes reliable and has a more reasonable noise figure.

- Hard wire the whitening filters ON. We never want these to be off. Then we can turn on the
  anti-whitening. This will give us a factor of 100 better noise without filtering.

- The AD602 on the front of the whitening board has a 100 Ohm internal impedance and the 
  resistor between the demod board and the AD602 is 909 Ohms. This results in dividing the
  signal by 10.

- The signal at the ADC is ~100 cts peak-peak. The full ADC range is, of course, 65000 cts. So
  we could use a lot more gain. The mean quadrant signals are also ~100 cts so we could easily
  up the analog DC gain by a factor of 30 on top of the whitening filter increase.

- The AD602 at the input and the AD620 on the output are both variable gain stages but because
  of our lack of control are set to ambiguous gain levels. We should set the AD602 on the input
  to its max gain of 30 dB. With the -20 dB from the x10 voltage division, this will give us
  an overall gain of 3 for the puny demod signals.

  455   Sun Apr 27 05:09:30 2008 ranaConfigurationIOOMC WFS Whitening turned on
I hardwired on the MC WFS whitening filters.

The MAX333A switches which choose between whitening and bypass on that board were in the bypass position
because the Xycom220 connections are not there. So the control switch gets +15V but there is no pull
down to set it to the whitened mode.

The least invasive (easiest) change I could do was to tie all of those inputs to ground. This pulls a few mA
through the pull-down resistors but is otherwise innocuous. All of these control lines come in on the A-row
of the P1 connector, so I was able to solder a single wire across all of them to ground them all.

The WFS2 board had a blown electrolytic capacitor on the -15 V line and so there was probably some extra noise
getting in that way. I couldn't find any extra SMD to replace it so I cut the legs off of a 22 uF polarized
tantalum and stuck it in there. Its even close to being the same color. I checked out the other caps, and they were all
close to 68 uF as spec'd. This one had luckily blown open and so didn't suck down the Sorensen and destroy everything.

Plugged everything back in switched the WFS servos back on. Looks good. Took before and after spectra.

In the plot:

GREEN: Open loop dark noise before changes
RED: Open loop bright (MC locked but MCWFS off)
BLUE: Closed loop, MC locked

BLACK: Dark noise after whitening
ORANGE:Closed loop after whitening

The cursor is at 16.25 Hz, the SOS bounce mode.

The I ran the new setMCWFSgains script which uses pzgain to set the UGFs of the 4 loops to 4.01 Hz.
We have in the past had problems with high WFS gains causing instabilities with the CM servo around 10-30 Hz. If this happens we should
just lower the gain by a factor of ~5.
  459   Tue Apr 29 21:09:12 2008 ranaDAQCDSFE Filters
These are new FE filters for downsampling and upsampling. We will be going from native hardware sampling rates of 64k down to 32k, 16k, and 2k.

The attached plot shows these filters. They are 3dB ripple, 40 dB stopband, 4th order elliptic filters in which I have moved the zeros around
into good places (e.g. to the Nyquist frequency).

I'm also attaching the .txt file containg the filter coefficients and the design strings. The filters are called x2, x4, and x32, for the
D2, D4, and D32 downsampling, respectively.
  468   Thu May 8 01:07:24 2008 ranaSummaryLSCFrequency Noise test: MC Trans Backscatter
There is a wandering hump in the MC_F spectrum. It can move around on the time
scale of seconds between 40 and 200 Hz. It has an amplitude ~5-50x above the background spectrum. This seems new; I don't remember it
from a year ago. It is there in the IFO unlocked as well as the IFO locked as well as the locked + CM mode.

Tapping the AS table and/or the PSL table enclosures produces a broadband increase in the MC_F spectrum but doesn't
selectively effect the hump.

We thought it might be backscatter from the MC TRANS path and so we stuck in one of Steve's cool black glass V's into
this space. No effect. We should design a black glass V dump which we can replicate in large quantities for us and for
the sites. Something like the one on the LSC PDs, but with a 1 sq. inch opening area and a 2 inch depth.


We have also done this on the MC2 - TRANS beam before. No noise reduced there either.

The noise hump is appearing in MC_F but not in CARM_IN1 (after the CM handoff) so it seems like the MC has enough gain
to squash it. This also exonerates the MC REFL path since anything there would not be effected by the MC servo gain and
so would be visible in CARM.

My best guess is that there is something really, really scattery on the PSL table. But for now it looks like this is not a
big factor in the locking
issues.
  469   Thu May 8 01:50:25 2008 ranaSummaryASCArm Cavity HOM Resonances
Nothing new, but I calculated the frequencies of the first 22 higher order transverse modes and thought I might as well list them here.

To do this I took formula (23) from page 762 of Siegmans book and put it into this form:
         f_fsr
dfmn =   ----- * (m+n) * acos(sqrt(g1*g2))
           pi

and then calculated them from m+n = 1..22 (22 is not a magic number).

I also used the 'mod' function of matlab to calculate the frequency mod FSR so that we would know how far away
from a cavity resonance it is. I took as parameters: Larm = 38.55 m, Ritm = 1e6 m, Retm = 57.1 m. Kirk measured
the arm length some time ago; we need to measure the arm g-factor...maybe we'll put Tobin on this when he comes
by for a visit.

1.1936 (TEM01, TEM10)
2.3871
3.5807
0.8859 (TEM22, TEM13, TEM31)
2.0795
3.2730
0.5782
1.7718
2.9654
0.2706 (TEM55, ...)
1.4641
2.6577
3.8512
1.1564
2.3500
3.5436
0.8488
2.0423
3.2359
0.5411
1.7347
2.9282
  470   Thu May 8 02:06:13 2008 ranaSummaryCOCThermal Lensing in the ITMs and BS may be a problem
The iLIGO interferometers start to see thermal lensing effects with ~2W into the MC, a recycling
gain of ~50, and a beam waist on the ITMs of ~3.5 cm.

At the 40m, the laser power into the MC is 1/2 as much, the recycling gain is 4-5x less, but the
beam on the ITM has a 3 mm waist. So the power in the ITM bulk is 10x less but the power density
is 100x more
. Seems like the induced lens in the ITM bulk might be larger and that if there's
significant absorption on the ITM face (remember our Finesse is 4-5x higher) the beam size in the
arm cavity may also change enough to measure.

Someone (like Andrey) should calculate how much the beam sizes change with absorbed power.
  484   Sun May 18 18:14:30 2008 ranaSummaryComputer Scripts / Programsautlockers and cron
Today I noticed that the MC was unlocked, the MC autolocker was off, the PSL autolocker was off,
and the PSL Slow loop was off.

Reading through .log files and our elog it seems like things have been this way since Tuesday
when Andrey went around rebooting computers to bring things back.

And it looks like the ETMY optical lever is dead.

I restarted the PSL & MC scripts on op340m. I also locked and aligned the X arm to verify that
not everything is broken. The Y Arm is unalignable until we replace the HeNe.
  485   Sun May 18 18:44:48 2008 ranaSummarySUSOptical Lever SUM Trend - 80 days
I used the OL-Trend.xml dataviewer template to make this plot. Looks like the ETMY optical lever
slowly degraded over the last few months and then finally died 10 days ago. Would someone please
replace this laser and tune the lens position to minimize the spot size on the quad?
  486   Sun May 18 18:59:15 2008 ranaConfigurationComputerscron and hosts
I added rosalba to the hosts file for the control room machines (131.215.113.103).

I also removed the updateddb cron from our op440m crontab because it was running at 5 PM
even though I had set it to run at 5:57 AM. If it still runs then, it must be because of
another crontab.
  493   Fri May 23 08:24:24 2008 ranaAoGTreasureYoichi Aso has arrived !
  495   Sun May 25 16:20:27 2008 ranaConfigurationComputersjoinPDF
I have installed joinPDF 2.1 on rosalba. Since its written in Java, I didn't have to tinker with it at all to work on a 64-bit machine. Now Caryn can put all of her plots into 1 file.
  496   Sun May 25 19:33:16 2008 ranaUpdateIOOMC Bad after Re-alignment
The MC pointing was off and the transmitted power was down after John and Andrey brought it back after the bootfest.

I tried getting it back on Friday but was unsuccessful. Today, after the Phoenix Landing, I got it back to someplace
reasonable, but it still seems to be far off. I will check with Rob before we recenter and of the QPDs.

I had to move all of the MC SUS and also align the beam using the IOO periscope. The attached PDF shows some trends
over the last 80 days. You can see that the drop in MC TRANS is about the same as the drop in PMC TRANS.
  497   Sun May 25 20:30:25 2008 ranaSummaryPSLPMC Mode Matching
I checked the PMC mode matching by ramping the gain down to -10 dB (from +20 dB) and
moving the DC offset around until it caught lock on the different HOMs. Then I recorded
the output power (PMCTRANSPD). The DC offset on this EPICS channel was -0.013 V, so I
used its AOFF field to zero this out. Here is a list of the power in the largest modes:
Mode    Power (V)
----    ---------
00        2.7
10        0.2
04        0.04
02        0.02
BE        0.36      **Bull's Eye mode is TEM02 + TEM20. This can be fixed by lens adjustment.


N.B. To make a PNG file with DTT, just make an EPS file -- then use the eps2png perl script.
  499   Sun May 25 22:33:00 2008 ranaUpdateSUSETMY Oplev Work
I found the ETMY table in disarray and put the panels back on and put the ETMY OL laser back on the quad.

The next thing to do is clean up the table (there's a lot of junk on it) and then put in a lens within
6" of the laser to focus the beam on the quad (no metal diving boards and the lens should be either
uncoated (from our Edmunds collection) or a red lens, not 1064).

Then we have to put the beam cover back on between the viewport and the table.
  509   Sun Jun 1 19:25:10 2008 ranaConfigurationComputersnew monitor on op440m
I installed the new 24" flat screen on op440m. I increased the screen resolution from 1280x1024 to 1900x1200 using
the obscure 'fbconfig' command. You can type Google it if you want.

The old monitor is on the surplus cart. If you are reading this and think you might walk from the 40 over to
Bridge, please wheel the cart full of old computer equipment (on the north side of the control room) over to Larry.

I also copied over all the images on the D40 to a folder on Kirk's computer and deleted the originals.

Dan Busby also visited us last week to help us move the drill press from the Y arm down into the sub basement
of W Bridge.
  544   Wed Jun 18 18:50:09 2008 ranaUpdateComputersIt can only be attributable to human error. (HAL - 2001)
There has been another one of "those" events and all of the front end machines are down.

We poked around and Rob determined that the FEs can't get the EPICS data from EPICS. The
dcuepics machine is hooked up and running and all of the epics binaries are running. We also
tried resetting its RFM switch as well as power cycling the box using the "poweroff" command.


Not a sausage.

Rob points out that although the Signal Detect lights are on on the cards, the 'Own Data' light
is not on on the dcuepics' card although it is on for some of the cards on the other boxes.


We have placed messages with the Russian. If anyone sees him, don't let him go without fixing things.
Also, make sure to follow him around with notepad and possibly a camera to record what it is that
he does. If he's muttering, maybe try to use a sensitive hidden sound recorder.
  546   Thu Jun 19 20:22:03 2008 ranaUpdateGeneralFE Computer Status
I called Rolf (@LLO) who called Alex (@MIT) who suggested that we power cycle every crate
with an RFM connection as we did before (twice in the past year).

Rob and I followed Yoichi around the lab as he turned off and on everything. There
was no special order; he started at the Y-end and worked his way into the corner and
finishing at the X-End. Along the way we also reset the 2 RFM switches around fb0.

This cured the EPICS problem; the FEs could now boot and received the EPICS data.

However, there are still some residual channel hopping-ish issues which Rob and Yoichi are
now working on.
  547   Fri Jun 20 01:38:55 2008 ranaUpdatePEM20 day Weather
Yoichi showed me that its possible to make PNG images from PS using GS:
gs -sDEVICE=png16m -sOutputFile=foo.png bar.ps
  552   Mon Jun 23 15:22:04 2008 ranaBureaucracySAFETYLaser Safety Walkthrough today
  560   Tue Jun 24 22:43:23 2008 ranaSummarySEIStack TF
  570   Thu Jun 26 01:08:22 2008 ranaConfigurationGeneralAlarm Handler Revived
I have revived the Alarm Handler by turning it on on op540m and adjusting the levels of
several of the alarming channels to not alarm (like laser power). The alarm levels are now
set to something reasonable and people should start actually paying attention to them.

I also removed the EO Shutter and Stacis alarm stuff since we don't use them.

To really get in and edit it, you have to close the Alarm Handler and edit the file
in /cvs/cds/caltech/alh/. It allows you to add/subtract useful channels and put in
guidance information.

If the alarm handler beeps about something, don't just close it or silence it, Steve. Just
fix it somehow (either set the threshold better or find the real cause).
  571   Thu Jun 26 01:10:18 2008 ranaUpdatePEMAlarm Handler indicates that dust level is high
In its first useful act, the Alarm Handler started beeping indicating that the dust particle
counts for particles of diameter less than 0.5 micron had exceeded 5000 /cu. ft.
Here's the
80 day trend of particles, temperature and humidity:
  576   Thu Jun 26 18:27:04 2008 ranaUpdateComputer Scripts / ProgramsNo Dataviewer No Cry
Dataviewer was hanging. It would open the Grace window but then not plot anything. Since DTT was working
fine we diagnosed this as a DV only problem. It turned out that there was a boatload of messages in the
dataviewer queue. You can check for extra messaages using the command 'ipcs -q' and then use 'rmq' to remove them.

Dataviewer is working now.

Here's the screen dump from op440m:
op440m:~>ipcs -q
IPC status from <running system> as of Thu Jun 26 18:19:32 PDT 2008
T         ID      KEY        MODE        OWNER    GROUP
Message Queues:
q        400   0x1a51     -Rrw-rw-rw- controls    staff
q          1   0x501      -Rrw-rw-rw- controls    staff
q          2   0x512      -Rrw-rw-rw- controls    staff
q        103   0x553      -Rrw-rw-rw- controls    staff
q          4   0x574      -Rrw-rw-rw- controls    staff
q          5   0x18be     --rw-rw-rw- controls    staff
q         56   0x1d9f     -Rrw-rw-rw- controls    staff
q          7   0x1e56     -Rrw-rw-rw- controls    staff
q          8   0x1efd     -Rrw-rw-rw- controls    staff
q        109   0x2044     -Rrw-rw-rw- controls    staff
q         10   0x207a     -Rrw-rw-rw- controls    staff
q         11   0x24c4     -Rrw-rw-rw- controls    staff
q         12   0x24d7     -Rrw-rw-rw- controls    staff
q         13   0x251b     -Rrw-rw-rw- controls    staff
q         14   0x2fe8     -Rrw-rw-rw- controls    staff
q        115   0x3a65     -Rrw-rw-rw- controls    staff
q        116   0x967      -Rrw-rw-rw- controls    staff
q         17   0x98e      -Rrw-rw-rw- controls    staff
q        118   0x456c     -Rrw-rw-rw- controls    staff
q        669   0x194      -Rrw-rw-rw- controls    staff
q        620   0xe70      -Rrw-rw-rw- controls    staff
q         71   0x15d0     -Rrw-rw-rw- controls    staff
q        222   0x3586     -Rrw-rw-rw- controls    staff
q        173   0x5e37     -Rrw-rw-rw- controls    staff
q        624   0x5e4d     -Rrw-rw-rw- controls    staff
q        475   0x10d7     -Rrw-rw-rw- controls    staff
q        176   0x5ee3     -Rrw-rw-rw- controls    staff
q        277   0x4e22     -Rrw-rw-rw- controls    staff
q        428   0x25f3     -Rrw-rw-rw- controls    staff
q         29   0x3354     -Rrw-rw-rw- controls    staff
q        180   0x368f     -Rrw-rw-rw- controls    staff
q        131   0xb0f      -Rrw-rw-rw- controls    staff
q         82   0x47a5     --rw-rw-rw- controls    staff
q         83   0x4b83     -Rrw-rw-rw- controls    staff
q         34   0x4f6d     -Rrw-rw-rw- controls    staff
q         85   0x4539     -Rrw-rw-rw- controls    staff
q         86   0x67a1     --rw-rw-rw- controls    staff
q         37   0x4b7      -Rrw-rw-rw- controls    staff
q         38   0xd37      -Rrw-rw-rw- controls    staff
q         39   0x156c     -Rrw-rw-rw- controls    staff
q         40   0x2b62     -Rrw-rw-rw- controls    staff
op440m:~>rmq
---------------------------------------------------------------
Deleting message queues which are owned by user: controls ....
---------------------------------------------------------------
      Deleted message queue: 400
      Deleted message queue: 1
      Deleted message queue: 2
      Deleted message queue: 103
      Deleted message queue: 4
      Deleted message queue: 5
      Deleted message queue: 56
      Deleted message queue: 7
      Deleted message queue: 8
      Deleted message queue: 109
      Deleted message queue: 10
      Deleted message queue: 11
      Deleted message queue: 12
      Deleted message queue: 13
      Deleted message queue: 14
      Deleted message queue: 115
      Deleted message queue: 116
      Deleted message queue: 17
      Deleted message queue: 118
      Deleted message queue: 669
      Deleted message queue: 620
      Deleted message queue: 71
      Deleted message queue: 222
      Deleted message queue: 173
      Deleted message queue: 624
      Deleted message queue: 475
      Deleted message queue: 176
      Deleted message queue: 277
      Deleted message queue: 428
      Deleted message queue: 29
      Deleted message queue: 180
      Deleted message queue: 131
      Deleted message queue: 82
      Deleted message queue: 83
      Deleted message queue: 34
      Deleted message queue: 85
      Deleted message queue: 86
      Deleted message queue: 37
      Deleted message queue: 38
      Deleted message queue: 39
      Deleted message queue: 40
---------------------------------------------------------------
op440m:~>
  578   Thu Jun 26 20:59:22 2008 ranaUpdateComputer Scripts / ProgramsAlarm Handler
Please do not turn off the Alarm Handler on op540m.
  579   Thu Jun 26 21:07:11 2008 ranaConfigurationASSdust & MC1
I realized today, that yesterday while we were trying to debug the adaptive noise canceler, I turned
off the analog dewhitening on MC1. I did this by changing settings on the Xycom screen but I
forgot to elog this -- this may have caused problems with locking via increased frequency noise.
I have now returned it to its nominal, dewhitening on, configuration.

I also used mDV to look at the last year of dust trend. I have plotted here the cumulative
histogram in percentile units of the 0.5 micron dust level. The x-axis is in units of particles per cu. ft.
and the y-axis is percentage. For example, the plot tells us that over the last year, the counts were
below 6000, 90% of the time. I have set the yellow and red alarm levels to alarm at the 95-th and 99-th
percentile levels, respectively.
  593   Sun Jun 29 18:58:43 2008 ranaSummaryComputers1e20 is too big for AWG and/or IOVME
While testing out my matlab/awgstream based McWFS diagnostic script I accidentally put a
huge excitation into
C1:IOO-WFS1_PIT_EXC
. This went to 1e20 and then caused
some SUS to trip and c1susvme2 to go red. I tried booting it via the normal procedures
but it wouldn't come back, even after 2 crate power cycles. I also tried booting AWG
via the vmeBusReset, but that didn't do it. Then I booted c1iovme from the telnet prompt
and then I could restart c1susvme2 successfully.

The reason the excitation was so large is that the following filter command is unstable:
[b,a] = butter(4,[0.02 30]/1024);

The low pass part is OK, but it looks like making such a low frequency digital filter
is not. Que lastima. On the bright side, the code now has some excitation amplitude
checking.
  594   Sun Jun 29 19:19:47 2008 ranaSummaryIOOTrends of the PSL/IOO Quads over 1000 days
Only IOO POS has been working for the past 2 years. I guess we should recommission the IOO ANG and REFL QPDs
  597   Sun Jun 29 20:29:48 2008 ranaUpdatePSLCorrelation of PSL SLOW control v. Room temperature
ELOG V3.1.3-