ELOG 40m

old hubs can make one happy

Joseph finds a XIX century bottle neck hub: CentreCOM 3624TR 10Base-T
and happily replaces it with Netgear GS724T 1000Base-T

Attachment 1: P1020934.jpg

973

Fri Sep 19 11:21:45 2008

josephb

Nameserver and Rosalba

I tried modifying the nsswitch.conf file to include going to dns in addition to local files for everything (services, network, etc) and then moving the /etc/hosts file to /etc/hosts.bak. Unfortunately, this still didn't allow front-ends to reboot properly. So I'm not sure what is using the hosts file, but whatever it is, is apparently important. After the test I placed the hosts file back and reverted the nsswitch.conf file.

I also noticed that Rosalba was having problems connecting to the network. This apparently was because I had shut down the dhcp server on the NAT router, as had been discussed at the meeting on Wednesday.

To fix this, I modified the /etc/sysconfig/network-scripts/ifcfg-eth1 file to fix rosalba's ip as 131.215.113.24 (which doesn't seem to be in use). I also updated rosalba's /etc/resolv.conf file to point at linux1's name server, and two additional name servers as well, and added the "search martian" line. I modified the /etc/sysconfig/network-scripts/ifcfg-eth0 file so the built in network card doesn't come up automatically, since its currently not plugged into anything. Lastly, I added rosalba and its IP to linux1's name server files.

972

Fri Sep 19 09:49:42 2008

The problem below is fixed now.
The cause was .svn/entries and .svn/format had wrong version number "9" where it had to be "8".
I changed those files in all the sub-directories. Now svn up runs fine.
I don't know how this version discrepancy happened.

Quote:

linux2:mDV>ssh nodus
Password:
Last login: Fri Sep 19 00:11:44 2008 from gwave-69.ligo.c
Sun Microsystems Inc.   SunOS 5.9       Generic May 2002
nodus:~>c
nodus:caltech>cd apps/
nodus:apps>cd mDV
nodus:mDV>svn update
svn: This client is too old to work with working copy '.'; please get a newer Subversion client
nodus:mDV>whoami
controls
nodus:mDV>uname -a
SunOS nodus 5.9 Generic_118558-39 sun4u sparc SUNW,A70 Solaris
nodus:mDV>pwd
/cvs/cds/caltech/apps/mDV
nodus:mDV>

971

Fri Sep 19 08:09:55 2008

I have just turned on the PSL HEPA filters at 60% operational speed.

970

Fri Sep 19 01:55:41 2008

Summary

SUS

SUS Drift Screen Updated

I wrote 2 matlab scripts to update the SUS DRIFT screen:

- setsval.m   uses mDV to get the minute trend from some specified start time
              and duration in the past. It then writes that 'good' value to the
              .SVAL field of the SUSPOS, SUSPIT, and SUSYAW records for all the
              optics

- setHILO.m   reads the .SVAL field and then sets the alarm levels and severity
              for the same records given a "sigma" as an argument. i.e. 1 sigma = HIGH,
              2 sigma = HIHI.

Attached is the new screen. WE can now use this to judge when the optics have moved alot.

If someone will edit the BURT .req file to have these subfields
(.HIHI .HIGH .LOW .LOLO .HHSV .HSV .LSV .LLSV) then they will come back after a reboot as well.

Below I'm also attaching the matlab code for people at the observatories who don't have
access to the SVN here.

Attachment 1: infection-3.png

Attachment 2: setsvals.m

function varargout = setsvals(varargin)
% SETSVALS
% sets the SVAL records for the SUS

debug = 0;


if nargin < 2
  error('Needs 2 arguments.')
elseif nargin > 2

... 56 more lines ...

Attachment 3: setHILO.m

function setHILO(varargin)
%  SETHILO 
%  Ex.  setHILO(1000);
%      this sets the SUS alarm levels to be 1000 counts
%      from the nominal

% 1 for debugging
debug_flag = 0;

if nargin == 1

... 62 more lines ...

969

Fri Sep 19 00:18:14 2008

linux2:mDV>ssh nodus
Password:
Last login: Fri Sep 19 00:11:44 2008 from gwave-69.ligo.c
Sun Microsystems Inc.   SunOS 5.9       Generic May 2002
nodus:~>c
nodus:caltech>cd apps/
nodus:apps>cd mDV
nodus:mDV>svn update
svn: This client is too old to work with working copy '.'; please get a newer Subversion client
nodus:mDV>whoami
controls
nodus:mDV>uname -a
SunOS nodus 5.9 Generic_118558-39 sun4u sparc SUNW,A70 Solaris
nodus:mDV>pwd
/cvs/cds/caltech/apps/mDV
nodus:mDV>

968

Fri Sep 19 00:06:54 2008

MC_F: Too much frequency noise around 100 Hz

IOO

WE noticed this excess again in MC_F. We tried recentering the WFS, but no effect.

Also no effect from changing the FSS gain, PMC gain, or ISS gain.

Actually, there IS a change when changing the PMC gain -- the ISS can be made to saturate
by lowering the PMC gain by 10 dB. Jenne and I need to finish off the PMC loop.

10 kHz UGF or bust!

Attachment 1: mcf.png

967

Thu Sep 18 23:31:26 2008

ISS: Saturating too often at nominal gain

The ISS has been saturating whenever the MC relocks and puts the gain up to +8dB. I have
lowered the gain to +1 dB for now to stop this, but we need to revisit the ISS loop and
performance. Stefan can fix it up for us as penance when he returns from the hedonism of Amsterdam.

Attachment 1: FIRE_BLOWER.jpg

966

Thu Sep 18 18:38:14 2008

HowTo

How to compile an SNL code for VxWorks

Dave Barker guided me through how to compile an SNL code into a Motorola 162 CPU object.

Here is the procedure:

(1) You need an account at LHO and a password for ops account at LHO. Contact Dave if you don't have these.

(2) Copy your code (say Particle.st) to the LHO gateway machine.

scp Particle.st username@lhocds.ligo-wa.caltech.edu:/cvs/cds/lho/target/t0sandbox0

(3) Login to lhocds.ligo-wa.caltech.edu

ssh username@lhocds.ligo-wa.caltech.edu

(4) Login to control0

ssh ops@control0

(5) Change directory to the sandbox dir.

cd /cvs/cds/lho/target/t0sandbox0

(6) Prepare for the compilation

setup epics

(7) Edit makefile in the directory. You have to modify a few lines at the end of the file.
There are comments for how to do it in the file.

(8) Compile

make Particle.o

(9) Copy the object file to the 40m target directory

scp Particle.o controls@nodus.ligo.caltech.edu:/cvs/cds/caltech/target/c1psl/

That is it.

965

Thu Sep 18 14:36:54 2008

josephb

Name server and Epics

The problems Rob was experiencing last night was due to part of the setup (or rather testing of the setup) of the new nameserver running on linux1.

The name server was setup on linux1 by doing the following:

1) Installed xorg-x11-xauth via yum which was necessary to get remote x windows to work in linux1

2) Installed xorg-x11-fonts-Type1 in order to get the gui system-config-* programs to work

3) Ran system-config-bind, which created a default set of nameserver files. I unfortunately didn't understand the gui all that well, so I manually edited and added files to these base ones. The base files were generated in /var/named/chroot/etc/ and /var/named/chroot/var/named.

4) I added martian.zone and 113.215.131.in-addr.arpa.zone, named.conf.local, and edited named.conf so it loaded named.conf.local. The martian.zone file acts a forward look up (i.e. give it a name and it returns an IP number like 131.215.113.20). The 113.215.131.in-addr.arpa.zone acts as a reverse look up (i.e. give it an IP number like 131.215.113.20 and it tells you the name). The file named.conf.local merely points to these two files.

Note: One can add or change IP lookup by simply updating these two files. The format should be obvious from the files.

5) I specifically ssh'd in as root to linux1 (using su wasn't sufficient) and then typed "service named start" (without quotes). You can also use "restart" or "stop" instead of "start". This started the name server, giving an [Ok] message.

6) I edited the /etc/resolve.conf file on linux1 so that it pointed to itself first ("nameserver 127.0.0.1" at the top of the file). I also added the line "search martian", which allows one to simply use linux1 as opposed to linux1.martian.

I also edited the /etc/resolve/conf file on linux2, and it seems to resolve names fine.

7) And here is where I broke things. As a test, I moved /etc/hosts to /etc/hosts.bak, and then tested to see if names were being resolved correctly. By using the command host, I determined they were in fact working. I also tested with ssh.

However, something basic didn't like me moving the hosts file. Apparently when a front-end machine needed to reboot, it wouldn't come back up, without any ability to SSH or telnet into them.

With Yoichi and I did quite a bit of debugging this morning and determined the nameserver itself isn't conflicting, merely the lack of the host file was the source of the problem. One theory is that services don't know to go to DNS to resolve host names. I think by modifying the /etc/nsswitch.conf file to include dns as an option for services and other programs, it might work without the host file, however, I'm going to leave that to tomorrow morning which is less likely to interfere with current operations.

As it stands, things are working with the nameserver running and the host file in place.

964

Thu Sep 18 13:05:05 2008

Quote:

The Y-arm doesn't, because one of the digital filters for the Y-arm lock fails to be loaded to the frontend.
I'm working on it now.

Rob told me that the filter "3^2:20^2" is switched on/off dynamically by the front end code for the LSC.
Therefore, the failure to manually load it was not actually a problem.
The Y-arm did not lock just because the alignment was bad.
Now the Y-arm alignment is ok and the arm locks.

963

Thu Sep 18 12:16:01 2008

Quote:

Somehow the EPICS system got hosed tonight. We're pretty much dead in the water till we can get it sorted.

The problem was caused by the installation of a DNS server into linux1 by Joe.
Joe removed /etc/hosts file after running the DNS server (bind). This somehow prevented proper boot of
frontend computers.
Joe and I confirmed that putting back /etc/hosts file resolved the problem.
Right now, the DNS server is also running on linux1.

We are not sure why /etc/hosts file is still necessary. My guess is that the NFS server somehow reads /etc/hosts
when he decides which computer to allow mounting. We will check this later.

Anyway, now the computers are mostly running fine. The X-arm locks.
The Y-arm doesn't, because one of the digital filters for the Y-arm lock fails to be loaded to the frontend.
I'm working on it now.

962

Thu Sep 18 09:30:12 2008

low noise metal film resistors are in

Low noise metal film resistor and capacitor kits from www.garrettelec.com are in.

manufacturer: Dale, 289 values, 25ea, surface mount,1206, 0.1% from 100 to 100K, 1/8 or 1/4W
additional values below 100 ohm and above 100K were purchased from Mouser with the same Dale specification

Ceramic capacitor kit from AVX
67 values, 25ea, surface mount, 1206 from 1.0 pF up

atm2: our new storage cabinet pick and put together by Jenni

Attachment 1: mfr&cap.png

Attachment 2: storcab.png

961

Thu Sep 18 01:14:23 2008

Somehow the EPICS system got hosed tonight. We're pretty much dead in the water till we can get it sorted.

The alignment scripts were not working: the SUS_[opt]_[dof]_COMM CA clients were having consistent network failures.
I figured it might be related to the network work going on recently--I tried rebooting the c1susaux (the EPICS VME
processor in 1Y5 which controls all the vertex angle biases and watchdogs). This machine didn't come back after
multiple attempts at keying the crate and pressing the reset button. All the other cards in the crate are displaying
red FAIL lights. The MEDM screens which show channels from this processor are white. It appears that the default
watchdog switch position is OFF, so the suspensions are not receiving any control signals. I've left the damping loops
off for now. I'm not sure what's going on, as there's no way to plug in a monitor and see why the processor is not coming up.

A bit later, the c1psl also stopped communicating with MEDM, so all the screens with PSL controls are also white. I didn't try
rebooting that one, so all the switches are still in their nominal state.

960

Wed Sep 17 19:13:47 2008

I installed the setup for measuring TEM01/10 on the X end table.
I'm leaving. I shut the laser, flipped down the flipper mirror, disconnected the pzt drive signal from the laser.
For Jenne. The power cable for the Guralps' board is now connected to the PDH box on my instruments cart but you can take it.

959

Wed Sep 17 17:58:35 2008

The cavity sweep is done. The IFO is free now.

958

Wed Sep 17 17:31:24 2008

I calibrated the reference cavity error signal with the following procedure.

(1) I disconnected the PC path BNC cable and locked the RC only using the PZT. To do so, I had to insert a 20dB attenuator
in the RF signal path going to the EOM to reduce the gain of the loop sufficiently.
The normal RF level going to the EOM is 17dBm. With the attenuator it is of course -3dBm.

(2) Using the SR785, I injected signal into the Test-IN2 (a sum-amp after the mixer) of the FSS box and measured the TF from the Ramp-IN to the IN1.
When the Ramp-In switch is off, the Ramp-IN port can be used as a test point connected to the PZT drive signal path just before the output.
There is a RC low-pass filter after the Ramp-IN. IN1 is the direct output from the mixer (before the sum-amp).
The attm1 is the measured transfer function along with the fitting by a first order LPF.
From this measurement, the DC transfer function from the applied voltage on the PZT to the error signal is determined to be 163.6 (V/V).
Since the RF level is lowered by 20dB, the cavity gain in the normal operation mode is 10 times larger (assuming that the modulation depth is
linearly proportional to the applied voltage to the EOM).

(3) According to elog:791, the conversion factor from the voltage on the PZT to the frequency change of the NPRO is 11.172MHz/V. Combining this with the
number obtained above, we get 6.83kHz/V as the calibration factor for converting the error signal (mixer output) to the frequency at DC.
Using 38kHz cavity pole frequency, the calibration factor is plotted as a function of frequency in the attm2.

(4) I took a spectrum of the error signal of the FSS and calibrated it with the obtained calibration factor. See attm3.
The spectrum was measured by SR785. I will measure wide band spectra with an RF analyzer later.

TO DO:
1: Use the actual modulation depth difference to extrapolate the calibration factor obtained by with a low RF signal for the EOM.
The cavity sweep was already done.

2: I assumed 38kHz cavity pole. I will measure the actual cavity pole frequency by cavity ringdown.

3: Measure out-of-the-loop spectrum of the frequency noise using PMC and MC.

Attachment 1: PZTresp.png

Attachment 2: Calibration.png

Attachment 3: FreqNoiseSpectrum.png

957

Wed Sep 17 15:22:31 2008

Quote:

I'm doing a cavity sweep of the RC. Please leave the IFO untouched until the meeting is over.

The measurement is still going on.
I will post an entry when it is done.
Thank you for the patience.

956

Wed Sep 17 13:58:36 2008

ABSL: results from the X arm

Today I repeated the measurement of the FSR on the X arm cavity. The noise in the transmitted power that made the measures fluctuate was much reduced after last night Rob worked on the interferometer. The X arm cavity length is now: (38.4580+/-0.0003)m. I'm attaching a summary of the data I've taken.

I'm now preparing the setup to measure the transverse mode spacing.

Attachment 1: Sept17_XarmFSRmeasurement_report.ps

954

Wed Sep 17 13:43:54 2008

I'm doing a cavity sweep of the RC. Please leave the IFO untouched until the meeting is over.

953

Wed Sep 17 12:58:12 2008

Locking was pretty unsuccessful last night. All the subparts were locked (ARMs, PRM, DRM) and
aligned, but no DRMI+2ARMs locks. The alignment may have drifted significantly by the time I
got around to working the full shebang, however.

We should get back into the habit of clicking the
yellow "Restore last auto-alignment" button when we finish using the interferometer.

952

Wed Sep 17 12:55:28 2008

I measured the mode cleaner length last night:


SR620                Marconi
                     199178070
165981524            165981725
                     132785380
                      33196345

I did the division in Marconi-land, rather than SR620-land.
If someone wants to do this in SR620-land, feel free to do it and post the numbers.

951

Tue Sep 16 16:47:01 2008

pete

Prototype FSS reference installed

After verifying output, I installed the new prototype 21.5 MHz FSS reference (Wenzel crystal oscillator and ZHL-2 amp). Yoichi and I successfully locked the MC, and have left the new reference in place. It's temporarily sitting on the corner of the big black optics table (AP table?).

950

Tue Sep 16 13:04:22 2008

C1:PSL-FSS_RMTEMP alarm level changed

At the request of Steve, I modified the HIGH value of C1:PSL-FSS_RMTEMP from 21.27 to 23.0.
The HIHI is set to 23.50.

949

Tue Sep 16 10:57:45 2008

Particle counter gain

Summary:
Since we reduced the integration time of the particle counter by a factor of 10, we had to add a gain of 10
to the EPICS channels C1:PEM-count_full and C1:PEM-count_half.
I asked Alex to change it and he did it. I forgot to ask him to change the gain of C1:PEM-count_half. So now only
C1:PEM-count_full has x10 gain.

Detail:
C1:PEM-count_full and C1:PEM-count_half are 'Soft Channel' records in the database (Pcount.db). The values are actually
written into the VAL fields directly by an SNL code Particle.o.
Particle.o reads data from the RS-232C port, to which the particle counter is connected. Then it parses the data and put values
into relevant EPICS channels using channel access. This means we cannot change the gain of the channels by modifying the
database file. For example, ASLO field does not have any effect when the value is directly written into the VAL field.
We had to modify the SNL code. Alex modified Particle.st and the new SNL object file is Particle_x10.o sitting in 
/cvs/cds/caltech/target/c1psl/. I modified seq.load so that c1psl loads Particle_x10.o when rebooted.
The source code for the old Particle.st can be found on lesath.ligo.caltech.edu in
/export/CDS/d/epics/apple/Caltech/40mVac/40mVacScipe/dev/src
I asked Alex to disclose the location of the source of the new code.
In order to compile the SNL code into an object file for Motorola CPU by ourselves, we have to call Dave Barker at LHO.

948

Mon Sep 15 14:00:52 2008

The 1Y9 switch is now using a labeled Cat6 cable in cable trays to connect to the main switch in the offices. In addition, the c1asc cable which had been coming out the door was fixed last Friday, and is now labeled, going out the top and connects to the hub in 1Y2.

Note: Do not connect new ethernet cable from switch to switch without disconnecting the old cable to the rest of the network - this tends to make the Ethernet network unhappy with white flashing alarms.

947

Sun Sep 14 19:29:07 2008

Quote:

Today I measured the X arm FSR.
Hi moved the fast PD (Thor Labs PDA255) from the Y end table to the X end table. I had to use a beam splitter to pick out the transmitted beam from the cavity beam and send it to the PD. I did not want to interpose the BS before the TRANS X PD, so I had to move the ETMXT camera to an other place in the table to gain some room. Now the beam that used to go directly to the camera is 50% split and goes also to the PD. I had to put a lens to focus the beam on the PD. The transmitted beam is currently not aligned to the ETMXT camera, I need to fix the alignment of the BS before.
I'm now doing a rough scan of a frequency range 5 times as large as the FSR. I'll post the results soon.

I'm leaving a long measurement running. I should be back later on. If I won't, whoever wanted to use the interferometer has just to shut the NPRO laser in the AP table.

946

Sun Sep 14 18:30:32 2008

Sat Sep 13 23:13:01 2008

abs cavity length experiment

The Y arm was locked all time today but, suddenly, this afternoon it lost lock and since then I've been unable to restore it. I tried unsuccessfully the Restore and the Align scripts several times, although the position of PZT steering mirrors were good (as in the snapshot). I tried things like unlocking/locking the MC, the FSS reference cavity, the PMC but it didn't work. Then I decided to switch to the X arm. Locking it was a piece of cake compare to Y. I'm going to start measuring the FSR of the X arm.

944

Fri Sep 12 11:09:20 2008

abs cavity length experiment

I'm leaving the lab for a couple of hours. I shut the NPRO. The interferometer is available to anyone.

943

Thu Sep 11 23:28:35 2008

alberto

abs cavity length experiment

The MC lost lock for some reason not related to either the FSS or the PMC I'm done with my measurement for tonight. I've shut the NPRO beam before leaving.

942

Thu Sep 11 14:27:53 2008

Peter Kalmus received 40m specific safety training last week.

941

Thu Sep 11 11:29:14 2008

josephb

Final netgear switch in place in 1Y2

I've placed the final (of 4) Netgear prosafe 24 port switch at the very top of 1Y2. At that location, there are no holes left to screw into, so it has 4 rubber feet and is sitting on the top most signal generator. It has been plugged in and connected to the control room hub with a labeled cat6 ethernet cable.

Its IP address has been set to 131.215.113.253, and has the usual controls password if using the "Smart Wizard Discovery Tool" which comes on the Netgear CD. The CD can be found in the Equipment manuals filing cabinet under Netgear. This program unfortunately only runs on a window PC.

To Do: Fix the C1:ASC ethernet connection which is currently coming straight out the front door and connected to the 1X4 switch (again through the front door).

940

Wed Sep 10 19:53:53 2008

abs length experiment

Update of the last days work on the experiment to measure the absolute length of the cavities.

I'm trying to repeat the same measurement that Koji did on the Y arm, before switching to the X arm.

I switched to the PHD universal box for the PLL control between the main laser and the secondary laser. I found a good gain value for the servo and now I can set the frequency of the beat to any value as long as I do it slowly turning the LO frequency from the knob on the Marconi.

I laid down a 50m BNC cable from the Y end to near the BS chamber, where all the abs length equipment is. I matched the two laser beams changing the alignment of the injection steering mirror at the the dark port on the AP table. I then locked the Y arm cavity. When I first tried to do that, the locking script didn't work because the beam was off of the 'sweet spot' where Rob had set it on Monday. It turned out that aborting the script during one of its previous run, had changed the alignment of the PZT steering mirrors. So with Rob I brought them back near the positions as in the snapshot and then saved a new one with the latest values.

Eventually I could set the beat frequency to the FSR of the arm cavity and saw it in transmission at the ETMY.

Now I'm working on the LabView interface for the GPIB data acquisition board.

939

Wed Sep 10 13:28:25 2008

IOO rack lost -24V (recovered)

Summary

Electronics

Alberto, Yoichi

This morning, the MC suddenly started to be unwilling to lock.
I found a large offset in the MC servo board.
It turned out that -24V was not supplied to the Eurocard crate of the IOO rack.
We found two loose cables (violet, that means -24V) around the cross connects with fuses.
We connected them back, and the -24V was back.
The MC locks fine now, and Alberto can continue his arm length experiment.

938

Wed Sep 10 08:57:03 2008

etmy illuminator turned off

The ETMY illuminator was left on yesterday.
I just turned it off.

937

Mon Sep 8 15:38:57 2008

POY RF amp is back to its original task

I temporarily fixed the busted ZHL-32A RF amplifier's power connector by simply soldering a cable to the internal circuit and pulling the cable out of the box through a hole for the power connector.
So I released the POY RF amplifier from the temporary duty of serving the FSS RF distribution and put it back to the original task,
so that Rob can finally re-start working on the lock acquisition.
Now the temporarily fixed ZHL-32A is sitting next to the IOO rack along with the power supply and a Stanford signal generator.
Please be careful not to topple over the setup when you work around there. They will be there until Peter's Wentzel RF box arrives.

936

Mon Sep 8 13:47:35 2008

thermostate setting changed

Quote:

Some one changed the thermostat (old control room ) setting behind 1Y6 from 73 to 79F
It should be in the elog.

In fact, it is. I demand satisfaction for the injury to my elogging reputation!

Thermostate setting was changed from 79F to 77F behind 1Y6

935

Mon Sep 8 10:57:49 2008

the psl and mc are back to normal

IOO

The alarm handler is silent this morning.
This is almost unbelievably pleasant after two mount of harassment.
The MC did not lose lock for three days.

Atm1: the new fss layout
Atm2: PMC with lead brick
Atm3: 3 days plot

Attachment 1: fss.png

Attachment 2: pmcbrick.png

Attachment 3: brick.jpg

934

Fri Sep 5 15:09:50 2008

thermostate setting changed

Quote:

Some one changed the thermostat (old control room ) setting behind 1Y6 from 73 to 79F
It should be in the elog.

In fact, it is. I demand satisfaction for the injury to my elogging reputation!

933

Fri Sep 5 10:36:34 2008

thermostate setting changed

Some one changed the thermostat (old control room ) setting behind 1Y6 from 73 to 79F
It should be in the elog.
The temp changed from freezing 20 to sunny 25 C

932

Fri Sep 5 09:56:14 2008

josephb, Eric

Funny channels, reboots, and ethernet connections

1) Apparently the I00-ICS type channels had gotten into a funny state last night, where they were showing just noise, exactly when Rana changed the accelerometer gains and did major reboots. A power cycle of the c1ioo crate and appropriate restarts fixed this.

2) c1asc looks like it was down all night. When I walked out to look at the terminal, it claimed to be unable to read the input file from the command line I had entered the previous night ( < /cvs/cds/caltech/target/c1asc/startup.cmd). In addition we were unable to telnet in, suggesting an ethernet breakdown and inability to mount the appropriate files. So we have temporarily run a new cat6 cable from the c1asc board to the ITMX prosafe switch (since there's a nice knee high cable tray right there). One last power cycle and we were able to telnet in and get it running.

931

Fri Sep 5 08:34:03 2008

The MC is happy.
The MZ can be locked if you move the slider by hand.

Attachment 1: mzhv.jpg

930

Thu Sep 4 18:02:34 2008

rana, josephb

Accelerometer gains increased by 10

We increased the Accelerometer gains by 10 by modifying the C1ADCU_PEM.ini file.

[C1:PEM-ACC_MC1_X]
chnnum=15014
gain = 10

etc.

The plot shows the before and after for one channel. The ADC noise floor is ~10^-2 counts/rHz in this plot so now
we can do much better noise subtraction.

Attachment 1: acc.png

929

Thu Sep 4 17:44:27 2008

FSS error signal spectrum

Attached is a spectrum of the FSS error signal.
There are a lot of sharp peaks above 100kHz (the UGF of the servo is about 200kHz).
These are mostly harmonics of 77kHz. They are the current suspects of the FSS slew rate saturation.
I remember when I blocked the light to the PD, these peak went away. So these noises must be
in the light. But I checked it a few weeks ago. So I will re-check it later.

One possible source of the lines is a DC-DC converter in the NPRO near the crystal.
We will try to move the converter outside of the box.

Attachment 1: FSS-Error-Spe.png

928

Thu Sep 4 17:17:03 2008

I measured open loop transfer functions of the MC servo.
The UGF was about 30kHz. Since there was some gain margin at higher frequencies, I increased
the input gain of the MC servo board from 19dB to 22dB. Now the UGF is 40kHz and we have more
phase margin (~30deg).

Attachment 1: MC-OPLTF.png

927

Thu Sep 4 17:12:57 2008

I changed the gain settings of the FSS servo.
Now the Common Gain is 5dB (the last night it was 2dB) and the Fast Gain is 12dB (formerly 16dB).
I measured the open loop TF with this setting (the attachment).
I also plotted the OPLTF when CG=2dB, FG=20.5dB. With this setting, the MC looses lock every 30min.

You can see that the OPLTF is smoother with FG=12dB.
When the FG is high, you can see some structure around 250kHz. This structure is reproducible.
This may be some interruption from the fast path to the PC path through a spurious coupling.

Attachment 1: FSS-OPLTFs.png

926

Thu Sep 4 17:03:25 2008

RF oscillator noise comparison

I measured current spectra of the RF signal going to the FSS EOM.
The attachment compares the spectra between a Stanford signal generator and a Marconi.
I borrowed the Marconi from the abs. length measurement experiment temporarily.
The measurement was done using the signal going to the EOM. That means the spectra include
noise contributions from the RF amp., splitter and cables.

21.5MHz peak was not included because that would overload the ADC and I would have to use a large attenuation.
This means the measurement would be totally limited by ADC noise everywhere except for 21.5MHz.

I noticed that with the Marconi, the FSS is a little bit happier, i.e. the PC path is less loaded
(0.9Vrms with Stanford vs. 0.7Vrms with Marconi). But the difference is small.
Probably the contribution from the 77kHz harmonics in the laser light is more significant (see entry #929).
Also the peaks in the Stanford spectrum are not harmonics of 77kHz, which we see in the FSS error signal.

I returned the Marconi after the measurement to let Alberto work on the abs. length measurement.

Attachment 1: RFSpectra.png

925

Thu Sep 4 16:24:56 2008