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

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)).
  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.
  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.
  1061   Mon Oct 20 20:50:09 2008 YoichiConfigurationPSLFSS 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.
  1063   Tue Oct 21 16:17:45 2008 YoichiUpdatePSLAD797 Oscillation in the FSS board
I checked each op-amp's output in the FSS board to see if any indication of slew-rate saturation can be found.
PA85, which was the most suspicious one, actually has a very large slew rate limit (1000V/usec).
Its output swing was about 5V/usec. So PA85 was ok in terms of slew rate.
However, I found that an AD797 used at the first stage of the PC path was oscillating by itself, i.e. even without the loop closed.
The frequency was about 50MHz and the amplitude was large enough to reach the slew rate limit of this chip (the steepest slope was 30V/usec whereas the slew
rate limit of AD797 is 20V/usec).

I replaced it and another AD797 right after the oscillating one with AD829s. Just replacing the chips caused oscillation of AD829.
It was because there were no phase compensation capacitors connected to the pin 5 of AD829s.
Since the PCB was designed for AD797, there is no pattern for compensation caps. So I ended up putting Mica capacitors (47pF) across the pin 5 and the nearest ground point.
It worked and the oscillation stopped.

As I reported in an earlier elog, stopping the oscillation did not solve the problem of low FSS bandwidth.
  1065   Tue Oct 21 18:19:42 2008 YoichiConfigurationComputersLISO 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.

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
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
  1069   Wed Oct 22 17:48:58 2008 YoichiUpdateGeneralLenses for focusing the optical lever laser (Re:divergence of He Ne 1035P)
Steve had difficulty in finding lenses for focusing the HeNe laser for the ITM op-lev.
Following his measurement of the beam divergence, I did some calculation to find a suitable set of lenses and positions.

First, I fitted Steve's data to get the waist size and location of the new HeNe.
The first plot shows the fitting result.
The size of the waist is 0.3mm at -367mm from the laser output (i.e. inside the laser).
(I only used horizontal beam size data.)

Then using the obtained beam parameter, I calculated the propagation of the beam through two lenses.
After playing with the focal length and location of the lenses, I found that with parameters {f1=-0.125m, f2=0.2m, d1=0.2m, d2=0.1m} we get about 1mm beam at the QPD (about 4m away from the laser). f1 and f2 are the focal lengths of the lenses, d1 is the distance from the laser to the first lens and d2 is the distance between the two lenses.
The second plot shows the beam size as a function of the distance from the laser.

The Mathematica notebook used to plot the beam propagation is attached.
By running it on Mathematica 6, you can dynamically change the parameters (focal lengths and locations) by sliders, and the plot (like the one shown in the second attachment) updates in real time. It is cool. Please try it.

The ITM oplevs laser diodes are noisy.
They will be replaced by JDS 1035P
SN T8093307 was measured with the beamscanner.
This will able us to calculate the right lenses to get a small beam on the qpd.

The first column is distance from the front face of the laser in cm.
The second column is beam diameter in the horizontal direction in microns.
The third column is the beam diameter in the vertical direction in microns.
(edit by Rana)
Attachment 1: BeamProfile.png
Attachment 2: BeamPropagation.png
Attachment 3: BeamPropagation.zip
  1079   Thu Oct 23 21:52:27 2008 YoichiUpdatePSLFSS UGF now 450kHz
I measured the open loop transfer function of the FSS, for the first time after I mitigated the oscillation.
The attached plot shows the comparison of the OPLTF before and after the oscillation was mitigated.
Blue curves are when AD797 was oscillating, and the red ones are after AD797s were replaced by AD829s.
The FSS gain slider values are the same for the both measurements.
There is a notable difference in the shape of the TF.
Right now the UGF is around 450kHz with the phase margin of 50deg.
When the gain is increased by a few dBs in the common gain slider, the PC path becomes saturated.
This might be caused by the peak in the OPLTF at 1.7MHz sticking out of the 0dB line.
Another peak at 770kHz is also annoying.
Too bad that I did not take the TF above 1MHz before the oscillation was mitigated.
Also at 100kHz, the new TF has a lower gain than the old one, although it looks like the slope of the red curve is getting steeper and
it is catching up the blue one at lower frequencies.
I will measure the TF below 100kHz later.

With this bandwidth, I was able to increase the MC gain further.
I will report on the MC open loop measurements soon.
Attachment 1: FSS_OPLTF.png
  1080   Thu Oct 23 23:09:18 2008 YoichiUpdatePSLMC UGF is now 75kHz
I measured three loop transfer functions of the MC servo.
The blue curve in the first attachment is the overall open loop gain of the servo measured using
the sum-amp A of the MC board (it is the sum-amp in the common part).
The red curve is the transfer function measured by the sum-amp B of the MC board, which is in the VCO path.
Mathematically the measured transfer function is G_vco/(1+G_L), where G_L is the loop gain of the length path
and G_vco is the loop gain of the VCO path.
The green curve is G_L/(1+G_vco) which was measured from dtt by using C1:SUS-MC2_MCL_EXC.
The UGF of the MC loop is 75kHz with the phase margin of 27deg.
The cross over frequency of the two loops is 43Hz. The phase margin there seems OK.

The second attachment is the comparison of the MC open loop TF measured on Sep. 4 (old) and today (new).
The increased bandwidth of the FSS gave us a slight gain in the phase margin and the elimination of
the slight bump in the gain around 150kHz existed in the blue curve.
Attachment 1: MC_Loop.png
Attachment 2: OldAndNew.png
  1081   Fri Oct 24 10:06:16 2008 YoichiConfigurationIOOMC 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.
  1092   Mon Oct 27 10:02:16 2008 YoichiUpdateComputer Scripts / ProgramsSVN medm problem
I tried to check out medm directory both from my laptop and nodus.
I did not get the error.
Have you already fixed it ? Or maybe it is to do with the version of the svn used to checkout ?

As we've seen in the past a few times, there's something wrong with the files in the trunk/medm area.
I get the following error message when doing a fresh checkout:
A    c1/lsc/help/C1LSC_LA_SET.txt
svn: In directory 'c1/lsc/help'
svn: Can't copy 'c1/lsc/help/.svn/tmp/text-base/C1LSC_RFadjust.txt.svn-base' to 'c1/lsc/help/.svn/tmp/C1LSC_RFadjust.txt.tmp.tmp': No such file or directory
It looks like that there are some .svn files which have been checked in as if they're some kind of source code instead of just maintenance files.
We probably have to go through and clean this out and then remove these excess files somehow.
  1095   Mon Oct 27 14:48:27 2008 YoichiConfigurationPSLEO 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.
  1099   Wed Oct 29 12:23:04 2008 YoichiConfigurationPSLMZ 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.
  1101   Thu Oct 30 11:07:25 2008 YoichiUpdateComputersWireless bridges arrived
Five wireless bridges for the GPIB-Ethernet converters arrived.
One of them had a broken AC adapter. We have to send it back.
I configured the rest of the bridges for the 40MARS wireless network.
One of them was installed to the SR785.
I put the remaining ones in the top drawer of the cabinet, on which the label printers are sitting.
You can use those to connect any network device with a LAN port to the 40MARS network.
  1110   Mon Nov 3 21:38:32 2008 YoichiConfigurationGeneralnew elog

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:

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.
  1136   Fri Nov 14 19:20:42 2008 YoichiUpdatePSLReference cavity ring down
Thanks to Bob making the high-voltage BNC cables for the HV pulse generator, I was able to operate the EOM in front of
the reference cavity.

The conceptual setup is the following:
[HV pulse] ----+           +-->-- [PD2]
               V           |
->--[HWP]->-- [EOM] -->-- [PBS] --<->-- [QWP] --<->-- [Reference Cavity] -->-- [PD1]
                [PD3] --<--+

The high voltage pulse rotates the polarization of the light after the EOM. When the HV is applied, the PBS reflects most of the light
into PD2 (Thorlabs PDA255), shutting down the incident light into the cavity.
The transmitted light power of the reference cavity is monitored by PD1 (PDA255). The reflected light from the reference cavity
is monitored by the DC output of the RF PD (PD3). PD3 is low-passed so the response is not fast.
Thorlabs says PDA255 has 50MHz bandwidth.

The attached plot shows the time series of the above PD signals when the HV was applied.
Input Pulse (blue curve) is the input to the HV pulse generator. When it is high, the HV is applied.
"PBS reflection" (red) is PD2. "Reflection" (green) is PD3. "Transmission" (light blue) is PD1.

The red curve shows huge ringing. At first I thought this was caused by the bad response of the PD.
However, the same ringing can be seen in the PD3 and the peaks match very well.
When red curve goes down the green curve goes up, which is consistent with the energy conservation.
So it looks like the light power is actually exhibiting this ringing.
May be the HV pulse is distorted and the voltage across the EOM is showing this ringing.
I will check the input voltage shape to the EOM using a high impedance probe, if possible.

The green curve shows a slow decay because it has a long time constant. It is not an actual
trend of the reflected light power.

The RC transmission power shows some peaks, probably due to the ringing in the input power.
So just fitting with an exponential would not give a good estimate of the cavity pole.
Even though, we should be able to de-convolute the frequency response of the reference cavity
from the input (red curve) and output (light blue curve) signals.
Attachment 1: RingDown.png
  1138   Fri Nov 14 22:40:51 2008 YoichiUpdatePSLReference cavity ring down


To make the DEI pulser make a fast pulse on the EO shutter EOMs, we had to make sure:

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

I'll check it with Bob.


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

Did you use a shunt or series resistor ?
If shunt, I guess it has to have a huge heat sink.
Actually, DEI says the pulser does not require any external shunt/series resistors or impedance-matching network.
Looks like it is not true ...


3) We needed ~3.5 kV to get the EO shutter crystal to flip the light by 90 deg.

Yes, I adjusted the voltage to maximize the power change and it was about 3.5kV.
  1140   Mon Nov 17 15:07:06 2008 YoichiUpdatePSLReference cavity ring down
I used MATLAB's system identification tool box to estimate the response of the reference cavity, i.e. cavity pole.
What I did was basically to estimate a model of the RC using the time series of the measured input and output power.

First, I prepared the input and output time series for model estimation.
The input is the input power to the RC, which I produced by inverting the PBS reflected light power and adding an offset
so that the signal is zero at t=0. Offset removal was necessary to make sure that the input time series does not give an
unintentional step at t=0.
The output time series is the transmission power of the RC. I also added an offset to make it zero at t=0.
Then I commanded MATLAB to compute the response of a first order low-pass filter to the input and try to fit
the computed response to the measured output by iteratively changing the gain and the cut-off frequency.
("pem" is the name of the command to use if you are interested in).

The result is shown in the attachment.
Blue curve is the input signal (I added a vertical offset to show it separately from the output).
The green curve is the measured output (RC transmission). The red curve is the response of the estimated model.
The estimated cut-off frequency was about 45kHz.

You can see that the red curve deviates a lot from the green curve after t=15usec.
By looking at this, I realized that the bandwidth of the RC cavity servo was too high.
The time scale we are looking at is about 50kHz whereas the FSS bandwidth is about 400kHz.
So when the input light was cut off, the error signal of the FSS becomes meaning less and the
input laser frequency was quickly moved away from the resonance. This is why the green curve does not
respond to the large peaks in the blue curve (input). The cavity was already off-resonance when the input power
showed bumps.

Since the red curve matches nicely with the green curve at the very beginning of the ring down, the estimated 45kHz
cavity pole is probably not that a bad estimate.

To make a better measurement, I will try to reduce the bandwidth of the RC servo by using only the PZT actuator.
If there were no ringing in the input light power, we wouldn't have to worry about the bandwidth of the servo because our
feedback is all made to the laser, not the cavity length.
In order to reduce the ringing in the input power, I asked Bob to make new HV cables using HV grade coax cables.
Attachment 1: Fit.png
  1144   Tue Nov 18 19:37:23 2008 YoichiUpdateIOOMC1 OSEM signals sign flipped and c1susvme1 restart problem
Around 2PM, MC1 started to swing crazily.
The damping feedback was not working and it was actually exciting the mirror wildly.
It turned out that the sign of the UR and UL OSEM signals flipped at that time.
Restarting c1sosvme fixed the problem.

While I was looking for the cause of the problem, c1susvme1 and c1susvme2 failed several times.
I don't know if it is related to this problem.
Now it is not trivial to restart c1susvme1. It fails to restart if you just power cycle it.
Alberto and I had to connect an LCD and a keyboard to it to see what was going on. After pushing the reset button on the front panel,
I had to press Ctrl+x. Otherwise, the state LED of c1susvme1 stays red and nothing happens.
After Ctrl+x, the boot screen came up but the boot sequence failed and an error message something the following was shown:
"PXE Boot failed, check the cable"
So I swapped the network cable with c1susvme2, which was already up and running.
This time, c1susvme1 started fine and surprisingly, c1susvme2 stayed alive.
Currently, both c1susvme1 and c1susvme2 are up and running with the LAN cables swapped.
We have to check the LAN cables.
  1177   Fri Dec 5 01:41:33 2008 YoichiConfigurationComputersMEDM 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 YoichiConfigurationASCtdscntr.pl now works at 40m
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.
  1181   Fri Dec 5 20:40:38 2008 YoichiHowToComputersElog multi-keyword search
The current Elog search allows you to look for only one keyword in the text.
You cannot search for two keywords by simply separating them with a white space.
That is, a search term "abc def" matches a literal "abc def", not a text containing "abc" and "def".
This is extremely annoying. However, there are still some ways to search for multiple keywords.
The Elog search fields are treated as regular expressions.
In order to match a text containing "abc" and "def", you can use a search term "abc.*def".
A period (.) means "any character", and an asterisk (*) means "any number of repetition of the preceding character".
Therefore, ".*" matches "any number of any character" i.e. anything.
The search term "abc.*def" works fine when you know "abc" appears first in the text you are looking for.
If you don't know the order of appearance of the keywords, you have two choices: either to use,
The vertical bar (|) means "or". Parentheses are used for grouping.
The first example does exactly what you want. However, you have to list all the permutations of your keywords
separated by |. If you have more than two keywords, it can be a very very long search word.
(The length of the search word is O(n!), where n is the number of keywords).
In the second example, the length of the keyword is O(n). However, it can also match a text containing two "abc".
This means the search result may contain some garbages (entries containing only "abc").
I guess in most cases we can tolerate this.

To automatically construct a multiple keyword search term for the Elog, I wrote a bash script called elogkeywd
and it is installed in the control room machines.
You can type
elogkeywd keyword1 keyword2 keyword3
to generate a regular expression for searching a text containing "keyword1", "keyword2" and "keyword3".
The generated expression is of the second type shown above. You can then copy-and-paste the result to
the Elog search field.
The script takes any number of keywords. However, there seems to be a limit on the number of characters you can type
into the search field of the Elog. I found the practical limit is about 3 keywords.
  1182   Fri Dec 5 21:31:11 2008 YoichiUpdateIOOdrum modes observable without excitation
The calibration of the MC_F feedback is posted in elog:1032.
I'm not sure where Caryn took MC signal, but if you take the signal from the servo out BNC on the MC board, it
directly corresponds to the voltage sent to the FSS VCO.
The DC calibration of the VCO is 1.75MHz/V. Since the AOM is the double-pass, the PSL frequency
change is 3.5MHz/V. At frequencies above 40Hz, the VCO calibration drops by a factor of 39/1000,
because of the pole/zero at 1.6Hz/40Hz in the VCO box.
So at the frequencies of interest (around 30kHz), the servo out voltage can be converted to the PSL frequency
change by 0.137MHz/V.
Since 30kHz is still within the bandwidth of the MC servo, the feedback signal should correspond to the actual
length change of the MC. So the above calibration factor can be used to calibrate Caryn's measurement and check
what Rana suggested.
  1186   Mon Dec 8 11:41:27 2008 YoichiSummaryVACThe rough pump for the TP2 replaced
Bob, Yoichi

The foreline pressure of the TP2 (the foreline pump for the main mag-lev turbo (TP1)) was at 2.8torr this morning
when Bob came in.
Looked like the foreline pump (Varian SH-110) was leaking.
Bob started the backup rough pump in parallel with the "leaking" one to keep the foreline pressure low.
We then closed the valve 4 (between TP2 and TP1) and stopped the TP2 and the SH-110.
We replaced SH-110 with another one, but still the foreline pressure was high.
So we replaced it with yet another one. We also changed the quick coupling fasteners on the SH-110 and wiped the O-rings.
This time, it worked fine and the foreline pressure dropped to around 38 mTorr.

Since there is no valve between the TP2 and the SH-110, we could not keep the TP2 running while we were replacing the
problematic SH-110. This means the TP1 was running without a foreline pump during the work. We tried to minimize the
down time of the TP2. The temperature of the TP1 was 33.6C before we stopped the TP2 and it went up to 37.3C during the
work. It is now coming down to the original temperature.

Since we don't know if the problem was caused by bad SH-110s or leaking quick couplings, Bob is checking these apparently
"leaking" SH-110s.
  1187   Mon Dec 8 11:54:27 2008 YoichiUpdateGeneralIFO mirrors aligned
This morning, I re-aligned the IFO mirrors to see if they were badly moved by the earthquake.
The both arms locked just by the restoring scripts, but the transmission was about 0.7. So I aligned them
with the dithering scripts.
To lock the PRMI, I had to manually tweak the PRM alignment. After running the dithering script, the SPOB
went up to 1200.
I also had to tweak the SRM to get the DRMI locked. After the dithering script, the SPOB was 4200 and REFL166Q
was 3000.
  1188   Mon Dec 8 17:50:21 2008 YoichiUpdateSUSITMY drift
The suspension drift monitor shows that the ITMY alignment was shifted after the earthquake.
Looks like only the UL sensor had a step at the earthquake (see the attachment 1).
So it is probably an electronics problem.
I pushed in the cable between the rack and the ITMY satellite amplifier, but no change observed.
Actually, the ITMY-UL sensor looks like it has been dead before the earthquake.
The second attachment shows a long-term trend of the UL sensor.
The sensor output had been around zero since Nov. 17th.
When I disabled the output of the UL sensor, the sus-drift-mon fields turned green.
So I think the drift-mon's reference values are wrong, and currently the ITMY is in a good alignment.

I also attached the free-swing measurements of the ITMY taken on Aug. 18th and today.
There is no notable change in the resonant frequencies.
Attachment 1: ITMY-OSEMs.png
Attachment 2: ITMY-UL.png
Attachment 3: ITMY-08-18.pdf
Attachment 4: ITMY-12-08.pdf
  1190   Fri Dec 12 22:51:23 2008 YoichiUpdatePSLReference cavity ring down measurement again
Bob made new HV-cables with HV compatible coaxes. The coax cable is rated for 2kV, which was as high as Bob
could found. I used it with 3kV hoping it was ok.
I also put a series resistor to the pockels cell to tame down the ripples I saw in elog:1136.

Despite those efforts, I still observed large ringings.
I tried several resistor values (2.5k, 1k, 330ohm), and found that 330ohm gives a slightly better result.
(When the resistance is larger, the edge of the PBS Refl. becomes dull).
Since the shape of the ringing does not change at all even when the pulse voltage is lowered to less than 1kV,
I'm now suspicious of the DEI pulser.

Anyway, I estimated the cavity pole using the MATLAB's system identification toolbox again.
This time, I locked the reference cavity using only the PZT feedback, which makes the UGF about a few kHz.
So, within the time scale shown in the plot below, the servo does not have enough time to respond, thus the laser
frequency stays tuned with the cavity. This was necessary to avoid non-linear behavior of the transmitted power
caused by the servo disturbing the laser frequency. With this treatment, I was able to approximate the response of
the cavity with a simple linear model (one pole low-pass filter).

MATLAB estimated the cavity pole to be 47.5kHz.
The blue curve in the plot is the measured RC transmitted power.
The incident power to the cavity can be inferred from the inverse of the red curve (the PBS reflection power).
The brown curve is the response of the first order low-pass filter with fc=47.5kHz to the input power variation.
The blue and brown curves match well for the first 10usec. Even after that the phases match well.
So the estimated 47.5kHz is probably a reasonable number. I don't know yet how to estimate the error of this measurement.

According to http://www.ligo.caltech.edu/~ajw/PSLFRC.png the designed transmission of the reference cavity mirrors is 300ppm (i.e.
the round trip loss (RTL) is 600ppm).
This number yields fc=35kHz. In the same picture, it was stated that fc=38.74kHz (I guess this is a measured number at some point).
The current fc=47.5kHz means, the RTL has increased by 200ppm from the design and 150ppm from the time fc=38.74kHz was measured.
Attachment 1: RC-Ringdown.png
  1191   Tue Dec 16 19:06:01 2008 YoichiUpdatePSLReference cavity ring down repeated many times
Today, I repeated the reference cavity ring down measurement many times to see how much the results vary.

I repeated the ring down for 20 times and the first attachment shows the comparison of the measured and estimated cavity transmission power.
The blue curve is the measured one, and the red curve is the estimated one. There are only 10 plots because I made a mistake when transferring data
from the oscilloscope to the PC, and one measurement data was lost.

The second attachment shows the histogram of the histogram of the estimated cavity pole frequencies.
I admit that there are not enough samples to treat it statistically.
Anyway, the mean and the standard deviation of the estimated frequencies are 47.6kHz and 2.4kHz.
Assuming a Gaussian distribution and zero systematic error, both of which are bold assumptions though, the result is 47.6(+/-0.6)kHz.

Now I removed the Pockels Cell from the RC input beam path.
I maximized the transmission by tweaking the steering mirrors and rotating the HWP.
Since the transmission PD was saturated without an ND filter on it, I reduced the VCO RF power slider to 2.85.
Accordingly, I changed the nominal common gain of the FSS servo to 10.5dB.
Attachment 1: RC_Ringdown_Estimates.png
Attachment 2: Cavity_Pole_Histogram.png
  1200   Sun Dec 21 14:18:04 2008 YoichiUpdateComputersRFM network bypass box's power supply is dead
I restarted the front-end computers by power cycling them one-by-one.
After issuing startup commands, most of them started normally at least by looking
at the output from telnet/ssh.
However, the status monitors of the FE computers on the EPICS screen are still red.
I noticed that all the LEDs on the VMIC 5594 RFM network bypass box are off.
According to the labels, fb40m, c0daqctrl, c0dcu are connected to the box.
This means (I believe) c1dcuepics cannot access the RFM network. So we have no control over
the FE computers through EPICS.

I pushed the reset button on the box, power cycled it, but nothing changed.
I checked the fuse and it was OK. Then I found that the power supply was dead.
It is a small AC adapter supplying +5VDC with a 5-pin DIN like connector.
We have to find a replacement.
  1201   Mon Dec 22 13:48:22 2008 YoichiUpdateComputersRFM network bypass box's power supply is dead
As a temporary fix, I cut the cable of the power supply and connected it to the Sorensen power supply +5V on the rack.
Now, the RFM bypass box is powered up, but some LEDs are red, which looks like a bad sign.
I restarted all the FE computers, but this time I got errors during the execution of the startup commands in the VxWorks machines.
The errors are "General Protection Fault" or "Invalid Opcode".
The linux machines do not show errors but still the status lights in EPICS are red.
We need Alex's help. He did not answer the phone, so Alberto left a voice mail.
  1202   Tue Dec 23 10:35:40 2008 YoichiUpdateComputersRFM network breakdown mostly fixed
Rana, Rolf, Alberto, Yoichi

The source of the problem was the RFM bypass box, as expected.
Rana pointed out that the long cable I used to bring the 5V from the Sorensen to the box
may cause a large voltage drop considering that the box is sucking ~3A.
So we connected the cable to another power supply (5V/5A linear power supply).
Then the LEDs on the bypass box turned green from red, and everything started to work.

A weired thing is that when I connected the cable to the wrong terminals of the power supply which
have lower current supply capabilities, the supply voltage dropped to 3V, but still the LEDs on the bypass box
turned green. This means the bypass box can live with 3V.
I noticed that there is a long cable from the Sorensen to the cross connect on the side of the rack, where I
connected my cable to the bypass box. This long cable had somewhat large resistance (1 or 2 Ohms) and dropped
the supply voltage to less than 3V ?
Anyway, the bypass box is now on a temporary power supply. Alberto was assigned a task to find a replacement power

There are two remaining problems.
c1susvme1 fails to start often claiming a DMA error on a Pentek. After several attempts, you can start the machine,
but after a while (1 hour ?) it fails again.
op340m is not responding to ssh login. It responds to ping.
We hooked up a monitor and keyboard (USB because the machine does not have a PS/2 port) to it and rebooted.
At the boot, it briefly displays a message "No keyboard, try TTYa", but after that no display signal.
Steve found me a serial cable. I will try to login to the machine using the serial port.

  1203   Wed Dec 24 10:33:24 2008 YoichiUpdateComputersSeveral fixes. Test point problem remains.
Yesterday, I fixed several remaining problems from the power failure.

I found a LEMO cable connecting the timing board to the Penteks was lose on the c1susvme1 crate.
After I pushed it in, the DMA error has not occured on c1susvme1.

I logged into op340m using a Null Modem Cable.
The computer was failing to boot because there were un-recoverable disk errors by the automatic fsck.
I run fsck manually and corrected some errors. After that, op340m booted normally and now it is working fine.
Here is the serial communication parameters I used to communicate with op340m:
>kermit      (I used kermit command for serial communication.)
>set modem type none
>set line /dev/ttyS0     (ttyS0 should be the device name of your serial port)
>set speed 9600
>set parity none
>set stop-bits 1
>set flow-control none

After fixing op340m, the MC locked.
Then I reset the HV amps. for the steering PZTs.
Somehow, the PZT1 PIT did not work. But after moving the slider back and forth several times, it started to work.

I reset the mechanical shutters around the lab.

I went ahead to align the mirrors. The X-arm locked but the alignment script did not improve
the arm power.
I found that test points are not available. (diag said test point management not available).
Looks like test point manager is not running. Called Rolf, but could not reach him.
I'm not even sure on which machine, the tp manager is supposed to be run.
Is it c0daqawg ?
  1204   Wed Dec 24 12:46:54 2008 YoichiUpdateComputersTest points are back
Rob told me how to restart the test point manager.
It runs on fb40m and actually there is an instruction on how to do that in the Wiki.

I couldn't find the page because when I put a keyword in the search box on the upper right
corner of the Wiki page and hit "enter", it only searches for titles. To do a full text
search, you have to click on the "Text" button.

Anyway, now the test points are back.
  1206   Mon Dec 29 21:38:57 2008 YoichiUpdateComputersSnapshots of MEDM screens
I wrote scripts to take snapshots of MEDM screens in the background.
These scripts work even on a computer without a physical display attached.
You don't need to have X running.
So now the scripts run on nodus every 5 minutes from cron.
The screen shots are saved in /cvs/cds/caltech/statScreen/images/

There is a wiki page for the scripts.

Someone has to make a nice web page summarizing the captured images.
  1207   Mon Dec 29 21:51:02 2008 YoichiConfigurationComputersWeb server on nodus
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

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
  1209   Wed Dec 31 22:59:40 2008 YoichiSummaryEnvironmentParticle counts going crazy
Yes it is a new year's eve, and a lot of crazy people are on Colorado to secure seats for the parade tomorrow.
They are burning woods to warm themselves. So smoky smell is floating around in the campus
and naturally the particle count is going up.

Actually at first I thought some building is on fire and called the security. Then they found
that it is the people on Colorado.

Now C1:PEM-count_half is 28400 and it is still climbing up.
  1210   Thu Jan 1 00:55:39 2009 YoichiUpdateASCAlignment scripts for Linux
A Happy New Year.

The dither alignment scripts did not run on linux machines because tdscntr and ezcademod do not run
on linux. Tobin wrote a perl version of tdscntr and I modified it for 40m some time ago.
Today, I wrote a perl version of ezcademod. The script is called ditherServo.pl and resides in /cvs/cds/caltech/scripts/general/.
It is not meant to be a drop-in replacement, so the command line syntax is different. Usage is explained in the comment of the script.

Using those two scripts, I wrote linux versions of the alignment scripts.
Now when you call, for example, alignX script, it calls alignX.linux or alignX.solaris depending on the OS of
your machine. alignX.solaris is the original script using the compiled ezcademod.
In principle, ezcademod is faster than my ditherServo.pl because my script suffers from the overhead of
calling tdsdmd on each iteration of the servo. But in practice ditherServo.pl is not that bad. At least, as far as
the alignment is concerned, the performances of the both commands are comparable in terms of the final arm power and the convergence.

Now the alignXXX commands from the IFO Configure MEDM screen work for X-arm, Y-arm, PRM and DRM. I did not write a script for Michelson, since
it is optional.
I confirmed that "Align Full IFO" works correctly.
  1211   Thu Jan 1 01:07:03 2009 YoichiSummaryEnvironmentParticle counts going crazy
I increased the fan speed of the PSL HEPA filter to the maximum.

Yes it is a new year's eve, and a lot of crazy people are on Colorado to secure seats for the parade tomorrow.
They are burning woods to warm themselves. So smoky smell is floating around in the campus
and naturally the particle count is going up.

Actually at first I thought some building is on fire and called the security. Then they found
that it is the people on Colorado.

Now C1:PEM-count_half is 28400 and it is still climbing up.
  1212   Thu Jan 1 01:15:45 2009 YoichiSummaryVACN2 line leak ?
I've been replacing the N2 bottles recently.
I noticed that the consumption is too high. I had to replace them every two days.
Normally the interval is three or more days.
I suspect there is some leak in the line.

Strangely, it is always the left hand bottle which goes empty. The right hand bottle has been
there for more than a week at about 1000 psi.

We should check it when Steve is back.
  1214   Fri Jan 2 18:49:54 2009 YoichiUpdateLSCLSC modulation frequencies adjusted
I noticed that the IFO did not lock in the MICH configuration.
This was because AS166Q signal was too small.
The demodulation phase seemed not right, i.e. the I-phase signal was larger than Q.
I suspected that the 166MHz modulation frequency was not exactly on the MC FSR, since I just
recovered the number written on the Marconi after the power failure.
I measured the optimal frequency by the method explained in elog:752.
It was 165981500Hz, which is pretty close to the number Rob measured in elog:952, but significantly different from
the label on the Marconi.
I set the frequencies of all the MARCONIs accordingly and updated the labels.

After this, the AS166 demodulation phase was still not good enough (the Q and I signals were about the same).
So I rotated the phase by 45deg. In principle, this should set the demod-phase right for DARM too. Is it correct, Rob ?
I also adjusted the PD offsets. After those adjustments, MICH locks stably with a slightly increased gain (20 as compared to 10 before).
  1223   Mon Jan 12 18:53:03 2009 YoichiUpdateLSCAS CCD centering and ASDD demod phase
After Rob's AS beam work, I centered the beam on the AS CCD.
I also optimized the ASDD demod-phase for the MICH signal.
Rob suggested to me that whenever we restart or change the frequency of the DD Marconis, we have to re-optimize the demod-phase
because the initial phase of the Marconi is random. We had the power failure, so it was time to do so.
I confirmed that MICH hand-off from REFL33Q to AS133DDQ is ok.
I will do the same thing for the PRCL, SRCL hand-offs.
  1231   Fri Jan 16 11:28:54 2009 YoichiUpdateComputersLab. laptop needs wireless lan driver update
One of the lab. laptops (belladonna) cannot connect to the network now.
I guess this was caused by someone clicked the update icon and unknowingly updated the kernel, which resulted in the wireless lan driver malfunctioning.
It was using a Windows driver through ndiswrapper.
Someone has to fix it.
  1234   Fri Jan 16 18:29:08 2009 YoichiUpdateSUSOplevs QPDs centered
Kakeru centered ITMX and BS optical levers with the help of Jenne on the walkie-talkie.
  1235   Fri Jan 16 18:33:54 2009 YoichiSummaryComputersc1lsc rebooted to fix 16Hz glitches
Kakeru, Yoichi

There were 16Hz harmonics in the PD3 and PD4 channels even when there is no light falling on it.
Actually, even when the connection to the ADC was removed, the 16Hz noise was still there.

Rob suggested that this might be digital problem, because data is sent to the daq computer very 1/16 of a second.

We restarted c1lsc and the problem went away.
  1236   Fri Jan 16 18:45:20 2009 YoichiConfigurationIOOMC_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
  1237   Mon Jan 19 13:58:53 2009 YoichiUpdateASCBetter ditherServo.pl
Nick Smith (@LHO) tested the ditherServo.pl at Hanford.
He added options to specify exit conditions to the script. Now you can make the script exit when
a condition, such as ArmPower > 1.0, is satisfied, or let it wait until a certain condition is satisfied.

I also modified the script to use ezcastep instead of tdswrite for feedback actuation.
The script now runs ezcastep in the background while the next iteration of the tdsdmd is performed.
Instead of kicking mirrors with a big thrust each time by a single tdswrite command, ezcastep gently moves the mirrors with fine steps.
I also implemented this "background ezcastep" technique in Tobin's tdscntr.pl.

The alignment scripts run smoother now.
ELOG V3.1.3-