ELOG 40m

FSS light power reduced

Rana, Yoichi

To change the gain distribution in the FSS, Rana reduced the VCO power for the AOM to reduce the light incident to the reference cavity.
Now the transmitted power of the RC is 2.3V compared to 6.5V before.
The FSS common gain can be increased to 5dB. I haven't changed the normal gain for this slider, so the mcup script will still set
the common gain to 1.5dB after an MC lock.
With this change, we take some gain from the optical part and give more gain in the electronics.
This might relieve the slew rate limit problem if it is happening in an early stage of the electronics.

1050

Wed Oct 15 22:07:52 2008

FSS ref phase measurements

Optimizing the FSS LO/RF phase at 500 kHz, above the servo band, proved to be noisy and those measurements were useless. Today I repeated
the measurement at 35 kHz and got good signal to noise. I've attached a plot of the 35 kHz peak in dBm as measured at IN2 by SR785, with
an injection into TEST2 at 35 kHz with 0.2 Vpp, as a function of delay in ns given by the delay phase shifter normally used by the 166 MHz.
I fit the bottom (quadratic) portion of this curve, and found an optimum delay of 25.8 ns, which can be implemented as 25.81 ns on the phase
shift box (25 + 1/2 + 1/4 + 1/16). This is an uncalibrated number and meaningless.. For all these measurements a very long SMA cable
(did not measure) was inserted on the RF output of the 21.5 MHz reference box. The actual phase difference depends on these cable lengths
which I didn't measure.

To determine the actual phase difference I compared the LO and RF input points with the 25.81 ns delay, using a scope with poor man's
averaging (33 manual triggers and recording the phase measurements). The phase difference was 8.24 degrees with an error on the mean of 3.4%,
with the LO having the longer effective cable (cable plus delay from the phase delay box). As a sanity check I set the phase delay box
to 20 ns and re-measured, and found 49.5 degrees. (1/21.5 MHz) * (49.5-8.24)/360 = 5.3 ns, which is about the difference between 20 ns
and 25.81 ns. I did the same with 0 ns dialed in, and found a difference of 21.5 ns (I expected 25.8 ns). So it is possible that the
phase delay box isn't too precise.

Finally, to determine the length of cable needed to implement 8.24 degrees of phase at 21.5 MHz with RG58 cable, I made some phase measurements
using the FSS reference box and mismatched cables. I used three cable lengths (93 cm, 140.5 cm, and 169.5 cm ) and two mismatched pairs with
dL of 29 and 76.5 cm. For each pair I took average of 20 measurements, finding 22.54 degrees mean for the dL=29 cm pair (0.78 degrees/cm, or
a speed of light of 1.0e10 cm/s, or 10.6 cm of cable length on the LO) and 43.57 degrees mean for dL=76.5 cm pair (0.57 degrees/cm, or a speed
of light of 1.4e10 cm/s, or 14.5 cm of cable length on the LO). I expected more precise agreement.

Maybe the 21.5 MHz reference box is not zero phase between the outputs. This could be easily tested. It might be interesting to repeat this
measurement with a few more dL values.

Attachment 1: phasedelay.png

1052

Thu Oct 16 09:47:49 2008

FSS ref phase measurements

Quote:

I fit the bottom (quadratic) portion of this curve, and found an optimum delay of 25.8 ns, which can be implemented as 25.81 ns on the phase shift box (25 + 1/2 + 1/4 + 1/16).

The gain of the loop is sinusoidally dependent on the phase delay. So the fit will be better with a function like this: 1/(1+G*sin(dphi + const)).

1053

Thu Oct 16 13:12:58 2008

phase between FSS reference outputs

I verified the phase between the FSS reference outputs (used for LO and RF) using matched BNC cables. I measured 0.95 degree (average of 12 scope measurements).

1054

Thu Oct 16 16:26:26 2008

FSS phase matching cable installed

RG 405 cable has a solid teflon dielectric, and a velocity factor of 0.69. To get the 8.2 degrees of additional phase on the LO output at 21.5 MHz then requires 22 cm of cable. I made a cable that ended up being 21 cm long after I'd gained some experience putting on the connector. It gives a phase difference between LO and RF of about 10 degrees. It is currently installed.

1055

Fri Oct 17 16:43:10 2008

mcup/down scripts on linux

I made some changes to /cvs/cds/caltech/medm/c1/ioo/cmd/medmMCup and medmMCdown so that those can be run from medm on linux machines.

1059

Mon Oct 20 15:02:00 2008

I moved missing files in /cvs/cds restored by Alan and Stuart to the original locations.
I confirmed autoburt runs, and dtt, which had also been having trouble running, runs ok now.

I found an interesting piece of evidence on allegra, our new 64bit linux machine.
In the Trash of controls Desktop on that machine, there is /cvs/cds/vw/ directory.
I remember that when I last time emptied the trash bin on the machine (yesterday), it took somewhat long time.
Too bad that I did not pay attention to what was actually in the Trash, but now I have a feeling that in the Trash were
missing /cvs/cds/* directories.
While emptying the Trash, I encountered several errors saying permission denied or something like that, and skipped those files.
Sometimes, when you move something from NFS mounted directories to the Trash, you get this kind of errors.
So my guess is that someone accidentally (or intentionally) moved /cvs/cds/* except for "caltech" to the Trash of allegra.
And I completely removed them carelessly.

1060

Mon Oct 20 16:18:00 2008

Quote:

In the meantime, I have re-started the nightly backup for /frames/minute-trends
but NOT YET for /cvs/cds ,
since I fear that we'll find another problem and will need to go back to the June 27 backup.
Let's wait a few days for the dust to settle,
and if everyone feels confident that /cvs/cds is ok,
I'll restart the backup of that.

How I restored the files, for the record:

Stuart mounted /archive/backup onto an accessible computer (garrak.ligo.caltech.edu ) and I logged on to controls@nodus and ran this command:

/cvs/cds/caltech/scripts/backup/rsync --rsync-path=/usr/bin/rsync --rsh=/usr/bin/ssh --compress --verbose --archive --hard-links --exclude=caltech/ ajw@garrak.ligo.caltech.edu:/backup/40m/cvs /cvs/cds/recover_20081020

I had to type in my GC password, and it ran for ~20 minutes (would have been much longer had I asked for /cvs/cds/caltech as well!).

you can view the backups by logging on to garrak.ligo.caltech.edu with your GC account:
/backup/40m/cvs/cds/
/archive/frames/trend/minute-trend/40m

1061

Mon Oct 20 20:50:09 2008

FSS board chip replacement

A quick update.

I changed two AD797s on the FSS board to AD829s to mitigate the 50MHz oscillation, which I plan to report later.
For some reason, the PA85 was broken after the replacement. So I had to replace it with a spare one too.
Right now the FSS is back and working. The oscillation is gone.
However, the maximum achievable gain is still about the same as before.

1065

Tue Oct 21 18:19:42 2008

LISO and Eagle installed

I installed LISO, a circuit simulation software, into the control room linux machines.
I also installed a PCB CAD called Eagle to serve as a graphical editor for LISO.
I put a brief explanation in the wiki.
http://lhocds.ligo-wa.caltech.edu:8000/40m/LISO

As a demonstration, I made a model of the FSS PC path and did a stability analysis of the op-amps.

The first attachment is the schematic of the model.
You can find the model in /cvs/cds/caltech/apps/linux/eagle/projects/liso-examples/FSS

The second attachment shows the stability analysis plot of the first two op-amps when AD829s are used.
The op-amp model is for the uncompensated AD829. The graph includes the bode plots of the open-loop transfer function of each op-amp.
If the phase delay is more than 360deg (in the plot it is 0 deg because the phase is wrapped within +/-180 deg) at the unity gain frequency,
the op-amp is unstable.
It is clear from the plot that this circuit is unstable. This is consistent with what I experienced when I replaced the chips to AD829 without
compensation.
Unfortunately, I don't have an op-amp model for phase compensated AD829. So I can't make a plot with compensation caps.

The third attachment is the stability analysis of the same circuit with AD797. It also shows that the circuit is unstable at 200MHz, though I
observed oscillation at 50MHz.

Finally, I did an estimate of frequency noise contribution from the noise of AD829.
First I estimated the voltage noise at the output of the board caused by the first AD829 using LISO's noise command.
Then I converted it into the input equivalent noise at the stage right after the mixer by calculating the transfer function
of the circuit using LISO.
Within the control bandwidth of the FSS, this input equivalent noise appears at the mixer output with the opposite sign.
Since we know the calibration factor from the mixer output voltage to the frequency noise, we can convert this into the frequency noise.
The final attachment is the estimated contribution of the AD829 to the frequency noise. As expected, it is negligible.

Attachment 1: FSS_PC_Path.pdf

Attachment 2: AD829Stability.png

Attachment 3: AD797Stability.png

Attachment 4: FreqNoiseByAD829.png

1078

Thu Oct 23 20:47:28 2008

FSS LO calibration for MEDM

Today I took a quick series of measurements to calibrate the FSS LO power measurement in the MEDM. This was done by using the spec.an. to measure the 21.5 MHz peak in dBm at the LO input to the FSS box on the PSL table, and recording the MEDM value, for attenuations applied at the FSS REF box output ranging from -5 dBm to -30 dBm.

I measured the loss due to the BNC cable I used, which was (19.66-19.50) dBm. I accounted for this and plotted ln(MEDM) vs. dBm on the attached plot. A linear fit of this gives the CALC field of a calc record for the IOC db:
6.29*LOGE(A)+5.36

Since no one knew how to do this nonlinear conversion in EPICS I will describe how to do it in detail tomorrow. It is simple, although it requires power cycling the scipe3 bunch (typing "reboot" or "ctl-x" at the command prompt took it down, but it did not come back). I did power cycle those computers a few times today.

Attachment 1: fss_lo_calibration.png

1081

Fri Oct 24 10:06:16 2008

MC gain and FSS gain changed

Following the measurements of MC and FSS loop gains, I modified mcup script to set the MC VCO gain to 2dB (it was -4dB before).
I also changed the normal value of the FSS common gain to 7dB. The open loop transfer functions posted in the previous two entries
were measured with those settings.

1083

Fri Oct 24 11:21:26 2008

FSS LO input calibrated in dBm

Based on the measurements described in my previous elog, I created a new calc record in the file /cvs/cds/caltech/target/c1psl/psl.db

grecord(calc, "C1:PSL-FSS_LOCALC")
{
        field(INPA,"C1:PSL-FSS_LODET")
        field(SCAN,".1 second")
        field(PREC,"4")
        field(CALC,"6.29*LOGE(A)+5.36")
}

After restarting scipe3 to load this change, I told C1PSL_FSS.adl to look at this record instead of *LODET. That MEDM screen now shows LO input calibrated in dBm.

For reference, the operators available for use in the CALC field are listed in the EPICS Record ref manual, Chapter 9. The manual can be found here:
http://www.aps.anl.gov/epics/EpicsDocumentation/AppDevManuals/RecordRef/Recordref-3.html

Yoichi said he was fixing an SVN problem, so I have not yet committed the two files I changed: /cvs/cds/caltech/target/c1psl/psl.db and /cvs/cds/caltech/medm/c1/psl/C1PSL_FSS.adl.

1088

Fri Oct 24 20:54:41 2008

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.

1089

Fri Oct 24 21:49:15 2008

Jenne

PEM

Short Seismometer Cable

Bad news regarding the cable that goes between the Guralp seismometer and the box that I've been working on: it's too short by about a factor of 2. Dang it. I've placed the seismometer underneath the Beam Splitter Chamber (where it needs to go), and started running the cable toward the ADC rack where box was planned to go, and as Rana guessed earlier tonight, the cable isn't nearly long enough. We have some options: the seismometer can go back into the half-height rack near the BS, SRM, PRM oplev's optical table where I think it used to be, or it can go into the rack with the Kepco high voltage power supplies and the laser's supply. The cable won't reach any farther than that.

I think that we can just add BNC extensions onto the octopus cable that Bob made for the Guralp box, so all we need to figure out after we decide on a rack is the power for the box.

1093

Mon Oct 27 11:16:23 2008

I implemented the calibration for the four channels of the StochMon in the ioo EPICS database. Now the output of those channels, as shown in the medm screen, gives the peak-to-peak amplitude in voltage of each frequency from the RFAMPD at the transmission of the MC, normalized by the DC output from the same photodiode.

Basically the calibration takes into account the following factors:
- two in series RF preamplifiers, currently laying on the PSL table near the RFAMPD, with gains of 19 dB and 17 dB, respectively
and, inside the StochMon blue box:
- a resonant band-pass filter with the following gains h_f(f) for each of the frequencies of interest: 33MHz -39.5 dB; 133MHz -40.8 dB; 166MHz -49.0 dB; 199MHz -45.0 dB
- a power detector that provides an output voltage linearly proportional to the input power in dBm, with a factor alpha of proportionality equal to an average value of -0.0271 V/dBm for all the frequencies

The calibration that relates the output voltage from the PD to the output voltage from the StochMon is then obtained as:

V_pd(f) = sqrt(2*R*P0)/h_f(f) * 10^( (Vo-q)/(20*alpha) )

where R=50ohm, P0=1mW and q=0.772 V, the latest being the offset in the calibration of the power detector (that is its output for a 0 dBm input).

1095

Mon Oct 27 14:48:27 2008

EO shutter installed to the reference cavity

I'm now preparing for cavity ring down measurements of the reference cavity.
An EOM for polarization rotation is installed between the two steering mirrors for the reference cavity.
The location is before the polarized beam splitter (used to pick-up the reflected light from the cavity) and
after the half-wave plate. So we should be able to use the PBS as a polarizer.
While setting up the high voltage pulse generator, I realized that we don't have enough cables for it.
It uses special kind of connectors (Kings 1065-N) for HV connections. We need three of those but I could find
only two. I asked Bob to order a new connector.

For the moment, the EOM is left in the beam path of the reference cavity until the connectors arrive (Wed. or Thu. this week)
and the measurements are done.
The EOM distorts the beam and degrades the mode matching to the reference cavity.
I optimized the alignment of the crystal so that the RC transmission is maximum.
Even though, the transmission of the reference cavity is down from 2.8 (without EOM) to 1.7 (with EOM).
I increased the common gain of the FSS from 7dB to 10dB to compensate for this.
The mode clearner locks with this configuration.

If the EOM is really disturbing, one can just take it out.
Since I did not touch the steering mirrors, the alignment to the reference cavity should be recovered immediately.

1098

Tue Oct 28 12:01:01 2008

Quote:

Note I still need to remove a fair bit of cabling no longer in use from the Martian network switch next to Alberto's desk. There's actually about 8-10 cables there which show no connectivity and are not being used. So there's really about 33% of the ports open in the control room hub, it just doesn't look like it.

As for linux2, I'll probably just connect it to the 1Y2 or 1Y6 Hubs when I get the chance.

1099

Wed Oct 29 12:23:04 2008

MZ alignment touched and the alarm level changed

Since the MZ reflection is alarming all the time, I tried to improve the MZ alignment by touching the folding mirror.
I locked the X-arm and monitored the transmitted light power while tweaking the mirror alignment to ensure that the output beam pointing is not changed.
I changed the alignment only a little, almost like just touching the knob.
The reflected power monitor was around 0.6 this morning and now it is about 0.525. Still large.
I changed the alarm level (HIGH) from 0.5 to 0.55.

1102

Thu Oct 30 20:39:47 2008

We attached the temperature sensor box to the MC1/MC3 chamber with a C-clamp. We connected the temp sensor to a 2nd box with a short BNC. Bob set up a power cable coming from the X-end towards the MC1/MC3 chamber(Thanks, Bob!) We soldered the end of Bob's power cable to a plug and attached it to the 2nd box (The power supply enters through the 2nd box). A ~20ft BNC cable connects the output signal of the 2nd box to the tall thing by the PSL where all the signals go labeled 1Y2. Once we had everything connected, we put in the fuses for the power supply. So, now the temperature sensor is receiving power. We checked that the power supply was working (we measured +15.08V and -14.95V, and we wanted 15V and -15V so it's OK for now). Tomorrow we will modify C1IOOF.INI file and reboot the frame builder.

About sensor-
There is an LM34 (looks like a transistor) glued w/ epoxy and thermal paste to the inside of a Pomona box ~1"x"1.5"x2". The lid to the box is covered with a 1-2mm thick piece of copper and a little thermal paste is sandwiched between the Pomona lid and the copper piece. A C-clamp attaches the copper piece to the chamber. A BNC is connected to one side of the box (the side with less copper)

About power supply box-
There is a power regulator and an op-amp inside a Pomona box ~2.5"x4"x2". The power regulator is attached to the center of lid of the pomona box with a screw and washer. There's a power plug on the front of the box
Left:+15V:red wire
Center:GND:white wire
Right:-15V:black wire
There are 2 BNC connections on the sides of the box. The left BNC connection is for the output signal and the right BNC connection is for the temperature sensor (if the power plug is coming out of the box towards you).

Sensor location-
Chamber which contains MC1/MC3. On the door facing towards the Y-end. On the bottom-left side. Behind the door. Attached with a C-clamp.

Power supply box location-
Chamber which contains MC1/MC3. On some metal leg thing near the floor facing towards the Y-end. Attached with a zip-tie

Power supply-
Coming from the X-end from a tall thing with all the fuses labeled 1X1
Fuse 160:+15V:red wire
Fuse 171:GND:white wire
Fuse 172:-15V:black wire

Signal-
Going towards the PSL to the tall thing labeled 1Y1 on the rack labeled SN208
ICS-110B
J12 (which we believe corresponds to 50-51 and channel number 13650)
Temperature sensor is connected to J12 with a ~20ft BNC attached to a BNC2LEMO connector we found lying around

1104

Sun Nov 2 20:21:58 2008

HP 5550dtn (Grazia) set up on allegra

lore

I set up printing to grazia from allegra. The CUPS interface was not as straightforward as Tobin had made it seem in the Wiki. I had to type in the IP address and port number by hand.

The steps (AFAIR):

1) Goto http://localhost:631/
2) Click on "Add Printer"
3) Choose HP JetDirect
4) Use the correct address (socket://131.215.115.220:9100)
5) Choose HP and the 5550 postscript driver as the options
6) Try to only print useful stuff and not kill too many trees.

1109

Mon Nov 3 19:18:47 2008

Phil Ehrens kindly poured our elog's content in a CD that now is here at the 40m.
I've been trying to install the 2.7.5 version of the elog on Nodus, a Sun machine, but the installing procedure is different from linux and I dont' know it. I tried to recompile the elog from the source code but the way gcc is called must be wrong because I get this error message:

nodus:elog-2.7.5>make
gcc -DHAVE_SSL -o elog src/elog.c -lsocket -lnsl -lssl
src/elog.c:45:25: openssl/ssl.h: No such file or directory
src/elog.c:329: error: parse error before "SSL"
src/elog.c: In function `ssl_connect':
src/elog.c:331: error: `SSL_METHOD' undeclared (first use in this function)
src/elog.c:331: error: (Each undeclared identifier is reported only once
src/elog.c:331: error: for each function it appears in.)
src/elog.c:331: error: `meth' undeclared (first use in this function)
src/elog.c:332: error: `SSL_CTX' undeclared (first use in this function)
src/elog.c:332: error: `ctx' undeclared (first use in this function)
src/elog.c:340: error: `ssl_con' undeclared (first use in this function)
src/elog.c:341: error: `sock' undeclared (first use in this function)
src/elog.c: In function `retrieve_elog':
src/elog.c:383: error: `SSL' undeclared (first use in this function)
src/elog.c:383: error: `ssl_con' undeclared (first use in this function)
src/elog.c: In function `submit_elog':
src/elog.c:631: error: `SSL' undeclared (first use in this function)
src/elog.c:631: error: `ssl_con' undeclared (first use in this function)
make: *** [elog] Error 1

Joe, Yoichi, anyone else knows how to do that?

1110

Mon Nov 3 21:38:32 2008

Quote:

I tried to recompile the elog from the source code but the way gcc is called must be wrong because I get this error message:

nodus:elog-2.7.5>make
gcc -DHAVE_SSL -o elog src/elog.c -lsocket -lnsl -lssl
src/elog.c:45:25: openssl/ssl.h: No such file or directory
src/elog.c:329: error: parse error before "SSL"

The location of ssl.h is a bit strange in the sunfreeware version of OpenSSL. Since elog does not use configure script, you have to
edit Makefile and add an appropriate -I option to an appropriate variable definition (probably LIBS or CFLAGS, because the elog Makefile does
not use INCLUDES).
If you don't understand what I'm saying, just wait for me.

1119

Thu Nov 6 22:07:56 2008

ELOG compile on Solaris

From the ELOG web pages:

Solaris:

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.

1133

Thu Nov 13 15:50:44 2008

The schematic of the 1Y7 rack that Alan pointed out (see attachment) don't represent anymore the actual rack.
First, with Yoichi we found that the GPS receiver for the 10 MHz is in a different position,
on the other side of the VME computer. It seems to output 1 kHz, which also appears in some modulated way.
This signal is then passed to a board on 1Y7 that seems make just copies of the signal. One of these goes
to an other board in 1Y6 that looks like a GPS receiver but has actually no GPs antenna input. Here it is
not connected to anything, but on its same crate is a the awg computer, so it might be providing the clock
to that by the crate.

We also checked the clock monitor output on the boards in the PSL that provides for the clock to the Penteks
and it seems that these are actually getting 4MHz.

Attachment 1: rackstuff.pdf

1146

Wed Nov 19 10:32:11 2008

All the Marconi Set to the Rubidium Frequency Standard

Electronics

I placed the SRS Rubidium FS275 over the PSL rack, next to the frequency counter. This one and the Marconi on the PSL rack have been connected to the 10MHz output of the frequency standard. I set also the first Marconi, the one that used to drive the others, to external, direct frequency reference. Now it reads 166981718 Hz versus 166981725 Hz measured by the frequency counter: 8 Hz difference.

1147

Wed Nov 19 18:02:18 2008

All the Marconi Set to the Rubidium Frequency Standard

Electronics

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

new 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).

1158

Sat Nov 22 10:55:51 2008

Caryn

Drum modes Lock-In settings changed

I unhooked the MC Demod Board's Qmon signal from the Lock-In. Set the demodulation frequency to 31.11Hz with 1V amplitude, and
put the output into MC_DRUM1. DTT showed a ~30Hz peak. Dataviewer showed signal with amplitude ~20,000.
Otherwise the settings were as Rana had them: Time Constant-100us,24dB/Sensitivity-200us/Low Noise
Want to check if Lock-In frequency drifts.

1159

Mon Nov 24 16:43:34 2008

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

1161

Mon Nov 24 19:15:16 2008

The PSL Room Temperature was alarming because it had gone above 23 C. This set off an unfortunate chain of events:

We found that the PSL HEPA was set low (20%). This is a fine setting for when no one is working in there but it
does raise the temperature since there are heat sources inside the blue box.

We tried to change the office area temperature to compensate and also the westmost sensor inside the lab area by 2 deg F.

The office area one was problematic - there was so much dust in it that the gas valve nipple was clogged. So we've
now blown it all clean with a compressed air can. We're now tuning the calibration screw to make our new
digital sensor agree with the setpoint on the controller.

Expect wild temperature swings of the office area for a couple days while Alberto and I tune the servo.

1163

Tue Nov 25 19:29:15 2008

Quote:

This morning Bob found 92F in the office area and in the control room of the lab. He turned down the thermostat and when I got in at about 9 I found 65. After a few hours of adjustment of the thermostat's calibration, I could stabilize the room temperature to about 72F. I also turned down the thermostats inside the lab of a couple of degrees F.

1164

Thu Nov 27 22:56:42 2008

8-)

Attachment 1: mc.png

1166

Tue Dec 2 17:56:56 2008

In the attempt to maximize the Mode Cleaner transmission and minimize the reflection from the steering mirrors of the MC periscope, we could not get more ~2 V at the MC Trans PD and ~ 0.5 V at MC REFL_DC. As it turned out from the SUS Drift Monitor, the reason was that the MC optics had been somehow displaced from the optimal position.

After restoring the reference position values for the mirrors and tweaking again the periscope, we got ~3V at the MC TransPD and 0.5V at the reflection.
The beam was then probably clipped at the REFL PD so that we had to adjust the alignment of one of the BS in the transmitted beam path on the AS table.
We also zeroed the WFS PDs, but not before reducing the power from the MZ, for their QPDs not to saturate.

After relocking, the transmission was 3V and the reflection ~0.3V.

The beam isnow centered on the Trans PD and REFL PD and the Mode Cleaner locked. More details on the procedure will follow.

1171

Wed Dec 3 19:21:09 2008

I looked at the Ranger signals. Somehow it has a relative transfer function of 'f' between it and the Guralp.

      Ranger
i.e.  ------ ~ f
      Guralp

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

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

Attachment 2: wsnb.pdf

1175

Thu Dec 4 16:29:20 2008

josephb

Error message on Frame Builder Raid Array

The Fibrenetix FX-606-U4 RAID connected to the frame builder in 1Y7 is showing the following error message: IDE Channel #4 Error Reading

1177

Fri Dec 5 01:41:33 2008

MEDM screen snapshot now works on linux machines

As a part of my "make everything work on linux" project, I modified 'updatesnap' script so that linux machines can update MEDM screen snapshots.
Now, all 'updatesnap' in the subsystem directories (like medm/c1/lsc/cmd/updatesnap) are sym-link to /cvs/cds/caltech/medm/c1/cmd/updatesnap.
This script will take a window snapshot to a PNG file, and move the old snapshot to archive folders with date information added to the filename.
For compatibility, it also saves JPEG snapshot. Right now, most of 'view snapshot' menus in MEDM screens are calling 'sdtimage' command, which cannot display PNG files. I installed Imagemagick to op440m. We should change MEDM files to use 'display' command instead of 'sdtimage' so that it can show PNG files.
I've already changed some MEDM screens, but there are so many remaining to be modified.

PNG is better than JPEG for crisp images like screen shots. JPEG performs a sort of spacial Fourier transformations and low-pass filtering to compress the information. If it is used with sharp edges like boundaries of buttons on an MEDM screen, it naturally produces spacial aliasing (ghost images).

I also created several sym-links on the apps/linux/bin directory to mimic the Solaris-only commands, such as 'sdtimage', 'nedit' and 'dtterm'.
For example, nedit is symbolic linked to gedit. Many MEDM buttons/menus, which used to be incompatible with linux, now work fine on the linux machines.

1178

Fri Dec 5 01:58:58 2008

tdscntr.pl now works at 40m

ASC

Tobin gave me the perl version of tdscntr some time ago.
Pinkesh and I modified and tested it at LHO.
I further modified it today and now it runs fine on the linux machines at the 40m. I haven't tested it with the Solaris machines.
My modifications include changing channel names to 40m ones, and using tdsavg to get QPD data rather than ezcaread.
The use of tdsavg is intended to avoid aliasing problem.
tdscntr.pl is installed in /cvs/cds/caltech/apps/linux/tds/bin

Now, the alignX runs on linux up to the centering of the QPDs.
However, ezcademod seems to behave wrongly on linux. I plan to investigate on this problem tomorrow.
I may try tdsdmd instead.

1192

Thu Dec 18 12:52:00 2008

Mode Cleaner Cavity Alignment

SUS

This morning I found the MC locked to the 10 mode. When I locked it on the 00 mode, it was unstable and eventually it always got locked to the wrong mode.

I looked at the Drift Mon MEDM screen, which shows a reference record for position, pitch and yaw of each mirror, and I found that the MC optics were in a different status. Moving the sliders of the mirrors' actuators, I brought them back to the reference position. Then the lock got engaged and it was stable, although the MC reflection from the photodiode, with the wave front sensors (WFS) off, was about 2V. That's higher than the 0.5V the it could get when we aligned the cavity and the input periscope last time.

With the WFS on, the reflection dropped to 0.3V and, so far, the the cavity has been stably locked.

1193

Thu Dec 18 19:15:54 2008

Alberto, Yoichi

Mode Cleaner Cavity Alignment

SUS

Quote:

This evening the mode cleaner was again locking on a higher mode so we tweaked the mirrors' actuators by their sliders on the MEDM screen until we improved the reflection to 0.3V.

Then we went inside and, on the AS table, we centered the beam on the wave front sensors.

Now the mode cleaner is locked, the reflection is less than 0.3V and the transmission about 3V, tha is it is in ideal conditions. We'll see if it holds.

1194

Fri Dec 19 11:18:52 2008

Mode Cleaner Temperature Monitor

General

I reduced from 10 to 5 the gain of the SR560 that Caryn has set up after the lock-in amplifier nest to the PSL rack because the overload LED was flashing.

1195

Fri Dec 19 11:29:16 2008

Alberto, Yoichi

MZ Trans PD

Lately, it seems that the matching of the input beam to the Mode Cleaner has changed. Also, it is drifting such that it has become necessary to continuously adjust the MC cavity alignment for it to lock properly.

Looking for causes we stopped on the Mach Zehnder. We found that the monitor channel:

C1:PSL-MZ_MZTRANSPD

which supposedly reads the voltage from some photodiode measuring the transmitted power from the Mach Zehnder, is totally unreliable and actually not related to any beam at all.

Blocking either the MZ input or output beam does not change the channel's readout. The reflection channel readout responds well, so it seems ok.

1207

Mon Dec 29 21:51:02 2008

The apache on nodus has been solely serving for the svn web access.
I changed the configuration and all files under /cvs/cds/caltech/users/public_html/ can be seen under
https://nodus.ligo.caltech.edu:30889/

The page is not password protected, but you can add a protection by putting an appropriate .htaccess
in your directory.
For the standard LVC password, put the following in your .htaccess

AuthType Basic  
AuthName "LVC password"
AuthUserFile /cvs/cds/caltech/apache/etc/LVC.auth
Require valid-user

1208

Tue Dec 30 18:51:18 2008

rana,yoichi

Illuminator Power Supply reset

Electronics

We noticed that none of the illuminators were working.

The switches were off on all the ports. After turning them on it still didn't work.

The +24 V Sorensen power supply which powers all of the illuminators had its OVP light on.
We turned it off, ramped the voltage to zero, turned it back on, and then went back to +24 V.

We then checked the operation of the illuminators; ETMY is still MIA.

Each of the illuminators sucks ~0.6-0.7 A when the (unlabeled) rheostat knob panel is set
to the "25" setting.

It seems pretty unwise, in the EMI sense, to be sending Amps of unshielded, high current,
switching supply outputs for 40m down the arms. This creates a huge antenna for radiating
the switching noise. I hereby assign minus 5 points to whoever designed this system.

Illuminator Upgrade:

- Use LEDs of a wavelength that the OSEMs don't see. LEDs are also cool so that the
  Suspension won't drift in alignment.

- Use 2 power supplies so that the power is balanced.

- Make is +/-12 V twisted AWG 14 wire so that the EMI is contained. Should also
  be shielded cable.

1217

Thu Jan 8 16:49:37 2009

HP 5550dtn (Grazia) set up on allegra

lore

Quote:

1) Goto http://localhost:631/
2) Click on "Add Printer"
3) Choose HP JetDirect
4) Use the correct address (socket://131.215.115.220:9100)
5) Choose HP and the 5550 postscript driver as the options
6) Try to only print useful stuff and not kill too many trees.

It ought to be root to do that.

1224

Tue Jan 13 11:10:42 2009

unknown how long it's been down.

1230

Thu Jan 15 22:30:32 2009

I tried to restart the DMF using the start_all script: http://dziban.ligo.caltech.edu:40/40m/280

it didn't work Frown

1232

Fri Jan 16 11:33:59 2009

Quote:

I tried to restart the DMF using the start_all script: http://dziban.ligo.caltech.edu:40/40m/280

it didn't work Frown

It should work soon. The PATH on mafalda does not include ".", so I added a line to the start_DMF subscript, which sets up the DMF ENV, to prepend this to the path before starting the tools. I didn't put it in the primary login path (such as in the .cshrc file) because Steve objects on philosophical grounds.

Also, the epics tools in general (such as tdsread) on mafalda were not working, due to PATH shenanigans and missing caRepeaters. Yoichi is harmonizing it.

1236

Fri Jan 16 18:45:20 2009

MC_L gain increased by a factor of 2

Rana, Yoichi

Since we fixed the FSS AOM double-pass, which used to be a single-pass, the MC_L gain was too low for
making the cross-over at 100Hz.
Rana increased it by a factor of two. Now it seems that the cross over is ok (attachment 1).

We also noticed that the MC_F spectrum is noisier than before (attachment 2).
The reference is from 6/24/2008.

Attachment 1: MC_F-MC_L-xover.pdf

Attachment 2: MC_F.pdf

1244

Thu Jan 22 11:54:09 2009