40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 116 of 341  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  1073   Thu Oct 23 18:23:47 2008 AlbertoUpdateGeneralAbs length

Quote:
Here are the measurements I've got yesterday. The plot shows the transmitted power after the X arm while sweeping the frequency of the beat between the two lasers. That frequency is changed by scanning the frequency of the local oscillator of the PLL (that is the Marconi).
The X arm cavity has been locked to the TEM00 of the main beam. I tilted ITMX in order to enhance the higher modes of the secondary beam with the purpose of making them beat with the main beam.
Three traces are shown in the plot correspondent to three different measurements in which I clipped the transmitted beam at the X end with a razor blade from up and from the side of the photodiode.
Both the beats of the TEM00 mode of the main laser with the TEM01 and TEM10 modes of the secondary laser are expected to be at 6.2763 MHz. The plot has a candidate peak at 6.325MHz but it does not appear on both the measurements with the blade. the peaks at 3.897MHz and 7.795MHz are the first and the second longitudinal modes of the X arm cavity.


Today I repeated the measurement and I'm attaching the resulting plot. Still, not clear and (and most of all) not nice.
It seems like tilting ITMX is introducing a lot of unwanted higher modes that don't let us to clearly identify TEM01 and TEM10.
I think I'm going to stop it to get back to technique in which the arm cavity is locked to the TEM01/10 of the main beam.
Attachment 1: TRX_plot_06_07_08_together.png
TRX_plot_06_07_08_together.png
  1074   Thu Oct 23 18:27:04 2008 AlbertoUpdateGeneralAbs length

Quote:
Here are the measurements I've got yesterday. The plot shows the transmitted power after the X arm while sweeping the frequency of the beat between the two lasers. That frequency is changed by scanning the frequency of the local oscillator of the PLL (that is the Marconi).
The X arm cavity has been locked to the TEM00 of the main beam. I tilted ITMX in order to enhance the higher modes of the secondary beam with the purpose of making them beat with the main beam.
Three traces are shown in the plot correspondent to three different measurements in which I clipped the transmitted beam at the X end with a razor blade from up and from the side of the photodiode.
Both the beats of the TEM00 mode of the main laser with the TEM01 and TEM10 modes of the secondary laser are expected to be at 6.2763 MHz. The plot has a candidate peak at 6.325MHz but it does not appear on both the measurements with the blade. the peaks at 3.897MHz and 7.795MHz are the first and the second longitudinal modes of the X arm cavity.


Here is the Matlab code I use to calculate the HOM frequencies.
Attachment 1: HOM_Frequencies.m
% FP Cavity HOM Frequencies Estimate
% Alberto Stochino, October 2008

R1 = 7280;      % Mirror1 radius of curvature
R2 = 57.57;     % Mirror2 radius of curvature
L = 38.458;     % Length of the FP Cavity
n = 1;          % X Order of the Mode
m = 0;          % Y Order of the Mode

c = 299792458;  % Speed of Light
... 11 more lines ...
  1084   Fri Oct 24 11:42:48 2008 AlbertoUpdateGeneralAbs length: locking the X arm cavity in TEM01/10
I went back to lock the arm cavity in either TEM01 or TEM10 mode. Attached are the results. We still have several resonances which we can't clearly identify. I expect TEM01/10 to be at 6.276MHz but we don't have a peak exactly there. What we have is:
- a peak at 6.320MHz in the measurement of the TEM01 mode (the one with the lobes of the spot almost on the vertical axis)
- a peak at 6.590MHz in both the TEM01 and TEM10 measurements.

I'm either missing the real TEM01/10 mode or the peaks at 6.590MHz are those. If that were true, that would mean that the radius of curvature of ETMX is 49.29 m instead of 57.57 m as listed in the IFO data sheets. I think it's much more likely that the measurements are missing the right peaks.
Attachment 1: TRX_armTEM00-plot_09-10_together.png
TRX_armTEM00-plot_09-10_together.png
  1086   Fri Oct 24 17:21:13 2008 AlbertoUpdateGeneralAbs length: the right amount of beam clipping
I found the reason why the peak at about 6.3MHz appeared only on the TEM10 mode: the blade was clipping the beam too much and it was probably totally killing the mode. I'm attaching a plot that shows that difference when I did that.
Attachment 1: 24OCT08_levels_of_clipping_comparison.png
24OCT08_levels_of_clipping_comparison.png
  1087   Fri Oct 24 18:05:01 2008 AlbertoUpdateGeneralAbs length: transverse mode spacing measured for the X arm
The ETMX suffers of astigmatism. I measured the following frequencies for the higher order modes:
- f_01 = 6317500 +/- 500 Hz
- f_10 = 6305500 +/- 500 Hz

From

g2=1/g1*(cos(A*L*pi/c))^2

where A= (fsr-f_i), fsr=(3897654+/-15)Hz (see elog entry 956), L=(38.4580+/-0.0003)m, g1=0.9947 (from R1=7280m), I get the following values for the g-factor coefficients:

g2_x = 0.3164 +/- 0.0002
g2_y = 0.3209 +/- 0.0002

from which we have the radius of curvature of ETMX:

R_x = 56.26 +/- 0.01 m
R_y = 56.63 +/- 0.01 m


The specs for the mirror have R2= 57.57 m (unc).

So, they seem conditions similar of those of ETMY that Koji measured:

Rx = 56.1620 +/- 0.0013 [m]
Ry = 57.3395 +/- 0.0011 [m]

for which L_yarm: 38.6462 m +/- 0.0003 m
Attachment 1: 24OCT08_TEM10-01_comparison(file12-14).png
24OCT08_TEM10-01_comparison(file12-14).png
  1108   Mon Nov 3 19:12:27 2008 albertoUpdateGeneralTransverse mode spacing measurement for the X arm
I know a lot of expectations have been building up on these days in the scientific community at the 40m towards a conclusive elog entry about the g-factor measurement of the X arm cavity.
The reason of the delay is that the results are still under review by the author. It turned out that the measurements of the transverse mode spacing have been performed on the beat
of the TEM02/20 and TEM00 modes between the two laser beams instead of on the beat between 00 and 01/10. However, the results posted on the elog in the last weeks seem likewise correct,
in particular my plot of the HOM of the sidebands.

Anyways, lately I have been trying to repeat the measurement on the beat of TEM01/10 with 00 but, despite all the efforts and the countless configurations tried (on the locking of
the arm, on the tilt of the mirrors, on the injection of the secondary beams, on the chopping with the blade), only the beat of TEM10 has been measured - although quite clearly -
whereas that of TEM01 has so far hidden itself.

The search continues but even if it does not succeeds, a summarizing document is going to be posted soon.

Here I attach a plot that shows the kind of difficulties trying to detect TEM10. The red neat peak is the beat of TEM01 whereas the other curves are some of the resulting
resonances after trying to couple TEM10 with 00 (or vice versa, according to whether I'm locking the cavity to the 00 mode of the main laser or to that of the secondary beam).
Attachment 1: 2008-11-02_summarizingplot.png
2008-11-02_summarizingplot.png
  1109   Mon Nov 3 19:18:47 2008 AlbertoConfigurationGeneralnew elog
Phil Ehrens kindly poured our elog's content in a CD that now is here at the 40m.
I've been trying to install the 2.7.5 version of the elog on Nodus, a Sun machine, but the installing procedure is different from linux and I dont' know it. I tried to recompile the elog from the source code but the way gcc is called must be wrong because I get this error message:

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

Joe, Yoichi, anyone else knows how to do that?
  1110   Mon Nov 3 21:38:32 2008 YoichiConfigurationGeneralnew elog

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

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


The location of ssl.h is a bit strange in the sunfreeware version of OpenSSL. Since elog does not use configure script, you have to
edit Makefile and add an appropriate -I option to an appropriate variable definition (probably LIBS or CFLAGS, because the elog Makefile does
not use INCLUDES).
If you don't understand what I'm saying, just wait for me.
  1133   Thu Nov 13 15:50:44 2008 AlbertoConfigurationGeneralGPS 10MHz clock
The schematic of the 1Y7 rack that Alan pointed out (see attachment) don't represent anymore the actual rack.
First, with Yoichi we found that the GPS receiver for the 10 MHz is in a different position,
on the other side of the VME computer. It seems to output 1 kHz, which also appears in some modulated way.
This signal is then passed to a board on 1Y7 that seems make just copies of the signal. One of these goes
to an other board in 1Y6 that looks like a GPS receiver but has actually no GPs antenna input. Here it is
not connected to anything, but on its same crate is a the awg computer, so it might be providing the clock
to that by the crate.

We also checked the clock monitor output on the boards in the PSL that provides for the clock to the Penteks
and it seems that these are actually getting 4MHz.
Attachment 1: rackstuff.pdf
rackstuff.pdf rackstuff.pdf rackstuff.pdf rackstuff.pdf
  1142   Mon Nov 17 20:47:19 2008 CarynSummaryGeneralDrove MC at 28kHz to excite drum modes
Rana, Alberto and I observed drum mode frequencies at 23.221kHz(MC1), 28.039kHz(MC2), 28.222kHz(MC3) while driving the mode cleaner. We observed no peaks when we didn't drive the mode cleaner. We used the SR785 to send a ~80mV noise signal in the 28-28.2kHz band to the mode cleaner mirrors via 1Y4-MC1,2,3-POSIN. Then we looked at 1Y2-Mode Cleaner-Qmon on the SR785 and saw peaks.
  1145   Tue Nov 18 19:44:53 2008 AlbertoUpdateGeneralX Arm Cavity "Negative" FSRs Measured
Previous measurements on the X arm cavity revealed a shift of the frequencies of the cavity resonances from where one would expect these to be by just looking at integer multiples of the cavity FSR. In particular, plotting the resonant frequencies versus the order of their occurrences while sweeping the laser frequency (in our case that of the beat between the two lasers), the linear fit of the data contained an unwanted offset:

resonant_frequency = n x FSR + offset

In part, we attributed this offset to the local oscillator of the PLL, the Marconi, which was not referred to an absolute frequency clock.
For that reason, I connected the Marconi to the RS FS275 which uses the 1PPS from the GPS to generate a 10 MHZ reference signal, and then scanned the cavity again. This time I started from negative beat frequencies, that happen when the frequency of the secondary laser is smaller than the main laser's, to positive frequencies. The way I made sure of the sign of the frequency was looking at the effect of changing the temperature of the NPRO. I decided that negative frequencies where those for which an increase in temperature lowered the beat frequency and positive frequencies those for which increasing the temperature made the beat frequency go up.
I then plotted the data and obtained the attached plot.

The offset was reduced to about 80 Hz (from more than 200 in the previous measurements). I think the residual offset has to do with something that happens in the cavity, something, as Koji found out, related to the alignment of the mirrors.

Thanks to the more data points, the measurement of the FSR improved to (3897627 +/- 5) Hz, which would let us know the measure of the cavity length with an error of 50um, if it weren't for the offset. I have to understand whether and how to take this into account to determine the precision in the cavity length. I guess it depends on whether it is real or it is still a systematic error due to the measurements.
Attachment 1: 2008-11-17_Linear_Fit.pdf
2008-11-17_Linear_Fit.pdf
  1150   Fri Nov 21 16:03:50 2008 ranaHowToGeneralRecharging Batteries
I found some black & red "Ninja" alkaline AA batteries in the battery charger. This is dangerous. Please
do not put alkaline batteries in there, only Nimh. If you need help with the battery charger you can
come and talk to me or Rob and we can help you out getting started.
  1183   Sun Dec 7 16:02:46 2008 ranaUpdateGeneralMag 5.1 EQ halfway to Vegas
There was a Mag 5.1 EQ Friday night at 8:18 PM.

It tripped most of our optics. They all damped down passively except for MC2. Further more, ITMY seems to have come back to a different place.

Don't know why MC2 was so upset but I think maybe its watchdog didn't work correctly and the side loop is unstable when there are
large motions. After I lowered the side gain by 10x and waited a few minutes it came back OK and the MC locked fine.

I have just now put all the WDs into the Shutdown state so that we can collect some hours of free swinging data to see if there's been
any damage. Feel free to redamp the optics whenever you need them. Someone should do the eigenfrequency check in the morning and compare
with our table of frequencies in the wiki.

I excited the optics using the standard SUS/freeswing-all.csh script. Here's the output:
Excited all optics
Sun Dec  7 16:07:32 PST 2008
Attachment 1: g.png
g.png
Attachment 2: Untitled.png
Untitled.png
  1185   Mon Dec 8 00:10:42 2008 carynSummaryGeneralcalibrating the jenne laser
I apologize in advance for the long list of numbers in the attachment. I can't seem to make them hide for some reason.

So, since Jenne's laser will probably be used for the Stoch mon calibration, Alberto and I took some measurements to calibrate Jenne's laser.
We focused the beam onto the New Focus RF 1GHz photodetector that we stole from rana's lab (powered with NewFocus power 0901). Measured the DC output of the photodetector with scope. Aligned the beam so DC went up (also tried modulating laser at 33MHz and aligning so 33MHz peak went up). Hooked up the 4395a Spectrum/Network Analyzer to the laser and to the AC out of the photodetector (after calibrating Network analyzer with the cables) so that the frequency response of the laser*photodetector could be measured.
(Note: for a while, we were using a splitter, but for the measurements here, I got rid of the splitter and just sent the RFout through the cables to channel A for the calibration, sent RFout to the laser and photodetector to channel A for the measurement)

Measured the frequency response. At first, we got this weird thing with a dip around 290MHz (see jcal_dip_2_norm.png below).
After much fiddling, it appeared that the dip was from the laser itself. And if you pull up just right on the corner of this little metal flap on the laser (see picture), then the dip in the frequency response seems to go away and the frequency response is pretty flat(see jcal_flat_3_norm below). If you press down on the flap, the dip returns. This at least happened a couple of times.
Note that despite dividing the magnitude by the DC, the frequency responses don't all line up. I'm not sure why. In some cases the DC was drifting a bit(I presume the laser was coming out of alignment or decided to align itself better) and maybe with avgfactor=16, and measuring mean DC on the scope, it made the DC meas not match up the the frequ resp meas...
I've attached the data for the measurements made (I'm so sorry for all the #'s. I can't figure out how to hide them)
name/lasercurrent/DC/analyzer SourcePower/analyzer avgfactor
jcal7_1/I=31.7mA/DC=-4.41/SourcePower=0dBm/avgfactor=16
jcal7_2/I=31.7mA/DC=-1.56/SourcePower=0dBm/avgfactor=none
jcal8_1/I=31.7mA/DC=-4.58/SourcePower=0dBm/avgfactor=16
jcal8_2/I=31.7mA/DC=-2.02/SourcePower=0dBm/avgfactor=16
jcal8_3/I=31.7mA/DC=-3.37/SourcePower=0dBm/avgfactor=16
Note also that the data from the 4395a seems to have column1-frequency, column2-real part, column3-imaginary part...I think. So, to calculate the magnitude, I just took (column2)^2+(column3)^2.


To get sort of an upper-bound on the DC, I measured how DCmax varied with laser current, where DCmax is the DC for the best alignment I could get. After setting the current, the laser was modulated at 33MHz and the beam was aligned such that the 33MHz peak in the photodetector output was as tall as I could manage. Then DC was measured. See IvsDCmax.png. Note the DC is negative. I don't know why.

Also, the TV's don't look normal, the alarm's going off and I don't think the mode cleaner's locked.
Attachment 1: IvsDCmax.png
IvsDCmax.png
Attachment 2: data.tar.gz
Attachment 3: jcal_dip_2_norm_log.png
jcal_dip_2_norm_log.png
Attachment 4: jcal_flat_3_norm_log.png
jcal_flat_3_norm_log.png
  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.
  1189   Tue Dec 9 10:48:17 2008 CarynSummaryGeneralcalibrating the jenne laser: impedance mismatch?

We sent RFout of network analyzer to a splitter, with one side going back to the network analyzer and the other to the laser modulation input. We observed a rippled transfer function through the splitter. The ripple is probably due to reflection due to an impedance mismatch in the laser.
Attachment 1: reflection.png
reflection.png
  1194   Fri Dec 19 11:18:52 2008 AlbertoConfigurationGeneralMode Cleaner Temperature Monitor
I reduced from 10 to 5 the gain of the SR560 that Caryn has set up after the lock-in amplifier nest to the PSL rack because the overload LED was flashing.
  1198   Sat Dec 20 23:37:43 2008 robOmnistructureGeneralSaturday Night Fever after presumed power failure

Just came by to pick something up...

... alarm handlers screeching...

... TP1 failure--closing V1... call Steve... Steve says ok till tomorrow...

... all front ends down (red)...

... all suspensions watchdogged...

... all (I think) servos off...

... PSL shutter closed ...

... chiller at 15C ... I turned it off to prevent condensation in PA...

... MOPA shutter closed... turned off key on Lightwave power supply

... good luck all, and happy holidays!
  1218   Thu Jan 8 20:26:17 2009 robOmnistructureGeneralEarthquake in San Bernardino
Magnitude 4.5
Date-Time

* Friday, January 09, 2009 at 03:49:46 UTC
* Thursday, January 08, 2009 at 07:49:46 PM at epicenter

Location 34.113N, 117.294W
Depth 13.8 km (8.6 miles)
Region GREATER LOS ANGELES AREA, CALIFORNIA
Distances

* 2 km (1 miles) S (183) from San Bernardino, CA
* 6 km (4 miles) NNE (25) from Colton, CA
* 8 km (5 miles) E (89) from Rialto, CA
* 88 km (55 miles) E (86) from Los Angeles Civic Center, CA

Location Uncertainty horizontal +/- 0.3 km (0.2 miles); depth +/- 0.8 km (0.5 miles)
Parameters Nph=142, Dmin=1 km, Rmss=0.38 sec, Gp= 14,
M-type=moment magnitude (Mw), Version=Q

I felt it from home.

All the watchdogs are tripped, vacuum normal. It looks like all the OSEM sensor values are swinging, so presumably no broken magnets. I'm leaving the suspensions off so we can take fine-res spectra overnight.

Watchout for crappy cables coming loose.
  1222   Mon Jan 12 10:57:38 2009 robUpdateGeneralsome stuff

The AS beam was not hitting the AS166 diode, so I aligned the last little steering mirror and adjusted the phase for MICH locking.

I turned on the HV supplies for the OMC.

Then I realigned the beam onto the AS166 diode, since the steering mirrors came on when I turned on the HV supplies.

It took awhile to find the alignment of the beam into the OMC. Once that was done, the output beam alignment was set, so I aligned onto the AS166 diode a third time.

The bottom two Sorensens in the OMC voltage supply don't look right. They have stickers that say +-24V, but each is sitting at 17.5V and showing no current draw. What's going on here?
  1263   Mon Feb 2 12:35:22 2009 AlbertoConfigurationGeneralNew Elog 2.7.5 in Service on Nodus
I moved the 40m, the Adhikari Lab and the SUS elogs from Dziban (located in Millikan's 6th floor) to our gateway server Nodus. In this way we should the complete control of it. I also updated the elog manager from the 2.6.5 version to the 2.7.5. Some smoothing of its interface might still be needed these days. We'll be testing it for a while before killing the old one. from now on everybody is invited to use only the new elog address since there will be no record of entries posted in the old one. Let me know of any possible difficulty in having access to it.
  1264   Mon Feb 2 17:25:44 2009 AlbertoConfigurationGeneralSome little problem with the new elog
For some reason the new elog does not look exactly like it should. 1) Some of the editing features are not available. 2) The Reply option opens the HTML of the message by default. I think this is happening because Nodus is a Sun of platform and things are a little bit different from linux. I'm working to fix these things. If I make any change and need to restart the elog, I'll try to be very quick. I apologize for the inconveniences.
  1265   Mon Feb 2 18:32:54 2009 AlbertoConfigurationGeneralSome little problem with the new elog

Quote:
For some reason the new elog does not look exactly like it should. 1) Some of the editing features are not available. 2) The Reply option opens the HTML of the message by default. I think this is happening because Nodus is a Sun of platform and things are a little bit different from linux. I'm working to fix these things. If I make any change and need to restart the elog, I'll try to be very quick. I apologize for the inconveniences.

 I think I solved the problem (as you can probably see).

The cause was that this WYSIWYG interface for HTML is provided by an independent text editor called FCKeditor which is included in the elog. Although the elog installer has a bug and does not unzip properly the relative package. One has to do it by hand. (going to /elog/scripts/ and unzipping fckeditor.zip by hand in the same directory).

  1266   Mon Feb 2 18:51:02 2009 AlbertoConfigurationGeneralNew Elog 2.7.5 in Service on Nodus

Quote:
I moved the 40m, the Adhikari Lab and the SUS elogs from Dziban (located in Millikan's 6th floor) to our gateway server Nodus. In this way we should the complete control of it. I also updated the elog manager from the 2.6.5 version to the 2.7.5. Some smoothing of its interface might still be needed these days. We'll be testing it for a while before killing the old one. from now on everybody is invited to use only the new elog address since there will be no record of entries posted in the old one. Let me know of any possible difficulty in having access to it.

 As a reference. The elog runs on background in nodus.

To kill the process:

1) pkill -3 elogd

2) rm -f /var/run/elogd.pid

To restart it:

elogd -p 8080 -c /export/elog/elog-2.7.5/elogd.cfg -D

  1267   Mon Feb 2 19:23:53 2009 YoichiUpdateGeneralNew optical layout plan
The attached is a plan of the optical layout in the central part for the upgrade.
I included, the folded recycling cavities, oplevs for the core optics, POX, POY, POB and video views.
I have not worked out how to handle the beams outside the chambers. It should not be that difficult.
I also did not include beam dumps for unwanted beams.

I used pink for main beams, brown for picked off beams, red for oplevs.

Comments, suggestions are welcome.
Attachment 1: 40mUpgradeOpticalLayoutPlan01.pdf.zip
  1269   Tue Feb 3 19:24:14 2009 YoichiUpdateGeneralNew optics layout wiki page
I uploaded a slightly updated version of the new optics layout on the 40m wiki.
http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_08/Optical_Layout

I also uploaded the Mathematica notebook I used to calculate various parameters of the new recycling cavities, including the lengths, asymmetry, ROCs, PRM reflectivity and TT-mirror loss margin etc.
It would be nice if someone could check if the calculation is reasonable.
There is a PDF version of the document for non-Mathematica users.
  1271   Wed Feb 4 17:45:39 2009 YoichiUpdateGeneralMode matching of the upgraded IFO
I did mode matching calculations for the new optical layout.
For the input mode matching, we have to change the focal length of the second mirror from 687mm to 315mm and the distance between the two MMT mirrors from 137mm to 149.2mm.
For the mode matching to the OMC, we only have to change the distance between the OMMT mirrors from 384mm to 391mm. No need to change the mirrors.

Details of the calculations can be found in
http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_08/Optical_Layout?action=AttachFile&do=get&target=NewRecyclingCavities.zip
(Mathematica notebook)
or if you prefer PDF, here
http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_08/Optical_Layout?action=AttachFile&do=get&target=NewRecCav.pdf
  1272   Wed Feb 4 19:22:57 2009 YoichiUpdateGeneralDo we need off-axis parabolic mirrors ?
I also estimated the mode matching degradation caused by the astigmatism.
Since the incident angles to the mode matching mirrors are not 0, the effective focal lengths in the incident plane and the perpendicular plane are different.
This effect leads to astigmatism of the beam.
When there is astigmatism, the maximum achievable mode matching rate becomes less than 100%.
According to my calculation, the mode matching cannot be better than 94% for the input beam.
For the output mode matching, we can theoretically achieve more than 99% even with the astigmatism.
The difference comes from the fact that the OMMT is longer, thus the incident angle is smaller.

If we don't like this 94%, we have to use off-axis parabolic mirrors, or modify the IMMT to a longer one.
I prefer to make it longer. Just 5" elongation will increase the mode matching rate to 99.4%.
We have a room for this 5" elongation.

Again, the details of the calculation are added to the Mathematica notebook below.


Quote:
I did mode matching calculations for the new optical layout.
For the input mode matching, we have to change the focal length of the second mirror from 687mm to 315mm and the distance between the two MMT mirrors from 137mm to 149.2mm.
For the mode matching to the OMC, we only have to change the distance between the OMMT mirrors from 384mm to 391mm. No need to change the mirrors.

Details of the calculations can be found in
http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_08/Optical_Layout?action=AttachFile&do=get&target=NewRecyclingCavities.zip
(Mathematica notebook)
or if you prefer PDF, here
http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_08/Optical_Layout?action=AttachFile&do=get&target=NewRecCav.pdf
  1274   Thu Feb 5 10:42:33 2009 YoichiUpdateGeneralDo we need off-axis parabolic mirrors ? No way !
I made a mistake in estimating the astigmatism problem.
If we use the current MMT1 as it is, this one is already an off-axis parabolic (OAP) mirror.
In this case, the astigmatism of this mirror is very small (if we use it with the correct angle). I did not include this effect in the previous calculation.
It turned out that the maximum achievable mode matching becomes far smaller (only 77%) if we use the OAP for MMT1 and a spherical mirror for MMT2.
This is not acceptable.
The reason behind this is that when we use spherical mirrors for both MMT mirrors, the astigmatism caused by the MMT1 is somewhat canceled by the astigmatism of MMT2. We don't get this cancellation if we mix OAP and spherical mirrors.

We should either (1) change MMT1 to a spherical mirror and keep the length of the input MMT as it is, or (2) change MMT1 to a spherical mirror and elongate the length of the input MMT.
In the case of (1) the maximum achievable mode matching is 94%. The focal length of MMT2 should be 315.6mm.
If we do (2), the mode matching rate can be as high as 99.8%. The focal lengths are MMT1 = -301.3mm, MMT2=558mm. The distance between the mirrors is 262mm.
We have enough space to do this elongation. But we have to mechanically modify the MMT mount.
I prefer (2).

As usual, the document on the Wiki was updated to include the above calculations.
  1290   Wed Feb 11 00:50:24 2009 carynUpdateGeneralants?

So, near 2 of the trashcans in the control room and underneath a desk there are hundrends of ants. Is this normal?

  1293   Wed Feb 11 11:39:17 2009 steveConfigurationGeneralvac envelope ground
The vacuum envelope was grounded from the IOO chamber to master ground north (under electric breaker panel L)
with 4GA  25ft red battery cable.

 

  1297   Thu Feb 12 14:39:07 2009 ranaSummaryGeneralSilicon Beam Dump test
Yesterday evening, Ken Mailand and I tested the reflectivity of a piece of polished Silicon. Since Silicon has such a high thermalconductivity (compared to stainless and fused silica) and can take much more heat than black glass and should have a very good BRDF and should absorb most of the 1064 nm light if we hit it at Brewster's angle, we want to try it out in the first version high power, low scatterbeam dump. This dump will be a 'V' style dump like what Steve has tested nearly a year ago, but the incoming beam will first hit this piece of Silicon.

The pictures of the setup and the Silicon with the beam hitting it are here.

Brewster's angle for p-pol at 1064 nm is 74.2 deg (n = 3.53 @ 1064 nm). We set up a cube polarizer on the output of the ~1064 nm CrystaLaser. 144 mW got to the Si; the reflected beam was ~1.9-2.0 mW after tuning the angle for minimum power. Via eyeball and protractor it seems that we're at ~74 deg. So the reflectivity is < 1.5-2%. This is good enough; the reflected power will be < 1 W in all cases for eLIGO and that can be absorbed by the rest of the stainless V dump. The 35 W of heat in the silicon will be mostly gotten rid of through conduction into the attached heat sink fins.

This kind of dump would go into places like the PMC-REFL, MC-REFL, & IFO-REFL, where we occasionally need to take high power, but also are sensitive to backscatter.
  1302   Fri Feb 13 16:30:49 2009 steveConfigurationGeneralstatus quo is disturbed

I have been getting ready for the annual safety inspection in the past 2-3 days.

Meaning cleaning up and disturbing the status quo on the floor  mostly under the optical tables and their surroundings.
For example: pd power supplies, He/Ne laser ps. and their positions.
BNC cables and ac power line positions can be different.
The new rule: no electronic equipment on the floor.
 
All electronic equipment were moved-placed into a plastic dish or tray.
  1331   Sun Feb 22 23:43:07 2009 carynSummaryGeneraltemperature sensor

Comparing  PSL-FSS-RMTEMP and PEM-MC1-TEMPS

So, to compare temp channels, I made a plot of PSL-FSS_RMTEMP and PEM-MC1_TEMPS(the test temp sensor channel after converting from cts to degC). This plot begins about 2 months ago t_initial=911805130. The temperature channels look kinda similar but MC1-TEMPS (the temp sensor clamped to MC1,3 chamber) is consistently higher in temperature than FSS_RMTEMP. See compare_temperature_channels.png.

MC1-TEMPS isn't exactly consistent with FSS-RMTEMP. I attached a few plots where I've zoomed in on a few hours or a few days. See compare_temperature_channels_zoom1.pdf & compare_temperature_channels_zoom2.pdf

Change the room temperature, see what happens to the chamber temperature

A while ago, somebody was fiddling around with the room temperature.  See compare_temperature_channels_zoom4.pdf.  This is a plot of PEM-MC1_TEMPS and PSL-FSS_RMTEMP at t0=911805130. You can see the chamber heating up and cooling down in happy-capacitory-fashion. Although, the PSL-FSS_RMTEMP and the PEM-MC1_TEMPS don't really line up so well. Maybe, the air in the location of the MC1,3 chamber is just warmer than the air in the PSL or maybe there's an offset in my calibration equation.

Calibration equation for PEM-MC1-TEMPS

For the calibration (cts to degC) I used the following equation based on the data-sheet for the LM34 and some measurements of the circuit:

TEMPERATURE[degC]=5/9*(((-CTS/16384/451.9/1.04094)-(.0499*10^-3))/(20*10^-6)-35);

How does the chamber temperature compare with the air temperature?

It looks like the chamber may be warmer than the air around it sometimes.

I wanted to check the temperature of the air and compare it with the temperature the sensor had been measuring. So, at t=918855087 gps, I took the temp sensor off of the mc1-mc3 chamber and let it hang freely, close to the chamber but not touching anything. See compare_temperature_chamber_air.png. MC1_TEMPS increases in temperature when I am handling the temp-sensor and then cools down to below the chamber temperature, close to FSS_RMTEMP, indicating the air temperature was less than the chamber temperature.

 When, I reattached temp sensor to the chamber at t=919011131 gps, the the temperature of the chamber was again higher than the temperature of the air. See compare_temperature_air2chamber.pdf.

Also, as one might expect, when the temp-sensor is clamped to the chamber, the temperature varies less, & when it's detached from the chamber, the temperature varies more. See compare_temperature_air_1day.pdf & compare_temperature_chamber_1day.pdf.

New temp-sensor power supply vs old temp-sensor power supply

The new temp-sensor is less noisy and seems to work OK. It's not completely consistent with PSL-FSS_RMTEMP, but neither was the old temp-sensor. And even the air just outside the chamber isn't the same temperature as the chamber. So, the channels shouldn't line up perfectly anyways.

I unplugged the 'old' temp-sensor power supply for a few hours and plugged in the 'new' one, which doesn't have a box but has some capacitors and and 2 more voltage regulators. The MC1_TEMPS channel became less noisy. See noisetime.png & noisefreq.pdf. For that time, the minute trend shows that with the old temp-sensor power supply the temp sensor varies +/-30cts and with the new power supply, it is more like +/-5cts (and Volt/16,384cts * 1degF/10mV -->  apprx +/-0.03degF). So, it's less noisy. 

I kept the new temp-sensor power supply plugged in for about 8 hours, checking if new temp sensor power supply worked ok. Compared it with PSL-FSS_RMTEMP after applying an approximate calibration equation. See ver2_mc1_rmtemp_8hr_appxcal.png.

Just for kicks

Measuring time constant of temp sensor when detached from chamber. At 918858981, I heated up the temp sensor on of the mc1-mc3 chamber with my hand. Took hand off sensor at  918859253 and let it cool down to the room temperature. See temperature_sensor_tau.pdf. 

Attachment 1: compare_temperature_channels.png
compare_temperature_channels.png
Attachment 2: compare_temperature_channels_zoom1.pdf
compare_temperature_channels_zoom1.pdf
Attachment 3: compare_temperature_channels_zoom2.pdf
compare_temperature_channels_zoom2.pdf
Attachment 4: compare_temperature_channels_zoom4.pdf
compare_temperature_channels_zoom4.pdf
Attachment 5: compare_temperature_chamber_air.png
compare_temperature_chamber_air.png
Attachment 6: compare_temperature_air2chamber.pdf
compare_temperature_air2chamber.pdf
Attachment 7: compare_temperature_air_1day.pdf
compare_temperature_air_1day.pdf
Attachment 8: compare_temperature_chamber_1day.pdf
compare_temperature_chamber_1day.pdf
Attachment 9: noisetime.pdf
noisetime.pdf
Attachment 10: noisefreq.pdf
noisefreq.pdf
Attachment 11: ver2_mc1_rmtemp_8hr_appxcal.pdf
ver2_mc1_rmtemp_8hr_appxcal.pdf
Attachment 12: temperature_sensor_tau.pdf
temperature_sensor_tau.pdf
  1340   Thu Feb 26 19:20:08 2009 YoichiConfigurationGeneralETMX camera centered. POX, POY PDs centered
Alberto, Yoichi

We centered the ETMX camera.
Alberto centered the POX and POY PDs.
We also updated the offset values of PD3 and PD4.
  1414   Fri Mar 20 15:54:29 2009 steveOmnistructureGeneral480V crane power switch on MEZ

CES Mezzanine is beeing rebuilt to accommodate our new neighbor: the 20ft high water slide...& .jacuzzi

All our ac power transformers are up there. Yesterday we labelled the power switch of 480VAC on the mezz

that we need to keep to run the 3 cranes in the lab.

  1446   Mon Mar 30 17:02:46 2009 YoichiConfigurationGeneralAP OSA aligned
I aligned the AP OSA, which had been mis-aligned for a while.
  1461   Wed Apr 8 18:46:50 2009 ranaConfigurationGeneralDMF, SVN, x2mc, and matlab

While waiting for the installation of the 32-bit Matlab 2009a to finish, I tried updating our seisBLRMS.m code.

Although DMF is in SVN, we forgot to check it out and so the directory where we have been doing our mods is not a working copy and our changes have not been captured: Shame.

We will probably have to wipe out the existing SVN trunk of DMF and re-import the directory after checking with Yoichi for SVN compliance.

Also wrote a script: LSC/x2mc, which will transition from regular ETM based X Arm locking to the MC2 based locking. It ran once OK, but I get a segfault on the 'trianglewave' which was trying to run the 'ezcastep' perl script which was calling 'ezcastep.bin'.

I also restarted the seisBLRMS.m on a terminal on Mafalda in the new Matlab 2009a to see if it loses its NDS connection like it did with 2007a. I also reduced the 'delay' parameter to 4 minutes and the 'interval' to 1 minute. This should be so that the total delay is now 5 minutes between seismic noise and seismic trend.

  1464   Thu Apr 9 20:56:12 2009 YoichiHowToGeneralRestore the alignment. Write elog entries.
I often find that the mirrors are left mis-aligned (like in X-arm mode) when I come in for the locking, including tonight.
As Rob stated repeatedly in the past elog, leaving the mirrors mis-aligned for a long time without a reason is an abomination.
It will cause a slow drift of the mirrors and the lock acquisition work is severely slowed down as I have to run the alignment script many times.

I also found that the GPIB-Ethernet box (named teofila) was taken away from the SR785 hooked up to the CM board.
I found it connected to Alberto's setup. Instead, another GPIB box was left on the SR785 but not connected.
I couldn't find any elog entry about this.
This is totally unacceptable.
The SR785 has been used as a very important tool for monitoring the AO path loop gain during the power up.
You can use it if you need, but you have to note it in elog.

The other GPIB box left on the SR785 had a wrong name labeled on it. It had a name "ERMINIA", but the IP address written next to the name was actually assigned to "crocetta" in the DNS server on linux1. I don't know who made the label. I put a new and correct label on it.
Now I'm using crocetta for the SR785 so Alberto can keep using teofila.

Anyway, I think recently people are lazy about elog.
Whatever work you did, please put it in the elog even if you think it is trivial.
I also would like to see more detailed elog entries from people. Many of the recent elog entries are too simple or superficial that it is hard for other people to figure out what was really done.
  1472   Fri Apr 10 19:10:53 2009 JenneUpdateGeneralXarm locked?

I don't know who left the X arm locked, but I just ran the Align Full IFO script, so everything is good in case Yoichi/someone comes in to lock the IFO this weekend.

  1504   Mon Apr 20 20:45:25 2009 ranaConfigurationGeneralSVN: project area added
I added the /cvs/cds/project/ directory to the SVN. I've noticed that we've been using target/ for code which is not
being targeted for any IOCs. This is out of line with the intention of separating real time FE code from just regular
code that we use for diagnostics or otherwise.

So please move all of your non-FE code over to project from target. And if you didn't have it in SVN at all, you
should experience level 3 shame and then import it.
  1538   Fri May 1 18:24:36 2009 AlbertoSummaryGeneraljitter of REFL beam ?
Some loud thinking.
 
For the measurement of the length of the PRC, I installed a fast photodiode in the path of the beam reflected by PRM which goes to the 199 PD on the AS table. I picked up the beam by a flipping mirror on the same table.
I have the problem that the DC power that I measure at the PD when the PRC is locked is not constant but fluctuates. This fluctuation is irregular and has a frequency of about one Hz or so. I.e. it makes the 33 Mhz line on the PD oscillate by +/- 10 dBm.
 
Since this fluctuation does not appear at the REFL 33 PD, which has a much larger surface, but also shows up on the REFL 199 PD, I suspected that it was due to the very small size of the fast PDs. If the spot is too large, I thought, the power on the PD should be affected by the beam jitter.
 
Trying to avoid any beam jitter, I placed two lenses with focal lengths one ten times the other on the optical path in such a way to reduce the spot size on my fast PD by the same factors. The DC power was still fluctuating, so I'm not sure it's beam jitter anymore.
 
SPOB is definitely not constant when the PRC is normally locked, even with high loop gains, so maybe the reflected power really fluctuates that much.
Although, if it's actually the DC power that is fluctuating, shouldn't it appear also at the REFL 33 and shouldn't it be a problem that it shows up also in REFL 199? The elog doesn't say anything about that.
 

It's crucial that I get a stable transmitted power to have an accurate measurement of the PRC transmissivity and thus of its macroscopic length.

  1687   Fri Jun 19 13:39:29 2009 AidanUpdateGeneralUpper limit measurement of the scatter from the eLIGO beam dumps.

 

 

I measured the scatter from the eLIGO beam dumps as best I could. The experiment setup is shown in the attached diagram. 

 

After familiarizing myself with the equipment in the morning I noticed three issues with the setup

 

1 - around the minimum scatter the back scatter from the beam dump is very susceptible to the incident angle (makes sense since the Si plate inside the beam dump at Brewster's angle when there is minimum scatter).

2 - The mirrored plug (Part 20 in D0900095) which is suppose to be used for alignment is not very effective. It moves around too much in its hole in the front face of the beam dump. Just by touching it I could make the reflected beam jump around by about 0.1 radians.

- I think to align these properly we'll have to partly assemble the dumps. If we leave off the front plate of the horn then we can measure the reflection off the Si. If we measure this with a power meter then alignment becomes a simple matter of rotating until this reflection is minimized.

3. - For this measurement the incident beam was a small (~ 1mm diameter) central beam with a small amount of spray of laser light beyond that central region. This spray was hitting the aluminium front face of the beam dump and was scattering back to the photodiode. This was clearly the limiting factor in the measurement. Most of this light was spread horizontally so I placed a couple of pieces of black glass on either side of the aperture, just blocking the edges a little. This reduce the background reading at the minimum scatter from 17.0uV to around 4.5uV with still a little bit of light hitting the top and bottom of beam dump face.

 

The incident power on the beam dump fluctuated a little but was in the range 20.5 to 22mW. The response of the PD is approximately 0.2 A/W and the transimpedance is 7.5E4 V/A.

 

The SR830 Sensitivity was set to 1x1 mV.

 

It was difficult to measure the actual angle of incidence. The dump pivoted about a point directly under the input aperture at the front. By measuring the displacement of a point on the back of the dump as I rotated it and knowing the distance between this point and the pivot point I was able to make a reasonably accurate measurement of a range of angles about the minimum.

 

The measured scatter (in V measured directly by the PD and as a fraction of the incident power) is shown in the attached plots.

 

I think I can do a better job cleaning up the incident beam - so these numbers only represent an upper limit on the scatter.

 

attachment 1: beam dump assembly

attachment 2: experimental layout

attachment 3: scatter measurement

attachment 4: BRDF - (scatter divided by the solid angle = 1.1 m steradians)

attachment 5: (slightly blurred )photo of dump - overhead view 

Attachment 1: D0900095_ELIGO_35_WATT_AIR_COOLED_BEAM_DUMP_3INCH_P.POL-3.PDF
D0900095_ELIGO_35_WATT_AIR_COOLED_BEAM_DUMP_3INCH_P.POL-3.PDF
Attachment 2: beam_dump_expt.png
beam_dump_expt.png
Attachment 3: scatter_measurement1.pdf
scatter_measurement1.pdf
Attachment 4: BRDF1.pdf
BRDF1.pdf
Attachment 5: IMG_0308.JPG
IMG_0308.JPG
  1694   Wed Jun 24 10:53:34 2009 Chris ZimmermanUpdateGeneralWeek 1/2 Update

I've spent most of the last week doing background reading; fourier transforms, shm, e&m, and other physics that I didn't cover at school.  I also read a few chapters in Saulson, especially the chapter on noise and shot noise.  To get a better grip on what I'm going to be doing I read through the polarization chapter in Hobbs' "Optics" text, mostly on wave plates since that's a large part of this readout.  Since then I've been working up to calculating the shot noise, starting with the electric field throughout the new interferometer readout.

  1695   Wed Jun 24 11:20:40 2009 StephanieUpdateGeneralMultiply Resonant EOM Update

I have created the attached EOM circuit with resonances at 11 MHz, 29.5 MHz, and 55 MHz (the magnitude and phase of the voltage across the EOM are shown in the attached plot). The gain is roughly the same for each resonant peak. Although I have managed to get the impedances at all of the resonant frequencies to equal each other, I am having more trouble getting the impedances to be 50 Ohms (they are currently all around 0.66 Ohms).

For the current circuit, initial calculations show that we will need around 4.7 - 14.2 A of current to drive the EOM at the desired voltage (8 - 24 V); this is much higher than the current rating of most of the available transformers (250 mA), but the necessary current will change as the impedance of the circuit is corrected, so this is probably not a cause for concern. For example, the necessary driving voltages for the current circuit are (2.8 - 8.5 V); if we assume that the 50-Ohm impedance will be purely resistive, then we get a current range of 56 - 170 mA.

Attachment 1: EOM_CktDiagram.JPG
EOM_CktDiagram.JPG
Attachment 2: EOM_VoltagePlot.JPG
EOM_VoltagePlot.JPG
  1710   Wed Jul 1 10:56:42 2009 Chris ZimmermanUpdateGeneralWeek 2/3 Update

I spent the last week working a lot with the differences between a basic Michelson readout and the new one as a displacement sensor.  The new one (w/ wave plates) ends with two differently polarized beams and should have better sensitivity; I've also been going through noise/sensitivity calculations for each, although that hit a road block when I had to start the 1st SURF progress report, which has taken up most of my time since Saturday.

  1711   Wed Jul 1 11:00:52 2009 StephanieUpdateGeneralMultiply Resonant EOM Update

Since last week, I have come up with a new circuit, which is shown in the attached figure. The magnitude (solid) and phase (dashed) of the voltage across the EOM (red), the ratio between the voltage across the EOM and the voltage across the primary nodes of the transformer (blue), and the impedance through the primary port of the transformer (red) are also shown in an attached figure. As can be seen on the plot, resonance occurs at 11 MHz, 29.5 MHz, and 55 MHz, as specified. Also, at these resonant frequencies, the impedance is about 50 Ohms (34 dB). The gain between the voltage across the EOM and the voltage across the primary nodes of the transformer (or output of the crystal oscillator) is about 12 dB; we'd like a higher gain than this, but this gain is primarily governed by the ratio between the secondary and primary inductances in the transformer, and we are using the largest available ratio (on the Coilcraft website) that has the necessary bandwidth. Because of this, we will likely have to add another component between the crystal oscillator and the EOM circuit, to get the voltage to the desired 8.5 Vp across the EOM (for an optical modulation depth of 0.1 rad).

The current and power through the primary port of the tranformer are 43-85 mA and 25-92 mW, respectively. Since the transformer ratings are 250 mA and 1/4 W for current and power; these values should be safe to use with the intended transformer. Also, the highest power dissipated by a resistor in the circuit (not including the 50 Ohm resistor that is part of the crystal oscillator setup) is around 74 mW.

Attachment 1: EOMCKT.png
EOMCKT.png
Attachment 2: PR1_VoltagePlot.pdf
PR1_VoltagePlot.pdf
  1719   Wed Jul 8 10:56:04 2009 StephanieUpdateGeneralMultiply Resonant EOM Update

This week, I've been working on adapting the last week's circuit to make it buildable. Mostly this has involved picking components that are already in the lab, adding tunable components when necessary, and planning roughly how the components should be laid out on a board. I then built the circuit and put it in a box with BNC connectors for easy connection during testing. A picture of the built circuit is attached.

For initial testing, the transformer was removed from the design; since this changed the response of the circuit, I added two resistors to correct the response. A figure showing a schematic of the built circuit is attached. The expected responce of the circuit is also shown; the magnitude (solid) and phase (dashed) of the voltage across the EOM are shown in green, and the impedance of the circuit is shown in blue. While this response has sharp peaks and 50 Ohms (34 dB) of impedance at resonances, the gain is low compared to the circuit with the transformer. This means that, as is, this circuit cannot be used to drive the EOM; it is simply for testing purposes.

Attachment 1: DSC_0566.JPG
DSC_0566.JPG
Attachment 2: InitialBuiltCkt.pdf
InitialBuiltCkt.pdf
Attachment 3: BuiltCkt_ExpectedResponse.png
BuiltCkt_ExpectedResponse.png
  1720   Wed Jul 8 11:05:40 2009 Chris ZimmermanUpdateGeneralWeek 3/4 Update

The last week I've spent mostly working on calculating shot noise and other sensitivities in three michelson sensor setups, the standard michelson, the "long range" michelson (with wave plates), and the proposed EUCLID setup.  The goal is to show that there is some inherent advantage to the latter two setups as displacement sensors.  This involved looking into polarization and optics a lot more, so I've been spending a lot of time on that also.  For example, the displacement sensitivity/shot noise on the standard michelson is around 6:805*10^-17 m/rHz at L_=1*10^-7m, as shown in the graph.  NSD_Displacement.png

  1734   Sun Jul 12 23:14:56 2009 JenneOmnistructureGeneralWeb screenshots aren't being updated

Before heading back to the 40m to check on the computer situation, I thought I'd check the web screenshots page that Kakeru worked on, and it looks like none of the screens have been updated since June 1st.  I don't know what the story is on that one, or how to fix it, but it'd be handy if it were fixed.

ELOG V3.1.3-