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.
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 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 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 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.
% 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
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.
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.
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.
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.
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
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.
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?
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.
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.
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.
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.
As PSL-126MOPA_DTEC went up, the power out put went down yesterday
[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.]
For several of the channels on the PEM ADCU, zeros are occuring at the same time. Does anyone know why that might happen or how to fix it?
The NPRO cooling water was clogged at the needle valve. The heat sink temp was around ~37C
The flow-regulator needle valve position is locked with a nut and it is frozen. It is not adjustable. However Jeenne's tapping and pushing down on the plastic hardware cleared the way for the water flow.
We have to remember to replace this needle valve when the new NPRO will be swapped in. I checked on the heat sink temp this morning. It is ~18C
There is condensation on the south end of the NPRO body, I wish that the DTEC value would just a little higher like 0.5V
The wavelenght of the diode is temp dependent: 0.3 nm/C. The fine tuning of this diode is done by thermo-electric cooler ( TEC )
To keep the diode precisely tuned to the absorption of the laser gain material the diode temp is held constant using electronic feedback control.
This value is zero now.