40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 3 of 326  Not logged in ELOG logo
ID Date Author Type Categorydown Subject
  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.

  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.

  8606   Tue May 21 17:03:45 2013 SteveUpdateendtable upgradeenclosure tops are sealed

Quote:

 

 I'm planning to remove the ETMY optical table enclosure and move it over to CES Shop 8am Thursday morning.

We'll install spring loaded lathes, hooks and quick release pins.

The bridge will be reinforced with steel plate to support release pins on posts.

There will be an other cut out for cable feedtrough as it is shown on elog #8472

Let me know if this timing does not fit your work.

 The bridge support posts were shimmed today. Surgical tubing 402R - o - rings were glued togeather with " instant krazy glue "

Atm2  Carey CH-3540 latches are compressed ~2.5 mm in the clamped position.

Atm3 is showing the captured quick release pin in the steel reinforced bridge that is supported by the post. It works great. The post screw is sealed by o-ring. The quick-pin is sealed by an epoxy attached copper cap.

Atm4 Enclosure is on it's back. Bottom o-ring can be seen. The hole reinforced bridge structure is visible.

Now I'm working on the window connection to the chamber. I'm very close leak checking this box.

In case of leaking around the top tubing seals we have two options:

a, cut down on the cover rim by 0.040"  or b, increase tubing diameter

Attachment 1: ETMYoptable.jpg
ETMYoptable.jpg
Attachment 2: surgtubclamps.jpg
surgtubclamps.jpg
Attachment 3: quickrelease.jpg
quickrelease.jpg
Attachment 4: reinforcbridge.jpg
reinforcbridge.jpg
  8628   Thu May 23 12:02:48 2013 SteveUpdateendtable upgradeETMY - oplev

 Temporary oplev in place. The spot on the qpd is still big. My two lens solution did not work.

I will finalize optical component position of the oplev after the the arm transmitted and green beam optics in place. They have priority.

 

Attachment 1: ETMYopl.jpg
ETMYopl.jpg
  8655   Thu May 30 11:10:00 2013 SteveUpdateendtable upgradeETMY - oplev

Quote:

 Temporary oplev in place. The spot on the qpd is still big. My two lens solution did not work.

I will finalize optical component position of the oplev after the the arm transmitted and green beam optics in place. They have priority.

 

 Oplev spot size on qpd ~ 1 mm 

PS: I realized it later that the returning beam is going through a lens for TRY. This is a nono.

      This beam path will be relayed again as the TRY, green beam and IP-ang get there place.

Attachment 1: ETMYoplev.jpg
ETMYoplev.jpg
  8660   Thu May 30 20:45:53 2013 AnnalisaUpdateendtable upgradeETMY - oplev

Quote:

Quote:

 Temporary oplev in place. The spot on the qpd is still big. My two lens solution did not work.

I will finalize optical component position of the oplev after the the arm transmitted and green beam optics in place. They have priority.

 

 Oplev spot size on qpd ~ 1 mm 

PS: I realized it later that the returning beam is going through a lens for TRY. This is a nono.

      This beam path will be relayed again as the TRY, green beam and IP-ang get there place.

 Oplev is disabled. I removed one of the steering mirrors because it was on the green beam  path.

  8662   Fri May 31 11:15:01 2013 AnnalisaUpdateendtable upgradeETMY - Mode Matching for green - new calculation

 Since the beam waist after the Faraday had changed since the last time I measured it (maybe alignment changed a bit), I made a new mode matching calculation for green. I attached the results.

I'm going to align the beam into the Yarm.

RXA: JPG images deleted - replace with PDF please.

  8669   Tue Jun 4 10:44:13 2013 SteveUpdateendtable upgradePI pzt holders are ready

The PI pzt holders are back from the shop. They are numbered 1, 2 & 3 and machined to match.

Tapered black delrin opener is to gauge the gap if it is too small to fit pzt. This is to prevent holder to be opened too much.

Attachment 1: PIpztholders.jpg
PIpztholders.jpg
  8685   Thu Jun 6 09:58:13 2013 SteveUpdateendtable upgradeenclosure to chamber connection

 

 Thin wall connector from McMCarr#55275K25 was tested in 150 mW, 1 mm beam size of 1064 nm  overnight. It did not show any degradation.

Super-Compressible Duct for Air

Hose is made from 0.005" thick, double-ply metalized polyester with a fabric-enclosed steel wire support. 

Atm2, Enclosure viewport adaptor is shown in place of the viewport.

Soft gaskit -   durumeter hardness 10A - McMCarr#9010K51 was added on the 10" od sufaces of conflat and viewport adaptor to insure being air tight.

The duct connector clamped with soft braided elastic " Velstrech" brand loop.

 

Attachment 1: thinwallconnector.jpg
thinwallconnector.jpg
Attachment 2: 06061301.PDF
06061301.PDF 06061301.PDF
  8746   Tue Jun 25 19:18:07 2013 gautamConfigurationendtable upgradeplan of action for PZT installation

  This entry is meant to be a sort of inventory check and a tentative plan-of-action for the installation of the PZT mounted mirrors and associated electronics on the Y-endtable. 

Hardware details:

  •  PZT mounts are cleaned and ready to be put on the end-tables.
  • The PZTs being used are PI S-330.20L Piezo Tip/Tilt Platforms. Each endtable requires two of these. The input channels have male single-lemo connectors. There are 3 channels on each tip/tilt platform, for tilt, yaw and a bias voltage.
  • The driver boards being used are D980323 Rev C. Each board is capable of driving 2 piezo tip/tilt platforms. I am not too sure of this but I think that the SMA female connector on these boards is meant to be connected with the bias voltage from our Kepco high-voltage power supplies. The outputs on these boards are fitted with SMB female connectors, while the piezo tip/tilt platforms have male single-lemo connectors. We will have to source cables with the appropriate connectors to run between the end-table and rack 1Y4 (see below). The input to these boards from the DAC will have to be made with a custom ribbon connector as per the pin out configuration given in the circuit drawing.
  • High-voltage power supply: KEPCO BHK 300-130 MG. This will supply the required 100V DC bias voltage to the piezo tip/tilts via the driver board. Since each board is capable of driving two piezos, we will only need one unit per end-table. The question is where to put these (photo attached). It doesn't look like it can be accommodated in 1Y4 (again photo attached) and the power cable the unit came with is only about 8ft long. If we put these under the end-tables, then we will need an additional long (~10m) cable to run from these to the driver boards at 1Y4 carrying 100 V. 
  •  We will need long (~10m by my rough measurement at the X and Y ends) cables to run from rack 1Y4 to the endtable to drive the piezos. These will have to be high-voltage tolerant (at least to 100V DC) and should have SMB male connectors at one end and female single-lemo connectors at the other. I have emailed 3 firms (CD International Technologies Inc., Stonewall Cables, and Fairview Microwave) detailing our requirements and asking for a quote and estimated time for delivery. We will need 6 of these, plus another cable with an SMA connector on one end and the other end open to connect the 100V DC bias voltage from the high voltage power supply to the driver boards (the power supply comes with a custom jack to which we can solder open leads). We will also possibly need ~3m long lemo-to-?(I need to check what the input connector for the data acquisition channels) cables for the monitoring channels, I am not sure if these are available, I will check with Steve tomorrow.

Other details:

  • I have attached a wiring diagram with the interconnects between various devices at various places and the type of connectors required etc. The error signal will the the transmitted green light from the cavity, and there is already a DQ channel logging this information, so nothing additional wiring is required to this end.
  • Jamie had detailed channel availability in elog 8580. I had a look at rack 1Y4, and there were free DAC channels available, but I am not sure as to which of the ones listed in the elog it corresponds to. In any case, Jamie did mention that there are sufficient channels available at the end-stations for this purposes, but all of these are fast channels. What needs to be decided is if we are going ahead and using the fast channels, or if we need to find slow DAC channels. 
  • I spoke to Koji about gluing the mirrors to the PZTs, and he says we can use superglue, and also to be sure to clean both the mirror and the tip/tilt surfaces before gluing. In any case, all the other hardware issues need to be sorted out first before thinking about gluing the mirrors.

High-Voltage Power Supply

photo_3.JPG

 

Situation at rack 1Y4

 

photo_4.JPG

 Wiring diagram

ASC_schematic.pdf

  8800   Wed Jul 3 21:19:04 2013 gautamConfigurationendtable upgradeplan of action for PZT installation

 This is an update on the situation as far as PZT installation is concerned. I measured the required cable (PZT driver board to PZT) lengths for the X and Y ends as well as the PSL table once again, with the help of a 3m long BNC cable, just to make sure we had the lengths right. The quoted cable lengths include a meter tolerance. The PZTs themselves have cable lengths of 1.5m, though I have assumed that this will be used on the tables themselves. The inventory status is as follows.

  1. Stuff ordered:
    • RG316 LEMO 00 (female) to SMB (female) cables, 10 meters - 6pcs (for the Y-end)
    • RG316 LEMO 00 (female) to SMB (female) cables, 11 meters - 6pcs (for the X-end)
    • RG316 LEMO 00 (female) to SMB (female) cables, 15 meters - 8pcs (6 for the PSL, and two spares)
    • RG316 SMA (male) to open cables, 3 meters - 3pcs (1 each for the X end, Y end and PSL table, for connecting the driver boards to the 100V DC power supply)
    • 10 pin IDC connectors for connecting the DAC interface to the PZT driver boards 
  2. Stuff we have:
    • 40 pin IDC connectors which connect to the DAC interface
    • PZT driver boards
    • PZT mounts
    • Twisted ribbon wire, which will be used to make the custom ribbon to connect the 10 pin IDC to the 40 pin IDC connector

I also did a preliminary check on the driver boards, mainly to check for continuity. Some minor modifications have been made to this board from the schematic shown here (using jumper wires soldered on the top-side of the PCB). I will have to do a more comprehensive check to make sure the board as such is functioning as we expect it to. The plan for this is to first check the board without the high-voltage power supply (using an expansion card to hook it up to a eurocrate). Once it has been verified that the board is getting powered, I will connect the high-voltage supply and a test PZT to the board to do both a check of the board as well as a preliminary calibration of the PZTs.

To this end, I need something to track the spot position as I apply varying voltage to the PZT. QPDs are an option, the alternative being some PSDs I found. The problem with the latter is that the interfaces to the PSD (there are 3) all seem to be damaged (according to the labels on two of them). I tried connecting a PSD to the third interface (OT301 Precision Position Sensing Amplifier), and hooked it up to an oscilloscope. I then shone a laser pointer on the psd, and moved it around a little to see if the signals on the oscilloscope made sense. They didn't on this first try, though this may be because the sensing amplifier is not calibrated. I will try this again. If I can get one of the PSDs to work, mount it on a test optical table and calibrate it. The plan is then to use this PSD to track the position of the reflected beam off a mirror mounted on a PZT (temporarily, using double sided tape) that is driven by feeding small-amplitude signals to the driver board via a function generator. 

 

Misc

The LEMO connector on the PZTs have the part number LEMO.FFS.00, while the male SMB connectors on the board have the part number PE4177 (Pasternack)

Plan of Action:

  • The first task will be to verify that the board is working by the methods outlined above.
  • Once the board has been verified, the next task will be to calibrate a PZT using it. I have to first identify a suitable way of tracking the beam position (QPD or PSD?)
  • I have identified a position in the eurocrate at 1Y4 to install the board, and I have made sure that for this slot, the rear of the eurocrate is not hooked up to the cross-connects. I now need to figure out the exact pin configuration at the DAC interface: the bank is marked 'DAC Channels 9-16' (image attached) but there are 40 pins in the connector, so I need to map these pins to DAC channels, so that when making the custom ribbon, I get the pin-to-pin map right.

DAC_bank.png

 

The wiring scheme has been modified a little, I am uploading an updated one here. In the earlier version, I had mistaken the monitor channels as points from which to log data, while they are really just for debugging. I have also revised the coaxial cable type used (RG316 as opposed to RG174) and the SMB connector (female rather than male).

ASC_schematic.pdf 

 

 

 

 

  8804   Mon Jul 8 13:45:19 2013 gautamConfigurationendtable upgradeDriver board verification

With the help of an expansion card,  I verified that the + 15V and + 24V from the eurocrate in the slot I've identified for the PZT driver boards are making their way to the board. The slot is at the right-most end of the eurocrate in 1Y4, and the rack door was getting in the way of directly measuring these voltages once I hooked up the driver board to the expansion card. So I just made sure that all the LEDs on the expansion card lit up (indicating that the eurocrate is supplying + 5, + 15 and + 24V), and then used a multimeter to check continuity between the expansion card and the driver board outside of the eurocrate. The circuit only uses + 15V and + 24V, and I checked for continuity at all the IC pins marked with these voltages on the schematic.

Since the whole point of this test was to see if the slot I identified was delivering the right voltages, I think this is sufficient. I will now need to fashion a cable that I can use to connect a DC power supply to the PZT driver boards so that these can be tested further.

The high voltage points (100V DC) remain to be tested.

  8823   Wed Jul 10 22:41:06 2013 gautamConfigurationendtable upgradePZT Driver Board

 I did the following with the PZT Driver Board: 

 

  •  With an expansion card attached to the driver board, I used an Agilent E3620A power supply to verify that the 15V and 24V supplies were reaching the intended ICs. It turns out that the +24 V supply was only meant to power some sort of on-board high voltage supply which provided the 100V bias for the PZTs and the MJE15030s. This device does not exist on the board I am using, jumper wires have been hooked up to an SMA connector on the front panel that directly provides 100V from the KEPCO high voltage supply to the appropriate points on the circuit.

  •  All the AD797s as well as the LT1125CS ICs on the board were receiving the required +15V.

      

The next step was to check the board with the high-voltage power supply connected.

 

  •  The output from the power supply is drawn from the rear output terminal strip of the power supply via pins TB1-2 (-OUT) and TB1-7 (+OUT). I used a length of RG58 coaxial cable from the lab and crimped a BNC connector on one end, and stripped the other to attach it to the above pins.

  •  There are several options that can be configured for the power supply. I have left it at the factory default: Local sensing (i.e. operating the power supply using the keypad on the front of it as opposed to remotely), grounding network connected (the outputs of the power supply are floating), slow mode, output isolated from ground.

  • I was unsure of whether the grounding network configuration or the 'positive output, negative terminal grounded' configuration was more appropriate. Koji confirmed that the former was to be used so as to avoid ground loops. When installed eventually, the eurocrate will provide the ground for the entire system.
  • I then verified the output of the HV power supply using a multimeter from 2V up to 150V.
  • I then connected the high voltage supply to the PZT driver board with a BNC-SMA adaptor, set, for a start, to output 30V. Ensured that the appropriate points on the circuit were supplied with 30V.

 

I then hooked up a function generator in order to simulate a control signal from the DAC. The signal was applied to pin 2 of the jumpers marked JP1 through JP4 on the schematic, one at a time. The signal applied was a 0.2 Vpp, 0.1 Hz sine wave.

 

 

 

  •  The output voltage was monitored both using a DMM at the SMB output terminals, and at the monitor channels using an oscilloscope. The outputs at both these points were as expected.
  • There are 4 potentiometers on the board, which need to be tuned such that the control output to the piezos are 50V when the input signal is zero (as this corresponds to no tilt). The gain of the amplifier stage (highlighted in the attached figure) right now is ~15, and I was using 30V in place of 100V, so an input signal of 2V would result in the output saturating. This part of the circuit will have to be tuned once again after applying the full 100V bias voltage. 
  • Koji suggested decreasing the gain of the amplifier stage by switching out resistor R43 (and corresponding resistor in the other 3 stages on the board) after checking the output range of the DAC so that possibility of unwanted saturation is minimised. I need to check this and will change the resistors after confirming the DAC output range. 
  • The potentiometers will have to be tuned after the gain has been adjusted, and with 100V from the high-voltage DC power supply. 

  

To Do:

 

  • Switch out resistors
  • Tune potentiometers with 100V from the HV supply
  • Verify that the output from the board after all the tuning lies in the range 0-100V for all possible input voltages from the DAC.
  • Once the output voltage range has been verified, the next step would be to connect a PZT to the board output, affix a mirror to the tip/tilt, and perform some sort of calibration for the PZT. 

HV_Amplifier.pdf

 

 

 

 

 

 

  8827   Thu Jul 11 09:15:10 2013 SteveUpdateendtable upgradeETMY optable grounded

ETMY optical table top was grounded to the ETMY chamber through 1 Mohms this morning. I  also strain releifed relieved a few cables that were pulling on components directly.

  8845   Mon Jul 15 11:51:18 2013 gautamConfigurationendtable upgradeDAC at 1Y4-Max Output and Power Spectrum

 Summary:

I measured the maximum output of the DAC at 1Y4 as well as its power spectrum. The results are as follows (plots below):

  • Maximum amplitude of differential output: + 10V.
  • Power spectrum has a peak at 64 kHz.

Therefore, the gain of the high-voltage amplification stage on the PZT driver boards do not need to be changed again, as the required output range of 0-100V from the DAC board was realised when the input voltage ranged from -10V to +10 V w.r.t ground. The AI board converts the differential input to a single ended output as required by the driver board.

I will now change some resistors/capacitors on the AI board such that the position of the notches can be moved from 16k and 32k to 64k and 128k.

Procedure:

 Max. amplitude measurement

My previous measurement of the maximum output amplitude of the DAC was flawed as I made the measurement using a single channel of the oscilloscope, which meant that the negative pin of the DAC channel under test was driven to ground. I redid the measurement to avoid this problem. The set up this time was as follows:

  • Positive pin of DAC connected to channel 1 of oscilloscope using break out cable and mini-grabber probe
  • Negative pin of DAC connected to channel 2 of oscilloscope
  • Grounds of channels 1 and 2 connected (I just hooked the mini-grabbers together)
  • Measurement mode on oscilloscope set to channel 1 - channel2
  • Used excitation points set up earlier to output a 3 Hz sine wave with amplitude of 32000 counts from channel 9 of the DAC. 

The trace on the oscilloscope is shown below;

max_amp.JPG

So with reference to ground, the DAC is capable of supplying voltages in the range [-10V 10V]. This next image shows all three traces: positive and negative pins of DAC w.r.t ground, and the difference between the two.

max_amp_all_channels.JPG

 Power spectrum measurement

 

I used the SR785 to make the measurement. The set up was as follows:

  • Positive pin of DAC to A-input of SR560
  • Negative pin of DAC to B-input of SR560
  • A-B output to Channel 1 input A of the SR785
  • SR785 configured to power spectrum measurement

Initially, I output no signal to the DAC, and obtained the following power spectrum. The peak at 65.554 kHz is marked.

DACOffPowerSpec.pdf

I then re-did the measurement with a 200 Hz (left) and 2000 Hz(right), 1000 counts amplitude (I had to change the Ch1 input range on the SR785 from -18dBm to -6dBm) sine wave from channel 9 of the DAC, and obtained the following. The peaks at ~64 kHz are marked.

DACOnPowerSpec.pdf    DAC2kPowerSpectrum.pdf

Now that this peak has been verified, I will work on switching out the appropriate resistors/capacitors on the AI board to move the notches from 16k and 32k to 64k and 128k. 

  8846   Mon Jul 15 13:51:17 2013 KojiConfigurationendtable upgradeDAC at 1Y4-Max Output and Power Spectrum

We need the unit of the voltage power spectrum density to be V/sqrt(Hz).
Otherwise we don't understand anything / any number from the plot.

  8848   Mon Jul 15 15:54:20 2013 gautamConfigurationendtable upgradeDAC at 1Y4- Power Spectrum -with the right units

Quote:

We need the unit of the voltage power spectrum density to be V/sqrt(Hz).
Otherwise we don't understand anything / any number from the plot.

 I redid the measurement with the appropriate units set on the SR785. Power spectral density plots for no output (top), 500Hz, 1000 counts amplitude sine wave (middle) and 2000Hz, 1000 counts amplitude (bottom) are attached, with the right unit on the Y-axis.

 

DACOffPSD.pdf

 

DAC500PSD.pdf

 

DAC2000PSD.pdf

ELOG V3.1.3-