40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 325 of 344  Not logged in ELOG logo
ID Date Author Type Category Subject
  978   Mon Sep 22 18:54:54 2008 JenneUpdatePSLPMC transfer functions with various brick-on-top configurations
Attached below is a graphical summary of different things that I have tried putting on the PMC to reduce the noise in the loop. The motivation behind these measurements is the current inability here at the 40m to increase the UGF of the PMC. This is part of a broader ISS loop/gain/noise problem that we are having, which is causing Rob's locking efforts to have trouble. (The ISS is next on the to-do list, after we find the best configuration for the PMC, if we are still having problems). Right now, it looks like we are being limited by the gain of the PMC (as mentioned by Rana in elog #968).

Anyhow, Rana and I had noticed that piling heavy things on top of the PMC seemed to reduce the noise. What follows are the transfer functions that I took with the different items on top of the PMC, so that we can compare their effects:
  • Nothing on the PMC (like it used to be)
  • New ~14kg lead brick wrapped in copper foil on top of the PMC
  • A stack of a piece of aluminum, a chunk of steel, and then the lead brick on top of the PMC
  • The lead brick + Rob pushing on top of the PMC

Unfortunately, I need to retake the power spectra in these configurations, but from eye-balling it, as one might expect, pushing on the PMC with a hand added more noise than the nominal nothing-on-PMC configuration.

Also unfortunately, none of these configurations seems to have significantly helped our noise reduction situation. We need a new plan. Rana is currently trying out some other configurations, including just aluminum+brick.

Attached is an open loop gain TF from 100Hz - 100kHz. Below that is a zoomed-in version from 5kHz - 30kHz. As you can see more clearly in the zoomed in version, the notch that Rana put onto the board at ~14.5kHz is working, but we need to make the notch deeper, to catch more of that 14.5kHz peak. We're going to try removing the resistor or reducing it's value in the RLC filter on the board (see elog #906). Also, we see that there is a giant peak at 18.3kHz. This is probably much more limiting to our stability at this point than the 14.5kHz peak. We need to add another filter to take care of this, or find another way to reduce this peak. Note that it is present even when there is no brick on the PMC, so it is not an artifact of the new brick.
Attachment 1: PMC_OLG_100Hz_to_100kHz.png
PMC_OLG_100Hz_to_100kHz.png
Attachment 2: PMC_OLG_5kHz_to_30kHz.png
PMC_OLG_5kHz_to_30kHz.png
  977   Mon Sep 22 16:51:27 2008 YoichiHowToComputersNetwork GPIB
I was able to make the wireless connected GPIB interface work with SR785.
Now you can download data from SR785 through network, wherever it is located.
Say good bye to floppy disks.

I wrote an installation note in the wiki.
http://lhocds.ligo-wa.caltech.edu:8000/40m/GPIB

I wrote a new script called "netgpibdata.py" which works similarly as "getgpibdata.py".
It is in the 40m svn. Instructions on how to use it is on the above mentioned wiki page.
  976   Mon Sep 22 15:02:45 2008 ranaFrogsTreasureMantis found outside the 40m door at night
Attachment 1: mantis.JPG
mantis.JPG
  975   Mon Sep 22 12:06:58 2008 robUpdateSUSITMY UL OSEM


Last week I found the ITMY UL OSEM dead. I went around and checked the connections on the various flat ribbon cables
in the suspension control chain; pushing hard on the rack end of the long cable that goes from the sus electronics rack to the
ITMY sat amplifier fixed the problem. It's been fine since then.

NB: A visual inspection of the cable connection would not have revealed a problem. You just can't trust those flat
ribbon connectors with the hook latches.
  974   Fri Sep 19 11:48:14 2008 steveUpdateComputers 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
P1020934.jpg
  973   Fri Sep 19 11:21:45 2008 josephbConfigurationComputersNameserver 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 YoichiUpdateComputerssvn is old
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>
Frown
  971   Fri Sep 19 08:09:55 2008 steveUpdatePSLpsl HEPAs turned on
I have just turned on the PSL HEPA filters at 60% operational speed.
  970   Fri Sep 19 01:55:41 2008 ranaSummarySUSSUS 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
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 ranaUpdateComputerssvn is old
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>
Frown
  968   Fri Sep 19 00:06:54 2008 ranaUpdateIOOMC_F: Too much frequency noise around 100 Hz
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
mcf.png
  967   Thu Sep 18 23:31:26 2008 ranaUpdatePSLISS: 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
FIRE_BLOWER.jpg
  966   Thu Sep 18 18:38:14 2008 YoichiHowToComputersHow 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 josephbConfigurationComputersName 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 YoichiUpdateComputersEPICS BACK

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 YoichiUpdateComputersEPICS BACK

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 steveUpdateGenerallow 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
mfr&cap.png
Attachment 2: storcab.png
storcab.png
  961   Thu Sep 18 01:14:23 2008 robSummaryComputersEPICS BAD

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 AlbertoUpdateGeneralABSL: status
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 YoichiConfigurationPSLRC sweep going on
The cavity sweep is done. The IFO is free now.
  958   Wed Sep 17 17:31:24 2008 YoichiUpdatePSLFSS calibration
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
PZTresp.png
Attachment 2: Calibration.png
Calibration.png
Attachment 3: FreqNoiseSpectrum.png
FreqNoiseSpectrum.png
  957   Wed Sep 17 15:22:31 2008 YoichiConfigurationPSLRC sweep going on

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 AlbertoUpdateGeneralABSL: 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
Sept17_XarmFSRmeasurement_report.ps
  954   Wed Sep 17 13:43:54 2008 YoichiConfigurationPSLRC sweep going on
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 robUpdateLockingbad

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 robConfigurationIOOMC length
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 peteConfigurationPSLPrototype 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 YoichiConfigurationPEMC1: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 YoichiConfigurationPEMParticle 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 josephbConfigurationComputers1Y9 Hub and C1asc
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 AlbertoUpdateGeneralABSL: measured X arm

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 AlbertoUpdateGeneralABSL: measured X arm
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.
  945   Sat Sep 13 23:13:01 2008 AlbertoUpdateGeneralabs 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 AlbertoUpdateGeneralabs 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 albertoUpdateGeneralabs 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 steveBureaucracySAFETYsafety training
Peter Kalmus received 40m specific safety training last week.
  941   Thu Sep 11 11:29:14 2008 josephbConfigurationComputersFinal 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 AlbertoUpdateGeneralabs 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 YoichiSummaryElectronicsIOO rack lost -24V (recovered)
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 steveUpdateGeneraletmy illuminator turned off
The ETMY illuminator was left on yesterday.
I just turned it off.
  937   Mon Sep 8 15:38:57 2008 YoichiConfigurationPSLPOY 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 steveUpdatePEMthermostate setting changed

Quote:

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 steveUpdateIOOthe psl and mc are back to normal
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
fss.png
Attachment 2: pmcbrick.png
pmcbrick.png
Attachment 3: brick.jpg
brick.jpg
  934   Fri Sep 5 15:09:50 2008 ranaUpdatePEMthermostate 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 steveUpdatePEMthermostate 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, EricConfigurationComputersFunny 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 steveUpdatePSLMZ locked
The MC is happy.
The MZ can be locked if you move the slider by hand.
Attachment 1: mzhv.jpg
mzhv.jpg
  930   Thu Sep 4 18:02:34 2008 rana, josephbConfigurationPEMAccelerometer 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
acc.png
  929   Thu Sep 4 17:44:27 2008 YoichiUpdatePSLFSS 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
FSS-Error-Spe.png
  928   Thu Sep 4 17:17:03 2008 YoichiUpdateIOOMC open loop TF
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
MC-OPLTF.png
ELOG V3.1.3-