We must remember that we are using the Rev.B SOS Coil Drivers and not the Rev. A. 

The main change from A->B was the addition of the extra path for the bias inputs. These inputs were previously handled by the slow EPICS system and not a part of the front end. So we used to have a separate bias screen for these than the bias which is in the front end. The slow bias is what was used for the alignment to avoid overloading the range of the main coil driver path.

I have reviewed the suspension model of C1SUS and refined it.

It is comaptible to the current one but has minor additions.

The Netgear Network Switch in the top shelf of Nodus' rack has a broken fan. It is the one interfaced to the Martian network.

The fan must have broken and it is has now started to produce a loud noise. It's like a truck was parked in the room with the engine running.

Also the other network switch, just below the Netgear, has one of its two fans broken. It is the one interfaced with the General Computer Side.

I tried to knock them to make the noise stop, but nothing happened.

We should consider trying to fix them. Although that would mean disconnecting all the computers.

To bypass the polarizer issue, I just used cubes. One I took from the FSS-Refcav path and the other from the power control part of the old MOPA, just downstream of the MOPA's periscope.

We'll swab these out with the thin-film polarizers after we get the mounts made.

With the cubes in, I also installed the Faraday + its 1/2-wave plate. The transmission looks good and we're getting into the PMC and its flashing a TEM00 mode sometimes. I set up a signal generator to drive the SLOW actuator by 1 FSR at 0.1 Hz.

I have set up a PMC transmission camera and transPD so that its easy to align. The flashing mode already allows us to align most of the rest of the table (except FSS).

Our next step should be to run the cables for locking the PMC:

1. RF cables to the PMC_REFL
2. Dsub for the PMC RFPD
3. HV cable between the PMC servo board and the PMC PZT (why is this not RED? we have to make sure to abide by the cabling color code).
4. RF cable from 35.5 MHz Frequency Reference card to the PMC EOM via the RF summing box on the table.

On Tuesday, we need to make sure that all of our mounts' drawings are in the cue for the shop. I'll put the list of mounts onto the PSL upgrade wiki page.

We also have to come up with a plan for wiring some of the 2W NPRO's channels into the cross-connect so that we can have some laser channels recorded by EPICS.

**** Deleted
apps/emacs
apps/linux64/firefoxold
apps/linux64/comsol      (old v. 3.5)

* running up2date on rossa

* rossa needs to be able move windows between monitors: Xinerama?

* there are permissions problems: controls on rossa can't
make and delete directories made by 'controls' elsewhere.
Some sort of user# or group issue?

Rana and I were poking around on the PSL table today, getting a few more items raised to the correct height.

I checked the polarization state of the new NPRO by using a HWP to minimize the transmission through a PBS cube, and then compared the power transmitted through the cube vs. reflected.  When the NPRO current was 0.772 \pm 0.001 (as read on the LCD), the transmission through the cube was 1.44mW, while the reflected was 10.53mW.  The reading of the Ophir power meter with no incident light was 0.03mW.  This factor of 10 means that the NPRO beam is ~10% circularly polarized and ~90% linearly polarized.  In order to improve the beam, we need a Quarter Wave Plate, which it turns out we don't have.  We need a QWP!

After that, using the linearly polarized part of my beam (maximizing the transmission through the PBS by rotating my HWP by 45deg), I tried to tune the angle of the polarizers that Rana pulled out of the MOPA.  I think I'm confused / too tired, because I can only get the polarizer to reflect a bunch of light, and I can't get it to pass any significant amount of light through, no matter where in its actuation range I put it (It's on a rotation stage with a few degrees of range).  It should just be a Brewster's Angle thing, and since I already have P-pol coming through the BS cube, this shouldn't be so hard.....

In any case, it may not be useful to do the final fine tuning of these polarizers until they are in their final places.  The hacky stack of mounts that I have has some slop in the position / alignment of the base of the polarizer, so no matter what we'll have to redo the tuning after the mounts are finalized.

Yeah, this looks nice.

And I also like to have something I have attached. This is "HOZAN P-90", but we should investigate American ones
so that we can cut the wires classified by AWG.

I found this very interesting German maker of cool cable cutting tools. It's called Jokari.

We should keep it as a reference for the future if we want to buy something like that, ie RF coax cable cutting knives.

http://www.jokari.de/en.htm

NPRO

Koji and I inspected and photographed the laser after opening up its case. I then drilled the clearance holes in the 4 corners and tapped holes for 1/4-20. I was careful to tap with the laser sideways, to avoid shavings getting into the laser and suctioned out as much of the pieces as I could. The laser is now mounted on some bad 1/4-20 based NewFocus style pedestals. The riser block can now be made with 1/4-20 through holes and the laser will sit on its for corner feet. We'll make the base aluminum to avoid differential CTE based stress in the laser base.

We checked the level of the laser. With the new mounting the beam is level to within ~1 mrad and has a 4" beam height.

Faraday

I've mounted the Faraday Rotator from the old MOPA. It has 8-32 mounting holes (who's shafts are curiously not parallel). We need an aluminum block of the proper height (2 3/4" ??) to make a permanent solution.

I've also mounted the thin-film polarizer. This works well, but it also needs a block machined to get the mounting to be less Mickey Mouse.

Pockel Cell for phase correction and 35.5 MHz PMC modulation

The EOM is mounted as before on the angle bracket to align it for P-pol light. The beam now goes cleanly through there. No further mounting hardware required.

Lenses

The 2 lenses in the 'mode matching telescope' between the laser and the PMC are in place, but not placed with any accuracy.

By sheer luck, I saw the PMC flashing in the TEM27 mode without any alignment from me. Next step is to get the lens positions tuned and then do the beam scan on the beam going towards the PMC to verify the approximate mode matching. This is all crude, but I just want to get the beam going into the vacuum as fast as possible.

Why are we running CentOS 4.8 instead of 5.5 ?    What runs at LLO?     What runs in Downs?

Simple steps (but don't try these on a working computer without getting some experience on a spare one, you may find it difficult to restore the system if something goes wrong):

1. download the appropriate driver from NVIDIA website for this computer
   
   • we did: NVIDIA GeForce 310 64bit Linux, version: 256.53, release date 2010.08.31
2. keep/move the driver in /root (use "sudo" or "su")
3. reboot the computer in "single user" mode
   • in the GRUB screen edit the boot command by pressing the appropriate key listed in the screen
   • in the boot command-line put " single" in the end (no other change is normally needed), don't save
   • press ENTER and the system will reboot to a root shell (# prompt)
4. cd /root
5. run the NVIDIA driver script
6. exit the shell (ctrl-d), let the system reboot
   • it should flash (mostly green) "nvidia" screen before starting X
   • in case of problems run system-config-display and revert to vesa driver
7. login as "root" and run "nvidia-settings" from command line or GUI menu to add/configure display

 Joe and Kiwamu:

We found one bug in the RCG code, where the second input for the CDO32 part (32 binary output) was simply a repeat of the first input, and totally ignored the second input.  This was fixed in the /advLigoRTS/src/epics/util/lib/CDO32.pm file by changing 

$calcExp .= $::fromExp[0];

to

$calcExp .= $::fromExp[1];

This fix has been added to the svn.  Unfortunately, while we have a single working binary output module, the 2nd and later modules do not seem to be responding at all.  We've done the usual swaping parts of the path in both software and hardware and can't find any bad pieces in our model files or the actual hardware.   That leaves me wondering about the c code, specifically if the CDO32Output[1], CDO32Output[2], and so forth array entries in the code are being handled properly.  I'll try to get some thoughts on it from Alex tomorrow.

Rolf has recently written a document describing how one should fill out an IO chassis and how the numbering works out.  This can be found in the DCC at Rolf's PCIe numbering guide (T1000523).

Basically it works out that slot 1 corresponds to PCIe number 1, but slot 2 corresponds to PCIe number 6.  And so forth.  The following table gives a quick summary.

I hooked up interlock to the Innolight 2W 1064 nm in the enclosure. The manual shutter  is closed on this unit.

SAFETY GLASSES REQUIRED !

The crane I -beam now leveled at all degrees of rotation.  The lower hinge was moved southward  about 1/4 of an inch.  Performance was tested at 2000 lbs

Atm1, work in progress

Atm2, load test at 1 Ton

Atm3, service report

This totally creeped me out when I found it wandering around on the floor not so far from my desk:

[Rana, Jenne]

More PSL progress. 

The new laser was raised to a 4 inch beam height using basically the most randomly thrown together method possible.  (It'll work just fine for aligning things, but we seriously need to get a nice block made.)  The PMC and the nice Osamu-mirror mount to go into the PMC also have temporary risers, so we'll need to replace them with the real deal as soon as we get things back from the shop.

So far we've got (1) the lens after the laser, (2) a Half Wave Plate (no quarter wave plate yet), (3) steering mirror that will go after the EOM, (4) 2 steering mirrors to get into the PMC, in addition to all of the stuff that we did the other day.  With all of this stuff we've got the beam hitting the 1st PMC mirror. We still don't have the EOM and AOM in the beam path however.

To get the rough alignment that we did, we turned on the new 2W NPRO, operating at the minimum power we could see on a card.  We turned it off after use, so it is still off.  Steve, we left the cable for the interlock sitting on the PSL table on the NW corner....can you please hook it up tomorrow?  Also, after the interlock is installed we should go back to regular running laser hazard mode. 

With the setup now working, we should now test the power filtering for the crystal and amplifier.

I removed the 50 Ohm in-line terminator when I did the measurement with the SR785. The for some reason I was getting more noise, so I removed it.

Now I put it back in and I did the measurement with the DAQ. I also moved the SR560 that amplifies the signal for the DAQ, Tee'ing it with the input of the in-loop SR560.

Now the setup looks like this:

And the phase noise that I measure is this:

Comparing it with the phase noise measured with the previous setup (see entry 3506), you can see that the noise effectively is reduced by about a factor of 2 above 10 Hz.

The differences between this setup and the one used previously is the lack of the 50 Ohm terminator in the mixer output and

that the SR560 readout with the G=100 should come before the first SR560 via T, so as not to be spoiled by the high noise of the G=1 SR560.

Alex, Joe:

We copied the latest x02 to c1x02 and modified to our the config block in it.

We removed gds_node_id.  We just have one number now, the dcuid, which is unique for each controller, simulated plant and IOP.  Set site to C1 and host to c1sus.

Alex made the latest awgtpman backwards compatible, and checked that into svn.

We installed the latest framecpp onto c1sus from www.ldas-sc.ligo.caltech.edu/packages/ using wget.

wget www.ldas-sc.ligo.caltech.edu/packages/framecpp-1.18 and then used make.

This let us compile diagd on c1sus, using the command make stand in the /advLigoRTS/build area.

We copied gds from the seiteststand over at handford and are trying to build that on megatron.  However, there's a bunch of packages we need for it to install properly.  Alex said he'd work on that later, possibly trying to make some portable binaries.

Checked out the latest dataviewer into /opt/rtcds/caltech/c1/core/daq, however its not quite working yet either.  This is another thing Alex said he'll work on later.

We are also going to test Alex and Rolf's kernel patch over on c1iscex on Centos base kernel (apparently they've been using Gentoo up at hanford for the test stands...) and see how that works.

I measured the phase noise of the LO output of the FSS box from the DAQ. I'm attaching the results.

As we expected, the measurement is limited by the internal phase noise of the Marconi.

The measurement was done as shown in this diagram.

Crane balancing at the south end is continuing today.

 I just turned on the other Sorensen's too in 1Y1.

1. I can not see whether the attaching surface is flat or not.
It should have ~1mm step to avoid "the legs" of the laser at the four corners.
Otherwise we will have ~0.5mm space between the block and the laser
and will squish this gap by the screws => cause the deformation of the block and the laser.

2. The countersinks for the M4 screws can be much deeper so that we can use the existing M4 screws.
In any case, the long M4 screws are not rigid and also not common.

I am feeling that it is ok to carefully make new holes and threads as far as the holes do not penetrate the plate.
The thickness of the plate can be measured by the four holes at the corners.

Today I put the FSS frequency box back into the 1Y1 rack.

To power it on, I turned on the 24V and 15V Sorensen switches in the same rack.

The PMC crystal board in the same rack should not be affected (it runs with 10V), but, to make sure it was not powered, I disconnected it from its crate. Since the board was disconnected from the EOM for the PSL table's upgrade, I wanted to avoid having the RF output floating.

We just have to remember to plug it back in, when we need it again.

1. Steve is handling the mount height increase for the PMC and RC steering mirrors, as well as a mount (non-steerable) for the ISS' AOM.
2. Rana is working on the laser mount.
3. Jenne is drawing and getting the PMC mount made.
4. We got the lenses from CVI for the mode matching, but not the metric screws for the laser mounting. I am tempted to tap holes in the laser base.

A few weeks ago, on Jul 24, Rana and I measured the phase noise of the FSS frequency box (aka the 'Kalmus Box'). See elog entry 3286.

That time, for some reason, we measured a phase noise higher than we expected; higher than that of the Marconi.

I repeated the measurement today using the SR785 spectrum analyzer. Here is the result:

(The measurement of July 24 on the plot was not corrected for the loop gain. The UGF was at about 30 Hz)

To make sure that my measurement procedure was correct, I also measured the combined phase noise of two Marconis. I then confirmed the consistency of that with what already measured by other people in the past (i.e. Rana elog entry 823 in the ATF elog).

This time the noise seemed reasonable; closer to the Marconi's phase noise, as we would expect. I don't know why it was so bad on July 24.

The shoulder in the Marconi-to-Marconi measurement between 80Hz and 800Hz is probably due to the phase noise of the other Marconi, the one used as LO.

I'm going to repeat the measurement connecting the setup to the DAQ, and locking the Marconi to the Rubidium standard.

Ultimately, the goal is to measure the phase noise of the new Sideband Frequency Generation Box of the 40m Upgrade.

Apparently updating to the latest revision of the RCG has some issues with diaggui and awgtpman.  Alex had to do some recompiling up at Hanford which apparently took him some time.  He'll be coming by tomorrow to try to bring those codes to the front end machines.

As a temporary fix, until Alex gets here tomorrow, we're reverting to the 2005 revision in the svn of the cds code.  I'm placing it in the location it is supposed to go in the new advLIGO scheme, which is /opt/rtcds/caltech/c1/core/, which is where Keith had it at LLO.  Once we get the new codes working, we will do an svn update on that location and migrate our work to that install location, at which point I'll remove the old /cvs/cds/caltech/cds/advLigoRTS/ location.

And I raised it back to 73F. The thermometers on the wall show 74-75F as the actual room temp. The dial on the temperature controller is not calibrated.

Our toilets were replaced by a green Gerber 1.6 gpf ( 6 lpf ) last week.

I lowered room 101 thermostat setting from 74F to 72F

 { Joe and Kiwamu },

 Now we  are able to compile the model file with more than 4 binary input/outputs (BIOs).

 As I wrote in a past entry (see here), the number of the BIOs was limited to 4, which is not enough for us.

  We modified a header file called "cdsHardware.h"  in order to allow model files having more than four BIOs.

The header file lives under /cvs/cds/caltech/advLigoRTS/src/include/drv/.

There was a sentence defining the maximum number in the file:

 #define MAX_DIO_MODULES         4.

We changed this to

 #define MAX_DIO_MODULES         8.

The PSL -leg concrete was sealed with a single coat of SCOFIELD Cureseal-S to minimize shedding of particles.

The optical table was covered  and optics were removed from the shelf. Accelerometers were turned off.

I plugged the new CDS to the vertex suspensions. 

Now PRM, SRM, ITMs, MCs and BS are under the control of the new CDS. 

From now on we will never go back to the old system.

Though,  the watchdogs are still running on the old system.

So if you need to turn on/off the watchdogs, you can simply enable/disable them from the usual medm screens.

To test out this website - emachineshop.com, Jenne and I are designing some of the mounts for the new beam height.

It took me a few hours to figure out how to do it, but the software is easy enough for simple stuff. This is a brass mount with M4 clearance holes which are countersunk and a lip so that it can be dogged down to the table.

{ Joe and Kiwamu }

Today we made some efforts to get the binary outputs (BOs) working.

They still are not working but the situation is getting better.

    So far the BO cards were not recognized by any realtime codes when we ran the codes on the new front end machine C1SUS.

We put some printk commands in an initialization code like Yoichi did (see this entry) to confirm if the initialization of the BOs properly happens or not.

Then we found that we had to put the BO modules also in an IOP model file which controls all the ADCs and the DACs.

We put the BO modules in the IOP file and then BOs started being recognized by the IOP, however they still are not fully recognized by the realtime control process.

We continue this work...

[Some notes]

[front end code]

First of all we looked at the front end c-code c1sus.c living under /cvs/cds/calech/cds/advLigoRTS/src/fe/c1sus/.

It was okay because there was a proper BO statement like

CDS_CARDS cards_used[] = { {CON_32DO,0}, {CON_32DO,2}};

[initialization code]

 There is an initialization code called map.c living under /cvs/cds/calech/cds/advLigoRTS/src/fe.

This code is complied when we do the make commands as described on the wiki.

Eventually the initialization code is executed only when the IOP starts up. This happens when we type startc1x02 at /cvs/cds/rtcs/caltech/c1/script/.

[printk statments]

   We made a backup file named map_20100830.c.back for map.c. Then we added to map.c some pintk statements in a while loop which looks for available BOs.   

After running the make commands for the IOP file and startc1x02, we basically can check the results of those printk statements by using dmesg.

We found that map.c was running correctly because  map.c went in the while loop 4 times which is exactly the same number as the BOs we put in the model file.

However the code failed to install the BOs each time.

[BO modules in IOP file]

  Joe pointed out the failure in map.c was caused by lack of the BO modules in the IOP file c1x02.mdl.

Indeed putting the BO modules in the IOP fixed the problem. 

Another thing we found at this time is that there is a maximum number of BOs we can put in a model file.

The maximum number is 4, which is not enough for us because we need to put 5 of them including a 16bit BIO and four 32bit BOs.

Now Joe is asking to Alex about this issue.

Anyway now the IOP can recognize the BO cards, this fact can be found if you look at the log file /cvs/cds/rtcds/caltech/c1/target/c1x02/logs/log.txt.

The log file saids "3 Contec 32ch PCIe DO cards found", which is a good sign. 

[BO modules in realtime code] 

Although the IOP started seeing the BO cards, the realtime code c1sus still didn't fully recognize the BO cards.

If we look at the log file log.txt at /cvs/cds/rtcds/caltech/c1/target/c1sus/logs/, there is an evidence that the code found some cards.

The log file saids  

   Model 6 = 10

   Model 7 = 4

   Model 8 = 4

   Model 9 = 4

   Model 10 = 0.

 It looks like these corresponds to the BO cards.

So the code found some cards, but doesn't know what they are.

We need few more debugging for the BOs... 

As it turns out, data seems to fall off the 16Tb drives after ~20 days.  Which makes it a good thing that I saved all of my raw data from my good Mode Cleaner / seismic weekend for offline Wiener Filtering in the following secret place:

/cvs/cds/caltech/users/jenne/AdaptiveFiltering/mat/MCseis_raw_data_7Aug2010

It's not linked to the svn, since it's a boatload of data.

The lifting and resetting of the BLUE PSL enclosure has made it unstable somehow. When I push on it a little it rocks back and forth a lot.

Steve, please look into what's happening and stiffen it if you can. Its too unstable right now.

Jenne and Koji

Last week Jenne has put the accelerometers on and under the PSL table immediately after the plastic sheets were removed.

So I took the same measurement as I did on 9th Aug.

Here is the comparison of the vibrational performance of the table before and after the modification.

Basically the table is now stiffer and more damped than it was before.
We don't find any eminent structure below (at least) 70Hz.
This result is obtained despite elevating of the table.

1) Attachment 1

For the horizontal comparison (top),  it is clearly seen that the large resonant peak at 20Hz was eliminated.
At least the new resonances went up to 70-90Hz region. Y is basically equivalent to X.

For the vertical comparison (bottom), it is clearly seen that the resonant peaks at around 50 & 70Hz were eliminated. 
At least no new resonance is seen.

2) Attachment 2

All-in-one plot for the measurement --- spectra, coherences, transfer functions --- after the upgrade. I put the same plot for the one before the upgrade.

 {Rana and Kiwamu}

Yesterday we disabled the sendmail daemon and the isdn daemon on allegra because we don't need these daemons always running.

-   How to disable/enable daemons:

sudo ntsysv

We changed the name of the new control room computer from kallo to rossa (since its red).

I also tried to install the nVidia graphics driver, but failed. I downloaded the one for the GeForce 310

for x86_64 from the nVidia website, but it failed to work. I installed it, but then X windows wouldn't start.

I've left it running a basic VESA driver.

Kiwamu updated the host tables to reflect the name change. We found that both rossa and allegra were

set up to look at the old 131.* DNS computers and so they were not resolving correctly. We set them up for new way.

I've taken the FSS frequency generation box out of the 1Y1 rack. It's sitting on one of the electronics benches. I'm measuring its phase noise.

In fact, many of the mounts need to be adapted to 4": the beefy steering mirrors going into the PMC, the PMC RFPD, the ISS AOM, the Faraday between the NPRO and the AOM, the NPRO itself, the ISS PDs.

Also for the FSS: the 21.5 MHz EOM, the PBS, the AOM, the refcav periscope, and the RFPD.

Its obvious, in retrospect, that we would have to do this, but it somehow didn't occur to me until actually trying to put things on the table...

The NPRO itself is already tapped with 3 (metric) M3 holes. It also has 4 (un-tapped) holes at its 4 corners which look like they are for feet. Anyone have a mount design for the Innolight NPRO already?

We also started labeling the table with the new coordinate system. In this system, the NE corner is the origin. The screw hole which is most NE is 1,1. The numbering increases in the south (+X) direction and goes negative in the west (-Y) direction.

[Rana, Jenne]

Like a new phoenix, the 40m PSL is in the process of being reborn...

We cleared many old optics and components (including Alberto's favorite periscope) off of the north end of the PSL table.  Some optics are stored on the SP table, others on the shelf inside the PSL enclosure.

The new Innolight 2W NPRO is on the table, the PMC has been moved, and the main path of the laser has been sketched out using steering mirrors. Since we still don't have a beam, we're roughly placing all of our optics, and we'll finalize the alignment after turning on the laser.

Using a leveled HeNe, I checked the height of optics we should use to match the height of optics in the chambers by shining the light at the first steering mirror in the chamber, and ensuring that the beam hit the center of that optic .  Since the new PSL table height is identical to the AP table, it's not a surprise that from now on we will be using a 4" beam height on the PSL table, rather than the old PSL 3" beam height.

On the to-do list is to make a plate with 4 through holes to raise the PMC up by 1 inch, and to make an adapter plate (or come up with another plan) for mounting the AOM that goes directly after the NPRO/Faraday, among many other things.  We also still need to make some space for the RefCav to be put in its new place on the table, and then install it with Steve's help.   

For the future SLOW controls our current plan is to keep using the VME based stuff and associated processors (Baja, Motorola, etc.). This is not

a sustainable plan since these are obsolete and eventually will die. One option is to use these boxes from Diamond Systems:

http://www.diamondsystems.com/products/octavio

 { Joe, Kiwamu }

Yes !

We now are damping all of the vertex suspensions including PRM, BS, ITMs and MCs by the new CDS. 

( Note that we are not damping SRM because we don't have it in the chamber. )

 (things to be done)

- Make the binary outputs work.

- Make DTT work

For a futher damping test, I again turned off the vertex optics watchdogs temporarily, including BS, ITMs, SRM, PRM, MCs.