ID |
Date |
Author |
Type |
Category |
Subject |
2736
|
Tue Mar 30 22:13:49 2010 |
Koji | Summary | Green Locking | conversion efficiency of PPKTP |
Question:
Why does the small spot size for the case (A) have small efficiency as the others? I thought the efficiency goes diverged to infinity as the radius of the cylinder gets smaller.
Quote: |
With a 30mm PPKTP crystal the conversion efficiency from 1064nm to 532nm is expected to 3.7 %/W.
Therefore we will have a green beam of more than 2mW by putting 700mW NPRO.
Last a couple of weeks I performed a numerical simulation for calculating the conversion efficiency of PPKTP crystal which we will have.
Here I try to mention about just the result. The detail will be followed later as another entry.
The attached figure is a result of the calculation.
The horizontal axis is the waist of an input Gaussian beam, and the vertical axis is the conversion efficiency.
You can see three curves in the figure, this is because I want to double check my calculation by comparing analytical solutions.
The curve named (A) is one of the simplest solution, which assumes that the incident beam is a cylindrical plane wave.
The other curve (B) is also analytic solution, but it assumes different condition; the power profile of incident beam is a Gaussian beam but propagates as a plane wave.
The last curve (C) is the result of my numerical simulation. In this calculation a focused Gaussian beam is injected into the crystal.
The numerical result seems to be reasonable because the shape and the number doesn't much differ from those analytical solutions.
|
|
2740
|
Wed Mar 31 11:52:32 2010 |
kiwamu | Summary | Green Locking | Re:conversion efficiency of PPKTP |
Good point. There is a trick to avoid a divergence.
Actually the radius of the cylindrical wave is set to the spot size at the surface of the crystal instead of an actual beam waist. This is the idea Dmass told me before.
So that the radius is expressed by w=w0(1+(L/2ZR)2)1/2, where w0 is beam waist, L is the length of the crystal and ZR is the rayleigh range.
In this case the radius can't go smaller than w0/2 and the solution can not diverge to infinity.
Quote: |
Question:
Why does the small spot size for the case (A) have small efficiency as the others? I thought the efficiency goes diverged to infinity as the radius of the cylinder gets smaller.
|
|
2762
|
Sun Apr 4 00:21:42 2010 |
rana, koji | Summary | Electronics | Checkout of EG&G (PARC) preamp model #113, s/n 49135 |
We tested out the functionality of the EG&G 113 preamp that I found in one of the cabinets. This is one of the ancestors of the SR560 preamp that we are all used to.
It turns out that it works just fine (in fact, its better than the SR560). The noise is below 3nV/rHz everywhere above 30 Hz. The filter settings from the front panel all seem to work well. And the red knob on the front panel allows for continuous (i.e. not steps) gain adjustment. In the high-bandwidth mode (low pass filter at 300 kHz), there is ~35 deg of phase lag at 100 kHz. So the box is pretty fast.

I would easily recommend this above the SR560 for use in all applications where you don't need to drive a 50 Ohm load. Also the battery is still working after 17 years!
There's several more of the this vintage in one of the last cabinets down the new Y-arm. |
2793
|
Mon Apr 12 19:50:30 2010 |
Aidan | Summary | Green Locking | Temperature sweep of the Lightwave: df/dT = 2.8GHz/K |
The beams from the Innolight and Lightwave NPROs were both incident on a 1GHZ New Focus PD. Mott and I swept the temperature of the Lightwave and tracked the change in frequency of the beatnote between the two. The Innolight temperature was set to 39.61C although the actual temperature was reported to be 39.62C.
Freq. vs temperature is plotted below in the attached PDF. The slope is 2.8GHz/K.
The data is in the attached MATLAB file. |
Attachment 1: LightWave_temp_sweep.pdf
|
|
Attachment 2: LightWave_Temp.m
|
% plot the data from the Lightwave Temperature sweep
% Lightwave temperature
LWTemp = [0.2744
0.2753
.2767
.2780
.2794
.2808
... 67 more lines ...
|
2794
|
Mon Apr 12 20:48:51 2010 |
Aidan, Mott | Summary | Green Locking | Temperature sweep of the Innolight: df/dT ~ 3.3GHz/K |
Quote: |
The beams from the Innolight and Lightwave NPROs were both incident on a 1GHZ New Focus PD. Mott and I swept the temperature of the Lightwave and tracked the change in frequency of the beatnote between the two. The Innolight temperature was set to 39.61C although the actual temperature was reported to be 39.62C.
Freq. vs temperature is plotted below in the attached PDF. The slope is 2.8GHz/K.
The data is in the attached MATLAB file.
|
Same thing for the Innolight Mephisto.
Not unexpected values with dn/dT around 11E-6 K^-1 and coefficient of thermal expansion = 8E-6 K^-1 and a laser resonator length of order 10cm. |
Attachment 1: Innolight_temp_sweep.pdf
|
|
Attachment 2: Innolight_Temp.m
|
% plot the data from the Innolight Temperature sweep
% Innolight temperature
InnTemp = [0.60
.59
.56
.52
.65] + 39;
... 25 more lines ...
|
2797
|
Tue Apr 13 12:39:51 2010 |
Aidan, Mott | Summary | Green Locking | Temperature sweep of the Innolight: df/dT ~ 3.3GHz/K |
Please put those numbers onto wiki somewhere at the green page or laser characterization page.
Quote: |
Quote: |
The beams from the Innolight and Lightwave NPROs were both incident on a 1GHZ New Focus PD. Mott and I swept the temperature of the Lightwave and tracked the change in frequency of the beatnote between the two. The Innolight temperature was set to 39.61C although the actual temperature was reported to be 39.62C.
Freq. vs temperature is plotted below in the attached PDF. The slope is 2.8GHz/K.
The data is in the attached MATLAB file.
|
Same thing for the Innolight Mephisto.
Not unexpected values with dn/dT around 11E-6 K^-1 and coefficient of thermal expansion = 8E-6 K^-1 and a laser resonator length of order 10cm.
|
|
2814
|
Tue Apr 20 09:15:15 2010 |
steve | Summary | SAFETY | annual safety audit |
|
Attachment 1: safa.PDF
|
|
2835
|
Fri Apr 23 18:30:49 2010 |
Aidan, Jenne, Koji | Summary | Green Locking | Green means GO! |
Jenne, Koji and I assembled the Covesion Oven today, inserted a PPKTP crystal from Raicol, aligned the crystal to a 50mW focus and
got some green beam coming out.
Covesion Oven assembly
The oven contains a brass clip that can clamp a crystal up to 10mm wide x 0.5mm high x 40mm long (according to the instructions). According to the correspondence from Covesion the clip can accomodate a crystal up to 1.5mm high. Our crystal is 1mm x 1mm x 30mm.
- We removed the brass springs from the clip - see Koji's photos
- We placed the Raicol PPKTP crystal (#725) into the clamp with the long polished surfaces facing out to the sides and the roughened surfaces facing up and down.
- We balanced the 10mm x 40mm x 1mm glass plate on top of the crystal.
- We replaced the brass springs in the top of the clip but only tightened the screws a couple of turns so they wouldn't fall out.
- Very carefully and slowly, I tightened the screws a few turns in a star-shaped order to distribute the pressure evenly across the glass top
- Each time I tightened all eight screws, I jiggled each of the four springs to see if there was any compression in them
- Once the springs started to show signs of compression I stopped tightening them and tested the stability of the glass plate - a reasonable amount of pressure was required to move the plate - about the same amount required to push a SR560 across an optical table with your index finger.
- We loosely attached the lid and moved the oven to the table
Alignment of the crystal to the focus
The oven was mounted on a 4-axis Newport translation stage. We plonked the assembly onto the table, removed the lid and adjusted the rough position so that a focus of the 1064nm beam, from a 100mm lens, was positioned near the center of the crystal - then it was clamped down to the table. From here we adjusted the alignment of the stage, using an IR card and a viewer to guide us, until we eventually saw some green beam coming out. We were all very excited by this! We optimized the alignment as best we could using the IR card and then we replaced the lid on the oven. At this point the temperature of the PPKTP was around 26.5C and the green beam coming out look quite dim. We turned the oven up to around 36 degC and observed the beam getting much brighter and we approached the optimum phase-matching condition.
We haven't done anyway quantitative measurements yet but we were pleased with how easy this first stage was.
[Edit by Koji] More photos are on Picasa album |
Attachment 1: IMG_2405.jpg
|
|
Attachment 2: IMG_2417.jpg
|
|
2863
|
Sun May 2 13:04:51 2010 |
Koji | Summary | SUS | Coil Actuator Balancing and Spot Position |
I liked to know quantitatively where the spot is on a mirror.
With an interferometer and A2L scripts, one can make the balance of the coil actuators
so that the angle actuation does not couple to the longitudinal motion.
i.e. node of the rotation is on the spot
Suppose you have actuator balancing (1+α) f and (1-α) f.
=> d = 0.016 x α [m]
Full Imbalance α = 1 -> d = 15 [mm]
10% Imbalance α = 0.1 -> d = 1.5 [mm]
1% Imbalance α = 0.01 -> d = 0.15 [mm]
Eq of Motion:
I ω2 θ = 2 R f
(correction) - I ω2 θ = D f cos(arctan(L/2/D))
(re-correction on Sep 26, 2017) - I ω2 θ = D f
m ω2 x = 2 α f ,
(correction) - m ω2 x = 2 α f ,
where R is the radius of the mirror, and D is the distance of the magnets. (kinda D=sqrt(2) R)
d, position of the node distant from the center, is given by
d = x/θ = α I / (m R) = 2 α β / D,
where β is the ratio of I and m. Putting R=37.5 [mm], L=25 [mm], β = 4.04 10-4 [m2], D~R Sqrt(2)
i.e. d = 0.015 α [m] |
Attachment 1: coil_balance.png
|
|
2865
|
Sun May 2 15:38:12 2010 |
rana | Summary | SUS | Coil Actuator Balancing and Spot Position |
Oh, but it gets even better: in order to trust the A2L script in this regard you have to know that the coil driver - coil - magnet gain is the same for each channel. Which you can't.
But we have these handy f2pRatio scripts that Vuk and Dan Busby worked on. They use the optical levers to balance the actuators at high frequency so that the A2L gives you a true spot readout.
But wait! We have 4 coils and the optical lever only gives us 2 signal readouts... |
2866
|
Sun May 2 16:52:44 2010 |
Koji | Summary | SUS | Coil Actuator Balancing and Spot Position |
Yes, of course. But so far I am trusting that the coils are inheretly balanced.
Probably you are talking about the dependence of the nodal position on the frequency...I need to check if 18Hz is sufficiently high or not for 0.1mm precision.
Also I am practicing myself to understand how I can adjust them by which screws as we probably have to do this adjustement many times.
(i.e. removal of the MZ, move of the table, PSL renewal and so on)
For the actuator calibration, we may be able to calibrate actuator responses by shaking them one by one while reading the OPLEV P/Y signals.
Quote: |
Oh, but it gets even better: in order to trust the A2L script in this regard you have to know that the coil driver - coil - magnet gain is the same for each channel. Which you can't.
But we have these handy f2pRatio scripts that Vuk and Dan Busby worked on. They use the optical levers to balance the actuators at high frequency so that the A2L gives you a true spot readout.
But wait! We have 4 coils and the optical lever only gives us 2 signal readouts...
|
|
2891
|
Thu May 6 19:23:54 2010 |
Frank | Summary | Computers | svn problems |
i tried to commit something this afternoon and got the following error message:
Command: Commit
Adding: C:\Caltech\Documents\40m-svn\nodus\frank
Error: Commit failed (details follow):
Error: Server sent unexpected return value (405 Method Not Allowed) in response to
Error: MKCOL request for '/svn/!svn/wrk/d2523f8e-eda2-d847-b8e5-59c020170cec/trunk/frank'
Finished!:
anyone had this before? what's wrong? |
2899
|
Sat May 8 02:38:08 2010 |
Koji | Summary | IOO | MC incident power |
As per Steve's request I checked the MC incident power as a function of time.
The output is negative: the lower voltage, the higher power.
Before I put the attenuator the incident power was 1.1W. It appear as -5V.
Now the output is -0.1V. This corresponds to 22mW.
|
Attachment 1: MC_input.png
|
|
2903
|
Mon May 10 17:47:16 2010 |
josephb | Summary | CDS | Finished |
So I finished writing a script which takes an .ipc file (the one which defines channel names and numbers for use with the RCG code generator), parses it, checks for duplicate channel names and ipcNums, and then parses and .mdl file looking for channel names, and outputs a new .ipc file with all the new channels added (without modifying existing channels).
The script is written in python, and for the moment can be found in /home/controls/advLigoRTS/src/epics/simLink/parse_mdl.py
I still need to add all the nice command line interface stuff, but the basic core works. And already found an error in my previous .ipc file, where I used the channel number 21 twice, apparently.
Right now its hard coded to read in C1.ipc and spy.mdl, and outputs to H1.ipc, but I should have that fixed tonight. |
2908
|
Mon May 10 20:33:29 2010 |
Koji | Summary | CDS | Finished |
This IPC stuff looks really a nice improvement of CDS.
Please just maintain the wiki updated so that we can keep the latest procedures and scripts to build the models.
Quote: |
So I finished writing a script which takes an .ipc file (the one which defines channel names and numbers for use with the RCG code generator), parses it, checks for duplicate channel names and ipcNums, and then parses and .mdl file looking for channel names, and outputs a new .ipc file with all the new channels added (without modifying existing channels).
The script is written in python, and for the moment can be found in /home/controls/advLigoRTS/src/epics/simLink/parse_mdl.py
I still need to add all the nice command line interface stuff, but the basic core works. And already found an error in my previous .ipc file, where I used the channel number 21 twice, apparently.
Right now its hard coded to read in C1.ipc and spy.mdl, and outputs to H1.ipc, but I should have that fixed tonight.
|
|
2928
|
Thu May 13 23:59:46 2010 |
Zach | Summary | IOO | MC table leveled |
After the recent removal of the old IMMT and the relocation of the Faraday isolator, the MC table was tilted a bit (southward and slightly westward---as of when I opened the chamber this afternoon). I re-leveled it by putting an extra two rectangular ballast blocks on the stack that was already hanging off the NNE edge of the table (there are a total of 4 in the stack now). I also screwed down the circular block that Koji and I put between the Faraday and SM1 on Tuesday, and re-mounted the two wire harness towers onto the table.
Needless to say, this threw the MC way out of alignment. I spent the rest of the afternoon reacquiring alignment and getting it to lock robustly. Here is a summary:
- I adjusted MC3 until I got the 2nd, 3rd+ pass beams to overlap with the input beam between MC1&3, then I adjusted MC2&1 semi-methodically until I got something flashing at the transmitted end. This took some time.
- I went back into the control room, engaged the loops and acquired lock on the TEM00 mode, whereupon I found that the beam spot was WAY off center on MC2 (due to my meddling with all the mirrors to get resonance flashes). I began using the MC2_spot_up (etc) scripts we wrote the other day to re-center it.
- After a few iterations, the lock became weak, and eventually gave out. This is because the REFL beam was falling off the RFPD (and being clipped by the iris on the AP table), so I moved the iris and re-centered the beam on the diode.
- With that, I was able to get the MC2 spot more or less centered, but then I noticed that---though the lock was clearly strong as evidenced both by the REFL power dip and visually via the camera on MC2---it looked like crap on the CCD. It seemed like there was some higher order mode structure sloshing around on top of the 00 spot, which didn't make any sense, until I realized that it was just a diffraction pattern from the TRANS beam getting clipped somewhere on the way out of the vacuum system.
- I went back to the AP table, where I noticed that the TRANS beam was hitting near the edges of several of the mirrors on the way back to the PSL table, including the first one out of the viewport, so I turned IM4 to center the beam on this mirror, then proceeded to center the beam on each mirror downstream and then onto the CCD.
- After getting a clear picture of the transmission on the CCD, centering the spot even better on MC2, then fine-tuning MC2&3 to strengthen the lock, I went back to the MC table to check that the transmitted beam was still passing through the center of the Faraday, which, by none other than an act of God, it was.
- Having done the necessary work in the tank, I ran the A2L_MC2 script to fine-tune the centering of the spot on MC2. It needed a couple steps up and to the side, but after that the actuator gains for pitch and yaw were both balanced again to within ~2%, which is only slightly above the measurement error. We will probably need to adjust this continually, especially during the upgrade, so I didn't bother with getting it better than that.
After that, I shut off the loops, blocked the beam, and put the light doors back on the tanks. Then I went to the parking lot, then I got in my car, etc, etc, etc. |
2929
|
Fri May 14 03:30:45 2010 |
Koji | Summary | IOO | MC table leveled |
Thanks Zach.This was a great job.
It was not mentioned but: was the Faraday clamped down on the table?
|
2931
|
Fri May 14 10:33:01 2010 |
Zach | Summary | IOO | MC table leveled |
Ah... no, I didn't. That explains why there were loose dogclamps on the table. I wrapped them in foil and put them on the clean cart. Can this wait until the next time we open the tank (i.e. to measure the beam profile), or should I go over there and clamp it down today?
|
2935
|
Sat May 15 04:13:33 2010 |
Koji | Summary | IOO | MC table leveled |
Fixing at the next time is absolutely OK.
Quote: |
Ah... no, I didn't. That explains why there were loose dogclamps on the table. I wrapped them in foil and put them on the clean cart. Can this wait until the next time we open the tank (i.e. to measure the beam profile), or should I go over there and clamp it down today?
|
|
2995
|
Wed May 26 18:54:55 2010 |
Aidan | Summary | Green Locking | Mounted Crystal 724 in the Doubling Oven |
Andri and I mounted the Raicol Crystal #724 in one of the new Covesion Ovens. The procedure was the same as before - see elog entry here.
There was one issue - the glass plate that goes on top of the crystal is coated on one side with ITO (Indium-Tin Oxide) and it's not 100% certain that this was mounted in the correct orientation. It is virtually impossible to tell which side of the glass is coated.
The base plate of the oven was tapped for an M3 hole. We retapped it for an 8-32 and bolted it to a post and that one of the New Focus 4-axis translation stage. The assembly is currently bolted to the PSL table, awaiting use. |
3048
|
Thu Jun 3 22:33:31 2010 |
valera | Summary | CDS | simulated plant work |
I put matlab files and a summary into the 40m wiki for the fitting of the 40m Optickle transfer functions and generating digital filters for the simulated plant:
http://lhocds.ligo-wa.caltech.edu:8000/40m/Generating_DOF-%3EPD_digital_filters_based_on_Optickle_modeling
The filters are not loaded yet. Joe and Alex will make a rcg code to make a matrix of filters (currently 5x15=75 elements) which will enable the simulated plant tf's.
Joe and I tried to put a signal through the DARM loop but the signal was not going through the memory location in the scx part of the simulated plant.
Edit by Joe:
I was able to track it down to the spx model not running properly. It needed the Burt Restore flag set to 1. I hadn't done that since the last rebuild, so it wasn't actually calculating anything until I flipped that flag. The data is now circulating all the way around. If I turn on the final input (the same one with the initial 1.0 offset), the data circulates completely around and starts integrating up. So the loop has been closed, just without all the correct filters in. |
3052
|
Sun Jun 6 08:08:05 2010 |
rana, sanjit | Summary | Electronics | Capacitor Bridge Test |
To get a feel for the Capacitive Bridge problems, we setup a simple bridge using fixed (1 nF) caps on a breadboard. We used an SR830 Lock-In amplifier to drive it and readout the noise.

We measured the cap values with an LCR meter. They were all within a few % of 0.99 nF.
With a 0.5 V drive to the top of the bridge, the A-B voltage was ~2 mV as expected from the matching of the capacitors.
(** Note about the gain in the SR830: In order to find the magnitude of the input referred signal, one has to divide by G. G = (10 V)/ Sensitivity. 'Sensitivity' is the setting on the front panel.)
- Directly measuring from Vs to ground gives 0.5 V, as expected. This is done to verify the calibration later on.
- Shorting the A and B wires to ground gives ~0 V and lets us measure the noise. On the spectrum analyzer it was ~400 nV/rHz at 100 Hz and rising slowly to 4 uV/rHz at 100 mHz. In this state, the sensitivity was 10 mV, so the overall gain was 1000. That gives an input referred level of ~0.4 nV/rHz at the input.
-
Hooking up now to A-B: the signal is ~10x larger than the 'dark' noise everywhere. 2 uV/rHz @ 100 Hz, 10 uV/rHz @ 10 Hz, 50 uV/rHz @ 1 Hz. The spectrum is very non-stationary; changing by factors of several up and down between averages. Probably a problem with the cheapo contacts in the breadboard + wind. The gain in this state was still 1000. So at 1 Hz, its 50 nV/rHz referred to the input.
To convert into units of capacitance fluctuation, we multiply by the capacitance of the capacitors (1 nF) and divide out by the peak-peak voltage (1 V). So the bridge sensitivity is 50e-9 * 1e-9 = 5 x 10^-17 F/rHz.
If we assume that we will have a capacitive displacement transducer giving 1 nF capacitance change for a 0.1 mm displacement, this bridge would have a sensitivity of 5 x 10^-12 m/rHz @ 1 Hz. We would like to do ~50-100x better than this. The next steps should be:
- Solder it all together on a PCB to have less air current sensitivity and decent contacts.
- Use a low-noise FET input. Since the impedance of the bridge is ~5 kOhms at this frequency, we are probably current noise limited.
- Estimate the oscillator amplitude noise sensitivity.
|
3061
|
Wed Jun 9 21:05:44 2010 |
rana | Summary | Computers | op540m is not to be used |
This is a reminder (mainly for Steve, who somehow doesn't believe these things) that op540m is not to be used for your general pleasure.
No web, no dataviewer, no DTT. Using these things often makes the graphical X-Windows crash. I have had to restart the StripTool, our seismic BLRMS and our Alarms many times because someone uses op540m, makes it crash, and then does not restart the processes.
Stop breaking op540m, Steve! |
3080
|
Wed Jun 16 11:31:19 2010 |
josephb | Summary | Computers | Removed scaling fonts from medm on Allegra |
Because it was driving me crazy while working on the new medm screens for the simulated plant, I went and removed the aliased font entries in /usr/share/X11/fonts/misc/fonts.alias that are associated with medm. Specifically I removed the lines starting with widgetDM_. I made a backup in the same directory called fonts.alias.bak with the old lines.
Medm now behaves the same on op440m, rosalba, and allegra - i.e. it can't find the widgetDM_ scalable fonts and defaults to a legible fixed font. |
3091
|
Sun Jun 20 16:07:23 2010 |
Koji | Summary | COC | Calibration of the metrology lab interferometer |
Kiwamu and Koji
Summary
We have visited GariLynn's lab to make a calibration of the metrology interferometer.
The newly calibrated value is
RoC(SRMU01) = 153.3+/- 1.6 [m]
This is to be compared with the specification of 142m +/- 5m
Although the calibration deviation from the previous value was found to be 1.3%, it is far from explaining the curvature difference between the spec (142m) and the measured value.
Motivation
The previous measurements of the SRM curvatures showed larger RoCs by ~10% compared with the spec.
It can be caused by the mis-calibration of the pixel size of the CCD in the metrology interferometer.
In order to confirm the calibration value, an object with known dimension should be measured by the instrument.
Method
We've got a flat blank optic from "Advanced Thin Film" together with a metalic ring.
The ring has been attached on the blank optic with 3 fragments of a double sided tape.
The RoC of SRMU1 was also measured in order to obtain "the radius of curvature of the day".
The calibration process is as follows:
- Measure the diameters of the ring by a caliper in advance to its attachment to the blank.
- Determine the inner and outer diameter of the ring in the obtained image.
Note that the obtained image is pre-calibrated by the default value given by the measurement program
(i.e. 0.270194mm/pixel for horizontal)
- Check the ratio of the diameters with the measured value by the caliper. Correct a systematic effect.
- Compare the image measurement and the caliper measurement.
Results
- The outer and inner diameters of 2.000" and 1.660" (measured by a caliper, error 0.005"). The ratio is 0.830+/-0.003.
- The center and radius for the inner circle were estimated to be (79.7924, 91.6372) and 21.4025 [mm].
The center and radius for the outer circle were estimated to be (79.6532, 91.6816) and 25.6925 [mm].
The error would be ~0.01mm considering they sweep 500 pixels by the circle and the pixel size is 0.27mm. i.e. 0.27/Sqrt(500) ~ 0.01mm
- Ratio of the inner and outer diameter is 0.8330 +/- 0.0005.
The systematic error of x is given by solving (21.4025+x)/(25.6925-x)=0.83 ==> x = -0.042 +/- 0.043 [mm]. This is just a 0.2% correction.
By correcting the above effect, we get (Rin, Rout) = (21.36 +/- 0.046, 25.74 +/- 0.047).
- By comparing the result with the caliper measurement, we get calibration factor of 1.013 +/- 0.005.
This means we measured "1mm" as "1.013mm". The scale was too small.
We have got the calibration of 0.2737+/-0.0014 [mm/pixel].
Discussion
Because of the calibration error, we measured too long RoC. The same day, we measured the curvature of SRMU01 as 155.26 m.
The newly calibrated value is
RoC(SRMU01) = 153.3+/- 1.6 [m]
This is the value to be compared with the specification of 142m +/- 5m
|
Attachment 1: ring1_inner_centering.pdf
|
|
Attachment 2: ring1_outer_centering.pdf
|
|
Attachment 3: SRMU01_pic.png
|
|
3102
|
Wed Jun 23 12:28:34 2010 |
Razib | Summary | Phase Camera | Weeekly Summary |
This past week I have completed the following tasks:
1. Built a trigger and power box for the camera GC 750M (06058) and took some test images to see whether the trigger box really works. Result: It is doing fine!
2. Went over the setup that is already sitting on the table. Ref: Aidan's elog entry
3. Attended seminars and talks given by Alan, Jahms, Koji and Rana.
4. Attended the mandatory laser safety training by Peter.
Expected task for this week (could be more):
1. Work out analytical expressions of the power of the carrier and sidebands going to the camera in the setup. (As suggested by Rana and Joe)
2. Work on producing beat signal to the camera using the He-Ne laser setup.
3. Move,if possible, to the Nd:YAG setup.
4. Go over the codes and paper by the past SURFers on the phase camera experiment.

|
Attachment 2: test1.png
|
|
3106
|
Wed Jun 23 15:15:53 2010 |
josephb | Summary | Computers | 40m computer security issue from last night and this morning |
The following is not 100% accurate, but represents my understanding of the events currently. I'm trying to get a full description from Christian and will hopefully be able to update this information later today.
Last night around 7:30 pm, Caltech detected evidence of computer virus located behind a linksys router with mac address matching our NAT router, and at the IP 131.215.114.177. We did not initially recognize the mac address as the routers because the labeled mac address was off by a digit, so we were looking for another old router for awhile. In addition, pings to 131.215.114.177 were not working from inside or outside of the martian network, but the router was clearly working.
However, about 5 minutes after Christian and Mike left, I found I could ping the address. When I placed the address into a web browser, the address brought us to the control interface for our NAT router (but only from the martian side, from the outside world it wasn't possible to reach it).
They turned logging on the router (which had been off by default) and started monitoring the traffic for a short time. Some unusual IP addresses showed up, and Mike said something about someone trying to IP spoof warning coming up. Something about a file sharing port showing up was briefly mentioned as well.
The outside IP address was changed to 131.215.115.189 and dhcp which apparently was on, was turned off. The password was changed and is in the usual place we keep router passwords.
Update: Christian said Mike has written up a security report and that he'll talk to him tomorrow and forward the relevant information to me. He notes there is possibly an infected laptop/workstation still at large. This could also be a personal laptop that was accidently connected to the martian network. Since it was found to be set to dhcp, its possible a laptop was connected to the wrong side and the user might not have realized this.
|
3125
|
Sat Jun 26 21:13:19 2010 |
rana | Summary | Computer Scripts / Programs | COMSOL 4.0 Installation |
I've installed COMSOL 4.0 for 32/64 bit Linux in /cvs/cds/caltech/apps/linux64/COMSOL40/
It seems to work, sort of.
Notes:
- It did NOT work according to the instructions. The CentOS automount had mounted /dev/scd0 on /media/COMSOL40. In this configuration, I was getting a permission denied error when trying to run the default setup script. I did a 'sudo umount /dev/scd0' to get rid of this bad mount and then remounted using 'sudo mount /dev/dvd /mnt'. After doing this, I ran the setup script '/mnt/setup' and got the GUI which started installing as usual.
- I also pointed it at the linux64/matlab/ installation.
- It seems to not work right on Rosalba because of my previous java episode. The x-forwarding from megatron also fails. It does work on allegra, however.
|
3127
|
Mon Jun 28 12:48:04 2010 |
josephb | Summary | CDS | CDS adapter board notes |
This applies to SUS:
Two ICS 110Bs. Each has 2 (4 total) 44 shielded conductors going to DAQ Interface Chassis (D990147-A). See pages 2 and 4.
Three Pentek 6102 Analog Outputs to LSC Anti-Image Board (D000186 Rev A). Each connected via 40 conductor ribbon cable (so 3 total). See page 5.
Eight XY220 to various whitening and dewhitening filters. 50 conductor ribbon cable for each (8 total). See page 10.
Three Pentek 6102 Analog Input to Op Lev interface board. 40 conductor ribbon cable for each (3 total). See page 13.
The following look to be part of the AUX crate, and thus don't need replacement:
Five VMIC113A to various Coil Drives, Optical Levers, and Whitening boards. 64 conductor ribbon cable for each (5 total). See page 11.
Three XY220 to various Coil boards. 50 conductor ribbon for each (3 total). See page 11.
This applies to WFS and LSC:
Two XY220 to whitening 1 and 2 boards. 50 conductor ribbon for each (2 total). See page 3.
Pentek 6102 to LSC Anti-image. 50 conductor ribbon. (1 total). See page 5.
The following are unclear if they belong to the FE or the Aux crate. Unable to check the physical setup at the moment.
One VMIC3113A to LSC I & Q, RFAM, QPD INT. 64 conductor ribbon cable. (Total 1). See page 4.
One XY220 to QPD Int. 50 conductor ribbon cable. (Total 1). See page 4.
The following look to be part of WFS, and aren't needed:
Two Pentek 6102 Analog Input to WFS boards. 40 conductor ribbon cables (2 Total). See page 1.
The following are part of the Aux crate, and don't need to be replaced:
Two VMIC3113A to Demods, PD, MC servo amp, PZT driver, Anti-imaging board. 64 conductor ribbon cable (2 Total). See page 3.
Two XY220 to Demods, MC Servo Amp, QPD Int boards. 50 conductor ribbon cable (2 Total). See page 3.
Three VMIC4116 to Demod and whitening boards. 50 conductor ribbon cable (3 Total). See page 3. |
3129
|
Mon Jun 28 21:26:05 2010 |
rana | Summary | CDS | CDS adapter board notes |
Those drawings are an OK start, but its obvious that things have changed at the 40m since 2002. We cannot rely on these drawings to determine all of the channel counts, etc.
I thought we had already been through all this...If not, we'll have to spend one afternoon going around and marking it all up.  |
3163
|
Wed Jul 7 00:15:29 2010 |
tara,Rana | Summary | PSL | power spectral density from RefCav transmitted beam |
I measured the RC transmitted light signals here at the 40m. I made all connections through the PSL patch panel.
Other than two steering mirrors in front of the periscope, and the steering mirror for the RFPD which were used to steer
the beam into the cavity and the RFPD respectively, no optics are adjusted.
We re-aligned the beam into the cavity (the DC level increased from 2 V to 3.83V) (Fig2) (We could not recover the power back to what it was 90 days ago)
and the reflected beam to the center of the RFPD.
I measured the spectral density of the signal of the transmitted beam behind RefCav in both time and frequency domain.
This will be compared with the result from PSL lab later, so I can see how stable the signal should be.
I did not convert Vrms/rtHz to Hz/rtHz because I only look at the relative intensity of the transmitted beam which will be compared to the setup at PSL lab.
We care about this power fluctuation because we plan to measure
photo refractive noise on the cavity's mirros
(this is the noise caused by dn/dT in the coatings and the substrate,
the absorption from fluctuating power on the coating/mirror changes
the temperature which eventually changes the effective length of the cavity as seen by the laser.)
The plan is to modulate the power of the beam going into the cavity,
the absorption from ac part will induce frequency noise which we want to see.
Since the transmitted power of the cavity is proportional to the power inside the cavity.
Fluctuations from other factors, for example, gain setting, will limit our measurement.
That's why we are concerned about the stability of the transmitted beam and made this measurement.
|
Attachment 1: RIN_rftrans.png
|
|
Attachment 2: tara.png
|
|
3164
|
Wed Jul 7 10:42:29 2010 |
Koji | Summary | PSL | power spectral density from RefCav transmitted beam |
How do you calibrate this to Hz/rtHz?
Quote: |
I measured the RC transmitted light signals here at the 40m. I made all connections through the PSL patch panel. No optics/PD were touched.
I measured the spectral density of the signal of the transmitted beam behind RefCav in both time and frequency domain.
This will be compared with the result from PSL lab later, so I can see how stable the signal should be.
We re-aligned the beam into the cavity (the DC level increased from 2 V to 3.83V)
and the reflected beam to the center of the RFPD.
|
|
3186
|
Fri Jul 9 11:41:58 2010 |
Gopal | Summary | Optic Stacks | Top Optic Layer Complete; Mechanical Tests Giving Problems |
For the last week, I have been attempting to determine the mirror stack transfer function which relates mechanical mirror response to a given ground-motion drive. The idea is to model the stacks in COMSOL and ultimately apply mechanical tests for manual calculation.
Procuring the correct drawings to base my 3D models off of was no simple task. There are two binders full of a random assortment of drawings, and some of them are associated with the smaller chambers, while others are appropriate for the main chamber, which is what we're interested in right now. For future workers, I suggest checking that your drawings are appropriate for the task at hand with other people before wasting time beginning the painstaking process of CAD design in COMSOL.
The drawings that I ultimately decided to use are attached below. They detail four layers of stacks, each which arrange 15, 12, 8, and 5 (going from bottom to top) Viton damping springs in an orderly fashion. The numbers have been chosen to keep the load per spring as constant as possible, in order for all springs to oscillate with as close a resonant frequency to each other as possible.



After making some minor simplifications, I have finished modeling the top stack:

After triangular meshing, before my many failed attempts at mechanical testing: 

Both the Viton and steel portions have been given their material properties, and so I should be (theoretically ) ready to perform some eigenfrequency calculations on this simplified system. If my predictions are correct, these eigenfrequencies shouldn’t be too far of the eigenfrequencies of the 4-layer stacked system, because of the layout of the springs. I’ve tried doing mechanical tests on the top stack alone, but there hasn’t been much progress yet on this end, mostly because of some boundary value exceptions that COMSOL keeps throwing at me.
In the next couple weeks or so, I plan to extend this model to combine all four layers into one completed stack, along with a simple steel base and mirror platform. I also plan to figure out how to make eigenfrequency and transfer function measurements.
Lastly, to anyone who is experienced with COMSOL, I am facing two major roadblocks and could really use your help:
1) How to import one model into another, merge models together, or copy and paste the same model over and over.
2) Understanding and debugging run-time errors during mechanical testing.
If you have any idea how to attack either of these issues, please talk to me! Thanks!
|
3189
|
Fri Jul 9 20:16:19 2010 |
rana | Summary | PSL | Things I did to the PSL today: Refcav, PMC, cameras, etc. |
I re-aligned the beam into the PMC. I got basically no improvement. So I instead changed the .LOW setting so that PMCTRANS would no longer go yellow and make the donkey sound.
I did the same for the MOPA's AMPMON because its decayed state is now nominal.
Steve and I removed the thermal insulation from around the reference cavity vacuum chamber. It wasn't really any good anyways.
Here are the denuded photos:
Steve and I are now planning to replace the foam with some good foam, but before that we will wrap the RC chamber with copper sheets like you would wrap a filet mignon with applewood bacon.
This should reduce the thermal gradients across the can. We will then mount the sensors directly to the copper sheet using thermal epoxy. We will also use copper to cover most of this hugely
oversized window flange - we only need a ~1" hole to get the 0.3 mm beam out of there.
My hope is that all of this will improve the temperature stability of this cavity. Right now the daily frequency fluctuations of the NPRO (locked to the RC) are ~100 MHz. This implies
that the cavity dT = (100 MHz) / (299792458 / 1064e-9) / (5e-7) = 1 deg. That's sad....
I also changed the RC_REFL cam to manual gain from AGC. I cranked it to max gain so that we can see the REFL image better. |
3190
|
Sun Jul 11 20:11:48 2010 |
rana | Summary | PSL | RC trend after the insulation removal |

|
3196
|
Mon Jul 12 14:22:36 2010 |
Jenne | Summary | PSL | Things I did to the PSL today: Refcav, PMC, cameras, etc. |
Quote: |
I re-aligned the beam into the PMC. I got basically no improvement. So I instead changed the .LOW setting so that PMCTRANS would no longer go yellow and make the donkey sound.
I did the same for the MOPA's AMPMON because its decayed state is now nominal.
|
[Jenne, Chip]
The alarm was still going, because the LOLO setting was higher than the LOW, which is a little bit silly. So we changed the .LOLO setting to 0.80 (the LOW was set to 0.82)
We also changed psl.db to reflect these values, so that they'll be in there the next time c1psl gets rebooted. |
3210
|
Tue Jul 13 21:04:49 2010 |
tara,rana | Summary | PSL | Transfer function of FSS servo |
I measured FSS's open loop transfer function.
For FSS servo schematic, see D040105-B.
4395A's source out is connected to Test point 2 on the patch panel.
Test Point 2 is enabled by FSS medm screen.
"A" channel is connected to In1, on the patch panel.
"R" channel is connected to In2, on the patch panel.
the plot shows signal from A/R.
Note that the magnitude has not been corrected for the impedance match yet.
So the real UGF will be different from the plot.
-------------------------
4395A setup
-------------------------
network analyzer mode
frequency span 1k - 10MHz
Intermediate frequency bandwidth 100Hz
Attenuator: 0 for both channels
Source out power: -30 dBm
sweep log frequency
------------------------------
medm screen setup
-----------------------------
TP2: enabled
Common gain -4.8 dB
Fast Gain 16 dB |
Attachment 1: TF_FSS_ser.png
|
|
3212
|
Wed Jul 14 01:05:27 2010 |
Sharmila,Katharine | Summary | elog | Maglev |
Yesterday we hooked up the Quadrant Maglev control to the power supply to test the components in the Input/Output part of the circuit.
The output from the buffer was an unexpected high noise signal which was caused by some circuit components.
Consequently these were replaced/removed after confirming the source of noise.
The following is a story of how it was done.
To test the components of input/output, we measured the output across TP_PD3(Test Point -Photo Diode 3).
We got a high noise signal with a frequency of several kHz.
We tested the values of various electronic components. The resistances R5 and R6 did not measure as mentioned(each had a value of 50 K in the schematic). The value of R6 was 10 K and we replaced R5 with a 10 K resistor. We still got the noise signal at 5.760 kHz with a Pk-Pk voltage of 2.6 V. The resistors in R-LED measured 1.5 K instead of the marked 2.2 K.

We had three suspects in hand: 
- BUF634P : A buffer from the Sallen-Key filter to the LED.
- C24 : A capacitor which is a part of the Sallen-Key filter.
- C23 : A capacitor in the feedback circuit of the Sallen-Key filter.
BUF634P : The data sheet for the BUF634P instructed a short across the 1-4 terminals in the presence of capacitive load. We followed this to overcome the effect(if any) of the extra-long BNC cables which we were using. The oscilloscope still waved 'Hi!' at a few kHz. We removed the buffer and also the feedback resistor R42 from the circuit, what we were testing boiled down to measuring the output of the Sallen-Key filter. The output still contained the funny yet properly periodic signal at a few kHz.
.
C24: Removing C24 did not do any good.
C23: As a final step C23 was removed. And ... We got a stable DC at 9.86 V(almost stable DC with a low noise at a few MHz). C24 and the buffer were replaced and output seemed fine. The output was a high frequency sine wave which was riding on a DC of 9.96 V.

We rechecked if the LED was on and the infrared viewer gave a positive signal.   
We went ahead obtaining the transfer function of the feedback control for which we used a spectrum analyzer.
The input for feedback system is a photo current whereas the spectrum analyzer tests the circuit with a voltage impulse. Hence the voltage input from the spectrum analyzer needs to be converted into current of suitable amplitude(few microamps) for testing the spectrum analyzer. Similarly the output which is a coil current needs to be changed to a voltage output through a load for feeding into the channel of the spectrum analyzer. We used a suitable resistance box with BNC receiving ends to do this. We obtained a plot for the transfer function which is shown below.

Future plans:
- Check the calculated transfer functions with the plot of the spectrum analyzer
- Model the entire(OSEM, magnet, actuators etc.) system in Simulink and calculate the overall transfer function
- Stable levitation of the 1X1 system |
3217
|
Wed Jul 14 12:12:03 2010 |
Razib | Summary | Phase Camera | Weekly update |
This week I was mainly interested in investigating the noise source at the phase camera. So having this issue in mind, my activities are the following:
1. I worked on producing multiple beat signal (1Hz and 5Hz). Elog entry.
2. I altered the setup so that instead of triggering the camera from the signal generator, we are now triggering it from the beat signal from the reference beam and sideband.
3. I made the nice little aluminium table for all the amplifiers, mixer and splitters to sit at one place instead of floating around.
4. I talked with Aidan and Joe and verified my calculation and extended it to further investigation of the noise source in the setup.
Plan for the upcoming week:
1. Measure and calibrate the camera w.r.t the power incident on it.
2. Investigate the noise source. |
3223
|
Wed Jul 14 19:15:26 2010 |
Gopal | Summary | Optic Stacks | REVISION: Eigenfrequency Analysis of Single Stack Complete |
My previous eigenfrequency analysis was incorrect by two orders of magnitude due to the misuse of Young's Modulus information for Viton. After editing this parameter (as documented on 7/14 19:00), the eigenmodes became much more reasonable. I also discovered the Deformation option under the Surface Plotting Options, which makes the eigenmodes of the single stack much more apparant.
Attached are pictures of the first four eigenmodes:
First Eigenmode: y-translational, 7.49 Hz

Second Eigenmode: x-translational, 7.55 Hz

Third Eigenmode: z-rotational, 8.63 Hz

Fourth Eigenmode: z-translational, 18.26 Hz

|
Attachment 2: Eigenfrequency_2_Stack4.png
|
|
3232
|
Thu Jul 15 19:27:04 2010 |
rana | Summary | PSL | RC trend after the insulation removal |

As you can see, there was not much (if any) worsening of the laser frequency fluctuation from removing the RefCav insulation. The plots below are zooomed in:
 
I have used the same peak-to-peak scale so that its easy to compare the fluctuations before (LEFT) and after (RIGHT).
As you can clearly see, the laser frequency moves just as much now (the SLOW_DC) as it did before when it had the insulation. Only now the apparent (i.e. fake) RC temperature fluctuations are much larger. So this sensor is fairly useless as configured. |
3247
|
Mon Jul 19 21:47:36 2010 |
rana | Summary | DAQ | DAQ timing test |
Since we now have a good measurement of the phase noise of the Rb clock Marconi locked to the Rb clock, I wanted to use that to check out the old DAQ system:
I used Megan's phase noise setup - Marconi #2 is putting out 11000013 Hz at 13 dBm into the ZP-3MH mixer. Marconi #1 is putting out 3 dBm at 11000000 Hz into the RF input.
The output goes through a 50 Ohm load and then a Mini-Circuits BNC LP filter (either 2 or 5 MHz). Then an SR560 set for low noise, G = 5, AC coupling, 1-pole LP @ 1 kHz.
This SR560 output goes into the channel C1:IOO-MC_DRUM1 (which is sampled at 16384 Hz with ICS-110B after the usual Sander Liu AA chassis containing the INA134s). |
3260
|
Wed Jul 21 15:43:38 2010 |
Megan | Summary | PSL | Copper Layer Thickness on the Reference Cavity |
Using the equation for thermal resistance
Rthermal = L/(k*A)
where k is the thermal conductivity of a material, L is the length, and A is the surface area through which the heat passes, I could find the thermal resistance of the copper and stainless steel on the reference cavity. To reduce temperature gradients across the vacuum chamber, the thermal resistance of the copper must be the same or less than that of the stainless steel. Since the copper is directly on top of the stainless steel, the length and width will be the same for both, just the thickness will be different (for ease of calculation, I assumed flat, rectangular strips of the metal). Assuming we wish to have a thermal resistance of the copper n times less than that of the stainless steel, we have
RCu = RSS/n
or
L/(kCu*w*tCu) = L/(kSS*w*tSS*n)
so that
tCu/tSS = n*kSS/kCu
We know that kSS = 401 W/m*K and KCu = 16 W/m*K, so
tCu/tSS = 0.0399*n
By using the drawings for the short reference cavity vacuum chamber (the only one I could find drawings for online) I found a thickness of the walls of 0.12 in or 0.3048 cm. So for the same thermal resistance in both metals, the copper must be 0.0122 cm thick and for a thermal resistance 10 times less, it must be 0.122 cm thick. So we will have to keep wrapping the copper on the vacuum chamber! |
3299
|
Tue Jul 27 16:03:36 2010 |
rana | Summary | DAQ | DAQ timing test |
Quote: |
Since we now have a good measurement of the phase noise of the Rb clock Marconi locked to the Rb clock, I wanted to use that to check out the old DAQ system:
I used Megan's phase noise setup - Marconi #2 is putting out 11000013 Hz at 13 dBm into the ZP-3MH mixer. Marconi #1 is putting out 3 dBm at 11000000 Hz into the RF input.
The output goes through a 50 Ohm load and then a Mini-Circuits BNC LP filter (either 2 or 5 MHz). Then an SR560 set for low noise, G = 5, AC coupling, 1-pole LP @ 1 kHz.
This SR560 output goes into the channel C1:IOO-MC_DRUM1 (which is sampled at 16384 Hz with ICS-110B after the usual Sander Liu AA chassis containing the INA134s).
|
This is the 0.3 mHz BW spectrum of this test - as you can see the apparent linewidth (assuming the width is all caused by the DAQ jitter) is comparable to the BW and therefore not resolved.
Basically, the Hanning window function is not sharp enough to do this test and so I will do it offline in Matlab. |
Attachment 1: Untitled.png
|
|
3300
|
Tue Jul 27 16:33:50 2010 |
Koji | Summary | General | High school students tour |
Jenne made the 40m tour for the annual visit of 30-40 students.
c.f.
Tour 2009 http://nodus.ligo.caltech.edu:8080/40m/1717
Tour 2008 http://nodus.ligo.caltech.edu:8080/40m/737
|
Attachment 1: IMG_2657.jpg
|
|
3317
|
Thu Jul 29 12:13:28 2010 |
kiwamu | Summary | CDS | near term plan |
[Joe and Kiwamu]

|
3318
|
Thu Jul 29 12:31:09 2010 |
Koji | Summary | General | Lab Schedule |
July
29 Thu BS chamber work: Move cable towers / green steering mirrors / (2 TTs with TT charactrization) / Put the heavy door by 5PM.
30 Fri Pumping down
31 Sat WFS work by Nancy
Aug
1 Sun - 5 Thu WFS work by Nancy
5 Thu PSL Table prep
6 Fri PSL Table prep / Likely to shut down the PSL
9 Mon PSL Table prep / shutting down of the PSL (optional)
10 Tue PSL box Frame lifting
12 Thu PSL table tapping
16 Mon - 17 Tue concrete pouring preparation
19 Thu - 23 Fri Tripod placement
24 Tue - 26 Thu concrete pouring |
Attachment 1: PSL_work_schedule.pdf
|
|
3324
|
Thu Jul 29 20:43:32 2010 |
Gopal | Summary | Optic Stacks | Modeling Tips and Tilts |
I have discovered a method of completely characterizing the 6x6 response of all six types (x-,y-, and z- translational/rotational) of oscillatory disturbances at the base of the stack.
- "Tipping" drives are trivial, and simply require a face load in the appropriate direction.
- "Tilting" drives could use a torque, but I am instead implementing multiple edge loads in opposing directions to create the appropriate net curl. This curl will be kept constant across the three axes for sake of comparing the resulting transfer functions.
- "Tipping" responses are once again trivial, and merely require the displacement vector of the top center coordinate to be recorded.
- "Tilting" responses require the normal vector to be recorded and manipulated to produce the angular coordinates (assuming right-handed coordinate system):
- θx = tan-1(x/z)
- θy = tan-1(y/z)
- θz = tan-1(y/x)
The first three concepts have been confirmed through simulations to produce correct transfer functions. The last test seems to be producing some problems, in that the vector normal to the equilibrium position (an obvious and useless piece of information) is sometimes given instead of the vector normal to the position of maximum displacement. This means that, as of now, I have the capability of measure the half of the complete 6x6 matrix of transfer functions in the coming weeks. The first three of eighteen transfer functions are attached below and will be included in my progress report.
   |
3339
|
Sat Jul 31 04:03:11 2010 |
Gopal | Summary | Optic Stacks | Complete Displacement Translational Transfer Function Matrix |
Over the past 36 hours, I've run full-fledged FDAs on KALLO.
The transfer functions for translational drives and responses are neatly described by the attached transfer function "matrix."

Next steps:
1) Extend the 3x3 analysis to include tilts and rotations in a 6x6 analysis.
2) Figure out how to do the same types of tests for phase instead of displacement. |
3345
|
Sun Aug 1 21:04:45 2010 |
rana | Summary | Computer Scripts / Programs | MC Autolocker fixed |
Someone had left a typo in the MC autolocker script recently while trying to set the lock threshold to 0.09. As a result, the autlocker wouldn't run.
I repaired it, made a few readability improvements, and checked in the new version to the SVN. If you make script changes, check them in. If you think its too minor of a change for a SVN checkin, don't do it at all. |