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.

 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.

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.

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.

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.

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. 

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.

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.

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.

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.

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.

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. 

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.  

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.