40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 277 of 339  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  982   Mon Sep 22 22:24:19 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...

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.
Attachment 1: Untitled.png
Attachment 2: Untitled.png
  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
Attachment 1: vegemite.png
  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.
Attachment 1: mcx.png
  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.
Attachment 1: Untitled.png
Attachment 2: Untitled.png
  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.
Attachment 1: Untitled.png
  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

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.

  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.
Attachment 1: fss.jpg
  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://
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.
Attachment 1: f.png
Attachment 2: f1.png
  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.
Attachment 1: DAQ.pdf
  1112   Tue Nov 4 00:47:53 2008 ranaUpdateASSWiener Filter performance over 5 hours
Same as before, but now with a working Ranger seismometer.

In the spectrogram, the color axis is now in dB. This is a whitened spectrogram, so 0 dB corresponds to
the average (median) subtraction. The color scale is adjusted so that the large transients are saturated
since they're not interesting; from the DV trend its some kind of huge glitch in the middle of the
night that saturated the MC1 accelerometers only (maybe a pump?).

The attached trend shows the 5 hours used in the analysis.
Attachment 1: f2.png
Attachment 2: f.png
  1113   Tue Nov 4 01:03:01 2008 ranaSummaryPEMperiodic thump noise in MC1_ACC
There seems to be a periodic thump seen by the MC1 Accelerometers as well as the surrounding optics.

The first 5 hour minute-trend plot shows the periodic thumping as well as the one large saturating event which ruins the
Wiener noise subtraction.

The second plot is a 30 minute second-trend zoom in.
Attachment 1: Untitled.png
Attachment 2: Untitled2.png
  1119   Thu Nov 6 22:07:56 2008 ranaConfigurationComputersELOG compile on Solaris
From the ELOG web pages:


Martin Huber reports that under Solaris 7 the following command line is needed to compile elog:

gcc -L/usr/lib/ -ldl -lresolv -lm -ldl -lnsl -lsocket elogd.c -o elogd

With some combinations of Solaris servers and client-side browsers there have also been problems with ELOG's keep-alive feature. In such a case you need to add the "-k" flag to the elogd command line to turn keep-alives off.
  1122   Fri Nov 7 15:58:10 2008 ranaUpdatePEMAC is back on
I'll bet Steve a dollar that it is mechanical. The attached PDF compares all of the accelerometers from right now.

You can see that the RMS in MC2 is way bigger than MC1.

In the second PDF file you can see the time series. I had to play around a lot with DTT to get it to work. The DTT/Foton
combo on Allegra is not stable, so make sure your work early and often.

In the plots shown, I am bandpassing the time series from 600-700 Hz. I found that doing so allowed the burp in MC1 to remain
large and reduce the extraneous fuzz in MC2. As you can see there is no such noise in MC2.

So its a noise around 600-700 Hz that comes on quickly and then shuts off after several seconds. Its also very periodic in that
it comes on around every 20 minutes. Steve also tells me (although he refuses to put in the elog) that it started up around
August 20th (?). I feel like someone in the 40m lab ought to be able to guess what this is at this point.

Please convince Steve to elog his findings about when the noise started.

If one goes out there and stands next to it when the trend predicts its happening it becomes clear what it is.
Attachment 1: mc-acc.pdf
Attachment 2: mc-acc-quad.pdf
  1137   Fri Nov 14 20:35:47 2008 ranaUpdatePSLReference cavity ring down
To make the DEI pulser make a fast pulse on the EO shutter EOMs, we had to make sure:

1) the cable had a high voltage rated dielectric. cheap dielectrics show the 'corona'
effect, especially when there is a bend in the cable.

2) the EO has to have a resistor on it to prevent ringing due to the impedance mismatch.

3) We needed ~3.5 kV to get the EO shutter crystal to flip the light by 90 deg.
  1147   Wed Nov 19 18:02:18 2008 ranaConfigurationElectronicsAll the Marconi Set to the Rubidium Frequency Standard
Not sure what was going on before. I changed the frequency counter to use an AC coupled input, and had it average
for 50 seconds. The output now agrees with the Marconi front panel to less than 1 Hz. Its still not 0.000 Hz,
but not bad.
  1148   Wed Nov 19 18:12:35 2008 ranaConfigurationIOOnew channel for MC drum modes
I set up the lockin to take the MC Demod Board's Qmon signal, demodulate it at 27.5 kHz, and
put the output into a DAQ channel (I think its either MC_DRUM1 or MC1_TEMPS). However,
the MC_DRUM channel doesn't look like its getting anything in the DTT although it looked fine
on a scope. I used the 'sensitivity' setting of the lockin to make the demodulated signal
large enough but not so large that it would saturate the ADC (+/- 2V).
  1150   Fri Nov 21 16:03:50 2008 ranaHowToGeneralRecharging Batteries
I found some black & red "Ninja" alkaline AA batteries in the battery charger. This is dangerous. Please
do not put alkaline batteries in there, only Nimh. If you need help with the battery charger you can
come and talk to me or Rob and we can help you out getting started.
  1154   Fri Nov 21 19:47:26 2008 ranaUpdatePEMGuralp noise measurement
and here's the spectra with them connected - from the coherences, it looks like it needs to be rotated by 90 deg.

I'll next rename the channels to fix this so that we get good seismic data over the weekend with the MC.
Attachment 1: a.png
  1156   Fri Nov 21 21:20:24 2008 ranaUpdatePEMGuralp noise measurement
This is the spectra and time series of the Guralp channels along with the Ranger (MC2). Looks like we could reduce the gain
on the ranger. The Guralp channels run into ADC noise around 40 Hz (which is OK). We'll have to look at the weekday trends
to see if they saturate.
Attachment 1: a.png
  1157   Fri Nov 21 21:28:32 2008 ranaSummaryComputersc0daqawg restart
A few minutes after restarting fb0 for the Guralp channels, the DAQAWG lights went red on the DAQ screens.
Why?? I chose revival procedure #3 for c0daqawg from the Wiki and it came back in a couple minutes.
  1159   Mon Nov 24 16:43:34 2008 ranaConfigurationComputersAlex and Jay took away some computers from the racks
I was over at Wilson house and saw Jay and Alex bring in 3 rackmount computers. One was a Sun 4600 and
then there were 2 3U black boxes. I got the impression that these were the data concentrators or
data collectors or framebuilder test boxes. They said that they got these from the 40m and no one was
in the lab to oppose them except for Bob and he didn't put up much of a fight.

Everything looks green on the DAQ Detail and RFM network screens so perhaps everything is OK. Beware.
  1160   Mon Nov 24 17:14:44 2008 ranaUpdatePSLMach Zender trends
It looks like the MZ has gotten less drifty after the alignment on Friday.
Attachment 1: Untitled.png
  1164   Thu Nov 27 22:56:42 2008 ranaConfigurationEnvironmenttemperature
Attachment 1: mc.png
  1167   Tue Dec 2 19:18:10 2008 ranaSummaryPEMRanger SS-1
In entry http://dziban.ligo.caltech.edu:40/40m/881 and a follow up from Jenne I put in the Ranger calibration.
Since then, we've reduced the SR560 gain from 200 to 100 so the calibration factor is now:

1e-9 (m/s)/count and then 2 poles at 0 Hz, and a Q~1 zero pair at 1 Hz.
in DTT:
G = 1e-9
p = 0, 0
z = 0.7 0.7
  1168   Tue Dec 2 19:51:32 2008 ranaUpdatePEMhalf-micron particle count is alarming
The 0.5 micron dust monitor count is now pretty high (36000). I wandered around the lab to see if there was anything
nasty going on but I didn't see or smell anything in particular. Since today Alberto was sitting around where the
dust monitor is while aligning the PSL beam, we should blame him. Its either garlic, cologne, or time to bathe.

The 400 day hour trend shows that while the counts are not so unusual, the 40m is dirtier than it was last year.
Attachment 1: Untitled.png
Attachment 2: dust.png
  1171   Wed Dec 3 19:21:09 2008 ranaConfigurationPEMRanger move
I looked at the Ranger signals. Somehow it has a relative transfer function of 'f' between it and the Guralp.
i.e.  ------ ~ f

which is strange since according to their manuals, they should both be giving us a voltage output which is proportional
to velocity. I checked that the Ranger only has a load resistor and then an SR560 low pass at 300 Hz. Jenne assures
me that the Guralp breakout box shouldn't have any poles either (to be double checked). Its a mystery.

We made sure that the SR560 now is DC coupled, G = 100, & 1-pole low pass at 300 Hz. I moved it over next to the Guralp
(went through the mass recentering procedure after forgetting to lock it before moving). It is behaving as it was

Attached is a 2 page PDF of the comparisons. The 'MC1' channels are Guralp and 'MC2' is Ranger.

The second attachment compares our seismometers (in counts) with the LHO Guralp seismometers. There's no high frequency
rolloff there like what we see here so I bet a dollar that there's a pole in the Guralp box somewhere.
Attachment 1: c.pdf
c.pdf c.pdf
Attachment 2: wsnb.pdf
  1179   Fri Dec 5 09:29:59 2008 ranaUpdateIOOdrum modes observable without excitation
Not sure what the y-scale is since there aren't any y axis labels in the plot, but it seems like we
now get an SNR of a ~few with a BW of 0.1 Hz. IN principle, the frequency noise out of the PSL ought
to be limited by the VCO phase noise at these frequencies (sort of) so the broadband MC_F level
is very roughly equal to 20-100 mHz/rHz.

Since dnu = dL*(c/lambda)/L_MC, the thermal peaks have a height of ~10^-15 m_RMS. We (Caryn) should check
that these numbers are true and then see if this is the correct amount of energy for thermally excited
mirror modes.
  1180   Fri Dec 5 14:13:41 2008 ranaSummaryIOOMC trend for the last 4 days
The MC has stayed locked for ~3 days! I just broke it to reset the MZ.
Attachment 1: g.png
  1183   Sun Dec 7 16:02:46 2008 ranaUpdateGeneralMag 5.1 EQ halfway to Vegas
There was a Mag 5.1 EQ Friday night at 8:18 PM.

It tripped most of our optics. They all damped down passively except for MC2. Further more, ITMY seems to have come back to a different place.

Don't know why MC2 was so upset but I think maybe its watchdog didn't work correctly and the side loop is unstable when there are
large motions. After I lowered the side gain by 10x and waited a few minutes it came back OK and the MC locked fine.

I have just now put all the WDs into the Shutdown state so that we can collect some hours of free swinging data to see if there's been
any damage. Feel free to redamp the optics whenever you need them. Someone should do the eigenfrequency check in the morning and compare
with our table of frequencies in the wiki.

I excited the optics using the standard SUS/freeswing-all.csh script. Here's the output:
Excited all optics
Sun Dec  7 16:07:32 PST 2008
Attachment 1: g.png
Attachment 2: Untitled.png
  1184   Sun Dec 7 16:12:53 2008 ranaUpdateDAQbooted awg
because it was red
  1213   Fri Jan 2 17:20:44 2009 ranaSummaryComputer Scripts / Programs40m GWINC
I have made a '40m' directory in the iscmodeling CVS tree which allows one to run a 40m version of GWINC.

As does the previous one, it takes the default advLIGO config file and modifies some of the struct parameters
to make it appropriate for the 40m.

To make it run, I have added susp1.m to the GWINC directory. This calculates suspension thermal noise using
the Gonzalez-Saulson method that was later extended to
mirrors by Y. Levin. This is also the code used in the LIGO Noise Budget at the sites.

The previous code was giving a much larger value for thermal noise (probably because I didn't understand how
to use it right). It was based on a SURF report from '99.

Since we will have a mixture of MOSs and SOSs in the arms, I have just used SOSs in the model. So the suspension
thermal noise is overestimated by ~sqrt(2) (and realistically its uncertain by a much larger factor).

Since the new code now uses GWINC, the mirror and coating thermal noise are now more correct and use the
coherent therm-optic noise picture.

The 2 page PDF file shows the noise for 0 deg and 90 deg tuning of the SRC.

Although it looks like, from this plot, that we could measure coating thermal noise at the 40m, in reality we would have
to fix all of the technical noise sources first. Just the coil driver noise is probably at the level of 3 x 10^-17 m/rHz
at 100 Hz.
Attachment 1: bench40.pdf
bench40.pdf bench40.pdf
  1217   Thu Jan 8 16:49:37 2009 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://
5) Choose HP and the 5550 postscript driver as the options
6) Try to only print useful stuff and not kill too many trees.

It ought to be root to do that.
  1230   Thu Jan 15 22:30:32 2009 ranaConfigurationDMFDMF start script
I tried to restart the DMF using the start_all script: http://dziban.ligo.caltech.edu:40/40m/280

it didn't work Frown
  1239   Mon Jan 19 18:21:41 2009 ranaUpdateComputersloadLIGOData a GUI for mDV
The tool is very nice; I looked at the seismic trend for 16 days (attached).
However, it gives some kind of error when trying to get Hanford or Livingston data.
Attachment 1: a.png
  1242   Wed Jan 21 22:53:08 2009 ranaUpdateLSCAS CCD centering and ASDD demod phase
Just my opinion, but I think all we want out of the DD signals is something to control the DRM
and not be sensitive to the carrier and the CARM offset. So if the handoff can be done so that
the lock point is unchanged from single demod then everything is fine.

A second order concern is how the 133 & 199 MHz signals are mixed in order to minimize the
matrix cross-coupling and the SNR of the diagonal elements.
  1297   Thu Feb 12 14:39:07 2009 ranaSummaryGeneralSilicon Beam Dump test
Yesterday evening, Ken Mailand and I tested the reflectivity of a piece of polished Silicon. Since Silicon has such a high thermalconductivity (compared to stainless and fused silica) and can take much more heat than black glass and should have a very good BRDF and should absorb most of the 1064 nm light if we hit it at Brewster's angle, we want to try it out in the first version high power, low scatterbeam dump. This dump will be a 'V' style dump like what Steve has tested nearly a year ago, but the incoming beam will first hit this piece of Silicon.

The pictures of the setup and the Silicon with the beam hitting it are here.

Brewster's angle for p-pol at 1064 nm is 74.2 deg (n = 3.53 @ 1064 nm). We set up a cube polarizer on the output of the ~1064 nm CrystaLaser. 144 mW got to the Si; the reflected beam was ~1.9-2.0 mW after tuning the angle for minimum power. Via eyeball and protractor it seems that we're at ~74 deg. So the reflectivity is < 1.5-2%. This is good enough; the reflected power will be < 1 W in all cases for eLIGO and that can be absorbed by the rest of the stainless V dump. The 35 W of heat in the silicon will be mostly gotten rid of through conduction into the attached heat sink fins.

This kind of dump would go into places like the PMC-REFL, MC-REFL, & IFO-REFL, where we occasionally need to take high power, but also are sensitive to backscatter.
  1307   Mon Feb 16 00:43:46 2009 ranaUpdateComputersmedm directory wiped on nodus
I accidentally did an 'rm -rf' on the medm directory in nodus, instead of on my laptop as was intended.

I then did an svn checkout. So everything should be current as of the last update, but I am sure that
we have not done a checkin on all of the latest screen enhancements. So...we may have to revert to the
Sunday morning tar to get the latest changes back.
  1312   Mon Feb 16 20:47:48 2009 ranaConfigurationIOOMode Cleaner WFS Loop Gain change
I found the MCWFS gain slider down at 0.012. In this state the UGFs are probably around 10-30 mHz
and so there is no reduction of seismic noise. It is mainly a DC alignment tool in this state.

We often have reduced the loop gain thusly, to prevent the dreaded "MCWFS eating CM loop gain" disease.
That disease is where there are CM loop instabilities at ~5-30 Hz because of loop cross-couplings
who's exact nature has never been understood (TBI).

Today, I implemented a 4th order, 7 Hz low pass (RLP7) into the loops and turned up the gain by a factor
of 30 to 0.3. In this state, the damping time constants seem to be ~0.5-2 seconds as shown in the first
PDF. I didn't have enough patience to do the interminable swept sine measurements down to 0.1 Hz.

The second PDF shows the Bode plot of the RLP7 filter compared to the pre-existing but unused ELP10.

The third PDF shows my estimate of the OLG TF. This is made by just putting a "Pendulum" filter into the
MCWFS bank and then plotting all the filters together using FOTON. The BLUE curve shows the old TF but
with the new high gain and the RED curve shows the new TF with the new gain.

With this new filter, I bet that we can get away with the higher WFS gain, but if there's any problem during the
handoff, the gain should be reverted to the low value.

In the 4th PDF file, I plot the spectra of 4 of MC2's control signals so that you can see what is bigger than what.
ASCPIT is the one that has the feedback from the WFS's in it. These are all just in units of counts and so to compare
them in some sort of displacement units you have to take into account the pitch moment of inertia, the mirror mass,
and the mis-centering of the beam from the center of rotation of MC2...
Attachment 1: pmc-pzt-cal.pdf
Attachment 2: a.pdf
Attachment 3: olg.pdf
Attachment 4: mc2.pdf
  1315   Mon Feb 16 23:09:52 2009 ranaUpdateElectronicsMC Servo Board offset gone bad!

The attached plot shows that someone broke the MC_SUM_MON channel around 10:30 AM this past Wednesday the 11th. This is the EPICS monitor of the MC error point.

Come forward now with your confession and I promise that I won't let Steve hurt you.

Attachment 1: mcoff.png
ELOG V3.1.3-