ELOG 40m

half-micron particle count is alarming

PEM

The 0.5 micron dust monitor count is now pretty high (36000). I wandered around the lab to see if there was anything
nasty going on but I didn't see or smell anything in particular. Since today Alberto was sitting around where the
dust monitor is while aligning the PSL beam, we should blame him. Its either garlic, cologne, or time to bathe.

The 400 day hour trend shows that while the counts are not so unusual, the 40m is dirtier than it was last year.

Attachment 1: Untitled.png

Attachment 2: dust.png

1171

Wed Dec 3 19:21:09 2008

I looked at the Ranger signals. Somehow it has a relative transfer function of 'f' between it and the Guralp.

      Ranger
i.e.  ------ ~ f
      Guralp

which is strange since according to their manuals, they should both be giving us a voltage output which is proportional
to velocity. I checked that the Ranger only has a load resistor and then an SR560 low pass at 300 Hz. Jenne assures
me that the Guralp breakout box shouldn't have any poles either (to be double checked). Its a mystery.

We made sure that the SR560 now is DC coupled, G = 100, & 1-pole low pass at 300 Hz. I moved it over next to the Guralp
(went through the mass recentering procedure after forgetting to lock it before moving). It is behaving as it was
before.

Attached is a 2 page PDF of the comparisons. The 'MC1' channels are Guralp and 'MC2' is Ranger.

The second attachment compares our seismometers (in counts) with the LHO Guralp seismometers. There's no high frequency
rolloff there like what we see here so I bet a dollar that there's a pole in the Guralp box somewhere.

Attachment 1: c.pdf

Attachment 2: wsnb.pdf

1179

Fri Dec 5 09:29:59 2008

drum modes observable without excitation

Not sure what the y-scale is since there aren't any y axis labels in the plot, but it seems like we
now get an SNR of a ~few with a BW of 0.1 Hz. IN principle, the frequency noise out of the PSL ought
to be limited by the VCO phase noise at these frequencies (sort of) so the broadband MC_F level
is very roughly equal to 20-100 mHz/rHz.

Since dnu = dL*(c/lambda)/L_MC, the thermal peaks have a height of ~10^-15 m_RMS. We (Caryn) should check
that these numbers are true and then see if this is the correct amount of energy for thermally excited
mirror modes.

1180

Fri Dec 5 14:13:41 2008

MC trend for the last 4 days

The MC has stayed locked for ~3 days! I just broke it to reset the MZ.

Attachment 1: g.png

1183

Sun Dec 7 16:02:46 2008

Mag 5.1 EQ halfway to Vegas

There was a Mag 5.1 EQ Friday night at 8:18 PM.

It tripped most of our optics. They all damped down passively except for MC2. Further more, ITMY seems to have come back to a different place.

Don't know why MC2 was so upset but I think maybe its watchdog didn't work correctly and the side loop is unstable when there are
large motions. After I lowered the side gain by 10x and waited a few minutes it came back OK and the MC locked fine.

I have just now put all the WDs into the Shutdown state so that we can collect some hours of free swinging data to see if there's been
any damage. Feel free to redamp the optics whenever you need them. Someone should do the eigenfrequency check in the morning and compare
with our table of frequencies in the wiki.

I excited the optics using the standard SUS/freeswing-all.csh script. Here's the output:

Excited all optics
Sun Dec  7 16:07:32 PST 2008

Attachment 1: g.png

Attachment 2: Untitled.png

1184

Sun Dec 7 16:12:53 2008

because it was red

Fri Jan 2 17:20:44 2009

40m GWINC

I have made a '40m' directory in the iscmodeling CVS tree which allows one to run a 40m version of GWINC.

As does the previous one, it takes the default advLIGO config file and modifies some of the struct parameters
to make it appropriate for the 40m.

To make it run, I have added susp1.m to the GWINC directory. This calculates suspension thermal noise using
the Gonzalez-Saulson method that was later extended to
mirrors by Y. Levin. This is also the code used in the LIGO Noise Budget at the sites.

The previous code was giving a much larger value for thermal noise (probably because I didn't understand how
to use it right). It was based on a SURF report from '99.

Since we will have a mixture of MOSs and SOSs in the arms, I have just used SOSs in the model. So the suspension
thermal noise is overestimated by ~sqrt(2) (and realistically its uncertain by a much larger factor).

Since the new code now uses GWINC, the mirror and coating thermal noise are now more correct and use the
coherent therm-optic noise picture.

The 2 page PDF file shows the noise for 0 deg and 90 deg tuning of the SRC.

Although it looks like, from this plot, that we could measure coating thermal noise at the 40m, in reality we would have
to fix all of the technical noise sources first. Just the coil driver noise is probably at the level of 3 x 10^-17 m/rHz
at 100 Hz.

Attachment 1: bench40.pdf

1217

Thu Jan 8 16:49:37 2009

HP 5550dtn (Grazia) set up on allegra

lore

Quote:

I set up printing to grazia from allegra. The CUPS interface was not as straightforward as Tobin had made it seem in the Wiki. I had to type in the IP address and port number by hand.

The steps (AFAIR):

1) Goto http://localhost:631/
2) Click on "Add Printer"
3) Choose HP JetDirect
4) Use the correct address (socket://131.215.115.220:9100)
5) Choose HP and the 5550 postscript driver as the options
6) Try to only print useful stuff and not kill too many trees.

It ought to be root to do that.

1230

Thu Jan 15 22:30:32 2009

I tried to restart the DMF using the start_all script: http://dziban.ligo.caltech.edu:40/40m/280

it didn't work Frown

1239

Mon Jan 19 18:21:41 2009

loadLIGOData a GUI for mDV

The tool is very nice; I looked at the seismic trend for 16 days (attached).
However, it gives some kind of error when trying to get Hanford or Livingston data.

Attachment 1: a.png

1242

Wed Jan 21 22:53:08 2009

AS CCD centering and ASDD demod phase

Just my opinion, but I think all we want out of the DD signals is something to control the DRM
and not be sensitive to the carrier and the CARM offset. So if the handoff can be done so that
the lock point is unchanged from single demod then everything is fine.

A second order concern is how the 133 & 199 MHz signals are mixed in order to minimize the
matrix cross-coupling and the SNR of the diagonal elements.

1297

Thu Feb 12 14:39:07 2009

Silicon Beam Dump test

Yesterday evening, Ken Mailand and I tested the reflectivity of a piece of polished Silicon. Since Silicon has such a high thermalconductivity (compared to stainless and fused silica) and can take much more heat than black glass and should have a very good BRDF and should absorb most of the 1064 nm light if we hit it at Brewster's angle, we want to try it out in the first version high power, low scatterbeam dump. This dump will be a 'V' style dump like what Steve has tested nearly a year ago, but the incoming beam will first hit this piece of Silicon.

The pictures of the setup and the Silicon with the beam hitting it are here.

Brewster's angle for p-pol at 1064 nm is 74.2 deg (n = 3.53 @ 1064 nm). We set up a cube polarizer on the output of the ~1064 nm CrystaLaser. 144 mW got to the Si; the reflected beam was ~1.9-2.0 mW after tuning the angle for minimum power. Via eyeball and protractor it seems that we're at ~74 deg. So the reflectivity is < 1.5-2%. This is good enough; the reflected power will be < 1 W in all cases for eLIGO and that can be absorbed by the rest of the stainless V dump. The 35 W of heat in the silicon will be mostly gotten rid of through conduction into the attached heat sink fins.

This kind of dump would go into places like the PMC-REFL, MC-REFL, & IFO-REFL, where we occasionally need to take high power, but also are sensitive to backscatter.

1307

Mon Feb 16 00:43:46 2009

medm directory wiped on nodus

I accidentally did an 'rm -rf' on the medm directory in nodus, instead of on my laptop as was intended.

I then did an svn checkout. So everything should be current as of the last update, but I am sure that
we have not done a checkin on all of the latest screen enhancements. So...we may have to revert to the
Sunday morning tar to get the latest changes back.

1312

Mon Feb 16 20:47:48 2009

Mode Cleaner WFS Loop Gain change

I found the MCWFS gain slider down at 0.012. In this state the UGFs are probably around 10-30 mHz
and so there is no reduction of seismic noise. It is mainly a DC alignment tool in this state.

We often have reduced the loop gain thusly, to prevent the dreaded "MCWFS eating CM loop gain" disease.
That disease is where there are CM loop instabilities at ~5-30 Hz because of loop cross-couplings
who's exact nature has never been understood (TBI).

Today, I implemented a 4th order, 7 Hz low pass (RLP7) into the loops and turned up the gain by a factor
of 30 to 0.3. In this state, the damping time constants seem to be ~0.5-2 seconds as shown in the first
PDF. I didn't have enough patience to do the interminable swept sine measurements down to 0.1 Hz.

The second PDF shows the Bode plot of the RLP7 filter compared to the pre-existing but unused ELP10.

The third PDF shows my estimate of the OLG TF. This is made by just putting a "Pendulum" filter into the
MCWFS bank and then plotting all the filters together using FOTON. The BLUE curve shows the old TF but
with the new high gain and the RED curve shows the new TF with the new gain.

With this new filter, I bet that we can get away with the higher WFS gain, but if there's any problem during the
handoff, the gain should be reverted to the low value.

In the 4th PDF file, I plot the spectra of 4 of MC2's control signals so that you can see what is bigger than what.
ASCPIT is the one that has the feedback from the WFS's in it. These are all just in units of counts and so to compare
them in some sort of displacement units you have to take into account the pitch moment of inertia, the mirror mass,
and the mis-centering of the beam from the center of rotation of MC2...

Attachment 1: pmc-pzt-cal.pdf

Attachment 2: a.pdf

Attachment 3: olg.pdf

Attachment 4: mc2.pdf

1315

Mon Feb 16 23:09:52 2009

MC Servo Board offset gone bad!

Electronics

The attached plot shows that someone broke the MC_SUM_MON channel around 10:30 AM this past Wednesday the 11th. This is the EPICS monitor of the MC error point.

Come forward now with your confession and I promise that I won't let Steve hurt you.

Attachment 1: mcoff.png

1320

Wed Feb 18 19:13:20 2009

SVN & MEDM & old medm files

Allegra had a 2 year old version of SVN installed and CentOS (yum) couldn't upgrade it, so I did an 'svn remove subversion'
and then a 'svn install subversion' to get us up to the Dec '08 version (1.5.5) which is the latest stable.

I also removed all of the old ASS medm directories without backing them up. There's a new RCG script version which is
fixed so that it no longer dumps these old medm directories in there; there's no need since there's already an
medm archive area.

I also removed the medm/old/ directory, did an svn remove, and then copied it back. This is the only way I know of
removing something from the repository without removing it from the working directory.

1321

Wed Feb 18 21:03:22 2009

ETMY Camera work not elogged!

Cameras

The control room video is showing us a false ETMY image. Who worked on the ETMY camera or video today??!!

1322

Wed Feb 18 21:10:21 2009

MC Drumhead mode lost again

In early December, Caryn and I noticed that the MC Drumhead mode was visible at the Qmon point of
the MC demod board using a spectrum analyzer and no external excitation of the MC mirrors. We then
started tracking the MC Drumhead modes.

Today I found that it is gone again. It also wasn't there when I looked for it in 2007. Mad

I looked at the MC error point spectrum and it seemed reasonable. Changing the gains in the MZ, ISS, PMC, & FSS
had no good effect on the noise spectrum.

The voltage noise above 10 kHz in the MC error point is increasing like ~f. I think that this means that
the leftover is the noise from the FSS. Below 10 kHz it is the noise of the VCO (10 mHz/rHz).

One possibility is that the high frequency noise changes with the mood of the NPRO. There should be no
frequency noise induced by the decay of the PA diode power. We can do an NPRO SLOW scan to see if there
is some kind of mode hop noise happening.

1357

Wed Mar 4 23:42:45 2009

I made the following change to correct the sign of the 126MON channel:

allegra:c1aux>ezcawrite C1:PSL-126MOPA_126MON.EGUF -410
C1:PSL-126MOPA_126MON.EGUF = -410
allegra:c1aux>ezcawrite C1:PSL-126MOPA_126MON.EGUL 410
C1:PSL-126MOPA_126MON.EGUL = 410
allegra:c1aux>

1360

Thu Mar 5 02:24:19 2009

I added the following repos which I found on allegra to megatron and then did a 'yum install sshfs' on both machines:

allegra:yum.repos.d>l total 28 -rw-r--r-- 1 root root 428 Feb 12 16:47 rpmforge.repo -rw-r--r-- 1 root root 684 Feb 12 16:47 mirrors-rpmforge -rw-r--r-- 1 root root 1054 Feb 12 16:47 epel-testing.repo -rw-r--r-- 1 root root 954 Feb 12 16:47 epel.repo -rw-r--r-- 1 root root 626 Feb 12 16:47 CentOS-Media.repo -rw-r--r-- 1 root root 1869 Feb 12 16:47 CentOS-Base.repo -rw-r--r-- 1 root root 179 Feb 12 16:47 adobe-linux-i386.repo

This also required me to import the rpmforge GPG key:

sudo rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt

1370

Sun Mar 8 23:09:26 2009

Not even data retrieval working

Although getting the regular DAQ data works, we can't get any testpoints.

I tried restarting tpman several times; there's no inittab on fb40m for this so we should get Alex to set one up when he comes.
I also tried various power cycles and reboots: daqawg, daqctrl, etc. I also notice that Osamu's setup of new stuff is connected to
the same rack and power strips as all of our sensitive DAQ machines. We should find out if there was any hardware installed in the
last couple days; it would be easy to accidentally unplug or damage on of our fibers.

I moved the old tpman.log over to tpman.log.090308. It starts out with a header and then just lists when each TP is requested.

When restarting tpman it puts the following into the terminal:

fb:controls>./tpman &
[1] 1037
fb:controls>VMIC RFM 5565 (0) found, mapped at 0x2868c90
VMIC RFM 5579 (1) found, mapped at 0x2868c90
Could not open 5565 reflective memory in /dev/daqd-rfm1
16 kHz system
Spawn testpoint manager
Channel list length for node 0 is 4168
Test point manager (31001001 / 1): node 0

which is OK?; its the same startup outputs that are in the old log file. It would be nice if there was not and error message about the RFM.
Requesting new testpoints via tdsdata, dtt, or the diag command line doesn't seem to work. tpman doesn't spit anything out although 'tp show 0'
does show that the TP is selected.

Once Alex fixes the 'tpman' issue, we should make sure to put an inittab or startup script in there so that tpman writes a log
file and also archives its old log files upon a restart.

1371

Sun Mar 8 23:14:52 2009

tdsdata doesn't work

Matt logged in and rebuilt the TDS stuff for us on Mafalda in /cvs/cds/caltech/apps/linux/tds_090304.

He says that he can't build his stuff on 64-bit because there's not a sanctioned 64-bit build of GDS yet.

This should have all the latest fixes in it. I tried using both the old and new code from allegra and they both are fine:

./tdsdata 16384 2 C1:IOO-MC_F > /users/rana/test.txt

I loaded the data I got with the above command and there were no data dropouts. Possibly the dropout problem is only

associated with testpoints and so we have to wait for the TP fix.

1378

Mon Mar 9 19:27:16 2009

Move of the CLIO Digital Controls test setup

Because of the network interference we've had from the CLIO system for the past 3-4 days, I asked the guys to remove

the test stand from the 40m lab area. It is now in the 40m control room. Since it needed an ethernet connection to get out

for some reason we've let them hook into GC. Also, instead of using a real timing signal slaved to the GPS, Jay suggested

just skipping it and having the Timing Slave talk to itself by looping back the fiber with the timing signal. Osamu will enter

more details, but this is just to give a status update.

1379

Mon Mar 9 19:33:10 2009

seisBLRMS in temp condition

DMF

The seisBLRMS has been running on megatron via an open terminal ssh'd into there from allegra with matlab running. This

is because I couldn't get the compiled matlab functionality to work.

Even so, this running script has been dying lately because of some bogus 'NDS' error. So for today I

have set the NDS server for mDV on megatron to be fb40m:8088 instead of nodus.ligo.caltech.edu. If this seems to fix the problem

I will make this permanent by putting in a case statement to check whether or not the mDV'ing machine is a 40m-martian or not.

Attachment 1: Untitled.png

1383

Wed Mar 11 01:16:40 2009

rogue trianglewave in the MC Servo offset slider

On Monday evening, I ran this command: trianglewave C1:IOO-MC_REFL_OFFSET 0 4 120 600;ezcawrite C1:IOO-MC_REFL_OFFSET 1.76

which I thought (from the syntax help) would move that offset slider with a period of 120 seconds for 600 seconds. In actuality, the last argument is the

run time in number of periods. So the offset slider has been changing by 8 Vpp for most of the last day. Oops. The attached image shows what effect

this had in the MC transmitted power (not negligible). This would also make the locking pretty difficult.

In the second plot you can see the zoom in view for ~30 minutes. During the first part, the MCWFS are on and there are large fluctuations

in the transmitted power as the WFS offset changes. This implies that the large TEM00 carrier offset we induce with the slider couples into

the WFS signals because of imbalances in the quadrant gains - we need someone to balance the RF gains in the WFS quadrants by injecting

an AM laser signal and adjusting the digital gains.

Since there is still a modulation of the MC RFPD DC with the WFS on, we can use this to optimize the REFL OFFSET slider. The third plot

shows a 8 minute second trend of this. Looks like the slider offset of zero would be pretty good.

Attachment 1: Untitled.png

Attachment 2: Untitled.png

Attachment 3: a.png

1384

Wed Mar 11 04:33:57 2009

wild ndsproxy tclshexe

The ndsproxy tcl task on nodus was eating up all the CPU and making the elog slow. I killed it and restarted it.

It looks like it hasn't been making a log file since January. Someone who has some skill in decoding the cryptic csh stdout redirection

syntax should look into this (its in target/ndsproxy/)

1397

Thu Mar 12 19:11:27 2009

Kakeru, Rana, Yoichi

We used the SUS DRIFT MON screen to set the MC biases such that the mirrors were returned to the old OSEM values.
To do this, we set the nominals and tolerances using the appropriate scripts in the mDV/extra/C1/ directory.

We then used the MC_ALIGN screen to set the angle bias sliders.

Then Kakeru and I went to the PSL table to the periscope magic and maximize the MC transmission. Kakeru seems to
have the careful Japanese alignment touch and I am hungry, so I am leaving him to optimize the power. After he
finishes he is going to align the beam to the WFS and turn the MC autolocker back on. The x-arm is locked on a
TEM00 mode so the MC alignment is maybe OK.

1405

Mon Mar 16 01:20:40 2009

MCWFS noise filtered on the SUS-MC

Recently, we noticed that the IOO-WFS system runs at 2048 Hz and sends its signals to the MC SUS
systems which run at 16 kHz. There is no upsampling filter or anti-imaging filter.

So, I've implemented an RLP666 filter as FM1 in the SUS-MCn_ASC(PIT/YAW) filter banks. This is like a 4th order
Cheby low pass with a low Q notch at 2048 Hz to catch the first image.

The attached PNG shows the ASCPIT_OUT signals before and after the filter is implemented. As you can see, the
big aliased spikes are gone. The reason that MC2 is different from MC1/3 is that they have a hardware 28Hz low pass
and MC2 doesn't. So MC2 had a 28 Hz low pass in software already to match the actuation phase between all the MC
mirrors. The apparent power law noise floor from 40-300 Hz in MC2 is not real - just the Hanning window tail.

And yes, it has been this way for several years and none of us noticed. It remains to be seen if this was causing
any noise in the MC coil drivers via slew rate limiting.

Attachment 1: xarm.png

1415

Sun Mar 22 22:39:24 2009

Calibration of the ITM and ETM Actuation

I used the following procedure to calibrate the ITMX actuation signal.

Free Swinging Michelson:
------------------------
- Restore Michelson
- Align Michelson: Minimize AS_DC (PD3_DC_OUT) by tweaking BS alignment.
- Enable Whitening filters for PD1_Q and PD3_DC.
- Run offsets script to get rid of DC and RF offsets.
- Use DTT Triggered Time Series to get time series and measure peak-peak
amplitude of PD1_Q using DTT horizontal cursors. (Templates/Calibration/090322/FreeSwing.xml)

Michelson Sweeps:
-----------------
- Lock Michelson
- Drive ITMX_LSC_EXC using ITMX-MI-Sweep.xml template.
- (Next time remember to turn on a low pass in the MICH loop so that its an open loop measurement below 50 Hz).
- Fit and so some math.

Arm Sweeps for the ETMs:
------------------------
- Lock a single arm
- Sweep ITM & ETM.
- Then sweep MC2 and record drive signal from MC board to the VCO driver.
- Compare and contrast.

Attachment 1: free.png

1416

Sun Mar 22 22:47:58 2009

seisBLRMS compiled but still dying

DMF

Looks like seisBLRMS was restarted ~1 AM Friday morning but only lasted for 5 hours. I just restarted it on megatron;
let's see how it does. I'm not optimistic.

1417

Sun Mar 22 23:16:41 2009

DAQ

tpman restart

Could get testpoints but couldn't start excitations. Restarted tpman on daqawg. Works now.

Still no log file. Mad

1418

Mon Mar 23 15:50:44 2009

filters deleted, lsc rebooted

The LSC time had gone too high. I deleted ~20 filters and rebooted. CPU time came down to 50 usec.

The filters all looked like old trash to me, but its possible they were used.

I didn't delete anything from the DARM, CARM, etc. banks but did from the PD and TM filter banks. You can always go back in time by using the

filter_archive/

1424

Tue Mar 24 23:23:05 2009

We also found that the SPOB RF cable was going through a splitter before going into the SPOB demod board. The other
input of the splitter was open (not terminated). Using 50m Ohm devices without terminated inputs is illegal. It
makes there be standing waves in the cables and makes the RF phase very dependent on cable lengths. We took away
the splitter and ran the cable straight. So expect some change in the SPOB gain and phase plus some shame.

1441

Mon Mar 30 09:07:22 2009

MC1 drift investigation continued

SUS

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

1456

Mon Apr 6 21:50:43 2009

Arm Locking via pushing MC2

Inspired by our 'No Refcav' scheme here, I was inspired to re-explore the idea of locking the
CARM DOF using only feedback to the MC/laser. Last week I got this to work on the single arm and
full IFO at Livingston.
I also estimate the MC noise there.

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

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

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

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

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

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

The third attachment shows the spectra.

Attachment 1: mc2-xarm.pdf

Attachment 2: Untitled.png

Attachment 3: nohands.pdf

1460

Wed Apr 8 18:18:33 2009

LSC code recompiled with a fix for denormalization problem

Below is the link to the anti-denormalization technique that Rolf and Alex implemented at the sites,
that was pointed out by Chris Wipf from MIT:

http://www.musicdsp.org/files/denormal.pdf

1461

Wed Apr 8 18:46:50 2009

DMF, SVN, x2mc, and matlab

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

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

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

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

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

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

Locking

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

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.

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.

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.

1501

Mon Apr 20 18:36:37 2009

Mafalda may need an update

Cameras

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.

1503

Mon Apr 20 20:00:44 2009

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

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