40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 21 of 341  Not logged in ELOG logo
IDup Date Author Type Category Subject
  1011   Wed Oct 1 00:24:54 2008 ranaUpdateLockinglast night
I had mistakenly left the MC boost off during my FAST investigations. The script is now restored.

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

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

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

The next plot is a 90 day hour-trend of the same signals. You can see that LODET came back to us between
September 10 and 19 ??? I looked at a 4 year trend and it seems that this signal has always been zero
(nice use of disk space) except for a few days in Nov of 06 and then whatever happend on Sep 10.
Attachment 1: Untitled.png
Untitled.png
Attachment 2: Untitled.png
Untitled.png
  1013   Wed Oct 1 02:47:53 2008 ranaUpdatePSLPSL ERR & LODET: Too much offset
Looks like there is an anomolous mixer offset correlated with the increase in the LO level. This may be leading to crazy offset locking in the FSS and too much coupling from ISS to FSS.
Attachment 1: Untitled.png
Untitled.png
  1014   Wed Oct 1 02:54:03 2008 robUpdateLockingbad

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.
  1015   Wed Oct 1 12:05:58 2008 AlbertoConfigurationComputers"StochMon" added to the Alarm Handler
John, Alberto,

we added the four channels of the RF Amplitude Monitor (aka StochMon) to the Alarm HAndler. First we modified the 40m.alh file just copying some lines and switching the name of the channels to the ones we wanted. Than we also added a few lines to the database file ioo.db in order to define the alrm levels. So far I used just test values for the thresholds of green, yellow and red states and need to update to some reasonable ones. To do that I need to calibrate those EPICS channels. I have the old data saved and I'm now trying to figure out how to properly change the database file.
  1016   Wed Oct 1 12:09:25 2008 AlbertoConfigurationComputers"StochMon" added to the Alarm Handler

Quote:
John, Alberto,

we added the four channels of the RF Amplitude Monitor (aka StochMon) to the Alarm HAndler. So far I used just test values for the thresholds of green, yellow and red states and need to update to some reasonable ones. To do that I need to calibrate those EPICS channels. I have the old data saved and I'm now trying to figure out how to properly change the database file.


John, Yoichi, Alberto

We restarted the C1iool0 computer both directly by the main key and remotely via telnet. We had to do it a couple of times and in one occasion the computer didn't restart properly and had connection problem with the newtowrk. We had to call Alex that did just the same thing, but used the CTRL+X command to reboot. It worked and the Alarm Handler now includes the StochMon.
  1017   Wed Oct 1 23:05:14 2008 YoichiUpdatePSLISS RIN spectra
Stefan, Yoichi

We took relative intensity noise (RIN) spectra of the ISS error point and the monitor PD (attm1).
In-loop RIN is the sensor PD and "Out of the loop RIN" is the monitor PD.
The ISS gain slider was at 8dB in this measurement.
It looks normal. 
An open loop transfer function of the ISS loop was measured (attm2). The UGF was 22kHz with the phase margin of ~22deg.
We should increase the UGF up to ~60kHz

When we increase the gain up to 14dB, the CS saturation warning comes up in the EPICS screen.
We confirmed this by monitoring the CS drive signal with an oscilloscope.
It is the output of an AD602J, which has +/-3V output range. 
By increasing the gain of AD602J, we saw that the output signal hits the rail.
There seems to be a lot of high frequency (100kHz - a few MHz) noise, out of the control band.
We also observed that AD602J itself oscillates at about 10MHz (don't remember the exact number) when the gain is increased.
(We saw this even when the loop is off. There is no such an oscillation in the input to the AD602J).
When we took wide band spectra of the CS drive signal, we saw many large harmonics of ~180kHz. We believe these peaks are limiting
our ISS gain now (causing the CS saturation). The harmonics persisted even when we disconnected the PDs. So it is not coming from the light.
We saw the same harmonics in the power lines. They may be the switching noise of the Sorensens. 
We took spectra of those harmonics, but the netgpibdata.py somehow did not save the data from AG4395A correctly. I have to debug this.

Stefan removed DC offsets from the AD829s (many of them are used in the ISS board) by turning the pots for offset adjustment.
This eliminated the problem of getting a large DC CS feedback (observable in C1:PSL-ISS_CSDRIVE_MEAN) when the gain is increased.

During the investigation, I noticed that increasing the PMC gain too much (~22dB) caused an oscillation of the PMC loop and consequently made
the ISS saturate. When the ISS is behaving bad, we should check the PMC gain.

Currently, the ISS is running OK with the gain = 8dB. I modified the mcup script to set the ISS gain to 8dB when the MC is locked.

TO DO:
Wait for Peter's answer about spare ISS boards.
Power line filtering. 
Find the cause of AD602J oscillation (Well this is the one mounted upright. So just mounting it normally might solve the problem :-). 
Attachment 1: RIN.png
RIN.png
Attachment 2: OPLTF.png
OPLTF.png
  1018   Wed Oct 1 23:21:03 2008 YoichiConfigurationPSLReference cavity reflection camera
I re-centered the reference cavity reflection camera, which has been mis-aligned for a while.
I also tweaked an input steering mirror to make the alignment better. This resulted in the increase of the transmission PD voltage
from 8V to 9V.
  1019   Thu Oct 2 02:45:50 2008 robUpdateLockingmarginally better
Locking the DRMI with the +f2 sideband was marginally better tonight. I was able to get it lock stably enough to take transfer
functions and handoff MICH & PRC to double demod signals. After re-alignment, however, behaviour was similar to last night
(locks quickly but only for a few seconds), so that lends some credence to HOM-as-bad-guy theories.
  1020   Thu Oct 2 16:44:28 2008 steveSummaryoplevsoptical levers
The idea is to push the UGF to 10 Hz of the TM oplev servos with quiet HeNe laser.
We measured good intensity noise of JDS 1103P in May 2007 and converted most of the TM oplevs to it.
The ITMs still have the noisy 670nm , 1 mW, diode lasers to begin with.
In order to get 1 mW power returning to the qpds I measured the power going to TMs
and returning on qpds ...so we can select the appropriate laser power for the conversion.

40m optical lever lasers:

HeNe laser JDS 1103P, 633nm, linear polarization 500:1,

ETMX: qpd 0.12 mw (4%) reflected of 3 mW,
ETMY: qpd 0.1o (3.8%) " 2.6
BS: qpd 0.02 ( 2.5%) " 0.8
PRM: qpd 0.01 (1.3%) " 0.75
SRM: qpd 0.08 (10%) " 0.8

Coherent 670 nm Diode Lasers VLM-tm, 0.95 mW, linear polarization 100:1,

ITMX: qpd 0.1 mW (11%) reflected back from TM of 0.9 mW
ITMY: qpd 0.04 (7%) " " 0.6

It seems that JDS HeNe laser 633 nm, linear polarization 500:1, 10 mW will do the job
  1021   Thu Oct 2 18:56:19 2008 ranaSummarySUSResistivity of Suspension Wire
Bob and Steve measured the resistance of the suspension wire today:
OD     = 0.0036" =  0.091 mm
Length = 46"     = 1168.4 mm
Resistance     =   33.3 Ohms

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


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

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

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

TBD
  1022   Fri Oct 3 12:15:21 2008 AlbertoConfigurationIOOC1iool0 rebooted
This morning, in order to update the threshold values of the alarm handler for the StochMon, I rebooted the C1iool0 computer following the procedure in the wiki, that is telnetting on it and typing CTRL+X. Apparently everything went well in the process.
  1023   Fri Oct 3 15:09:58 2008 robUpdatePSLFAST/SLOW

Last night during locking, for no apparent reason (no common mode), the PSL FAST/SLOW loop starting going just a little
nutz. Attached is a two day plot. The noisy period started around 11-ish last night.
Attachment 1: FASTSLOW.png
FASTSLOW.png
  1024   Fri Oct 3 15:57:05 2008 robUpdateLockinglast night, again
Last night was basically a repeat of the night before--marginally better locking with the DRMI resonating the +f2
sideband. Several stable locks were achieved, and several control handoffs to DDM signals worked, but never from
lock to lock--that is, a given DD handoff strategy would only work once. This really needs to work smoothly before
more progress can be made.

Also, a 24Hz mode got rung up in one/several of the suspensions--this can also impede the stability of locks.
  1025   Fri Oct 3 19:38:02 2008 robMetaphysicsEnvironmentThe Gatekeeper

Found this lady outside the door of the 40m lab a few nights ago.
Attachment 1: DSC_0409.JPG
DSC_0409.JPG
  1026   Sat Oct 4 07:23:42 2008 KojiMetaphysicsEnvironmentThe Gatekeeper
Hi, this is Koji from Japan.

I am afraid that this is a poisonous spider, Latrodectus hasseltii.
In Japanese word "Seaka-goke-gumo" (red-backed widow spider)

I am not an expert of insects, but this type of spider is getting famous in Japan as they were accidentally imported from South-West asia and Austraria to Japan in recent years, and they settled in certain city areas.

It is said that its neurotoxic venom causes unpleasant results such as shock, pain, and inflammation, even it is not too strong to kill human.

Be careful.


Quote:

Found this lady outside the door of the 40m lab a few nights ago.
  1027   Mon Oct 6 10:00:49 2008 steveUpdateMOPAMOPA_HTEMP is up
Monday morning conditions:

The laser head temp is up to 20.5 C
The laser shut down on Friday without any good reason.
I was expecting the temp to come down slowly. It did not.
The control room temp is 73-74 F, Matt Evans air deflector in perfect position.
The laser chiller temp is 22.2 C

ISS is saturating. Alarm is on. Turning gain down from 7 to 2 pleases alarm handler.

c1LSC computer is down
Attachment 1: htup.jpg
htup.jpg
  1028   Mon Oct 6 12:45:41 2008 AlbertoDAQLSCC1LSC in coma
Alberto, Joe,

The C1LSC medm screen is frozen and the C1LSC computer is down. We tried to reboot and to restart it first turning off the power and then just rebooting remotely. None of them worked. We check whether any of the cable was unplugged but they were ok. Also all the led turned on to green after rebooting.
Trying to reboot we get the following error message: init_module: device or resource busy.

We called Alex who first suggested to check all the connection and then to swap the timing cable between two Pentek boards but the computer was still down.
It is possible that the board is dead. Alex and Rolf are going to look into this problem and for any spare board.

by now we can't lock any DOF of the IFO.
  1029   Mon Oct 6 16:41:33 2008 AlbertoDAQLSCC1LSC in coma

Quote:
Alberto, Joe,

The C1LSC medm screen is frozen and the C1LSC computer is down. We tried to reboot and to restart it first turning off the power and then just rebooting remotely. None of them worked. We check whether any of the cable was unplugged but they were ok. Also all the led turned on to green after rebooting.
Trying to reboot we get the following error message: init_module: device or resource busy.

We called Alex who first suggested to check all the connection and then to swap the timing cable between two Pentek boards but the computer was still down.
It is possible that the board is dead. Alex and Rolf are going to look into this problem and for any spare board.

by now we can't lock any DOF of the IFO.


Alex, Rob, Alberto,

Alex replaced the Pentek board used by C1LSC with a spare one that they had at the Wilson house. That fixed the DMA failure but since the board had a channel broken, one of the channels (POY) was still not available.

Looking at the wiring diagram of the ASC crate, we found that one of the Pentek boards in it was actually not used by anything and thus available to replace the bad one in LSC. We switched the two boards so that now the one that Alex installed is mounted in the ASC crate and it is connected to the cable labeled 1x2-ASC 6.

C1LSC is up again and all the channels in the C1LSC screen, including POY, now seem to be working properly.
  1030   Tue Oct 7 10:49:29 2008 AlbertoUpdateGeneralDisplaced Photodiode
This morning I found that the photodidode of the PLL in the PSL table was not aligned to the beam anymore. The PD support was not tight to the pedestal so that the PD was rotated and completely off of the beam.

It is possible that the BNC cable connected to the PD was pulled very strongly, or the PD was hit so that the support got unscrewed by its pedestal. Anyways, it did not happen spontaneously.

I re-aligned the PD and observed again the beat between the two laser beams. Here are the values from the measurement of the signal from the PD:
I measured the DC values of the hitting power, alternatively occluding one of the two laser beams, and I measured the beat amplitude letting them interfere and reading the peak-to-peak amplitude of the oscillating signal:

main beam DC: 200mV
secondary beam DC: 490
beat: 990mV
beat at the spectrum analyzer (after the two-way splitter of the PLL): -8.40dBm on a noise floor of the photodiode of -75dBm

the frequency of the beast is 8.55MHz and the temperature of the NPRO of the secondary beam, as read from the laser driver display, is 48.7357C.


Alberto
  1031   Tue Oct 7 12:17:57 2008 AlbertoConfigurationComputersTime reset on MEDM
Yoichi, Alberto

I noticed the MEDM screen time was about 7 minutes ahead of the right time. The time on MEDM is read on channel C0:TIM-PACIFIC_STRING which takes it from the C1VCU-EPICS computer. Yoichi found that that computer did not have the right time because one of the startup scripts, ntpd, which are contained in the directory /etc/init.d/ for some reason did not start. So restring it by typing ./ntpd start updated the time on that computer and fixed the problem.
  1032   Tue Oct 7 21:19:40 2008 YoichiUpdateIOOMC_F calibrated spectrum
I updated the plots because I did not take into account the double path AOM effect, which doubles the frequency actuation efficiency. (2008/10/8)

I determined the MC_F counts to the PSL frequency change calibration.
The attachment 1 is the calibrated MC_F spectrum, which is, above the cross over frequency, equivalent to the frequency noise seen by the MC.

The calibration method is the following:

1) I picked spare AD and DA channels (C1:IOO-MC_TMP1 and C1:OMC-SPARE_DAC_CH_16_EXC). C1:OMC-SPARE_DAC_CH_16_EXC is labeled C1:OMC-OSC_FM on the cable.

2) C1:IOO-MC_TMP1 was calibrated by injecting a sine wave of known amplitude and measuring the amplitude in counts in dataviewer.
It was 63uV/cnt.

3) C1:IOO-MC_TMP1 was connected to the feedback BNC connector of the MC board, that is the direct monitor of the feedback voltage to the VCO.

4) C1:OMC-SPARE_DAC_CH_16_EXC was connected to the channel B excitation input of the MC board, which adds the signal to the fast feedback path.

5) Using DTT a swept sine signal was injected to the MC board through C1:OMC-SPARE_DAC_CH_16_EXC, and the transfer function from C1:IOO-MC_TMP1 to the
C1:IOO-MC_F was measured.

6) Using the calibration of C1:IOO-MC_TMP1, the transfer function from the MC_F count to the actual voltage applied to the VCO input was obtained.
(attm2)

7) Using the DC calibration of the VCO input voltage to the VCO frequency change (1.75MHz/V elog:993) and the fact that there is a 1.6Hz pole and a 40.8Hz zero between the VCO input connector and the actual input of the VCO chip, the final calibration transfer function from the MC_F count to the frequency change of the PSL (that is twice the frequency change of the VCO within the bandwidth of the FSS) can be obtained (attm3).

8) The analytic form of the calibration TF is, poles at [1.6Hz, 11.42Hz, 11.42Hz] and zeros at [40.8Hz, 113Hz, 113Hz] with the DC gain of 110Hz/cnt.
Attachment 1: MC_F-spectrum.png
MC_F-spectrum.png
Attachment 2: VCO_VoverMC_F.png
VCO_VoverMC_F.png
Attachment 3: PSL_FoverMC_F.png
PSL_FoverMC_F.png
  1033   Wed Oct 8 12:35:56 2008 josephbConfigurationComputersNew Network diagram for the 40m
Attached is a pdf of the new network diagram for the 40m after having removed all of the old hubs.
Attachment 1: 40m_network_10-07-08.pdf
40m_network_10-07-08.pdf
  1034   Wed Oct 8 19:17:55 2008 YoichiConfigurationPSLLaser power is slowly recovering
This afternoon we (rich, steve, yoichi) shutdown the laser for the DC-DC converter installation.
(we decided not to do so. Detail will be posted soon.)
After we turned on the laser again,the laser power has been recovering but very slowly.
At the time of writing, the laser power is 2.6W (MOPA_AMPMON).
I think it is because the chiller temparature has not yet settled down (it went up to 25C and slowly coming down, now at 22C).
It will take some hours until the power fully comes back.
Right now I confirmed that at least the MC locks.
  1035   Wed Oct 8 21:26:20 2008 YoichiUpdatePSLAttempt to replace the DC-DC converter (aborted)
Rich, Steve, Yoichi

We opened the MOPA box and inspected our NPRO.
We concluded that this NPRO is different from the ones at the sites.
At the sites, the NPROs have a connector on the board which accepts the output of the DC-DC converter.
Rich's replacement DC-DC converter has a matching connector to it. So replacement of the DC-DC converter is easy.
In our NPRO, there is no such a connector found. The cables coming from the external power supply are directly soldered
on to the PCB (see attm1).

We have to take out the PCB in order to work on it.
As shown in the second picture, there is a D-SUB connector sticking out of the box through the rear panel.
In addition, the PCB is connected to the metal box containing the crystal with an IDE style connector.
This means the PCB is tightly constrained.
To take out the PCB without applying too much stress on it, we have to take off the rear panel.
To do so, we have to remove the screws on the bottom of the NPRO box. That means we have to move the NPRO.
We did not want to do so, because it will screw up the alignment to the amplifier.

The model number of the DC-DC converter looks like NMH0512-something.
According to the datasheet of NMH0512S, the switching frequency is typically 95kHz. We saw 77kHz harmonics in the FSS error signal.
I'm not sure if this is the culprit. I will try to measure the EMI from this guy later.
Attachment 1: DCDC.JPG
DCDC.JPG
Attachment 2: NPRO.JPG
NPRO.JPG
  1036   Wed Oct 8 22:23:43 2008 YoichiConfigurationElectronicsElectronics work bench cleanup
Yesterday, I cleaned up the electronics work bench. I figured that keeping the work bench
in order has larger effect on the work efficiency than buying expensive soldering stations.
Whoever works there should clean up the table after the work to the state shown on
the right side of the picture (at least).
If you leave the bench for a while (more than 30min) but intend to return later and
resume the work, please write your name and time on a piece of paper and put it on the bench.
Otherwise, your stuff can be taken away anytime.
Attachment 1: Cleanup.jpg
Cleanup.jpg
  1037   Wed Oct 8 23:18:23 2008 YoichiUpdatePSLCorrelation between the Sorensen switching noise and the FSS error signal
I took some spectra and coherence function of the FSS error signal and the +24V Sorensen power line.
The first plot shows spectra of the two signals. Looks like Sorensen is not responsible for most of the lines
in the FSS error signal.
The coherence function between the two signals supports it (second plot).
Slight coherence can be seen at 23kHz and 98.4kHz but not significant.

I will check the coherence of the power line with the ISS signal next.
Attachment 1: PowerLineSpe.png
PowerLineSpe.png
Attachment 2: Coherence.png
Coherence.png
  1038   Fri Oct 10 00:34:52 2008 robOmnistructureComputersFEs are down

The front-end machines are all down. Another cosmic-ray in the RFM, I suppose. Whoever comes in first in the morning should do the all-boot described in the wiki.
  1039   Fri Oct 10 10:20:42 2008 AlbertoOmnistructureComputersFEs are down

Quote:

The front-end machines are all down. Another cosmic-ray in the RFM, I suppose. Whoever comes in first in the morning should do the all-boot described in the wiki.


Yoichi and I went along the arms turning off and on all the FE machines. Then, from the control room we rebooted them all following the procedures in the wiki. Everything is now up again.

I restored the full IFO, re-locked the mode cleaner.
  1040   Fri Oct 10 13:57:33 2008 AlbertoOmnistructureComputersProblems in locking the X arm
This morning for some reason that I didn't clearly understand I could not lock the Xarm. The Y arm was not a problem and the Restore and Align script worked fine.

Looking at the LSC medm screen something strange was happening on the ETMX output. Even if the Input switch for c1:LSC-ETMX_INMON was open, there still was some random output going into c1:LSC-ETMX_INMON, and it was not a residual of the restor script running. Probably something bad happened this monring when we rebooted all the FE computers for the RFM network crash that we had last night.

Restarting the LSC computer didn't solve the problem so I decided to reboot the scipe25 computer, corresponding to c1dcuepics, that controls the LSC channels.

Somehow rebooting that machine erased all the parameters on almost all medm screens. In particular the mode cleaner mirrors got a kick and took a while to stop. I then burtrestored all the medm screen parameters to yesterday Thursday October 9 at 16:00. After that everything came back to normal. I had to re-lock the PMC and the MC.

Burtrestoring c1dcuepics.snap required to edit the .snap file because of a bug in burtrestore for that computer wich adds an extra return before the final quote symbol in the file. That bug should be fixed sometime.

The rebooting apparently fixed the problem with ETMX on the LSC screen. The strange output is not present anymore and I was able to easily lock the X arm. I then run the Align and the Restore full IFO scripts.
  1041   Fri Oct 10 20:03:35 2008 YoichiConfigurationComputersmedm, dataviewer, dtt on 64 bit linux
I compiled EPICS (base, medm and ezca) and dataviewer for 64 bit linux.
These are installed in /cvs/cds/caltech/apps/linux64/.
I also configured cshrc.40m to make it possible to run the 32bit dtt on 64bit machines.
64bit ligotools is also installed to /cvs/cds/caltech/apps/linux64/ligotools although I haven't tested it extensively.

With those essential tools available for 64bit linux, Joe and I decided to install 64bit CentOS to the new linux machine.
It is named allegra.
Now, medm, dataviewer, dtt, awg, foton and ezca commands all work on rosalba and allegra.
I put some notes on how to make things work on 64bit in the wiki.
http://lhocds.ligo-wa.caltech.edu:8000/40m/Building_LIGO_softwares_for_64_bit_linux

I compiled dtt (actually the whole GDS tree) for 64bit linux and the build process finished normally.
But somehow dtt does not work properly. It starts on my laptop but does not retrieve data. It crashes on rosalba.
So I had to retreat to 32bit.
  1042   Mon Oct 13 11:32:50 2008 YoixhiUpdatePSLMOPA is in trouble now
Steve, Alberto, Yoichi

A quick update.
The MOPA output went down to zero on Sunday early morning (00:28 AM).
We found that the NPRO beam is mis-aligned on the power monitoring PD (126MON).
We don't know yet if it is also mis-aligned to the power amplifier (PA) because the mechanical shutter is not working (always closed).
Most likely the beam is not aligned to the PA.
A mystery is that although the beam is terribly (more than a half inch) missing the monitor PD, the beam still goes through two faradays.
Another mystery is that the NPRO output power is now increased to 600mW.

The power drop was a very fast phenomenon (less than 1/16 sec).
We are trying to figure out what happened.
The first step is to fix the mechanical shutter. We have a spare in our hand.
Attachment 1: powerdrop.png
powerdrop.png
  1043   Mon Oct 13 13:51:49 2008 peteConfigurationPSLattempt to measure FSS ref phase
On Friday I began a measurement of the FSS reference phase. The setup involves the following:
+ turn off the 166 MHz LO (top signal generator on 1Y2 rack)
+ bring FSS LO 21.5 MHz to the 166 MHz delay line phase shifter, and back out the phase shifter with a second length of cable
+ add a length of cable to the RF 21.5 MHz in preparation for measuring FSS IN2 as a function of delay

Trouble locking the FSS, and ran out of time before the measurement could be performed.
  1044   Mon Oct 13 13:56:03 2008 YoichiUpdatePSLMOPA is not that much in trouble now
The problem was found to be all to do with the shutter.
The shutter started to work again, after a while, apparently for no clear reason.
The alignment to the PA was actually not screwed, and the MOPA output is now slowly increasing.
We figured that the 126MON PD has been mis-aligned for a long time. It was just picking the
scattered light from the output of the PA. So when the shutter is closed, it is natural that 126MON also goes down to zero.
It is a bit difficult to center the beam on the PD because there is not much room for moving the PD.
However, Alberto came up with a configuration (flip the PD and reflect back the beam with a mirror to the PD), which seems to
be feasible. We will do this modification when the MOPA is confirmed to be ok.

Here is more detail about the shutter problem:
The shutter is controlled by the MOPA power supply. There are three ways to command the power supply.
The switch on the front panel of the power supply, the EPICS switch (through a XYCOM XY220), and the interlock.
The ribbon cable from the power supply's back is connected to J1 of the cross connect. The pin 59 of the cable is the one
controlling the shutter. It is then routed to J12 pin 36. The interlock and a XYCOM switch are both connected to this
pin.
Now what happened was, on the way tracking down those cables, I pushed some connectors, especially the ones on the XYCOM.
After that, I was able to open the shutter from the EPICS button.
Steve and Alberto tried the EPICS button many times in the morning without success.
My guess is that it was some malfunctioning of the XY220 accidentally fixed by my pushing of the cables.
But I cannot exclude the possibility of the interlock malfunctioning.



Quote:
Steve, Alberto, Yoichi

A quick update.
The MOPA output went down to zero on Sunday early morning (00:28 AM).
We found that the NPRO beam is mis-aligned on the power monitoring PD (126MON).
We don't know yet if it is also mis-aligned to the power amplifier (PA) because the mechanical shutter is not working (always closed).
Most likely the beam is not aligned to the PA.
A mystery is that although the beam is terribly (more than a half inch) missing the monitor PD, the beam still goes through two faradays.
Another mystery is that the NPRO output power is now increased to 600mW.

The power drop was a very fast phenomenon (less than 1/16 sec).
We are trying to figure out what happened.
The first step is to fix the mechanical shutter. We have a spare in our hand.
  1045   Mon Oct 13 18:59:39 2008 YoichiUpdatePSLNPRO EMI and FSS error signal correlation
I made a simple loop antenna to measure the electro-magnetic inteference (EMI) around the master oscillator NPRO.

The first plot shows the comparison of the FSS error signal with the EMI measured when the antenna was put next to the NPRO (the MOPA box was opened).
There are harmonics of 78.1kHz which are present in both spectra. It is probably coming from the DC-DC converter in the NPRO board.

The second plot is the same spectra when the antenna was put far from the NPRO (just outside of the PSL enclosure).
The 78.1kHz harmonics are gone. So these are very likely to be coming from the NPRO.

The third plot shows the coherence functions between the signal from the antenna and the FSS error signal.
When the antenna was put near the NPRO, there is a strong coherence seen around 78.2kHz, whereas there is no strong coherence
when the antenna is far away from the NPRO.
This is a strong evidence that the 78.2(or 78.1)kHz harmonics is coming from the NPRO itself.

There are many peaks other than 78.1kHz harmonics in the FSS error signal spectrum. For most of them you can also find corresponding peaks in the EMI spectrum.
We have to hunt down those peaks to avoid the slew-rate saturation of the FSS.
Attachment 1: IMG_1692.JPG
IMG_1692.JPG
Attachment 2: Spectrum.png
Spectrum.png
Attachment 3: SpectrumFar.png
SpectrumFar.png
Attachment 4: Coherence.png
Coherence.png
  1046   Tue Oct 14 14:19:36 2008 peteConfigurationPSLFSS ref phase
Today I made several measurements which should yield the optimized phase for the FSS 21.5 MHz reference. I made two sets of measurements, using the 166 MHz phase delay shifter. For each phase value I made 5 measurements of a 500 kHz injection into test2 at 1 Vpp, with the 4195 spectrum analyzer on in1 with the high impedance probe, 51 points, a 10 kHz range. It was surprisingly noisy. I will make plots using matlab to find the maximum, and hope for consistent results between the two sets of measurements. If it is too noisy or inconsistent I will repeat the measurement at ~800 kHz.

Once I find the phase which yields peak amplitude in in1, I will measure the relative phase between LO and RF going in to the FSS, measure the speed of light in RG58 cable, and construct a new cable which will implement the desired relative phase.
  1047   Tue Oct 14 19:18:18 2008 YoichiUpdateComputersBootFest
Rana, Yoichi

Most of the FE computers failed around the lunch time.
We power cycled those machines and now all of them are up and running.
I confirmed that the both arms lock.
Now the IFO is in "Restore last auto-alignment" status.
  1048   Tue Oct 14 19:24:34 2008 YoichiConfigurationPSLFSS 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.
  1049   Wed Oct 15 17:40:50 2008 ranaUpdatePSLPMC Offset adjusted
I set the PMC servo input offset: closed the MOPA shutter, zeroed the mixer output with the offset slider,
relocked everything, and set the nominal to the new value of -6 V.
  1050   Wed Oct 15 22:07:52 2008 peteConfigurationPSLFSS 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
phasedelay.png
  1051   Thu Oct 16 09:44:49 2008 YoichiUpdatePSLBad cable for FSS
Yesterday arount 1:30PM, we lost the LO signal for the FSS.
I found it was caused by a bad cable connecting from the peter's RF oscillator box to the LO of the FSS.
I temporarily replaced it with a BNC cable of comparable length.
  1052   Thu Oct 16 09:47:49 2008 YoichiConfigurationPSLFSS 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 peteConfigurationPSLphase 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 peteConfigurationPSLFSS 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 YoichiConfigurationComputersmcup/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.
  1056   Fri Oct 17 21:41:09 2008 YoichiUpdateComputer Scripts / Programsburtwb missing on Solaris but installed on linux64
c1lsc stalled this evening, so I powercycled it.
After that, I tried to lock arms to confirm the computer is working.
Then I realized that the restore alignment buttons do not work from any control room computer.
I found that it was because burtwb command was missing. For Solaris, looks like there used to be /cvs/cds/epics/extensions/burtwb but now
there is no /cvs/cds/epics directory. I thought there were directories other than "caltech" in /cvs/cds/, weren't there ?
Right now, there is only /cvs/cds/caltech.
Anyway, I installed burt for 64bit linux computer (under /cvs/cds/caltech/apps/linux64/epics/extensions/).
At this moment the alignment save/restore works on allegra (and probably on rosalba), but not on op440m yet.
  1057   Mon Oct 20 09:45:56 2008 steveUpdatePEMPSL HEPA on
The PSL HEPA filter was turned on.
It should be running all times.
The 0.5 micron particle count is up to 20,000 this morning.
  1058   Mon Oct 20 12:18:38 2008 AlanUpdateComputer Scripts / Programsburtwb missing on Solaris but installed on linux64

Quote:
c1lsc stalled this evening, so I powercycled it.
After that, I tried to lock arms to confirm the computer is working.
Then I realized that the restore alignment buttons do not work from any control room computer.
I found that it was because burtwb command was missing. For Solaris, looks like there used to be /cvs/cds/epics/extensions/burtwb but now
there is no /cvs/cds/epics directory. I thought there were directories other than "caltech" in /cvs/cds/, weren't there ?
Right now, there is only /cvs/cds/caltech.
Anyway, I installed burt for 64bit linux computer (under /cvs/cds/caltech/apps/linux64/epics/extensions/).
At this moment the alignment save/restore works on allegra (and probably on rosalba), but not on op440m yet.



The automatic backup of /cvs/cds (and /frames/minute-trends ) to the LIGO archive in Powell-Booth,
which runs from fb40m using the scripts in /cvs/cds/caltech/scripts/backup ,
stopped when fb40m was rebooted on June 28, 2008,
and the check_backup script I run to send an email when this happens also failed due to a scripting error.

But we still have a backup of /cvs/cds from June 27.

The backup of /cvs/cds (excluding /cvs/cds/caltech and /cvs/cds/tmp)
circa June 27, 2008
has been restored to
/cvs/cds/recover_20081020 .

Please check to see that it has what we need.

Before moving it over to where it belongs,
it would be really nice to figure out what happened...

Meanwhile, I have fixed the check_backup script and restarted the backup, which will run this evening...
but maybe I should wait till the dust settles?

Now is also a good time to think about whether there is anything else besides for
/cvs/cds and /frames/minute-trends that should be backed up regularly.


- Alan
  1059   Mon Oct 20 15:02:00 2008 YoichiConfigurationComputers/cvs/cds restored
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 AlanConfigurationComputers/cvs/cds restored

Quote:
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.


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
ELOG V3.1.3-