Yesterday I measured the Open Loop Gain of the PLL in the absolute length experiment. The servo I used was that of the old Universal PDH box.

The OLG looks like this:

The UGF is at 10 KHz.

 To me, they both look stable. I guess that the phase has to go to -180 deg to be unstable.

Why does the magnitude go flat at high frequencies? That doesn't seem like 1/f.

How about a diagram of what inputs and outputs are being measured and what the gain knob and boost switch settings are?

This plot shows the Transmission for 532 and 1064 nm as a function of the thickness of the SiO2 layer.

i.e. the thickness is constrained so that the optical thickness of the SiO2 and Ta2O5 pair is always 1/2 of a wavelength.

The top layer of the mirror is also fixed in this plot to be 1/2 wave.

This plot shows the result for 17 pairs. For 16 pairs, we are unable to get as low as 15 ppm for the 1064 nm transmission.

This is perhaps best put in the LLO elog, but I'm not yet a 'person' there, so I can't write to their elog (yet another thing for the eternal to-do list).  So for now, we're putting things here...

This isn't totally finalized, but I do want to get what I have posted before I hop on a plane in the morning.  Mostly it just needs more time to run, to make the plot longer.  Hopefully I'll be able to edit this in the morning and have a longer-duration plot. 

What's plotted:

This spectrogram shows the amplitude spectra of L1:LSC-DARM_CTRL, after being subtracted via a Static Wiener Filter.  Each spectra is normalized by the very first one, which was created from the same data that was used to determine the Wiener Filter.  The X-axis is time.  The Y-axis is frequency, and the Color/Z-axis is amplitude in dB.  I'm only looking at Science Mode time, so other times when the IFO isn't in science mode, I plot a black stripe to fill in the plot.  The start time of the plot is 83675598, which is Jul 08 2006 06:33:04 UTC. 

Why?

The idea is to see that the filter does equally well a long time after it was created, as when it was initially made.  This will help tell us how often it is useful to recompute the Wiener filters.  Less often is nice, because redoing the Wiener filters may also include remeasuring the high precision transfer functions...if the filter isn't working as well anymore it may be because the transfer function has changed ever so slightly. 

How the plot is created / the background story:

I use one hour of DARM_CTRL data and the following seismometer channels to create an optimal Wiener Filter (pem indicates L0:PEM- , sei indicates L1:SEI- , and lsc indicates L1:LSC- ) :

chans = {[pem 'EX_SEISX'],...
         [pem 'EX_SEISY'],...
         [pem 'EX_SEISZ'],...
         [pem 'EY_SEISX'],...
         [pem 'EY_SEISY'],...
         [pem 'EY_SEISZ'],...
         [pem 'LVEA_SEISX'],...
         [pem 'LVEA_SEISY'],...
         [pem 'LVEA_SEISZ'],...
         [sei 'LVEA_STS2_X'],...
         [sei 'LVEA_STS2_Y'],...
         [sei 'LVEA_STS2_Z'],...
         [sei 'ETMX_STS2_X'],...
         [sei 'ETMX_STS2_Y'],...
         [sei 'ETMX_STS2_Z'],...
         [sei 'ETMY_STS2_X'],...
         [sei 'ETMY_STS2_Y'],...
         [sei 'ETMY_STS2_Z'],...
         [lsc 'DARM_CTRL']};

I then apply this one filter to ten minute chunks of science mode data, for some long period of time.  The game plan is to have a month long plot, but it takes a while to fetch all of the data in separate 10min intervals (~45sec per iteration, times ~3000 iterations), so this plot isn't a full month.  Even if I don't get a chance to plot a full month by Thursday morning, it'll go up here within the next few days. The particular times chosen have the most science mode data within a 30 day period.  I can easily run the code for some other time, if there is a known time (or season) which might be more interesting.  For the spectrogram plot, I then normalize each amplitude spectra by the first one, which comes from the first ten minutes in the hour which was used to make the filter.  This makes it easier to see how the filter's efficacy changes over time.

The analogous analysis for Hanford is in the 40m elog: 1606.  The Hanford stuff in the elog has some cool BLRMS plots also, but I'm not sure that they're so helpful when I only have a few days of L1 data so far.  I'll do those and add them later.

Conclusions:

I can't really say anything yet about the long-term efficacy of a Wiener Filter for LLO yet, since my code hasn't finished filtering my one month of S5 L1 data.  It definitely looks like (so far) that there was a big seismic event around the (arbitrarily defined) 'Day 4'. 

This surface plot is the same as the previous one, with a little more data than I had previously. 

This time around, I also include the "BLRMS" plots for this data.  The first one takes each residual and normalizes it by the DARM_CTRL signal at that time, separates the spectra into bands, and integrates underneath the spectra within that band.  The second one is the raw DARM_CTRL signal's spectra at each time, and integrates under the spectra for each band, and the third BLRMS plot does the same thing for the residuals.  Unfortunately, these plots don't have the same handy black stripe during time which I don't analyze that the spectrogram utilizes.

From the second BLRMS plot we can see that the large red splotch in the spectrogram is due to higher noise in the DARM spectrum, and that (by looking at the Ratio BLRMS plot) the Wiener filter still does a pretty good job during this time.  I expect that for later times when the seismic (or something) event is gone, the Wiener filter will continue performing almost as well as it had been initially.

Again, once the script finishes applying the filter to the many ten minute chunks (the huge time drain is the data fetching, so this shouldn't be a limiting factor for using Wiener filters online), I'll post a final plot.

The elog has been quite slow for the last two days. The cause is nodus, that has been slowing down the access to it.

I looked at the list of the running processes on nodus by typing the command prstat, which is the equivalent for Solaris of the Linux "top". I didn't see any particular process that might be absorbing too many resources.

I remember Rana fixing the same problem in the past but couldn't find his elog entry about that. Maybe we should just restart nodus, unless someone has some other suggestion.

 Problem solved. Nodus and the elog are running fine. It's just that the elog takes some time to make a preview of complex pdf attachments, like those in Kiwamu's entry 2405.

I have started measuring the low frequency noise of the FET front end + LT1128 low noise preamp from Rai Weiss. It has a very low input current noise because its FET based, which is not surprising. It is also a fairly low voltage noise box - the best measured ones have an input referred noise of ~0.35 nV/rHz.

Today I measured the noise of the one we have down to 0.1 Hz. It looks like a good candidate for a Geophone readout (e.g. Ranger or GS-13 or perhaps the L-4C). Because I didn't thermally shield any of this stuff, the broadband noise is ~0.8 nV/rHz. The low frequency corner is ~15 Hz.

I attach the LISO simulation of the voltage noise referred to the input. The circuit is described in this entry.

We can probably do better than this if we package it a little better or give it time to warm up or use metal film resistors inside. Even as it is, however, it would allow us to reach the thermal noise of the Ranger (or GS-13) down to 0.1 Hz.

This should be ~1.5 or 2x better than the LT1012 based readout at 1 Hz and 10x better down at 0.1 Hz (c.f. T0900457).

This afternoon I felt like saying hello to the input mode cleaner. So I decided to center the spot on MC2.

Motivation

MC has 6 alignment dofs. 4 of them are controlled by the WFSs. Remaining 2 appears at the spot position on MC2.
If the spot on the MC2 is fixed, the beam hits the same places of three mirrors. If the mirrors are completely fixed
in terms of the incident beam, I suppose the reflected beam is also fixed. This makes the WFS spots more stable.
Then I feel better.

Today's goal is to confirm the behaviour of MC such as dithering amplitude, response of the couplings to the alignment,
behavior of the WFS, and the transmitted power.

Method

1) Turned off MC auto locker. Turned off MC WFS as the WFS servos disturbs my work.
2) Dithered MC2 in Pitch and Yaw using DTT. There looks elliptic filter (fc=28Hz) in the ASC path, I used 20Hz-ish excitations.
- C1:SUS-MC2_ASCPIT_EXC 100cnt_pk@19Hz
- C1:SUS-MC2_ASCYAW_EXC 100cnt_pk@22Hz
3) Looked at C1:SUS-MC2_MCL_OUT to find the peaks at 19Hz and 22Hz. These are caused by alignment-length coupling.
If they are minimized I assume the spot is somehow centered on MC2.
Note: This may not be the true center. The suspension response should be investigated. But this is a certain reporoducible spot position.
Note: I should use ezcademod in order to obtain the phase information of the dither result.

4) Move MC2 Pitch for certain amount (0.01cnt) by the alignment slider. Align MC1/MC3 to have max transmittion.
5) If the Pitch peak got lower, the direction of 4) was right. Go further.
5') If the Pitch peak got higher, the direction of 4) was wrong. Go the other direction.

6) Repeat 4)&5) for Yaw.

Result

After the adjustment, the couplings got lower about 10 times. (Sorry! The explanation is not so scientific.)
Next time I (or someone) should make a script to do it and evaluate the coupling by the estimated distance of the spot from the center of the mirror (the center of the rotation).
I have not seen visible change in the spectrum of C1:SUS-MC2_MLC_OUT.

MCT QPD issue

By the spot centering, I could expected to see some improvement of the transmittion. But in reality, there was no change.
In fact, the transmittion power was getting down for those weeks.

I checked WFS and MCT paths. Eventually I found that a couple of possible problems:
1) MCT Total output varies more than 10% depending on the spot position on MCT QPD.
2) Just before the QPD, there is a ND1 filter.
This may suggest that:
a) Four elemtns of the MCT QPD have different responses.
b) The ND filter is causing a fringe.

So far I aligned the ND filter to face the beam. The reflection from the filter was blocked at a farther place.
Still the output varies on the spot position. Probably I have to look at the QPD someday.

So far the spot on the QPD was defined so that I get the maximum output from the QPD. This is about 8.8.
As I touched the steering mirrors, the X and Y outputs of the QPD are no longer any reference.

For now, I closed the PSL table. The full IFO was aligned.

In order to enable 'set terminal pdf' in gnuplot on Rosalba/Allegra, I installed PDFlib lite and gnuplot v4.2.6. to them.
(PDFlib lite is required to build the pdf-available version of gnuplot)

Installation of PDFlib lite:

• Building has been done at rosalba
• Download the latest distribution of PDFlib lite from http://www.pdflib.com/products/pdflib-7-family/pdflib-lite/
• Expand the archive. Go into the expanded directory
        tar zxvf PDFlib-Lite-7.0.4p4.tar.gz
      cd ./PDFlib-Lite-7.0.4p4
• configure & make
        ./configure
      make
• install the files to the system / configure the dinamic linker
        sudo make install
      sudo ldconfig

Installation of gnuplot:

• Building has been done at rosalba
• Download the latest distribution of gnuplot form http://www.gnuplot.info/
• Expand the archive. Go into the expanded directory
        tar zxvf gnuplot-4.2.6.tar.gz
      cd ./gnuplot-4.2.6.tar.gz
• configure & make
        ./configure --prefix=/cvs/cds/caltech/apps/linux/gnuplot
      make
      make install
• Create symbolic links of the executable at
        /cvs/cds/caltech/apps/linux/bin
      /cvs/cds/caltech/apps/linux64/bin
• Note: Although the original (non-PDF) gnuplot is still at
        /usr/bin/gnuplot
new one is active because of the path setting
      rosalba:linux>which gnuplot
      /cvs/cds/caltech/apps/linux64/bin/gnuplot


It seemed that the ETMY watchdog tripped early Sunday morning.
The reason is not known. I just looked at ETMX, but it seemed fine.

I called the control room just in case someone is working on the IFO.
Also I did not see any elog entry to indicate on going work there.

So, I decided to reset the watchdog for ETMY. And it is working fine again.

After a lot of headache, I got the OAF working again - read on for details.....................

Sometime last week, Jenne, Kiwamu, and I tried to update the OAF model to include the IIR "feed-around" path.

This path is in parallel to the existing FIR-based adaptive FXLMS stuff that Matt put in earlier. The reason for the

new path is that we want to try emulating the same FF technology which has been successful lately at LLO.

However, we were unable to make the ASS work after this work. Mostly, the build stuff worked fine, but we couldn't get DTT

to make a transfer function. The excitation channels could be selected and the excitation would actually start and get all the

way into MC1, but DTT would just hang on the first swep-sine measurement with no time-out error. Clearly our ASS building

documentation is no good. We tried using the instructions that Koji gave us for AAA, but that didn't completely work.

In particular, the 'make-uninstall-daq-ass' command gave this command:

[controls@c1ass advLigo]$ make uninstall-daq-ass
grep: target/assepics/assepics*.cmd: No such file or directory
Please make ass first
make: *** [uninstall-daq-ass] Error 1

re-arranging the order to do 'make-ass' first fixes this issue and so I have fixed this in the OAF Wiki.

The there's the whole issue with the tpchn_C3.par file. This contains all the test point definitions for the ASS/OAF machine. The main

IFO numbers are all in tpchn_C1.par and the OMC is all in tpchn_C2.par. When we do the usual build, in the 'make install-daq-ass' part:

[controls@c1ass advLigo]$ make install-daq-ass
Installing GDS node 3 configuration file
/cvs/cds/caltech/target/gds/param/tpchn_C3.par
Updating DAQ configuration file
/cvs/cds/caltech/chans/daq/C1ASS.ini
we get this .par file installed in the target area. The ACTUAL param file seems to actually be in /cvs/cds/caltech/gds/param  !!

Of course, it still doesn't work. That's because the standard build likes to point to /cvs/cds/caltech/gds/bin/awgtpman and the one that runs on

linux is actually /opt/gds/awgtpman. So I've now made a file called startup_ass.cmd.good which runs the correct one. However, the default build

will try to start the wrong one and we have to fix the 'startass' script to point to the correct one on each build. Running the correct awgtpman

allows us to get the TP data using tools like tdsdata, so far no luck with DTT.\

UPDATE (23:33): It turns out that it was my old nemesis, NTPD. c1ass had a /etc/ntp.conf file that was pointing at an ntp server called rana113. I

am not an NTP server; I don't even know what time it is. I have fixed the ntp.conf file by making it the same ass c1omc (it now points to nodus). After

this I set the date and time manually (sudo date -s "20 DEC 2009 23:27:45") and then restarted NTPD. It should now be fine even when

we reboot c1ass.

After all of this nonsense, I am able to get TP data from c1ass and take transfer functions between it and the rest of the world !

I've got most of the new Mode Matching Telescope figured out.  The scripts and an example result are at: MMT09 wiki  (Rather, the scripts are in the svn: MMT svn)

Issues still to be resolved: 

* We're getting pretty iffy 'angles' between tilt and translation when using the mode matching mirrors for steering.

* I haven't taken into account the astigmatism which occurs when you tilt the mode matching mirrors. 

The nifty thing about these scripts is that they take a look at the mode matching overlap:  For each possible mode matching solution it adds noise to all of the distances and radii of curvature during ~10,000 iterations and plots a histogram of the overlap so that we can see which solutions have a better chance of giving us the optimal overlap, even if we place the optics in slightly the wrong place.

I'd like to update the overlap part of the script with the astigmatism business:  do we lose goodness of overlap if we tilt the mirrors by a bit?  I think this will require redoing the overlap part with the X and Y directions separate.  Koji has done this in the past.  My current code assumes that the beam is always symmetric in X and Y. 

 I shorted the input to the box and then put its output into the SR560 (low noise, G = 100, AC). I put the output of the SR560 into the SR785.

*** BTW, the 2nd channel of the SR785 is kind of broken. Its too noisy by a factor of 100. Needs to go back for repair once we get started in the vac.

The attached PNG shows its input-referred noise with the short.

The picture shows the inside of the box before I did anything. The TO-5 package metal can is the meaty super dual-FET that gives this thing all of its low noise power.

In the spectra on the right are two traces. The BLUE one is the noise of the box as I found it. The BLACK one is the noise after I replaced R1, R6, R7, & R10 with metal film resistors.

The offset at the output of the box with either an open or shorted input is +265 mV.

I think we probably should also replace R2, R3, & R1, but we don't have any metal film resistors lower than 100 Ohms in the kit...but hopefully Steve will read this elog and do the right thing.

This allowed measuring the MC1 -> MCL TF finally. Its mostly flat. Data saved as Templates/OAF/OAF-MCLTF.xml

 What does OAF stand for? The entry doesn't say that. Also the acronym is not in the abbreviation page of the wiki.

Can anyone please explain that?

At ITMX, on the CES side, 5 Ft  from the wall the jackhammer is on. The susses are holding well.

I fit the MC1 -> MCL TF using vectfit4.m (from mDV). The wrapper file is mDV/extra/C1/ fitMC12MCL.m.

Plotted here are the data (RED), the fit (BLUE), and the residual x10 (GREEN).

For the magnitude plot, residual is defined as ------   res = 1 - fit / data

For the phase plot the residual is defined as -------    res =  phase(data)-phase(fit)

You can see that the agreement is very good. The phase match is better than 5 deg everywhere below 10 Hz.

This TF is so smooth that we could have probably done without using this, but its good to excercise the method anyway.

Kiwamu made the OAF screen functional today - screenshot attached.

After this, I used the measured TF of the MC1 to MCL to filter the signals from the Wilcoxon accelerometers and feed them into the MC.

The noise at 3 Hz went down by a factor of ~3. There's a little excess created at 100 Hz. Its good to see that our intuition about feed-forward is OK.

I did all of the filter calculations by adapting the scripts that Haixing, Valera, and I got going at LLO. They're all in the mDV/extra/C1 SVN.

The Wiener code predicts much better performance from using more than just 2 horizontal accelerometers, but I was too lazy to do more channels today.

I also added the Rai box to the Ranger readout today - the noise at 0.1 Hz went down by a factor of 10 and the noise at 1 Hz is close to 10^-11 m/rHz.

We have been waiting for this for 20 some years. Arrowhead water with cooler. AWESOME

THANKS Alan

In this morning I found MC unlocked.

Steve restored the watchdogs before I found that.

Then I relocked MC and now MC is locked and working well.

The reflected DC power is ~0.38, which is usual number.

 Happy holidays, everyone!

I found the e-log has been down around 3:40pm, then I restarted the e-log. Now it's working.

Thanks.

Sometimes back we modified /cvs/cds/caltech/chans/daq/C1ASS.ini to save some of the channels. The file was reverted to default after the recent changes in ASS.

We again uncommented and made acquire=1 to save the following three channels using daqconfig:

C1:ASS-TOP_ERR_MCL_IN1_2048

C1:ASS-TOP_PEM_15_IN1_2048

C1:ASS-TOP_PEM_18_IN1_2048

The script automatically created a back up in /cvs/cds/caltech/chans/daq/archive

For a certain investigation of the sum/diff module for MCT QPD/MC REFL QPD, I removed it from the system.

The Rai box ran out of batteries a couple of days ago and so the data is no good. I've put the Ranger back on the SR560 for now (but with the damping resistor removed, so the gain is 2x more than before).

The validation for high impedance measurement has been well done.

The impedance measurement is one of the keys for designing the EOM circuit.

So far I was very struggling to measure the high impedance ( above several 1000 Ohm) at RF because the EOM circuit has a high impedance at its resonance.

Finally I realized that the measured impedance was suppressed by a parasitic resistance, which especially reduces the impedance at the resonance.

Also I found that we can extract the TRUE impedance data by subtracting the effect of the parasitic resistance from resultant data.

In order to confirm whether this subtraction works correctly or not,  the impedance was directly re-measured with another analyzer for crosscheck.

(measurement )

The measurement has been performed with help from Peter and Frank. ( Thank you !)

By using  network analyzer AG4395A with the impedance test kit AG43961A (these are at the PSL lab.), the impedance of resonant circuit with EOM was measured.

The picture of setup is attached. This impedance test kit allows to measure typically 0.1 [Ohm]-1M [Ohm] and frequency range of 100kHz-500MHz.

(result)
The resultant plot is attached. In the plot the blue curve represents the impedance measured by usual analyzer at 40m.

Note this curve is already subtracted the effect of the parasitic resistance.

( the parasitic resistance is in parallel to the circuit and it has ~7.8k Ohm, which is measured while the probe of the analyzer stays open. )

The red curve is the re-measured data using the impedance test kit.

The important point is that; these two peak values at the resonance around 40MHz show good agreement in 10%.

The resonant frequencies for two data differs a little bit, which might be the effect of a stray capacitance ( ~several [pF] )

The red curve has a structure around 80MHz, I think this comes from the non-coaxial cables, which connect the circuit and analyzing kit.

You can see these cables colored black and red in the picture.

( conclusion )

Our measurement with the subtraction of the  parasitic resistance effect is working reliably !

I found that MCT QPD has a dependence of the total output on the position of the spot. Since the QPD needs the supply and bias voltages from the sum/diff amp, I could not separate the problems of the QPD itself and the sum/diff amplifier by the investigation on Tuesday. On Wednesday, I investigated a generic quad photodiode interface module D990692.

...I was so disappointed. This circuit was left uninvestigated and used so long time with the following sorrowful conditions.
- This circuit has 4 unbuffered inputs with input impedance of 300~400 Ohm. It's way too low!
- Moreover, those channels have different input impedances. Ahhhh.
- Even worse, the QPD circuit D990272 has output impedance of 50 Ohm.
- The PCB of this circuit has four layers. It is quite difficult to make modifications of the signal route.
- It is a headache: this circuit is "generic" and used in many places.

D990692 has 4 channel inputs that are not buffered. Each channel has two high impedance buffers but they are used only for the monitors. The signal paths have no buffer.

The differential amplifier is formed by R=1k Ohm. The inverted side of the input has 1kOhm impedance. The non-inverted side has 1.5kOhm impedance.

CH1: 10K // 1.5k // 1.5k // 1k = 411 Ohm
CH2: 10K // 1.5k // 1k // 1k = 361 Ohm
CH3: 10K // 1k // 1k // 1k = 323 Ohm
CH4: 10K // 1k // 1.5k // 1k = 361 Ohm

Considering the output impedance of 50Ohm for the QPD, those too low input impedances result in the following effect:
- Because of the voltage division, we suffer absolute errors of 10.8~13.4%. This is huge.
- Because of the input impedance differences, we suffer a relative error of 1.5%~3%. This is also huge.

Unfortunately, the circuit has no room to modify; the signal paths are embedded in the internal layer.

I decided to replace the resistors of the sum/diff amps from 1k to 10k. Also the input impedance of the buffer was removed as the input is terminated by the sum/diff amps in any case.This changes the input inpedance to the followings:

CH1: 15k // 15k // 10k = 4286 Ohm
CH2: 15k // 10k // 10k = 3750 Ohm
CH3: 10k // 10k // 10k = 3333 Ohm
CH4: 10K // 15k // 10k = 3750 Ohm

These yield the absolute error of 1.2-1.5%. The relative error is now 0.3%. I can accept these numbers, but later I should put additional terminating resistors to compensate the differencies.

So far I have modified the resistors for the MCT as the modification for a QPD needs 17 10k resistors.
Next thing I have to check is the dependence of the QPD outputs on the spot positions.

-----------------------------------------------

Edit: Feb 11, 2010

I talked with Frank and he pointed out that the impedances are not the matter but the gains of the each channels are the matters (after considering the output impedance of the QPD channels).
If we assume the ideal voltage sources at the QPD and the symmetric output impedances of 50Ohm, the gain of the each circuit are affected but the change should be symmetric.

He found that several things:
- The analog switch (MAX333) used in the QPD unit adds more output impedance (somewhat randomly!).
- The resistance of the sum/diff circuits may vary each other unless we use 0.1% resistors.

In this note, amplitude and power couplings of two astigmatic (0,0)-th order gaussian modes are calculated.

In this evening I found that fb40m has been down, then I restarted fm40m successfully.

However there still is a problem, the reflective memory can not communicate with some front-end CPUs ( such as c1iscey, c1susvme, ...etc.)

Right now I don't have any ideas about this, I am leaving them as they are now .... we can deal with them tomorrow. 

The followers are what I did.

(1) ssh to fb40m then "pkill tpman"

(2) telnet to fb40m then typed "shutdown". ( These procedure are on the 40m wiki)

(3) make sure fb40m gets recovered while watching the medm screen C0DAQ_DETAIL.adl

(4) run the backup script in fb40m

(5) in order to fix the communication problem, physically turn off c1dcuepics and c0daqctrl

(6) keying some front-end CPUs. ---> still some of front ends indicate RED on the medm screen C0DAQ_DETAIL.adl ( figure attached )

 This is indeed sad. But, we can perhaps bypass all of this by just using the individual segment outputs. According to the circuit diagram and the c1iool0 .db file, we should be able to just do the math on the segments and ignore the VERT/HOR/SUM signals completely. In that case, we can just use high impedance for the sum/diff buffers as Koji says and not suffer from the calibration errors at all I think.

Unfortunately, the signals for individual segments also suffer from the voltage drop as all of the low impedance amplifiers are hung from the same input.
In order to utilize the individual channels, we anyway have to remove the resistors for the VERT/HOR/SUM amps.
That is possible. But does it disable some fast channels for future ASC purposes?

Nothing like a good ol' Bootfest to get back into the swing of things after vacation....

It was a regular bootfest, keying crates and running everyone's startup.cmd .  There wasn't any RFM funny business which we had been dealing with a lot earlier in December (maybe Kiwamu took care of that part of things last night).

After finishing the bootfest, I tried to re-enable the watchdogs.  I noticed that the optics weren't damping at all (not that any of them were swinging crazily, they just weren't damped like regular).  This was traced to the OSEM sensor inputs and outputs being disabled on all of the suspensions' screens.  I suspect that no burt-restoring happened after c1dcuepics was powercycled yesterday. 

All of the optics are now happy as clams.

MC2 is having a bad day, and I'm not yet sure why.  It's to do with the damping though.  When the damping is off, after a little while it will settle to ~30mV or so on the Watchdog screen.  When I enable all of the outputs and then turn on the damping, the optic gets kicked up.  It's like there's a minus sign error somewhere, maybe in a bad burtrestore?  This has been going on since I did my morning bootfest.

It's started to sit down and play nicely now.  Is someone doing magic remotely that is fixing things that I hadn't figured out yet?

The MCL path of MC2 was in a strange state as the filters were activated as if it is in lock even though we had no lock. So I manually ran "mcdown". This reset the filters of the MCL path.

Since it wasn't sure whether all the front-ends had been restored after the bootfest, I burtrestored everything to Dec 26 at 20:00.

Always keep in mind that to burtrestore c1dcuepics, the snapshot file has to be modified by hand by moving the last quote up to the line before the last.

I opened the auxiliary laser's shutter.

I'm currently working on the AP table.

 I finished working on the table.

I closed the AUX NPRO's shutter.

The HIGH and LOW channels are added into the burt request file "/target/c1losepics/autoBurt.req".

These values are used to colorize the alarm texts in the "C1DRIFT_MONITOR.adl" like a threshold. (the screenshot attached)

Hereafter these values will be automatically restored by the burt.  Happy !

We have installed the new Video Matrix.

Its still in an intermediate state, so don't try to "fix" anything before Kiwamu and I get back onto it in the afternoon.

The status so far is that we have removed the old switch (it was a 256 input x 128 output !! mux)  and installed the new one in the same rack. We have hooked it up to the CDS network and have set up its matrix by using the web interface (i.e. NOT EPICS).

Along the way, we discovered that there is lack of impedance matching in the video all over the 40m. Video signals are RF and need to be treated that way. The PSL signals are T'd around and sent on 50 Ohm cables to high impedance monitor inputs.

We should eliminate any switches besides the new one (called Luciana) and control the PSL's Video Monitor from the main MUX interface. No more Rogue Video Switches.

Another couple of things we have found is about RCR camera.

(1) The long cable which connects the RCR camera box and the video matrix doesn't work. Although the signal is alive and we can see it by the local tv monitor nearby PSL.

(1) The reflected beam going to the camera is too weak to see in the monitor.  We found a strange polarized cube splitter in front of the camera. We should modify it sooner or later.

Before we installed the video switch box, we also took some photos of it. We uploaded them onto the 40m Picasa.

Video Matrix

The first photo is the an entire view of the switch box. The following four photos are the details of the switch matrix.

 The slideshow below is a dump of the last several months of photos from the Olympus. The originals have been deleted.

I added 600 cc of Arrowhead Distilled Water to the chiller.

60 days plot shows that about every ~ 10 days I have to add some.

Please check the water level yourself.

This morning I found all the watchdogs had tripped during the night.

I restored them all.

I can't damp ITMX. I noticed that its driving matrix is all 1s and -1s as the the right values had been lost in some previous burtrestoring.

Rana fixed the problem. He found that the side damping was saturating. He lowered the gain a little for a while, waited for the the damping to slow down the optic and then he brought the gain back where it was.

He also upadted the MEDM screen snapshot.

We restored the good state of the ITMY camera and neatened both the MC2 and ITMY camera.

The MC2 camera was driving a triple T jungle into some random cables and spoiling the image. We removed all T's and the MC2 camera now drives only The Matrix.

The ITMY camera was completely unmounted and T'd. So it was misaligned just by the force of gravity acting on its BNC cable. We swapped the lens for a reasonable sized one and remounted it in its can. We then used orange cable ties to secure the power and BNC cable for the MC2 and ITMY cameras so that tugging on the cables doesn't misalign the cameras. This is part of the camera's SOP.

No more driving 50 Ohm cables and T's with video cables, Steve! If you need a portable video, just use a spigot of the Matrix and then you can control it with a web browser.

I also wiped out the D40's memory card after uploading all of the semi-useful files to the Picasa page.

The input channels of the cameras and the output channels for the monitors are summarized on the wiki.

The channel table on the wiki is very helpful when you want to make a change in the video matrix.

thank you.

Tobin & Keith pointed out in the LLO ilog that there was a code bug in the autoburt.pl script for autoburts.

I edited the autoburt.pl script so that it will work from now until 2099 (by which time we may no longer be using this version of perl):

nodus:autoburt>diff autoburt.pl~ autoburt.pl
234c234
<     $thisyear = "200".$timestamp[5];
---
>     $thisyear = "20".$timestamp[5];

The autoburt has not been working ever since 11PM on New Year's eve.

I ran it by hand and it seems to run fine. I noticed along the way that it was running on op340m (our old Sun Blade 150 machine). The autoburt.pl was pointing at /cvs/cds/bin/perl

which is Perl v5.0. I changed it to use '/usr/bin/env' and now points at '/usr/bin/perl' which is perl 5.8. It runs fine with the new perl:

op340m:scripts>time perl /cvs/cds/scripts/autoburt.pl >> /cvs/cds/caltech/logs/autoburtlog.log
5.37u 6.29s 2:13.41 8.7%

Also ran correctly, via cron, at 9AM.

I fixed up the ITMX camera like we did for ITMY recently (removed T's and added strain relief - the lens was already OK).

I also updated the .SCAN field for the RMTEMP and RCTEMP channels to 0.1 second. This had been done via probe but was wiped out after reboot previously, because I forgot to update the psl.db file.