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.

[Rob, Jenne]

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).

 Here are the corresponding transfer functions for REFL-DC.

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.

Pete, Yoichi

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.