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.
% Paschen Curve plotting
% From http://home.earthlink.net/~jimlux/hv/paschen.htm
% Breakdown voltage:
% Vbreakdown = B * p * d / (C + ln( p * d))
% Breakdown field strength:
% Ebreakdown = p * ( B / ( C + ln ( p * d)))
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
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 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?
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:
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
sudo make modules_install
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.
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.
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.
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
I edited c1psl.db to include the following:
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:
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:
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.
Vacuum normal valve condition was changed to accommodate SRS-RGA calibration.
VM1 was closed to isolate the RGA from 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.
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.
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.
% 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
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:
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.
tmp = netSock.recv(1024)
## 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
# 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
from optparse import OptionParser
from socket import *