ID |
Date |
Author |
Type |
Category |
Subject |
12109
|
Thu May 5 21:28:44 2016 |
gautam | Update | endtable upgrade | Innolight PZT capacitance |
I suggested in an earlier elog that after the repair of the NPRO, the PZT capacitance may have changed dramatically. This seems unlikely - I measured the PZT capacitance with the BK Precision LCR meter and found it to be 2.62 nF, which is in excellent agreement with the numbers from elogs 3640 and 4354 - but this makes me wonder how the old setup ever worked. If the PZT capacitance were indeed that value, then for the Pomona box design in elog 4354, and assuming the PM at ~216kHz which was the old modulation frequency was ~30rad/V as suggested by the data in this elog, we would have had a modulation depth of 0.75 if the Function Generator were set to output a Signal at 2Vpp (2Vpp * 0.5 * 0.05 * 30rad/V = 1.5rad pp)! Am I missing something here?
Instead of using an attenuator, we could instead change the capacitor in the pomona box from 47pF mica to 5pF mica to realize a modulation depth of ~0.2 at the new modulation frequency of 231.25 kHz. In any case, as elog 4354 suggests, the phase introduced by this high-pass filter is non-zero at the modulation frequency, so we may also want to install an all-pass filter which will allow us to control the demodulation phase. This should be easy enough to implement with an Op27 and passive components we have in hand...
|
12122
|
Thu May 19 16:29:20 2016 |
Steve | Update | endtable upgrade | Optical layout almost complete |
|
12526
|
Fri Sep 30 19:53:07 2016 |
gautam | Update | endtable upgrade | X end IR pickoff fiber coupled |
[johannes, gautam]
Today we re-installed the fiber coupler on the X-endtable to couple some of the PSL light into a fiber that runs to the PSL table, where it is combined with a similar PSL pickoff to make an IR beat between the EX AUX laser and the PSL. The main motivation behind this was to make the process of finding the green beatnote easier. We used JAMMT (just another mode matching tool) to calculate a two lens solution to couple the light into the collimator - we use a +200mm and -200mm lens, I will upload a more detailed mode matching calculation + plot + picture soon. We wanted to have a beam waist of 350um at the collimator, a number calculated using the following formula from the Thorlabs website:

where d is the diameter of the output beam from the collimator, f is the collimating lens focal length and MFD is 6.6um for the fiber we use.
There is ~26mW of IR light coming through the BS after the EX AUX - after playing around with the 6 axis stage that the coupler is mounted on, Johannes got the IR transmission to the PSL table up to ~11.7mW. The mode matching efficiency of 45% is certainly not stellar, but we were more curious to find a beat and possibly measure the X arm loss so we decided to accept this for now - we could probably improve this by moving the lenses around. We then attenuated the input beam to the fiber by means of an ND filter such that the light incident on the coupler is now ~1.3mW, and the light arriving at the PSL table from the EX laser is ~550uW. Along with the PSL light, after the various couplers, we have ~500uW of light going to the IR beat PD - well below its 2mW threshold.
The IR beat was easily found with the frequency counter setup. However, there was no evidence of a green beat. So we went to the PSL table and did the near-field-far-field alignment onto the beat PD. After doing this, we were able to see a beat - but the amplitude was puny (~-60dBm, we are more used to seeing ~-20dBm on the network analyzer in the control room). Perhaps this can be improved by tweaking the alignment onto the PD while monitoring the RF output with an oscilloscope.
Moreover, the green PDH problems with the X end persist - even though the arm readily locks to a TEM00 mode, it frequently spontaneously drops lock. I twiddled around with the gain on the uPDH box while looking at the error signal while locked on a oscilloscope, but was unable to mitigate the situation. Perhaps the loop shape needs to be measured and that should tell us if the gain is too low or high. But ALS is getting closer to the nominal state...
Johannes is running his loss measurement script on the X arm - but this should be done by ~10pm tonight.
|
12532
|
Wed Oct 5 16:28:10 2016 |
gautam | Update | endtable upgrade | EX laser power monitor PD installed |
I installed a 10% BS to pick off some of the light going to the IR fiber, and have added a Thorlabs PDA55 PD to the EX table setup. The idea is to be able to monitor the power output of the EX NPRO over long time scales, and also to serve as an additional diagnostic tool for when ALS gets glitchy etc. There is about 0.4mW of IR power incident on the PD (as measured with the Ophir power meter), which translates to ~2500 ADC counts (~1.67V as measured with an Oscilloscope set to high impedance directly at the PD output). The output of the PD is presently going to Ch5 of the same board that receives the OL QPD voltages (which corresponds to ADC channel 28). Previously, I had borrowed the power and signal cables from the High-Gain Transmon PD to monitor this channel, but today I have laid out independent cabling and also restored the Transmon PD to its nominal state.
On the CDS side of things, I edited C1SCX to route the signal from ADC Ch28 to the ALS block. I also edited the ALS_END library part to have an additional input for the power monitor, to keep the naming conventions consistent. I have added a gain in the filter module to calibrate the readout into mW using these numbers. The channel is called C1:ALS-X_POWER_OUT, and is DQed for long-term trending purposes.
The main ALS screen is a bit cluttered so I have added this channel to the ALS overview MEDM screen for now.. |
438
|
Tue Apr 22 22:19:02 2008 |
rob | Metaphysics | lore | jiggling sliders |
In the interests of tacit communication of scientific knowledge, I here reveal a nugget of knowledge which may or may not prove useful to new LIGOites: sometimes when front-end machines are rebooted, the hardware they control can wind up in a state which is not accurately represented by the EPICS values you may see. This can be easily rectified by momentarily changing the EPICS settings in question. For reference, this came up tonight in the context of the whitening gain sliders for the TransMon QPDs. |
1104
|
Sun Nov 2 20:21:58 2008 |
rana | Configuration | lore | HP 5550dtn (Grazia) set up on allegra |
I set up printing to grazia from allegra. The CUPS interface was not as straightforward as Tobin had made it seem in the Wiki. I had to type in the IP address and port number by hand.
The steps (AFAIR):1) Goto http://localhost:631/
2) Click on "Add Printer"
3) Choose HP JetDirect
4) Use the correct address (socket://131.215.115.220:9100)
5) Choose HP and the 5550 postscript driver as the options
6) Try to only print useful stuff and not kill too many trees. |
1217
|
Thu Jan 8 16:49:37 2009 |
rana | Configuration | lore | HP 5550dtn (Grazia) set up on allegra |
Quote: | I set up printing to grazia from allegra. The CUPS interface was not as straightforward as Tobin had made it seem in the Wiki. I had to type in the IP address and port number by hand.
The steps (AFAIR):1) Goto http://localhost:631/
2) Click on "Add Printer"
3) Choose HP JetDirect
4) Use the correct address (socket://131.215.115.220:9100)
5) Choose HP and the 5550 postscript driver as the options
6) Try to only print useful stuff and not kill too many trees. |
It ought to be root to do that. |
1579
|
Wed May 13 02:53:12 2009 |
rob | Summary | lore | Channel Hopping: That ancient enemy (MC problems) |
We were stymied tonight by a problem which began late this afternoon. The MC would periodically go angularly unstable, breaking lock and tripping the MC2 watchdogs. Suspicion fell naturally upon McWFS.
Eventually I traced the problem to the MC3 SIDE damping, which appeared to not work--it wouldn't actually damp, and the Vmon values did not correspond to the SDSEN outputs. Suspicion fell on the coil driver.
Looking at the LEMO monitors on the MC3 coil driver, with the damping engaged, showed clear bit resolution at the 100mV level, indicating a digital/DAC problem. Rebooting c1sosvme, which acquires all the OSEM sensor signals and actually does the side damping, resolved the issue. |
1582
|
Wed May 13 14:43:29 2009 |
rob | Summary | lore | Channel Hopping: That ancient enemy (MC problems) |
Quote: |
We were stymied tonight by a problem which began late this afternoon. The MC would periodically go angularly unstable, breaking lock and tripping the MC2 watchdogs. Suspicion fell naturally upon McWFS.
Eventually I traced the problem to the MC3 SIDE damping, which appeared to not work--it wouldn't actually damp, and the Vmon values did not correspond to the SDSEN outputs. Suspicion fell on the coil driver.
Looking at the LEMO monitors on the MC3 coil driver, with the damping engaged, showed clear bit resolution at the 100mV level, indicating a digital/DAC problem. Rebooting c1sosvme, which acquires all the OSEM sensor signals and actually does the side damping, resolved the issue.
|
Lies! The problem was not resolved. The plot shows a 2-day trend, with the onset of the problem yesterday clearly visible as well as the ineffectiveness of the soft-reboot done yesterday. So we'll try a hard-reboot. |
2138
|
Fri Oct 23 15:02:00 2009 |
rob | Update | lore | marconi phase |
So, it appears that one doesn't even have to change the Marconi set frequency to alter the phase of the output signal. It appears that other front panel actions (turning external modulations on/off, changing the modulation type) can do it as well. At least that's what I conclude from earlier this morning, when after setting up the f2 Marconi (166MHz) for external AM, the double-demod handoff in the DRMI no longer worked. Luckily this isn't a real problem now that we have the setDDphases and senseDRM scripts. |
2139
|
Sat Oct 24 04:57:33 2009 |
rana | Update | lore | marconi phase |
Quote: |
So, it appears that one doesn't even have to change the Marconi set frequency to alter the phase of the output signal. It appears that other front panel actions (turning external modulations on/off, changing the modulation type) can do it as well. At least that's what I conclude from earlier this morning, when after setting up the f2 Marconi (166MHz) for external AM, the double-demod handoff in the DRMI no longer worked. Luckily this isn't a real problem now that we have the setDDphases and senseDRM scripts.
|
The real problem is that we are using frequency synthesizers to make the beat signals (133 and 199) instead of mixers. Luckily, the future 40m will not use beat signals (?) or synthesizers. |
2414
|
Mon Dec 14 15:18:18 2009 |
Jenne | Update | lore | armLoss script ran....results confidential |
I ran the armLoss script for both Xarm and Yarm. The results are confidential, pending the completion of Alberto's cavity pole/finesse measurement due to the 'bet' as to what the new losses are after the drag wiping.
If you're the kind of person who likes to look at their Chrismas presents, the log files with the results are in the usual place for this script: /scripts/LSC/loss-ARM-GPStime.log (loss-Y-944865071.log and loss-X-944865946.log) |
2566
|
Wed Feb 3 09:01:42 2010 |
rob | Update | lore | IFO isn't playing nice tonight |
Quote: |
I checked the situation from my home and the problem was solved.
The main problem was undefined state of the autolocker and the strange undefined switch states, being associated with the bootfest and burtrestore.
- MC UP/DOWN status shows it was up and down. So I ran scripts/MC/mcup and scripts/MC/mcdown . These cleared the MC autolocker status.
- I had a problem handling the FSS. After mcup/mcdown above, I randomly pushed the "enable/disable" buttons and others, and with some reason, it recovered the handling. Actually it acquired the lock autonomously. Kiwamu may have also been working on it at the same time???
- Then, I checked the PSL loop. I disconnected the loop by pushing the "test" button. The DC slider changes the PZT voltage only 0~+24V. This is totally strange and I started pushing the buttons randomly. As soon as I pushed the "BLANK"/"NORMAL" button, the PZT output got back under the control.
- Then I locked the PMC, MZ, and MC as usual.
Alberto: You must be careful as the modulations were restored.
Quote: |
[Jenne, Kiwamu]
It's been an iffy last few hours here at the 40m. Kiwamu, Koji and I were all sitting at our desks, and the computers / RFM network decided to crash. We brought all of the computers back, but now the RefCav and PMC don't want to lock. I'm a wee bit confused by this. Both Kiwamu and I have given it a shot, and we can each get the ref cav to sit and flash, but we can't catch it. Also, when I bring the PMC slider rail to rail, we see no change in the PMC refl camera. Since c1psl had been finicky coming back the first time, I tried soft rebooting, and then keying the crate again, but the symptoms remained the same. Also, I tried burt restoring to several different times in the last few days, to see if that helped. It didn't. I did notice that MC2 was unhappy, which was a result of the burtrestores setting the MCL filters as if the cavity were locked, so I manually ran mcdown. Also, the MC autolocker script had died, so Kiwamu brought it back to life.
Since we've spent an hour on trying to relock the PSL cavities (the descriptive word I'm going to suggest for us is persistent, not losers), we're giving up in favor of waiting for expert advice in the morning. I suppose there's something obvious that we're missing, but we haven't found it yet......
|
|
This is a (sort of) known problem with the EPICS computers: it's generally called the 'sticky slider' problem, but of course it applies to buttons as well. It happens after a reboot, when the MEDM control/readback values don't match the actual applied voltages. The solution (so far) is just to `twiddle' the problematic sliders/button. There's a script somewhere called slider_twiddle that does this, but I don't remember if it has PSL stuff in it. A better solution is probably to have an individual slider twiddle script for each target machine, and add the running of that script to the reboot ritual in the wiki. |
2598
|
Fri Feb 12 14:19:28 2010 |
rana, steve | HowTo | lore | International Fax |
Steve showed me how to send an international fax today:
- Load paper.
- Dial: 011 - (country code) - number
- Press START (either the black or color option)
- wait for the screaming fax noise
- Done
|
3660
|
Wed Oct 6 14:49:54 2010 |
rana | Summary | lore | Steve on the sea |

|
4960
|
Mon Jul 11 14:03:37 2011 |
steve | HowTo | lore | how to visit your old lab |
Alberto is visiting us from Australia. He brought some terrific presents. It is going to be very demanding task to wait for the rest of the 40m team
to return from Wales to taste coffee: PNG Peaberry of Wagonga, Monsooned Malabar of Jindebah and Signature Blue Blend of Cosmorex. |
6694
|
Sun May 27 17:19:27 2012 |
rana | Summary | lore | Strawberries |
We have placed some sweet giant strawberries in the fridge; free for eating for anyone working in the lab today or tomorrow:

|
8887
|
Mon Jul 22 03:10:41 2013 |
rana | Summary | lore | Angel of the Y End Table? |
Trying to take an image or movie of the ETMY Transmon cam, we got instead this attached image.
I think it is just some scattered green light, but others in the control room think that it is a message from somewhere or someone... |
8888
|
Mon Jul 22 06:58:17 2013 |
Lisa | Summary | lore | Angel of the Y End Table? |
Quote: |
Trying to take an image or movie of the ETMY Transmon cam, we got instead this attached image.
I think it is just some scattered green light, but others in the control room think that it is a message from somewhere or someone...
|
It is not an angel, it is clearly a four leaf clover (also known as "quadrifoglio"). It is very rare, it brings good luck! |
9966
|
Fri May 16 20:55:18 2014 |
Jamie | Frogs | lore | un-full-screening Ubuntu windows with F11 |
Last week Rana and I struggled to figure out how to un-full-screen windows on the Ubuntu workstations that appeared to be stuck in some sort of full screen mode such that the "Titlebar" was not on the screen. Nothing seemed to work. We were in despair.
Well, there is now hope: it appears that this really is a "fullscreen" mode that can be activated by hitting F11. It can therefore easily be undone by hitting F11 again. |
12915
|
Wed Mar 29 09:24:28 2017 |
Steve | Update | lore | summery pages |
The summery pages are working at a slow motion speed. It's response time 12 minutes. |
1020
|
Thu Oct 2 16:44:28 2008 |
steve | Summary | oplevs | optical levers |
The idea is to push the UGF to 10 Hz of the TM oplev servos with quiet HeNe laser.
We measured good intensity noise of JDS 1103P in May 2007 and converted most of the TM oplevs to it.
The ITMs still have the noisy 670nm , 1 mW, diode lasers to begin with.
In order to get 1 mW power returning to the qpds I measured the power going to TMs
and returning on qpds ...so we can select the appropriate laser power for the conversion.
40m optical lever lasers:
HeNe laser JDS 1103P, 633nm, linear polarization 500:1,
ETMX: qpd 0.12 mw (4%) reflected of 3 mW,
ETMY: qpd 0.1o (3.8%) " 2.6
BS: qpd 0.02 ( 2.5%) " 0.8
PRM: qpd 0.01 (1.3%) " 0.75
SRM: qpd 0.08 (10%) " 0.8
Coherent 670 nm Diode Lasers VLM-tm, 0.95 mW, linear polarization 100:1,
ITMX: qpd 0.1 mW (11%) reflected back from TM of 0.9 mW
ITMY: qpd 0.04 (7%) " " 0.6
It seems that JDS HeNe laser 633 nm, linear polarization 500:1, 10 mW will do the job |
1245
|
Thu Jan 22 12:08:59 2009 |
pete | Update | oplevs | oplev calibration |
Following the procedure described in Royal Reinecke's 2006 SURF report, I've calibrated the ETMY yaw oplev DOF. The idea is to sweep the mirror tilt, measuring the transmitted cavity power and the oplev error signal. The cavity power can be related to the mirror tilt in radians following D. Anderson APPLIED OPTICS, Vol. 23, No. 17, 1984.
I've made a simple matlab script which spits out the final number; it calls Royal's perl script to do the sweep. I get 420 microrad/ct for ETMY yaw. In 2006 Royal got 250 microrad/ct. Could something have changed this much, or is one of us wrong? I'll double check my procedure and do the other arm cavity oplevs, and describe it in detail when I have more confidence in it.
Kakeru and I plan to extend this to handle the PRM, SRM, and BS. One script to rule them all. |
1247
|
Thu Jan 22 23:36:50 2009 |
pete | HowTo | oplevs | arm cavity oplev calibration |
calibrated the y-arm oplevs. the procedure is contained in a matlab script. the whereabouts of this script will be revealed in a future log entry.
ITMYpit 140 microrad/ct
ITMYyaw 98 microrad/ct
ETMYpit 400 microrad/ct
ETMYyaw 440 microrad/ct (previous measurement gave 420 microrad/ct)
procedure:
1) Start with a single arm aligned and locked. Dither the mirror tilt in a DOF. Measure arm cavity power and oplev error signal. See the first attached plot.
2) Fit the plot to a gaussian and determine mu and sigma.
3) For a spherical ETM optic, the power in the cavity P(a), as a function of translational beam axis displacement a=R*sin(theta), is proportional to exp[-a^2/(2*x^2)] where x is the waist size (D. Anderson APPLIED OPTICS, Vol. 23, No. 17, 1984). The power as a function of mirror tilt in cts, P(tilt) is proportional to exp[-(tilt-mu)^2 /(2*sigma^2)]. So if R is the mirror radius then theta = arcsin(a/R) = arcsin[(1/R)*(tilt-mu)*x/sigma)].
4) Fit theta versus mirror tilt to get the calibration. See the second attached plot.
5) For a flat ITM optic, mirror tilt causes an angular displacement of the beam. The math for this case is given in Anderson. |
1249
|
Fri Jan 23 12:48:12 2009 |
Kakeru | Update | oplevs | arm cavity oplev calibration |
I calibrated optlevs of x and y arm cavity, indipendently from Peter's work.
ITMX pit: 77 microrad/ct
ITMX yaw: 73 microrad/ct
ETMX pit: 280 microrad/ct
ETMX yaw: 263 microrad/ct
ITMY pit: 120 microrad/ct
ITMY yaw: 93 microrad/ct
ETMY pit: 280 microrad/ct
ETMY yaw: 270 microrad/ct
This result is similar to Royal's one (within 30% difference except for ETMX pit), but different from Peter's in ETMY.
The attached figure is the data and fitted curve of ITMX pit.
I took this data for 8s, with 4 Hz excitation. |
1251
|
Fri Jan 23 16:33:27 2009 |
pete | Update | oplevs | x-arm oplev calibrations |
ITMXpit 71 microrad/ct
ITMXyaw 77 microrad/ct
ETMXpit 430 microrad/ct
ETMXyaw 430 microrad/ct
As with y-arm, my ITM measurements agree with Kakeru and Royal, but my ETM measurements are not quite a factor of 2 higher. Kakeru and I are investigatin. |
1259
|
Thu Jan 29 17:24:41 2009 |
Kakeru | Update | oplevs | arm cavity oplev calibration |
I calibrated optlevs again. My previous work has a lot of mistakes, so ignore it.
ITMX pit: 195 microrad/ct
ITMX yaw: 185 microrad/ct
ETMX pit: 303 microrad/ct
ETMX yaw: 296 microrad/ct
ITMY pit: 192 microrad/ct
ITMY yaw: 141 microrad/ct
ETMY pit: 294 microrad/ct
ETMY yaw: 301 microrad/ct
(For ITMY, the data is low quality)
My calcuration and Peter's(based on Royal's report) is different in two point.
i) Royal uses some geometrical factor to calibrate ITM.
ii) Royal fits data to exp(-a^2/(2*w0^2)), and I fit data to exp(-a^2/w0^2).
When I calculate with modification of these differences, my result became almost same value of Peter's one.
Now we are discussing which equation is correct.
But we must do some laser works before it... |
1377
|
Mon Mar 9 17:11:38 2009 |
Alberto | Configuration | oplevs | optical levers centering |
Yoichi, Alberto
this afternoon we centered the optical levers for all the optics.
To do that we first ran the alignment scripts for all the cavities. |
1403
|
Sat Mar 14 22:53:12 2009 |
Kakeru | Update | oplevs | arm cavity oplev calibration |
I finished a calibration of optical levers.
To calibrate oplevs, I locked appropriate cavity and tilted a mirror.
A cavity with tilted mirror decrease its arm power. So I can know how much the tilt is.
For calibration of ITMX and ETMX, I locked X arm and measured TRX.
For ETMX, ETMY and BS, I locked Y arm and measured TRY
For PRM, I locked PRC and measured SPOB
For SRM, I locked SRC and measured REFL166
I used, for example, C1:SUS-ITMX_OPLEV_PERROR as an oplev signal.
The calibration factors for each mirror is below. The attachment is figures of my fitting.
I used modified equation for ITM calibration from my last calibration, so the value become small around 30%.
ITMX Pitch: 142 microrad/counts
ITMX Yaw: 145 microrad/counts
ITMY Pitch: 257 microrad/counts
ITMY Yaw: 206 microrad/counts
ETMX Pitch: 318 microrad/counts
ETMX Yaw: 291 microrad/counts
ETMY Pitch: 309 microrad/counts
ETMY Yaw: 299 microrad/counts
BS Pitch: 70.9 microrad/counts
BS Yaw: 96.3 microrad/counts
PRM Pitch: 78.5 microrad/counts
PRM Yaw: 79.9 microrad/counts
SRM Pitch: 191 microrad/counts
SRM Yaw: 146 microrad/counts
It looks strange that ITMY, BS and SRM has different value. I think this is a fitting problem.
These data have some asymmetry and cause these 20%-30% difference.
Actually, PRM Yaw has a little asymmetry but the value doesn't differ from Pitch.
This means that this calibration factor potentially has below 30% error.
(These data are the most fine data. I think we must adjust Y arm yaw alignment. The beam spot of ETMY looks too low!)
For SRM, I couldn't get fine data because it was very sensitive to tilt and easily lose its lock.
When I tuned cavity enough, The data become almost flat, so I used detuned cavity.
It is also strange that ITMX and ITMY is different. I guess that this is caused by the difference of the QPD input. The sum of QPD is around 10000 for ITMX and around 4500 for ITMY.
The difference between BS or PRM and SRM is same, I guess. The sum of QPD input for BS and SRM is around 1500, but for SRM, it is around 10000.
I will write more detailed document and upload it with my calibration code. |
1413
|
Fri Mar 20 15:37:58 2009 |
Kakeru | Update | oplevs | arm cavity oplev calibration |
I calibrated several oplevs with OSEM signal as a confirmation of my fitting method the method is:
1) I tilted mirrors and get signals from oplevs (C1:SUS-XXXX_OPLEV_PERROR) and OSEM (C1:SUS-XXXX_SUS{PIT/YAW}_IN1).
2) I compared amplitudes of two signals and calculated conversion factors.
3) I calibrated factors above to microrad/counts with
i) The calibration factor of OSEM (2 V/mm)
ii) The calibration factor from count to V of OSEM; 1/16384 V/counts
iii) The shape of whitening filter of OSEM: 30, 100:3 (these values is taken from http://www.ldas-sw.ligo.caltech.edu/ilog/pub/ilog.cgi?group=40m&task=view&date_to_view=04/07/2005&anchor_to_scroll_to=2005:04:07:20:28:36-rana).
iv) The size of mirrors; 125mm for large optics and 75.5mm for small optics.
This calibration has some uncirtainties.
1) The calibration factor of OSEM looks very rough.
2) Output matrixes looks not to be normalized. It looks vary from 0.5 to 1.5 .
3) I don't know where OSEMs are put on mirrors accurately.
So, this calibration is very rough and may have uncertnty of a few factors, I could confirm my fitting calibration in orders.
From this calibration, I got calibration factors listed below.
ITMY Pit: 76 microrad/counts (257 microrad/counts with fitting method)
ITMY Yaw: 58 microrad/counts (206 microrad/counts)
BS Pit : 27 microrad/counts (70.9 microrad/counts)
PRM Yaw : 22 microrad/counts (79.9 microrad/counts)
For the other mirrors, OSEM outputs matrixes are not optimized and I couldn't get fine signals (I think this is not good!).
Each value is smaller than the value calibrated with fitting method in factor 3-4. There looks to be some systematic error, so there must be some difference in parameters used in OSEM calibration. |
1434
|
Thu Mar 26 09:08:18 2009 |
Kakeru | Update | oplevs | arm cavity oplev calibration |
I uploaded a document about my oplev calibration.
/cvs/cds/caltech/users/kakeru/oplev_calibration/oplev.pdf
At same place I put my matlab codes for calibration.
/cvs/cds/caltech/users/kakeru/oplev_calibration/oplev_calibration.m |
1563
|
Fri May 8 04:46:01 2009 |
rana, yoichi | Summary | oplevs | BS/PRM/SRM table bad! |
We went to center the oplevs because they were far off and found that (as usual) the numbers changed
a little after we carefully centered the oplevs and came back to the control room.
To see if the table was on something soft, we tried pushing the table: no significant effect with ~10 pounds of static force.
With ~10 pounds of vertical force, however, we saw a large change: ~0.25 Oplev units. This corresponds to
~20-30 microradians of apparent optic pitch.
In the time series below you can see the effects:
2.5 s: lid replaced on table after centering.
2.5 - 11 s: various force tests on table
11 s: pre-bias by aligning beams to +0.25 in pitch and then add lid.
So there's some kind of gooey behavior in the table. It takes ~1 s to
settle after we put the lid on. Putting the laptops on the table also
has a similar effect. Please do not put anything on this table lid. |
1578
|
Tue May 12 17:26:56 2009 |
pete | Update | oplevs | etmy oplev quad was bad |
Pete, Rob
After looking at some oplev noise spectra in DTT, we discovered that the ETMY quad (serial number 115) was noisy. Particularly, in the XX_OUT and XX_IN1 channels, quadrants 2 (by a bit more than an order of magnitude over the ETMX ref) and 4 (by a bit less than an order of mag). We went out and looked at the signals coming out of the oplev interface board; again, channels 2 and 4 were noise compared to 1 and 3 by about these same amounts. I popped in the ETMX quad and everything looked fine. I put the ETMX quad back at ETMX, and popped in Steve's scatterometer quad (serial number 121 or possibly 151, it's not terribly legible), and it looks fine. We zeroed via the offsets in the control room, and I went out and centered both the ETMX and ETMY quads.
Attached is a plot. The reference curves are with the faulty quad (115). The others are with the 121.
|
1580
|
Wed May 13 03:05:13 2009 |
pete | Update | oplevs | etmy oplev quad was bad |
Quote: |
Pete, Rob
After looking at some oplev noise spectra in DTT, we discovered that the ETMY quad (serial number 115) was noisy. Particularly, in the XX_OUT and XX_IN1 channels, quadrants 2 (by a bit more than an order of magnitude over the ETMX ref) and 4 (by a bit less than an order of mag). We went out and looked at the signals coming out of the oplev interface board; again, channels 2 and 4 were noise compared to 1 and 3 by about these same amounts. I popped in the ETMX quad and everything looked fine. I put the ETMX quad back at ETMX, and popped in Steve's scatterometer quad (serial number 121 or possibly 151, it's not terribly legible), and it looks fine. We zeroed via the offsets in the control room, and I went out and centered both the ETMX and ETMY quads.
Attached is a plot. The reference curves are with the faulty quad (115). The others are with the 121.
|
I adjusted the ETMY quad gains up by a factor of 10 so that the SUM is similar to what it was before. |
1644
|
Tue Jun 2 23:55:45 2009 |
Alberto | Update | oplevs | oplevs centerd |
Tonight I centered the oplevs for ITMX/Y, SRM, PRM, BS.
After doing that I noticed that the BS drifted a little from where I had set it. |
1662
|
Tue Jun 9 11:29:07 2009 |
Jenne | Update | oplevs | Measured ETMY oplev beam size...put everything back |
I measured the ETMY oplev beam size at a couple different distances away from the HeNe by taking out the steering mirror and letting the light propagate a ways. I put the steering mirror back, aligned the oplev, and was able to relock the Yarm, so I think it's all back as it has been the last couple of weeks.
Now I need t o do some geometry and ray-tracing matrices to decide what focal length lens to buy, then we'll have a shiny new ETMY oplev. |
1786
|
Fri Jul 24 17:20:48 2009 |
Jenne | Update | oplevs | ETMY oplev is iffy |
ETMY oplev is currently a work in progress. The HeNe beam is hitting the photodiode, but the spot size there is pretty much the size of the entire QPD. Thus, the ETMY oplev isn't really useful right now. I'm re-figuring things out (note to self: close to the laser, you have to use Gaussian optics...regular ray tracing doesn't really work), and hopefully will have the oplev back under control by the time Alberto is finished realigning the IFO, so this doesn't keep anyone from doing any exciting locking work. |
1798
|
Mon Jul 27 17:48:44 2009 |
Jenne | Update | oplevs | ETMY oplev is still down for the count |
ETMY oplev is still out of order. Hopefully I'll get it under control by tomorrow. |
2352
|
Fri Dec 4 21:48:01 2009 |
Jenne | Update | oplevs | Oplevs centered, IP_POS and IP_ANG centered |
[Jenne Koji]
We aligned the full IFO, and centered all of the oplevs and the IP_POS and IP_ANG QPDs. During alignment of the oplevs, the oplev servos were disabled.
Koji updated all of the screenshots of 10 suspension screens. I took a screenshot (attached) of the oplev screen and the QPD screen, since they don't have snapshot buttons.
We ran into some trouble while aligning the IFO. We tried running the regular alignment scripts from the IFO_CONFIGURE screen, but the scripts kept failing, and reporting "Data Receiving Error". We ended up aligning everything by hand, and then did some investigating of the c1lsc problem. With our hand alignment we got TRX to a little above 1, and TRY to almost .9 . SPOB got to ~1200 in PRM mode, and REFL166Q got high while in DRM (I don't remember the number). We also saw a momentary lock of the full initerferometer: On the camera view we saw that Yarm locked by itself momentarily, and at that same time TRX was above 0.5 - so both arms were locked simultaneously. We accepted this alignment as "good", and aligned all of the oplevs and QPDs.
It seems that C1LSC's front end code runs fine, and that it sees the RFM network, and the RFM sees it, but when we start running the front end code, the ethernet connection goes away. That is, we can ping or ssh c1lsc, but once the front end code starts, those functions no longer work. During these investigations, We once pushed the physical reset button on c1lsc, and once keyed the whole crate. We also did a couple rounds of hitting the reset button on the DAQ_RFMnetwork screen. |
2353
|
Fri Dec 4 23:17:55 2009 |
rob | Update | oplevs | Oplevs centered, IP_POS and IP_ANG centered |
Quote: |
[Jenne Koji]
We aligned the full IFO, and centered all of the oplevs and the IP_POS and IP_ANG QPDs. During alignment of the oplevs, the oplev servos were disabled.
Koji updated all of the screenshots of 10 suspension screens. I took a screenshot (attached) of the oplev screen and the QPD screen, since they don't have snapshot buttons.
We ran into some trouble while aligning the IFO. We tried running the regular alignment scripts from the IFO_CONFIGURE screen, but the scripts kept failing, and reporting "Data Receiving Error". We ended up aligning everything by hand, and then did some investigating of the c1lsc problem. With our hand alignment we got TRX to a little above 1, and TRY to almost .9 . SPOB got to ~1200 in PRM mode, and REFL166Q got high while in DRM (I don't remember the number). We also saw a momentary lock of the full initerferometer: On the camera view we saw that Yarm locked by itself momentarily, and at that same time TRX was above 0.5 - so both arms were locked simultaneously. We accepted this alignment as "good", and aligned all of the oplevs and QPDs.
It seems that C1LSC's front end code runs fine, and that it sees the RFM network, and the RFM sees it, but when we start running the front end code, the ethernet connection goes away. That is, we can ping or ssh c1lsc, but once the front end code starts, those functions no longer work. During these investigations, We once pushed the physical reset button on c1lsc, and once keyed the whole crate. We also did a couple rounds of hitting the reset button on the DAQ_RFMnetwork screen.
|
A "Data Receiving Error" usually indicates a problem with the framebuilder/testpoint manager, rather than the front-end in question. I'd bet there's a DTT somewhere that's gone rogue. |
2354
|
Sat Dec 5 01:40:11 2009 |
Koji | Update | oplevs | Oplevs centered, IP_POS and IP_ANG centered |
We restarted daqd and it did restored the problem
http://lhocds.ligo-wa.caltech.edu:8000/40m/Computer_Restart_Procedures#fb40m
Then restart the 'daqd' process:'telnet fb40m 8087 ', type "shutdown " at the prompt. The framebuilder will restart itself in ~20s.
It did not related to the problem, but we also cleaned the processes related to dtt, dataviewer by pkill
After that the alignment scripts started to work again. As a result, we got some misalignment of the oplevs.
I am going to come on Sunday
- Align the optics
- Align the oplevs again
- Take snapshots for the suspensions
- Align the IP_POS, IP_ANG
- Align the aux laser for the absolute length
- Align PSL table QPDs, and MCT QPD |
2358
|
Sat Dec 5 18:23:48 2009 |
Koji | Update | oplevs | Oplevs centered, IP_POS and IP_ANG centered |
NOTE: HEPA is on at its full.
[[[OK]]] Align the suspended optics (by Rob)
[[[OK]]] Align the oplevs again
[[[OK]]] Take snapshots for the suspensions/QPDs/IO QPDs/PZT strain gauges
[[[OK]]] Align the IP_POS, IP_ANG
[[[OK]]] Align the PSL table QPDs, the MC WFS QPDs, and the MCT QPD
[[[OK]]]
Align the aux laser for the absolute length
Alignment of the aux laser
o Go to only ITMX mode:
Save the alignment of the mirrors. Activate X-arm mode. Misalign ITMY and ETMX.
o Inject the aux beam:
Open the shutter of the aux NPRO. Turn the injection flipper on.
o Look at the faraday output:
There are several spots but only one was the right one. Confirm the alignment to the thorlabs PD. Connect the oscilloscope to the PD out with a 50Ohm termination.
Thanks to the Alberto's adjustment, the beat was already there at around 10MHz. After the PD adjustment, the DC was about 600mV, the beat amplitude was about 50mVpp.
o Adjust the aux beam alignment:
Adjust the alignment of the aux beam by the steering mirrors before the farady isolator. These only change the alignment of the aux beam independently from the IFO beam.
After the alignment, the beat amplitude of 100mVpp was obtained.
o Closing
Close the shutter of the NPRO. Turn off the flipper mirror. Restore the full alignment of the IFO. |
2615
|
Fri Feb 19 02:38:32 2010 |
Koji | Configuration | oplevs | Intsant green oplevs for ITMs shooting from the ends |
I set up instant green oplevs for ITMs.
A green laser pointer has been set on each end table. It illuminates the ITM center. The beam goea through the ETM substrate.
The reflected green beam returns to the ETM if the ITMs are aligned. Even though the reflected beam to the end is too big, this can
be a rough reference for each ITM.
Note: The green laser pointer at the ETMX were borrowed from Frank. We must return it to him when we finish the work. |
8285
|
Wed Mar 13 11:34:24 2013 |
Steve | Update | optical tables | table covers moved to CES |
The two acrylic optical table enclosures were moved from the carpenter shop to CES. I need to order windows. The latest quotes from Laseroptik are posted at the wiki / aux_optics page.
Things to do: order windows, draw and order window flange, install surgical tubing seals, buy and line enclosures with IR shield films. |
8342
|
Mon Mar 25 18:58:09 2013 |
Albert Yang | Update | optical tables | Optical Table Toolboxes |
For those of you who spend annoying amounts of time looking for tools, fear no more. Toolboxes for each optical table are coming!
They will probably have:
IR Viewer (a few optical tables will have IR viewers, these specific tables will be labeled in the diagram coming out later)
IR Card
Ball screw drivers (3/16 in.) 6-8 in. handle
SMA Wrench
Allen Keys
Flashlight
Various Connectors (I'll find out what's needed at some point)
Zip Ties
Small flat screwdrivers (for adjusting camera gains)
Please suggest what else may be needed in these boxes.
The boxes will be held to the side of the tables, either by magnets or screws. A diagram of where they will be placed on each optical table in order to minimize obstruction of walkways will be distributed soon. Any objections can then be noted. |
8382
|
Mon Apr 1 16:16:16 2013 |
Albert | Update | optical tables | Optical Table Toolboxes Update |
A heavy duty plastic box is the likeliest candidate for the optical table toolbox. It measures 5 9/16 in. x 11 5/8 in. x 4 5/8 in. and fits all the tools comfortably. ( http://www.mcmaster.com/#plastic-bin-boxes/=m4yh4m , under Heavy Duty Plastic Bin Boxes)
The list of tools has been updated to include a pen and a wire cutter as well as everything previously stated.
In addition, Steve has recommended that boxes should be secured to the walls or surfaces near the optical tables as opposed to the optical tables themselves, as to keep the tables from wobbling when tools are being exchanged.
A diagram of tentative box placements will go out soon. |
8384
|
Mon Apr 1 16:35:42 2013 |
Albert | Update | optical tables | Optical Table Toolboxes Update |
Quote: |
A heavy duty plastic box is the likeliest candidate for the optical table toolbox. It measures 5 9/16 in. x 11 5/8 in. x 4 5/8 in. and fits all the tools comfortably. ( http://www.mcmaster.com/#plastic-bin-boxes/=m4yh4m , under Heavy Duty Plastic Bin Boxes)
The list of tools has been updated to include a pen and a wire cutter as well as everything previously stated.
In addition, Steve has recommended that boxes should be secured to the walls or surfaces near the optical tables as opposed to the optical tables themselves, as to keep the tables from wobbling when tools are being exchanged.
A diagram of tentative box placements will go out soon.
|
I also took every allen key I can find so they can be sorted. They will be back in the appropriate drawer locations soon. |
8395
|
Tue Apr 2 21:11:42 2013 |
Rana | Update | optical tables | Optical Table Toolboxes Update |
Quote: |
A heavy duty plastic box is the likeliest candidate for the optical table toolbox. It measures 5 9/16 in. x 11 5/8 in. x 4 5/8 in. and fits all the tools comfortably. ( http://www.mcmaster.com/#plastic-bin-boxes/=m4yh4m , under Heavy Duty Plastic Bin Boxes)
The list of tools has been updated to include a pen and a wire cutter as well as everything previously stated.
In addition, Steve has recommended that boxes should be secured to the walls or surfaces near the optical tables as opposed to the optical tables themselves, as to keep the tables from wobbling when tools are being exchanged.
A diagram of tentative box placements will go out soon.
|
No, the small boxes must be attached to the optical tables. They won't be heavy enough to change the table tilt.
Also, all tools must be color coded according to the optical table using the 3M Vinyl table color code:
http://www.3m.com/product/images/Vinyl-Electrical-Color-Tape-300.jpg |
8408
|
Wed Apr 3 19:01:06 2013 |
Albert | Update | optical tables | Optical Table Toolboxes Update |
Quote: |
Quote: |
A heavy duty plastic box is the likeliest candidate for the optical table toolbox. It measures 5 9/16 in. x 11 5/8 in. x 4 5/8 in. and fits all the tools comfortably. ( http://www.mcmaster.com/#plastic-bin-boxes/=m4yh4m , under Heavy Duty Plastic Bin Boxes)
The list of tools has been updated to include a pen and a wire cutter as well as everything previously stated.
In addition, Steve has recommended that boxes should be secured to the walls or surfaces near the optical tables as opposed to the optical tables themselves, as to keep the tables from wobbling when tools are being exchanged.
A diagram of tentative box placements will go out soon.
|
No, the small boxes must be attached to the optical tables. They won't be heavy enough to change the table tilt.
Also, all tools must be color coded according to the optical table using the 3M Vinyl table color code:
http://www.3m.com/product/images/Vinyl-Electrical-Color-Tape-300.jpg
|
Ok.
So the new tentative plan on the boxes is to bolt them (magnetic strips were proposed but overruled on the grounds that they're not strong enough to withstand being knocked down by accidents).
The boxes are going to be a mix of the Thorlabs Benchtop Organizer (http://www.thorlabs.com/thorProduct.cfm?partNumber=BT17) and the original box. The box will have a region covered in mesh, so tools can be placed and held there. The box will also have a spacer at the bottom, with another mesh right above it, lined up. However, this double-mesh will only cover half of the box. The other half of the box will be compartmentalized to hold things such as screws, connectors, etc. I will talk to Steve about building the boxes.
Also, using nail-polish to coat the Allen wrenches is not going to work. Nail polish does not stick easily enough. The tentative new plan is oil paint, but this is to be reviewed.
Finally, the diagram with the placement of the boxes relative to the optical tables has been put on paper, but needs to be computerized so it's easier to read. This will be done as soon as possible. |
8410
|
Wed Apr 3 23:22:20 2013 |
rana | Update | optical tables | Optical Table Toolboxes Update |
There are some tips for how to appy nail polish on YouTube from MKNails and MissJenFABULOUS. Their tips on how to prepare the site for a strong bonding strength are probably helpful for our gold/nickel coated tools. For chrome tools we may need to abrade the surface with a stone or fine sandpaper for it to take the layer better. IF the YouTube videos don't do it for you, then I suggest contacting Tom Evans at LLO to find out what kind of nail polish he uses. |