As noted previously, we were having problems with getting multiple 32 channel binary output cards working.  Alex came by and we eventually tracked the problem down to an incorrect counter in the c code.  This has been fixed and checked into the CDS svn repository.  I tested the actual hardware and we are in fact able to turn our test LEDs on with multiple binary output boards.

Alex and I also looked at the non-functional IO chassis (the one which wouldn't sync with the 1PPS signal and wasn't turning on when the computer turned on.  We discovered one corner of the trenton board wasn't screwed down and was in fact slightly warped.  I screwed it down properly, straightening the board out in the process.  After this, the IO chassis worked with a host interface board to the computer and started properly.  We were able to see the boards attached as well with lspci.  So that chassis looks to be in working condition now.

Onwards to the RFM test.

elog crashed on an upload. restarted and it worked fine with the same file.

We need a distribution unit in the LSC rack to: 1) collect the demod signals coming from the Frequency Generation Box 2) adjust the power level 3) generate 2nd harmonics (for POP) 4) distribute the demod signals to the single demodulation boards.

The base line plan is the following:

The box can be build up gradually, but the priority goes to these parts:

I need help for this work. I know exactly how to do it, I just don't have the time to do it all by myself.

 Besides the Distribution Box, the demodulation part of the upgrade would still require two steps:

1) upgrade the Band Pass Filters of the demodulation boards (I have all the parts)

2) cabling from the distribution box to the demod board (one-afternoon kind of job)

The controls group is user id 500 by default on most new machines. Unfortunately, the user ID used across the already existing machines is 1001. One method of doing this switch is in this elog.  You can also do the change of the controls ID by becoming root and using the graphical command system-config-users.  This will  let you change the user ID and group ID for controls to 1001.  This graphical interface also lets you change the login shell.

Unfortunately, I had some minor difficulty and I ended up removing the old controls and creating a new controls account with the correct values and using tcsh.  The .cshrc file has been recreated to source cshrc.40m.  The controls account now has correct permissions, although some of the preferences such as background will need to be reset.

Here are the results of my phase noise measurements on the 7 outputs of the Frequency Generation Box. (BIN=95L applied by DTT). See attached pdf for a higher definition picture.

The plot shows that the phase noise of the 11 MHz outputs (Source, EOM modulation signal, Demodulation signal) is as low as that of the Marconi. The Marconi is limiting my measurement's resolution.

The mode cleaner signal's oscillator (29.5 MHz output, blue trace) is higher than the 11MHz above 1KHz.

The 55MHz signals have all the same phase noise (traces overlapped), and that is higher than the 11 MHz ones from about 100Hz up. i don't know what's going on.

I need to use the spare 11MHz Wenzel crsytal to have a better reference source for the measurement.

Last week I noticed that the high power amplifiers in the Frequency Generation Box became hot after 2 hours of continuous operation with the lid of the box closed. When I measured their temperature it was 57C, and it was still slowly increasing (~< 1K/hr).
According to the data sheet, their maximum recommended temperature is 65C. Above that their performances are not guaranteed anymore.

These amplifiers aren't properly dissipating the heat they produce since they sit on a plastic surface (Teflon), and also because their wing heat dissipator can't do much when the box is closed. I had to come up with some way to take out their heat.
The solution that I used for the voltage regulators (installing them on the back panel, guaranteeing thermal conduction but electrical isolation at the same time) wouldn't be applicable to the amplifiers.

I discussed the problem with Steve and Koji and we thought of building a heat sink that would put the amplifier in direct contact with the metal walls of the box.
After that, on Friday I've got Mike of the machine shop next door to make me this kind of L-shaped copper heat sink:



On Saturday, I completely removed the wing heat dissipator, and I only installed the copper heat sink on top of the amplifier. I used thermal paste at the interface.

I turned on the power, left the lid open and monitored the temperature again. After 2 hours the temperature of the amplifier had stabilized at 47C.

Today I added the wing dissipator too, and monitored again the temperature with the lid open. then, after a few hours, I closed the the box.
I tracked the temperature of the amplifier using the temperature sensors that I installed in the box and which I have attached to the heat sink.
I connected the box temperature output to C1:IOO-MC_DRUM1. With the calibration of the channel (32250 Counts/Volt), and Caryn's calibration of the temperature sensor (~110F/Volt - see LIGO DOC # T0900287-00-R), the trend that I measured was this:



Conclusion
The heat sink is avoiding the amplifier to overheat. The temperature is now compatible with that of the other component in the box (i.e., crystal oscilaltors, frequency multiplier).
Even with the lid closed the temperature is not too high.

Two things remain untested yet:
1) effect of adding a MICA interface sheet between the heat sink and the wall of the chassis. (necessary for gorund isolation)
2) effect of having all 3 amplifiers on at the same time

I am considering opening air circulation "gills" on the side and bottom of the chassis.

Also we might leave the box open and who ever wants can re- engineer the heat sink.

For posterity.
- Ideally we would like that the heat sink had the largest section area. A brick of metal on top the amplifier would be more effective. Although it would have added several pounds to the weight of the box.
- We need these amplifiers in order to have the capability to change the modulation depth up to 0.2, at least. The Mini-Circuit ZHL-2X-S are the only one available off-the-shelf, with a sufficiently low noise figure, and sufficiently high output power.

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.