[Joe, Kiwamu] 

Woooo Yeaaaah ! 

With the new CDS we succeeded in damping of PRM and BS !!

 { 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

 Enclosure is at the east end. It has it's bottom o-ring in place. It will be ready for optics tomorrow around 5pm

I have to shim out the enclosure, finish leveling the table and cut surgical tubing O-ring for the top.

We changed the HIGH/LOW values of the PMC_TRANS.

The edited file was updated on the svn.

Since the PMC_TRANSPD was replaced behind the pzt mirror (see the entry), its nominal value were reduced to something like ~1V from the previous value of ~2V.

In the medm screen C1PSL_PMC.adl the PMC_TRAN always indicated red because the value were low compared with the previous one.

We went to /cvs/cds/caltech/target/c1psl, then edited psl.db

- Here are the new parameters we set up in the file.

grecord(ai,"C1:PSL-PMC_PMCTRANSPD")
{

  field(LOW,"0.98")
  field(LOLO,"0.93")
  field(HIGH,"1.15")
  field(HIHI,"1.3")

}

- - - -

These values are based on ~4days trend of the PMC_TRAN.

Then we manually updated those numbers by using ezcawrite in order not to reboot C1PSL.

So now it nicely indicates green in the medm screen.

The alarm had kept crying. I reduced the LOW to be 0.90 and the LOLO to be 0.85 both in psl.db and with ezcawrite.

grecord(ai,"C1:PSL-PMC_PMCTRANSPD")
{

New LSC screen is 80% completed.

It is now accessible from the LSC menu of "sitemap".

Most of the part in the screen is clickable such that it launches another screen depending on the location of the click.

The bottom part of the screen still need some work.

RFPD screen is temporary

LSC control screen is also temporary

DAC overflow indicators are still broken.

Channel assignment of the whitening filters are arbitrary so far.

(Joe, Yuta)

Summary:
 No more discrimination for SIDE!
 We had all SIDE filters in SDSEN, so we splitted into SDSEN, SUSSIDE, and SDCOIL just like other DOFs. (Not SIDECOIL. SDCOIL from now on!)
 Also, there was a confusion in output filters, so we fixed the filter bank(dewhitening and 28HzELP).
 More than that, I found that "13HzCheby" in SUSPOS, SUSPIT, SUSYAW was actually doing ~1.6Hz Chebyshev, so I fixed it. (No wonder we had no damping when turing "13HzCheby" on!)
 Our new MEDM screen is Attachment #1.

Input filter design:
 Every optics, every OSEM has same analog whitening filter.
 So;

Next work:
 - Fix Simulink connection and logic so that analog/digital switching go correctly.
 - Check if the switching are correct for all channels by measuring transfer functions.
 - Currently, we are focusing on MCs, but we have to do the same fixing for other optics, too.
 - More than setting the right filter TF, there are switching settings like Zero History, Ramp, Zero Crossing...... We should investigate that.
 - Actually, TF of analog DW in D000183 doesn't look like the same with digital SimDW. Why??

 Conclusion: There is no need to silver plate the SS plunger at the torque level we hold the OSEMs

Mike Gerfen will be done with 50 pieces by April 4 and he will give them to Bob for cleaning. They should be cleaned and baked in a jig so the springs would be compressed for better venting.

I installed an improvised version of PSL output beam iris at the output periscope last week.

[ Johannes, Rana, Mark and Steve ]

On the second trial the shelf was installed. Plastic cover removed. South end door put back on and 2W Inno turned on.

Shelf 10 " below the existing one:   92" x 30" x 3/4" melamine (or MDF) covered with white Formica.  200 lbs it's max load. Working distance to top of the table 18"

After fixing the spelling of the EX temperature readback, I also added all of the MEDM sliders to the C0EDCU.ini file (making sure to add an even number of channels). Restarted FB (after installing telnet on rossa):

telnet fb 8083

> shutdown

preferred method of posting DataViewer images: print as a SVG image (since its vectorized). Then from the command line do:

inkscape steven.svg --export-pdf=vass.pdf

for whatever reason, I am unable to get minute or second trends from nodus for any channels (IMC, PEM, etc) since the reboot. has there been some more recent FB failure or is this still a bug since last years FB catastrophe?

Received the new 1100VA APC UPS today and placed it at the bottom of the valve rack.  I'd connected the battery and plugged the unit into the AC outlet, but did not turn it on due to the power outage this weekend.

The new APC Smart -UPS 2200VA is now running at  the vacuum rack. There are 2 load monitoring leds on out of 5

Maglev, dry pumps and roughing pumps are not using UPS.

The switch over went smoothly with Yoichi's help.

First we closed all vacuum valves and stopped the two small turbos.

Than turned power off to instruments in the vac-rack and VME: c1vac1 & c1vac2

Maglev was left running.

Now we moved the AC plugs from the wall receptacles over to the back of the UPS and powered them up.

Varian turbos were restarted and vacuum valves were restored in order to reach  vacuum normal condition.

See 40m Vacuum System States and Sequences Manual of 10-24-2001

Linux 3 desk top computer is out of order at the pump spool. We should replace it.

The vacuum control screen can be pulled up on a lap top: /cvs/cds/caltech/medm/c0/ve/VacControl_BAK.adj

 I measured the noise spectra and loop TF of the green PDH with the newly stuffed board. Unfortunately, I never took the noise below 100Hz of the previous box, so we can't see what has happened to the overall RMS, or more specifically, the RMS due to the pendulum resonance. All of these plots are in the boosted state, as that is how we intend to use the box. 

Here is the loop, which does not have quite as much margin as the y-arm, but 10dB of gain peaking is probably ok, since the RMS at 10s of kHz is not so important to ALS. (OL measured, CL inferred)  We see the 1/f shape from 1k to 50k or so, and 1/f^2 under 1k, as desired. 

Comparing in the in loop error signals, we see the effect from the increased gain from 100Hz to 10kHz. (Here is where I regret not looking at the low frequency spectrum two weeks ago)

Finally, here is the noise breakdown. 

The error signal RMS is now dominated by the 1Hz peak. We have talked about using digital feedback for this, since we have the PDH error signal coming into an ADC, and can sum in a DAC signal into the servo output. This also lets us intelligently trigger a sub-10Hz boost once the PDH box locks itself. With a good boost, we maybe could bring the in-loop RMS of the error signal to under 1kHz. 

Something odd that Rana brought to my attention, however, is that my measurement and calibration indicates an RMS of ~5kHz, but the cavity pole should be something like 18kHz. If this is true, how can we be seeing stable power? This maybe means that my calibration is too many Hz per Volt.

I performed the calibration by creating a MIST model of the arm, and generating the PDH error signal on a demodulated PD, I then find the slope of Hz per arbitrary error signal unit. Then, looking at a scope trace, I match up the horn-to-horn voltage to the horn-to-horn arbitrary error signal units, which lets me finally find Hz per error signal volt. 

However, there is some qualitative difference in the shape between the simulated and observed error signals, namely, that the outer horns are larger than the inner horns in the real signal. 

Does this matter? Is there something in my simulation that I can correct that would give a more accurate calibration? 

Data, plots, code, attached. 

 What modulation depth are you using for the simulation? I have never seen a real measurement of that in our elog for the end-PDH systems.

I also disbelieve your RMS calculations. It looks like in the 1.5-0.5 Hz band we're picking up 50 kHz of frequency noise even though the 1 Hz peak is only 80 Hz/rHz, even though math says  "80 * sqrt(1) = 80".

Take a look at:

http://www.mathwords.com/r/root_mean_square.htm

and

http://www.ligo.caltech.edu/~rana/mat/utilities/rms.m

I used a modulation depth of 0.3, which, if I recall correctly, is what we aimed for on the Y-arm when we adjusted the LO signal there. However, this is probably not the case for the X arm. 

In any case, I found the bug in my RMS calculation. (I had forgotten to flip the x array in addition to the y array for the right-to-left integration, and had uneven bin spacing, so the integration bandwidths weren't correct...)

Here are the updated plots. The properly evaluated RMS is ~600Hz, which seems to mostly come in around 10k, so we may want to turn down the gain for less gain peaking in that region. 

600 Hz seems ~OK. From the measured reflectivities for 532 nm, the green Finesse = 108. So the green cavity pole should be 18.3 kHz given an arm length of 37.8 m. 

600 Hz of green frequency noise means that we would get 38 pm RMS of arm mirror motion. We should assumed a peak/RMS factor of 10, so this would allow us to get to ~0.4 nm CARM offset.

However, its better than that. What we really care about for ALS is the amount of this green frequency noise which is put onto the arm. With an ALS feedback bandwidth of 100 Hz, my eyeball estimate say that the contribution from green PDH error will be ~100 Hz RMS, since we don't care too much about the 10 kHz stuff. So this seems good enough for now; let's figure out what's up with PDH-Y and get back to locking.

These are plots and notes from last week's PDH adventures. 

For the PDH servo box re-design, we wanted to think a little bit about what we actually wanted out of the box.

* We want the zero of the main transfer function to be at the same frequency as the cavity pole for green, which is about 18kHz.

* We want the boost to suppress noise at a few hundred Hz.  We don't need super-duper low-frequency boost, nor do we want it.  We'd like to leave the boost on all the time.

* Wanted to get rid of 10dB attenuator on PD input, so needed to lower the overall gain.

* We acknowledge that the gain of the raw error signal times the PZT response is very high, so no matter what, we will have to have a low-gain servo, even perhaps have the servo shape be less than unity gain.

---> We reduced the gain of the first amplification stage from a gain of 20 to a gain of 3.

---> Made the boost stage have a DC gain of 1.  Pole at 75 Hz and Zero at 1.6kHz to give suppression at a few hundred Hz.  Boost is *not* a pure integrator, so that we can leave it on.  (If we required triggering anyway, we would have made it a pure integrator).

---> In transfer function stage, put zero at 17.7kHz to match cavity pole.  Pole of servo was going to be at 20 Hz, but we wanted a little more gain, so we lowered it to 2 Hz.

Here is the final measured servo box transfer function for the Yend box (with an arbitrary gain knob setting):

Once installed, I set the gain knob for the Yend at 4.0, which gave an overall UGF of about 10kHz.  Then I measured the loop:

I also measured the error point and the control point, and compared them to Q's measurements in elog 10430.

In order to see what we might expect for a contribution to ALS noise, I looked at the error point spectra and lowpassed it with a pole at 200Hz.  I do this because the PDH error is like sensor noise for the ALS, but the ALS UGF is around 200 Hz, so noise at frequencies higher than that will be suppressed like 1/f.  So, I lowpass the error signal, then look at the RMS, and see that we should be pretty happy with our result. I include also the Xend error spectrum, as measured and reported by Q in elog 10460.

I've set up one 2U server unit received from KT in the control room area (the fans in it are pretty loud but other than that, no major issues with it being tested here). The IPMI interface is enabled and the machine is also hooked up to the martian network for diskless boot (usual login creds). I also installed a Dolphin interface card and the one-stop-systems host side card, and both seem to be recognized (the OSSI card has the "PWR" LED on, the Dolphin card shows up in the list of PCIe devices, but has no LEDs on at the moment). I actually can't find the OSSI card in the list of PCI devices, but maybe I'm not looking for the right device ID, or it needs the cable to be connected to the I/O chassis side to be recognized. Anyways, let the testing begin.

The machine previously christened c1bhd has been turned off and completely disconnected from the martian network (though I didn't bother removing it from the rack for now).

BTW - I think most of our 19" racks are deformed from years of loading - I spent 5 mins trying to install the rails (at 1Y1 and 1X7) to mount the supermicro on, and couldn't manage it. I could be missing some technique/trick, but i don't think so.

I made a new model, c1tst, that we can use for debugging the FREQUENT RCG bugs that we keep encountering.  It's a bare model that runs on c1iscey.  Don't do any thing important in here, and don't leave it in some crappy state.  Clean if up when you're done.

 I wanted to test biquad form in this model. I added biquad=1 flag to cdsParameters, compiled, installed and restarted it. After that c1iscey suspended.

The same thing as we had several month ago

controls@c1iscey /opt/rtcds/caltech/c1/target/c1tst/c1tstepics 0$ cat iocC1.log

Starting iocInit
iocRun: All initialization complete
sh: iniChk.pl: command not found
Failed to load DAQ configuration file

I have fixed the iniChk.pl issue (which actually fixed a separate model startup-on-boot issue that we had been having).  However, that is completely unrelated to the system freeze.  I'll discuss that in a separate post.

We received 6 new  chairs stools for the work benches that have 36" heights.

The control room east side and general office desks require 18" seat height. The new chairs stools have  minimum seat heights  26"

Please label chairs that we are getting rid of.

I've just installed the new control room machine: "pianosa".   It is a replacement for the old sun machine "op440m" [0].

Hardware:

• dual dual-core Intel Core i7-2600 CPU @ 3.40GH, hyperthreaded to provide 8 effective cores
• 16G memory (4x 4G dimms)
• nVidia GF108 GeForce GT 430

It's now running Ubuntu 10.04 LTS 64bit.  Unfortunately, the default 10.04 kernel is 2.6.32, which does not support pianosa's apparently very new network adapter, which is (from lspci):

00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)

To get around this I temporarily added a PCI nic so that I could get on the network.  I then added the Ubuntu kernel team PPA archive and installed linux-image-2.6.38-2, which is new enough to have the needed network driver, but not completely bleeding edge:

sudo add-apt-repository ppa:kernel-ppa/ppa
sudo apt-get update
sudo apt-get install linux-image-2.6.38-2-generic linux-headers-2.6.38-2-generic

Once the built in nic was working I removed the temporary one.  Everything seems to be working fine now.

I have not yet done any configuration to integrate pianosa into the CDS network.  I'll do that tomorrow.

[0] op44m has been moved into the control room rack next to linux1, in headless mode.  If there is still a need to run scripts that only run on solaris, op440m can still be accessed via ssh as normal.  Hopefully we can fully decommission this machine soon.

[1] https://launchpad.net/~kernel-ppa/+archive/ppa

 Konecrane representative gave crane operator training in the 40m. Koji has become a qualified, trained crane operator of the 40m lab.

This is the daqd restart procedure:

That will restart all of the daqd services (daqd_dc, daqd_fw, daqd_rcv).

The front end mx_stream processes should all auto-restart after the daqd_dc comes back up.  If they don't (models show "0x2bad" on DC0_*_STATUS) then you can execute the following to restart the mx_stream process on the front end:

I installed a new version of dataviewer (2.3.2), and at the same time fixed the NDSSERVER issue we were having with cdsutils.  They should both be working now.

The problem turned out to be that I had setup our dataviewer to use the NDSSERVER environment, whereas by default it uses the LIGONDSIP variable.  Why we have two different environment variables that mean basically exactly the same thing, who knows.

 Dataviewer seems to run fine on Chiara (Ubuntu 12), but not on Rossa or Pianosa (Ubuntu 10), or Megatron, which I assume is also something medium-old.

We get the error:

controls@megatron:~ 0$ dataviewer
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Error in obtaining chan info.
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1

Sadface :(   We also get the popup saying "Couldn't connect to fb:8088"

Sorry, that was a goof on my part.  It should be working now.

 Yesterday I moved the whole green electronics stuff, which had been sitting on the floor at the X end,  into a new electronics rack.

The rack now is placed under the cable rail close to the ETMX chamber.

New self checking emergency back up lights were installed at 13 locations in the 40m lab.

Larry Wallace hooked up a new switch (Brocade FWS 648G) today which is our 40m lab interface to the outside world internet. Its faster.

He then, just now, switched over the cables which were going to the old one into the new one, including NODUS and the NAT Router. CDS machines can still connect to the outside world.

In the next week or two, he'll install a new NAT for us so that we can have high speed comm from CDS to the world.

The old IBM laptop (Asia) has died from a fan error after 7 years. WE have a new Lenovo 330 IdeaPad to replace it:

1. to enter bios, the usual FN keys don't work. Power off laptop. Insert paperclip into small hole on laptop side with upside-down U symbol. Laptop powers up into BIOS setup.
2. Insert SL 7.6 DVD into drive
3. Change all settings from modern UEFI into Legacy support. Change Boot order to put CDROM first.
4. Boot.
5. Touchpad is not detected. Hookup mouse for setup.
6. Delete windows partition.
7. Setup wireless network according to (https://wiki-40m.ligo.caltech.edu/Network). Computer name = asia.martian. 
8. Set root password. Do not create user (we want to make the controls acct later using the command line so that we can set userID and groupID both to 1001).
9. Begin install...lots of disk access noises for awhile...

Install done. Touchpad not recognized by linux - lots of forum posts about kernel patching...Arrgh!

Following instructions here, I installed ndscope on this machine. DTT still could not be be run from this machine, and I want to use this today - so I ran the following commands from the K. Thorne setup instructions.

yum clean metadata
yum update
yum install cds-workstation pcaspy subversion redhat-lsb  gnuradio google-chrome-stable xorg-x11-drv-nvidia epel-release redhat-lsb

Now diaggui can be opened, and spectra can be made. I'm moving this laptop to its new home at EY.

had trouble using YUM to update. This turned out to be a config problem with our Martian router, not the new laptop. Since I've changed the WiFi pwd awhile ago for the martian access for the CDS laptops, you'll have to enter that in order to use the laptops.

turned out to be some Access Control nonsense inside of the router. Even loggin in as admin with a cable gave some of the fields the greyed out color (had to hover over the link and then type the URL directly in the browser window). ASIA is now able to connect and use YUM + usual connections. Gautam and I have also moved the router a little to get easier view of its LED lights and not blockk its WiFi signal with the cable tray. We'll get a little shelf so that we can mount it ~1 foot off of the wall.

still, this seems like a bad laptop choice: the Lenovo Ideapad 330 will not have its touchpad supported by SL7 without compiling a new version of the kernel 

• setup controls user using K Thorne LLO CDS offsite workstation instructions
• modified /etc/fstab ala pianosa to NFS mount disks
• set up symlinks as other workstations
• troubles with libsasl2 and libmetaio libraries as usual for SL7 - doing symlink tricks
• setup shared .bashrc
• now running 'yum install gds-all' to see if we need more local libraries to run GDS from the shared disks...

Just for a record. We got 4 new laser pointers (2 greens, 1 blue, and 1 green and red combination). Don't lose them.

They reside in a bucket on the SP table, where IR viewers and sensor cards also reside.

 Low power green-red laser pointers are in. High power green, red and blue pointers are confiscated.

  Red-green laser pointers added to the depleted stock of 2011

The two pointers output measured 4.4 mW green and 2 mW red

I spent today making another daughter board (so that we can use the new scheme for I and Q for one arm), testing it (i.e. measuring noise and TF and comparing to LISO model), and arranging all of this inside the 1U demod chassis. To accommodate everything inside, I decided to remove the 2 unused demod units from inside the box. I then drilled a few holes, installed the daughter boards on some standoffs, removed the capacitors and inductors as I outlined yesterday, and routed input and output signals to/from the daughter board. The outputs are routed to a D-sub on the rear panel. More details + better photo + results of testing the combined demod+daughter board signal chain tomorrow...

I did a quick test of the noise of the new ALS electronics with the X arm ALS. Attachment #1 shows the results - but something looks off in the measurement, especially the "LO driven, RF terminated" trace. I will have to defer further testing to tomorrow. Of course the real test is to digitize these signals and look at the spectrum of the phase tracker output, but I wanted a voltage noise comparison first. Also, note that I have NOT undone the whitening TFs of (z,p) = (15,150) on these traces. I wonder if these noisy signals (particularly the 10Hz multiple harmonics) are an artefact of measurement, or if something is wonky in the daughter board circuits themselves. I am measuring these with the help of a DB9 breakout board and some pomona minigrabbers. Reagrdless, the sort of ripple seen in the olive green trace for the I channel wasn't present when I did the same test with RF signal generators out on the electronics workbench, so I am inclined to think that this isn't a problem with the circuit. I'm measuring with the SR785 with the "A" input setting, but with the ground set to "Float". I need to look into what the difference is between this mode, and the "A-B" mode. At first glance, both seem to be equivalent differential measurements, but I wonder if there is some subtlety w.r.t. pickup noise.

Perhaps I can repeat the test at the output of the AA board. I looked into whether there is a spare +/- 24V DC power supply available at the LSC rack, to power the 1U AA chassis, but didn't see anything there.

I am almost ready for a digital test of the new ALS electronics. Today, Koji and I spent some time tapping new +/-24VDC DIN terminal blocks at the LSC rack to facilitate the installation of the 1U differential receiving AA chassis (separate elog entry). The missing piece of the puzzle now is the timing adapter card. I opted against trying a test tonight as I am having some trouble bringing c1lsc back online.

Incidentally, a repeat of the voltage noise measurement of the X arm ALS beat looked much cleaner today, see Attachment #1 - I don't have a good hypothesis as to why sometimes the signal has several harmonics at 10Hz multiples, and sometimes it looks just as expected. The problem may be more systematically debuggable once the signals are being digitally acquired.