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.
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
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.
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 POX33, the ideal phase for single arm locking does not yield a zero-offset CARM signal. So the offset needs to be manipulated digitally.
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)))
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.