ELOG 40m

Locking

bad

Tried the spring-y side tonight with a discouraging lack of progress. There were several locks of DRMI+2ARMs with
the +f2 (springy) sideband resonating in the DRM, but they weren't very stable. Moving to just the DRMI and resonating
the +f2, in order to tune up the acquisition and the handoff to the double demod signals, revealed the problem that the
DRM just won't stay locked on the +f2 sideband. It locks quickly, but only for a few seconds. This is different from the
behaviour with the -f2 sideband, which locks quickly and stably. In theory, the two sidebands should behave similarly.
It could be problems with HOMs in the recycling cavities, and so we may try changing the modulation frequency slightly.

1013

Wed Oct 1 02:47:53 2008

PSL 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

1012

Wed Oct 1 02:10:03 2008

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

1011

Wed Oct 1 00:24:54 2008

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.

1010

Tue Sep 30 19:50:27 2008

Quicky Summary - more details later

Quicky summary for now, more details later tonight / tomorrow morning:

PMC notch: It's tuned up, but it is out, and it is staying out. It looks like the 18.3kHz junk isn't being helped by the brick, in fact the brick makes it worse. And the notch isn't enough to make the peak go away. Rana's and my conclusions about the PMC: the 18.3kHz resonance is associated with the way the PMC touches its mount. Depending on where we push (very gently, not much pressure) on the PMC, we can make the peak come and go. Also, if the PMC happens to be set nicely on its ball bearings, the peak doesn't appear. More notes on this later.

PMC's RF modulation depth: Since with the PMC's brick off, and the PMC sitting nicely on its ball bearings, we don't see any crazy oscillations, we were able to take the gain slider on the PMC screen all the way up to 30dB. To give us more range, we changed the modulation depth of the RF to 2V, from its previous value of 1V.

Phase of PMC servo: Since the phase of the PMC servo hasn't been set in a while, I eyeballed it, and set the phase to: Phase Flip = 180, Phase Slider = 4.8000 . I measured many points, and will plot a calibration curve later.

I also measured the actual value of the RF out of the PMC's LO board, when changing the RF output adjust slider. Again, will post the calibration later.

The attached PNG shows the PMC spectra from now and from Aug. 30 (ref). As you can see there's been some good reduction in the acoustic noise (red v. orange). The large change in the error signal is because of the much higher gain in the servo now. We'll have to redo this plot once Jenne measures the new UGF.

Attachment 1: mcf.png

1009

Tue Sep 30 13:43:43 2008

Steady progress again in locking again last night. Initial acquisition of DRMI+2ARMs was working well.
Short DOF handoff, CARM->MCL, AO on PO_DC, and power ramping all worked repeatedly, in the cm_step script.
This takes us to the point where the common mode servo is handed off to an RF signal and the CARM offset
is reduced to zero. This last step didn't work, but it should just require some tweaking of the gains
during the handoff.

1008

Mon Sep 29 17:53:33 2008

ISS has been saturating easily.
Today I opened the PSL enclosure to inspect the ISS box. Then I found that the sensor PD was disconnected from the box.
I don't know for how long it has been like this, but it is clearly bad.
I connected the PD and I was able to increase the ISS gain to 0dB (from -5dB).
When I turned off the FSS, I was able to increase the gain further up to 8dB. So the FSS must have been doing something bad to the laser intensity.
The FSS fast path did not get huge kicks when ISS was turned on as observed before. But still the FSS fast signal is wondering around about +/-0.3V.
It does not stop wondering even when the ISS is turned off (even if the CS drive cable is physically disconnected).
I will try to optimize the slow servo.

After Peter tried to optimize the demodulation phase of the FSS (see his entry), I was able to increase the ISS gain to 8dB even with the FSS running.
I haven't fully understood what is behind this behavior.

To investigate what is going on in the ISS, I opened the box and inspected the circuit.
I found many innovative implementations of electric circuit components. See the attached photo. It is a three dimensional mounting of
a surface mount AD602 !
Anyway, the board is somewhat different from the schematic found in the DCC. But I roughly followed the circuit.
I will measure open loop TFs and various signals to see how we can improve the ISS.

Attachment 1: IMG_1671.JPG

1007

Mon Sep 29 15:09:36 2008

steve

almost 4 yrs plot of power & temps

The water chiller is normally running 1.5 C warmer than the laser head temp.
When control room temp is stable and PEM-count_temp is stable we can expect the head temp to be stable 20.0 C

PSL-126MOPA_HTEMP is running warmer in the last ~40 days

The ifo arm thermostate temp settings were raised by 2 F on 8-11-08

Attachment 1: 3.5y.jpg

1006

Mon Sep 29 13:33:39 2008

josephb

Gigabit network finished and conlog available on Nodus

The last 100 Mb unmounted hub has been removed (or at least of the ones I could find). We should be on a fully gigabit network with Cat6 cables and lots and lots of labels.

In other news, the pearl script that runs the web interface on linux1 for the conlog has been copied to /cvs/cds/caltech/apache/cgi-bin/ and is now being pointed to by the apache server on Nodus.

https://nodus.ligo.caltech.edu:30889/cgi-bin/conlog_web.pl

1005

Mon Sep 29 13:23:40 2008

rob

Summary

Laser chiller running a little hot

Quote:

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.

My entry about the laser chiller got deleted. The PSL appears to be running with the ISS gain at -5dB, so that's good, but the
chiller is still showing 21+ degrees. It should be at twenty, so there's something causing it to run out of
headroom. We'll know more once Yoichi has inspected the ISS.

In the deleted entry I noted that the VCO (AOM driver), which is quite warm, has been moved much closer to the MOPA.
This may be putting some additional load on the chiller (doubtful given the amount of airflow with the HEPAs on,
but it's something to consider).

1004

Mon Sep 29 11:17:14 2008

steve

horizontal viewports are protected with lexan

SAFETY

The four horizontal viewports of arms are protected
by 3/8" thick, 8.5" OD Lexan disk of MR10 Polycarbonate.

ITMX, ETMX, ITMY and ETMY ccd cameras are not focused now.

1003

Mon Sep 29 01:19:40 2008

Summary

Laser chiller running a little hot

1002

Fri Sep 26 19:18:39 2008

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

General

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

General

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