40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 276 of 339  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  784   Sat Aug 2 16:05:38 2008 ranaConfigurationComputer Scripts / ProgramsmDV update
I did an svn update on our mDV directory. Justin has improved it so that the NDS client binaries
are included for solaris, mac, linux32, and linux64. Now you can just use this version without
having to worry about any path definitions.
  785   Sat Aug 2 18:37:41 2008 ranaUpdateSUSOSEM Spectra

The attached PDF file is from the .xml files that I found from 7/30. Looks like someone
took some free swinging data and even made nice plots but didn't elog it. Raspberry for you.
The data files are saved in Templates/FreeSwinging/{ETMX,ETMY,etc.}/2008_07_30.xml

The top left plot on the multi-page file all have the same scale so you can see what's happened.
The peaks should all be as measured by Busby in Sep '06
but instead they are as you see here.
  786   Sun Aug 3 20:53:54 2008 ranaConfigurationPEMGuralp
We got our repaired Guralp back in the mail from England (s/n T4157). I plugged it in
to Ben's 3-Guralp breakout box (http://www.ligo.caltech.edu/docs/D/D060506-00.pdf) and
verified that it is not oscillating (like it was before) and that it responds to us
jumping around.

The breakout box has way too much gain, however. The ADC wants +/-2 V and the box puts out
~5 Vpk in the night time.

Looking at the schematic, it has a DC gain of 200 and a double whitener (50,50:10,10) so that
there's a gain of 5000 from 50-2000 Hz. The Guralp has a transduction gain of 800 V/(m/s) and
so we can just calculate what the frequency dependent noise figure of the box has to be. I've
pulled it out, put it on the bench, and started reworking it. I am looking for a soldering/
testing volunteer.

The other kink in the problem is that since we want to use this for the adaptive noise cancellation,
we have to make the noise floor of the readout better than the ambient noise by the same factor
with which we want to cancel the noise.
  808   Thu Aug 7 10:27:59 2008 ranaUpdateSUSFree swinging OSEM spectra
Sometimes we see extra peaks in the OSEM spectra coming from a beat between the regular eigenmodes.
This probably comes from the OSEM shadow sensor not being entirely linear - the nonlinearity is
greatly increased if the magnet is not perfectly centered in the LED beam. So the beats are
probably there at some level in all of them; usually below the noise.
  812   Fri Aug 8 09:54:10 2008 ranaUpdateCamerasNew code + gstreamer allows for easy saving and compression of images

Quote:
Modified the CamSnap code to output the image data stream to standard out. This can then be piped into a gstreamer plugin and then be used


Didn't work; Prosilica has only 1 "l". Even so, sshing from op440m to mafalda, I got this:
mafalda:SnapCode>CamSnap -F 'Mono8' -c 44058 -E 5000 -X 0 -Y 0 -H 480 -W 752 -l 0 -m 300 | gst-launch-0.10 fdsrc fd=0 blocksize=360960 ! video/x-raw
-gray, height=480, width=752, bpp=8,depth=8,framerate=30/1 ! ffmpegcolorspace ! theoraenc ! oggmux ! filesink location="./testVideo.ogm"
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...

** (gst-launch-0.10:27121): WARNING **: Size 60 is not a multiple of unit size 360960
Caught SIGSEGV accessing address 0x487c
ERROR: from element /pipeline0/ffmpegcsp0: subclass did not specify output size
Additional debug info:
gstbasetransform.c(1495): gst_base_transform_handle_buffer (): /pipeline0/ffmpegcsp0:
subclass did not specify output size
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7deddae in __lll_mutex_lock_wait ()
#2  0xb7de9aac in _L_mutex_lock_51 () from /lib/tls/i686/cmov/libpthread.so.0
#3  0xb7de949d in pthread_mutex_lock ()
#4  0xb7e452e0 in g_static_rec_mutex_lock () from /usr/lib/libglib-2.0.so.0
#5  0xb7f1fa08 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#6  0x080c1220 in ?? ()
#7  0x00000001 in ?? ()
#8  0x0809586c in ?? ()
#9  0x00000001 in ?? ()
#10 0x08095868 in ?? ()
#11 0xb7f7a2a8 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#12 0xb7e8da80 in ?? () from /usr/lib/libglib-2.0.so.0
#13 0xb7f7a2a8 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#14 0xb7f7a2a8 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#15 0x00000000 in ?? ()
Spinning.  Please run 'gdb gst-launch 27121' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
Caught interrupt -- 
  819   Sun Aug 10 16:57:02 2008 ranaSummaryPhotosPhotos from Vent 8/4 - 8/8
http://www.ligo.caltech.edu/~rana/40m/VentAug08/

I've added the D40 pictures from last week to this web page. I have done some cropping and
rotating to make things look better.

On page 3, there are some over head shots of the Michelson area so that one can use screw holes
to judge what the spacing between the suspensions is and also possibly the cavity lengths. Lets
also remember to measure the ITM-BS distance accurately using a tape measure or ruler while we
have the thing open.
  820   Mon Aug 11 00:58:31 2008 ranaUpdatePEM2 years of temperature trend
The PSL RMTEMP alarmed again because it says the room temperature is 19.5 C. Steve said in
an earlier log entry that this is a false alarm but he didn't say why he thought so...

I say that either the calibration of the RMTEMP channel has drifted, the setpoint of the HVAC
has shifted, or there's a drift in the RMTEMP channel. I don't know what electronics exactly
are used for this channel so not sure if its susceptible to so much drift.

However, since the Dust Monitor (count_temp) shows a similar temperature decline in the
last two years I am inclined to blame the HVAC system.

The attached plot shows 2 years of hour-mean trend.
  821   Mon Aug 11 09:39:29 2008 ranaUpdatePEM2 years of temperature trend
Steve and I went around and inspected and then adjusted the thermostats and humidostats.

All the thermostats were set at 70F in 2005 by Steve. We adjusted the ones on the arms up to 72F
and set the one on the wall west of the framebuilder up to 74F (this area was consistently colder
than all the others and so we're over-correcting intentionally).
  867   Thu Aug 21 17:55:14 2008 ranaHowToIOOMC WFS DC Offsets
I ran the McWFS_dc_offsets script to trim out the DC offsets on the MC WFS DC signals.

Rob says "who cares?"
  868   Thu Aug 21 18:13:24 2008 ranaUpdateIOOMC WFS Control signals not responsible for lock losses
This is a 4 hour, second-trend of the MC WFS error and control signals.

There is no sign that the MC loses lock because of feedback signal saturations.
  881   Mon Aug 25 15:50:18 2008 ranaSummaryPEMRanger SS-1
The manual for the Ranger SS-1 seismometer can be found on line here:
ftp://ftp.kmi.com/pub/software_manuals/300190/300190nc.pdf

and now in our 40m PEM Wiki page:
Ranger_SS-1

To calibrate it, we use the formula from the manual:
                 R_x
G_L = G_0 * ------------   =  149 +/- 3 V/(m/s)
             R_x  +  R_c

where
G_0 = 340 V/(m/s)    (generator constant)
R_x = 4300 Ohms      (external damping resistor in Pomona box)
R_c = 5500 Ohms      (internal coil resistance)

Then we have a gain of 200 in the SR560 so that gets us to ~30000 V/(m/s).

And then there's a DAQ conversion factor of the usual 2^16 cts / 4 V.

so the calibration constant is

G = 488 counts / (micron/sec)

in the ~1-50 Hz band
  883   Mon Aug 25 21:15:23 2008 ranaConfigurationLSCaux NPRO off
Looks like no one has used the Lightwave NPRO on the AS table after Koji left, so I turned it off so that it can rest until Alberto does the X-arm measurements.
  884   Tue Aug 26 09:04:59 2008 ranaConfigurationPSLPMC Servo Board: Out for Repairs
I've started modifying our PMC board to bring it up to the 21st century - leave the screen alone or else you might zap something.
  888   Tue Aug 26 18:19:16 2008 ranaOmnistructureElectronicsResistor Noise at the 40m
As Stefan points out in his recent ISS ilog entries at LLO, Daniel Sigg recently wrote a
recommendation memo on resistor and capacitor
choices: T070016.

While working on the PMC I have had to use leaded resistors and wondered about the noise. As it turns
out we have the RN series of 1/4 W resistors from Stackpole Electronics. The RN series are
metal film resistors (datasheet attached); metal film is what Sigg recommends for lowest flicker
noise.

So we are OK for using the Stackpole 1/4 W leaded resistors in low noise circuits.
  893   Thu Aug 28 18:56:14 2008 ranaConfigurationPSLbeam block distorted
There was a beam block after the Mach Zender. Who or what put this there?

The going to the MC now looks distorted as if someone has left something funny in the beam or maybe the new PMC has started to degrade??

Use the ELOG people...its good for you.
  903   Fri Aug 29 17:39:25 2008 ranaConfigurationPSLPMC: ADC Channels
The attached PNG shows the PMC error and controls signals with no calibration.

There are 3 states:

DARK - RF input disabled & output blanked. This should be a measure of the ADC noise

(-10 dB) - This is with the gain slider down at 5 dB instead of the nominal 15 dB.

Looks like the Generic DAQ board whitening is good enough for these signal levels above ~1 Hz.

From the low and high gain spectra it also looks like the UGF is ~500 Hz with the gain at 15 dB.
  904   Fri Aug 29 18:24:48 2008 ranaHowToPSLPMC: PZT Calibration
I calibrated the PMC PZT at DC by using 'trianglewave' to drive the DC offset slider
and reading back PMC_PZT and PMC_TRANSPD_F (both are DC coupled DAQ channels).

The attached PDF illustrates the method: look at the voltage required to span 1 FSR and then divide.
PMC_cal (m/V) = (1064 nm)/2 / V_FSR
The calibration for our PZT is therefore 10.4 nm/V.
The full scale (0-300 V) range is 3.1 microns.

From Jenne's elog entry we know that the series resistor to the PZT is 63.6 kOhms. The PZT is labeled as
having a capacitance of 279 nF. So the PMC drive's pole frequency is 1/2/pi/63.6e3/279e-9 = 9 Hz +/- 0.5 Hz.
The cable capacitance is ~20 pF/foot so its not significant for this.

The template file is Templates/PMC-PZTcal.xml.

Using the above calibrations, also plot the calibrated PMC ERR and PZT spectra.
  906   Sat Aug 30 13:28:01 2008 ranaConfigurationPSLPMC: List of changes
This is a list of changes made to the PMC board while we had it out for modifying the notch:

  • LC-LC 4th order low pass filter
  • Replace the AD797 (U2) with an OP27. AD797's are bad - do not use them anywhere for any reason. The OP27 is slower and has a 3x worse input noise but doesn't compromise the bandwidth or noise performance of the PMC by any significant amount. The rule is: use OP27 everywhere unless you have a very good reason why not.
  • There is no 'H1' jumper on board. R9 is 90.9 Ohms and R2=900 Ohms so that the U2 stage has a gain of 10.
  • Cut a trace and inserted a 500 Ohm resistor between U2-pin6 and U5A-pin2 (the AD602). The AD602 has a 100 Ohm input impedance which cannot be driven without limiting by the AD797 or the OP27. The 500 Ohm resistor makes it a driveable load for low level signals which is all that should be there since its the error point of the servo. it also becomes a 6:1 voltage divider. Since the AD602 has a fixed output voltage noise of 100 nV/rHz, this will limit the noise performance if the VGA gain is less than 20 dB, but whatever.
  • R11 7.87k -> 1.74k, R12 = 78.7k -> 700k. This increases the high frequency gain of that stage by 7.87/1.74 = 4.5 and lowers the low frequency pole from 2 to 0.2 Hz to give the PMC some more staying power at DC. The loop shape is now 1/f^2 in the 9-480 Hz band and so the phase dips enough to make it almost conditionally stable, but not quite.
  • C26 changed from ??? + a 30 pF trim cap into a fixed NNN pF cap to set the notch frequency for the 14.5 kHz body mode that we measured. Once our brick configuration is more settled we can increase the Q of this notch from small to big.
  • Grounded pin 5 of U14 & U15 (AD620). These have sometimes been used as "differential" drivers in LIGO by connecting this reference voltage pin to the remote ground of the next board. This has always lead to insidious oscillation and noise. This beauty also has an output noise of 100 nV/rHz. Just never use this chip if you can help it; we can make true differential drivers - we have the technology.

Of course, we didn't have a current version of a schematic sitting around so I printed out a Rev E schematic and marked it up with red pen. I'll post pictures later and put the schematic into the PSL schematics notebook. Would be useful to take the old schematic and update it in Acrobat so that we have something electronic.
  907   Mon Sep 1 04:34:00 2008 ranaUpdatePSLFSS loop transfer functions
I started from 6th item in Yoichi's todo list.

1) Increased the setpoint of the thermostat next to the framebuilder from 73F to 79F. Its freezing over there
in the room with the drill press. Steve's illegal mercury thermometer is reading 19 C.


2) Looked the RFPD's output spectrum using the 20 dB coupled output from the coupler that's in-line.
The first attached PDF file (n.pdf) has several plots:
page 1: 0-500 MHz anomolous peaks at 138 & 181 MHz but nothing too crazy
page 2: 0-100 MHz 80 MHz peak is RF pickup from the VCO Driver - not on the light
page 3: 10-30 MHz totally nuts
page 4: 18-25 MHz that's just wrong

The RF spectrum should only have some action around 21.5 MHz and a little peak at 2x 21.5 MHz. All that extra
junk means that something is broken!


3) To see if I could rid of any of the 80 MHz signal or any of that other trash from 18-25 MHz, I wound the RF cable
around a large toroidal ferrite core. This should have given us many uH of inductance for any signals common to
both the center and shield of the cable with no effect on the differential RF signals. There was no effect.


4) Next went to look at the 21.5 MHz Crystal Oscillator Reference card (D980353...I bet you can't figure out how
this one works). These have the Mini-Circuits SMA 30 MHz low pass (SLP-30) filters on both the LO and EOM outputs.

FSSLO.PNG shows the waveform after 20 dB attenuation going into a scope terminated with 50 Ohms.
FSSLO-Spec.png shows the spectrum of this signal - its pretty distorted. Here's the levels
   f (MHz) |  before filter (dBm) | after filter (dBm)
   ---------------------------------------------------
     21.5  |       -12.8               -13.1       
     43            -24                 -46
     64.5          -50               < -80
     86            -64               < -80

This would be OK after the filter, but the level is very low. Only 7dBm (accounting for my 20 dB att) !!
The FSS uses a JMS-1H mixer which needs, as everyone knows, a +17 dBm LO signal. Que lastima.

There seems to be something wrong already, but wait...


5) PC25.PNG shows the output signal going to the EOM from 0 - 25 MHz. The step that's visible there at
around 10 MHz is just something inherent to the analyzer (??). But see all that crap there down below
5 MHz ? That is NOT supposed to be there.

pc.pdf shows on the first page the comparison in EOM drive with 2 different slider values on the
RF AM adjust screen for the FSS. But page 2 is the punchline of this long entry: There is a bunch of
excess junk on the drive signal going to the FSS's phase modulator.
The FSS is then trying to handle
this extra frequency noise and getting into trouble.

We have to fix this board. I have also ordered a few SBP-21.4 from mini-circuits (SMA bandpass around 21.4 MHz)
just in case. Another option is to just replace this thing with a Marconi and an RF amp.






  909   Tue Sep 2 07:58:34 2008 ranaSummaryPSLFSS & PMC LO trends for 2 years
The attached plot is a 2 year minute trend of the EPICS readback of the PMC & FSS LO Monitors (FSS_LODET & PMC_LODET).
Clearly the FSS LO has been dying for at least 2 years. The step up from 10 months
ago is probably when Rob removed a 3dB attenuator from in front of the box.
  918   Thu Sep 4 00:38:14 2008 ranaUpdatePSLc1iovme power cycled
Entry 663 has a plot of this using the PSL/FSS/SLOWscan script. It shows that the SB's were ~8x smaller than the carrier.
P_carrier   J_0(Gamma)^2 
--------- = ------------
P_SB        J_1(Gamma)^2

Which I guess we have to solve numerically for large Gamma?
  925   Thu Sep 4 16:24:56 2008 ranaConfigurationComputersAttempt to increase gain for C1:PSL-ISS_INMONPD_F via 110B

Quote:
We were attempting to increase the gain on the channel C1:PSL-ISS_INMONPD_F in preparation to do a scan of the PMC at very low input power.

According to the Wikipedia, certain esoteric mathematical
operations lead to the result that 4000 x 10 > 32768.
  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!
  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.
  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!
  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
  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.
  976   Mon Sep 22 15:02:45 2008 ranaFrogsTreasureMantis found outside the 40m door at night
  980   Mon Sep 22 21:30:06 2008 ranaConfigurationPSLbad FSS
The MC refl power was going up and the FSS PC drive was so large that I had to turn up the FSS
common gain from 1.5 dB to 10.5 dB to get it to be better. Attached are the before (REF) and
after plots of frequency noise. Is the FSS gain really supposed to be 1.5 dB?? How did we gain
so many dB's of optical gain? Is there a loop measurement from after Peter's oscillator change?
  981   Mon Sep 22 21:54:05 2008 ranaUpdateASSNew Wiener result with x10 gain in ACC
The 2 attached PDF files show the performance of the Wiener filter code on 2 hours of data
with a 4000 tap filter on 64 Hz data. All 6 accelerometers around the MC and the Ranger seismometer
were used.

I attribute the improved performance in the 3-10 Hz band to the better SNR of the ACC channels. To
do better below 1 Hz we need the Guralps.
  982   Mon Sep 22 22:24:19 2008 ranaConfigurationPSLbad FSS

Quote:
The MC refl power was going up and the FSS PC drive was so large that I had to turn up the FSS...


Looks like I bumped the PS for the 21.5 MHz test setup and changed the supply voltage of the amplifier
from +24 to +38 V. This made the amplifier go hot after a few hours and the output eventually dropped.

Yoichi and I walked out there now and it was too hot to touch. We turned it off and put it on a heat
sink to make it chill out and it came back after a few minutes. We have set the input to the amp to
be -7 dBm instead of -8 dBm after deciding that we should take into account the 1 dB loss in the cable
run and deliver a real +17 dBm to the mixer.

The right way is to calibrated the LO mon of the FSS.
  988   Wed Sep 24 19:13:06 2008 ranaConfigurationComputer Scripts / Programsupdatedb & locate: megatron & rosalba
I ran updatedb as root today on megatron and rosalba just before the meeting.
It finished at ~14:10 on both machines so that's ~20 minutes total.

The default updatedb.conf for these guys also seems to be set up right so that
it is indexing the NFS mount (/cvs/cds/) so that's good. Next, someone needs to
add the updatedb command to the daily cron for each of these guys (5 AM) and
add this to the wiki page on how we set up new computers.

I also found that the root passwd on Megatron was different from all of the other
machines, indicating that perhaps megatron was trying to free himself. I have put
down that rebellion viciously
:D and he's now toeing the line.
  989   Thu Sep 25 02:35:21 2008 ranaSummaryPSLFAST is moving alot
It looks like the FAST signal has started moving a lot - this is partly what inspired us to tune the SLOW loop.

Some of the spiking events happen when people go on the table or the MC loses lock. But at other times it just
spikes for no apparent reason. You can also see from the first plot (9 day 10-minute trend) that there is no
great change in DTEC so we shouldn't be worried about clogging in the NPRO head.

The second plot is a 1 day minute-trend.
  990   Thu Sep 25 03:12:13 2008 ranaSummaryComputersconlog and linux1
It would be nice to have conlog from outside. Right now its on linux1 and so its unavailable. To
test it for speed we ran the command line conlog on linux1, linux2, and nodus.

It was slightly faster on nodus than linux1, implying that its not a network speed issue. It was
phenomenally slower on linux2.

I used the command '/sbin/lspci -vvv' to check what network cards are installed where. As it turns
out, linux2 has a GigE card, but linux1, our NFS server, has only a 100 Mbit card:
01:08.0 Ethernet controller: Intel Corporation 82562EZ 10/100 Ethernet Controller (rev 01)
        Subsystem: Intel Corporation Unknown device 304a
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 209
        Region 0: Memory at ff8ff000 (32-bit, non-prefetchable) [size=4K]
        Region 1: I/O ports at bc00 [size=64]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-

We (Joe) need to buy a GigE card for linux1 and to also set up conlog and conlogger to run on Nodus.
  994   Thu Sep 25 17:14:31 2008 ranaConfigurationGeneralnew sitemap
  999   Fri Sep 26 16:13:57 2008 ranaUpdateIOOMC_L / MC_F crossover
We were trying to understand why the FAST_F signal had such large excursions (~1V ~ 5 MHz).

Some of this is due to the seismic noise and the resulting MC_F signals. Increasing the MCL
gain reduces it somewhat. But as you can see from the attached loop gain measurement, the
crossover is a healthy 90 Hz with the MCL digital gain = 1. But what's going on in the MC loop
in the 10-20 Hz band? That looks like bad news.

Then I noticed that changing the ISS gain slider puts a large step (~1V) into the FAST. My guess
is that the board has large DC offsets and also much of the switching supply noise. Not sure why
this would be worse than before though.

To prevent large noise in the FAST, I've changed the mcup script to set this gain to -5 dB. Our
intensity noise is now presumably 10-15 dB worse than the nominal good levels we had a year ago.
Needs investigation.
  1001   Fri Sep 26 19:08:43 2008 ranaConfigurationPSLRefcav Trans: PD + Camera + Dumps
I went out to improve the Refcav trans path.

I removed all ND filters to get rid of the fringing.

I removed the anodized Al dump that was there. Black anodized Aluminum dumps are forbidden for use as
dumps in any low phase noise setup (such as our frequency stabilization cavity). The scatter was going
directly back into the cavity and making noise. For now its undumped, but Steve will find the
reflections and dump them on unblemished razor blade dumps mounted stiffly.

I will post a photo of the new setup later - the new setup is sketched on the control room markerboard.

The transPD level is now 8 V, up from its previous 3-4 V. We will probably have to also put a lens
in front of it to get the beam size down.
  1003   Mon Sep 29 01:19:40 2008 ranaSummaryPSLLaser chiller running a little hot
I looked at it some last night and my suspicion was the ISS. Whenever the ISS switch came on the FAST got a kick.

We should try to disable the MC locking and ISS and see if the FSS/PMC/MZ are stable this way. If so this may be
a problem with the ISS / Current Shunt.
  1011   Wed Oct 1 00:24:54 2008 ranaUpdateLockinglast night
I had mistakenly left the MC boost off during my FAST investigations. The script is now restored.

The ISS is still saturating with gains higher than -5 dB. We need to request a PeterK / Stefan consult in the morning.

Also found the MZ gain down at -10 dB around midnight - need an alarm on that value.
  1012   Wed Oct 1 02:10:03 2008 ranaUpdateIOOMZ is going bad
Here's a 2 day trend of the MZ. You can see that there is something bad with ERR - it should really be going to zero.

Also LODET is dead. We need to rejuvinate LODET somehow.

The next plot is a 90 day hour-trend of the same signals. You can see that LODET came back to us between
September 10 and 19 ??? I looked at a 4 year trend and it seems that this signal has always been zero
(nice use of disk space) except for a few days in Nov of 06 and then whatever happend on Sep 10.
  1013   Wed Oct 1 02:47:53 2008 ranaUpdatePSLPSL ERR & LODET: Too much offset
Looks like there is an anomolous mixer offset correlated with the increase in the LO level. This may be leading to crazy offset locking in the FSS and too much coupling from ISS to FSS.
  1021   Thu Oct 2 18:56:19 2008 ranaSummarySUSResistivity of Suspension Wire
Bob and Steve measured the resistance of the suspension wire today:
OD     = 0.0036" =  0.091 mm
Length = 46"     = 1168.4 mm
Resistance     =   33.3 Ohms

resistivity = R * pi * (OD/2)^2
              ----------------- = 1.85e-7 Ohm-meters
                  Length 


This was a batch of California Fine Wire from 2001 (same as used at LHO and LLO).

By comparison the standard tabulated resistivity for steels is (http://hypertextbook.com/facts/2006/UmranUgur.shtml):
                  resistivity (Ohm-meter x 10^-7)
-------------     ----------------
304 Stainless       7.2
316 Stainless       7.4
Cast Steel          1.6

This is all to see whether or not the 60 Hz fields produce forces on the suspension wires via coupling with the Earth's DC field.

TBD
  1049   Wed Oct 15 17:40:50 2008 ranaUpdatePSLPMC Offset adjusted
I set the PMC servo input offset: closed the MOPA shutter, zeroed the mixer output with the offset slider,
relocked everything, and set the nominal to the new value of -6 V.
  1064   Tue Oct 21 17:52:30 2008 ranaSummaryPSLFSS Photo: early October
This is a photo of the FSS board before Yoichi did his surgery - it was taken with the D40 in macro mode, sitting on the big Gorilla pod.
  1088   Fri Oct 24 20:54:41 2008 ranaConfigurationComputerslinux2
I have removed linux2 and its cables from the control room and put it into 1Y3 along with op340m.

When Joe next comes in we can ask him to Cat6 it to the rest of the world, although it already
seems to me that the CDS hub/switch next Alberto's desk is too full and that we need to purchase
a 48 port device for there.
  1091   Sun Oct 26 21:02:18 2008 ranaUpdateComputer Scripts / ProgramsSVN medm problem
As we've seen in the past a few times, there's something wrong with the files in the trunk/medm area.
I get the following error message when doing a fresh checkout:
A    c1/lsc/help/C1LSC_LA_SET.txt
svn: In directory 'c1/lsc/help'
svn: Can't copy 'c1/lsc/help/.svn/tmp/text-base/C1LSC_RFadjust.txt.svn-base' to 'c1/lsc/help/.svn/tmp/C1LSC_RFadjust.txt.tmp.tmp': No such file or directory
It looks like that there are some .svn files which have been checked in as if they're some kind of source code instead of just maintenance files.
We probably have to go through and clean this out and then remove these excess files somehow.
  1104   Sun Nov 2 20:21:58 2008 ranaConfigurationloreHP 5550dtn (Grazia) set up on allegra
I set up printing to grazia from allegra. The CUPS interface was not as straightforward as Tobin had made it seem in the Wiki. I had to type in the IP address and port number by hand.

The steps (AFAIR):
1) Goto http://localhost:631/
2) Click on "Add Printer"
3) Choose HP JetDirect
4) Use the correct address (socket://131.215.115.220:9100)
5) Choose HP and the 5550 postscript driver as the options
6) Try to only print useful stuff and not kill too many trees.
  1105   Sun Nov 2 20:44:58 2008 ranaUpdateASSWiener Filter performance over 5 hours
I took one 2 hour stretch of data to calculate a MISO Wiener filter to subtract the Ranger seismometer
and the 6 Wilcoxon accelerometers from the IOO-MC_L channel. I then used that static filter to calculate
the residual of the subtraction in 10 minute increments for 5 hours. The filter was calculated based upon
the first 2 hours of the stretch.

The MC lock stretch is from Oct 31 03:00 UTC (I think that we are -8 hours from UTC, but the DST confounds me).
So its from this past Thursday night.

I wrote a script (/users/rana/mat/wiener/mcl_comp.m) which takes the static filter and does a bunch of loops
of subtraction to get a residual power spectrum for each 10 minute interval.

In the attached PNG, you can see the result. The legend is in units of minutes from the initial t0 = 03:00 UTC.

BLACK-DASHED -- MCL spectrum before subtraction

I have also used dashed lines for some of the other traces where there is an excess above the unsubtracted data.
Other than those few times, the rest are all basically the same; this indicates that we can do fine with a very
slow adaptation time for the feed-forward filters
-- a few hours of a time constant is not so bad.

After making the plot I noticed that the Ranger signal was totally railed and junky during this time.
This probably explains the terrible performance below 1 Hz (where are those Guralps?)

The second attached image is the same but in spectrogram form.
  1106   Sun Nov 2 21:37:22 2008 ranaUpdatePEMRanger recovery
The ranger signal has been bad since around 11 AM on Oct 25 (last Saturday). There are no elog
entries from that day, but I am quite sure that someone must have been working around the PSL
rack area.

It looks like what happened is that someone moved the chair with the monitor on it and/or the wooden
stool next to it. That put tension on the cable connecting the SR560 and the seismometer. The SR560
connector now seems loose and I think probably the cable ground wasn't connected. I swapped the
cable over to the "B" side of the SR560 and the ranger signal is now reasonable (very small offset
and normal seismic signal).

Please be careful when working around there. Everyone always says "I didn't do anything" or "it doesn't
effect anything".

We need to clean up the cabling around there in addition to running a new power cable for the RF amplifier
on the POY table.


I have also reduced its sample rate from 2048 to 512 Hz. The data are OK after 909640694.

I also increased the sample rate of AS_MIC from 2048 to 16384 Hz but that one seems to be broken
---->> the microphone seems to be either disconnected or broken.
  1111   Mon Nov 3 22:35:40 2008 ranaUpdateASSWiener Filter performance over 5 hours
To speed up the Wiener filter work I defined a 256 Hz version of the original 16kHz IOO-MC_L signal. The
attached plots show that the FE decimation code works correctly in handling the anti-aliasing and
downsampling as expected.
ELOG V3.1.3-