This is at least partially related to the mx_stream issue I reported previously.  I restarted mx_stream on c1iscex and that cleared up the models on that machine.

Something else is happening with c1sus.  Restarting mx_stream on c1sus didn't help.  I'll try to fix it when I get over there later.

I managed to recover c1sus.  It required stopping all the models, and the restarting them one-by-one:

$ rtcds stop all     # <-- this does the right to stop all the models with the IOP stopped last, so they will all unload properly.

$ rtcds start iop

$ rtcds start c1sus c1mcs c1rfm

I have no idea why the c1sus models got wedged, or why restarting them in this way fixed the issue.

For some reason the state of the oplevs is completely different for almost every suspension.  They have different sets of filters in the bank, and different filters engaged.  wtf?  How did this happen?  Is this correct?  Do we expect that the state of the oplevs should be different on all the different suspensions?  I wouldn't have thought so.

I discovered this because the PRM is unstable with the oplevs engaged.  I don't think it was yesterday.  Is something hidden changing the oplev settings?

 As of February 23, 2012 when oplev PIT and YAW transfer functions were taken

 Its a good question, but the answer is yes. At some level all of the OL servos should be different to handle the different mechanical resonances of the suspension as well as the optical table's acoustic noise and the different noise requirements for the difference optical cavities.

However, it would be better to have the same basic structure and then one or two customization filters.

Summary:
  I tried to find Y arm green beat in order to do the mode scan.
  I found a beat peak(see attached picture), but the amplitude seems too small.
  It is may be because the alignment/mode matching of the green beams at the PSL table is so bad. Or, the peak I found might be a beat from junk light.

What I did:
  1. Aligned Y arm to the IR beam from MC.

  2. Re-aligned Y end green beam to the Y arm using steering mirrors on the Y end table.

  3. Re-aligned PSL green optics.

  # C1:GCV-GREEN_TRY is temporary connected to the DC output of the Y green beat PD.

  4. Temperature of the PSL laser was 31.48 deg C, so I set "T+" of the Y end laser to 34.47 deg C, according to Bryan's formula (elog #4439);

  Y_arm_Temp_set = 0.87326*T_PSL + 6.9825

  5. Scanned Y end laser temperature by C1:GCY-SLOW_SERVO2_OFFSET. Starting value was 29725 and I scanned from 27515 to 31805, by 10 or 100. Laser frequency changes ~ 6 MHz / 10 counts, so it means that I scanned ~ 2.5 GHz. During the scan, I toggled C1:AUX-GREEN_Y_Shutter to make sure the green beam resonates in TEM00 mode.

  # I made a revolutionary python script for toggling channels(/opt/rtcds/caltech/c1/scripts/general/toggler.py). I made it executable.

  6. Found a tiny beat note when C1:GCY-SLOW_SERVO2_OFFSET = 29815. I confirmed it is a beat signal by blocking each PSL and Y arm green beam into the beat PD. I left  C1:GCY-SLOW_SERVO2_OFFSET = 29815.

  7. I found that Bryan's formula;

Y_arm_Temp_meas = 0.95152*T_PSL + 3.8672
Y_arm_Temp_set = 0.87326*T_PSL + 6.9825

  was actually

Y_arm_Temp_set = 0.95152*T_PSL + 3.8672
Y_arm_Temp_meas = 0.87326*T_PSL + 6.9825

  according to his graph(elog #4439). So, I set  "T+" of the Y end laser to 33.82 deg C.

  8. This time, I scanned PSL laser temperature by C1:PSL-FSS_SLOWDC. I found a tiny beat note when C1:PSL-FSS_SLOWDC = 1.0995. C1:PSL-FSS_SLOWDC has 10 V range, so I scanned ~ 10 GHz, assuming the laser frequency changes 1 GHz/K and the temperature changes 1 K/V.

  9. Re-aligned PSL green optics so that the beam hits optics at their center, and checked that the poralization of the two green beams are the same.

  10. Checked that amplifier ZFL-100LN+ on the beat PD is working correctly. The power was supplied correctly (+15 V) and measured gain was ~ 25 dBm.

  11. Exchanged BNC cable which connects the beat PD to the spectrum analyzer. Previous one we used was too long and it had -15 dB loss(measured). I exchanged to shorter one which has -2 dB loss.

Beat note amplitude estimation:
  The amplitude of the beat note observed in the spectrum analyzer was ~ -54 dBm. According to the estimation below, it seems too small.

  The measured power of the two green beams are

  P_Y = 4 uW
  P_PSL = 90 uW

  So, the power of the beat signal should be

  P_beat ~ 2 sqrt(P_Y * P_PSL) = 37 uW

  Responsivity and transimpedance of the beat PD (Broadband PD, LIGO-T0900582) are 0.3 A/W and 2 kOhm. So, the power of the electrical signal is

  W = (P_beat * 0.3 A/W * 2 kOhm / sqrt(2))^2 / 50 Ohm = 5 uW

  5 uW is -23 dBm. We have +25 dB amplifier after the PD and the loss of the BNC cable is -2 dB. So, if the two beams interfere perfectly, the peak height of the beat signal should be ~ 0 dBm. The measured value -54 dBm seems too small. According to elog #5860, measured value by Kiwamu and Katrin was -36 dBm.

Current values:
  PSL laser temperature: 31.48 deg C (PSL HEPA 100%)
  Y end laser "T+": 33.821 deg C
  Y end laser "ADJ": 0
  C1:GCY-SLOW_SERVO2_OFFSET = 29815 (was 29725)

We have 2 sts-2 readout box - pink and blue. Pink outputs 12 DVC - this a problem of amplifier. This box has a rectifier (the box works from AC power) and an amplifier for velocity channels. Mass positions, calibration channels are connected by a wire from input to output. The amplifier for velocity channels does not work properly, so I connected velocity channels directly to the output - the signal from sts-2 is large enough even without amplification. When I plugged sts-2 to pink readout board, on the velocity output I saw ~4 VDC. Sts-2 was needed to be recentered. I pressed AUTOZERO command, but this did not work out. Before I had checked that this readout box indeed gives an autozero logical signal - 5VDC for ~2 sec. I think it does not provides sts-2  with enough current, seismometer needs 0.1 A in autozero regime.

Blue readout box after switching it to 1 sec regime and zeroing sts-2 started to output reasonable signal for gains = 10. I tried gains = 100, X velocity channel started to output noise. Now the gain is 10 and the response is 120 sec. But at least this box works. Still performance is not clear as well as noise level. To determine this I've put sts-2 to isolation box.

After I've put Guralps in the isolation and waited for a couple of days, Guralp noise has been improved a little more.

From now all models calculate iir filters using biquad form. I've added biquad=1 to cdsParameters to all models except c1cal, built, installed and restarted them.

As of now, the regular LSC DoF triggers work, just as they used to.  There is a problem with the filter module triggers that I haven't figured out yet. 

We can't send integers (like control words for the filter banks) through Choice blocks, since those pass doubles by default.  I fixed that by removing the choice block, but the triggering still isn't happening properly.

We're trying to do a yarm measurement....before I forget, I want to write this down...

I changed the gain of each of the top 2 SR560's down, by a factor of 2.  This made the overload lights quit coming on.

[Yuta, Jenne]

Vaguely chronological order:

Found a beat peak, thought it was puny, went to realign Ygreen at end table.

Noticed that beam out of faraday was clipping on the last lens before the steering optics.  We adjusted the mirror directly before the faraday, making sure the power transmitted (measured by the Ophir) didn't go down. Now we're roughly centered on both the lens directly after the faraday, and the lens before the steering optics.

This, of course, meant that we had to completely realign the Ygreen beam to find the TEM00 resonance.  We did that.  Actually, this took us a really long time. We ended up putting a temporary CCD camera on the PSL table to look at the transmitted green light.  This helped a lot, but the resonant modes were just totally wacky.  We finally were able (after 30+ minutes, using the camera) to get to TEM01.  Then Yuta adjusted ITMY a teeny bit, and green was happy to resonate.  We then removed the CCD camera so that we could move on to beat stuff.

Yuta decided it's faster to sweep the PSL temp, rather than the end laser temp, since we don't have to watch that the arm maintains lock.  So we set the end laser temp (T+) to 34.049C, which gave a measured temperature at the back of 34.68C (with an offset of 29425)

We then swept the SLOW adjust on the FSS screen to change the PSL temp.  We went all the way, starting at 0, to +10, back to 0, then on to -10, in steps of 0.01 .

We found a puny peak at -0.96, and pretty good peak at -9.48.  Height of the pretty good peak, after optimizing PSL table beat alignment was -50dBm. At this time, the PSL temp is 33.81C, while the Yend is still measured at 34.68C.

I checked the cabling, and it looks like the beat setup is still as it should be, using the old-school, non-beatbox stuff.  We plugged the beat PD into the beat detection setup, removing it from the spectrum analyzer.  As mentioned in my self-reminder elog, I changed the gains on the top 2 SR560's down by a factor of 2 so they weren't overloading. 

We aren't really sure that we're getting any real signals into the ALS model though.  C1:ALS-BEATY_COARSE_I_MON seems to be the same whether or not the arm is locked on green, therefore it seems to be the same ~500 or 600 counts whether or not there is a beat.  Hmmmm. We used the offset option of the OFFSETTER2 to send an offset to the beat signal that gets sent to the ETMY.  We confirmed that signals are going out to ETMY from the ALS model, but we're not sure if they are correct / non-insane signals.  One symptom that we're seeing is even though we have the Yarm locked on green, and the ALS system engaged, the arm is still flashing in IR, which means the green is mostly just following the arm.  We're not actually holding the arm in place.

Also, TRY and TRX are not recorded channels, so I went into the .ini file to have them acquire (uncommented them, set acquire=1, set the data rate to 2048), saved the ini file, and restarted the fb's daqd process.  The new TRY_OUT_DQ channel is digital zeros, and is red in dataviewer.  Also, the lsc model is no longer happily connected to the framebuilder.  I then decided to try Joe's old .daqconfig script (in the scripts directory) which provides a gui for acquiring channels.  Restarted the daqd process, same story.  I then went back to comment out the TRY_OUT_DQ lines, set acquire=0, set data rate back to 16384.  Joe's program put a bunch of spaces into the .ini file, but I don't think they do anything bad.  Except that now when I restart daqd, lsc still won't connect to the framebuilder.  Yuta setup pynds to save the data, if we were able to get anything useful.

We couldn't make awg, tdssine, or DTT write anything to the OFFSETTER2_EXC.  This is annoying, because this is how (once we figure everything else out) we need to sweep (with a ramp or triangle) the beat signal.

Moral of the night: we learned some stuff, but ultimately failed.

What not to do:

The PRM oplev servo was left on and it was driving this oscillation overnight.

 I noticed that the ion pump was turned off.

It was turned ON. It showed 0.00 microA at 5kV  The current display is not sensitive enough. There must be some small outgassing or leak. It adds up if we stop pumping.

We want to keep the reference cavity in pristine condition. It required the ion pump running all times.

 Air conditioning maintenance is scheduled for tomorrow from 8 to 11am

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.

Currently, ezca tools are flakey and fails too much.
So, I hacked ezca tools just like Yoichi did in 2009 (see elog #1368).

For now,

/ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcaread
/ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcastep
/ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcaswitch
/ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcawrite

are wrapper scripts that repeats ezca stuff until it succeeds (or fails more than 5 times).

Of course, this is just a temporary solution to do tonight's work.
To stop this hack, run /users/yuta/scripts/ezhack/stophacking.cmd. To hack, run /users/yuta/scripts/ezhack/starthacking.cmd.

Original binary files are located in /ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcabackup/ directory.
Wrapper scripts live in /users/yuta/scripts/ezhack directory.

I wish I could alias ezca tools to my wrapper scripts so that I don't have to touch the original files. However, alias settings doesn't work in our scripts.
Do you have any idea?

We have too much crap in the rfm model.  CPU time for the rfm model is regularly above 60us, and sometimes in the mid-70's (but sometimes jumps down briefly to ~47us, which is where I think it "used" to sit, but I don't remember when I last thought about that number)

This is potentially causing lots of asynchronous grief.

Just as Yuta and I were sitting down to look at our beatnote (really the output of the freq discriminator) on Dataviewer, all the FB net boxes on the CDS status screen were white.  I restarted daqd, and most of the computers came back fine.  c1iscey and c1sus still had some red bad boxes.  So I restarted mx_stream on both, and they are now fine.

Somehow, this also fixed whatever I had done to the lsc model yesterday (although I think TRY is still not recorded at this time - not messing with it yet).

[Jenne, Yuta]

Summary:
  We tried to see the Yarm length change using Yarm green beat note. The beat note is still puny, so we put an extra amplifier. We saw something, but still can't control the arm length with ALS.

What we did:
  1. Aligned Y arm and PSL green optics as usual.

  2. By changing the temperature of the PSL laser with C1:PSL-FSS_SLOWDC, we find small beat note when

  PSL laser temperature on display: 30.59 deg C (PSL HEPA 100%)
  C1:PSL-FSS_SLOWDC = 5.2100
  Y end laser "T+": 34.049 deg C
  Y end laser "ADJ": 0
  Y end laser measured temperature: 34.68 deg C (*)
  C1:GCY-SLOW_SERVO2_OFFSET = 29425

 (*) Measured using diagnostic output on the back of the laser controller(Lightwave 125/6-OPN-PS) - between pins 2(GND) and 4. Calbration factor is 10 degC/V.

  3. The peak height right after the amplifier on the Y green beat PD was ~ -48dBm, so we put another amplifier (and attenuator) because the beat note which goes into the frequency divier should be -30 dBm to +7 dBm. After we put the amplifier, the peak height was ~ -23 dBm.

  4. We could see the C1:ALS-BEATY_COARSE_I_ERR ringing down, when opening and closing the control room door, which may introduce Y arm length change(screenshot of dataviewer below). But we are still not sure if we are actually getting the Y arm length signal because closing and opening Y end green shutter doesn't make difference on C1:ALS-BEATY_COARSE_I_ERR. The ring down was seen when we turned on the unWhiten filters in C1:ALS-BEATY_COARSE filter modules.



  5. Tried to hold Y arm length with ALS, but couldn't.

Current setup:
  Red ones are the ones we added or changed.



Note:
  Dataviewer is so slow and flakey now.

 Oplev servo turned off and sus damping restored. What is kicking up the PRM?

Rana, Steve,

 Late entry for Monday morning June 4, 2012

Cables were stress relieved. Cable entry - exit ports enlarged. Air gaps were minimized.

MC reflection (C1:IOO-MC_RFPD_INMON) got worse when WFS servos were on. After aligning MC optics, it will be ~0.5 but if I turned on WFS, it became ~0.8.
I measured the beam spot positions on MC optics. They seemed like the same from the measurement yesterday.

# filename      MC1pit  MC2pit  MC3pit  MC1yaw  MC2yaw  MC3yaw  (spot positions in mm)
./dataMCdecenter/MCdecenter201206052111.dat     3.234388        4.234564        2.654212        -6.656221       -0.677541       4.506170       
./dataMCdecenter/MCdecenter201206061420.dat     3.300867        4.567555        2.692971        -6.484464       -1.705443       4.423250

So, I ran /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets to adjust the WFS offsets.

C1:IOO-MC_RFPD_INMON is now ~ 0.5 and  C1:IOO-MC_TRANS_SUM is now ~ 2.7e3 with WFS on.

I didn't like this solution, so I hacked up something else.  I made a new single wrapper script to handle all of the utils.  It then executes the correct command based on the zeroth argument (see below).

I think moved all the binaries to give them .bin suffixes, and the made links to the new wrapper script.  Now everything should work as expected, with this new retry feature.

controls@rosalba:/ligo/apps/linux-x86_64/gds-2.15.1/bin 0$ for pgm in ezcaread ezcawrite ezcaservo ezcastep ezcaswitch; do mv $pgm{,.bin}; ln ezcawrapper $pgm; done
controls@rosalba:/ligo/apps/linux-x86_64/gds-2.15.1/bin 0$ cat ezcawrapper
#!/bin/bash

retries=5

pgm="$0"
run="${pgm}.bin"

if ! [ -e "$run" ] ; then
    cat <&2
This is the ezca wrapper script.  It should be hardlinked in place of
the ezca commands (ezcaread, ezcawrite, etc.), and executing the
original binaries (that have been moved to *.bin) with $retries
failure retries.
EOF
    exit -1
fi

if [ -z "$@" ] || [[ "$1" == '-h' ]] ; then
    "$run"
    exit
fi

for try in $(seq 1 "$retries") ; do
    if "$run" "$@"; then
	exit
    else
	echo "retrying ($try/$retries)..." >&2
    fi
done
echo "$(basename $pgm) failed after $retries retries." >&2
exit 1

Yuta and I added a feature such that it will not retry if the environment variables EZCA_NORETRY is set, e.g.

$ EZCA_NORETRY=true ezcaread FOOBAR

Summary:
  Y arm green transmission to the PSL table improved from ~ 20 uW to 61 uW. Improvement was done by adjusting steering mirrors before and after the faraday on the Y end table.
  But 61 uW is not enough!

What I did:
  1. The incident power to the faraday for the green beam on the Y end table was 1.4 mW, but the transmission was 1.2 mW. So, I adjusted the steering mirrors and the transmission increased to 1.4 mW.

  2. I found that adjusting the steering mirrors to the faraday also increased alignment of the green beam to the Y arm. We always adjusted only the steering mirrors after the faraday for the alignment. I adjusted the alignment using both steering mirrors this time. Reflection of the green beam on the ETMYT camera seems more reasonable now and more frequently lock to TEM00 when closing and opening the Y end green servo loop.

  3. For the adjustment, I tried to utilize PD at the reflection port, or the transmission port. However, I couldn't do that because they fluctuates too much. I don't know why.

  4. Measured the green transmission to the PSL table, The transmitted power was ~20 uW, but after the aligning, it improved to 61 uW.

Current green power:
  I measured the green beam power at various places using Newport power meter (Model 840) with its filter on.



  Incident green power to the Y arm is ~ 1 mW (more than 1 mW because the aparture of the power meter was smaller than the beam size) and Y arm transmission is designed to be 55%. So, if the alignment and mode matching are perfect, the transmission to the PSL table should be ~ 600 uW. The measured value 61 uW seems too small. Kiwamu says it was 140 uW when he did Y arm.

Next:
  I will find the beat note again tonight and check if the beat PD is working correctly and if the mode matching of the two beams at the PSL table is good.

I've spent an inordinate amount of time trying to figure out how to get pianosa to support dual monitors.  It apparently has some special nvidia graphics that are not well supported in Ubuntu (10.04 at least).  I've tried installing a newer kernel (3.0.0) and installing the special nvidia compile-from-source Ubuntu packages, but nothing is working.  And now unfortunately he's not giving me any video at all.  I'm sick of this today, so I'll try again tomorrow.

In the future we should avoid these bullshit nvidia cards like the plague.

I managed to get pianosa working again with just a single monitor.  I'm done trying to configure it for dual, though.

I'll finish the rest of the config to turn it into a full-fledged workstation tomorrow.

[Koji, Yuta]

Summary:
  We improved the Y arm green transmission to the PSL table. It is now 197 uW.
  The improvement was done mainly by adjusting the Y arm green servo gain.

What we did:
  1. Fine-adjusted steering mirrors after the faraday on Y end table by monitoring Y arm green transmission (used Thorlabs PDA36A as a PD, C1:GCV-GREEN_TRY as a channel). We decided which way to adjust the mirrors by just pushing/pulling its mount.

  2. The output of the reflection PD on the oscilloscope seemed like the Y end frequency servo was oscillating. So, we reduced the amplitude of the frequency modulation from 2.83 V to 0.13 V.

  3. We noticed there were two TEM00, one is brighter and the other is dim. We thought this came from a mode-hopping or something. So, we changed the Y end laser temperature from 34.68 deg C to 34.13 deg C (measured). This reduced dim TEM00 and the main one got brighter. C1:GCY-SLOW_SERVO2_OFFSET was changed from 29425 to 29845.

  4. Fine-adjusted the position of the mode-matching lens by reduing LG modes.

Current green power:
  Current measured green power values are as follows.



  Calculated value for the Y arm green transmission is ~ 600 uW, but we think we are almost at the maximum we can get. So, we have about 70% loss from the Y end table to the PSL table. There may be large loss in windows. The beam shape of the transmitted beam seems OK, but there may be some clipping.

To do:
  - Fine tune the Y end frequency servo loop. Reducing the amplitude of the frequency modulation for reducing the gain is not a very good idea.

Summary:
  I found the big green beat note for the Y arm. The alignment of the green optics on the PSL table was crappy.

What I did:
  1. By adjusting PSL laser temperature, I found tiny beat note when

  PSL laser temperature on display: 31.35 deg C (PSL HEPA 100%)
  C1:PSL-FSS_SLOWDC = 1.75

and

  PSL laser temperature on display: 33.21 deg C (PSL HEPA 100%)
  C1:PSL-FSS_SLOWDC = -6.82

Y end laser temperature settings are fixed as follows during the measurement.

  Y end laser "T+": 34.049 deg C
  Y end laser "ADJ": 0
  Y end laser measured temperature: 34.13 deg C (*)
  C1:GCY-SLOW_SERVO2_OFFSET = 29845

Bryan's formula (swapped one; see elog #6746),  suggests the paring

  (Yend laser temp, PSL laser temp) = (34.13 deg C, 31.09 deg C).

  2. Checked that beat PD is working by swapping the beat PDs for Y arm and X arm.

  3. Checked that the mode-matching of the two beams, one from Y arm and the other from PSL, is OK by moving mode-matching lens and measuring the beam spot size at near/far field are the same.

  4. When checking the beam spot size at far field(~ 1 m from the BS), I noticed the relative beam tilt by ~ 1 mrad. We aligned them few days ago, but I think the green beam from the Y arm has shifted. Of course we align IR to the Y arm first, but we difinitely need dither servo or A2L for the arm, too.

  5. As soon as aligning the PSL green optics near the BS, I found a large beat note. The measured amplitude was ~ -26 dBm, without any amplifiers after the PD.

  Currently the measured green beam power onto the beat PD from Y end is 75 uW and from PSL is 92 uW. So the calculated beat amplitude will be ~ -10 dBm (see calculation in elog #6746). So there is about 84% loss. Anyway, I will go on to the mode scan.

c1lsc and c1ioo computers had FB net statuses all red. So, I restarted mx_stream on each computer.

ssh controls@c1lsc
sudo /etc/init.d/mx_stream restart

I coarsely stabilized Y arm length to off resonance point for IR using ALS.
Currently, ASL servo loop is unstable and oscillates so much that I can't hold the length to the resonance point.
We need more investigation on the servo loop before doing the mode scan.

Below is a snapshot of ALS medm screens and time series data of the error signal for ALS coarse loop (C1:ALS-BEATY_COARSE_I_ERR) and IR transmission for the Y arm (C1:LSC-TRY_OUT) when I turned the servo on.

Note:
  I took off amplifiers right after the beat PD on PSL table.
  Also, I reverted the gain change Jenne made last night (elog #6750), because they no longer show overload lights.

Yes. The end PDH servo should be checked more carefully.

The end PDH seems to have insufficient gain at around 100Hz.
The attached is the ALS noise budget calculated with the simulink model for the green locking paper.

The residual error of the end AUX laser (green) is contributing to the final ALS signal (black).
In particular, the residual AUX frequency noise, which is shown as the blue, is contributing to the noise above 100Hz.

In the model I also confirmed that the servo still has a room for improvement.

By having more suppression of the AUX frequency noise, we will be able to increase the ALS servo bandwidth
without increasing the ALS residual RMS by a servo bump. This will give us the improvement of the seismic
noise suppression at 10Hz (i.e. more suppression of red).

 The PRM oscillation stopped by turnig off oplev servo.

Do not turn Oplev Servo on when PRM is missaligned !

 Jeff checked and  replaced filters  as needed. Job completed this morning.

I decided to remove what I thought was the problematic extra nVidia video card, since there are already two DVI outputs build-in.  The card turned out to not even be nVidia, so I don't know what was going on there.

I futzed with the BIOS to configure the primary video card, which is some new Intel card.  The lucid (10.04) support for it is lacking, but it was easy enough to pull in new drivers from the appropriate Ubuntu PPA repository:

controls@pianosa:~ 0$ sudo apt-add-repository ppa:f-hackenberger/x220-intel-mesa
controls@pianosa:~ 0$ sudo apt-add-repository ppa:glasen/intel-driver
controls@pianosa:~ 0$ sudo apt-get update
...
controls@pianosa:~ 0$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be upgraded:
  libdrm-intel1 libdrm-nouveau1 libdrm-radeon1 libdrm2 libgl1-mesa-dri libgl1-mesa-glx libglu1-mesa xserver-xorg-video-intel
8 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 3,212kB of archives.
After this operation, 25.2MB disk space will be freed.
Do you want to continue [Y/n]?
...
controls@pianosa:~ 0$

After a reboot, both monitors came up fine.

http://www.subcritical.org/running_ubuntu_lts_on_sandy_bridge/

Added zita to the martian host table, and configured his network accordingly:

zita            A       192.168.113.217

https://wiki-40m.ligo.caltech.edu/Martian_Host_Table

  Set the PRM OL servo gains to zero until someone can take care of this. Turning off the buttons doesn't help anything if people run the alignment scripts.

Done.

C1:SUS-PRM_OLPIT_GAIN 1.0 -> 0
C1:SUS-PRM_OLYAW_GAIN -0.7 -> 0
 

Somehow c1sus was in a very strange state.  It was running models, but EPICS was slow to respond.  We could not log into it via ssh, and we could not bring up test points.  Since we didn't know what else to do we just gave it a hard reset.

Once it came it, none of the models were running.  I think this is a separate problem with the model startup scripts that I need to debug.  I logged on to c1sus and ran:

rtcds restart all

(which handles proper order of restarts) and everything came up fine.

Have no idea what happened there to make c1sus freeze like that.  Will keep an eye out.

PRM oplev beam was not hitting on the QPD since Jun 1, so I centered it. I reverted the oplev servo gains and now oplev servo looks fine.

C1:SUS-PRM_OLPIT_GAIN = 1.0
C1:SUS-PRM_OLYAW_GAIN = -0.7

There's SIDE to UL/UR/LL/LR coil element in PRM TO_COIL matrix. They were 0 until Mar 31, 2012, but someone changed them to -0.160. I couldn't find elog about it.
Same thing happened to BS on Mar 13, 2012 (see elog #6409), so I think somebody did the same thing to PRM.

Laser temperature settings for Y arm green work today are;

  PSL laser temperature on display: 31.38 deg C (PSL HEPA 100%)
  C1:PSL-FSS_SLOWDC = 1.68
  Y end laser "T+": 34.049 deg C
  Y end laser "ADJ": 0
  Y end laser measured temperature: 34.13 deg C (*)
  C1:GCY-SLOW_SERVO2_OFFSET = 29845

Green transmission from Y end and PSL green power on the beat PD are;

  P_Y = 28 uW
  P_PSL = 96 uW

P_Y decrease from its maximum we got (75 uW, see elog #6777) is because the alignment for Y arm green is decreased. I can see the decrease from the green reflection on ETMT camera, but I will leave it because we already have enough beat.

I aligned PSL optics, including the mode-matching lens to maximize the beat note. The beat note I got is about 26dBm.
The calculated value is -14 dBm, so we have about 75 % loss.
I measured the reflection from the PD window and its reflectivity was about 30%. We still have unknown 45% loss.

 40m - pumpdown 71- maglev pumping speed - at day 276........all normal

 The PMC was locked and the MC followed intantly

There is an intermittent rattling sound coming from the HEPA in the NE corner of the PSL table (right above the PMC, all of our input optics).

Steve says it might be a bad bearing, but he'll check it out in the morning and get it fixed.

 MC was having a hard time staying locked, with no discernable reason from the control room (i.e. no big seismic, no PMC PZT railing).    The HEPA was on 100%, so I turned it down to 50% to hopefully reduce the rattling, if that was what was wrong. 

Summary:
  We need I-Q frequency deiscriminator to control the arm length fine and continuously.
  I checked the beatbox (LIGO-D1102241-v4; see elog #6302) and it was working.

What I did:
  1. Measured some transferfunctions with a network analyzer (Aligent 4395A) and checked the cabling is correct.

  2. Put 30 m/1.5 m delay line and checked I-Q outputs are actually orthogonal. I did this by sweeping the frequency of RF input to the beatbox. See attached picture. You can see nice circle on the oscilloscope.

Some measurement results:
  - Gains of the transferfunctions(@ 10-100MHz) between;

   RF in -> RF mon: -25 to -20 dB
   RF in -> fine delay out: -50 to -40 dB
   RF in -> coarse delay out: -50 to -40 dB
   RF in -> LO of mixer RMS-1: ~ +4 dB  (RMS-1 needs +7 dB LO)
 
  - 30m delay line(RG-142B/U) had -2 dB loss.

Note:
  - RF input must be larger than about -3 dBm to get enough LO to the mixer. Otherwise, you won't get I-Q outputs.
  - The comparator, whitening filter and differential DAQ outputs are not installed in the current beatbox.
  - Current beatbox only has electronics for the one arm.
  - The print on the board D1102241 says +15V and -15V, but they are actually opposite. Cabling is swapped in order to supply correct power to the ICs.

tdsavg isn't working:

controls@rossa:/opt/rtcds/caltech/c1/scripts/LSC 6$ tdsavg 10 C1:LSC-ASDC_IN1
ERROR: LDAQ - Unable to find NDS host "fb0"
ERROR: LDAQ - Unable to find NDS host "fb1"
ERROR: LDAQ - Unable to open socket to NDS.


When this command is executed inside a script, it doesn't return anything.  eg:

set offset = `tdsavg 10 C1:LSC_ASDC_IN1`
echo $offset

returns a blank line. 

Past elog research said lots of things about test points.  I didn't suspect that, since there aren't many test points occupied (according to the CDS status screens), but I cleared the test points anyway (elog 6319).  Didn't change anything, still broken.

LSCoffsets script, and any others depending on tdsavg will not work until this is fixed.

We can't compile any changes to the LSC or the GCV models since Jamie's new script / program isn't found.  I don't know where it is (I can't find it either), so I can't do the compiling by hand, or point explicitly to the script.  The old way of compiling models in the wiki is obsolete, and didn't work :(

This means we can't (a) record TRY or (b) add the Q quadrature of the beat PD to the real time system tonight.

We're going to try just using Yuta's pynds script to capture data in real time, so we can keep working for tonight.