40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 71 of 344  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  9534   Tue Jan 7 23:24:41 2014 JenneUpdateGeneralIFO plan, list o' things to do

It seems that the most important short-term task we have right now is to figure out what our PRC length is, and what our tolerance from nominal is.  Gabriele and EricQ are going to work on that tomorrow.  If our PRC is of a length that we can't do anything useful for full IFO locking, we need to open up and fix it sooner rather than later.

While we're in there, we need to also put a baffle on the back side of the PRM cage, to protect the OSEMs from stray light.  Den and I discovered before Christmas that turning off the OSEM and OpLev damping to the PRM (while using the POP QPD for ASC) significantly reduced the power fluctuations in the PRC.  We still had arm power fluctuations, but I believe those are likely because our ALS system can't hold an arm precisely at full resonance.  So, putting a black glass baffle with ~2 inch aperture right up against the OSEMs should help a lot.  This week, I'll ask Steve to make me a quickie to-scale cardboard version of the baffles that he has had cut, so I can try securing it to the dirty suspension cage that we have out.  I will also check to make sure I have seen with my own eyes the baffles that I need, and copper wire to tie it to the cage.

Other, lower-priority things that we should do eventually:

* Steve, please find another razor beam dump for the WFS reflections - Rana and I used one of the ones that was there for reflection off the 2 inch lens in the MC refl path (replacing the aluminum dump that has been there for ages).  We also need to label all of our razor dumps with their purpose, with a label on top, so we remember not to remove dumps that are actually in use.

* At some point, we should change the one remaining steering mirror in the main PSL path that is aluminum, to a steel Polaris ("Polanski" or "Polish") mount.  For now, we should just make sure we have one handy.  Hopefully this will help reduce the PMC transmission drift that we see.

* Steve, in the morning sometime this week, can you please do a test of the drift of the IOO QPDs?  We'd like to see a trend that is maybe 30 or 60 minutes long of the QPD signals.  First 10 minutes, all lights in IFO room off.  Then, 10 minutes with the lights in the PSL on.  Then, the rest of the time the PSL lights off.  We want to see if these are hot enough to be causing a big temperature change in the PSL box, which may then be causing some optics to drift.

* QPD code in the simulink models (trans QPDs, but also OpLevs, and anywhere else we do normalization) needs to have anti-divide-by-zero protection.  I'll take care of this, it should be a quick copy of what we have elsewhere in the simulink code.

* Note to self for the future, instead of doing a dither alignment for the ASS for the arms, we can use the IP POS and IP ANG, as well as end transmission QPD signals.  However, for now, the ASS is working just fine.

* We want to go back to the idea of putting a lens into the in-vac IP ANG path, to avoid the clipping that Manasa and I were seeing tonight.  We want something of order 2inch diameter, 1meter focal length.  The material doesn't matter, but we do want it AR coated for 1064nm on both sides.  We also need to make sure that we could use a fixed 2 inch in-vac mirror mount, or something, to hold this lens.  If that won't work, we need to come up with another plan.  Manasa is working on thinking about precisely what lens we want to buy for a nice guoy phase telescope for IPANG, so we'll buy a lens after she puts her conclusions in the elog.

* An idea for the MC spots plot that Rana had was to plot the beam tilt and translation, rather than the raw spot positions on the mirrors.  The point of this would be to make it easier to see what the output beam from the MC looks like.  For MC pointing, we should also think about what our actual tolerances are.  The biggest thing is that we need to get through the Faraday without being too close to any edge, and also the REFL beam needs to come back through without clipping.  For now, we're just visually checking that the POP beam and the REFL beam both look unclipped since we don't have access to good camera views of either side of the Faraday.

  9538   Wed Jan 8 13:46:39 2014 JenneUpdateGeneralIFO plan, PRM baffle

Quote:

While we're in there, we need to also put a baffle on the back side of the PRM cage, to protect the OSEMs from stray light.  Den and I discovered before Christmas that turning off the OSEM and OpLev damping to the PRM (while using the POP QPD for ASC) significantly reduced the power fluctuations in the PRC.  We still had arm power fluctuations, but I believe those are likely because our ALS system can't hold an arm precisely at full resonance.  So, putting a black glass baffle with ~2 inch aperture right up against the OSEMs should help a lot.  This week, I'll ask Steve to make me a quickie to-scale cardboard version of the baffles that he has had cut, so I can try securing it to the dirty suspension cage that we have out.  I will also check to make sure I have seen with my own eyes the baffles that I need, and copper wire to tie it to the cage.

Steve may actually be onto something with the clamps that he had made a year and a half ago.  These clamps hold the glass, and then clamp to the base of the suspension cage.  Not the table, but the base of the suspension cage. The drawings are in elog 6344.  I'm not sure that the 1/4-20 holes in the clamp things are exactly where we'll want them, but we should be able to just dog it down to the base of the suspension.  I need to check this, but it may be even easier than tieing the glass to the cage.

Also, something to think about is that the earthquake stop screws extend backwards farther than the OSEMs.  I'm not sure anymore if we have shorter 1/4-20 earthquake stops around (if we do, they should be in the cleanroom shelves), but if we can't swap those out, they'll limit how close we can get to the OSEMs. 

Here's an overhead photo from 6 Sept 2012:

PRMcage_6Sept2012.JPG

  9556   Wed Jan 15 13:05:30 2014 JenneUpdatePEM4.4 EQ in Fontana, CA

It looks like there was a 4.4 magnitude earthquake near Fontana, CA around 1:30am today.  This tripped all of the suspension watchdogs, which Q has just now re-enabled. 

  9558   Wed Jan 15 18:42:57 2014 JenneUpdateASCPOP ASC QPD offline for a few hours this afternoon

I was in the lab, near the south end of the ITMX oplev table, looking for something, and I bumped the POP ASC QPD's power supply.  I thought that it was fine, but did not adequately check it.  When EricQ asked me just now about why the PRC is so wobbly today, I checked, and the power for the QPD wasn't properly connected (it's kind of a crappy connector, that if you nudge, contacts or loses contact).  Anyhow, I restored power to the QPD, and the PRC looks a little more stable now.  My fault for not checking more carefully, and my apologies to Q and Gabriele for their frustrations this afternoon.

  9562   Tue Jan 21 17:26:59 2014 JenneSummaryVACRebooted RGA computer and reset RGA settings

[Jenne, Steve]

Steve noticed that the RGA was not logging data and that not all the correct connection lights were on, and he wasn't able to run the "RGAset.py" script (in ...../scripts/RGA/) that sets up the proper parameters. 

I looked, and the computer was not mounting the file system.  I did a remote shutdown, then Steve went in and pushed the power button to turn the machine back on.  After it booted up, it was able to talk to the file system, so I started ..../scripts/RGA/RGAset.py .  The first 2 times I ran the script, it reported errors, but the 3rd time, it reported no communication errors.  So, now that the computer can again talk to the file system, it should be able to run the cronjob, which is set to take data at 4am every day.  Steve will check in the morning to confirm that the data is there.  (The last data that's logged is 22Dec2013, 4am, which is right around when Koji reported and then fixed the file system).

 

 

  9563   Tue Jan 21 19:41:59 2014 JenneUpdateElectronicsRF distribution box power button fail

Rana, Gabriele and I are trying to measure the FSR of the PRC (elog about that later), and we turned off the power to the RF generation box so that we could switch cables at the EOM combiner.  However, as in elog 9101, the power button won't latch when we try to turn the power back on.  All 3 of us tried, to no avail.  For our measurement, poor Gabriele is standing holding the button pushed in, so that we can have some RF sidebands. 

Tomorrow, we'll have to pull the RF generation box, and put in a better switch.

  9567   Wed Jan 22 18:17:46 2014 JenneUpdateCDSfb timing was off

Since this morning, the fb's timing has been off.  Steve pointed it out to me earlier today, but I didn't have a chance to look at it until now. 

This was different from the more common problem of the mx stream needing to be restarted - that causes 3 red blocks per core, on all cores on a computer, but it doesn't have to be every computer.  This was only one red block per core in the CDS FE status screen, but it was on every core on every computer. 

The error message, when you click into the details of a single core, was 0x4000.  I elog searched for that, and found elog 6920, which says that this is a timing issue with the frame builder.  Since Jamie had already set things on nodus' config correctly, all I did was reconnect the fb to the ntp: 

fb$ sudo /etc/init.d/ntp-client restart

As in elog 6920, the daqd stopped, then restarted itself, and cleared the error message. It looks like everything is good again.

I suspect (without proof) that this may have to do with the campus network being down this morning, so the computers couldn't sync up with the outside world.

  9568   Wed Jan 22 20:00:41 2014 JenneUpdateGeneralVENT GO!

Steve, please begin the vent!!

[EricQ, Jenne]

We have followed the pre-vent checklist, and done everything except check the jam nuts (which Steve can do in the morning).

We are ready to vent, so Steve, please begin bringing us up to atmosphere first thing in the morning.

Here is a copy of the list, from the wiki:

 

 

  • Center all oplevs/IPPOS/IPANG
  • Align the arm cavities for IR and align the green lasers to the arms. (Green powers were both ~0.8.  We only touched the Xend PZTs remotely, did not touch Yend).
  • Make a record of the MC pointing
  • Align the beam at the PSL angle and position QPDs (Did not need doing, left QPDs as-is so we keep our long-term trend.)
  • Reduce input power by touching wave plate on the PSL table BEFORE THE PMC.  (HWP was at 269degrees, now at 3 hundred something to make power just before PSL shutter 90mW)
  • Replace 10% BS before MC REFL PD with Y1 mirror and lock MC at low power.
  • Close shutter of PSL-IR and green shutters at the ends
  • Make sure the jam nuts are protecting bellows
  •  

     

    Attachment 1: IFOstatus_lowPower_preVent.png
    IFOstatus_lowPower_preVent.png
      9598   Tue Feb 4 23:01:24 2014 JenneUpdateGeneralReady for pump down??

     

     This sounds great! The only suggestion that I have is for checking POP. If you have the beam on the camera, you can hold a card in front of each mirror, and find out where the edge of the beam is. Introduce the card from the side, and watch for the point where you just start to see the beam on the camera be obstructed. Repeat for the other side, and you have an idea of the centering of the beam. 

    I think this is most important for the in-vac mirrors, since the beam is large-ish, and we have to hit both steering mirrors at ~45 degrees.

      9610   Fri Feb 7 13:00:52 2014 JenneUpdateGeneralIn-Vac Alignment

    Quote:

    I then used the same settings as in ELOG 9554, except I used -1s instead of +1s for the POP110I trigger matrix elements. (I'm not sure why this is different, but I noticed that the PRC would lock on carrier with positive entries here, so I figured we wanted the peaks with opposite sign).

     Nice work!!  As with all the other RF PDs, POP110's phase likely needs tuning.  You want POP110 (and POP22) I-quadratures to be maximally positive when you're locked on sidebands, and maximally negative when locked on carrier.  What you can do to get close is lock PRC on carrier, then rotate the POP phases until you get maximally negative numbers.  Then, when locked on sideband, you can tweak the phases a little, if need be.

      9616   Mon Feb 10 16:02:12 2014 JenneUpdateGeneralPRM oplev clipped in vacuum

    The PRC (locked on carrier so far today), is pretty wobbly.  It'll stay locked on carrier, but it's wobbling.  The ASC was over-ridden during the vent.  While I was looking around for that, I noticed that the PRM oplev sum is very low. 

    I went into the lab, and turned off / blocked all oplev beams except the PRM beam.  I can't tell what it's clipping on, but there is definitely some red glow in the BS chamber (not as much as the stuff that's coming from the ITMY or SRM oplev hitting a tip tilt suspension - that giant spot went away when I turned off the ITMY/SRM oplev laser).  The beam going into the vacuum is nice and strong, but the beam coming out is very weak, and has a horizontal line of scatter through it, like it's clipped somewhere in pitch.  The PRM oplev sum is currently ~150 cts, when it should be closer to 2,000.

    Screenshot-Untitled_Window-1.png

    So far, this seems to be livable, but it's definitely disappointing. 

      9617   Mon Feb 10 16:20:28 2014 JenneUpdateGeneralPRM QPD recentered

    In an effort to stop the PRC from wiggling around so much, I recentered the POP QPD after maximizing the POPDC power when locked on carrier.  The beam was basically off the QPD in yaw, and at half-range in pitch.

      9619   Mon Feb 10 18:59:25 2014 JenneUpdateASCPRM ASC better, but not great yet

    I have turned off the 3.2Hz res gains in the PRC ASC loops, since those seem to make the loops unstable. 

    Right now the pitch gain is -0.001, with FM1,3,9 on.  Yaw gain is -0.004, with FM1,3,9 on. 

    Pitch gain can't increase by factor of 2 without oscillating. 

    I tried to take transfer functions, but I think the ASC situation is really confusing, since I have OSEM damping, oplev damping, and this POP QPD damping on the PRM.  It's hard to get coherence without knocking the PRC out of lock, and it keeps looking like my gain is 0dB, with a phase of 0 degrees, from ~1 Hz to ~10 Hz.  Outside that range I haven't gotten any coherence.  Moral of the story is, I'm kind of puzzled. 

    Anyhow, as it is right now, the ASC helps a bit, but not a whole lot.  I increased the trigger ON value, so that it shouldn't kick the PRM so much.  I wish that I had implemented a delay in the trigger, but I'm not in the mood to mess with the simulink diagrams right now.

      9626   Wed Feb 12 11:57:55 2014 JenneUpdateLSCMusings on RFPDs

    [Rana, Jenne, Manasa]

    We looked at the I vs. Q separation in several of the Refl PDs, while driving the PRM, while the  PRMI was locked on sidebands.

    For REFL 55, we adjusted the demod phase to try to minimize the peak in the Q signal, and were only able to get it to be about 1/10th the size of the I peak.  This is not good, since it should be more like 1/100, at least.

    For both REFL 11 and REFL 165, we were able to get the Q peaks to less than 1/100 of the I peak height. 

    We changed the REFL55 phase from 17 to 16, and the REFL165 phase from -160.5 to -162.5. 

    Since we believed that we had done a good job of setting the demod phase for REFL165, we used it to also check the balance of BS/PRM for MICH locking.  I drove the BS with an arbitrary number (0.5), which creates a peak in the I phase of REFL165, and then I put in a drive on the PRM and tweaked it around until that peak was minimized.  I came up with the same ratio as Koji had last Friday:  BS=0.5, PRM=-0.2625.  (The old ratio we were using, up until ~December when we started locking MICH with the ITMs, was BS=0.5, PRM=-0.267). 

    Also, while we were locked using REFL55 I&Q, we noticed that the other REFL PDs had lots of broadband noise in their I signals, as if some noise in the REFL55 diode is being injected into the PRM, that we are then seeing in the other PDs. 

    Some checks that we need to do:

    * Inject a calibration line, set all the peak heights equal, and look at the noise floors of each PD.

    * Use the calibration line to calibrate the PDs (especially REFL165) into meters, so that we know that it's noise is low enough to hold the PRC through the CARM offset reduction.

    * Check out the state of the transmission QPDs - what is their noise, and is it good enough to use for holding the arms after we transition from green beatnote locking?  Does the whitening switching do anything?  What is the state of the whitening?

      9629   Wed Feb 12 19:37:05 2014 JenneUpdateSUSclipping removed from PRM oplev

    I'm not happy with the beam position on that first lens, but since it's so crazy in the BS chamber, and the PRM oplev has something like 5 in-vac steering mirrors, I'm hesitant to suggest that we do anything about it until our next vent.  But we should definitely fix it.

      9630   Wed Feb 12 19:47:40 2014 JenneUpdateLSCCalibrated REFL signals

    I calibrated the REFL signals to meters from counts.  The I-phase signals all line up very nicely, but the Q-phase signals do not at all.  I'm not sure what the deal is.

     I locked  the PRMI on sidebands, and drove the PRM.  I looked at the peak values at the drive frequency in the REFL signals, and used that as my "COUNTS" value for each PD. 

    I know the PRM actuator calibration is 19.6e-9 (Hz/f)^2 m/ct , so if I plug in my drive frequency (564 Hz, with the notch in the PRC loop enabled), and multiply by my drive amplitude in counts, I know how many meters I am pushing the PRM.  Then, to get a meters per count calibration, I divide this calibration number (common for every PD) by the peak value in each PD, to get each signal's calibration.

    As a side note, I also drove MICH, and tried to use this technique for the Q-phase calibrations, but neither calibration (using the PRCL drive nor the MICH drive) made the Q-phase signals line up at all.

    At least for the I-phase signals, it's clear that REFL33 has more noise than REFL11 or REFL165, and that REFL55 has even more noise than REFL33. 

    Here are the calibration values that I used:

     

    PD m/ct calibration
    REFL11 I 1.71e-13
    REFL11 Q 2.05e-11
    REFL33 I 1.22e-12
    REFL33 Q 3.80e-11
    REFL55 I 9.54e-13
    REFL55 Q 6.29e-12
    REFL165 I 6.98e-14
    REFL165 Q 8.63e-13

     

    Attachment 1: CalibratedUsingPRMdrive.pdf
    CalibratedUsingPRMdrive.pdf
      9635   Thu Feb 13 22:27:54 2014 JenneUpdateLSCPRMI locked on REFL 33 I&Q

    [Jenne, Koji]

    I was able to get the PRMI locked on REFL33 I&Q, but it wasn't overly stable, since there is so little separation between the MICH and PRCL signals in that PD. 

    We have already adjusted the phase to maximize PRCL in the I-phase.  Since MICH is ~45 degrees separated from PRCL, there is some projection of MICH in the I-phase, and some in the Q-phase. 

    To remove this MICH component, I locked the PRMI on REFL55, and drove MICH.  I looked at REFL33I at the CARM filter bank input (as just a dummy location to get a signal into DTT).  I then added REFL33Q to the CARM row of the input matrix, to try to get the MICH line minimized.  I then used these values for PRCL, and used just REFL33Q for MICH, and re-locked the PRMI.  The PRMI was much more stable and happy. 

    The input matrix values that I used were:

    MICH:  REFL33Q = -0.487, Servo Gain = -20.0

    PRCL:  REFL33I = 1.556, REFL33Q = 1.8, Servo Gain = -0.020

     

    Some locking notes:

    The PRMI is very sensitive to alignment, and the PRM tends to drift away from optimal alignment on a ~1 hour timescale.  When the PRM was not well aligned, it looked like MICH had a locking offset (manifested as non-equally sized blobs at AS).  The MICH offset seemed to go away when we realigned the PRM. 

      9636   Fri Feb 14 00:58:41 2014 JenneUpdateLSCThoughts on Transition to IR

    [Koji, Jenne, EricQ, Manasa]

    We had a short discussion this evening about what our game plan should be for transitioning from using the ALS system to IR-generated error signals. 


    The most fundamental piece is that we want to, instead of having a completely separate ALS locking system, integrate the ALS into the LSC.  Some time ago, Koji did most of the structural changes to the LSC model (elog 9430), and exposed those changes on the LSC screen (elog 9449).  Tonight, I have thrown together a new ALS screen, which should eventually replace our current ALS screen.  My goal is to retain all the functionality of the old screen, but instead use the LSC-version of the error signals, so that it's smoother for our transition to IR.  Here is a screenshot of my new screen:

    Screenshot-Untitled_Window-1.png

    You will notice that there are several white blocks in the center of the screen. From our discussion this evening, it sounds like we may want to add 4 more locking servo paths to the LSC (ALS for each individual arm, and then ALS for CARM and DARM signals).  The reason these should be separate is that the ALS and the "regular" PDH signals have different noise characteristics, so we will want different servo shapes.  I am proposing to add these 4 new servo blocks to the c1lsc model.  If I don't hear an objection, I'll do this on Monday during the day, unless someone else beats me to it.  The names for these filter modules should be C1:LSC-ALS_XARM, C1:LSC-ALS_YARM, C1:LSC-ALS_DARM and C1:LSC_ALS_CARM.  This will add new rows to the input matrix, and new columns to the output matrix, so the LSC screen will need to be modified to reflect all of these changes.  The new ALS screen should automatically work, although the icons for the input and output matrices will need to be updated. 

    The other major difference between this new paradigm and the old, is the place of the offset in the path.  Formerly, we had auxiliary filter banks, and the summation was done by entering multiple values in the ALS input matrix.  Now, since there is a filter bank in the c1lsc model for each of the ALS signals precisely where we want to add our offsets, and I don't expect us to need to put any filters into those filter modules, I have used the offset and TRAMP of those filter banks for the offsets.  Also, you can access the offset value, and the ramp time, as well as the "clear history" button for the phase tracker, all from the main screen, which should help reduce the number of different screens we need to have open at once when locking with ALS.  Anyhow, the actual point where the offset is added has not changed, just the way it happens has. 

    When we make the move to using the ALS in the LSC, we'll also need to make sure our "watch arm" and "scan arm" scripts are updated appropriately.

    As an intermediary locking step, we want to try to use the ALS system to actuate in a CARM and DARM way, not XARM and YARM.  We will transition from using each ALS signal to feed back to its own ETM, to having DARM feed back to the ETMs, and CARM feed back to MC2.  We may want to break this into smaller steps, first lock the arms to the beatnotes, then find the IR resonance points.  Transition to CARM and DARM feedback, but only using the ETMs.  After we've done that, then we can switch to actuating on MC2.  If we do this, then we'll be using the MC to reduce the CARM offset.

    Once we can do this, and are able to reduce the CARM offset, we want to switch CARM over to a combination of the 1/sqrt(transmission) signals.  The CARM loop has a tighter noise requirement, so we can do this, but leave DARM locked to the beatnotes for a while.

    After continuing to reduce the CARM offset, we will switch CARM over to one of the RF PDs, for its final low-noise state. 

    We'll then do a quick swap of the DARM error signal to the AS port (maybe around the same time as CARM goes over to a PDH signal, before the CARM offset is zero?). 

    During all of this, we hope that the vertex has stayed locked. If our 3f sensing matrix elements are totally degenerate when the arms are out of resonance, then we may need to acquire lock using REFL 1f signals, and as we approach the delicate point in the CARM offset reduction, move to 3f signals, and then move back to 1f signals after the arm reflection has done its phase flip.  Either way, we'll have to move from 3f to 1f for the final state.

      9639   Fri Feb 14 12:39:02 2014 JenneUpdatesafetySmoke detector cleaned

    Facilities just came by and cleaned the smoke detector that is above Steve's desk.  It's next to an air vent, so I guess it collects dust more than a "typical" smoke detector.

      9645   Tue Feb 18 14:28:15 2014 JenneUpdateIOOMC unstable - centering spots helped

    As we've been seeing a bit lately, the MC will be locked happily for several hours, but then it will start misbehaving. 

    Today, I measured the spots on the MC mirrors, and found that the MC2 spot was quite far off in yaw (about -3.5 cm).  I recentered the MC2 spot, and then (with the MCWFS on), moved MC1 and 3 until their WFS outputs were close to zero (they had gone up to 100+).  In the ~15 minutes since doing that, the MC refl signal is not oscillating like it was, the transmission is up, and the MC has not unlocked. 

    To reiterate, I did not touch any settings of anything, except the alignment of the MC mirrors to center the MC2 spot, and then offload the WFS.  Next time the MC starts acting up, we should measure the spots, and roughly center them, before messing with any other settings.  Note however, that this is a ~10 minute procedure (including the fact that one spot measurement takes a little less than 5 minutes).  This need not be a several hour endeavour. 

      9646   Tue Feb 18 18:52:08 2014 JenneUpdateLSCALS not locking with LSC

    Koji mentioned to me (and elogged) that he was unsuccessful locking the ALS using the LSC servos.  He suggested I look into this.

    So, rather than just looking at the transfer function between POX or POY and the green beatnotes at a single frequency, I did a whole transfer function.  The point was to see if the TF is flat, and if we get any significant phase lag in the transfer from c1als to c1lsc.  (c1als is running on the IOO machine, so an RFM connection is involved in getting it over to the LSC machine.)

    In the first figure, I have plotted POX vs. Beatnote_PHASE_OUT (ALS error signal, still in the c1als model), and POX vs. ALSX_IN1 (the ALS error signal, after transfer over to the c1lsc model).  You can see that we have a little phase lead in the blue transfer function, and fairly significant phase lag in the red (red is after transfer over to the lsc model).  In the grand scheme of things, the magnitude is fairly flat, however that is not perfectly true - the peaks seen near 50 Hz and 300Hz are repeatable.  The relative phase lag between the "BEATX" version of the signal in the ALS model, and the "ALSX" version of the signal in the LSC model is 15 degrees at 200 Hz, which corresponds to 33 usec.   

    ALSX_POXvsBeatnote.pdf

    The second figure is the same as the first, except for the Yarm.  The relative phase lag between the ALS version of the error signal and the LSC version is 16 degrees at 200 Hz, which is about 35 usec.

    ALSY_POYvsBeatnote.pdf

    As a side note, before trying any ALS locking, I took a spectrum of the beatnote (in the ALS model) while the arms were locked with IR:

    BeatNoteSpectra_ArmsLockedWithIR_28Feb2014.pdf

    To check things, I made sure that I could lock the Xarm ALS using the old ALS system - I was able to do so.  (Has someone put the "watch" script as a constantly-on thing?  It's kind of nice not to have to turn it on, although we'll need to change it to turn off the LSC versions of the servos eventually). 

    Then, I tried locking the Xarm using the LSC system (using only FM5 of the regular LSC-XARM filter bank).  Like Koji, I was not able to acquire lock.  As a next step, I copied all of the LSC-XARM filters into an empty filter module, LSC-XXXDC (the first one on the list underneath LSC-XARM), and copied over the ALS Xarm filters to the LSC Xarm filter bank.  I then tried to acquire lock, but am unable to get it to stay.  Using the ALS system, when you put in a small gain, the beatnote starts to settle down, and as you increase the gain, the beatnote stops moving (as seen on the spectrum analyzer) almost completely.  However, using the LSC system, the beatnote never really stops moving or settles down.  And if I increase the gain, I push the ETM hard enough that I lose green lock.  I have put the regular LSC filters back for now.

    Here is a plot from Foton comparing the FM5 filter modules from the LSC-XARM (regular IR locking) and the ALS-XARM servo.  They are pretty different, and have 10 degrees of phase difference at 200 Hz, because 2 of the 3 poles are complex in the LSC version, while the ALS version is just a single real pole.

    ALSvsLSC_LockingFilters.pdf

    Anyhow, I am declaring it to be dinnertime, and I plan to return in a few hours. Since I put the regular LSC filters back (since I'm going to have to realign after dinner anyway), the IFO should be in its nominal state if anyone wants to come in and play with it.

      9648   Tue Feb 18 23:27:14 2014 JenneUpdateLSCALS not locking with LSC

    It looks like its somehow a discrepancy between the TFs of each error signal, because features are similar, and present, in both error signals.

    ALSX_POXvsBeatnote_withEXCtfs.pdf

      9649   Tue Feb 18 23:55:33 2014 JenneUpdateLSCALS locked with LSC!

    I'm really excited, so I'm posting this, even though I'm still working:

    I currently have ALS locked using the LSC system, and have (by hand, coarsely) found IR resonance!  Hooray!

    I looked at my error signals, as well as LSC-XARM_IN1 with dataviewer, and noticed that the XARM_IN1 signal was crazy when I was using the ALS signal as the error.  I soon realized that this is because there was a non-zero element in the power normalization matrix, and I'm overriding the trigger.  So, I was trying to divide by zero, and was getting crazy numbers.  After zeroing the power normalization matrix element for the Xarm, the XARM_IN1 signal matched the ALSX_OUT, and I was easily able to acquire lock.

    I had already re-transferred over the ALS versions of the filters, so that's what I'm using right now.  Next up (on a 5 minute time-scale) is trying to acquire lock using the regular LSC filters. 

    Oh, also, something I hadn't thought of before dinner:  I am setting the offset of the ALSX filter bank such that the output is centered around zero, so that I can lock, since these are not AC coupled servos.

      9651   Wed Feb 19 01:33:03 2014 JenneUpdateLSCALS locked with LSC!

    I am also not able to lock the ALS using the 'regular' LSC filters.  To figure out what filters were doing what, I made several comparison plots from Foton.

    The first one is the progression of ALS locking, using the filters from ALS-XARM.  FM5 is always engaged, then FMs 2, 3, 6, 7, and 8, and finally FM 10 (the low frequency boost) is engaged.

    ALS_XARM_LockingFilters.pdf

    The next plot is a comparison between the ALS version of the filters, and the LSC-XARM equivalents. 

    ALSvsLSC_AllLockingFilters.pdf

    Finally, just so I remember which LSC filters do what, I made an equivalent of the first plot, but for the LSC filters.

    LSC_XARM_LockingFilters.pdf

    When I try to lock the Xarm ALS using the regular LSC filters, I'm getting an oscillation somewhere, that grows and eventually knocks me out of lock.  It looks from dataviewer to be in the ~few Hz range, but it's hard to see it in DTT, since I don't stay locked all that long once the oscillation starts.  (If I catch it, I can back off the gain and turn off the servo without losing lock, but if I don't turn off the servo, I inevitably push the ETM too hard and lose green lock to the arm.)  I tried engaging the 3.2 Hz resonant gain filter, and it just makes things oscillate sooner, so that's not a solution with the current filter designs. 

    Also, I'm not able to lock the IR using the ALS version of the XARM filters.  I'll have to meditate more on the situation, but the filters seem to be different enough that there's no crossover at this point.

      9652   Wed Feb 19 03:07:22 2014 JenneUpdateLSCALS locked with LSC!

    No more progress tonight.  I am still unable to lock the ALS using the regular LSC filters.  I went back to putting the ALS filters into the LSC filter banks, and locked both arms with ALS, and found their IR resonances. I then held them off resonance, and tried to lock PRMI with REFL 55 I&Q, with no success.  Just before locking the arms, I had redone the whole IFO alignment (lock arms in IR, ASS, lock and align MICH, lock and align PRMI), and the PRMI was flashing very nicely.  I'm not sure why I wasn't able to catch lock, except that perhaps 3 or 6 ALS offset counts isn't far enough away from the IR resonance to make the 1f signals happy. The MC lost lock, which I then took as a sign that it's time to go home. (I was hoping to do a quick PRMI + 2arms, and see that we don't lose PRMI lock.  I was going to catch lock with REFL55, then transition to REFL33, although if I had thought about it before the MC lost lock, I would have tried just catching lock with REFL33).

    I restored the regular LSC filters for the X and Y arms, and locked the arms in IR just to make sure it's all honkey-dory.  Which, it's not quite.  I don't know why, but right now, neither arm wants its boost (FM9) enabled.  It's part of the restore script that FM9 is triggered along with the rest of the filters, but even if I turn on the filters manually, I can turn on all but FM9, and then when I turn on the boost, the arm falls out of lock. Same behavior for both arms.  Anyhow, they lock, and they seem okay modulo the boost not being able to engage.

      9655   Wed Feb 19 11:45:12 2014 JenneUpdateLSCScripts for ALS being modified

    We need to change several scripts for use with the new ALS-in-the-LSC paradigm:

    * Watch arms (to turn off ALS if we lose the beatnote, before pushing optics too hard)

    * Find IR resonance

    * Offset from resonance

    None of these should be difficult, just changing the filter bank names to match the new ones (ex. LSC-XARM rather than ALS-XARM, and LSC-ALSX rather than ALS-OFFSETTER1). 

    So far, I have changed the "find resonance" script (ALSfindIRresonance.py).  I believe, in principle, to first order, that my modifications should work, however I have not yet tested the script.  So.  If you use it, watch the output of the script and ensure it's doing what it ought.  I'll check it after the lunch meeting and update this log entry.  (I changed the name of the "OFSFILT" variable, line 26, and also modified line 114.  Both of those lines have comments on how to revert the changes).

    I have also changed the "offset from resonance" script (ALSchangeOffset.py).  Again, since I'm not locking right now, I have not tested this script either.  So, pay attention if you need to use it, before I check it.  (I changed the name of the OFSFILT variable, and the check which arm logic around line 37.  Again, both of those lines have comments on how to revert the changes.)

      9659   Wed Feb 19 22:47:26 2014 JenneUpdateLSCALS locked using LSC model, Common & Diff transitioned to IR transmission signals

    [Jenne, Koji, Manasa, EricQ]

    Today we successfully locked the ALS using the LSC system, with filters that are good for both the IR PDH and the ALS locking.  We tried PRFPMI, but were unable to hold PRMI lock while the arms were held with ALS.  We combined the ALS signals into common and differential signals, and successfully transitioned over to a combined set of 1/sqrt(TRANS) signals for the common mode part of the lock (differential stayed with ALS). 


    Locking the ALS using filters in the LSC system that are also good for IR PDH

    The biggest difference between the ALS and LSC filters were the ones used for lock aquisition. At Koji's suggestion, I made FM5 of the LSC servos (for X and Y arms) the filter needed for ALS locking.  Then, I made FM4 into a combination of old LSC FM4 and FM5, as well as an inverse of the new FM5, so that when both FM4 and FM5 are engaged, the servo shape is the same as the old LSC.  I left the other LSC filters where they were.  I replaced the FM1 +6dB with the combined integrators (really, just gentle DC boosts) for the ALS, since we were never using this +6dB filter module.  The LSC resonant gain filter for the bounce mode also included a resgain for 18.5 Hz.  I don't know what that was for, and it was eating into phase that I needed, so I removed it.

    The other filter that changed significantly was the Boost filter.  The ALS system had been using more DC gain than the LSC had.  However, the current ALS boost filter (in FM10 of the old ALS servos) was eating too much phase near my UGF.  So, I scooted the whole boost filter to lower frequencies, to give myself some extra phase margin.  The boost was set to "zero history", "zero crossing", with 0.01 tolerance and an 8 second timeout.  Setting it to zero crossing with a low tolerance, rather than just ramping it on, was the key to engaging the boost.

    ALS_newVSoldBoosts.pdf

    I had to be so careful about phase margin, since I lost ~15 degrees of phase at 200 Hz from the lag of going through the RFM network.  This was pretty frustrating, but I don't have a better plan yet, save moving the c1als model and ADC to the SUS machine, which has Dolphin access to the LSC.  I may back off my safety margin, and give myself some gain in the boost back at 10Hz, since we are now seeing too much noise at 10Hz in the closed-loop spectra.  I also "cheated" and lowered my UGF from the ~150Hz it used to be in the ALS model, to 100Hz, where I was closer to the top of the new phase bubble.

    With the new filter situation, I was able to lock the Xarm (the one I was using for design work) with both IR and ALS.  To lock IR, the "restore" script still works. For the ALS, we should put in a separate "restore" script into the IFO_CONFIGURE screen. 

    The ALS locking procedure is as follows:

    * Prepare ALS and green locking.  Green locked to 00 mode, alignment all nice, etc, etc.  Beatnote within 100MHz on spectrum analyzer.  If doing both arms, try to get beatnotes on opposite sides of PSL, to keep crossbeatnotes at higher frequencies, and out of the way.

    * Turn on Watch script.

    * Set LSC parameters (this is where a new restore script will come in handy): 

           * Zeros in RFPD columns of input matrix (i.e. POX and POY).

           * Ones in AUX input matrix elements.

           * Zeros in power normalization matrix rows for arms.

           * All FM triggers for arms set to "Man" for manual.

           * Override main trigger, so that signals are always going through to the servo.

           * Only FM5 engaged in arm servo.

           * Gain of servo set to zero, output on, then engage main LSC master switch.  ETM output on.

    * Clear history in phase tracker.

    * Check sign of gain using + or - 0.1 in the servo.  You'll know if you got it wrong (the ETM will be kicked, and the beatnote will fly around).  If you didn't get it wrong, you probably got it right.

    * Increase gain to about 12 (with correct sign).

    * Engage FM1 (gentle DC boost), FM6,7,8 (resonant gains for stack, bounce, roll)

    * Wait a few seconds for filters to settle, then engage FM9 (boost).

    * Run find IR resonance script.

    * Move off resonance by ~36 counts (12 times the +3 script).  This number comes from trying to be completely off the IR resonance, even when the PRMI was locked.

    * Do whatever locking (ex. PRMI) you set out to do.


     PRFPMI attempt

    After locking both arms with ALS using the LSC system, we attempted to lock the PRMI.  We were able to lock PRMI on REFL55 I&Q, REFL33 I&Q, and REFL55 I&AS55Q before the arms were locked, so we were hoping that we wouldn't have too much trouble.

    We found the IR resonance for both arms, then moved off resonance.  Then, restored the PRM.  For REFL55, Koji coarsely turned the REFL 55 demod phase from 16 degrees to 87, while we were locked on the carrier.  After this, I stepped farther and farther from the IR resonance, since at first I found that our transmitted powers were something like 4, rather than almost zero, so the demod phase may not be totally correct.  

    We were having trouble, so we locked the PRMI on carrier using REFL55 I and AS55 Q, with 1's in both elements in the input matrix.  MICH gain was about -10, PRCL +0.010.  We used this time to tweak up the alignment of the PRMI.  At some point, Koji tweaked the REFL33 demod phase from 124 to 134 degrees.  Then we switched back to sideband locking.  After some trials with REFL55 I&Q, and REFL55/AS55, we went to REFL33 I&Q.  REFL33I->PRCL was 1.556 in the input matrix, and REFL33Q->MICH was -0.487.  No other elements in the input matrix.  MICH gain was reduced to -6, PRCL gain to -0.020.  MICH FMs 3,6,9 triggered, PRCL FMs 2,3,6,8,9 triggered.  We were able to keep short locks on the order of ~10 seconds, but not longer. We played with every parameter we could think of (alignment being good is one of the most important!), but were not able to keep better lock.  The POP spot is moving around a lot, so the PRCL ASC needs to be examined, hopefully tomorrow.

    We started losing the Xarm lock fairly regularly, I'm not sure why, but the Yarm was locked for almost 2 hours straight, held off resonance with ALS!


     ALS Common and Differential, transition to IR control

    We set PRMI aside for the rest of the night, and looked at using ALS to control the arms in common and differential modes. 

    Regular ALS locking procedures were used (see above), with the exception of the AUX input matrix:

      1/sqrt(TRX) 1/sqrt(TRY) ALSX ALSY
    XARM (common) 0 0 +1 -1
    YARM (differential) 0 0 +1 +1

     Since the beatnotes were on opposite sides of the PSL frequency, the common and differential modes look opposite of what you'd expect. 

    We then used the regular find IR resonance scripts running simultaneously, which worked really well to find both arms' IR resonance points.

    I put a 1 count offset in the Xarm servo (which was our proxy for common mode), although in retrospect this should have been +0.5 in ALSX, and -0.5 in ALSY, so that our signals going through the input matrix were at their zero crossings.  Anyhow, this offset put us at about half fringe on both arms (transmissions were about 0.6). 

    Koji set the offsets in the 1/sqrt(trans) filter banks before the input matrix so that they would have zero crossings at this point (avg the IN1, put negative of that value into the offset). 

    We then stepped the input matrix values until our common mode (Xarm) row was:

      1/sqrt(TRX) 1/sqrt(TRY) ALSX ALSY
    XARM (common) -0.7 -0.7 0 0

    We left the differential (YARM) row alone, so that the ALS system would still be controlling the differential degree of freedom.  The values and sign for the 1/sqrt(trans) signals came from a transfer function of dividing the spectra of each error signal and noting the relative gain and sign.

    After we swapped the error signals, we realized that we had to remove the offset from the XARM servo, which is why we should have put the offsets elsewhere in the first place.

    Then, Koji took a spectrum, which is attached to this entry.  We note that the ALS signals are strongly correlated, and mostly common. 


    To Do List

    Going forward, we need to figure out what is going on with the PRMI, and why we're having trouble keeping lock.

    We need to redo the PRCL ASC servo, with the anti-oplev trick that Rana mentioned a week or two ago.

    We need to investigate the degeneracy of REFL165, now that Q's simulation doesn't justify / explain it. 

    Attachment 1: common_diff_ALS.pdf
    common_diff_ALS.pdf
      9661   Mon Feb 24 13:21:00 2014 JenneUpdateElectronicsMeasured REFL165 demod board

    I measured the REFL 165 demod board's I/Q separation. 

    Our 11MHz signal is currently 11.066092 MHz, so I put a signal to the RF input of the REFL165 demod board at 165.992380 MHz (15*11 MHz + 1kHz), with a signal of -13 dBm.

    I then used the SR785 to measure the transfer function between the I and Q output channels. 

    I got 82.7 degrees, at -0.64 dB. (I don't remember now if I had I/Q, or Q/I, not that it really matters). So, it seems that the REFL165 demod board has good separation, and at least isn't totally broken.

      9662   Mon Feb 24 13:40:13 2014 JenneUpdateCDSComputer weirdness with c1lsc machine

    I noticed that the fb lights on all of the models on the c1lsc machine are red, and that even though the MC was locked, there was no light flashing in the IFO. Also, all of the EPICS values on the LSC screen were frozen.

    Screenshot-Untitled_Window-1.png

    I tried restarting the ntp server on the frame builder, as in elog 9567, but that didn't fix things.  (I realized later that the symptom there was a red light on every machine, while I'm just seeing problems with c1lsc. 

    I did an mxstream restart, as a harmless thing that had some small hope of helping (it didn't). 

    I logged on to c1lsc, and restarted all of the models (rtcds restart all), which stops all of the models (IOP last), and then restarts them (IOP first).  This did not change the status of the lights on the status screen, but it did change the positioning of some optics (I suspect the tip tilts) significantly, and I was again seeing flashes in the arms.  The LSC master enable switch was off, so I don't think that it was trying to send any signals out to the suspensions.  The ASS model, which sends signals out to the input pointing tip tilts runs on c1lsc, and it was about when the ass model was restarted that the beam came back.  Also, there are no jumps in any of the SOS OSEM sensors in the last few hours, except me misaligning and restoring the optics.  I we don't have sensors on the tip tilts, so I can't show a jump in their positioning, but I suspect them.

    I called Jamie, and he suggested restarting the machine, which I did.  (Once again, the beam went somewhere, and I saw it scattering big-time off of something in the BS chamber, as viewed on the PRM-face camera).  This made the oaf and cal models run (I think they were running before I did the restart all, but they didn't come back after that.  Now, they're running again).  Anyhow, that did not fix the problem.  For kicks, I re-ran mxstream restart, and diag reset, to no avail.  I also tried running the sudo /etc/init.d/ntp-client restart command on just the lsc machine, but it doesn't know the command 'ntp-client'. 

    Jamie suggested looking at the timing card in the chassis, to ensure all of the link lights are on, etc.  I will do this next.

      9663   Mon Feb 24 15:25:29 2014 JenneUpdateCDSComputer weirdness with c1lsc machine

    The LSC machine isn't any better, and now c1sus is showing the same symptoms.  Lame.

    The link lights on the c1lsc I/O chassis and on the fiber timing system are the same as all other systems.  On the timing card in the chassis, the light above the fibers was solid-on, and the light below blinks at 1pps. 

    Koji and I power-cycled both the lsc I/O chassis, and the computer, including removing the power cables (after softly shutting down) so there was seriously no power.  Upon plugging back in and turning everything on, no change to the timing status.  It was after this reboot that the c1sus machine also started exhibiting symptoms. 

      9664   Mon Feb 24 16:26:14 2014 JenneUpdateCDSNTP fell out of sync on front end machines - fixed

    [Koji, Jenne]

    Koji noticed that the time on the front-end detail screens was not correct, and that the GPS time was not matching up between different models.  Koji ran the following on all front-end machines, and on nodus:

    sudo ntpdate -b -s -u pool.ntp.org

    Now, everything is fine, and every status light on the cds overview screen is green.

      9673   Tue Feb 25 17:27:41 2014 JenneUpdateLSCREFL signals calibrated

    I have recalibrated the REFL signals.

    I first adjusted the demod phases until the I-signals lined up with the I-phase in the sensing matrix plot:

    SensMat_25Feb2014.png

    I then balanced the ITM drives by pushing on -1*ITMX and +1.015*ITMY, and seeing a minimum of MICH actuation in the I-phase of REFL55 (the PD I was locking with).

    I then took a nice long measurement with DTT, and measured the peak heights in I and Q for each REFL diode.  I was driving PRM with 100 cts at 675.1Hz, and ITMX with 1000 cts at 452.1 Hz (and matching ITMY drive, to make pure MICH).  Knowing these numbers, and the actuator calibrations (PRM elog 8255, ITMs elog 8242), I know that I was driving PRCL by ~4.3 pm, and MICH by ~23 pm. 

    For the I-phase calibrations, I find the peak height at the PRCL drive frequency, and divide 4.3 pm by that height.  For the Q-phase calibrations, I find the peak height at the MICH drive frequency, and divide 23 pm by that height.

    This gives me the following calibrations:

      Calibration [picometers / count]
    REFL 11 I    0.15
    REFL 11 Q   21.6
    REFL 33 I    1.06
    REFL 33 Q  209
    REFL 55 I    0.9
    REFL 55 Q   27       
    REFL 165 I    0.1
    REFL 165 Q   11.6

     My calibrated REFL spectra then looks like:

    Calibrated_25Feb2014.pdf

      9674   Tue Feb 25 18:16:22 2014 JenneSummaryLSCEven more violin filters

    A new violin mode at 1303 Hz was ringing up this afternoon.  Rana and I added a notch for this.

    RXA: while the mode at 1303.6 Hz was ringing down, I used the narrowband DTT technique to measure the Q (after turning on the notch in SUS-PRM_LSC). So its another frequency in the PRM (not the BS).

    The time that it takes for 2 -foldings is 652 s, which implies that Q = pi*f*tau = 1.3e6. This seems too high by a factor of ~10, so my guess is that there is still some feedback path happening. The previous bandstop filter was centered around 1285 Hz and seems also weird that the PRM would have 2 violin modes with such different frequencies. Is the mirror rotated around the optic axis such that the standoffs are not at the same height?

    Attachment 1: PRMvio2.png
    PRMvio2.png
      9676   Wed Feb 26 01:49:08 2014 JenneUpdateLSCChanging PRCL offset changes REFL 165 degeneracy

    I have measured the sensing matrix at a variety of PRCL offset values.

    DemodPhaseSeparation.pdf

    During this each measurement, I also took a 20 second average of the POP 2f signals and the ASDC signal:

    POP_AS_PDvalues.pdf

    All of this data was taken during a single lock stretch. 

    If / when I do this again, I want to go out to larger offsets.  I won't take as many points, but I do want to see how far I can go before I lose lock, and what the phase separation looks like at larger offset values (this time, I stopped at +700 counts which is about 0.7nm, to start checking the negative values. MC has been unhappy, so I wasn't able to take very many negative offset values.) 

    I conclude that these sensing matrix measurements do see changes in the phase separation with PRCL length offset (what we saw / said yesterday), but that they do not line up with Q's simulation from this afternoon in elog 9671.

    The simulation says that we shouldn't be seeing large phase changes until we get out to several nanometers, however the measurement is showing that we get large phase chnages with picometer scale offsets.  Yesterday, Rana and I said that the offsets due to RAM were small (of order picometer), and that they were therefore likely not important (elog 9668).  However, now it seems that the RAM is causing significant length offsets which then cause poor MICH/PRCL phase separation.

    To Do List:

    * Confirm MIST simulation with Optickle.

    * Look at sensing matrix data pre-lockins (in the raw sensors).

    * Check that there is no clipping anywhere in the REFL path (at least out of vacuum), and that the beam is sufficiently small on all 4 REFL diodes.

    * Calculate the new PRC g-factor with the new length.

      9677   Wed Feb 26 02:20:35 2014 JenneUpdateIOOMC unhappy

    I've asked Manasa and Q to have a look at the MC in the morning.  Rana and I have found it to be slightly uncooperative in relocking after a lockloss.

    The concern is that we may be (by actuating on things during lock, or during a lockloss) ringing up some mode, maybe a violin mode in one of the suspensions, maybe a PZT mode of some sort.  If we are, and then we have to push with the PZT on the laser to lock things, that may be why the laser's PZT RMS (on the FSS screen) is so often above 1Vrms.  When we close the PSL shutter, the rms is low, like 0.6 or something, and it stays flat.  As we've all see many a' time, the red trace on the top projector plot is pretty erratic throughout the day when the MC is locked or trying to lock.

    We have found that just letting the autolocker go doesn't seem to work very well, and sometimes the MC just doesn't want to re-lock.  Closing the PSL shutter or disabling the autolocker for a few minutes (5ish) doesn't do anything, but leaving it closed for a long time (30 ish minutes) helps a lot.  The MC  will relock immediately after a nice long break. 

     

      9679   Wed Feb 26 23:14:07 2014 JenneUpdateCDSfb timing was off

    ....fb timing issue happened again.

    I thought that it was the thing that Koji and I saw the other day, where it was individual front end computers that had lost ntp sync, since it wasn't every core on every computer that was red, but reconnecting to the ntp server on c1lsc didn't do anything.  I then tried reconnecting to the ntp server on fb, and that fixed things right up.  Annoying.

      9680   Thu Feb 27 01:02:57 2014 JenneUpdateSUSOplev Tuning Party - round 1

    [Jenne, Vivien]

    We had an oplev tuning party this afternoon.  What we have learned is that we don't have a lot of intuition yet on tuning loops.  But, that was part of the point - to build some intuition. 

    I took responsibility for the PRM, and Vivien took ITMX.  I think, in the end, all changes were reverted on ITMX, however Vivien took some data to try and make a computer-generated controller.  Before we got started, I locked and aligned the PRMI, and we centered the PRMI-relevant oplevs.

    I moved my "boost bump" around a bit, to do more at higher frequencies, but had to sacrifice some of the "oomph", since it was starting to eat up too much phase at my UGF of ~8Hz.  I also made the stack resonant gain higher Q and lower height so that it didn't eat so much phase.  In the end, I have 25 degrees of phase margin, which isn't really great, but I do win a factor of 2 around 2 and 3 Hz.  Also, now I'm able to engage the 3.2 resgain at all, whereas with the previous filter shape I was not able to turn it on.

    PRM_oplevTuning_26Feb2014.pdf

    Maybe it's because I really want it to have helped, but I feel like the POP spot isn't moving as much when I'm locked on PRMI sidebands as it was earlier (we were seeing a lot of low frequency (few Hz) motion).  So, I think I did something good.

      9683   Mon Mar 3 10:42:53 2014 JenneUpdateCDSfb timing was off

    ...yet again.

    lsc and sus needed mxstream restarts after I restarted the ntp on fb.

      9686   Mon Mar 3 21:50:35 2014 JenneUpdateComputer Scripts / ProgramsDropbox installed on Workstations

    I have installed Dropbox on the 40m workstations, using the foteee account. 

    I put it in /users/Dropbox.

    As a side note, I did the install while sitting on Pianosa, but since I put the folder on the mounted hard drive, I think we should be able to use it from any workstation, although I have not yet confirmed this.

      9690   Wed Mar 5 09:52:31 2014 JenneUpdateSUSOplev Tuning - Cartoon cost function

    Not a whiteboard, but here's a cartoon of my oplev cost function cartoon.  For the "maximize this area" and "minimize this area", I plan to use ratios between the curves, and then give those ratios to a sigmoid function.

    CostFunctionOplev.pdf

     

     

      9694   Wed Mar 5 19:15:39 2014 JenneSummaryLSCALS offset moving script modified

    Quote:

    - Step 3: Transition from ALS Common to 1/SQRT(TRX)+1/SQRT(TRY). Make sure that the calibration of TRX and TRY are matched.
      The current understanding is that the offset for 1/SQRT(TRX)+1/SQRT(TRY) can't be provided at the servo filter. Figure out
      what is the correct way to give the offsets to the TR signals.

     I have modified the script ALSchangeOffsets.py (in ..../scripts/ALS/) to also handle a "CARM" situation.  There is a new button for this on the ALS in LSC screen.  This script takes the desired offset, and puts half in the ALSX offset, and half in the ALSY offset.  Whatever offset you ask for is given the sign of the input matrix element in the ALS->CARM row of the input matrix.  For example, if you ask for a CARM offset of 1, and the matrix elements are ALSX->CARM=+1 and ALSY->CARM=-1 (because your beatnotes are on opposite sides of the PSL), you will get an offset of +0.5 in ALSX and -0.5 in ALSY, which should be a pure CARM offset. The offsets get set as expected, but I haven't had a chance to test it live while the arms are locked. 

    I also want to write a script that will average the IN1 of the 1/sqrt(TR) signals, and put that number into the 1/sqrt(TR) offsets.  If this is run when we are at about half fringe, this will set the zero point of the 1/sqrt(TR) signals to the half fringe (or where ever we are).  Then, we need a script similar to the ALS CARM one, to put offsets into the CARM combination of 1/sqrt(TR)s. 

    I think that putting the offsets in before the servo filters will mean that the signals coming out of the input matrices will already be at their zero points, so we won't have as much trouble shifting from ALS to IR.

      9706   Mon Mar 10 11:42:36 2014 JenneUpdateCDSfb timing was off

    fb timing was off again.

      9707   Mon Mar 10 12:49:27 2014 JenneUpdateIOOPMC input pointing misaligned

    I don't know why, but as you can see in Steve's plot from earlier this morning, the PMC transmission has been going down significantly all weekend.  The PMC refl camera was very bright.  I tweaked up the alignment (mostly pitch), and now we're back to normal. 

    The IMC was having trouble staying locked all morning, and I'm hoping that this PMC adjustment will help - the MC already looks better, although it's only been a few minutes.

      9716   Tue Mar 11 15:19:45 2014 JenneUpdateElectronicsHigh gain Trans PD electronics change

    As part of our CESAR testing last night, we had a look at the noise of the 1/sqrt(TR) signal. 

    Looking at the time series data, while we were slowly sweeping through IR resonance (using the ALS), Rana noted that the linear range of the 1/sqrt(TR) signal was not as wide as it should be, and that this is likely because our SNR is really poor. 

    When a single arm is at a normalized transmission power of 1, we are getting about 300 ADC counts.  We want this to be more like 3000 ADC counts, to be taking advantage of the full range of the ADC.

    This means that we want to increase our analog gain by a factor of 10 for the low gain Thorlabs PDs. 

    Looking at the photos from November when I pulled out the Xend transmission whitening board (elog 9367), we want to change "Rgain" of the AD620 on the daughter board.  While we're at it, we should also change the noisy black thick film resistors to the green thin film resistors in the signal path. 

    The daughter board is D04060, S/N 101.  The main whitening board for the low gain trans QPD is D990399, RevB, S/N 104.

    We should also check whether we're saturating somewhere in the whitening board by putting in a function generator signal via BNC cable into the input of the Thorlabs whitening path, and seeing where (in Dataviewer) we start to see saturation.  Is it the full 32,000 counts, or somewhere lower, like 28,000? 


    Actually the gain was changed. From gain of 2 (Rgain = 49.4kOhm) to 20 (Rgain = 2.10kOhm), Corresponding calibration in CDS was also changed by locking the Xarm, running ASS, then setting the average arm power to be 1. Confirmed Xarm is locking. And now the signal is used for CESAR.  We see emperically that the noise has improved by a factor of approximately 10ish.

    Attachment 1: IMG_1309.JPG
    IMG_1309.JPG
      9719   Tue Mar 11 18:34:11 2014 JenneUpdateLSCComposite Error Signal for ARms (7)

    [Nic, Jenne, EricQ, and Koji]

    We have used CESAR successfully to bring the Xarm into resonance.  We start with the ALS signal, then as we approach resonance, the error signal is automatically transitioned to 1/sqrt(TRX), and ramped from there to POX, which we use as the PDH signal.

    In the first plot, we have several spectra of the CESAR output signal (which is the error signal for the Xarm), at different arm resonance conditions.  Dark blue is the signal when we are locked with the ALS beatnote, far from IR resonance.  Gold is when we are starting to see IR resonance (arm buildup of about 0.03 or more), and we are using the 1/sqrt(TRX) signal for locking.  Cyan is after we have achieved resonance, and are using only the POX PDH signal.  Purple is the same condition as cyan, except that we have also engaged the low frequency boosts (FM 2, 3, 4) in the locking servo.  FM4 is only usable once you are at IR resonance, and locked using the PDH signal.  We see in the plot that our high frequency noise (and total RMS) decreases with each stage of CESAR (ALS, 1/sqrt(TR) and PDH). 

    To actually achieve the gold noise level of 1/sqrt(TR), we first had to increase the analog gain by swapping out a resistor on the whitening board. 

     

    spectra-ungarble.pdf

    The other plots attached are time series data.  For the python plots (last 2), the error signals are calibrated to nanometers, but the dark blue, which is the transmitted power of the cavity, is left in normalized power units (where 1 is full IR resonance). 

    In the scan from off resonance to on resonance, around the 58 second mark, we see a glitch when we engage FM4, the strong low frequency boosts.  Around the 75 second mark we turned off any contribution from 1/sqrt(TR), so the noise decreases once we are on pure PDH signal. 

    In the scan through the resonance, we see a little more clearly the glitch that happens when we switch from ALS to IR signals, around the 7 and 12 second marks. 

    We want to make some changes, so that the transition from ALS to IR signals is more smooth, and not a discrete switch.

     

    Attachment 2: Screenshot-1.png
    Screenshot-1.png
    Attachment 3: ScanFromOffToOnResonance.pdf
    ScanFromOffToOnResonance.pdf
    Attachment 4: ScanThroughResonance.pdf
    ScanThroughResonance.pdf
      9724   Thu Mar 13 01:18:00 2014 JenneUpdateLSCComposite Error Signal for ARms (8)

    [Jenne, EricQ]

    As Koji suggested in his email this afternoon, we looked at how much actuator range is required for various forms of arm locking:  (1) "regular" PDH lock aquisition, (2) ALS lock acquisition, (3) CESAR cooling.

    To start, I looked at the spectra and time series data of the control signal (XARM_OUT) for several locking situations.  Happily, when the arm is at the half fringe, where we expect the 1/sqrt(TRX) signal to be the most sensitive (versus the same signal at other arm powers), we see that it is in fact more quiet than even the PDH signal.  Of course, we can't ever use this signal once the arm is at resonance, so we haven't discovered anything new here.

    XARM_OUT_VariousErrorSignals_ungarb.pdf

    EricQ then made some violin plots with the time series data from these situations, and we determined that a limit of ~400 counts encompasses most of the steady-state peak-to-peak output from locking on the PDH signal.

    xarmOutViolinPlot.pdfxarmOutViolinSub.pdf

    [ericq: What's being plotted here are "kernel density estimates" of the time series data of XARM_OUT when locked on these signals. The extent of the line goes to the furthest outlier, while the dashed and dotted lines indicate the median and quartiles, respectively]

    I tried acquiring ALS and transitioning to final PDH signals with different limiters set in the Xarm servo.  I discovered that it's not too hard to do with a limit of 400 counts, but that below ~350 counts, I can't keep the ALS locked for long enough to find the IR resonance.  Here's a plot of acquiring ALS lock, scanning for the resonance, and then using CESAR to transition to PDH, with the limit of 400 counts in place, and then a lockloss at the end.  Even though I'm hitting the rails pretty consistently, until I transition to the more quiet signals, I don't ever lose lock (until, at the end, I started pushing other buttons...).

    LimiterAt400cts.pdf

    After that, I tried acquiring lock using our "regular" PDH method, and found that it wasn't too hard to capture lock with a limit of 400, but with limits below that I can't hold the lock through the boosts turning on.

    noLimitPDHAcq.pdfwithLimitPDHAcq.pdf

    Finally, I took spectra of the XARM_OUT control signal while locked using ALS only, but with different limiter values. Interestingly, I see much higher noise between 30-300 Hz with the limiter engaged, but the high frequency noise goes down.  Since the high frequency is dominating the RMS, we see that the RMS value is actually decreasing a bit (although not much).

    XARM_OUT_VariousLimits_ungarb.pdf

    We have not made any changes to the LSC model, so there is still no smoothing between the ALS and IR signals.  That is still on the to-do list.  I started modifying things to be compatible with CARM rather than a single arm, but that's more of a daytime-y task, so that version of the c1lsc model is saved under a different name, and the model that is currently compiled and running is reverted as the "c1lsc.mdl" file.

      9736   Tue Mar 18 00:51:02 2014 JenneUpdateSUS4.4M local earthquake

     

     I am really, really happy to hear that it was just a sticking situation.  Really happy. 

      9771   Tue Apr 1 20:56:27 2014 JenneUpdatePEMNo noticeable effect from Chile's M8.2 earthquake

    Koji locked the MC, arms, and PRMI, with no troubles, after the M8.2 earthquake off the coast of Chile, that happened about 4 hours ago.

      9772   Tue Apr 1 21:45:01 2014 JenneSummaryLSCPRM violin notch not at correct freq?

    Koji and I have the PRMI locked right now, and we hear a very strong violin mode ringing up, at 628Hz.  This is, according to Koji's elog 9634, what we expect the PRM's violin mode to be.  However, the current PRM violin mode notch is really more of a bandstop filter, between 622-670Hz.  At 628Hz, it has a suppression of about -20dB.  If I try to increase the width of this notch by making it 612-670Hz, the PRMI won't hold lock.

    We're leaving this as a daytime task for tomorrow, since we're in the middle of taking data to show that Koji's new ASC filter design (slightly tuned from his elog 9769) works well.

    Edit:  I have moved the PRM violin notch frequency over to 612-660 Hz, and after letting it sit for a while (while locked on PRMI), the violin mode has settled down.  Interestingly, if I compare the spectrum with and without the 1st order violin mode notch, it looks like the 2nd order mode changes from 1256Hz to 1303Hz.  I don't know what is going on here, but we already have notches for both of those frequencies.

      9774   Wed Apr 2 01:18:30 2014 JenneUpdateLSCAttempt at PRMI+2 arms

    I was trying to lock PRMI+2 arms, but I'm losing patience with the MC losing lock.  It's mostly well-behaved, but every now and again it'll lose lock, and it always seems to be just when I've gotten to a delicate part.  Anyhow.  I don't think anything needs fixing.

    I am not able today to acquire PRMI lock with REFL 165 I&Q, nor am I able to follow Koji's prescription to transition to 165 from 55.  However, I am able to transition to, or just straight-up aquire on, REFL 33 I&Q.  The new ASC is awesome.

    Before trying to lock with REFL165, I redid it's demod phase, by actuating on the PRM while locked on REFL 55, and minimizing the PRCL signal in the Q-phase.  Old 165 phase was -83.5 degrees, new is -79.5 degrees.

    I then tried the procedure of misaligning the PRM, acquiring ALS lock of both arms, finding the arm IR resonances, and moving the arms off resonance.  Then I restored the PRM, and locked the PRMI on sidebands using REFL33 I&Q. 

    Something was a little weird and unexpected:  If the arms were not far, far off resonance, there was a large MICH offset, so that AS was bright, and POP was pretty dark.  If I moved the arms farther from resonance, POP would come back to the "normal" brightness, which was ~460 counts on POP110I.  When POP was dark-ish, POP110I was about 150, although this number could be changed by moving the arms around.  This number was not dependent on PRM alignment.  Also, PRCL was not yet starting to resonate the carrier, because POPDC stayed at its low sideband-lock level of about 90 counts (vs. 2,000+ for a PRMI-only carrier lock), and POP was visually dark on the camera. 

    ---------------------------------

    While playing with PRMI + 2 ALS arms is entertaining for the evening, I don't yet have a plan for dealing with the changing CARM optical plant for IR signals situation.  That's in progress in the daytime.

    ELOG V3.1.3-