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.
I noticed that the ISS Mean Value and CS Saturation were both RED and unhappy. (The alarms were going off, and they were both red on the MEDM screen). None of the MEDM settings seemed off kilter, so we went out to take a look at the PSL table.
Rob checked that light is indeed going to both of the ISS photodiodes (Morag and Siobhan). Next we checked that all the cables were good, and that the power to the ISS box was plugged in. In this process, Rob wiggled all the cables to check that they were plugged in. Just after doing this, the Mean Value and CS Sat were happy again. Rob thinks the current shunt connection might be bad, but we don't really know which one it was since all of the cables were jiggled between our checking the screens.
Right now, everything is happy again, but as with all bad-cabling-problems, we'll probably see this one again.
I don't know why in particular the connection decided to spaz out this afternoon...I don't think anyone opened the PSL table before Rob and I went to investigate. I was working on the PMC servo (checking the LO levels...to be posted in a couple minutes), but didn't have anything to do with the ISS. After I was done, I put everything back, and locked the PMC and the MC, and everything was good, until some time later when the ISS started flipping out.
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
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).
I've plotted some transfer functions showing the response at POB DC to laser frequency (phase) noise. There are transfer functions for multiple CARM offsets. Basically, the transfer function looks like the DARM transfer function when the CARM is at zero offset, and is super-wonky elsewhere. POB-DC is not a good CARM signal for intermediate stages of lock acquisition in a dual-recycled interferometer. We should look into switching back to REFL-DC.
Here are the corresponding transfer functions for REFL-DC.
Last night, we put the IFO in FP Michelson configuration. We took transfer functions of CARM and DARM, first using CM excitations directly on the ETMs, and then using modulations of the laser frequency via MC excitation. We found that there was basically no coupling into DARM using the MC excitation, but that there was coherence in DARM using the ETM excitation. Therefore, I tuned the ETM common mode in the output matrix. I did this by taking transfer functions of PD1_Q with PD2_I (see attached plot). I changed the drdown_bang script to set C1:LSC-BTMTRX_14 0.98 and C1:LSC-BTMTRX_24 1.02.
Cold cathode gauge CC4 is reading normal.
CC1 is glitching, it is probably dirty.
CC2 is fluctuating too much and it is cutting out for 6-7 minutes. It must be insulated by deposits and there is no emission current.
I think the same goes for P1
They will have to be replaced at the next vent
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.
Vacuum normal valve condition was changed to accommodate SRS-RGA calibration.
VM1 was closed to isolate the RGA from the IFO.
Old Guralp is hooked back up, the new one is sitting next to it, disconnected for now.
After many, many "it'll be there in 2 weeks" from the Guralp people, our seismometer is finally back!
I have it plugged into the Guralp breakout box's Channel 1xyz (so I have unplugged the other Guralp). Both of the Guralp's are currently sitting under the MC1/MC3 chamber.
Before we can have both Guralps up and running, I need to stuff the next 3 channels of the breakout box (back in the fall, I only had Caryn do 1x, 1y, 1z, and now I need 2x, 2y and 2z done with the fancy low-noise resistors), so all the gains match between the 2 sets of channels.
I'm leaving the new Guralp plugged in so we can see how it behaves for the next couple days, until I take out the breakout box for stuffing.
Rga scan of day 231 since pumpdown pd66-m-d231
m stands for maglev pumping speed, vacuum normal condition of valves,
cc4 cold cathode gauge at the rga location,
cc1 is real ifo pressure from the 24" tube at the pumpspool,
PEM-count temp: vac envelope temp at the top of IOO chamber
Thanks to Joe B who made the SRS RGA working with linux
Last data file logged at 2008 Oct 24 with old Dycor unit
First data file logged at 2009 Feb 10 with SRS
The Caltech gasoline storage tank is being upgraded.
They are jack hammering and digging with bulldozer 50 yards south of ETMY
Eric Gustafson is handling the old HP4291A rehabilitation. Tarac picked both units up today.
March of 2008 Tucker Electronics failed to fix it's intermittent ~25MHz 0.5V oscillation at the swept sine output
See 40m-elog id:398 on 3-24-2008 by Rob Ward
ETMY sus damping was found to be tripped.
It was retored.
All fluorecent light were turned off. Please try to conserve some energy.
We ran cable from the suspension rack to the IOO rack to record the signals with DAQ channels.
The test channels:
UL coil C1:IOO-MC_DRUM1 (Caryn was using, we will replace when we are done)
UL input C1:IOO-MC_TMP1 (Caryn was using, we will replace when we are done)
LR coil C1:PEM-OSA_SPTEMP
LR input C1:PEM-OSA_APTEMP
We will leave these overnight; we intend to remove them tomorrow or Monday.
We closed the PSL shutter and killed the MC autolocker.
netgpibdata.py is giving me weird data. When I plot the data it has saved from the 4395A, it's some wierd other universe's version of my transfer function. I don't really know what's up.
Yoichi, in all his infinite wisdom, reminded me that the netgpibdata script saves the data as the REAL and IMAGINARY parts, not the Mag and Phase. Brilliant. Using that nugget of information, here are the TFs that I measured earlier:
The last attachment is the .dat and .par files which contain the data and measurement parameters for the 3 TFs in the plots.
When all things fail (netgpibdata.py is giving me weird data. When I plot the data it has saved from the 4395A, it's some wierd other universe's version of my transfer function. I don't really know what's up. I'm pretty sure I'm getting the 'correct' data, since each TF looks vaguely like it should, but with some crazy humps. I'll talk to Yoichi in the morning about it maybe.) (also, we're low on emergeny floppy discs), you can always take a picture of the Agilent 4395's screen, as shown below.
* Mode cleaner and PMC are both relocked after my shenanigans, and I'll try again in the morning (I assume locking is going on tonight) to get real TF's with real data, as opposed to the photo method.
Note to self: post the data of the TFs in the elog along with the plots, for posterity.
These TFs are of the Mode Cleaner servo board, exciting IN1 (or the 3.7MHz notch pomona box which is connected to IN1), and measuring at the SERVO out of the board.
One with the box, one without the box, and one of just the box for good measure.
C1:IOO-MC_BOOST1 0 (You can turn it on if you want, but turn it off for locking)
C1:IOO-MC_POL 1 (Minus)
C1:IOO-MC_LIMITER 1 (Disable)
C1:PSL-FSS_SW1 0 (Test1 ON)
C1:PSL-FSS_FASTGAIN 14 (Do not increase it, at least while locking. Otherwise the phase lag from the PZT loop gets significant and the MC loop will be conditionally stable).
SUS-MC1_SENSOR_SIDE and SUS-MC2_SENSOR_UL are glitching
Yesterday's 4.8mag earthquake at Salton Sea is shown on Channel 1