40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 234 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectdown
  14069   Fri Jul 13 20:36:33 2018 KojiSummaryGeneralIn vac/In air heater wiring

I went to the Y-end and took more photos of the cable stand. These revealed that in-vac pin #13 is connected to the shield of the cable (P.2). This in-vac pin #13 corresponds to  in-air pin #1. So in the end, we bunch the pins in the following order.

In Air In Vac
Pin #2-7 Pin #12-7
Pin #8-13 Pin #6-1
Pin #14-19 Pin #25-20
Pin #20-25 Pin #19-14

 

Attachment 1: heater_wiring.pdf
heater_wiring.pdf heater_wiring.pdf heater_wiring.pdf
  7314   Thu Aug 30 00:08:34 2012 jamieUpdateGeneralIn vac plans for tomorrow, 8/30

Quote:

We need to check spot centering on PRM with camera tomorrow.

Suresh checked that we're not clipped by IP ANG/POS pickoff mirrors, but we haven't done any alignment of IP ANG/POS.

 I think we should NOT do any adjustment of IP ANG/POS now.  We should in fact try to recover them when doing the PRM spot centering

Quote:

Tomorrow:  Open ITMX door.  Check with Watek that we're hitting center of PRM.  Then look to see if we're hitting center of PR2.  Then, continue through the chain of optics.

The motivation for removing the ITMX door was so that the scatter measurement team could check alignment of the new viewing mirror next to ETMX.  After discussion today we decided that everything can be done at the X end.  They can inject a probe beam into the ETMX chamber, bounce it off of ITMX and align the viewing mirror with the reflection.  So we'll leave ITMX door on for now.

We should, however, inspect the situation ITMY and make sure we have good clearance in the Y arm part of the Michaelson.  Koji previously expressed suspicion that we might have clipping on the southern edge of the POY steering mirror, so we need to check that out.

Koji and I discussed the situation for getting camera face views of BS and PRM.  Koji said the original idea was to see if we could install something at the south-east view port of ITMX chamber.  Steve also suggested utilizing the "ceiling" camera mounted on the top of the IOO chamber.

Vertex tasks:

  • check spot centering in PRM
  • check that REFL is getting cleanly to the AP table
  • check IPPOS and IPANG - we should be adjusting IPPOS or IPANG at this point
  • check spot centering on BS
  • remove ITMY north door
  • check clearance of POY steering mirror
  • ...

in parallel:

  • Steve will inspect the situation for getting a camera view of BS and PRM face, either through IOO or ITMX.

End X tasks:

  • install baffle
  • install "permanent" ITMX viewing mirror, on west side of ETMX - this might require moving ETMX SUS cable bracket south
  • install temporary steering mirror for probe laser on south-east side of ETMX
  • at some point the scatter guys can also do transmission measurements of the ETMX view ports
  • ...
  7315   Thu Aug 30 08:12:39 2012 SteveUpdateGeneralIn vac plans for tomorrow, 8/30

 

 1,PRM spot can be viewed directly from the window south-east of ITMX chamber.  I can easy set up the mobile- Watek for this reason or you can just use an IR viewer.

   Remember, we have 2 SOS centering targets ready to use , that Rana was suggesting.

2, PR2 spot centering can be viewed directly through window north-west of ITMX.

3, We should put back the BS view pick-up mirror for the vertical camera on the BS chamber and adjust its upper pick-up.

4, The BS centering can be viewed with the mobile-Watek placed inside the BS chamber immediately.

  460   Tue Apr 29 21:30:49 2008 AndreyUpdatePEMIn the process of renaming channels for Weather Station

I startted renaming channels for the weather station, and I will continue this tomorrow, on Wednesday.

I have restarted 'c1pem1' several times and reconfigured "C0DCU1" on the framebuilder MEDM screen.

Framebuilder now does not work.
  12353   Fri Jul 29 03:59:55 2016 ericqUpdateSUSIn air OSEM diagonalization check

The question arose whether we can get good enough data to diagonize our OSEM sensing matrices in air. 

I just took a look at the BS spectra over the last six hours (~10PM-4AM), and the SNR looks good. The BS diagonalization itself doesn't seem so great; the POS is hugely coupled into pitch and yaw, and the angular motions are themselves coupled to each other at around 10%. 

NB: use a flat-top window when you really care about peak heights that don't fall exactly on an FFT bin. 

I would've liked to check this for the PRM and SRM too, but one of the PRM sensors continues to be dark, and I just noticed that all of the SRM OSEM signals are dark. ughhhh

Attachment 1: BS_OSEM_diag.pdf
BS_OSEM_diag.pdf
  14614   Thu May 16 22:58:25 2019 gautamUpdateASSIn air ASS test with green?

We were wondering yesterday if we can somehow test the ASS system in air. Though the arm cavity can be locked with the low power IMC transmission, I think the dither would render the POY lock unstable. But I wonder if we can use the green beam for a test. The steering PZTs installed by Yuki can serve the role of TT1/TT2 and we can dither the arm cavity mirrors while the green TEM00 mode is locked to the arm no problem. This would at least give us confidence that the actuation of ETMY/ITMY are okay (in addition to the other suspension tests). Then on the sensing side, after pumping down, the only thing we'd be foiled by is in-vacuum clipping or some major gunk on ETMY - everything else should be de-buggable even after pumping down?

I think most of the CDS infrastructure for this is already in place.

  7390   Fri Sep 14 18:18:33 2012 JenneUpdateGeneralIn Vac Pictures

Quote:

After much fussing, we got a picture of MMT1 with the beam.

Using the iris doesn't seem feasible. Since it has to be significantly separated from the optic, it is hard to judge whether it is centered, especially in yaw.

It took ~30 min to get this picture. Comments on whether this kind of picture is good enough are welcomed, since there are many more to be taken.

 I've been taking more photos.  Obviously, it gets quicker as I go along and get the hang of it.  Also, I've been taking overhead pictures with the Nikon so we can see what kind of parallax there is for each snapshot.

However, I just took MMT2, and the beam is nearly falling off the side of the optic!  It seemed fine last night when Rana and I were working on it.  The MC spots haven't moved significantly (I had measured yesterday, and again a few hours ago).  WTF?

This means that I need to move the knobs of MMT1, and then redo the whole alignment chain all over again.  Lame.

 

EDIT:  MC spot positions, last night at 12:33am, and this afternoon at 2:12pm:

                        year month day hour minute       MC1pit         MC2pit          MC3pit            MC1yaw         MC2yaw          MC3yaw

./data_spotMeasurements/MCdecenter201209140033.dat      1.749759        9.744013        1.025681        -0.791683       -1.338786       -1.779958      
./data_spotMeasurements/MCdecenter201209141412.dat      1.702974        7.916438        0.986519        -0.888736       -0.170237       -1.771267

 

Attachment 1: mmt2.jpg
mmt2.jpg
  7391   Fri Sep 14 18:28:25 2012 JenneUpdateGeneralIn Vac Pictures

All the photos so far:

PZT1:

pzt1_light.jpg

MMT1:

mmt1.jpg

MMT2:

mmt2.jpg

PZT2:

pzt2.jpg

IPPO:

ippo.jpg

  289   Thu Jan 31 16:53:41 2008 josephbConfigurationCamerasImproving camera user interface
There's a new and improved version of Snap program at the moment people are free to play with.

Located in /cvs/cds/caltech/target/Prosilica/40mCode/

The program Snap now has a -h or --help option which describes some basic command line arguments. The height (in pixels), width (in pixels), exposure time (in micro seconds), file name to be saved to (in .tiff format), and packet size can all be set. The format type (i.e. pixel format such as Mono8 or Mono16) doesn't work at the moment.

At the moment, it only runs on mafalda.

Currently in the process of adding a loop option which will take images every X seconds, saving them to a given file name and then appending the time of capture to the file name.

After that need to add the ability to identify and choose the camera you want (as opposed to the first one it finds).

Lastly, I've been finding on occassion that the frame fails to save. However if you try again a few seconds later with the exact same parameters, it generally does save the second time. Not sure whats causing this, whether on the camera or network side of things.

I've attached two images, the first at default exposure time (15,000 microseconds) and the second at 1/5th that time (3,000 microseconds).
The command line used was "./Snap -E 3000 -F 'Camera_exp_3000.tiff' "
Attachment 1: Camera_exp_15000.tiff
Attachment 2: Camera_exp_3000.tiff
  4226   Sat Jan 29 03:13:44 2011 ranaUpdateWienerFilteringImprovement in H1 Wiener FF prediction by using weights and taps

(Jenne, Rana)

Tonight we noticed that there were significant improvements to be had in the predicted DARM Wiener filtering FF performance by using weighting filters and more taps in the FIR filter.

The plots below tell the story:

The first one shows the improvement in the residual (black & blue) by applying a weighting filter. The weight filter tilts the spectrum up at HF and applies and all real pole BP from 10-20 Hz.

The second plot shows the improvement gotten by using 3000 instead of 2000 taps for the Wiener filter. With the larger number of taps we not only get the big improvement at LF, but also some beefy reduction in the higher frequency stack modes and the LOS roll mode.

I'm not sure why we haven't run across this before; the weighting filter was arrived at today by just iterating by hand on the placement of poles and zeros until the trace looked nice.

Jenne is going to run this new filter on the S5-month that we have been using for stationarity testing.

* Some notes:

** this Wiener stuff is faster, by far, on rossa than either megatron or rosalba or my laptop. More than a factor of 3.

*** there is a bug with Macports/Matlab - if you get fftw3 with Macports, it sets itself as the right version to use. This confuses matlab in some cases.

     if you get the error about libfftw3.dylib, whe trying fft in matlab after installing macports, then you can fix it by setting the Matlab lib/ path with the fftw libraries to be ahead of /opt/local/lib in the LD_LIBRARY_PATH in your .cshrc.

Attachment 1: darmweight.png
darmweight.png
Attachment 2: darm3000.png
darm3000.png
  4231   Mon Jan 31 10:31:30 2011 josephbUpdateWienerFilteringImprovement in H1 Wiener FF prediction by using weights and taps

Rossa is a rather beefy machine. It effectively has 8 Intel i7 Cores (2.67 Ghz each) and 12 Gigs of ram.  Megatron only has 8 Gigs of ram and just 8 Opterons (1 GHz each).  Rosalba has 4 Quad Core2  (2.4 GHz) with only 4 Gigs of ram. 

MC damp dataviewer diaggui AWG c1ioo c1sus c1iscex RFM The Dolphins Sim.Plant Frame builder TDS
                       
  1590   Fri May 15 16:47:44 2009 josephbUpdateCamerasImproved camera code

At Rob's request I've added the following features to the camera code.

The camera server, which can be started on Ottavia by just typing pserv1 (for camera 1) or pserv2 (for camera 2), now has the ability to save individual jpeg snap shots, as well as taking a jpeg image every X seconds, as defined by the user.

The first text box is for the file name (i.e. ./default.jpg will save the file to the local directory and call it default.jpg).  If the camera is running (i.e. you've pressed start), prsessing "Take Snapshot to" will take an image immediately and save it.  If the camera is not running, it will take an image as soon as you do start it.

If you press "Start image capture every X seconds", it will do exactly that.  The file name is the same as for the first button, but it appends a time stamp to the end of the file.

There is also a viedo recording client now.  This is access by typing "pcam1-mov" or "pcam2-mov".  The text box is for setting the file name.  It is currently using the open source Theora encoder and Ogg format (.ogm).  Totem is capable of reading this format (and I also believe vlc).  This can be run on any of the Linux machines.

The viewing client is still accessed by "pcam1" or "pcam2".

I'll try rolling out these updates to the sites on Monday.

The configuration files for camera 1 and camera 2 can be found by typing in camera (which is aliased to cd /cvs/cds/caltech/apps/linux64/python/pcamera) and are called pcam1.ini, pcam2.ini, etc.

 

  6850   Thu Jun 21 20:07:18 2012 JamieUpdateGreen LockingImproved beatbox returns

I've reinstalled the beatbox in the 1X2 rack.  This improved version has the X and Y arm channels stuffed, but just one of the DFD channels (fine) each.

I hooked up the beat PD signals for X and Y to the RF inputs, and used the following two delay lines:

  • X: 140' light-colored cable on spool
  • Y: 30m black cable

The following channel --> c1ioo ADC --> c1gcv model connections were made:

  • X I  --> SR560 whitening --> ADC 22 -->  X fine I
  • X Q --> SR560 whitening --> ADC 23 --> X fine Q
  • Y I --> SR560 whitening --> ADC 24 --> Y fine I
  • Y Q --> SR560 whitening --> ADC 25 --> Y fine Q

The connections to the course inputs on the ALS block were grounded.  I then recompiled, reinstalled, and restarted c1gcv.  Functioning fine so far.

 

  11496   Wed Aug 12 01:32:18 2015 IgnacioUpdateIOOImproved SISO (T240-X) FF of MCL

In my previous elog:11492, I stated that in order to improve the subtraction and reduce the injection of high frequency noise we want the filter's magnitude to have a 1/f rolloff.

I implemented this scheme on the filter SISO filter previously analyzed. The results are shown below.

The filters bode plot:

The nice 1/f rollof is the main change here. Everything else remained pretty much the same.

The predicted FIR and IIR subtractions:

Everything looks right but that hump at 8 Hz. I used 8 pairs of poles/zeros to get this subtraction.

The online MCL subtraction:

This looks better than I expected. One has to keep in mind that I ran this at 1 AM. I wonder how well this filter will do during the noisier hours of the day. The RMS at high frequencies doesn't look great, there will definitely be noise being injected into the YARM signal at high frequencies.

Measuring the YARM signal:

There is still noise being injected on YARM but it is definitely much better than the previous filter. I'm thinking about doing some IIR subtraction on the arms now to see if I can get rid of the noise that is being injected that way, but before I embark on that quest I will rething my prefiltering.

The plot below shows the ratio of the unfiltered versus filtered ASDs for the FIR and IIR subtraction predictions as well as for the measured online IIR subtraction. Positive dB means better subtraction.

Attachment 1: filter.png
filter.png
Attachment 2: stsx.png
stsx.png
Attachment 3: mclonline.png
mclonline.png
Attachment 4: yarmonline.png
yarmonline.png
Attachment 5: sub.png
sub.png
  13294   Tue Sep 5 16:37:47 2017 GabrieleSummaryLSCImproved PRMI deep learning reconstruction

This is an update on the results already presented earlier (refer to elog 13274 for more introductory details). I improved significantly the results with the following tricks:

  • I retuned the demodulation phase of AS55, this time ensuring that the (alleged) MICH motion is visible mostly in Q when crossing a carrier resonance. Further fine tunings of phases will be possible once we have a measurement of the length optical matrix

  • I fine tuned the netwrok by training it again using the real data. The ides is the following. I started with the network trained on the simulated data, and froze the parameters of the input recurrent layers. I fed the real signal to the network, computed the reconstructed PRCL/MICH, and fed them to my PRMI model to compute simulated signals. I allowed some of the parameters of the models to vary (expecially demodulation phases). I then trained again the network by trying to match the model predicted signals with the real input signals. I allowed only the parameters of the fully connected layers to vary (mostly for technical reasons, I'm working on re-training also the recurrent layers)

An example of time domain reconstruction is visible below. It already looks better than the old results:

As before, to better evaluate the performance I plotted averaged values of the real signals as a function of the reconstructed MICH and PRCL positions. The results are compared with simulation below. They match quite well (left real data, right simualtion expectation)

One thing to better understand is that MICH seems to be somewhat compressed: most of the output values are between -100 and +100 nm, instead of the expected -lambda/4, lambda/4. The reason is still unclear to me. It might be a bug that I haven't been able to track down yet.

  13891   Fri May 25 13:06:33 2018 Jon RichardsonConfigurationElectronicsImproved Measurements of AUX-PSL PLL

Attached are gain-variation measurements of the final, in situ AUX-to-PSL phase-locked loop (PLL).

Attachment 1: Figure of open-loop transfer function

Attachment 2: Raw network analyzer data

The figure shows the open-loop transfer function measured at several gain settings of the LB1005 PI servo controller. The shaded regions denote the 1-sigma sample variance inferred from 10 sweeps per gain setting. This analysis supercedes previous posts as it reflects the final loop architecture, which was slightly modified (now has a 90 dB low-frequency gain limit) as a workaround to make the LB1005 remotely operable. The measurements are also extended from 100 kHz to 1 MHz to resolve the PZT resonances of the AUX laser.

Conclusions:

  • Gain variation confirms response linearity.
  • At least two PZT resonances above the UGF are not far below unity (150 kHz and 500 kHz).
  • Recommend to lower the proportional gain by 3 dB. This will place the UGF at 30 kHz with 55 degrees of phase.
Attachment 1: LB1005_OL_transfer.pdf
LB1005_OL_transfer.pdf
Attachment 2: data.tar.gz
  8476   Tue Apr 23 15:02:19 2013 Max HortonUpdateSummary PagesImporting New Code

Duncan Macleod (original author of summary pages) has an updated version that I would like to import and work on.  The code and installation instructions are found below.

I am not sure where we want to host this.  I could put it in a new folder in /users/public_html/  on megatron, for example.  Duncan appears to have just included the summary page code in the pylal repository.  Should I reimport the whole repository?  I'm not sure if this will mess up other things on megatron that use pylal.  I am working on talking to Rana and Jamie to see what is best.

http://www.lsc-group.phys.uwm.edu/cgit/lalsuite/tree/pylal/bin/pylal_summary_page
https://www.lsc-group.phys.uwm.edu/daswg/docs/howto/lal-install.html
  8496   Fri Apr 26 15:50:48 2013 Max HortonUpdateSummary PagesImporting New Code

 

I am following the instructions here:

https://www.lsc-group.phys.uwm.edu/daswg/docs/howto/lal-install.html#test

But there as an error when I run the ./00boot command near the beginning.  I have asked Duncan Macleod about this and am waiting to hear back.

For now, I am putting things into /home/controls on allegra.  My understanding is that this is not shared, so I don't have a chance of messing up anyone else's work.  I have been moving slow and being extra cautious about what I do because I don't want to accidentally nuke anything.

  8504   Mon Apr 29 15:35:31 2013 Max HortonUpdateSummary PagesImporting New Code

 

 I installed the new version of LAL on allegra.  I don't think it has interfered with the existing version, but if anyone has problems, let me know.  The old version on allegra was 6.9.1, but the new code uses 6.10.0.1.  To use it, add . /opt/lscsoft/lal/etc/lal-user-ench.sh to the end of the .bashrc file (this is the simplest way, since it will automatically pull the new version).

I am having a little trouble getting some other unmet dependencies for the summary pages such as the new lalframe, etc.  But I am working on it.

Once I get it working on allegra and know that I can get it without messing up current versions of lal, I will do this again on megatron so I can test and edit the new version of the summary pages.

  8523   Thu May 2 14:14:10 2013 Max HortonUpdateSummary PagesImporting New Code

 

 LALFrame was successfully installed.  Allegra had unmet dependencies with some of the library tools.  I tried to install LALMetaIO, but there were unmet dependencies with other LSC software.  After updating the LSC software, the problem has persisted.  I will try some more, and ask Duncan if I'm not successful.

Installing these packages is rather time consuming, it would be nice if there was a way to do it all at once.

  8536   Tue May 7 15:09:38 2013 Max HortonUpdateSummary PagesImporting New Code

 

 I am now working on megatron, installing in /home/controls/lal.  I am having some unmet dependency issues that I have asked Duncan about.

  8572   Tue May 14 16:14:47 2013 Max HortonUpdateSummary PagesImporting New Code

I have figured out all the issues, and successfully installed the new versions of the LAL software.  I am now going to get the summary pages set up using the new code.

  8604   Tue May 21 14:50:52 2013 Max HortonUpdate Importing New Code

There was an issue with running the new summary pages, because laldetchar was not included (the website I used for instructions doesn't mention that it is needed for the summary pages).  I figured out how to include it with help from Duncan.  There appear to be other needed dependencies, though.  I have emailed Duncan to ask how these are imported into the code base.  I am making a list of all the packages / dependencies that I needed that weren't included on the website, so this will be easier if/when it has to be done again.

  8678   Wed Jun 5 14:39:41 2013 Max HortonUpdate Importing New Code

Most dependencies are met.  The next issue is that matplotlib.basemap is not installed, because it is not available for our version of python.  We need to update python on megatron to fix this.

  9713   Tue Mar 11 14:49:01 2014 KojiSummaryLSCImportant notice on the XARM servo

The nominal gain of the XARM for the POX11 error signal is 0.03 (instead of previous 0.3)

This is due to my increase of the gain in FM4 by 20dB so that we can turn of FM4 without changing the UGF when it is at 150Hz.

The YARM servo was not yet touched.

  13324   Wed Sep 20 16:14:17 2017 gautamUpdateEquipment loanImpedance test kit borrowed from Downs

I borrowed the HP impedance test kit from Rich Abbott today. The purpose is to profile the impedance of the NPRO PZTs, as part of the AUX PDH servo investigations. It is presently at the X-end. I will do the test in the coming days.
 

  14758   Mon Jul 15 03:15:24 2019 KruthiUpdateLoss MeasurementImaging scatterometer

On Friday, Koji helped me find various components required for the scatterometer setup. Like he suggested, I'll first set it up on the SP table and try it out with an usual mirror. Later on, once I know it's working, I'll move the setup to the flow bench near the south arm and measure the BRDF of a spare end test mass.

  6645   Tue May 15 23:40:46 2012 Mike J.UpdateComputersImage Subtraction

I acquired 2 raw frames of MC2 using "/users/mjenson/sensoray/sdk_2253_1.2.2_linux/capture -n -s 720x480 -f 1", one while the laser was off the mode cleaner and another while it was on:

mc2_1.bmp mc2_2.bmp

I then used "/users/mjenson/sensoray/sdk_2253_1.2.2_linux/imsub/display-image.py" to generate bitmaps of the raw images, which I then subtracted using the Python Imaging Library to generate a new image:

mc2_1-mc2_2.bmp

It doesn't look all that different, but the first image didn't have that much lit up in it to begin with. I should be able to write a script that does all of this without needing to generate new files in between acquisition and subtraction.

  6646   Wed May 16 11:53:45 2012 JenneUpdateComputersImage Subtraction

Quote:

It doesn't look all that different, but the first image didn't have that much lit up in it to begin with.

 This is totally cool!  You can see that the OSEM lights are almost entirely gone in the subtracted image.

Can you switch to trying with one of the *TM*F cameras?  (ITMXF, ITMYF, ETMYF, ETMXF)  They tend to have more background, so there should be a more dramatic subtraction.  Den or Suresh should be able to lock one of the arms for you.

  653   Wed Jul 9 17:58:19 2008 JohnSummaryGeneralIlluminator alarms
This morning some time was wasted on alignment due to the illuminators.

I added the illuminators to the alarm handler. They will give a RED alarm whenever
they are turned on. You can find the alarms in 40M->Misc->Illuminators.

To do this I edited the Illuminators.db file and restarted c1aux by telneting and typing Ctl-X.
I then added the groups and channels to 40M.alhConfig.
  1208   Tue Dec 30 18:51:18 2008 rana,yoichiConfigurationElectronicsIlluminator Power Supply reset
We noticed that none of the illuminators were working.

The switches were off on all the ports. After turning them on it still didn't work.

The +24 V Sorensen power supply which powers all of the illuminators had its OVP light on.
We turned it off, ramped the voltage to zero, turned it back on, and then went back to +24 V.

We then checked the operation of the illuminators; ETMY is still MIA.

Each of the illuminators sucks ~0.6-0.7 A when the (unlabeled) rheostat knob panel is set
to the "25" setting.

It seems pretty unwise, in the EMI sense, to be sending Amps of unshielded, high current,
switching supply outputs for 40m down the arms. This creates a huge antenna for radiating
the switching noise. I hereby assign minus 5 points to whoever designed this system.

Illuminator Upgrade:
- Use LEDs of a wavelength that the OSEMs don't see. LEDs are also cool so that the
  Suspension won't drift in alignment.

- Use 2 power supplies so that the power is balanced.

- Make is +/-12 V twisted AWG 14 wire so that the EMI is contained. Should also
  be shielded cable.
  6254   Fri Feb 3 20:58:56 2012 SteveConfigurationGeneralIlluminator Picture
Attachment 1: P1080526.JPG
P1080526.JPG
  2242   Wed Nov 11 18:43:57 2009 rana, kojiHowToPhotosIlluminated Paintbrush Technique

IMG_0215.JPGIMG_0214.JPG

1/4" exposure, standard room lights                                                                              3" exposure, slowly moving LED bar light from ~60 cm distance

Note:
Because of the light behind, the focus was attracted by the far objects...
Evenso the magnet ball looks better in the right picture.

The technique is as follows:
Use longer exposure time, move the LED bar illumination through the area like painting the light everywhere.
It is supposed to provide a picture with more uniform light and the diminished shadow.

(KA)

  6219   Tue Jan 24 13:36:05 2012 ZachBureaucracyGeneralIf I'm Peter Pan...

jamie_rufio.png

JA - MIE - RO!

  8538   Tue May 7 17:13:30 2013 JenneUpdateRF SystemIdeal PRMI RF frequency

Koji asked me to look at what the ideal RF modulation frequency is, for just the PRMI case (no arms).  If we had a perfect interferometer, with the sidebands exactly antiresonant in the arms when the arms resonate with the carrier, this wouldn't be an issue.  However, due to vacuum envelope constraints, we do not have perfect antiresonance of the sidebands in the arm cavities.  Rather, the sideband frequencies (and arm lengths) were chosen such that they pick up a minimum amount of extra phase on reflection from the arms.  But, when the arms are off resonance (ex, the ETMs are misaligned), the sideband frequencies see a different amount of phase.   

We want to know what a rough guess (since we don't have a precise number for the length of the PRC since our last vent) is for the ideal RF modulation frequency in just the PRMI. 

If I take (from Manasa's kind measurements from the CAD drawing yesterday) the relevant distances to be:

L_P[meters] = 1.9045 + 2.1155 + 0.4067

L_X[meters] = 2.3070 + 0.0254*n

L_Y[meters] = 2.2372 + 0.0359*n + 0.0254*n

L_PRCL = L_P + (L_X + L_Y)/2 = 6.7616 meters.

The *n factors (n=1.44963) are due to travel through glass of the BS, and the substrate of the ITMs. 

I find the FSR of the PRC to be 22.1686 MHz. For the sidebands to be antiresonant, we want them to be 11.0843 MHz. This would correspond to a mode cleaner length of 27.0466 meters.  Our current modulation frequency of 11.066134 MHz corresponds to a MC length of 27.091 meters.  So, if we want to use this 'ideal' modulation frequency for the PRC, we need to shorten the mode cleaner by 4.4cm!  That's kind of a lot.

  8539   Tue May 7 17:30:28 2013 KojiUpdateRF SystemIdeal PRMI RF frequency

To change the MC length is not the point.

If we can improve the length sensing by the intentional shift of the modulation frequency from the MC FSR, that's worth to try, I thought.

But that is tough as the freq difference is 18kHz that is ~x4 of the line width of the MC.
Not only the 55MHz sidebands, but also the 11MHz sidebands will just be rejected.

Nevertheless: Is there any possibility that we can improve anything by shifting the modulation frequency by ~1kHz?

  8441   Thu Apr 11 03:25:29 2013 JenneHowToSUSIdea for how to properly balance SUS actuators
We have calibrated the overall actuators of each suspension independent of the optical levers. So, we know how much we are 
moving the optic in POS in real units as a result of the dither we inject for the lockin measurement. The amount the oplev beam 
appears to move if there is only POS motion is
d/cos(theta)
where theta is the oplev's angle of incidence and d is the distance the optic has moved in POS.  None of the of the steering mirrors in the 
oplev path matter. 

I propose that I will add an option in the lockin path to subtract away the apparent angle from the oplev output just before the signal 
goes into the lockin module.  Then we will be balancing the actuators based on only the actual angular motion.

The success of this technique depends on how well we know our actuator calibration and the oplev angle of incidence. This also 
assumes that the oplev beam is centered on the optic, so we don't have beam displacement from A2L of the oplev beam, which then 
makes another apparent angular motion.  I suspect that we are close enough that we won't have to worry about this effect.
  14617   Fri May 17 10:57:01 2019 gautamUpdateSUSIY chamber opened

At ~930am, I vented the IY annulus by opening VAEV. I checked the particle count, seemed within the guidelines to allow door opening so I went ahead and loosened the bolts on the ITMY chamber.

Chub and I took the heavy door off with the vertex crane at ~1015am, and put the light door on.

Diagnosis plan is mainly inspection for now: take pictures of all OSEM/magnet positionings. Once we analyze those, we can decide which OSEMs we want to adjust in the holders (if any). I shut down the ITMY and SRM watchdogs in anticipation of in-chamber work.

Not related to this work: Since the annuli aren't being pumped on, the pressure has been slowly rising over the week. The unopened annuli are still at <1 torr, and the PAN region is at ~2 mtorr.

  8777   Thu Jun 27 23:01:39 2013 gautamUpdateGeneralITMx Oplev-servo gains adjusted

 

 With rana's input, I changed the ITMx oplev servo gains given the beam path had been changed. The pitch gain was changed from 36 to 30, while the yaw gain was changed from -25 to -40. Transfer function plots attached. The UGF is ~8Hz for pitch and ~7Hz for yaw.

I had to change the envelope amplitudes in the templates for both pitch and yaw to improve the coherence. Above 3Hz, I multiplied the template presets by 10, and below 3Hz, I multiplied these by 25.

 

pitch-plot.pdf

 

yaw-plot.pdf

  8784   Fri Jun 28 13:10:28 2013 gautamUpdateGeneralITMx Oplev-servo gains adjusted

 

 As mentioned in elog 8770, I wanted to give the POX beam a little more clearance from the pick-off mirror steering the outcoming oplev beam. I tweaked the position of this mirror a little this morning, re-centred the spot, and checked the loop transfer function once again. These were really close to those I measured last night (UGF for pitch ~8Hz, for yaw ~7Hz), reported in elog 8777, so I did not have to change the loop gains for either pitch or yaw. Plots attached.

 pitch-plot_copy.pdf

 

yaw-plot_copy.pdf

  8770   Thu Jun 27 18:11:53 2013 gautamUpdateGeneralITMx Oplev-POX looks beam okay

 

 Jenne just aligned the X arm and I got a chance to check the status of the POX beam coming out of the chamber. Turned the Oplev servo off so that the red beam could be blocked, turned all the lights off, and had a look at the beam in the vicinity of the mirror steering the Oplev-out beam to the QPD with an IR view-card. The beam is right now about half a centimeter from the pitch knob of the said mirror, so its not getting clipped at the moment. But perhaps the offending mirror can be repositioned slightly, along with the Oplev QPD such that more clearance is given to the POX beam. I will work this out with Steve tomorrow morning. 

  8665   Mon Jun 3 18:49:44 2013 GautamUpdateGeneralITMx Oplev Fixed

 (Manasa)

The ITMx Oplev was misaligned. Switched the ITMx Oplev back on and fixed the alignment.

EDIT, JCD:  This is totally my fault, sorry.  I turned it off the other day when I was working on the POP layout, and forgot to turn the laser back on.  Also, I moved the fork on the lens directly in front of the laser (in order to accommodate one of the G&H mirrors), and I nudged that lens a bit, in both X and Y directions (although very minimally along the beam path).  Anyhow, bad Jenne for forgetting to elog this part of my work.

  8684   Wed Jun 5 20:45:19 2013 gautamUpdateGeneralITMx Oplev Fixed

Quote:

 (Manasa)

The ITMx Oplev was misaligned. Switched the ITMx Oplev back on and fixed the alignment.

EDIT, JCD:  This is totally my fault, sorry.  I turned it off the other day when I was working on the POP layout, and forgot to turn the laser back on.  Also, I moved the fork on the lens directly in front of the laser (in order to accommodate one of the G&H mirrors), and I nudged that lens a bit, in both X and Y directions (although very minimally along the beam path).  Anyhow, bad Jenne for forgetting to elog this part of my work.

 [Jenne, Gautam]

It turned out that the earlier fix was not really a fix, because there was some confusion as to which of the two lenses Jenne moved while working, and while Manasa and I were re-aligning the beam, we may have moved the other lens.

Subsequently, when we checked the quadrant sum, it was low (in the region of 20), even though OPLEV_PERROR and OPLEV_YERROR were reasonably low. We called up a 30 day trend of the quadrant sum and found that it was typically closer to 4000. This warranted a visit to the table once again. Before going to the table, we did a preliminary check from the control room so as to make sure that the beam on the QPD was indeed the right one by exciting ITMx in pitch (we tried offsets of 500 and -500 counts, and the spot responded as it should). ITMx oplev servo was then switched off.

At the table, we traced the beam path from the laser and found, first, that the iris (I have marked it in one of the photos attached) was practically shut. Having rectified this, we found that the beam was getting clipped on the first steering mirror after the laser (also marked in the same photo, and a second photo showing the clipping is attached). The beam isn't very well centred on the first lens after the laser, which was the one disturbed in the first place. Nevertheless, the path of the entering beam seems alright. The proposed fix, then, is as follows;

  1. Use the existing iris and a second one to mark the path of the entering beam.
  2. Make the necessary adjustments (i.e. move the lens immediately after the laser and the first steering mirror after the laser) such that the direction of the entering beam is unchanged, and the clipping and centering problems are resolved. 

Back in the control room we noticed that the quadrant sum had gone up to ~3500 after opening out the iris. The OPLEV_PERROR and OPLEV_YERROR counts however were rather high (~200 counts in pitch and ~100 counts in yaw). Jenne went back to the table and fixed the alignment such that these counts were sub-10, and the quadrant sum went up to ~3800, close to the trend value. 

At the time of writing, the beam is still not centred on the lens immediately after the laser and is still getting clipped at the first steering mirror. Oplev servo back on.

Photos

 An overview

ITMx_overview.JPG

 

The clipping

ITMx_clipping_.JPG

  8758   Wed Jun 26 19:02:38 2013 gautamUpdateGeneralITMx Oplev (not quite?) Fixed

 

Summary:

Steve and I tried to fix the Oplev situation detailed in elog 8684, today afternoon. We have come up with a fix which needs to be adjusted, possibly completely overhauled depending on whether the mirror steering the return beam to the QPD is blocking the POX beam coming out. 

Details:

  • ITMx Oplev servo was first turned off.
  • It turns out we were hitting the wrong pair of Oplev steering mirrors inside the chamber. The incident beam was hitting a mirror meant for IR light (see sketch below) and not the intended first steering mirror. We pretty much redid the entire alignment (we used a pair of irises initially to set up a reference path) so as to hit the right pair of mirrors inside the chamber. At the end of today's efforts, the beam is reasonably well centered on both the intended mirrors, and there is not as much scattered light. 

Situation in the chamber: the black line is meant to indicate what was happening, the red is indicative of the present path.

 

oplev_chamber.pdf

  • The Oplev laser was installed in 2011 (October 13,2011 to be precise), and the quality of the beam coming out of the laser was pretty bad (the cross section was badly distorted even before it hit any optics). Steve thought this laser had reached the end of its lifetime, so we replaced the laser with a new one. Output power of this new laser has yet to be measured. The power-supply for the laser was also dodgy so we switched that out as well, and installed a new power supply. New laser and power supply are working satisfactorily. The old power supply will be checked with another laser tomorrow to gauge its status.
  • The cross-section of the beam from the new Oplev laser was deemed satisfactorily circular and we centred it on the first of the two lenses in the beam-path. We are getting 2.81 mW of power from the new laser.
  • In order to hit the right pair of Oplev steering mirrors while avoiding the clipping the beam on the tip-tilt/PR2 suspension, we had to sort of widen the angle of the beam going in, and so both steering mirrors, as well as the second lens in the beampath were shifted around. I have attached before and after pictures of the layout on the table. We adjusted things till the beam is reasonably well centred on both steering mirrors inside the chamber.
  • Because of the changed beam-path, the return Oplev beampath also changed, and so we had to move the steering mirror directing the return beam to the QPD as well. In its new position, it may be clipping the POX beam.
  • The beam is not getting clipped anywhere on the table now. It is also well centered on the two lenses in its path.
  • We placed two irises marking the new path so that we have a reference if the alignment needs to be changed again.
  • Turned ITMx Oplev servo back on.

Other stuff:

  1. The higher--power new laser means that the QPD sum is now ~6000counts (up from ~3500). The power in the return beam is 143.5 uW, which is ~5% of the power of the input beam.
  2. We centred the spot on the QPD, though when we excited ITM in yaw, the spot doesn't quite move horizontally, rather, it moves somewhat diagonally
  3. I turned the lights off, blocked the beam and measured the zero-current counts for the various QPD quadrants. These were all less than 1.5, and I reset these values on the ITMx Oplev screen according to my measurements.
  4. While viewing the spot of the Oplev beam on the ITMx face, we noticed that there were two spots, one less bright than the other. Steve suspects that this is because of multiple reflections from the chamber window.
  5. The status of the POX beam has to be verified (i.e is it getting clipped by the steering mirror for the return beam?)
  6. There was a Thorlabs PD on the table which had a green power LED. Jenne had asked me to cover this LED up, which I did with bits of tape.

Plan of action:

  • The spot size at the QPD is right now about 3mm. We may want to improve this by moving the first of the two lenses in the beam-path (there is not a whole lot of room to maneuvering the second lens.
  • Jenne just aligned and locked the X-arm, and doesn't think that the POX beam is being blocked, but I will verify this sometime tomorrow.

 

BEFORE

photo_1.JPG

 

AFTER

photo_2.JPG 

 

  6233   Fri Jan 27 13:13:03 2012 JenneUpdateSUSITMs tripped

Sitting down to start cavity measurements, I found both ITMs tripped.  It must have happened a while ago (I didn't bother to check dataviewer trends) because both had rms levels of <5 counts, so they've had a while to sit and quiet down.

  2766   Mon Apr 5 09:48:57 2010 KojiUpdateSUSITMs placed on the tables in the chambers

Steve and Koji (Friday, Apr 02)

Summary

Intsallation of ITMs are going on. Two new ITMs were placed on the optical table in the vacuum chambers. ITM for the south arm was put at the right place in accordance to the CAD drawing. ITM for the east arm is still at a temporaly place.


Tower placement (10:30-11:30)

- Put the tower on the table at a temporary place such that we can easily work on the OSEMs.

ITM (South arm) (14:00-16:30)

- Put the tower on the table at a temporary place such that we can easily work on the OSEMs.

- Leveled the table approximately.

- Released the EQ stops

- Removed anchors for the OSEM cables as it was too short. The wire distribution will be changed later.

- Put the OSEMs. Adjust the insertion to the middle of the OSEM ranges.

- Clamped the EQ stops again

- Placed the tower to the right place according to the CAD drawing.

- Released the EQ stops again.

- Check the OSEM values. The LL sensor showed small value (~0.5). Needs to be adjusted.

 


ITM (South) damping adjustment

- Found the signs for the facing magnets are reversed.

- Otherwise it damps very well.

 

  14004   Fri Jun 22 08:50:33 2018 SteveUpdateSUSITMY_UL sensor

We may lost the UL magnet or LED

Attachment 1: ITMY_UL.png
ITMY_UL.png
  14009   Fri Jun 22 18:30:21 2018 gautamUpdateSUSITMY_UL sensor

I think if the magnet fell off, we would see high DC signal, and not 0 as we do now. I suspect satellite box or PD readout board/cabling. I am looking into this, tester box is connected to ITMY sat. box for now. I will restore the suspension later in the evening.

Suspension has now been restored. With combination of multimeter, octopus cable and tester box, the problem is consistent with being in the readout board in 1X5/1X6 or the cable routing the signals there from the sat. box.

  • Tester box hooked up to sat box ---> UL coil still shows 0 in CDS.
  • Tester box hooked up to sat box ---> Mon D-sub on sat box shows expected voltages on DMM. So tester box LEDs are being powered and seem to work.
  • Sat box re-connected to test mass ---> Mon D-sub on sat box shows expected voltages on DMM. So OSEM LEDs are being powered and seem to work.
  • Sat box remains connected to TM ---> Front panel LEMO monitor points on readout board shows 0 for UL channel, other channels are okay.
Quote:

We may lost the UL magnet or LED

 

  14034   Mon Jul 2 09:01:11 2018 SteveUpdateSUSITMY_UL sensor

This bad connection is coming back

Quote:

We may lost the UL magnet or LED

 

Attachment 1: ITMY_ULcripingback.png
ITMY_ULcripingback.png
  12459   Thu Sep 1 08:30:24 2016 SteveUpdateSUSITMY_UL is sick

So if the SRM satellite box is good, than the ITMY sensor UL or vacuum cabeling from sersor to sat amp is bad.

Quote:

Koji tweaked the alignment sliders till we were able to get the Y arm locked to green in a 00 mode, GTRY ~ 0.5 which is the prevent number I have in my head. The green input pointing looks slightly off in yaw, as the spot on the ITM looks a little misaligned - I will fix this tomorrow. But it is encouraging that we can lock to the green, suggests we are not crazily off in alignment.

[Ed by KA: slider values: ETMY (P, Y) = (-3.5459,  0.7050), ITMY (P, Y) =  (0.3013, -0.2127)]

While we were locked to the green, ITMY UL coil acted up quite a bit - with a large number of clearly visible excursions. Since the damping was on, this translated to somewhat violent jerking of ITMY (though the green impressively remained locked). We need to fix this. In the interest of diagnosis, I have switched in the SRM satellite box for the ITM one, for overnight observation. It would be good to narrow this down to the electronics. Since SRM is EQ-stopped, I did not plug in any satellite box for SRM. The problem is a difficult one to diagnose, as we can't be sure if the problem is with the LED current driver stage or the PD amplifier stage (or for that matter, the LED/PD themselves), and because the glitches are so intermittent. I will see if any further information can be gleaned in this regard before embarking on some extreme measure like switching out all the 1125 OpAmps or something...

Does anyone know if we have a spare satellite box handy? 

Is the spare sat amp is bad ?

Attachment 1: ITMY_SENSOR_UL.png
ITMY_SENSOR_UL.png
Attachment 2: spareSatAmp.jpg
spareSatAmp.jpg
ELOG V3.1.3-