40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 119 of 341  Not logged in ELOG logo
ID Date Author Type Category Subject
  11177   Fri Mar 27 04:36:46 2015 denUpdateLSCals->pdh transition, prcl on 1f, alignment

Tonight I have modified transition steps from als to pdh signals. I have added 1:20 filters to CARM_A and DARM_A filter banks to make them unconditionally stable. These filters made locking more robust -- duty cycle is was ~70% tonight. I have also modified slow/ao crossover to avoid ringing up of lines above 1kHz.

Once AO is engaged with high bandwidth, REFL55 signal looks good and I transition PRCL from 165I to 55I. Optical gain compared to PRMI reduced from 55I/165I = -330 down to 55I/165I = 30 in full lock.

I worked on alignment of ETMs. Looking on the cameras I could improve arm power up to 160 and ifo visibility was 80%. POP22 fluctuated by ~50% and every few minutes we loose lock because POP22 almost touches zero.

  11176   Thu Mar 26 16:32:32 2015 JenneUpdateLSCREFL PDs get more light

Some more words on yesterday's REFL path work. 

The 90/10 BS that splits the light between REFL11 and REFL55 was placed back in August 2013, to compensate for the fact that REFL11 has a much larger RF transimpedance than REFL33.  See elog 9043 for details.

We had been operating for a long time with an embarrasingly small amount of light on the REFL PDs.  REFL11 used to have 80 uW, REFL33 used to have 400 uW and REFL55 used to have 700 uW.  REFL 165 was the only sane one, with about 15 mW of light.

After yesterday's work, the situation is now:

  Power incident [mW] PD responsivity [A/W] photocurrent [mA]
shot noise intercept
current [mA]
Ratio (photocurrent) /
(shot noise intercept current)
REFL 11 1.3 mW 0.7 0.91 mA 0.12 mA 7.6
REFL 33 13 mW 0.7 9.1 mA 0.52 mA 17.5
REFL 55 12 mW 0.7 8.4 mA 1.6 mA 5.3
REFL 165 50 mW 0.15 7.5 mA 1.06 mA 7.1

As an aside, I was foiled for a while by S vs. P polarizations of light.  The light transmitted through the PBS was P-pol, so the optics directing the beams to REFL11, 33 and 55 were all P-pol.  At first I completely removed the PBS and the waveplate, but didn't think through the fact that now my light would all be S-pol.  P-pol beam splitters don't work for S-pol (the reflection ratios are different, and it's just a terrible idea), so in the end I used the PBS to set the half waveplate so that all of my light was P-pol, and then removed the PBS but left the waveplate.  This means that all of the old optics are fine for the beams going to the 3 gold-box REFL PDs.  We don't have many S-pol beamsplitter options, so it was easier to use the waveplate to rotate the polarization. 

  11175   Thu Mar 26 10:41:06 2015 SteveUpdateIOOThe PMC is not clamped

The PMC is seated on 3 SS balls and it is free to move. I'm sure it will move in an earthquake. Not much, because the input and output K1 mirror frame will act as an earthquake stop.Atm2

Are there a touch of super glue on the balls? No, but there are V grooves at the bottom and on the top of each ball.Atm3


Attachment 1: IMG_0001.JPG
Attachment 2: PMCstops.jpg
Attachment 3: PMCballv.jpg
  11174   Wed Mar 25 21:44:20 2015 KojiUpdateLSCIFO recovery / PRFPMI locking activity

[Koji, Den]

- Aligned the arms with ASS. It had alot of offset accumulated. We offloaded it to the suspension.

- We could lock the PRMIsb with the new setup.
PRCL: REFL165I (-14deg, analog +9dB)) -0.1, Locking FM4/5, Triggered FM 2
MICH: REFL165Q (-14deg, analog +9dB) -1.5, Locking FM4/5, Triggered FM2/6/9

- Demod phases at REFL were adjusted such that PRCL in Q signals were minimized :
REFL165 -80deg => -14deg
POP55 -63deg
REFL11 +164 => +7
REFL33 +136 => +133

Note: analog gains: REFL11: +18dB,  REFL33: +30dB, POP55: +12dB, REFL165: +9dB

- Try some transition between REFL signals to check the signal quality.
Measure TFs between the REFL signals

PRCL gain
REFL11I/REFL165I = +58
REFL33I/REFL165I = +8.5
POP55I /REFL165I = -246

MICH gain
REFL11Q/REFL165Q = +11
REFL33Q/REFL165Q = -1.5
POP55Q /REFL165Q = +280

- This resulted us to figure out the relationships of the numbers in the input matrix 

REFL55I/Q -4e-3/4e-3
REFL165I/Q 1.0/1.0 (reference)
REFL11I/Q  0.02/0.1
REFL33I/Q +0.12/-0.7

Full locking trial

Arm locked -> ALS -> Arm offset locked
PRMI locking
REFL165 phase tuned -110deg
PRCL gain -0.1 / MICH gain -2

We needed script editing.
Previous script saved in: /opt/rtcds/caltech/c1/scripts/PRFPMI/carm_cm_up_BACKUP.sh

- PRMI gain setting (input matrix & servo gain)
- CARM/DARM transition setting (see below)

The current CARM/DARM transition procedure:

- CM REFL1 gain is set to be -32
- CARM_B is engaged and the gain is ramped from 0 to +2.5
- Turn on FM7 (integrator)
- MC IN2 (AO path) engaged
- MC IN2 gain increased from -32 to -21

- DARM_B is engaged and the gain is ramped from 0 to +0.1
- Turn on FM7 (integrator)

- CM REFL1 Gain is increased from -32 to -18
- Ramp down CARM A gain to 0

- DARM_B gain is incrased to 0.37. At the same time DARM_A gain is reduced to 0

We succeeded to make the transition several times in the new setting.

- But later the transition got hard. We started to see big jump of the arm trans (TRX/Y 50->100) at the CARM transition.

- We tested the PRCL transition from 165MHz to 55MHz. 55MHz (i.e. POP55 which is REFL55PD) looks alot better now.

- ~1:30 The PMC was realigned. This  increased PMC_TRANS about 10%. This let the Y arm trans recover ~1.00 for the single arm locking

- Decided to end around 3:00AM

  11173   Wed Mar 25 18:48:11 2015 KojiSummaryLSC55MHz demodulators inspection

[Koji Den EricG]

We inspected the {REFL, AS, POP}55 demodulators.

Short in short, we did the following changes:

- The REFL55 PD RF signal is connected to the POP55 demodulator now.
Thus, the POP55 signals should be used at the input matrix of the LSC screens for PRMI tests.

- The POP55 PD RF signal is connected to the REFL55 demodulator now.

- We jiggled the whitening gains and the whitening triggers. Whitening gains for the AS, REFL, POP PDs are set to be 9, 21, 30dB as before.
However, the signal gain may be changed. The optimal gains should be checked through the locking with the interferometer.

- Test 1

Inject 55.3MHz signal to the demodulators. Check the amplitude in the demodulated signal with DTT.
The peak height in the spectrum was calibrated to counts (i.e. it is not counts/rtHz)
We check the amplitude at the input of the input filters (e.g. C1:LSC-REFL55_I_IN1). The whitening gains are set to 0dB.
And the whitening filters were turned off.

f_inj = 55.32961MHz -10dBm
REFL55I @999Hz  22.14 [cnt]
REFL55Q @999Hz  26.21 [cnt]

f_inj = 55.33051MHz -10dBm
REFL55I @ 99Hz  20.26 [cnt]  ~200mVpk at the analog I monitor
REFL55Q @ 99Hz  24.03 [cnt]

f_inj = 55.33060MHz -10dBm
REFL55I @8.5Hz  22.14 [cnt]
REFL55Q @8.5Hz  26.21 [cnt]

f_inj = 55.33051MHz -10dBm
AS55I   @ 99Hz 585.4 [cnt]
AS55Q   @ 99Hz 590.5 [cnt]   ~600mVpk at the analog Q monitor

f_inj = 55.33051MHz -10dBm
POP55I  @ 99Hz 613.9 [cnt]   ~600mVpk at the analog I monitor
POP55Q  @ 99Hz 602.2 [cnt]

We wondered why the REFL55 has such a small response. The other demodulators seems to have some daughter board. (Sigg amp?)
This maybe causing this difference.


- Test 2

We injected 1kHz 1Vpk AF signal into whitening board. The peak height at 1kHz was measured.
The whitening filters/gains were set to be the same condition above.

f_inj = 1kHz 1Vpk
REFL55I 2403 cnt
2374 cnt
AS55I   2374 cnt
AS55Q   2396 cnt
POP55I  2365 cnt
  2350 cnt

So, they look identical. => The difference between REFL55 and others are in the demodulator.

  11172   Wed Mar 25 18:46:14 2015 JenneUpdateLSCREFL PDs get more light

After discussions during the meeting today, I removed the PBS from the REFL path, which gives much more light to REFL11, REFL33 and REFL55.  Also, the ND1.5 in front of REFL165 was replaced with ND1.1, so that REFL165 now gets 50mW of light.  REFL11 gets about 1.3mW, REFL33 gets about 13mW and REFL55 gets about 12mW. 

No locking, and importantly no re-phasing of any PDs has been done yet. 

Here is an updated diagram of the REFL branching ratios.

Attachment 1: AS_REFL_branchingRatios_25Mar2015.png
  11171   Wed Mar 25 18:27:34 2015 KojiSummaryGeneralSome maintainance

- I found that the cable for the AS55 LO signal had the shielding 90% broken. It was fixed.

- The Mon5 monitor in the control room was not functional for months. I found a small CRT down the east arm.
It is now set as MON5 showing the picture from cameras. Steve, do we need any safety measure for this CRT?

  11170   Wed Mar 25 08:29:31 2015 SteveUpdateLSCMeh

  I turned on the HEPA at the south end during the LSC. Sorry I ment to turn it off.


[Jenne, Den]

Overall a "meh" night for locking I think.  The script to all-RF worked several times earlier in the evening, although it was delicate and failed at least 50% of the time.  Later in the evening, we couldn't get even ~10% of the lock attempts all the way to RF-only. 

Den looked into angular things tonight.  With the HEPA bench at the Xend on (which it was found to be), the ETMX oplevs were injecting almost a factor of 10 noise (around 10ish Hz?) into the cavity axis motion (as seen by the trans QPD) as compared to oplevs off.  Turning off the HEPA removed this noise injection.

Den retuned the QPD trans loops so that they only push on the ETMs, so that we can turn off the ETM oplevs, and leave the ITMs and their oplevs alone. 

We are worried again about REFL55.  There is much more light on REFL55 than there is on REFL11 (a 90/10 beam splitter divides the light between them), and we see this in the DC output of the PDs, but there seems to be very little actual signal in REFL55.  Den drove a line (in PRCL?) while we had the PRMI locked with the arms held off resonance, and REFL55 saw the line a factor of 1,000 less than REFL 11 or REFL165.  The analog whitening gain for REFL11 is +18dB, and for REFL55 is +21dB, so it's not that we have significantly less analog gain (that we think).  We need to look into this tomorrow.  As of now, we don't think there's much hope for transitioning PRMI to REFL55 without a health checkup. 


  11169   Wed Mar 25 03:31:18 2015 JenneUpdateLSCMeh

[Jenne, Den]

Overall a "meh" night for locking I think.  The script to all-RF worked several times earlier in the evening, although it was delicate and failed at least 50% of the time.  Later in the evening, we couldn't get even ~10% of the lock attempts all the way to RF-only. 

Den looked into angular things tonight.  With the HEPA bench at the Xend on (which it was found to be), the ETMX oplevs were injecting almost a factor of 10 noise (around 10ish Hz?) into the cavity axis motion (as seen by the trans QPD) as compared to oplevs off.  Turning off the HEPA removed this noise injection.

Den retuned the QPD trans loops so that they only push on the ETMs, so that we can turn off the ETM oplevs, and leave the ITMs and their oplevs alone. 

We are worried again about REFL55.  There is much more light on REFL55 than there is on REFL11 (a 90/10 beam splitter divides the light between them), and we see this in the DC output of the PDs, but there seems to be very little actual signal in REFL55.  Den drove a line (in PRCL?) while we had the PRMI locked with the arms held off resonance, and REFL55 saw the line a factor of 1,000 less than REFL 11 or REFL165.  The analog whitening gain for REFL11 is +18dB, and for REFL55 is +21dB, so it's not that we have significantly less analog gain (that we think).  We need to look into this tomorrow.  As of now, we don't think there's much hope for transitioning PRMI to REFL55 without a health checkup. 

  11168   Tue Mar 24 18:47:10 2015 ericqUpdateLSCAO Path engaged

Jenne has more detailed notes about how things went down last night, but I figure I should write about how we got the AO path stably up. 

As the carm_cm_up script stood after Jenne and Den's work last week, the CARM loop looked like the gold trace in the loop shape plot I posted in the previous elog. The phase bubble was clearly enlarged by the AO path, but there was some bad crossover instability brewing at 400 Hz. This was evident as a large noise peak, and would lead to lock loss if we tried to increase the overall CARM gain.



As with our single arm CM board locking adventures, it was useful to have a filter that made the digital loop shape steeper around the crossover region, so that the 1/f AO+cavity pole shape played nice with the digital slope. As in the single arm trials, this effectively meant undoing the cavity pole compensating zero with a corresponding pole, letting the physical cavity pole do the steepening. This is only possible once the AO path has bestowed some phase upon you. A zero at a somewhat higher frequency (500Hz) gives the digital loop back some phase, which is neccesary to stay locked when the loop has only a few hundred Hz UGF, and the digital phase still matters. This gives us the purple trace. 

This provided us with a loop shape that could smoothly be ramped up in overall gain towards UGFs of multiple kHz (red trace). At this point we could reliably turn on the first boost, which will help in transitioning the PRMI to 1f signals (green trace). We didn't want to ramp it up too much, as we saw that the phase bubble likely ended not much higher than 100kHz, and the OLG magnitude was flattening pretty clearly around 40kHz. While we could turn on a super boost, it didn't look too nice, as we would have to stay at low phase margin to avoid bad gain peaking (blue trace).

As could be seen in the noise spectra that Jenne showed, you can see the violin notches in the CARM noise. This means we are injecting the digital loop noise all over the place. We attempted rolling off the digital loop (by undoing the zero at 500Hz), but found this made the gain at ~200Hz crash down, almost becoming unstable. We likely haven't positioned the crossover frequency in the ideal place for doing this. 

We didn't really give the interferometer any time to see how the long term stability was, since we wanted to poke around and measure as much as we could. While not every attempt would get us all the way there, the current carm_cm_up's success rate at achieving multi-kHz CARM bandwidth was pretty good (probably more than 50%) and the whole thing is still pretty snappy. 

  11167   Tue Mar 24 18:22:11 2015 ericqUpdateLSCAO Path engaged

For increased flatness of the AO response, and thus less gain peaking in the CARM loop, I reccomend turning down the MC servo VCO gain to 22dB, -6dB of the current setting. 

From there, we should be able to up the overall CARM gain by another 10dB, and turn on a super boost. 

I measured the IN1/IN2 response of the IMC loop with the aglient analyzer providing the IN2 excitation, to see the transfer function of the AO acutation. The hump in the TF explains the flattening out of the CARM OLTF we saw last night. Turning down the gain by 6dB flattens this bump, and more importantly, has around 10dB less gain when the phase goes through -180, meaning more gain margin for the CARM loop. 

Oddly, when I back out the MC OLG from these measurements, the loop shape is different than what Koji and Rana measured in December (ELOG 10841). Specifically, there is some new flattening of the loop shape around 300-400kHz that lowers the frequency where the phase hits -180. What could have caused this???

The -6dB that I mentioned was determined by putting the MC UGF at about 100kHz, at the peak of the phase bubble. This should allow us to safely have a CARM UGF of 40kHz since the MC loop has around +10dB loop gain there, which Rana once quoted as a rule of thumb for these loops. At that UGF, at least one CM board super boost should be fine, based on the loop shapes measured last night. 

Lastly, I also checked out whether the 3 MC super boosts were limiting the AO shape; I did not observe any diffrence of the AO TF when turning off one super boost. It's likely totally fine. 

Attachment 1: IMC_ao_Mar242015.png
Attachment 2: IMC_olgs_Mar242015.png
  11166   Tue Mar 24 15:22:12 2015 manasaUpdateComputer Scripts / ProgramsNew slow channels for FOL

[Koji, Manasa]

I have created new slow channels for FOL. To do so, I have edited the fcreadout.db file in Domenica and the C0EDCU.ini file in /chans/daq

Domenica and frame builder were restarted after the edits.

Koji has moved the following files from /opt/rtcds/caltech/c1/chans/daq/ to /opt/rtcds/caltech/c1/chans/daq/trash  as they are not being used anymore.


  11164   Tue Mar 24 10:53:30 2015 manasaUpdateGeneralScripts updated to the svn

I found that the scripts in FOL and PDFR directories were not in the svn. These were added to the svn.

  11163   Tue Mar 24 05:05:09 2015 ericqUpdateLSCAO Path engaged

[J, Q]

Terse tonight, more verbose tomorrow. 

We have succesfully achieved multiple kHz bandwidth using the CARM AO path. The CM board super boosts are at too high of a frequency to use effectively, given the flattening of the AO TF. 

Jenne's totally, completely, and in all possible ways uncalibrated plot.  Calibration lines are in here (numbers in control room notebook).  I'm going to export and replot the data tomorrow, in real units.


Attachment 1: CARM_DARM_AOengaged_23March2015.pdf
Attachment 2: loops.png
  11162   Mon Mar 23 22:56:54 2015 ericqUpdateComputer Scripts / ProgramsNodus web things

Back when Diego and I were getting all of the web services running up on the new nodus, we inexplicably were not able to get the hosting of the public_html directory and wikis to share the same port of 30889. In ELOG 10793, we stated that public_html was hosted on a new port, 30888, though we didn't really bring much attention to that new fact. 

Unbeknowst to us at the time, this broke other links/bookmarks/sites that people had been using. Koji pointed this out to me the other day, but I have not made any sort of resolution. For now, the public_html directory, and the sites therein, have been taken offline. 

In other nodus news, Jamie has set Nodus' apache service with a certificate for SSL goodness. We want to extend this to the ELOG, which uses a built in webserver, rather than apache. 

He set up a proxy at the https address which will later host the secured elog: https://nodus.ligo.caltech.edu:8081/

When we make the switch to running the ELOG with HTTPS on by default, living on port 8081, we will set up apache to point 8080 at 8081, to preserve all of the old links. 

I.e. this change should effectively be invisible to ELOG users if we implement it right. 

  11161   Mon Mar 23 19:30:36 2015 ranaUpdateComputer Scripts / Programsrsync frames to LDAS cluster

The rsync job to sync our frames over to the cluster has been on a 20 MB/s BW limit for awhile now.

Dan Kozak has now set up a cronjob to do this at 10 min after the hour, every hour. Let's see how this goes.

You can find the script and its logfile name by doing 'crontab -l' on nodus.

  11160   Mon Mar 23 13:27:33 2015 ericqUpdateSUSITMX oplev quadrant gains unbalanced

I've been poking around the oplev situation. One thing I came across regarding ITMX was that the gain on segment 4 seems to be about higher than the other segments. I was led to believe this by steering the optic around, and looking at the counts on each quadrant when the other 3 were dark.

Putting a gain of 0.86 (the ratio of the other segments' max counts over segment 4's max counts) in the segment 4 FM flattens the 1 Hz peak in the ITMX_OL_SUM spectrum, as well as significantly reducing the sub-Hz coherence of the sum with the individual quandrant counts. This is what I would expect from reducing the coupling of angular motion due to quadrant gain mismatch into the sum. 

Here are the ITMX_OL_SUM spectra before and after (oplev servos are off).

The "burps" and control filter saturations are still unexplained. Investigations continue...

Attachment 1: olsum.png
  11159   Mon Mar 23 10:36:55 2015 ericqUpdateVACPressure watch script

Based on Jenne's chiara disk usage monitoring script, I made a script that checks the N2 pressure, which will send an email to myself, Jenne, Rana, Koji, and Steve, should the pressure fall below 60psi. I also updated the chiara disk checking script to work on the new Nodus setup. I tested the two, only emailing myself, and they appear to work as expected. 

The scripts are committed to the svn. Nodus' crontab now includes these two scripts, as well as the crontab backup script. (It occurs to me that the crontab backup script could be a little smarter, only backing it up if a change is made, but the archive is only a few MB, so it's probably not so important...)

  11158   Mon Mar 23 09:42:29 2015 SteveSummaryIOO4" PSL beam path posts

To achive the same beam height each components needs their specific post height.

 Beam Height Base Plate Mirror Mount Lens Mount  Waveplates-Rotary 0.75" OD. SS Post Height                      
4" Thorlabs BA2   Newport LH-1   2.620"  
4" Thorlabs BA2 Polaris K1     2.620"  
4" Thorlabs BA2 Polaris K2     2.220"  
4" Thorlabs BA2   Thorlabs LMR1   2.750"  
4" Thorlabs BA2     New Focus 9401 2.120"  
4" Thorlabs BA2 Newport U100     2.620"  
4" Thorlabs BA2 Newport U200     2.120"  
4" Newport 9021   LH-1   2.0" PMC-MM lens with xy translation stage: Newport 9022, 9065A    Atm3
4" Newport 9021   LH-1   1.89 MC-MM lens with translation stage: Newport 9022, 9025        Atm2

We have 2.625" tall, 3/4" OD SS posts for Polaris K1 mirror mounts: 20 pieces

Ordered Newport LH-1 lens mounts with axis height 1.0 yes


Attachment 1: .75odSSpost.pdf
Attachment 2: MC_mml_trans_clamp.jpg
Attachment 3: PMCmmLn.jpg
  11156   Sun Mar 22 18:42:40 2015 SteveUpdateVACvac pressure rose to 1.2mTorr



We run out of N2 for the vacuum system. The pressure peaked at 1.3 mTorr with MC locked. V1 did not closed because the N2 pressure sensor failed.

We are back to vac normal. I will be here tomorrow to check on things.

We run out of N2 for the vacuum system 6 hrs ago. The pressure rose to 1.2 mTorr with V1 closed. The interlock worked! See Nirogen presure reading fixed at http://nodus.ligo.caltech.edu:8080/40m/10968


The vacuum interlock: Nitrogen pressure transducer is reading the pneumatic pressure continously at the pump spool and c1vac1 processing it. When it drops below 60 PSI it closes V1 gate valve and V4 & V5.  Gate valve V1 needs minimum 60 PSI to close. It is critical that V1 is closed before you run out of Nitrogen so the IFO pressure is contained.


IFO vacuum is back to Vac Normal. The MC is locked.

cc4 = 2E-6 Torr with VM1 open.


Daily N2 consumption measured to be 530PSI as 3 days on 3-27-2015 but note: it does vary !

I have seen it as high as 900 psi  The long term average ~750 psi

Attachment 1: NoN2.png
Attachment 2: PressureReadingWorks.png
  11155   Sun Mar 22 13:53:44 2015 ranaUpdateSUSITMX alignment jumps

So, was there real shifting in the ITMX alignment as seen in the DV trend or just mis-diagnosis from the ETMX violin mode? Or how would the ETMX violin mode drive the ITMX with the LSC feedback disabled?

  11154   Sat Mar 21 05:19:49 2015 JenneUpdateLSCIFO awake

[Jenne, Den]

The problem with the ASS turned out to be a mode that was rung up at 1326Hz in ETMX.  It was rung up when the Xarm's overall gain was too high.  So, by turning down the digital gain we were able to prevent it ringing up, and then the ASS worked.  To circumvent this, we added a notch to the violin filter bank.  It turned out that, upon trying to check if this existed also for the Yarm by turning up the digital gain, the ETMY frequency was almost identical.  So, the same single notch is in both ETMs, and it covers the modes for both ETMs.

After that, we got back to locking.  We have made at least 9 transitions to all-RF (both CARM and DARM) tonight (I have lost track of how many Den has done while I've been writing this - maybe we're up to 10 or so.). We have changed the order of things a little bit, but they're mostly similar to last week.  There are some new notches in the CARM_B filter bank, as well as a 700Hz low pass.  We have not been using the lead filter in DARM from last week.  Script is checked in, and also zipped and attached.  At first CARM was actuating on ETMs, but the last half of the locks we've been using MC2.  The script is optimized for MC2 actuation.

While locked all RF, we phased REFL55 in preparation for transitioning PRMI over from REFL165. REFL55 phase was +125, now is +80, give or take 5 deg.  We have tried measuring the relative gain and sign between REFL55 and REFL165, but we keep losing lock, perhaps as a result of the TFs Den is taking.  He's being gentle though. 

Up next:

Transition PRMI

Measure CARM loop (why was SRmeasure not working?? is it plugged in??)

Turn on AO boosts, etc.


Attachment 1: carm_cm_up_zip.sh.gz
  11153   Fri Mar 20 23:37:46 2015 JenneUpdateSUSWaking up the IFO

In addition to (and probably related to) the XARM ASS not working today, the ITMX has been jumping around kind of like ETMX sometimes does.  It's very disconcerting. 

Earlier today, Q and I tried turning off both the LSC and the oplev damping (leaving the local OSEM damping on), and ITMX still jumped, far enough that it fell off the oplev PD. 

I'm not sure what is wrong with ITMX, but probably ASS won't work well until we figure out what's up.

I tried a few lock stretches (after realigning the Xgreen on the PSL table) after hand-aligning the Xarm, but the overall alignment just isn't good enough.  Usually POPDC gets to 400 or 450 while the arms are held off resonance, but today (after tweaking BS and PRM alignment), the best I can get POPDC is about 300 counts. 

Den and I are looking at the ASS and ITMX now.

  11152   Fri Mar 20 16:44:49 2015 ericqUpdateIOOWaking up the IFO

X arm ASS is having some issues. ITMX oplev was recentered with ITMX in a good hand-aligned state. 

The martian wifi network wasn't showing up, so I power cycled the wifi router. Seems to be fine now. 

  11151   Fri Mar 20 13:29:33 2015 KojiUpdateIOOWaking up the IFO

If the optics moved such amount, could you check the PD alignment once the optics are aligned?

  11150   Fri Mar 20 12:42:01 2015 JenneUpdateIOOWaking up the IFO

I've done a few things to start waking up the IFO after it's week of conference-vacation.

PMC trans was at 0.679, aligned the input to the PMC, now it's up at 0.786.

MC transmission was very low, mostly from low PMC transmission.  Anyhow, MC locked, WFS relieved so that it will re-acquire faster.

Many of the optics had drifted away. AS port had no fringing, and almost every optic was far away from it's driftmon set val.  While putting the optics back to their driftmon spots, I noticed that some of the cds.servos had incorrect gain.  Previously, I had just been using the ETMX servo, which had the correct gain, but the ITMs needed smaller gain, and some of the optics needed the gain to be negative rather than positive.  So, now the script ..../scripts/SUS/DRIFT_MON/MoveOpticToMatchDriftMon.py has individually defined gains for the cds.servo. 

Next up (after lunch) will be locking an aligning the arms.  I still don't have MICH fringing at the AS port, so I suspect that the ASS will move some of the optics somewhat significantly (perhaps the input tip tilts, which I don't have DRIFT_MON for?)

  11149   Fri Mar 20 10:51:09 2015 SteveSummaryIOOMC alignment not drifting; PSL beam is drifting

Are the two  visible small srews holding the adapter plate only?

If yes, it is the weakest point of the IOO path.

Attachment 1: eom4.jpg
Attachment 2: eom3.jpg
  11148   Thu Mar 19 17:11:32 2015 steveSummarySUSoplev laser summary updated

           March  19, 2015   2  new  JDSU 1103P, sn P919645 & P919639 received from Thailand through Edmond Optics. Mfg date 12/2014............as spares

  11147   Thu Mar 19 16:58:19 2015 SteveSummaryIOOMC alignment not drifting; PSL beam is drifting

Polaris mounts ordered.


In the attached plot you can see that the MC REFL fluctuations started getting larger on Feb 24 just after midnight. Its been bad ever since. What happened that night or the afternoon of Feb 23?
The WFS DC spot positions were far off (~0.9), so I unlocked the IMC and aligned the spots on there using the nearby steering mirrors - lets see if this helps.

Also, these mounts should be improved. Steve, can you please prepare 5 mounts with the Thorlabs BA2 or BA3 base, the 3/4" diameter steel posts, and the Polanski steel mirror mounts? We should replace the mirror mounts for the 1" diameter mirrors during the daytime next week to reduce drift.


Attachment 1: driftingInputBeam2.jpg
  11145   Thu Mar 19 14:37:17 2015 manasaConfigurationIOOIMC relocked

The autolocker was struggling to lock the IMC. I disabled the autolocker and locked the IMC manually. It seems happy right now. 

With PMC trans at 0.717 counts, the IMC trans sum is ~15230.


The MC autolocker hasn't been so snappy recently, and has been especially fussy today. Previously, the mcup script was triggered immediately once the transmission was above a certain threshold. However, this could waste time if it was just an errant flash. Hence, I've added a 0.5 second delay and a second threshold check before mcup is triggered. 

After breaking the lock 5ish times, it does seem to come back quicker.


  11144   Sun Mar 15 18:49:57 2015 JenneUpdateLSCMore stable DARM transitions

I have modified the DARM model from elog 11133, to include the fact that these are digital filters.

I have also extracted the data from elog 11143, and it together with the model.

The modeled loop has an arbitrary gain factor, to make it have the same 234Hz UGF as the measured data.

The modeled loop includes:

  • Actuators
    • Pendulum (1Hz, Q of 4)
    • Violin filters
      • ETMs 1st, 2nd, 3rd order
      • MC2 1st, 2nd order
    • 3 16kHz delays for computation on the rfm model, transfer to the end sus models, and computation on end sus models.
    • Digital anti-imaging to get up to the IOP model
    • Delay of 64kHz for computation on IOP model
    • Analog anti-imaging
  • Plant
    • Single 4.5kHz pole
  • Sensor
    • Analog anti-aliasing
    • 64kHz delay for computation on IOP model
    • Digital anti-aliasing to get to LSC model rate
  • Loop Shape (digital filters extracted from Foton file using FotonFilter.m)
    • DARM B's integrator (FM7)
    • DARM's low freq boost (FM3)
    • DARM's locking filter (FM5)
    • DARM's bounceRoll filter (FM6)
    • DARM's new lead filter (FM7)
    • Delay of 16kHz for computation on LSC model (includes Dolphin hop to c1sus rfm model)

There is a 1.5 degree phase discrepancy at 100Hz, and an 11 degree phase discrepancy at 900Hz, but other than that, the modeled and measured loops match pretty well.

For the measured frequencies, here are the residuals:

Attachment 1: DARM_modelVsmeas_15March2015.png
Attachment 2: DARMresiduals.png
  11143   Sat Mar 14 01:14:09 2015 JenneUpdateLSCMore stable DARM transitions

[Jenne, Koji, Rana]

Thanks to turning off the AS55 analog whitening as well as the 1k:6k lead filter that Koji put into Darm's FM7, the DARM transition was more stable early in the evening.

The AS55 gain and offset did not change noticeably when we switched the AA on or off (switching happened while *not* using AS for any feedback).  Earlier in the evening, we did also check what happened with PRMI and REFL33 AA on vs. off, and REFL33 did have a many tens of counts offset on both the I and Q input channels.  I have turned the AA filters back on, but run LSCoffsets before trying to lock.

I'm not sure what was up, but somehow I couldn't lock the PRMI for about half an hour or so.  Very frustrating.  Eventually after futzing around, I was able to get it to lock with REFL33 in PRMI-only, and after that it worked again in PRFPMI with REFL165. 

With FSS slow around 0.5, MC has been a bit fussy the last hour.  Also frustrating.

Later on in the evening, I started taking out a bunch of the "sleep" commands from the up script, and many of the "press enter to continue" spots, but I think it might be moving too fast.  That, or I'm just not catching where I have too much gain.  Anyhow, near the middle/end of the CARM transition I am getting severe gain peaking at several hundred Hz.  I think I need to use a lower final gain.

So, progress on DARM, but maybe a little more fine-tuning of CARM needed.

Here's a DARM loop measurement, taken after both CARM and DARM were RF-only:



Attachment 1: DARM_RF-only_13Mar2015.pdf
DARM_RF-only_13Mar2015.pdf DARM_RF-only_13Mar2015.pdf
  11142   Sat Mar 14 00:12:18 2015 ranaUpdateSUSOplevs huh?

The oplev situation still seems unresolved - notice this DTT. I guess there are still inconsistencies in the screens / models etc.

Could use some some investigation and ELOGGING from Eric.

Attachment 1: burp.png
  11141   Fri Mar 13 23:49:28 2015 ranaUpdatePSLRelaxation Osc and the NPRO Noise eater

Another thought about the mystery PCDRIVE noise: we've been thinking that it could be some slow death inside the NPRO, but it might also be a broken and intermittent thing in the MC servo or MC REFL PD.

Another possibility is that its frequency noise in the old oscillator used to drive the pre-PMC EOM (which is the Pockel Cell for the FSS). To check this, we should swap in a low noise oscillator for the PMC. I have one for testing which has 36 and 37 MHz outputs.

  11140   Fri Mar 13 14:11:59 2015 ranaUpdateLSC6+ CARM->REFL transitions, 1 DARM->AS transition

Since the DARM_OUT signal is only 500 counts_peak, I don't see why AS55 whitening needs to be switched on.cool Maybe in a couple weeks after the lock is robust. In any case, its much better to do the switching BEFORE you're using AS55, not after.

  11139   Fri Mar 13 03:10:35 2015 JenneUpdateLSC6+ CARM->REFL transitions, 1 DARM->AS transition

Much more success tonight.  I only started my tally after I got the CARM transition to work entirely by script, and I have 6 tally marks, so I probably made the CARM to RF-only transition 7 or maybe 8 times tonight in total.  Unfortunately, I only successfully made the DARM transition to AS55 once.    From the wall striptool, counting the number of times the transmitted power went high, I had about 40 lock trials total. 

The one RF-only lock ended around 1:27am.

I think 2 things were most important in their contributions to tonight's success.  I modified the bounceRoll filters in the CARM and DARM filter banks to eat less phase.  Also, using Q's recipe as inspiration, I started engaging the AO path partway through the CARM transition which makes it much less delicate. 

Bounce roll filter

Koji and I added a ~29Hz resonant gain in the bounce roll filter several months ago, to squish some noise that we were seeing in the CARM and DARM ALS error signals.  This does a lot of the phase-eating.  I'm assuming / hoping that that peak won't be present in the CARM and DARM RF error signals.  But even if it is, we can deal with it later.  For now, that peak is not causing so much motion that I require it.  So, it's gone. 

This allowed me to move the complex zero pair from 30 Hz down to 26 Hz.  Overall I think this gained me about 10 degrees of phase at 100Hz, and moved the low end of the phase bubble down by about 10Hz. 

Prep for REFL 11 I through the CM board and CM_SLOW

In order to use Q's recipe (elog 11138), I wanted to be able to lock CARM on REFL11 using the CM_SLOW filter bank. 

I did a few sweeps through CARM resonance while holding on ALS, and determined that the REFL1 input to the CM board needed a gain of -20dB in order to match the slope of CM_SLOW_OUT to CARM_IN (ALS), leaving all of Q's other settings alone.  Q had been using a REFL1 gain of 0dB for the PRY earlier today.

I needed to flip the sign in the input matrix relative to what Q had (he was using +1 in the CM_SLOW -> CARM_B, I used -1 there).  To match this in the fast path, I flipped the polarity of the CM board (Q was using minus polarity, I am using positive).

The CM_SLOW filter bank had a gain of 0.000189733.  I assume that Q did this so that the input matrix element could be unity.  I left this number alone.  It is of the same order as the plain REFL11I->CARM input matrix element of 1e-4 from Saturday night, so it seemed fine.

During my sweeps through CARM resonance, I also saw that I needed an offset to make CM_SLOW's average about 0.  With the crazy gain number, I needed an offest of -475 in the CM_SLOW filter bank.  As I type this though, it occurs to me that I should have put this in the CM board, since the fast path will have an offset that isn't handled.  Ooops. 

Trying Q's recipe for engaging AO path

I am able to get the MC2 AO gain slider up to -10dB (-7 is also okay).  If I increase the digital CARM gain too much, I see gain peaking at about 800Hz, so something good is happening.  (That was with a CARM_B gain of 2.0 and CARM_A gain of 0.  Don't go to 2.0)

I tried once without engaging his 300:80 1/f^2 filter in the CM_SLOW filter banks to start stepping up the CM REFL1 and MC AO gains together, but I only made it 2 steps of 1dB each before I lost lock. 

I tried once or twice turning on that 300:80 filter that Q said over the phone really helped his PRY locking, but it causes loop oscillations in CARM.  Also, I forgot to turn it off for ~45 minutes, and it caused several locklosses.  Ooops.  Anyhow, this isn't the right filter for this situation.

AS55 whitening problem

Twice I tried turning on the AS55 whitening.  Once, I was only partly transitioned from ALSdiff to AS55, the other time was the one time I made the full transition.  It caused the lockloss from the only RF-only lock I had tonight :(

Unfortunately I don't have the time series before the whitening filters (not _DQ-ed), but you can see a giant jump in the _ERR signals when I turn on the whitening, just before the arm power dies:


The AS55 phase is -30, I has an offset of 28.2 and Q has an offset of 6.4.  Both have a gain of 1.  This should give us enough info to back out what the _IN1 signals looked like before I turned on the whitening if that's useful.

Other random notes

Ramp times for CARM_A, CARM_B, DARM_A and DARM_B are all 5 seconds.  This is set in the carm_cm_up script.

carm_cm_up script freezes the arm ASS before it starts the IR->ALS transition, to make it more convenient to run the ASS each lockloss.

carm_cm_up script no longer has a bunch of stuff at the bottom that we're not using.  It's all archived in the svn, but the remnants from things like variable finesse aren't actively  useful.

carm_cm_down script turns off the CM_SLOW whitening (which gets set in the up script)

carm_cm_down script clears the history of the ETM oplevs, in case they went bad (from some near divide-by-zero action?), but the watchdog isn't tripped. This clears away all the high freq crap and lets them do their job.

FSS Slow has been larger than 0.55 all night, larger than 0.6 most of the night, and larger than 0.7 for the last bit of the night.  MC seems happy.

both carm_cm_up and carm_cm_down are checked into the svn.  The up script is rev 45336 and the down script is 45337.

Some offset (maybe the fact that the fast AO path had an un-compensated offset?) is pulling the arm powers down as I make the transitions:

Recipe overview

  • Lock PRMI with arms held on ALS at 3nm CARM offset.  Bring CARM offset to 0.
  • Turn on CARM_B and DARM_B a little bit, then turn on their integrators
  • Lower the PRCL and MICH gains a little.
  • Increase the CARM_B gain a bit, then turn off FM1 for both CARM and DARM.
  • Increase CARM_B gain, lowering CARM_A gain.
  • Increase DARM_B gain, lowering DARM_A gain.  Now the power should definitely be stable (usually ends up around 80).
  • Partly engage AO path.
    • CM board REFL1 gain = -20dB
    • CM board AO gain = 0dB
    • MC2 board AO gain starts at -32dB, stepped up to -20dB
  • Increase CARM_B gain a bit
  • More AO path:  MC2 board AO gain steps from -20dB to -10dB
  • Increase CARM_B gain to 1.5, turn CARM_A gain to zero
  • CM_SLOW whitening on

After that, I by-hand made the DARM transition on the 6th successful scripted CARM transition, and tried to script what I did, although I was never able to complete the DARM transition again.  So, starting where the recipe left off above,

  • Turn off DARM's FM2 boost to win some more phase margin.
  • Increase DARM_B gain to 0.5, lower DARM_A gain to 0.

Since DARM doesn't have an analog fast path, it is stuck in the delicate filter situation.  I think that I should probably start using the UGF servo once the arm power is stable so that DARM stays in the middle of its phase bubble.

Rather than typing out the details of the recipe, I am attaching the up script.

Attachment 1: AS55whitening_lockloss_12March2015.pdf
Attachment 2: MoreDARMB_powerWentDown_12March2015.png
Attachment 3: carm_cm_up_zip.sh.gz
  11138   Thu Mar 12 19:54:31 2015 Q UpdateLSCHow to: PRY

Q doesn't like elogging, but he sent me this nice detailed email, so I'm copying it into the log:

I’ve locked the power recycled Y arm numerous times today, to try and find a usable AO recipe for the full locking.

Really, the “only" things that I think are different are the DC gain and pole frequency of the REFL11 CARM signal. The pole frequency can be simulated in the CM board (through the 1.4k:80 zero/pole pair), and the DC gain can be changed by changing the REFL1 gain on the CM board. 
The crossover frequency only depends on the relative gains of the digital and AO path, which is independent of these two factors, since they’re common to both. So, if we scale the common part appropriately, the same AO crossover procedure should work. I think.
So, concretely, I set up the gain in the CM_SLOW input filter so that 1x CM_SLOW_OUT -> CARM in the input matrix matched the ~120Hz UGF that we get with a gain 6 or 7 in the CARM FM. The REFL1 gain on the CM board was 0dB. 
I then normalized the signal by 1/Trmax. (i.e. I had TRY of ~3.3, so I put 0.30 in the normalization matrix), so that at full resonance, the slope should bee the same as with no normalizing. 
Then, with the Yarm locked on ALS through 1xCARM_A, PRY locked on REFL165, and at zero arm offset (TRY~3.3), I did the following
  • Transition the digital loop from 1xCARM_A (ALS) to 1xCARM_B (1xCM_SLOW_OUT)
  • Turn on CM_SLOW FM1 (whitening)
  • With CM board gains: 0db REFL1, 0dB AO, negative polarity, MC In2 gain=-32dB, turn on In2 on MC servo
  • Slowly ramp up MC In2 gain to -10dB (this starts pulling up the phase bubble of the loop)
  • Turn on the 300:80 filter in the CM_SLOW input filter (this provides a f^-2 slope around the crossover region)
  • Go from [AO,REFL1]=[-10,0] to [-4,+6] by stepping them together. (This brings you to a UGF of a few hundred Hz with tons of phase margin)
  • At this point, up the REFL1 gain to +12 or so. Turn on the :300 FM in the CM_SLOW input filter (This rolls off the digital part of the loop, makes the violin filters stop interfering with the shape)
  • UGF is now ~1kHz. Boosts can be turned on once the gain is ramped up high enough. 
The moral of the story is: if you set the REFL1 gain such that a +1.0 element in the input matrix gives you about the right UGF, then the above recipe should work, just with the REFL1 gains offset by your starting gain. (I suppose if you need a minus sign in the input matrix, that just means that the AO polarity needs to change too)
Every time the REFL1 gain is changed, the electronic offset changes, so I had to keep an eye on POY as a DC out-of-loop sensor and adjust the CM board voltage offset. For the full IFO, I think REFL55 would work for this. However, I hope that, since less REFL1 gain will be needed for the PRFPMI, the changes will be smaller….
Lastly, I think it’s good to keep the digital UGF at around 120, because the crossover steals some gain below the UGF, and you want to have some gain margin there. Turning off boosts may help with this too; I did all of this with all the normal CARM boosts on. 
Hope this made some sense!
  11137   Thu Mar 12 11:57:38 2015 KojiUpdateGeneralFOL troubleshooting

BTW, during this trouble shoot, we looked at the IR beatnote spectrum between the Xend and the PSL.
It showed a set of sidebands at ~200kHz, which is the modulation frequency.
There was another eminent component present at ~30kHz.
I'm afraid that there is some feature like large servo bump, a mechanical resonance, or something else, at 30kHz.

We should check it. Probably it is my job.

  11136   Thu Mar 12 03:47:56 2015 JenneUpdateLSCCARM and DARM loop adjustments

No wins tonight.

I've tried playing with the shapes of the loops a little bit (mostly CARM so far), to no avail.  I think I made it to CARM RF-only only one time tonight.  I was able to turn on the REFL11 whitening, although I lost lock while about halfway through the DARM transition. 

I tried making a double integrator instead of a single integrator for CARM_B, since that would allow me to make a complex zero pair which could help win back some phase. I also tried just straight copying FM1 from CARM into CARM_B, so that it could be turned off for the ALS part of the loop, but left on for the REFL part, but that didn't work very well.  Like Rana and I saw last Friday, we really need the REFL signal to have a true integrator, to force the PDH signal toward zero, before we can complete the transition.

I moved the cavity pole compensator's zero back up to 120 Hz, since that was what had worked on Saturday night.  That helped me get farther before running into gain peaking problems at ~50Hz.  This is because, as seen in my simulation earlier tonight, I win back some gain margin by having the pole compensator more closely matched with the pole frequency.

I've been turning off both FM1 and FM2 in CARM and DARM.  I think this is helping a lot, when I can get far enough to do so.  I don't want to turn off the second boost until after I'm about 50/50 on REFL.  (When  I have that much REFL, with the true integrator, the PDH signal sticks to zero).

I tried once turning off the bounce/roll filters for CARM and DARM, rather than the FM1 boost, since the bounce roll filters eat lots of phase, but I got pushed off resonance.  I think not having that focused boost may have made my overall RMS larger, which caused me to randomly jump too far outside of the good PDH range.

Early on in the evening, I turned off the MC2 violin filters in the ETM LSC-SUS filter banks, since I am actuating on only the ETMs tonight. However, I saw a violin mode ring up at ~642, which showed up in POX but not POY.  This was causing up-conversion, beating against the 40-50Hz buzzing from the IR resonance.   The MC2vio1,2 filter covers this frequency (because it's an absurdly wide notch), but the EXYvio1 filter does not.  There seems to be some confusion on the wiki as to what the ETMX violin mode frequency is - it says 631 (638??).  The notch that is in the EXYvio1 filter is for 631 Hz, but this is not correct.  DAYTIME self: Make the MC2 violin filter smaller than 40Hz(!) wide, and move the ETMX notch up to the correct frequency.  For tonight, I just turned back on the MC2 filter, and the mode has rung down.

Idea:  MICH offset, or ETM misalignment, enough to keep the power recycling low-ish, so that the CARM cavity pole doesn't come down too far in frequency?  Daytime brain should think about this.

  11135   Wed Mar 11 19:48:25 2015 KojiUpdateGeneralFOL troubleshooting

There is a frequency counter code written by the summer student.
The code needed some cleaning up.
It's still there in /opt/rtcds/caltech/c1/scripts/FOL as armFC.c

This code did not provide unified way to send commands to the FCs.
Therefore I made a code to change the frequency range of the FCs
by removing unused variables and instructions, adding more comments,
adding reasonable help messages and trouble shooting feedbacks.

Obviously these codes only run on domenica (raphsberry Pi host)


change_frange : change the freq range of the frequency counter UFC-6000

Usage: ./change_frange DEVICE VALUE
    DEVICE: '/dev/hidraw0' for Xarm, '/dev/hidraw1' for Yarm
0 - automatic
1 -    1MHz to   40MHz
2 -   40MHz to  190MHz
3 -  190MHz to 1400MHz
4 - 1400MHz to 6000MHz

  11134   Wed Mar 11 19:15:03 2015 KojiSummaryLSCROUGH calibration of the darm spectrum during the full PRFPMI lock

I made very rough calibration of the DARM spectra before and after the transition for the second lock on Mar 8.

The cavity pole (expected to be 4.3kHz) was not compensated. Also the servo bump was not compensated.

[Error calibration]

While the DARM/CARM were controlled with ALS, the calibration of them are provided by the ALS phase tracker calibration.
i.e 1 degree = 19.23kHz

This means that the calibration factor is

DARM [deg] * 19.23e3 [Hz/deg] / c [m Hz] * lambda [m] * L_arm [m]
= DARM* 19.23e3/299792458*1064e-9*38.5 = 2.6e-9 *DARM [m]

[Feedback calibration]

Then, the feedback signal was calibrated by the suspension response (f=1Hz, Q=5)
so that the error and feedback signals can match at 100Hz.

This gave me the DC factor of 5e-8.

The spectra at 1109832200 (ALS only, even not on the resonance) and 1109832500 (after DARM/CARM transitions) were taken.
Jenne said that the whitening filters for AS55Q was not on.

Attachment 1: 150308_DARM_ROUGH_CALIB.pdf
  11133   Wed Mar 11 18:02:02 2015 JenneUpdateLSCCARM and DARM loops marginal

I have looked at the CARM and DARM RF loops, assuming the loop shapes that we've been using, and it pretty much looks like a miracle that we were ever able to make the transition.  The CARM and DARM loops are very marginal.

The ALS CARM loop was already pretty close to marginal, but we lose an extra 12 degrees of phase with the REFL loop:

  • -4 deg because REFL has analog AA, but ALS does not.
  • -6 deg because FM1 is designed to have minimal phase loss at 100Hz, but the REFL integrator is not.
  • -2 deg because the cavity pole compensator must have a zero at finite frequency.

However, if our cavity pole compensator's zero frequency is too low, we get all of that phase back, at the sacrifice of 2dB of gain margin at both ends of the phase bubble.

I looked at an Optical simulation to check what the cavity pole frequencies are expected to be, with the losses that we've measured.  In both cases, I assume the Xarm has about 150ppm of loss.  The DARM cavity pole is about 4.5kHz no matter what the Yarm loss is.  The CARM cavity pole is about 172 Hz if the Yarm has 500ppm of loss, or 120 Hz if the Yarm has 200ppm of loss.

In the plots below, I use a CARM cavity pole frequency of 150 Hz, to roughly split the difference.

Edit, 13Mar2015, JCD:  Rana points out to me that I was using from Foton the analog design strings, without including the fact that these are actually digital filters. This means that I am missing some phase lag.  Eeek.

The ALS loop includes:

  • Actuator
    • 3 16kHz computation cycles (includes computer hops)
    • Pendulum
    • Analog anti-imaging
    • Digital anti-imaging
    • 1 64kHz computation cycle
    • Violin filters: ETM 1st, 2nd, 3rd order notches
  • Plant
    • Flat, not including the cavity pole at ~17kHz
  • Sensor
    • Closed loop response of phase tracker
    • Digital anti-aliasing
    • 1 64kHz computation cycle
    • 1 16kHz computation cycle
  • Servo (CARM filter bank)
    • FM1
    • FM2
    • FM3
    • FM5
    • FM6
    • 1 16kHz computation cycle

The REFL loop includes:

  • Actuator
    • 3 16kHz computation cycles (includes computer hops)
    • Pendulum
    • Analog anti-imaging
    • Digital anti-imaging
    • 1 64kHz computation cycle
    • Violin filters: ETM 1st, 2nd, 3rd order notches
  • Plant
    • 150 Hz cavity pole
  • Sensor
    • Analog anti-aliasing
    • Digital anti-aliasing
    • 1 64kHz computation cycle
  • Servo (CARM_B filter bank and CARM filter bank)
    • Cavity pole compensator
    • Integrator (20:0)
    • FM2
    • FM3
    • FM5
    • FM6
    • 1 16kHz computation cycle

The first plot is the case of perfectly matched cavity pole and compensating zero (150Hz, with compensator having 3kHz pole):

This next version is the case where the compensating zero is a little too low, which is the case I think we have now:

The last plot is a DARM loop.  Everything is the same, except that the RF plant has a 4.5kHz pole, and no compensation:

Attachment 1: CARMloop_ALSvsREFL_fcav150_fcomp150.png
Attachment 2: CARMloop_ALSvsREFL_fcav150_fcomp80.png
Attachment 3: DARMloop_ALSvsAS55_fcav4500_nocomp.png
  11132   Wed Mar 11 15:35:38 2015 manasaUpdateGeneralWaking up the PDFR measurement system

I was around the 1Y1 rack today. Trials were done to get the PDFR of AS55.


[EricG, Manasa]

We woke up the PDFR measurement setup that has been sleeping since summer. We ran a check for the laser module and the multiplexer module. We tried setting things up for measuring frequency response of AS55.
We could not repeat Nichin's measurements because the gpib scripts are outdated and need to be revised. 

PDFR diode laser was shutdown after this job.


  11131   Wed Mar 11 13:54:18 2015 SteveUpdateGeneraltemporaly storage in the east arm

Green glass for aLIGO OMC shield is temporarly stored in the inside of the Y-arm.

Attachment 1: greenG.jpg
Attachment 2: EastArm.jpg
  11130   Tue Mar 10 20:08:23 2015 ericqUpdateCDScdsRampMuxMatrix Backported to 40m RCG

I have successfully backported the cdsRampMuxMatrix part for use in our RCG v2.5 system. This involved grabbing new files, merging changes, and hacking around missing features from RCG 2.9. 

The added/changed files, with relative paths referred to /opt/rtcds/rtscore/release/src/, are:

  • M include/drv/tRamp.c
    • New C functions to directly report current ramping value and ramping state 
  • M epics/util/feCodeGen.pl
    • Added if statements to main simulink parser to properly handle the part
  • AM epics/util/lib/RampMuxMatrix.pm
    • New Perl script that writes the frontend code for a given ramp matrix
  • A epics/util/mkrampmatrix.pl
    • New perl script that creates the default MEDM screen
  • A epics/simLink/lib/cdsRampMuxMatrix.mdl
    • Simulink block for the part
  • M epics/simLink/CDS_PARTS.mdl
    • Added block and doc for the part (which is missing an underscore in its definition of EPICS field names)

[A means the file was added, M means the file was modified]

Most of the trouble came from the EPICS reporting of the live ramping value and ramping state, since this depended on some future RCG value masking function. I had to rewrite the C-code writing perl script to define and update these EPICS variables in a more old-school way. 

This leaves us vunerable to the fact that a user/program can directly write to the live matrix element and ramping state, which would cause bad and unexpected behavior of the matrix.

So, when using a ramping matrix: NEVER WRITE to [MAT]_[N]_[N] as you would for a normal matrix. Use [MAT]_SETTING_[N]_[M] and trigger [MAT]_LOAD_MATRIX.

Similary, [MAT]_RAMPING_[N]_[N] is off limits. 

I tested the new part in the c1tst model. There are two EPICS input (TST-RAMP1_IN and TST-RAMP2_IN) that are the inputs to a 2x2 ramp matrix called TST-RAMP, and the outputs go to two testpoints (TST-RAMP1_OUT and TST-RAMP2_OUT) and two epics outputs (TST-RAMP1_OUTMON and TST-RAMP2_OUTMON). You can write something to the inputs from ezca or whatever, and use the C1TST_RAMP.adl medm screen in the c1tst directory to try it out. The buttons turn red when you've input a new matrix, yellow when a ramp is ongoing and green when the live value agrees with the setting. 

At this time, I have not rebuilt any of our operational models in search of potential issues.

I have created backups of the files I modified, such that a file such as feCodeGen.pl was renamed feCodeGen.40m.pl, and left next to the modified file. I am open to more robust ways of doing the backup; since our RCG source is an svn checkout of the v2.5 branch (with local modifications, to boot), I suppose we don't want to commit there. Maybe we make a 40m branch? A seperate repo? 

  11129   Tue Mar 10 19:59:13 2015 KojiFrogsCamerasMessage from the IFO

  11128   Tue Mar 10 17:48:07 2015 manasaUpdateGeneralFOL troubleshooting

[Koji, Manasa]

This problem was solved by changing the Frequency Counter range settings.

Frequency counter automatic range setting has been modified and now the range can be manually set depending on the input frequency. New codes have been written to do this. The scripts will be polished and wrapped up shortly.


Figuring out the problem with frequency counter readouts:

RF amplifier box:
The frequency counter was setup to read the beat frequency after amplification of the RFPD signals. The output as seen on the frequency counter screen as well as the epics values was intermittent. Also, locking the arms and changing the end laser frequencies did not change the frequency counter outputs. It looks like the RF amplifier is oscillating (Oscillating frequencies were ~107 MHz and 218 MHz) and the input circuit needs to be modified and the connections need better insulation.

As of now, I have connected the RFPD outputs to the frequency counter sans any amplification and we are able to get a readout of the beat frequency at > 40MHz (Frequency counter requires much higher amplitude signals for frequencies lower than that).

The frequency counter has 4 ranges of operation: 
Range 1 : 1 - 40MHz
Range 2: 40 - 190MHz
Range 3: 190 - 1400MHz  
Range 4: 1400 - 6000MHz

I set up the beat frequency readout in various configurations to troubleshoot and have recorded my observation (attachments). The amplifiers in all cases is just a single ZFL-500LN.

There seems to be a problem with the RF amplifier and the frequency counter when they are set together. I am not able to figure it out and stuck right here sad

Attachment 1: schematic for readout and corresponding observations

Attachment 2: Oscilloscope screen snapshot for schematic 3

Attachment 3: Spectrum analyzer screen snapshot for schematic 3

More info: RFPD used is Thorlabs FPD310 and frequency counter is Mini Circuits UFC-6000. The RF amplifier has decoupling capacitors soldered across the power supply.


  11127   Tue Mar 10 14:47:05 2015 manasaUpdatePSLPMC relocked

PMC was locked in a bad state. FSS slow actuator adjust was at ~ -0.7 and PZT voltage at ~45.

So I set these right by moving the appropriate sliders and relocked it. FSS slow actuator adjust brought back to zero and PZT voltage ~115. PMC trans after relock is 0.789.

  11126   Tue Mar 10 03:37:03 2015 ericqUpdateLSCLocking efforts

[Q, J]

Not much luck locking tonight; we made the RF transition to CARM numerous times, but it never lasted more than a minute or so. We were able to take a couple of loop and spectrum measurements as we transistioned. 

Here are some spectra showing the noise evolution of CARM_IN1 and DARM_IN1 as we start to transition CARM to RF. We did not manage to grab spectra while CARM was RF only; we can go back in the DQ to find some data. 

As we transition, our phase bubble is shrinking, which may explain our poor stability. On the following plot, I actually mistyped the legend. The cyan trace is ALL RF. I'm not sure why we have a 1/f^2 shape from 100->200Hz. 


We adjusted the pole compensation frequency by looking at REFL11/ALS during a CARM swept sine measurement, the -3db/-45degree point looked more like 80Hz. Strangely, the compensated REFL11 signal appears to lag the ALS signal around the UGF. Maybe this is a loop effect? 

In terms of practical improvements, I've written a script that reliably transitions from POX/POY IR lock to ALS CARM/DARM lock already on resonance. This is saving us a bunch of time. I've svn'd the new ALS script and the new carm_cm_up that uses it. 

We looked into the odd oplev behavior as well. We had earlier seen what looked like railed values on the FM output medm screen (which seemed unexpected for an AC coupled loop), but dataviewer showed it was actually ringing/railing at some 10+Hz as the oplev beam fell off the QPD. The ringing continues even after the quadrant values stop crossing zero, so I think it may be the filters themselves misbehaving. Why there is new behavior here is still beyond me. 

We lost a fair bit of time to a fussy mode cleaner tonight; there was a good 45 minute stretch where it refused to lock for more than a minute or so, the PC drive angriliy never falling below 5. The thing I changed when it started working was using the fast C1:IOO-MC_F channel instead of the slow C1:IOO-MC_FAST_MON as a readback for the FSS input offset; oddly there is a DC difference between the two. This has resulted in a FSS offset of ~4.2, whereas it was previously ~1.8. After this change, the PC drive fell to ~1.0 levels, and the IMC has been mostly ok. 

Given our problems stabilizing the RF lock, we attempted to give the FOOL path a shot, since we now had a better idea of the neccesary REFL11 gain. In short, no luck. Every attempt to use some RF signal just disturbed the lock further. We didn't really pursue it too much after a couple of attempts showed little promise. 

Attachment 1: 2015-03-10_rfCarmOLG.png
Attachment 2: 2015-03-10_rfTransitions.png
  11125   Mon Mar 9 18:10:59 2015 JenneUpdateASCOplev filters re-copied

Back on Feb 20th (elog 11056) Q replaced all of our oplev parts with the aLIGO version. 

Unfortunately, after this it has seemed like there was something not quite right with the optical lever servos.

  • When we would restore kicked optics, after the osem rms values come down the scripts try to engage the optical levers.  This would often kick and ring up the optics (I've seen this with ETMX and ETMY, and once or twice with the beam splitter)  Not good.
  • Sometimes, if the optic wasn't kicked, it would oscillate.  I would see this in particular with ETMY, by seeing the green transmission at the PSL table oscillating.
  • Q noticed that sometimes when the oplevs' outputs were turned off, the outputs were railed at the limiter values.

Since, when the models were changed which gave us an extra underscore in the oplev names, Q did a find-and-replace in the foton text files, I was worried that this might have broken things.  I'm not entirely sure how it would have broken them (I didn't see any difference in a diff), but I've heard enough horror stories about the delicacy of the foton text files.

Anyhow, I opened the last archived foton files from just before Q made the change, and copy-and-pasted the design strings from the old filter banks to the new ones.  Hopefully this fixes things.

ELOG V3.1.3-