40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 168 of 344  Not logged in ELOG logo
ID Date Author Type Categorydown Subject
  7710   Wed Nov 14 00:56:19 2012 JenneUpdateIOOWFS on, PZT2 ~set, AS camera back

WFS are back on, and working nicely.  Den and I had seen a problem (which I had seen before) that when you turn on the integrators in the WFS loops, the MC Refl value gets worse (goes up).  Koji reminded me that he had a nice elog (7452) on how to get the MC awesome.  Ayaka and I last night stopped after Step 7.  Step 8, zeroing the WFS offsets, is the secret important thing that I keep forgetting.  I ran the script /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets, then turned on the WFS loop, and the WFS are working just fine now.   

I'm back to wishing that I had control over PZT1.  I went back and forth for a while between 1Y4 and the ETMY table to get the IPANG beam centered on the QPD.  Initially, the beam was coming out of the vacuum a little high.  The digital HV power supply is pitch, and the analog HV power supply is yaw.  When I get the beam reasonably well centered on IPANG, with a beautiful, non-clipped, beam, the beam is much too high on IPPOS.  The beam barely hits the top of the first out of vac steering mirror, and then is too high on the QPD.  It looks like (based on the sum value) that the beam is on the diode, just entirely in the upper 2 quadrants.  But if I try to fix this, since IPANG has a longer lever arm, the IPANG beam doesn't come out of the vacuum.  I have compromised by getting the beam on IPANG, centered in pitch and ignoring IPPOS pitch.  For yaw, since moving PZT2 only makes one of POS or ANG good at a time, I split the difference, so the beam is not really centered in yaw on either, but it's close on both.

AS beam is back on the camera.  I forgot that, especially since the beam at REFL is pretty bright, I had moved the AS and REFL cameras out of the beam so we didn't crispy-fry the CCDs.  Therefore, the camera spots are no longer a reference of spot position. We can still eyeball the position on, say, the 2" lens, but that's not any kind of accurate.  I put the AS camera back to it's normal place, so the AS beam is going toward AS55 and AS110, and a little bit is going to the camera.  I have not yet aligned the beams actually on to the PDs.

REFL beam is dumped by a razor dump after the 2" lens.  Manasa did some work (elog 7666) to the REFL path, and I'm not 100% sure how it was before, so I leave it to her to please work on during the day tomorrow.  I think we need to put back the Y1 that used to be there, but I don't know where the optic is.  I put a yaw dither on the PRM with awggui, and saw the REFL beam moving at my 2Hz dither frequency, so this time we actually have a useful beam coming out.

  7711   Wed Nov 14 09:01:42 2012 Dumb statement catcherUpdateIOOTurn off MCL path before doing MC spot measurement

Quote:

We have discovered that the MCL loop squishes the length fluctuations that result from the MC spot measurement angular dither.  This is good, in that the MCL is doing what it ought to do.  However, we need to turn it off before doing a spot measurement.

 This is totally non-sensical statement, of course.

We might also say that the DARM loop totally squishes the GW signal and so its better not to have any feedback in the interferometer.

  7712   Wed Nov 14 13:58:18 2012 JenneUpdateIOOTurn off MCL path before doing MC spot measurement

Quote:

Quote:

We have discovered that the MCL loop squishes the length fluctuations that result from the MC spot measurement angular dither.  This is good, in that the MCL is doing what it ought to do.  However, we need to turn it off before doing a spot measurement.

 This is totally non-sensical statement, of course.

We might also say that the DARM loop totally squishes the GW signal and so its better not to have any feedback in the interferometer.

 Hmmm, indeed.  To keep MC_L on, we should be looking at the control signal rather than the error signal.  I think Den has MC_L running nicely such that it always comes on when the MC locks, so I can switch it.

  7735   Tue Nov 20 20:37:51 2012 KojiUpdateIOOMC autolocker

Last night I found that the MC autolocker has not been updated since the chamber was closed.
i.e. The low power version had been used.

I logged into op340m and modified crontab via "crontab -e" so that the normal power version is spawned.

  7737   Wed Nov 21 01:36:36 2012 KojiUpdateIOOMCL disabled / WFS clear history restored

As MCL is disturbing arm locking by injecting a lot of noise, I have modified 'mcup'  to disable MCL

As MC WFS keeps failing to start up when it is locked, the lines in 'mcwfsoff' to clear WFS filter history were restored.

  7741   Sat Nov 24 23:50:35 2012 KojiUpdateIOOMC WFS refusing to work

Today I found the IMC was misaligned significantly by WFS feedback.
Once the feedback was cleared, it locks with nice visibility.
But WFS misaligns it again as soon as the intergrators are engaged.
I checked the beam on the table, but found nothing really wrong.
The offsets of the error signals were nulled at the input filter modules of the WFS segments.
They did not fix the problem.

The instability started about 48hour ago, that means my work on the AP table did not 
made immediate trouble. But it does not mean anything.

For now, the WFS outputs are off. More work is needed to find what's wrong.

 

  7742   Mon Nov 26 10:06:51 2012 ranaSummaryIOOMC slides from 2002
Attachment 1: MCtalk.pdf
MCtalk.pdf MCtalk.pdf MCtalk.pdf MCtalk.pdf MCtalk.pdf MCtalk.pdf
  7748   Mon Nov 26 23:45:52 2012 AyakaUpdateIOOTuning MC_L

[Rana, Jamie, Ayaka]

We could not lock the arms with MC_L loop on. Therefore we measured the change in YARM error signal when the MC_L is turned on.

POYerr_MCL.jpg

(data; POYerr_MCF.xml in zip file)

Green line; POY error signal when MCL loop was on and the YARM loop gain (0.5) was so high that the saturated control signal made funny peak around 250 Hz.
Blue line; POY error signal when MCL loop was off and the YARM loop gain was low (0.2).
Pink line; POY error signal when MCL loop was on (the gain was -300) and the YARM loop gain was low (0.2).
Red line; POY error signal when MCL loop was on, another low pass filter (2nd order, cut off frequency of 55Hz) was added to MCL loop and the YARM loop gain was low (0.2).

We also changed the filter trigger in order to lock YARM. The FM7 and 8 trigger was turned off. It means that spectrum above was took with FM2,3,4,5,6,9,10 on. Whitening filters were also on.

MCL control signal makes the arm spectrum bad because the MCL control signal moves MC2 mirror additionally and adds extra frequency noise.
Ideally, error signal should be the same at higher frequencies and go down at the lower frequencies when the MCL loop is on because MCL signal should suppress the seismic noise.

Before we added the LPF, MCF/MCL loop cross over (which was taken with the template /users/Templates/MC/MCL-MCF_xover-2012-8-23.xml) is below;

MCL-MCFxover.jpg

(MCL-MCF_xover.xml in zip file)

After the LPF is added, the cross over has been changed as below;
MCL-MCFxover2.jpg

(MCL-MCF_xover2.xml in zip file)

For now, I will just turn off the MCL loop for the acoustic noise experiments.

Attachment 4: 121126.tar.gz
  7750   Tue Nov 27 00:45:20 2012 jamieUpdateIOOMC_L and laser frequency noise spectra

I grabbed the a plot of the iLIGO PSL frequency noise spectrum from the Rana manifesto:

laser_noise.pdf

Rana's contention is that this spectrum (red trace) is roughly the same as for our NPRO.

From the jenne/mevans/pepper/rana paper Active noise cancellation in a suspended interferometer I pulled a plot of the calibrated MC_L noise spectrum:

MCL_noise.pdf

The green line on this plot is a rough estimate of where the above laser frequency noise would fall on this plot.  The conversion is:

    L / f  =  10 m / 2.8e14 Hz = 3.5e-14 m/Hz

which at 10 Hz is roughly 1.5e-11 m.  This puts the crossover somewhere between 1 and 10 Hz.

  7761   Thu Nov 29 00:15:13 2012 Den, KojiUpdateIOOMC WFS work

Quote:

The instability started about 48hour ago, that means my work on the AP table did not 
made immediate trouble. But it does not mean anything.

For now, the WFS outputs are off. More work is needed to find what's wrong.

 

 The problem was caused by low reflectivity of the mirror that splits MC reflected beam into two: first goes to trash, second - to WFS. Power before the mirror was 100mW, reflected beam that goes to WFS was 0.3mW. Using dataviewer we learnt that the beam intensity was ~5 times more in the past.

This happened because the mirror position was adjusted a few days ago. Its reflection depends on the angle of incidence and amount of light to WFS was significantly reduced. We could either increase the angle of incidence or use two mirrors with high reflectivity instead of this with high transmission.

We've chosen the second variant not to confuse anyone in future with non-45 degrees angles. We are now using one mirror with reflectivity 98% to direct most power to the trash while other 2% are directed using the second mirror to WFS path. We now have 0.7 mW on WFS1 and 1.3 mW on WFS2.

Then we adjusted WFS 

  • blocked the beam and run scripts/MC/WFS/WFS_FilterBank_offsets to calculate offsets in the WFS servo
  • aligned MC and centered beams on WFS 1 and 2
  • provided excitation to MC1 at 5 Hz (400 counts) and adjusted I&Q phase rotation
  • adjusted the gain and changed it in MC autolocker (reduced from 0.25 to 0.15 as we now have more power of WFS as before)

We were able to close the loops. The phase margin is too low though, we need to improve feedback filters.

DSC_4942.JPG

Attachment 1: wfs_fb.pdf
wfs_fb.pdf wfs_fb.pdf wfs_fb.pdf wfs_fb.pdf wfs_fb.pdf wfs_fb.pdf
  7840   Mon Dec 17 18:39:02 2012 JenneUpdateIOOIPPOS centered, no IPANG beam

I centered IPPOS.  I do not find any IPANG beam on the ETMY table, even waving the IR card in the black beam tube.

I took photos of the PZT2 HV supplies with the new camera, but I can't figure out how to get the pictures off the camera.  I guess the camera is smarter than I am.

  7851   Tue Dec 18 15:51:33 2012 JenneUpdateIOOOld G&H TT mirrors' phase maps measured

I took the 2 G&H mirrors that we de-installed from PR3 and SR3 over to GariLynn to measure their phase maps. Data is in the same place as before, http://www.ligo.caltech.edu/~coreopt/40MCOC/Oct24-2012/ .  Optic "A" is SN 0864, and optic "B" is SN 0884, however I'm not sure which one came from which tip tilt.  It's hard to tell from what photos we have on picasa.

Both are astigmatic, although not lined up with the axes defined by where the arrow marks the HR side.  Both have RoCs of -600 or -700m. RMS of ~10nm.

  7857   Wed Dec 19 18:40:00 2012 JenneUpdateIOOPZT1 removed, TT1 in place

[Manasa, Jamie, Jenne]

PZT1 has been removed, and is wrapped in foil and stored in a (labeled) plastic box.

We beeped the cable between the cable holder bracket on the in-vac table, and the outside of the feedthrough.  Things are mirrored, so pins 1,14 (one edge on the feedthrough) go to pins 13,25 on the in-vac cable bracket.

Tip Tilt, serial number ### (Manasa will get the serial number and put it in the elog) was taken out of the cleanroom, for use as TT1.

We checked the epics controls from the TT screen that Jamie made a while back (accessible from the ASC tab on the sitemap) to the output of the AI board.  Things were very weird, but Jamie fixed them up in the model, then rebuilt and restarted the ASS model so that now the epics channel corresponding to, say, UL actually actuates on the UL output of the boards.

We tested the cables from the rack to the feedthrough, and discovered that they are also mirrored, to undo the mirroring between the feedthrough and the in-vac bracket.

Jamie made an adapter cable to take the pinout of the coil driver boards correctly to the pinout of the quadrupus cable, through this double-mirroring (i.e. no net mirror effect).

We set up a laser pointer on a tripod outside the door of the MC chamber (where the access connector usually is), and pointed it at the back of the TT.  Den or whomever put the cable on the TT didn't follow the diagram (or something got messed up somewhere), because when we actuate in pitch (+ on the uppers, - on the lowers), we see the TT move in yaw, and vice versa. 

We are in the process of removing the quadrupus from the TT, figuring out which connector goes where, putting it on correctly, and re-testing.

Depending on how far things get tonight, Jamie and Manasa may ask Steve to help them remove the BS door, so they can get started on replacing PZT2 with TT2.

  7858   Wed Dec 19 19:28:12 2012 ManasaUpdateIOOPZT1 removed, TT1 in place

Quote:

Tip Tilt, serial number ### (Manasa will get the serial number and put it in the elog) was taken out of the cleanroom, for use as TT1.

 

Depending on how far things get tonight, Jamie and Manasa may ask Steve to help them remove the BS door, so they can get started on replacing PZT2 with TT2.

Tip-Tilt TT1

 

I have fixed TT1 close to what it's position looks like in the CAD drawing. Only 2/3 of TT1 rests on the table...so we need to be extra careful when we will move it for alignment.

Serial Number:  SN 027

dcc number: D1001450-V2

 We are still in the process of removing the quadrupus from the TT, figuring out which connector goes where, putting it on correctly, and re-testing.

We closed the IMC chamber with light doors calling it a day!

 

  7861   Thu Dec 20 10:11:12 2012 ManasaUpdateIOOTT1 connections

[Jamie,Manasa]

We've been trying to figure out the connector for the TTs. Since, we found the cables were plugged in wrong in TT1; when triggered in pitch, the mirror moves in yaw and viceversa.

Referring to the cabling diagram, D1000234-v10, we infer that connectors go as J2 - LR, J3 - UR, J4 - LL, J5 - UL and the connections are made looking at the mirror from behind.

  7862   Thu Dec 20 10:35:27 2012 SteveUpdateIOOTT1 connections

Quote:

[Jamie,Manasa]

We've been trying to figure out the connector for the TTs. Since, we found the cables were plugged in wrong in TT1; when triggered in pitch, the mirror moves in yaw and viceversa.

Referring to the cabling diagram, D1000234-v10, we infer that connectors go as J2 - LR, J3 - UR, J4 - LL, J5 - UL and the connections are made looking at the mirror from behind.

 The view looking at the optic from the back:  

UL    UR

LL    LR

 

 

  7904   Wed Jan 16 10:57:37 2013 taraSummaryIOONoise budget for MC

I calculated thermal noise in mode cleaner (MC) mirrors and compared it with the measured MC noise. Thermal noise won't be a significant noise source for MC.

== Motivation==

 There is an idea of using MC and a refcav to measure coating thermal noise. One laser is frequency locked to MC, another laser is locked to an 8" refcav. Then the two transmitted beams are recombined so that we can readout the frequency noise. In this case, the transmitted beam from MC is a better reference (less frequency noise) than the beam from refcav. However, we need to make sure that we understand the noise sources, for example brownian noise, thermoelastic noise in both substrates and coatings, in MC more thoroughly.

==Calculation==

I used Rana's code for MC's technical noise sources from, svn. The same plot can be found in appendix C of his thesis. Then I added my calculation to the plot.  Jenne pointed me to 40m:2984 for the spot size and the cavity length. The spot radius on MC1 and MC3 is ~ 1.5mm, and ~3.4 mm@MC2, The round trip length is ~27m, thus the frequency fluctuation due to thermal noise is lower than that of refcav by 2-3 orders of magnitude. I calculated Brownian noise in coatings, Brownian noise in substrate, Thermoelastic noise in substrate. I assumed that the coatings are SiO2/Ta2O5, quarter stacks, coatings thickness for MC1/3 = 5um, for MC2 = 8um. The code can be found in the attachment.

mc_nb_TN.png

==result==

Total thermal noise on MC (Brownian + Thermoelastic on substrate and coatings of MC1-MC3) is plotted in dashed red. It is already below 10^-5 Hz/rtHz at ~20 Hz. This is sufficiently low compared to other noise sources. Beat signal from CTN measurement with 8" cavities is plotted in pink, the estimated coating brownian noise is plotted in a yellow strip. They are well above the measured MC noise between 100 Hz to a few kHz. Measuring coating thermal noise on 8" refcav seems plausible with this method. We can beat the two transmitted beams from IMC and refcav and readout the beat signal to extract the displacement noise of refcav. I'll discuss this with Koji if this is a good surf project.

 mc_nb_TN_2013_01_18.png

[the internal thermal noise in the original plotted is removed and replaced with the total thermal noise plot instead]

 note:I'm not sure about the current 40m MC configuration. The parameters used in this calculation are summarized in mcnoiseS2L1.m (in the svn page).

 

Attachment 2: mc_nb_TN.png
mc_nb_TN.png
Attachment 3: mc_nb_TN.fig
Attachment 4: MC_nb.m.zip
  7908   Wed Jan 16 19:08:51 2013 KojiSummaryIOONoise budget for MC

I missed the point.
Do you mean that we can measure the coating thermal noise of the ref cav at the 40m as the IMC is quiet enough?

  7911   Thu Jan 17 01:27:54 2013 Tara(?)SummaryIOONoise budget for MC

Quote:

I missed the point.
Do you mean that we can measure the coating thermal noise of the ref cav at the 40m as the IMC is quiet enough?

 Yes, it should be. However, what I did was calculating thermal noise of MC. I'm not sure about the 40m IMC's actual noise level. The plot in the entry was taken from LLO's MC in 2003.

  8083   Thu Feb 14 08:29:41 2013 SteveUpdateIOOlow MC1 OSEM voltage

MC1 -  LR, LL, UL & UR  OSEMs should be adjusted to get  1.2V

Attachment 1: Feb14_2013.png
Feb14_2013.png
  8107   Tue Feb 19 09:37:23 2013 SteveUpdateIOOlow MC1 OSEM voltage

 

    See TT DB25 pin swapping   elog#7869 

Attachment 1: MC1_MC3.png
MC1_MC3.png
Attachment 2: MC1_MC3_.png
MC1_MC3_.png
  8108   Tue Feb 19 12:02:00 2013 JamieUpdateIOOIMC table levelling.

In order to address the issue of low MC1 OSEM voltages, Yuta and I looked at the IMC table levelling.  Looking with the bubble level, Yuta confirmed that the table was indeed out of level in the direction that would cause MC1 to move closer to it's cage, and therefore lower it's OSEM voltages.  Looking at the trends, it looks like the table was not well levelled after TT1 installation.  We should have been more careful, and we should have looked at the MC1/3 voltages after levelling.

Yuta moved weights around on the table to recover level with the bubble level.  Unfortunately this did not bring us back to good MC1 voltages.  We speculate that the table was maybe not perfectly level to begin with.  We decided to try to recover the MC1 OSEM voltages, rather than go solely with the bubble level, since we believe that the MC suspensions should be a good reference.  Yuta then moved weights around until we got the MC1/3 voltages back into an acceptable range.  The voltages are still not perfect, but I believe that they're acceptable.

The result is that, according to the bubble level, the IMC table is low towards MC2.  We are measuring spot positions now.  If the spot positions look ok, then I think we can live with this amount of skew.  Otherwise, we'll have to physically adjust the MC1 OSEMS.

Screenshot-Untitled_Window.png

  8112   Tue Feb 19 19:55:52 2013 yutaUpdateIOOMC yaw input tuned

[Jenne, Manasa, Yuta]

Since we levelled IMC stack, we had to center beam spots on MC mirrors again.
We did this by steering PSL mirror in yaw (about same amount but opposite direction to what we did in elog #8077)
Residual beam tilt compared with a line through MC1 and 3 actuator nodes is ~ 15 mrad, mainly in yaw.
MCdecenter_19Feb2013.png

  8175   Wed Feb 27 00:08:43 2013 JenneUpdateIOOMeditations on converting TT channels to be more SUS-like

Jamie and I have had a few back-and-forths on this, but I wanted to write down my thoughts on the parts of the SUS infrastructure that we need for the active tip tilts.

I think we want the ASC pitch and yaw filter banks.  I also think we want to change the channel names so that they are C1:SUS rather than C1:IOO, to make scripting easier.  A corollary to this is that we should make the DC bias sliders have the same naming structure as the regular suspensions (C1:SUS-TT#_{PIT/YAW}_COMM).  This makes scripts like the save/restore scripts easier.  If we keep the IOO naming, it would still be convenient to add the _COMM.

I am having trouble imagining what we might want the lockins for, so I propose we leave them out.

Do we want the output matrix (PIT/YAW -> coils) to be a filter bank matrix?  If we want f2a filters, we need to change this to a filter bank matrix.

I also think we want a master on/off switch for the AC actuation (ASC stuff).  We don't have sensors, so we won't have watchdog-ing, but it might be useful to have a 'panic' switch.  Perhaps though if we are careful to set limits on the ASC filter banks, we won't ever have a panic about actuating too hard.

I'm think I'm joining Jamie's side in the medm screen debate....I think we want a separate TT_SINGLE screen, laid out similar to the SUS_SINGLE, but without all of the irrelevant parts.

EDIT:  Yuta just pointed out to me that right now, the TT DC bias sliders are not recorded anywhere (_DQ, conlog,...).  We *must* fix this.

  8265   Sun Mar 10 13:29:29 2013 KojiHowToIOOHow to calculate the accumulated round-trip Gouy phase

How to calculate the accumulated round-trip Gouy phase (and namely the transverse mode spacing) of a general cavity
only from the round-trip ABCD matrix

T1300189

  8269   Mon Mar 11 15:52:46 2013 JenneUpdateIOOMC spots centered, WFS realigned

Looking more into the MC, it appears that no spot centering was done after the power attenuation optics were removed (see elog 8142).  Since Manasa had changed the zig-zag steering after putting in the attenuation optics (elog 7843) the pointing was not correct for the nominal MC.  This is (likely) why Yuta and Manasa found some significant decentering.  If Manasa's tweaks when preparing for vent were primarily in yaw, then this is most definitely what happened.  A note, this is why we should change to inserting the attenuation optics before the PMC, but even so, one should adjust the angle of the PBS, NOT the zig zag optics, to get the input pointing back to the same place.  This is also why it is useful to ensure the attenuation optics do not block the PSL pointing QPD pickoff, so it is easier to adjust the PBS to get back to the original pointing.

In any case, I touched the last zig-zag mirror in yaw today (the top of the knob was moved away from me) to recenter the spots.

MCspots_11Mar2013.png

With the MC unlocked, I centered the WFS.  Now the MC is back to its normal working condition....WFS are on, autolocker is on, reflected DC power is low, etc., etc.

  8275   Tue Mar 12 00:45:50 2013 JenneUpdateIOOMC weird again

~20 minutes ago, maybe right around the time the fb's RAID died (elog 8274) the mode cleaner started behaving weirdly again.  The reflected value is very high, even with the WFS on.  Earlier this evening, I saw that with the WFS off, the MC reflection was high, but the WFS brought it back down to ~0.7 or 0.8.  But now it's ~1.3.  With the WFS off, the reflected value is ~1.1.  I don't really understand.

Also, the PMC has been drifting in alignment in pitch all day, but a lot more later in the day. The PMC trans is 0.800 right now, but it was as high as 0.825 today, and spent most of the day in the high 0.81xxx range today.

I would provide plots, but as mentioned in elog 8274, we can't get data right now.

  8277   Tue Mar 12 11:49:18 2013 JenneUpdateIOOMC weird again

[Manasa, Annalisa, Jenne]

The MC wasn't locking on TEM00 this morning, and the WFS kept pulling the MC out of alignment.  The MC was realigned, and the WFS spots are back to being roughly centered (all of this only touching the MC sliders), but the WFS keep doing bad things.  They're okay, and improve the alignment slightly at first, but as soon as the FM1 integrator comes on, the MC alignment immediately starts going bad, and within a second or so the MC has unlocked.

The WFS are off right now, and we'll keep investigating after LIGOX.

  8281   Wed Mar 13 02:48:13 2013 JenneUpdateIOOMC all better

Koji reminded me (again....this is probably the  2nd or 3rd time I've "discovered" this, at least) that the script

..../scripts/MC/WFS/WFS_FilterBank_offsets

exists, and that we should use it sometimes.  See his elog 7452 for details. 

 

Notes about using this script:

* Only use it after MC has been very well aligned.  MC REFL DC should be less than 0.5 when the MC is locked (with the DC value ~4.5 with the MC unlocked, as usual).  This is hard to achieve, but important.  Also, check the MC spot centering.

* With the WFS servo off, but the MC locked and light on the WFS diodes, run the script. 

  8288   Wed Mar 13 16:25:16 2013 ManasaUpdateIOOTuning MC length/FSR

[Koji, Manasa]

We looked at the MC modulation frequency on the spectrum analyzer and observed beat notes between MC modulation freq (29.5MHz) and modulation frequencies (11.06 MHz and 55.3MHz).

Beat notes were suppressed by changing the carrier frequency from 11.065910 MHz to 11.066147MHz. 

Detailed discussion and data will be posted in the next elog.

  8343   Mon Mar 25 23:17:11 2013 ranaSummaryIOOMC

I measured the dark noise and regular intensity noise in MC trans tonight to get some estimate for the free running spectrum that the Chas ISS must overcome. PDF is attached.

XML file is /users/rana/dtt/MC-trans_130325.xml

The RIN normalization was done by using the mean of the SUM time series. The dark noise was measured by misaligning MC2 and making the same measurement with the bright normalization.

Attachment 1: MC-trans.pdf
MC-trans.pdf
  8349   Tue Mar 26 01:40:49 2013 KojiUpdateIOOTuning MC length/FSR

I'm still waiting for the follow-up analysis of the modulation freq tuning.

  8353   Tue Mar 26 15:00:55 2013 ManasaUpdateIOOTuning MC length/FSR

Quote:

[Koji, Manasa]

We looked at the MC modulation frequency on the spectrum analyzer and observed beat notes between MC modulation freq (29.5MHz) and modulation frequencies (11.06 MHz and 55.3MHz).

Beat notes were suppressed by changing the carrier frequency from 11.065910 MHz to 11.066147MHz. 

Detailed discussion and data will be posted in the next elog.

The goal was to tune the carrier modulation frequency, f1 ~ 11.06 MHz to match the FSR  (c/2L) of the MC. (Reference to the technique: R.G.DeVoe et al., PRA 30, 5, Nov 1984)

We looked at the MC_REFL output on the spectrum analyzer. Since the MC FSR was not well matched with the carrier modulation frequency, we observed significant beat notes at the following frequencies (fMC-f1),  (fMC+f1), (fMC-f2) and (fMC+f2); where fMC (the MC modulation frequency) = 29.5MHz, f1(carrier modulation frequency) ~ 11.06MHz and f2 ~ 55.3MHz. The carrier modulation frequency was changed at the frequency generator until these beat notes were suppressed i.e. until the cavity FSR matched the carrier modulation frequency.

The plot below shows the MC spectrum after the beat notes were suppressed.

MC_spectrum.png

Attachment 2: MC_spectrum.zip
  8354   Tue Mar 26 15:43:45 2013 ranaUpdateIOOTuning MC length/FSR

  Please attach the data file of the measurement - its hard to get the real information out of picture. In general, WE should always include the code / explanation of how to reconstruct the plot and get the scientific information out.

  8357   Tue Mar 26 17:27:17 2013 KojiUpdateIOOTuning MC length/FSR

Please add the discussions on the cavity absolute length (and its change, adjustment precision),
identification of the peaks, before/after comparison of the plot, the effect of the MC REFL PD response,
and comparison of the cavity linewidth vs deviation of the 55MHz SBs from the resonance.

  8426   Tue Apr 9 00:32:39 2013 ranaConfigurationIOOTurn on MCL

 Listening to the free swinging Y-arm, its clear that the fringe velocity is higher with the MCL path off, than on. I checked that the default gain of -300 was too high and changed it to -100 in the mcup script. With the higher gain value, there was clear gain peaking at just under 60 Hz (where the 60 Hz comb filter starts). We basically want the UGF to be between 20 and 60 Hz so that we can have the Bounce mode RG at 16.25 Hz and also the notch filter at 60 Hz.

Den is measuring and setting the UGF to be ~45 Hz.

With the MCL path on there is a high frequency horn-like noise in the Yarm when it locks. Its reduced a little by reducing the loop gain, but clearly this is just noise introduced by the MCL loop as Den noted before (and also tonight). He is cleaning up the whole MCL MEDM situation so that its useable by us. At the moment I've re-enabled it in the mcup.

My belief is that the frequency noise from the unstabilized MC is making the PRC locking harder. This will be investigated by tuning the shape of the MCL/MCF crossover so that we can turn it on without ruining the arm cavity spectra. Since the PRC length is ~2x smaller than the MC, we would expect it to be less sensitive to the MC frequency noise. But, since there is some common mode rejection in there, this may not be true. We'll only know by measuring PRC control signal with MCL on/off.

  8434   Wed Apr 10 03:59:41 2013 DenConfigurationIOOTurn on MCL

Quote:

 My belief is that the frequency noise from the unstabilized MC is making the PRC locking harder. This will be investigated by tuning the shape of the MCL/MCF crossover so that we can turn it on without ruining the arm cavity spectra. Since the PRC length is ~2x smaller than the MC, we would expect it to be less sensitive to the MC frequency noise. But, since there is some common mode rejection in there, this may not be true. We'll only know by measuring PRC control signal with MCL on/off.

 I think if we make MCL UGF higher then 20 Hz, arm cavity spectra will feel it. It might be possible to use a combination of feedback and feedforward control from ground seismometers. I made MCL UGF at 3 Hz to reduce 1 Hz motion of the pendulum; feedforward OAF subtracted the stack at 3.3 Hz. Once OAF converged, I blocked adaptation and the filter became static FIR. MC length RMS was reduced by a factor of 10 and arm cavity spectra was not affected at frequencies >20 and became better at low frequencies. We'll see if this enough.

On the attached plot red color shows MC_F with MC_L OFF, blue - MC_L is ON, green - MC_L and OAF are ON.

Then I locked PRCL (using AS_Q and REFL55_I) to carrier and aligned the cavity. Power RIN was 50-70% and 00 beam on the POP camera was moving significantly. BS oplev was shaking the optics at 5 Hz. I fixed it, but there should be something else as RIN was still high.

Attachment 1: MCL.pdf
MCL.pdf
  8469   Mon Apr 22 11:46:09 2013 KojiSummaryIOOMC locked/aligned. MC WFS offloading by ezcaservo

Еру ьс шы тщц дщслув фтв фдшптувю

Фдыщ ш кфт еру ащддщцштп ыскшзе ещ щаадщфв еру ЬС ЦАЫ ыукмщю

I blame Den for russian keyboard installation on the control machines.

ezcaservo -r 'C1:SUS-MC2_ASCPIT_OUT16' -g '0.00001' -t 60 C1:SUS-MC2_PIT_COMM&
ezcaservo -r 'C1:SUS-MC2_ASCYAW_OUT16' -g '0.00001' -t 60 C1:SUS-MC2_YAW_COMM&
ezcaservo -r 'C1:SUS-MC1_ASCPIT_OUT16' -g '0.00001' -t 60 C1:SUS-MC1_PIT_COMM&
ezcaservo -r 'C1:SUS-MC1_ASCYAW_OUT16' -g '0.00001' -t 60 C1:SUS-MC1_YAW_COMM&
ezcaservo -r 'C1:SUS-MC3_ASCPIT_OUT16' -g '0.00001' -t 60 C1:SUS-MC3_PIT_COMM&
ezcaservo -r 'C1:SUS-MC3_ASCYAW_OUT16' -g '0.00001' -t 60 C1:SUS-MC3_YAW_COMM&

  8471   Mon Apr 22 17:06:42 2013 ranaSummaryIOOMC locked/aligned. MC WFS offloading by ezcaservo

 

 Why use the PSL beam as a reference? Don't we want to keep the MC pointing in a good direction through the Faraday instead???

  8530   Mon May 6 19:04:30 2013 JamieUpdateIOOmode cleaner not locking

About 30 minutes ago the mode cleaner fell out of lock and has since not been able to hold lock for more than a couple seconds.

I'm not sure what happened.  I was in the middle of taking measurements of the MC error point spectrum, which included adjusting the FAST gain.  I've put all the gains back to their nominal levels but no luck.  I'm not sure what else could have gone wrong.  Seismic noise looks relatively quiet. 

  8531   Mon May 6 21:05:06 2013 rana, Jamie, KOjiUpdateIOOmode cleaner not locking

As it turned out, the setting of +26dB for the FSS Fast gain was making the NPRO PZT / Pockels cell crossover too unstable. This was the cause of the large ~30 kHz peak that Jamie was seeing in his spectra (more to follow in the morning).

After recovering the locking, etc. by fiddling with the gains, we went about systematically setting all of the gains/offsets. Jamie's elog will show all of the various spectra with different FSS gains.

For offset setting, this was the procedure:

  1. We want the MC servo board to have zero voltage on its MCL and MCF outputs (aka MC_SLOW_MON and MC_FAST_MON) with the Boosts ON, so we switched ON the 40:4000 and the 2 Super Boosts and put the VCO gain into its nominal +25 dB setting. This saturates the outputs and makes them impossible to use as readbacks so you have to be careful. Get the outputs close to zero as you turn on each boost. Finally, you will see that +/- 1mV of input offset (aka MC_REFL_OFFSET) will flip the FAST output between +/- 10V. This is the right setting.
  2. With the MC board adjusted to send 0 V into the FSS error point, adjust the FSS input offset (with the Common and Fast gains at the nominal values) so that the FAST output voltage goes to +5.5 V. This is the middle of the range for the high voltage driver which drives the NPRO.
  3. Let the MC lock and go through the UP script. When the MCL comes on with the integrator, the FAST voltage will shift from +5.5 V to something else. Use the following line: ezcaservo -r C1:PSL-FSS_FAST -g -1 -s 5.5 C1:SUS-MC2_MCL_OFFSET, to automatically tune the MCL offset.

     

    That's all. I have left the FSS common gain at +10.5 and the Fast gain at +23.5. These seem to be close to the optimum. Jamie will have more tuning tomorrow.
     
    I have also changed the 'mcup' script to set the MCL offset and set the FSS Slow setpoint to shoot for +5.5 V of FSS_FAST.
     
    MC_REFL_OFFSET = +1.176 V
    MC2_MCL_OFFSET = +47.8 counts
    FSS_INOFFSET   = -0.85 V
  8534   Tue May 7 03:25:28 2013 JenneUpdateIOOMC WFS drifting??

I'm not sure why, but starting ~3.5 hours ago, the WFS seem to not be holding the MC in optimal alignment. 

The WFS are definitely engaged and the loops are closed, but every time the MC locks, the WFS pitch and yaw values start drifting off.  In particular, the WFS loop actuation pushing on MC2 is in the many hundreds of counts after ~90 minutes of drift time.  I tried offloading those values by moving the MC2 slider, but then I unlocked the MC to check what that did to the alignment, and it was decidedly bad.  So, I'm not sure what's up with the WFS, but I need to look at it tomorrow.

  8575   Tue May 14 20:30:29 2013 JamieSummaryIOOMC error spectrum at various FSS gain settings.

I used the Agilent 4395A and the GPIB network bridge to measure the MC error spectrum at the MC servo board.

I looked at various settings of the FSS Common and FAST gains.

Here is the spectrum of various Common gain settings, with a fixed FAST setting of 23.5:

f23.5.pdf

The peak at 34k is smallest at the largest Common gain setting of 13.0 (probably expected).  The other higher frequency peaks are higher, though, such as the ones at 24.7k, 29.6k, 34.5k, etc.:

f23.5z1.pdf

Here's a blow up of the peak at 1.06M, which peaks at about 9dB of common gain:

f23.5z2.pdf

 Here's the spectrum with a fixed Common gain of 10.5, and various FAST gains:

c10.5.pdf

and here's a zoom around that 1.06 MHz peak, which is smallest at a FAST gain of 23.5 dB:

c10.5z1.pdf

I'm not sure yet what this points to as the best gain settings.  We can of course explore more of the space.  I'm going to leave it at 13/23.5, which leaves the PC RMS at ~1.5 and the FAST Monitor at ~6.0.

If this does turn out to be a good setting we'll need to adjust some of the alarm levels.

Various settings:

MCS
  in1 gain: 15
  offset: 1.174
  boost enabled
  super boost: 2
  VCO gain: 25

FSS:
  input offset: -0.8537
  slow actuator: 0.6304

I include the python scripts I used to remotely control the AG4395 to take the measurements, and make the plots.

PS: I made some changes/improvements to the netgpib stuff that I'll cleanup and commit tomorrow.

 

Attachment 6: getdata
#!/usr/bin/env python

import os
import sys
import time
import numpy as np
sys.path.append('/opt/rtcds/caltech/c1/scripts/pylibs/')
import pyezcalib as ca
sys.path.append('/opt/rtcds/caltech/c1/scripts/general/netgpibdata/')
import netgpib
... 64 more lines ...
Attachment 7: plot
#!/usr/bin/env python

import os
#import numpy as np
from pylab import *

#name = sys.argv[1]

#atten = 10 # 10dB

... 31 more lines ...
  8587   Thu May 16 01:41:31 2013 JenneSummaryIOOFSS gain settings set

Quote:

I'm not sure yet what this points to as the best gain settings.  We can of course explore more of the space.  I'm going to leave it at 13/23.5, which leaves the PC RMS at ~1.5 and the FAST Monitor at ~6.0.

 I changed the value of the nominal FSS common gain in the PSL Settings screen (It's called the 'FSS global gain' there).  To get to this screen:  sitemap -> PSL_main -> PSL_settings.  The MC autolocker reads these settings from the screen and uses those values.  Now the FSS returns to this value of 13 that Jamie has chosen.  For the past few days, it's been going back to the old value of 10.1 .  The FAST gain was already set to this 23.5 value.

  8627   Thu May 23 10:48:42 2013 ManasaUpdateIOOMC autolocker and MCWFS enabled

Some strong seismic noise (not related to any earthquakes - watchdogs are all green) had got the MC unlocked this morning.

I found the MC autolocker and MCWFS disabled. Enabling them locked the MC right away. I don't see any updates in the elog  as to why these were left disabled and hence have left them ON now.

  8647   Tue May 28 11:11:37 2013 ManasaUpdateIOOMC aligned

[Jenne, Manasa]

Fixed crappy alignment of MC by moving MC mirrors. MC REFL PD measured 0.5 after alignment. Spot positions were measured using msassMCdecenter. Plot for the same is attached.

Attachment 1: MC_0528.png
MC_0528.png
  8673   Tue Jun 4 20:19:07 2013 ranaConfigurationIOOChanged threshold for FSS SLOW loop

The FSS SLOW actuator often runs off away from zero and into a region where the mode hopping is bad and makes a lot of frequency noise (e.g. that 8 hour period a few weeks ago when Jamie couldn't lock the MC).

It should not have this behavior. The SLOW loop should only be running when the MC is locked.

Today I found that the threshold was set back to 0.2 V (which is approximately the correct value for the RefCav locking). Its being compared to the MC TRANS, so the correct value should be ~1/2 of the maximum MC TRANS.

To find this out, I read this piece of text:

    # Make sure the loop is supposed to be active
    if (get_value("C1:IOO-MC_TRANS_SUM") < get_value("C1:PSL-FSS_LOCKEDLEVEL")) {
    print("Reference Cavity not locked -- control loop disabled.\n");
    next;
    }

from scripts/PSL/FSS/FSSSlowServo. I set the threshold using the commmand:

caput -c -t C1:PSL-FSS_LOCKEDLEVEL 12000

Then I restarted the code on op340m, by typing:

> nohup FSSSlowServo

and then closing the terminal. Seems to be behaving correctly now. Previously, the value was so low that the SLOW loop was never turning itself off.

  8718   Tue Jun 18 18:24:07 2013 ManasaUpdateIOOMC WFS turned OFF

[Jenne, Jamie, Manasa]

Jamie was working on the MC guardian today (I think he will elog about this soon).

After this, I received the MC locked in TEM00 with MC_REFL at ~2.5 counts from Jamie. Usually the WFS would do their job in this case to bring MC to a good locking condition and since this did not happen, I figured out that something was wrong with the MC_WFS.

What we did:

1. The WFS were turned off. 

2. As a first step, we wanted to run the WFS_OFFSET script (Koji's elog) which requires MC to be locked with MC_REFL<0.5 and spot positions centered. The autolocker was disabled and MC locked manually to MC_REFL<0.5. 

3. While running the WFS_OFFSETS script, Jamie pointed out that the inputs to the WFS servo had been turned off. After the WFS_OFFSET script finished running we turned ON the WFS inputs. 

4. Following this, the MC was relocked manually and MC spot positions were measured (all spot positions were decentered by < 2 mm). 

5. We ran the WFS_OFFSET script again and turned the WFS back ON. But this would still kick the MC out of lock. 
 

Status: MC is locked with WFS turned OFF. Jamie will be looking through what changes he had made earlier today to fix this problem. 

 

  8724   Wed Jun 19 15:07:20 2013 ranaUpdateIOOWFS debugging

Trying to figure out what's wrong with the MC WFS:

1) The symptom seems to be that the control signals become very large in the pitch and then the loop breaks when they saturate. Usually this is due to a degenerate matrix or improper inversion. Most likely some of the BURT restore is bad or the analog gain for one of the WFS has been switched when Jamie was doing the "Guardian" debugging.

2) In checking this out, I found that several buttons on the WFS  screens were not working (and apparently have never been working). Please try to test things in the future...The filter bank buttons in C1IOO_MC_TRANS_QPD were using relative path names; fixed these to use abs path names. The buttons in the WFS_MASTER for the IOO_PIT banks were using IOO_PITCH instead...

2.5) Recentered beams on WFS heads with MC alignment good and MC unlocked.

3) Main problem in the WFS still not found - disabling this in the autolocker.

  8733   Thu Jun 20 15:15:39 2013 ranaUpdateIOOWFS debugging

Tried a bunch of stuff, but eventually just turned off the TRANS_QPD loops and loops are stable. Needs more debugging.

  1. Modified the on/off scripts so that the Integrators are no longer toggled. No reason to turn them off since we are clearing the filter bank histories.
  2. With QPD feedback OFF, I have lowered the overall gain by 15x so that its just drift control.
  3. Deleted unused / bad filters from the main filter banks.
  4. Gautam is going to debug the QPD with a red laser pointer and then elog.
  5. Jamie is checking out the MC Coil dewhitening logic to see if that's in a funny state.
Attachment 1: Untitled.png
Untitled.png
ELOG V3.1.3-