ELOG 40m

IOO

MC2 is having a bad day

As Steve mentioned earlier in today's elog, MC2 keeps ringing up for no clear reason. It is definitely only MC2 that is ringing up, since it's sensors will read several hundreds of counts, while all the other optics are at regular 2 counts and below on the Watchdog screen.

Preliminary investigation results: Around the time of these "kick up" events, the Ranger seismometer does not see any motion, nor does the set of accelerometers under the MC1 chamber. The set of accelerometers under the MC2 chamber do see activity that is at the same time as these events. These events are not caused just by someone walking around, since Rana went inside and clunked around near MC2 while I watched the sensor levels. MC2's watchdog did not trip.

For further investigation: Why is it that only the MC2 accelerometers are seeing the motion? Similarly, why is MC2 the only optic being kicked? Has anyone done anything lately to the MC2 stack?

1001

Fri Sep 26 19:08:43 2008

Refcav 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.

1000

Fri Sep 26 18:35:17 2008

PMC filter is out for tuning

The PMC's new Pomona Box filter is out for tuning. I'd like to get the notch right on the 18.3kHz, rather than being off in 21.7kHz land.

999

Fri Sep 26 16:13:57 2008

IOO

MC_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

998

Fri Sep 26 16:08:39 2008

There's been good progress in locking the last couple of nights. A lot of time was wasted before I found that
all the SUS{POS,PIT,YAW} damping gains on the SRM were set to 0.1 for some reason, which let it get rung up
just a bit during bang locking. After setting these gains to 0.5 (similar to PRM and BS), the initial lock
acquisition of DRMI+2ARMs (nospring) got much quicker. Then more time was wasted by sticky sliders on the
transmon QPD whitening gain, causing the Schmitt triggered HI/LO gain PD switch not to happen. This meant
that the arm power was not reported properly when the CARM offset was reduced, and so loop gain normalizations
were not working properly. After all this, by the end of the night last night, reduced the CARM offset such
that stored power in the arms was about half of the max. Should be able to get to full power with another
good night, and then back to springy locking.

997

Fri Sep 26 14:10:21 2008

Yoichi

Lab laptops maintenance

The linux laptops were unable to write to the NFS mounted directories.
That was because the UID of the controls account on those compters was different from linux1 and other control room computers.
I changed the UID of the controls account on the laptops. Of course it required not only editing /etc/password but also dealing with
numerous errors caused by the sudden change of the UID. I had to chown all the files/directories in the /home/controls.
I also had to remove /tmp/gconf-controls because it was assigned the old UID.

Whenever we add a new machine, we have to make sure the controls account has the same UID/GID as other machines, that is 1001/1001.

I did some cleanups of the laptop environment.
I made dataviewer work on the laptops *locally*. We no longer have to ssh -X to other computers to run dataviewer.
The trick was to install grace using Fedora package by

sudo yum install grace

Then i modified /usr/local/stow_pkgs/dataviewer/dataviewer to change the option to dc3 from "-s fb" to "-s fb40m".

996

Fri Sep 26 09:05:47 2008

The MC2 sus damping was restored.

995

Fri Sep 26 00:19:54 2008

Filter-action with the PMC

Written, but not posted on 24Sept2008:

PMC adventures for this evening

Today's mission was to make more progress on increasing the bandwidth of the PMC servo.

First order of business was to improve the performance of the 14.6kHz notch that Rana put in the PMC servo board a few weeks ago to remove the 14.6kHz body mode resonance of the PMC. Looking at the zoomed in TF that I posted Monday (elog #978), we see that there is still a remnant of a peak near 14.5kHz. A first gut-reaction is that the notch is not tuned properly, that we have just missed the peak. As previously noted in the elog, the peak that we are trying to notch out is at 14.68kHz (elog #874). By unlocking the PMC and measuring the transfer function between FP2 and OutMon (OutMon is the monitor for the high voltage going to the PMC's PZT), I measure the transfer function of the notch, and find that it is notching at 14.63kHz. So we're a teensy bit off, but the Q of the notch is such that we're still getting improvement at the peak frequency. After checking that we are hitting the correct frequency, I put a short (just some wire) around R21, which is the R in the RLC notch filter, to increase the depth of the notch. At the peak frequency of 14.68kHz, we see a 2.5dB improvement of the notch. At the actual notch frequency of 14.63kHz, we see a 3.2dB increase in the depth of the notch. So, shorting R21 helped a little, but not a lot. Also, it's clear that we don't get that much more improvement by being on the resonant frequency, so there's no need to go in and tune the notch on the board.

Second order of business was to investigate the 18.34kHz peak in the transfer function. (Rana spent some time Monday night measuring this peak, and determined that it was at 18.34kHz) We decided that the best plan was to re-implement the Pomona Box notch filter that had previously existed to remove a higher frequency body mode, but tuned for the 18.34kHz mode. I am still not entirely sure what this mode is, but clearly it's a problem by about 20dB (on the TF, the next highest peak is 20dB below the 18.34kHz peak). Unfortunately, while the components should, by Matlab calculations, give me an 18.3kHz notch, I ended up with something like a 21.7kHz notch. This notch is approximately -30dB at 21.7kHz, and -20dB at 18.3kHz. I still need to take transfer functions and power spectra of the PMC servo with this new filter in place to (a) confirm that it did some good, and (b) to determine how important it is that the notch be right-on. More likely than not, I'll take the filter out and fiddle with the capacitors until I get the correct notch frequency.

Third on the list was to lock everything back up (FSS, PMC) after my tinkering, and see what kind of gain we get. Rob and I fiddled with the PMC gain, and it looks like the servo oscillates just before we get up to the max slider gain of 30dB. Looking at the power spectra in DTT, we do not see any significant peaks that suggest oscillation, so it is likely that there is some investigation to be done at frequencies above the 7kHz that we were able to look at with DTT (which isn't surprising, since all of this work has been at 14kHz and higher).

A final note is that we see a feature around 9kHz in the transfer function, and it is not at all clear where it comes from. At this time, it does not seem to be the dominant feature preventing us from increasing the gain, but at some point if we want the bandwidth of the PMC servo to be 10kHz, we'll have to figure this one out.

Still on the PMC todo list:

Measure the new transfer function, see if 18.34kHz peak is reduced
Tune Pomona Box notch filter to 18.3kHz instead of the current 21.7kHz
Retake power spectra of different items on top of PMC, compare to see if there is any one configuration that it obviously better than the others.
Find out why the PMC still oscillates when we try to take it up to the max slider gain, and fix it.

PS, is anyone else having trouble getting to the elog from laptops on other parts of the Caltech network (but not LIGO network)? My laptop won't go to the elog, but I can get to the rest of the internet using the Caltech wireless. My computer stopped seeing the elog on Tuesday or so. Joe, do you have any inspiration? Thanks.

994

Thu Sep 25 17:14:31 2008

Attachment 1: vegemite.png

993

Thu Sep 25 15:24:05 2008

I calibrated the VCO driving the AOM for the AO path of the MC feedback.

I injected DC voltage to the VCO and measured the output frequency with the SR620.

The attached plot shows the relation between the input voltage to the VCO and the output frequency.
The coefficient is 1.75MHz/V. Since the AOM is double path, the actual actuation efficiency is 3.5MHz/V.
We can use this value for the calibration of the MC_F. However, the MC_F DAQ channel is sampling the VCO input voltage through a 10Hz high-pass filter.
This filter has to be taken into account to convert the MC_F counts to frequency.
I will measure the transfer function from the VCO input to the MC_F counts tomorrow.

Attachment 1: VCO_Cal.png

992

Thu Sep 25 14:03:08 2008

josephb

Quote:

We (Joe) need to buy a GigE card for linux1 and to also set up conlog and conlogger to run on Nodus.

A spare Intel Pro 1000/GT desktop adapter (gigabit ethernet card) has been added to Linux1 and is now using that card to connect to the network.

This was after a slight scare when I somehow reset the bios on Linux1 during the first reboot after adding the card.
After some debugging and discussion with Yoichi, the bios was fixed and the computer works again, with its new faster network connection.

Although we both noted that Linux1 is a rather old machine, with only half a gig of Ram and reaching about 80% capacity on its 58 gigabyte hard drive (raid). Might be worth upgrading in general.

Need to figure out how to install conlog/conlogger programs next...

991

Thu Sep 25 10:48:29 2008

Yoichi

FSS calibration again

I did a calibration of the FSS error signal again with a different method.
This time, I swept the laser frequency with the NPRO PZT around a resonance.
The attached figures show the transmitted light power and the PDH error signal vs the applied voltage to the PZT.
From the width of the transmitted light power peak, we can obtain the PZT voltage to the laser frequency coefficient,
i.e. the HWHM (Half Width Half Maximum) equals to the FSR (38kHz).
Once the PZT is calibrated, the PDH error signal can be calibrated by the fitting the central slope with a line.

I repeated the measurement 8 times and fitted the obtained data to get the HWHM and the slope.
The results are the following:
PZT calibration = 6.3 +/-0.1 MHz/V
PDH calibration = 6.5 +/-0.5 kHz/V

Note:
(1) The calibration coefficient (6.5kHz/V) is almost consistent with the previous value (6.83kHz/V elog:958). However, that calibration
used a considerably different value for the PZT calibration (11.172MHz/V elog:791). The discrepancy in the PZT calibration is understandable
because my previous PZT calibration was very rough. The fact that the two calibrations still agree is a mystery.

(2) In the transmitted power curve, there seems to be a slight distortion, probably due to the thermal effect.
We should reduce the power to the reference cavity to remove this effect.

(3) This measurement was done after Peter installed his RF source. The demodulation phase had not yet been optimized. We should
repeat the calibration after he optimizes the phase.

(4) I used the Tektronix oscilloscope for the measurement.
Using the ethernet-wireless converter, you can connect the scope to the network from anywhere in the lab.
No hard wire required anymore.
Then you can download the data from a web browser. It is cool !

Attachment 1: PDTrans.png

Attachment 2: PDHsignal.png

990

Thu Sep 25 03:12:13 2008

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.

989

Thu Sep 25 02:35:21 2008

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

988

Wed Sep 24 19:13:06 2008

Computer Scripts / Programs

updatedb & 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.

987

Wed Sep 24 17:57:04 2008

Alberto

ABSL: FSS Slow Actuator Control

Rana, Alberto

Today when I started working with the PLL that I use to control the secondary laser on the ABSL experiment, I found that the beat between the two lasers was at a much higher temperature of NPRO than usual (about one Celsius Degrees higher, 49.79 instead of 48.7). It turned out that the main beam frequency had changed, and so had its frequency, because of a too much high value of the slow actuator gain on the FSS. We looked at the trend for the gain and noticed it had changed from 0.3 to 3 at about noon today. We brought it back to the old value and also optimized the single gains in the FSS slow servo to obtain a faster and stabler response to step changes in the laser temperature.

It is very important for the ABSL experiment that the frequency and the NPRO temperature of the main laser do not change.

** update:

you asked for:   diff 2008/09/25,0:00 2008/09/25,8:50:19 utc 'FSS[-_]SLOW'
LIGO controls: differences, 2008 09/25 00:00:00 utc vs. 2008 09/25 08:50:19 utc
__Epics_Channel_Name______   __Description__________   __value1____     __value2____
C1:PSL-FSS_SLOWKD                                      0.000000         0.001000
C1:PSL-FSS_SLOWKI                                     -0.001000        -0.001700
C1:PSL-FSS_SLOWKP                                     -0.000300        -0.001000

It seemed later that it was not being cool with the derivative gain up at -0.001, so I set it to zero. We really need some documentation on this
loop (e.g. pseudo code and a PID tuning procedure). Note that the PID record as documented in the EPICS Reference Manual
has been deprecated and so we run a perl script that Tobin wrote.

986

Tue Sep 23 15:28:06 2008

pete

new 21.5 MHz FSS reference installed

The new 21.5 MHz FSS reference is now installed in the rack with the 7 Sorensen PS. Both outputs give 18.7 dBm. The MC seems happy.

Bob did the +24 V and +15 V hookups for the amp and the Wenzel oscillator respectively, off of the din strips on the right of the rack.

I have attached two photographs. One shows the front of the box as mounted in the rack, and the other shows the inside of the box. From the second photo the circuit is apparent. Black wire coming in has ground, green has +15, and white has +24. After the switches, ground and +15 go to the Wenzel crystal oscillator, and ground and +24 go to the mini-circuits amp. There is 5 dB attenuation between the Wenzel 21.5 MHz output and the amp input. There is 3 dB attenuation between the amp output and the splitter.

The Wenzel crystal oscillator is their "streamline" model, and puts out 13.2 dBm. The amp is mini-circuits ZHL-2.

Attachment 1: fss_ref_001.jpg

Attachment 2: fss_ref_013.jpg

985

Tue Sep 23 13:25:07 2008

I've been spending time working on the short DOF loops (PRC,MICH,SRC) in an attempt to make the
initial stage of lock acquisition (the DRMI+2ARMs, no spring) better. This seems to have been
largely successful, as last night there were several locks of the DRMI+2ARMs with pretty short
wait times.

The output matrix for the short DOFs is a bit strange, though. The MICH->PRM element is about
3 times too small, which seems to indicate something broken in hardware. The MICH->SRM element
seems normal, though, which suggests the BS is isn't broken--either the PRM has had a sudden
actuation increase or it's a problem with the sensing.

984

Tue Sep 23 11:17:59 2008

The PMC output side has a new madly scattering spot at chamfer 2 o'clock position

Attachment 1: rainbow.png

Attachment 2: pmcclip.png

983

Tue Sep 23 00:47:24 2008

Quote:

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.

netgpibdata.py is now installed on the controls machines (/cvs/cds/caltech/scripts/general/netgpibdata/netgpibdata.py).
You can use it like,

netgpibdata.py -i 131.215.113.106 -d AG4395A -a 10 -f spectrum01

In this example, data from Agilent 4395A analyzer at GPIB address 10 connected to the GPIB-LAN box with the IP address 131.215.113.106
is downloaded and saved to spectrum01.dat. The measurement parameters are saved to spectrum01.par.

982

Mon Sep 22 22:24:19 2008

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.

981

Mon Sep 22 21:54:05 2008

New Wiener result with x10 gain in ACC

ASS

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.

Attachment 1: f.pdf

980

Mon Sep 22 21:30:06 2008

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?

Attachment 1: DAQ.png

979

Mon Sep 22 20:00:35 2008

Alberto

ABSL: running measurement

I'm leaving the X arm locked on the TEm01 mode while a measurement is running. Just please wait for 40 minute if you need the interferometer tonight.

978

Mon Sep 22 18:54:54 2008

PMC 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

Attachment 2: PMC_OLG_5kHz_to_30kHz.png

977

Mon Sep 22 16:51:27 2008

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

Mantis found outside the 40m door at night

Frogs

Treasure

Attachment 1: mantis.JPG

975

Mon Sep 22 12:06:58 2008

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

steve

old hubs can make one happy

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

Attachment 1: P1020934.jpg

973

Fri Sep 19 11:21:45 2008

josephb

Nameserver and Rosalba

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

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

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

972

Fri Sep 19 09:49:42 2008

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

Quote:

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

971

Fri Sep 19 08:09:55 2008

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

970

Fri Sep 19 01:55:41 2008

Summary

SUS

SUS Drift Screen Updated

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

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

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

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

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

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

Attachment 1: infection-3.png

Attachment 2: setsvals.m

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

debug = 0;


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

... 56 more lines ...

Attachment 3: setHILO.m

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

% 1 for debugging
debug_flag = 0;

if nargin == 1

... 62 more lines ...

969

Fri Sep 19 00:18:14 2008

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

968

Fri Sep 19 00:06:54 2008

MC_F: Too much frequency noise around 100 Hz

IOO

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

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

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

10 kHz UGF or bust!

Attachment 1: mcf.png

967

Thu Sep 18 23:31:26 2008

ISS: Saturating too often at nominal gain

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

Attachment 1: FIRE_BLOWER.jpg

966

Thu Sep 18 18:38:14 2008

Yoichi

HowTo

How to compile an SNL code for VxWorks

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

Here is the procedure:

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

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

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

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

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

(4) Login to control0

ssh ops@control0

(5) Change directory to the sandbox dir.

cd /cvs/cds/lho/target/t0sandbox0

(6) Prepare for the compilation

setup epics

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

(8) Compile

make Particle.o

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

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

That is it.

965

Thu Sep 18 14:36:54 2008

josephb

Name server and Epics

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

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

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

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

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

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

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

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

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

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

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

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

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

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

964

Thu Sep 18 13:05:05 2008

Quote:

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

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

963

Thu Sep 18 12:16:01 2008

Quote:

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

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

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

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

962

Thu Sep 18 09:30:12 2008

steve

low noise metal film resistors are in

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

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

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

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

Attachment 1: mfr&cap.png

Attachment 2: storcab.png

961

Thu Sep 18 01:14:23 2008

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

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

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

960

Wed Sep 17 19:13:47 2008

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

959

Wed Sep 17 17:58:35 2008

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

958

Wed Sep 17 17:31:24 2008

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

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

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

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

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

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

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

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

Attachment 1: PZTresp.png

Attachment 2: Calibration.png

Attachment 3: FreqNoiseSpectrum.png

957

Wed Sep 17 15:22:31 2008

Quote:

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

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

956

Wed Sep 17 13:58:36 2008

Alberto