40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 325 of 327  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  12094   Wed Apr 27 15:04:47 2016 SteveUpdateendtable upgradeCleaning ETMX vacuum dirty window

It looks very promising.

 

Attachment 1: 1cETMX-Tcmp.jpg
1cETMX-Tcmp.jpg
  12095   Thu Apr 28 00:41:08 2016 gautamUpdateendtable upgrademore progress - Transmon PD installed

The IR Transmon system is almost completely laid out, only the QPD remains to be installed. Some notes:

  1. The "problem" with excessive green power reflected from the harmonic separator has been resolved. It is just very sensitive to the angle of incidence. In the present configuration, there is ~10uW of green power reflected from either side, which shouldn't be too worrisome. But this light needs to be dumped. Given the tiny amount, I think a black glass + sticky tape solution is best suited, given the space constraints. This does not reach the Transmon PDs because there is a filter in the path that is transmissive to IR only. 
  2. I aligned the transmitted beam onto the Thorlabs PD, and reconnected the signal BNC cable (the existing cable wasn't long enough so I had to use a barrel connector and a short extension cable). I then reverted the LSC trigger for the X arm back to TRX DC and also recompiled c1ass to revert to TRX for the dither alignment. At the moment, both arms are stably locked, although the X arm transmission is saturated at ~0.7 after running the dither alignment. I'm not sure if this is just a normalization issue given the new beam path or if there is something else going on. Further investigations tomorrow.
  3. It remains to dump some of the unwanted green light from the addition of the harmonic separator...
  4. We may want to redesign some (or all) of the Transmon path - the lens currently in use seems to have been chosen arbitrarily. Moreover, it is quite stubbornly dirty, there are some markings which persist after repeated first contact cleaning...

I feel like once the above are resolved, the next step would be to PDH lock the green to the arm and see what sort of transmission we get on the PSL table. It may be the polarization or just alignment, but for some reason, the transmitted green light from the X arm is showing up at GTRY now (up to 0.5, which is the level we are used to when the Y arm has green locked!). So a rough plan of action:

  1. Install transmon QPD
  2. PDH lock green to X arm
  3. Fix the window situation - as Steve mentioned in an earlier elog, the F.C. cleaning seems to have worked well, but a little remains stuck on the window (though away from where any laser radiation is incident). This is resolved easily enough if we apply one more layer of F.C., but the bottle-neck right now is we are out of PEEK which is what we use to remove the F.C. once dried. Steve thinks a fresh stock should be here in the next couple of days...
  4. Once 3 is resolved, we can go ahead and install the Oplev.
  5. Which leaves the lst subsystem, coupling to the fiber and a power monitor for the NPRO. I have resolved to do both these using the 1% transmitted beam after the beamsplitter immediately after the NPRO rather than pick off at the harmonic separator after the doubling oven. I need to do the mode-matching calculation for coupling into the fiber and also adjust the collimating lens...
  6. Clean-up: make sure cables are tied down, strain-relieved and hooked up to whatever they are supposed to be hooked up to...
  12099   Fri Apr 29 00:55:46 2016 gautamUpdateendtable upgradegreen PDH locked to Xarm

Using the modulation frequency suggested here, I hooked up the PDH setup at the X-end and succeeded in locking the green to the X arm. I then rotated the HWP after the green Faraday to maximize TRX output, which after a cursory alignment optimization is ~0.2 (I believe we were used to seeing ~0.3 before the end laser went wonky). Obviously much optimization/characterization remains to be done. But for tonight, I am closing the PSL and EX laser shutters and applying first contact to the window once more courtesy more PEEK from Koji's lab in W Bridge. Once this is taken care of, I can install the Oplev tomorrow, and then set about optimizing various things in a systematic way.. MC autolocker has also been disabled...

Side note: for the IR Transmon QPD, we'd like a post that is ~0.75" taller given the difference in beam height from the arm cavity and on the endtable. I will put together a drawing for Steve tomorrow..

  12100   Fri Apr 29 16:05:23 2016 gautamUpdateendtable upgradeCleaning ETMX vacuum dirty window

After a second round of F.C. application, I think the window is clean enough and there are no residual F.C. pieces anywhere near the central parts of the window (indeed I think we got most of it off). So I am going to go ahead and install the Oplev. 

Quote:

It looks very promising.

 

 

Attachment 1: IMG_0755.JPG
IMG_0755.JPG
  12104   Mon May 2 19:14:18 2016 gautamUpdateendtable upgradeOptical layout almost complete

With Steve's help, I installed the Oplev earlier today. I adjusted the positions of the two lenses until I deemed the spot size on the QPD satisfactory by eye. As a quick check, I verified using the DTT template that the UGF is ~5Hz for both pitch and yaw. There is ~300uW of power incident on the QPD (out of ~2mW from the HeNe). In terms of ADC counts, this is ~13,000 counts which is about what we had prior to taking the endtable apart. There are a couple of spots from reflections off the black glass plate in the vacuum chamber, but in general, I think the overall setup is acceptable.

This completes the bulk of the optical layout. The only bits remaining are to couple the IR into the fiber and to install a power monitoring PD. Pictures to follow shortly. 

Now that the layout is complete, it remains to optimize various things. My immediate plan is to do the following:

  1. Maximize green transmission by tweaking alignment. I should also do a quick check using mirror specs to see that the measured transmitted green power compares favourably to what is expected.
  2. Check the green PDH loop transfer function at the X end - this will allow me to set the gain on the uPDH box systematically.
  3. Re-establish green beats, check noise performance.
  4. There are possibly multiple beam dumps that have to be installed. For now, I've made sure that no high power IR beams are incident on the enclosure. But there are a couple of red and green beams that have to be accounted for.

I will also need to upload the layout drawing to reflect the layout finally implemented.


Not directly related:

The ETMx oplev servo is now on. I then wanted to see if I could lock both arms to IR. I've managed to do this successfully - BUT I think there is something wrong with the X arm dither alignment servo. By manually tweaking the alignment sliders on the IFOalign MEDM screen, I can get the IR transmission up to ~0.95. But when I run the dither, it drives the transmission back down to ~0.6, where it plateaus. I will need to investigate further. 

 

GV Edit: There was some confusion while aligning the Oplev input beam as to how the wedge of the ETM is oriented. We believe the wedge is horizontal, but its orientation (i.e. thicker side on the right or left?) was still ambiguous. I've made a roughly-to-scale sketch (attachment #1) of what I think is the correct orientation - which turns out to be in the opposite sense of the schematic pinned up in the office area.. Does this make sense? Is there some schematic/drawing where the wedge orientation is explicitly indicated? My search of the elog/wiki did not yield any..

Attachment 1: ETMX_wedge.pdf
ETMX_wedge.pdf
  12105   Thu May 5 03:05:37 2016 gautamUpdateendtable upgradeALS status update

[ericQ, gautam]

Today we spent some time looking into the PDH situation at the X end. A summary of our findings.

  1. There is something that I don't understand with regards to the modulation signal being sent to the laser PZT via the sum+HPF pomona box - it used to be that with 2Vpp signal from the function generator, we got ~5mVpp signal at the PZT, which with the old specs resulted in a modulation of ~0.12rad. Now, however, I found that there was a need to place a 20dB attenuator after the splitter from the function generator in order to realize a modulation depth of ~0.25 (which is what we aim for, measured by locking to the TEM00 modes of the carrier and sidebands and comparing the ratio of powers). It could be that the PZT capacitance has changed dramatically after the repair. Nevertheless, I still cant reconcile the numbers. We measured the transfer function from the LO input of the pomona box to the output with the PZT connected, and figure there should be ~70dB of attentuation (with the 20dB additional attenuator in place). But this means 1Vpp*0.0003*70rad/V = 0.02rad which is an order of magnitude away from what the ratio of powers suggest. Maybe the measurement technique was not valid. In any case, this setup appears to work, and I'm also able to send +7dBm to the mixer which is what it wants (function generator output is 3Vpp).
  2. In addition to the above, I found that the demodulated error signal had a peak-to-peak of a few volts. But the PDH servo is designed to have tens of mV at the input. Hence, it was necessary to turn down the gain of the REFL PD to 10dB and add a 20dB attenuator between mixer output and servo input.
  3. While Johannes and I were investigating this earlier in the afternoon, we found that the waveform going to the laser PZT was weirdly distorted (still kind of sinusoidal in shape, but more rounded, I will put up a picture shortly). This may not be the biggest problem, but perhaps there is a better way to pipe the LO signal to the PZT and mixer than what is currently done.
  4. We then looked at loop transfer function and spectrum of the control signal. Plots to follow. They look okay.
  5. I measured the green power coming onto the PSL table. It is ~400uW. After optimizing alignment, the green transmission is ~0.4 according to whatever old normalization we are using.
  6. We then recovered the X green beatnote and looked at the ALS noise spectrum. Beatnote amplitude at the beat PD is ~ -27dBm. The coherence in the region of a few hundred Hz suggests that some improvements can be made to the PDH situation (the gain of the PDH servo is maxed out at the X end at the moment...). But the bottom line is this is probably good enough to get back to locking...
Attachment 1: ALS_noiseSpec_5May2016_2.pdf
ALS_noiseSpec_5May2016_2.pdf
Attachment 2: Coherence_5May2016.pdf
Coherence_5May2016.pdf
Attachment 3: image.jpeg
image.jpeg
  12108   Thu May 5 14:05:01 2016 ranaUpdateendtable upgradeALS status update

All seems very fishy. Its not good to put attenuators and filters in nilly-willy.

  1. Once the post-PD bandpass has been designed and constructed, you should be able to use whatever PD gain setting gives you the best SNR. There's no need to use more PD gain than necessary; it just reduces the PD bandwidth. What is the input referred current noise of the PD at the different gain settings?
  2. The open loop mixer output *should* be very large. It should be reduced to mV only when the loop is closed.
  3. The better way to estimate the modulation depth is to lock the arm on red as usual and then scan the EX laser and look at the green transmission. The FSR is 3.7 MHz, so the SBs should show up well in a narrow scan around the carrier.
  4. I guess its going to be tough to impedance match the splitter box to the NPRO PZT, since its impedance is all over the place at 200-300 kHz, but you could put a 50 Ohm in-line terminator in there somewhere?
  5. The Bode plot seems to indicate that we could easily get a 10 kHz UGF and then switch on a Boost. Is the remote Boost switch disabled or always ON? I am suspicious of the plot and think that the coarse trace is probably missing some sharp resonances which will sneakily bite you.
  12109   Thu May 5 21:28:44 2016 gautamUpdateendtable upgradeInnolight 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 SteveUpdateendtable upgradeOptical layout almost complete

 

 

Attachment 1: ETMX_4x3_closed.jpg
ETMX_4x3_closed.jpg
Attachment 2: sealedETMXenclosure.jpg
sealedETMXenclosure.jpg
  12526   Fri Sep 30 19:53:07 2016 gautamUpdateendtable upgradeX 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:

d =4\lambda (\frac{f}{\pi*MFD})

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 gautamUpdateendtable upgradeEX 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 robMetaphysicslorejiggling 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 ranaConfigurationloreHP 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 ranaConfigurationloreHP 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 robSummaryloreChannel 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 robSummaryloreChannel 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.

Attachment 1: MC3sidemon.png
MC3sidemon.png
  2138   Fri Oct 23 15:02:00 2009 robUpdateloremarconi 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 ranaUpdateloremarconi 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 JenneUpdatelorearmLoss 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 robUpdateloreIFO 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, steveHowToloreInternational Fax

Steve showed me how to send an international fax today:

  1. Load paper.
  2. Dial:   011 - (country code) - number
  3. Press START (either the black or color option)
  4. wait for the screaming fax noise
  5. Done

 

  3660   Wed Oct 6 14:49:54 2010 ranaSummaryloreSteve on the sea

jacques.jpg

  4960   Mon Jul 11 14:03:37 2011 steveHowTolorehow 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.

Attachment 1: P1080069.JPG
P1080069.JPG
  6694   Sun May 27 17:19:27 2012 ranaSummaryloreStrawberries

 We have placed some sweet giant strawberries in the fridge; free for eating for anyone working in the lab today or tomorrow:

20120527_145826.jpg

  8887   Mon Jul 22 03:10:41 2013 ranaSummaryloreAngel 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...

Attachment 1: asdasd.jpg
asdasd.jpg
  8888   Mon Jul 22 06:58:17 2013 LisaSummaryloreAngel 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!

Attachment 1: image.jpg
image.jpg
  9966   Fri May 16 20:55:18 2014 JamieFrogsloreun-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 SteveUpdateloresummery 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 steveSummaryoplevsoptical 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 peteUpdateoplevsoplev 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 peteHowTooplevsarm 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.
Attachment 1: ETMYpitpower.png
ETMYpitpower.png
Attachment 2: ETMYpitcal.png
ETMYpitcal.png
  1249   Fri Jan 23 12:48:12 2009 KakeruUpdateoplevsarm 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.
Attachment 1: ITMX_pitch.png
ITMX_pitch.png
  1251   Fri Jan 23 16:33:27 2009 peteUpdateoplevsx-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 KakeruUpdateoplevsarm 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 AlbertoConfigurationoplevsoptical 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 KakeruUpdateoplevsarm 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.
Attachment 1: oplev.pdf
oplev.pdf oplev.pdf oplev.pdf
  1413   Fri Mar 20 15:37:58 2009 KakeruUpdateoplevsarm 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 KakeruUpdateoplevsarm 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, yoichiSummaryoplevsBS/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.
Attachment 1: a.png
a.png
  1578   Tue May 12 17:26:56 2009 peteUpdateoplevsetmy 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.

 

Attachment 1: bad_oplev_quad.pdf
bad_oplev_quad.pdf
  1580   Wed May 13 03:05:13 2009 peteUpdateoplevsetmy 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 AlbertoUpdateoplevsoplevs 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 JenneUpdateoplevsMeasured 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 JenneUpdateoplevsETMY 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 JenneUpdateoplevsETMY 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 JenneUpdateoplevsOplevs 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.

Attachment 1: Oplev_IPang_screenshot_4Dec2009.png
Oplev_IPang_screenshot_4Dec2009.png
  2353   Fri Dec 4 23:17:55 2009 robUpdateoplevsOplevs 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 KojiUpdateoplevsOplevs 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 KojiUpdateoplevsOplevs 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.

Attachment 1: Screenshot_091205_1830.png
Screenshot_091205_1830.png
  2615   Fri Feb 19 02:38:32 2010 KojiConfigurationoplevsIntsant 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.

ELOG V3.1.3-