ELOG 40m

Laser 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

Attachment 2: CARMoffs2.png

Attachment 3: CARMcarpet.png

1466

Thu Apr 9 23:20:35 2009

Laser PM to REFL-DC transfer functions at multiple CARM offsets

Quote:

Here are the corresponding transfer functions for REFL-DC.

Attachment 1: CARMoffs1_r.png

Attachment 2: CARMoffs2_r.png

Attachment 3: CARMcarpet_r.png

1467

Fri Apr 10 01:24:08 2009

allegra 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).

1468

Fri Apr 10 03:10:08 2009

Laser 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

1469

Fri Apr 10 04:54:24 2009

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

1470

Fri Apr 10 18:11:18 2009

[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.

1471

Fri Apr 10 19:09:48 2009

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 Adjust	Output measured on scope	Oscillator Output Monitor
[V]	[Vpp]	[no units given on MEDM screen]
	All \pm 0.0159	all of this column is NEGATIVE
0.0000	3.838	0.007
0.5000	3.854	0.007
1.0000	3.838	0.006
1.5000	3.838	0.007
2.0000	3.838	0.006
2.5000	3.838	0.007
3.0000	3.838	0.007
3.5000	3.838	0.007
4.0000	3.838	0.007
4.5000	3.822	0.007
5.0000	3.822	0.012
5.5000	3.790	0.076
6.0000	3.758	0.257
6.5000	3.694	0.555
7.0000	3.615	0.931
7.5000	3.535	1.277
8.0000	3.456	1.532
8.5000	3.392	1.709
9.0000	3.344	1.829
9.5000	3.312	1.908
10.0000	3.296	1.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

Attachment 2: RFSliderAdjustCalibWithOsc.png

1472

Fri Apr 10 19:10:53 2009

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.

1473

Sat Apr 11 00:45:41 2009

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 ?

1474

Sun Apr 12 01:19:30 2009

New 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.

1475

Sun Apr 12 19:27:20 2009

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.

1476

Sun Apr 12 19:31:43 2009

Electronics

Amphony 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.

1477

Mon Apr 13 08:59:57 2009

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 ?

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

1478

Mon Apr 13 17:55:37 2009

PMC 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

1479

Mon Apr 13 18:57:03 2009

Alberto

Frogs

GPIB/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 ...

1480

Tue Apr 14 02:59:02 2009

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.

1481

Tue Apr 14 12:10:11 2009

Alberto

Frogs

GPIB/ETH Interface Troubles

Quote:

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.

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.

This morning Joe looked at my code and made me notice that for some reason the query to the Spectrum Analyzer made by netSock.recv(1024) contained two answers. It was like the buffer contained the answer two different queries.

After some experiment I found that basically the GPIB interface wasn't switching from the "auto 1" to the "auto 0" mode as it should. I rewrote part of the code and that seemed have solved the problem.

Still don't understand why it used to work in the past and then it stopped.

1482

Tue Apr 14 17:20:36 2009

Parallel Optickle

I wrote a parallel version of tickle() function for Optickle.
The attached ptickle.m, which provides ptickle() command, can be used as a drop-in replacement of tickle() command.
Just download it and place it in the @Optickle directory.
This command will run multiple instances of Matlab to calculate the frequency responses in parallel.
The speed gain is roughly proportional to the number of CPU cores you use.

To use multiple cores, you have to run matlabpool() command first. See the comment at the beginning of ptickle.m for more detail.
The progress bar is disabled at this moment because it is not clear for me how to make a single progress bar from multiple instances of Matlab.

I sent the code to Matt, so this may be included in the next release of Optickle.

Attachment 1: ptickle.m

% Compute DC fields, and DC signals, and AC transfer functions
%
% This is a parallelized version of tickle. You have to run matlabpool(n)
% command before using this command. matlabpool(n) will invoke n instances
% of matlab workers in your computer. Once you have started those workers,
% you can reuse them many times (i.e. you don't have to run matlabpoo(n)
% every time you use ptickle). Usually n should be equal to the number of
% CPU cores in your computer, but the Matlab parallel computing toolbox has
% the limit of maximum 4 workers for a local computer. If you use a cluster 
% of computers across a network, this limit does not apply. But I haven't

... 393 more lines ...

1483

Wed Apr 15 02:18:42 2009

nodus vfstab changed for rigel

nodus was hanging because it was trying to mount the cit40m account from rigel and rigel was not responding.

Neither I nor Yoichi can recall what the cit40m account does for us on nodus anymore and so I commented it out of the nodus /etc/vfstab.

nodus may still need a boot to make it pay attention. I was unable to do a 'umount' to get rid of the rigel parasite. But mainly I don't want anything in

the 40m to depend on the LIGO GC system if at all possible.

1484

Wed Apr 15 02:20:46 2009

We found that DMF/ was not an SVN working copy, so I wiped out the SVN version, imported the on-disk copy, moved it to DMFold/ and then checked out the SVN version.

We can delete DMFold/ whenever we are happy with the SVN copy.

1485

Wed Apr 15 03:52:27 2009

NDS client32 updated for DMF

DMF

Since our seisBLRMS.m complains about 'can't find hostname' after a few hours, even though matlab is able to ping fb40m,

I have recompiled the NDS mex client for 32-bit linux on mafalda and stuck it into the nds_mexs/ directory. This time I

compiled using the 'gcc' compiler instead of the 'ANSI C' compiler that is recommended in the README (which, I notice,

is now missing from Ben Johnsons web page!). Let's see how long this runs.

1486

Wed Apr 15 11:25:21 2009

Quote:

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.

Vacuum valve configuration is back to VACUUM NORMAL condition. RGA calibration completed.

RGA scan attached is the backgroud of the rga with std cal leak open, sn 08581

Krypton at amu 84 and Argon at amu 40 are the cal signals.

Attachment 1: rga-090415-bg-d7-cald2.png

1487

Wed Apr 15 17:11:37 2009

Edited c1psl.db to calibrate PMC's LO mon



Following the method in Peter's Elog, 

I edited c1psl.db to include the following: 


grecord(calc, "C1:PSL-PMC_LOCALC")
{
        field(INPB,"C1:PSL-PMC_LODET")
        field(SCAN,".1 second")
        field(PREC,"4")
        field(CALC,".955*LOGE(B)-17.11")
}

I restarted c1psl (had to go hit the physical reset button since it didn't come back after telnet-ing and "reboot"ing) to make this take effect.

Next step is to tell the PMC screen to look at this _LOCALC rather than _LODET, and the screen will be calibrated into dBm.

Right now, the screen is as it always has been, because after relooking at the calibration, I no longer believe it. This calibration claimes -19dBm for an LOmon value of 0.1200, when I actually measured +16dBm for this LOmon value. So I've screwed something up in doing my MatLAB calibration. I'll fix it tomorrow, and put in the correct calibration before I change the PMC screen.

RefCav, PMC, MC are all back and locked after my shenanigans.

1488

Thu Apr 16 11:17:56 2009

Edited c1psl.db to calibrate PMC's LO mon

Quote:


I edited c1psl.db to include the following: 


grecord(calc, "C1:PSL-PMC_LOCALC")
{
        field(INPB,"C1:PSL-PMC_LODET")
        field(SCAN,".1 second")
        field(PREC,"4")
        field(CALC,".955*LOGE(B)-17.11")
}

As it turns out, I apparently can't tell X from Y when fitting a function in a rush. The real calibration stuff which is now in c1psl.db is:

grecord(calc, "C1:PSL-PMC_LOCALC")
{
        field(INPB,"C1:PSL-PMC_LODET")
        field(SCAN,".1 second")
        field(PREC,"4")
        field(CALC,"1.004*LOGE(B)+17.76")
}

I restarted c1psl (again, had to go hit the physical reset button since it didn't come back after a telnet-reboot) to have it take in the changes.  The psl.db file that was in place before yesterday (before I touched it) is saved as psl.db.15Apr2009 just in case.

I edited the PMC EPICS screen to have the LO mon look at C1:PSL-PMC_LOCALC, which is the calibrated channel in dBm.  I also stuck a little label on the screen saying what units it's in, because everyone likes to know what units they're looking at.

1489

Thu Apr 16 16:26:57 2009

yoichi, pete

We installed the watchLockLoss script in scripts/AutoDTT/.  This script monitors arm power and uses command line
DTT to save 5 s snapshot of the interferometer when it senses loss of lock.  We ran it on linux and it seemed to
save an xml file about half the time; we'll try it on solaris.  

I managed to get up to arm power of about 20 a couple of times.  IFO lost lock a couple of times after turning
off moving zero.  MC2 would often get tripped by lock loss and need resetting.  Maybe we will try to stiffen the
op levs.

1490

Thu Apr 16 16:37:42 2009

It takes 18 months to double the computational power of microprocessors but it took man thousands of years to invent the zipper. I never really understood that till these days.

Here is a sample of my latest results from Optickle simulations of the locking signal for the Power Recycling Cavity.

Thanks also to Rob's revolutionary bidimensional rotating matrix idea (I can see entire books of linear algebra going to be rewritten now because of that) I could find the way to determine the optimal demodulation phases for the demod signals.

There were also an other couple of missing details. But that came easily along.

The parfor function for the parallel computation in Matlab sped up some loops by a factor of 100.

In these particular plots there's still no CARM offset scan. That's what I'm going to post next on the elog, together with the signals for the other degrees of freedom.

Attachment 1: 19_3f_Current_40m_plots_SUCCESS.pdf

1491

Thu Apr 16 17:19:44 2009

Quote:

It takes 18 months to double the computational power of microprocessors but it took man thousands of years to invent the zipper. I never really understood that till these days.

Here is a sample of my latest results from Optickle simulations of the locking signal for the Power Recycling Cavity.

There were also an other couple of missing details. But that came easily along.

The parfor function for the parallel computation in Matlab sped up some loops by a factor of 100.

In these particular plots there's still no CARM offset scan. That's what I'm going to post next on the elog, together with the signals for the other degrees of freedom.

Just to show that I'm confident I'm getting reasonable results, I'll post two PRC scans for different CARM. One set of plots is for the current 40m with -19.78 deg of SRM detuning phase, the other is for the Old Upgrade (9 Mhz vs the 11 currently planned) with no detuning phase.

I'm going to put together the results and get some conclusion about the 3f locking scheme for the current 40m and the upgrade.

Attachment 1: 04_3f_Current_40m_plots.pdf

Attachment 2: 11_3f_40mUpgrade_plots.pdf

1492

Thu Apr 16 17:48:00 2009

AutoDTT

As Peter mentioned in his entry on the last night's locking, I imported AutoDTT from Hanford.
It resides in /cvs/cds/caltech/scripts/AutoDTT/.
The main script is restoreRunSave, which takes three arguments, templete_file_name, result_file_name and log_file_name.
This script opens a template xml file and execute it. Then saves the result in the result file.
You can open the result file in a normal DTT.
You can call restoreRunSave from watch scripts, such as c1_watch_dr_bang.

watchLockLoss is a standalone watch script to detect a lock loss and call restoreRunSave.
It runs both on Linux and Solaris. However on Linux, diag fails 50% of the time with some glibc error.
So it is probably better to run it on op440m.

1493

Fri Apr 17 11:05:22 2009

Thursday night locking status

The last night, it was sort of robust to go up until arm power = 26.
The REFL_DC gain seems to change a lot around this region. So I did fine adjustments of the gain with small incremental steps of the arm power.
This work will continue.
The AutoDTT shows that the lock loss happens with an oscillation of CARM at around 100Hz. This indicates that the cross-over is the culprit.
I was also able to increase the CM UGF up to 10kHz.

1494

Fri Apr 17 11:37:32 2009

AutoDTT

In order to get test point data with AutoDTT, you have to pre-trigger test points you want to use.
This is done by starting a DTT measurement with necessary test points for a few second, then stop it but keep the DTT opened.
I made prepTP script which does this job.
It takes a file name of an XML file, which should include a DTT measurement setup with test point channels you want to open and the trigger time set to "now".
The script will open an xterm and run diag with the XML file. Unlike restoreRunSave script, it does not save the result nor quit diag. Therefore, you can keep the test points as long as you keep the xterm opened. You can manually exit the diag (Ctrl-D) when you no longer need the test points.
watchLockLoss script now calls prepTP at the beginning. Therefore, you have to be able to open an xterm. If you run the script through SSH, make sure that you give -X option to ssh.

1495

Sun Apr 19 03:34:05 2009

Tonight I was able to go up to arm power = 33, by mainly tweaking the DARM gain. A small progress.
In order to give more phase margin to the CARM MC_L path, I added a 300:100 filter to C1:LSC-MC.
To reduce the load to the lsc computer I deleted several filters from the filter bank, which were not used in the locking scripts.
Before I deleted the filters, I checked in the current chans directory into the svn repository.
If you want to restore the deleted filters, go back to the revision 36142.

1496

Sun Apr 19 11:34:33 2009

josephb

HowTo

USB Frame Grabber - How to

To use the Sensoray 2250 USB frame grabber:

Ensure you have the following packages installed: build-essential, libusb-dev

Download the Linux manual and linux SDK from the Sensoray website at:

http://www.sensoray.com/products/2250data.htm

Go to the Software and Manual tab near the bottom to find the links. The software can also be found on the 40m computers at /cvs/cds/caltech/users/josephb/sensoray/

The files are Manual2250LinuxV120.pdf and s2250_v120.tar.gz

Run the following commands in the directory where you have the files.

tar -xvf s2250_v120.tar.gz

cd s2250_v120

make

cd ezloader

make

sudo make modules_install

cd ..

At this point plug in the 2250 frame grabber.

sudo modprobe s2250_ezloader

Now you can run the demo with

./sraydemo or ./sraydemo64

Options will show up on screen. A simple set to start with is "encode 0", which sets the recording type, "recvid test.mpg", which starts the recording in file test.mpg, and "stop", which stops recording. Note there is no on screen playback. One needs an installed mpeg player to view the saved file, such as Totem (which can screen cap to .png format) or mplayer.

All these instructions are on the first few pages of the Manual2250LinuxV120 pdf.

1497

Sun Apr 19 11:51:05 2009

josephb

Mafalda may need an update

I tried installing libusb-dev on mafalda in order to try getting the usb frame grabber to work on it, but could not as it could not download the package.

I then tried to do a sudo apt-get update, which failed completely, as the repository seems to have ceased existing. Basically I had all 404 Not Found errors.

Turns out Mafalda is still running Ubuntu 7.04, whose support ended late 2008. So there's a couple things that can be done:

1) Ignore it, and simply not update Mafalda anymore. This also means some newer software and hardware simply won't work with it (like the usb frame grabber)

2) Try to find another, unofficial repository which still has all of the Ubuntu 7.04 packages.

3) Upgrade to a newer, still supported Ubuntu, such as 7.10, 8.04, or 8.10.

I'd personally lean towards the 3rd option, and go to the 8.04 long term support version. If people agree with it, I could do the upgrade sometime Monday or Tuesday.

1498

Mon Apr 20 05:18:42 2009

FM6 and FM10 of LSC-MC were restored

During tonight's locking work, I realized that FM6 and FM10 (both resonant gains around 20Hz) were actually activated by cm_step.
So I restored those filters from the svn history.
Instead, I removed a bunch of unused filters from LSC-DEMOD and LSC-DEMOD_A (moving zero filters) to off load c1lsc.

As for the locking itself, the DARM loop becomes unstable at around arm power = 30. I may have to add a filter to give a broader phase bubble.

1499

Mon Apr 20 11:57:27 2009

Mafalda may need an update

Quote:

I tried installing libusb-dev on mafalda in order to try getting the usb frame grabber to work on it, but could not as it could not download the package.

I then tried to do a sudo apt-get update, which failed completely, as the repository seems to have ceased existing. Basically I had all 404 Not Found errors.

Turns out Mafalda is still running Ubuntu 7.04, whose support ended late 2008. So there's a couple things that can be done:

1) Ignore it, and simply not update Mafalda anymore. This also means some newer software and hardware simply won't work with it (like the usb frame grabber)

2) Try to find another, unofficial repository which still has all of the Ubuntu 7.04 packages.

3) Upgrade to a newer, still supported Ubuntu, such as 7.10, 8.04, or 8.10.

I'd personally lean towards the 3rd option, and go to the 8.04 long term support version. If people agree with it, I could do the upgrade sometime Monday or Tuesday.

I don't see a reason to proliferate operating systems. Is there any reason we actually need Ubuntu? Can we put CentOS on it?

1500

Mon Apr 20 18:17:44 2009

CARM offset/Power rubric

Plotted assuming the average arm power goes up to ~80. No DARM offset.

Attachment 1: ARMpowersCARM.png

1501

Mon Apr 20 18:36:37 2009

Mafalda may need an update

Sadly, the sensoray crap doesn't seem to build on CentOS. I too would prefer a homogenous solution,
but I don't know how to make this happen without punishing Joe with sensoray driver development on CentOS.

1502

Mon Apr 20 19:51:51 2009

PMC has new Level 13 Mixer installed

The new Level 13 mixer on the PMC servo board is installed (minicircuits SRA-3MH). Since the RF output of the LO board was ~16dBm, I put a 3dB attenuator between the LO board and the LO input on the servo board. Since the previous cable was *just* the right length, this required adding a tiny bit of cable. I found a very short cable, which worked out nicely, and didin't leave bunches of extra cable between the two boards. One of these days if I have time (i.e. if it is necessary), I'll make a new cable for this purpose, so that we don't have 2 cables daisy-chained.

A note on the Mixer-replacement: The mixer on the PMC servo board is soldered in a set of 8 through-holes, not stuck in a socket. So I had to desolder the old Level 23 Mixer (minicircuits RAY-3) which was a total pain. Unfortunately, in this process, I lifted one of the pads off the back side of the board. Once the old mixer was removed, it became clear that the pin for the pad I had lifted was shorted via a trace on the front side of the board to the pin directly across from it. So when installing the new mixer, I did my best to get some solder into the through-hole for the lifted-pad-pin, and then tied it using a jumper wire to the pin that it's shorted to on the front of the board. You can't see the trace that shorts the two pins because it's underneath the mixer, when the mixer is installed. (Sidenote: after talking with Rana, this should be okie-dokie, especially if these are ground pins).

The PMC and MC locked nice and happily after I replaced the board and turned all the HV supplies back on, so I call this a success!

I also measured the OLG of the PMC servo after today's adventures in mixer-land. I get a UGF of 1.4kHz, with 66 degrees of phase margin. The method for this is in elog 924.

I checked the phase slider setting of the PMC phase screen by putting 30kHz at 100mV into the Ext DC input of the servo board, and looking at the 30kHz peak output of the Mixer Out. I fiddled with the phase slider, and chose the value for which the 30kHz peak was maximized. The phase slider is now set to 5.0V.

Attachment 1: PMColg20Apr2009.png

1503

Mon Apr 20 20:00:44 2009

IOO

McWFS gains re-allocated

Since it looks like the night time people have been running with a WFS gain of 0.05 and I like the slider
to be at 1.0, I lowered all of the WFS1/2_P/Y gains by 10 and increased the overall slider from 0.05 to 1.0.
So the loop gains are now 2x higher; with it like this I guess the UGFs are in the ~0.2-0.5 Hz range.

1504

Mon Apr 20 20:45:25 2009

General

SVN: project area added

I added the /cvs/cds/project/ directory to the SVN. I've noticed that we've been using target/ for code which is not
being targeted for any IOCs. This is out of line with the intention of separating real time FE code from just regular
code that we use for diagnostics or otherwise.

So please move all of your non-FE code over to project from target. And if you didn't have it in SVN at all, you
should experience level 3 shame and then import it.

1505

Mon Apr 20 23:27:59 2009

c1vac2 rebooted: non-functional for several months

VAC

We found several problems with the framebuilder tonight. The first symptom was that it was totally out of
disk space. The latest daqd log file had gone up to 500 MB and filled the space. The log file was full of
a lot of requests from my seisBLRMS.m code, but what was really making it so big was that it couldn't
connect to c1vac2 (aka scipe4) to make connections for some channels.

We looked into the daqd log files and this has been going on since at least December. There were several
'whited out' records for TP2 and TP3 in the Vacuum overview as well as the Checklist screen! Why did no
one notice this and fix it?? WE cannot function if we just ignore any non-functioning displays and say
"Oh, that never worked."

For sure, we know that it was working in 2005. Jay and Steve and Alan looked at it.

Today it was responding to ping and telnet, but not allowing any new connections. I hit the RESET button
on it. Several lights went RED and then it came back up. The readbacks on the EPICS screens are OK too.

I went into fb0 and deleted many of the GB size log files from the past several months. There is now
19GB free out of its local 33GB disk.

1506

Tue Apr 21 18:18:27 2009

Our Osaka TG360MB maglev failed with CSB error message. This means that the dry emergency landing bearing has to be replaced.

I will consalt with Osaka about the choice of replacing bearing or installing new spare tomorrow.

Mean while V1 is closed and the vac envelope is not pumped.

Valve configuration: BG -background, pumping on the RGA-only

High voltage to IOO PZT steering mirrors and OMC are turned off.

PSL output shutter is closed and manual block is in place.

I will start cooling the CYO pump in the morning, so the IFO will be pumped by noon.

Outgassing plus leakrate after 10 hrs the pressure is 2.3 mTorr

This rate of rise is normal and it is safe to work with the ifo.

Attachment 1: nopumping10h.jpg

1507

Wed Apr 22 11:16:26 2009

steve

Cryo pump is ON and the Maglev is dead

VAC

The CRYO pump cooled down and VC1 was opened. This valve configuration is Cryo-only

PSL output shutter opened at 4pm

PZT HV power supplies turned on for OMC and IOO steering mirrors.

There positions were not corrected to strain gauge values.

Ben helped us to conclude that the FAILURE led indicator is working correctly and

has nothing to do with the one lose, dangling wire#258 in the side connects of the vac rack.

I reset the CSB switch inside the Maglev controller and tried to start accelerating.

It fails after 2-3 sec and failure led light comes on.

Now we can say the MAGLEV 360 is DEAD and the new OSAKA TG420M can be swapped in.

However it requires new interface with our epics based MEDM or better...?

Attachment 1: cryoOn.jpg

1508

Thu Apr 23 13:55:43 2009

We successfully compiled and installed the Real time Code Generator "Hello World" example (which is a skeleton for the ETMX suspension controller) on megatron. In order to get it to compile, we had to add a flag indicating the computer is stand alone, and not using a myrinet card at the moment. This was done by adding the shmem_daq = 1 flag to the cdsParameters module. The symptom was it was unable to find gm.h (and there is no installed /opt/gm directory).

It is called "sam". It was installed to /cvs/cds/caltech/target/sam, and produced medm screens in /cvs/cds/caltech/medm/c1/sam. As nothing points to these, I figure it won't harm any of the current configuration, but lets us play around a bit. If by some strange reason, these do cause problems, feel free to remove them.

1509

Thu Apr 23 16:27:24 2009

Locking with the cryo-pump

The last night, the IFO was unstabler than usual and the locking script often failed before reaching the power up stage.
The failure happened at random points.
I'm not sure if this is related to the operation of the cryo-pump.
The mode cleaner reflection image seemed to move around more than usual. Maybe it was just a high seismic night.

1510

Thu Apr 23 16:35:23 2009

restoreWatchdog script

When the IFO loses lock during the lock acquisition steps, it often kicks the MC2 (through the CM servo) and trips the watchdog.
I wrote a script to restore the tripped watchdog (/cvs/cds/caltech/scripts/SUS/restoreWatchdog).
The script takes the name of a mirror (such as MC2) as an argument.
It will enable the coils and temporarily increase the watchdog threshold to a value higher than the current OSEM RMS signals.
Then it will bring the watchdog back to the normal state and wait for the mirror to be damped. After the mirror is damped enough, the
watchdog threshold will be restored to the original value.
The script will do nothing if the watchdog is not tripped.
I put this script in the drdown_bang so that the MC2 watchdog will be automatically restored when a lock loss kicks out the MC2.

1511

Thu Apr 23 16:38:33 2009

steve

vac valve relay box is shorting

VAC

Ben and I found this vacuum valve relay box intermittently shorthing yesterday.

It effects V4, V5, VA6 and VM1........ Please do not touch this box under the beam pipe next to the vac rack!

The function of this box to send 120VAC to the vacuum valve to move.

Attachment 1: vacrel.png

1512

Thu Apr 23 18:09:11 2009

The attached is the trend plot of the MC1 accelerometer for 3 days.
It is evident that the seismic level increased by a factor of two on Wednesday morning (when Steve started the cryopump).

Attachment 1: SeisTrend.pdf

1513

Thu Apr 23 21:13:37 2009