[From Jenne:  When we first opened up the MOPA box, the NPRO's cooling fins were HOT.  This is a clear sign of something badbadbad.  They should be COLD to the touch (cooler than room temp).  After jiggling the needle valve, and hearing the water-rushing sounds, the NPRO radiator fins started getting cooler.  After ~10min or so, they were once again cool to the touch.  Good news.  It was a little worrisome however that just after our needle-valve machinations, the DTEC was going down (good), but the HTEMP started to rise again (bad).  It wasn't until after Alberto's tinkering that the HTEMP actually started to go down, and the power started to go up.  This is probably a lot to do with the fact that these temperature things have a fairly long time constant. 

Also, when we first went out to check on things, there was a lot more condensation on the water tubes/connections than I have seen before.  On the outside of the MOPA box, at the metal connectors where the water pipes are connected to the box, there was actually a little puddle, ~1cm diameter, of water. Steve didn't seem concerned, and we dried it off.  It's probably just more humid than usual today, but it might be something to check up on later.]

As PSL-126MOPA_DTEC went up, the power out put went down yesterday

I plugged the Guralp cables back into the PEM ADCU

       Guralp NS1b ---> #11

       Guralp Vert1b --->#10

       Guralp EW1b --->#12

Earthquake 4.4 Leo Carrillo Beach.

Some of the watchdogs tripped out.

It's crucial that I get a stable transmitted power to have an accurate measurement of the PRC transmissivity and thus of its macroscopic length.

With no DARM offset, sweeping CARM shows an asymmetry between the state where we lock to a DARM spring and the state with a DARM anti-spring.  This is why we have a link between the DARM and CARM optical springs. 

For each DARM detune direction (positive or negative, spring or anti-spring), there is only one CARM direction which can yield a DC-based error signal lock with a CARM offset but no DARM offset, which is what we want.

 The Cryo pump is running reliably since April 22 hence there is no need to close VC1 repeatedly.

The photo switch interlock was put back onto the H2 vapor pressure gauge and it is working.

For POX33, the ideal phase for single arm locking does not yield a zero-offset CARM signal.  So the offset needs to be manipulated digitally. 

To set the demod phase for RF CARM, sensed at REFL2 (REFL 166I), it suffices to set the demod phase for REFL2 to be the optimal phase for controlling SRCL in a no-arm state.

For the purpose of testing out the temperature sensors, I stole the PEM-SEIS_MC1X,Y,Z channels.

I unplugged Guralp NS1b, Guralp Vert1b, Guralp EW1b cables from the PEM ADCU(#10,#11,#12) near 1Y7 and put temp sensors in their place (temporarily).

Congratulation Yoichi and Peter for full rf locking at night. Let's remember that the cryopump was shaking the hole vac envelope and ifo during this full lock.

At about 1am or so Yoichi and I opened VC1.  CC1 had fallen to about 5e-5 torr.

CC1 5e-7 Torr,  VC1 closed at 18:25,  IFO is not pumped, RGA is in bg-mode

In response to Steve's elog entry, and for 40m posterity, I provide the Paschen Curve.

I tested the cryopump interlock today. It is touchy. I do not have full confidence in it.

I'm proposing that VC1 gate valve should be kept closed while nobody is working in the 40m lab.

How to open gate valve:

1, confirm temp of 12K on the gauge at the  bottom of the cryopump

2, if medm screen cryo reads OFF( meaning warm) hit reset will result reading ON (meaning cold 12K )

3, open VC1 gate valve if P1 is not higher than 20 mTorr

VC1 was closed at 18:25,

IFO condition: not pumped,

expected leak plus  out gassing should be less than 5 mTorr/day

The RGA is in bg-mode, annuloses are closed off

-------------------------------------------------------
Magnitude    4.0
Date-Time    * Friday, April 24, 2009 at 03:27:50 UTC
             * Thursday, April 23, 2009 at 08:27:50 PM at epicenter 
Location     33.910°N, 117.767°W
Depth	     0 km (~0 mile) (poorly constrained)
Region	     GREATER LOS ANGELES AREA, CALIFORNIA
-------------------------------------------------------

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.

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.

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

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.

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. 

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

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

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.

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.