40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 155 of 335  Not logged in ELOG logo
ID Date Author Type Category Subject
  9078   Wed Aug 28 03:28:00 2013 JenneUpdateLSCPlaying with DRMI, some ASS automation prep

[Rana, Jenne]

We did lots of poking around with the DRMI tonight.  I should elog more in the morning, but the most important points are:

Locking settings same as elog 9068, except PRCL gain changed to 0.035, and the FMs that are triggered.  PRCL tonight had FM2,3,6 triggered.  MICH had FM1,2,3,7 triggered.  SRCL had FM1,2 triggered.  Engaging the MICH boosts helped make things more quiet, so that some of the SRC boosts could be enabled.  Still not as good of lock stretches as Koji got last Friday (elog 9060). 

REFL55 and REFL11 were still saturating (only during acquisition), after the optical path changes I did last week (elog 9043).  We reduced the REFL55 whitening slider from 15 dB to 6 dB (but forgot to compensate with digital gain), to keep the counts (as seen on DTT time series, binning off) to less than ~20,000 counts.  REFL11 is still saturating, and we're not sure why, since it's slider gain is 0 dB.  To be investigated.

I was prepping the ASS to be more conveniently put into a wrapper script, which could be called from the IFO Configure screen.  This involved adding PRCL to the burt .req and .snap files, as well as modifying the scripts a little bit to include PRCL as an option.  I ended up changing the script names from DITHER_Arm_ON.py and DITHER_Arm_OFF.py to DITHER_ASS_ON.py adn DITHER_ASS_OFF.py, since they are no longer restricted to being arms-only.  You must still provide an argument to the script, to tell it which degree of freedom you want to activate.  I also changed the save offsets scripts.  The way they were, the X and Y arms just had separate hard-coded scripts, with no convenient way to incorporate PRCL.  I merged them (including PRCL) into WRITE_ASS_OFFSETS.py, which you must now provide the DoF as an argument.  I tested these new scripts on all 3 of the DoFs, and made changes to the ASS screen, so it now calls only the new scripts.  It should now be easy to incorporate future ASS modifications.

Rana was in the middle of modifying the ASS model to include SRCL, and we also need to include MICH.  The ASS model is not compile-ready, so don't compile it!!  If you need to compile the ASS, please save what's there as a different name, and do an "svn up" to get the latest working version.


We suspected that there might be angular drive issues with the SRM (it was wiggling a lot). We checked the damping via step responses - all Qs were less than 10. Then we found that the INPUT button on the SRM PIT OL was OFF (why ???). After turning this back on it behaved better. We measured the loop shape and found that the UGF was 7 Hz; good. Need to work on some loop shaping for this guy. Its just 1/f out to 300 Hz right now. UGF should be made a little lower so that we can stably turn on the Bounce/Roll notches and a ~50 Hz low pass filter.

Most importantly, the F2A filters need to be measured and implemented. They are a few years old.

  9077   Wed Aug 28 00:41:23 2013 JenneUpdateCDSCDS svn commits not happening

svn status update. asx, als and ioo were found not committed. Not sure about who modified ioo last after Jenne.

//edit Manasa - edited the/ elog instead of replying //

  9076   Tue Aug 27 20:43:34 2013 KojiConfigurationCDSfront end IPC configuration

The reason we had the PCIe/RFM system was to test this mixed configuration in prior to the actual implementation at the sites.
Has this configuration been intesively tested at the site with practical configuration?

Quote:

Attached is a graph of my rough accounting of the intended direct IPC connections between the front ends. 

It's hard to believe that c1lsc -> c1sus only has 4 channels. We actuate ITMX/Y/BS/PRM/SRM for the length control.
In addition to these, we control the angles of ITMX/Y/BS/PRM (and SRM in future) via c1ass model on c1lsc.
So there should be at least 12 connections (and more as I ignored MCL).

I personally prefers to give the PCIe card to c1ioo and move the RFM card to c1lsc.
But in either cases, we want to quantitatively compare what the current configuration is (not omitting the bridging by c1rfm),
and what the future configuration will be including the addtional channels we want add in close future,

because RFM connections are really costly and moving the RFM card to c1lsc may newly cause the timeout of c1lsc
just instead of c1sus.

  9075   Tue Aug 27 19:50:06 2013 JamieConfigurationComputer Scripts / Programscdsutils checked out into /opt/rtcds

I have checked out the new cdsutils repository at:

/opt/rtcds/cdsutils/release

This is a new repository that is intended to hold all of our python libraries and command-line utilities for interacting with the IFO, things like:

  • get/write values EPICS channels
  • interact with filter module switches
  • average a test point for some amount of time
  • etc.

Basically everything that used to be ez* or tds*.

There's not much in there at the moment, but hopefully it will start to get filled in soon.

WARNING:

This code in here will be used by the sites to interact with the real aLIGO IFOs.  Please be careful as you develop things in here, and o so conscientiously.  If you do bad things here and it messes things up at the sites people will be angry.  Particularly me, since I have to support everything in here for Guardian use.

Usage

<cdsutils>/lib/cdsutils is the primary python library.  For each function you want to add, put it in a new file named after the function.  So for instance function "foo" should be in a file called <cdsutils>/lib/cdsutils/foo.py.

There is a command line utility at <cdsutils>/bin/cdsutils.  It will automatically find anything you add to the library and expose it as a sub command (e.g. "cdsutils foo")

We'll try to put together a wiki page describing development and usage of this soon.

  9074   Tue Aug 27 19:34:36 2013 JamieConfigurationCDSfront end IPC configuration

So the IPC situation on the front end network is not so great right now.  For various no-longer-valid reasons, c1lsc had no RFM card, all the IPC connections were routed through the c1rfm model on c1sus, and routed to c1lsc via dolphin PCIe as needed.  As things grew, c1rfm became overloaded.  Koji tried to fix the situation by breaking things out of c1rfm to make direct connections where we could.  This cleared up c1rfm a bit, but not c1mcs is overloading.

Reminder: PCIe (dolphin) is faster and higher bandwidth than RFM.  The more things we can put on PCIe the better.

Attached is a graph of my rough accounting of the intended direct IPC connections between the front ends.  By "intended direct" I mean what should be direct connections if we had all the appropriate hardware.  Right now the actual connection graph is more convoluted than this since things are passing through c1rfm.  I note this graph was NOT particularly easy to make, which is very unfortunate.  I had to manually look through every model and determine the ultimate source of every incoming IPC.  Kind of a pain in the butt.  It would be nice if there was a simple way to represent this.

Here are some various solutions to the problem as I see it:

a) put c1lsc on the RFM network

This would allow c1lsc to talk to c1ioo, c1iscex, and c1iscey without having to go through c1sus, thereby eliminating c1rfm altogether.  I'm not sure why we didn't just do this originally.

Requires:

  • One RFM card for c1lsc

b) put c1ioo on the PCIe network (and move c1sus's RFM card to c1lsc)

This is probably the most robust solution.

b1) There are roughly 8 IPCs going from c1ioo to c1sus, and 4 going the other way, and 3 IPCs from c1ioo to c1lsc.  If we put c1ioo on PCIe all of these now RFM connections would become direct PCIe connections, which would be a big win.

At this point only the end station front ends would be on RFM, and most of the connections to those come from c1lsc, so it would make sense to give c1lsc the RFM card, thereby eliminating a lot of stuff from c1rfm.

Requires:

  • dolphin card for c1ioo (do the old sun machines support these?  if they don't we could swap the old sun machine with a new spare aLIGO-approved supermicro machines, which we have spares of)
  • dolphin fibre to go to dolphin switch in 1X3 rack

b2) OR, we could move c1ioo to 1X4 with c1lsc and c1sus, and get a OneStop fibre cable to connect to its IO chassis.  We would still need a dolphin card, but we could use coper instead of fibre.  This is my preferred solution, since it moves c1ioo out of 1X1, where it's really in the way and making a lot of noise.  It would also be easier to manage all the machines if they're together in one rack.

Requires:

  • dolphin card for c1ioo
  • dolphin coper cable for c1ioo
  • OneStop fibre for c1ioo

c) put another cpu in c1sus

c1sus is (I believe) able to support another 6-core cpu.  If we added more cores to c1sus, we could break up c1rfm into c1rfm0, c1rfm1, etc.  This is a less elegant solution imho, but it would probably do the job.

Requires:

  • one new CPU for c1sus
Attachment 1: hosts.png
hosts.png
  9073   Tue Aug 27 18:58:52 2013 KojiConfigurationElectronics110 MHz LO options

- Do we have an appropriate amplifier?

- True challenge could be to find a feedthrough for the new port. (or to find a space for the amplifier in the box)

- PDXXX channels is on the DC whitening filter module. There could be some modification on this module (like diabling the whitening gain selector).

- We don't have AS11 and AS165, and so far it is unlikely to use AS11. i.e. The feedthrough, the slot on the crate, the whitening, and the channels can be trasnsition from 11 to 110.

Quote:

I want to amplify that by ~10 dB, to give 9 dBm.  Attenuate by 5 dB to get to 4 dBm, then split into 2, giving me 2 110 MHz spigots, each of ~1 dBm. 

Thoughts, before I start scrounging parts, and pulling the RF distribution box?

 

  9072   Tue Aug 27 18:21:35 2013 JenneConfigurationElectronics110 MHz LO options

As I see it, we have a few options for getting the 110 MHz LO to both the POP110 and AS110 demod boards.  

The current situation is described by Kiwamu in elog 5746.  The 55 MHz signal comes into the box, and is split 4 ways, with each path having 19.7 dBm.  One of these 4 is for 110.  It has a 2dB attenuator (giving us ~17.7 dBm), and then it goes to an MK-2 frequency multiplier.  I'm a little lost on why we're giving the MK-2 17 dBm, since it says that it can handle an input power between 1 - 15 dBm.  It has ~16 dB conversion loss, so the 110 output of the distribution board has (according to the drawing) 1.9 dBm.  The demod boards have a 10 dB attenuator as the first element on the LO path, so we're giving the ERA-5 -8 dBm. 

We can either amplify the 110 leaving the distribution box, split it, and then attenuate it to the appropriate level for the demod boards, or we can change the attenuators on the POP110 and AS110 demod boards. 

Since we seem to be over driving the 2x frequency multiplier, I think I should change the 2dB attenuator to a 5dB attenuator, so we're giving the 2x multiplier ~15 dBm.  The conversion loss of ~16 dB means we'll have -1 dBm of 110 MHz.  I want to amplify that by ~10 dB, to give 9 dBm.  Attenuate by 5 dB to get to 4 dBm, then split into 2, giving me 2 110 MHz spigots, each of ~1 dBm.  Since the demod boards expect between 0-2 dBm for the LO's, this should be just fine.

Thoughts, before I start scrounging parts, and pulling the RF distribution box?

  9071   Tue Aug 27 17:32:52 2013 JenneConfigurationElectronicsputting together a 110 MHz LSC demod board for AS

I measured the phase split between the I and Q signals of my AS110 board.  To do so, I plugged the board into an empty slot next to the PD DC readout / whitening board in the LSC rack.  I borrowed the POP110 local oscillator, and used a Marconi to generate a "PD input".  (I'm roughly following what Suresh did in elog 4736).  Our 11MHz is currently 11.066134MHz, so I had the Marconi going at 110.662340 MHz (1kHz from 10*11MHz), and I had the Marconi source at -13dBm.  

I took a transfer function using the SR785 between the I and Q outs of the AS110 demod board, and got a magnitude misbalance of 0.809 dB, and a phase split of 110.5 degrees.  This isn't so close to 90 degrees, but this may be a problem with the splitter that we're using, as Suresh detailed in elog 4755.  In that elog, he measured a phase split of POP110 of 105 degrees, unless the power going into the splitter was pretty high.  As with POP110, since I expect that we'll usually only look at one channel (I, for instance), this isn't such a big deal for AS110. 

I have left, for now, the board in the empty slot.  It looks like (I'm going to go check) there are 3 open channels on the whitening board that has the PD DC signals.  So, the only thing left to figure out is how we want to get some local oscillator action for this new board.

EDIT: Yes, those channels are available.  Right now (as a remnant from testing the whitening filters waaaay back in the day) they are called C1:LSC-PDXXX I, Q, DC.  I'll use 2 of those for the AS110 I and Q. 

  9070   Tue Aug 27 15:44:08 2013 manasaUpdateCDSIssues with ALS fixed

I figured out the problem with ALS from yesterday. While the model was just fine, the medm screens were not checked if they were reading the correct channel names. 

The channel names of the ALS input matrix elements had changed when the coarse channels were deleted from the c1als model. So the error signals were not reaching the servo modules as expected. This is why I was not able to make sense as to what the ALS was doing. 

All is fixed now and should be back to normal

  9069   Tue Aug 27 15:31:48 2013 JenneConfigurationElectronicsputting together a 110 MHz LSC demod board for AS

Quote:

Quote:

I have modified one of the spare demod boards that was sitting above the electronics bench (the one which was unlabeled - the others say 33MHz, 55MHz and 165MHz) to be the new AS110 demod board.  In place of the T1 coil, and the C3 and C6 resistors, I have put the commercial splitter PSCQ-2-120+.  In place of U5 (the low pass for the PD input) I have put an SCLF-135+.

OK, but what kind of filter should we be actually using? i.e. what purpose the 135 MHz low pass serve in contrast to a PHP-100+ ?

 Hmmm. Indeed. This is just cutting off higher frequency stuff, but anything from other lower sidebands still gets through.  I should actually stick in the SXBP-100's, which will band pass from 87-117 MHz.  These have an insertion loss at 100 MHz of 1.64 dB. 

Jamie ordered 2 of these, so I can put one in each of AS110 and POP110. 

  9068   Tue Aug 27 02:18:28 2013 JenneUpdateLSCPRMI, DRMI sensing matrices

I have made a measurement of the PRMI and the DRMI sensing matrices. 

Keiko pointed out to me in an email a little while ago that I wasn't zeroing elements in the oscillator drive matrix after using them, so I was effectively driving all the degrees of freedom at once, which is why some of the recent sensing matrices looked a little bullshitty.  Anyhow, I put in a few lines to zero that row of the LSC  output matrix, so that we don't do that any more. 

PRMI sensing matrix:

SensMatMeas_26Aug2013_withErrorBars.png

DRMI sensing matrix, first-ever measurement, after the optic flipping / recent locking success:

SensMatMeas_26Aug2013_DRMI_firstEverMeasurement.png

Note that we don't have any error bars in the DRMI case, since the IFO fell out of lock during the error bar measurements.  So, we got the "real" data from the degrees of freedom, but not extra data for making error bars.  Also, the MICH / SRCL coupling hasn't been balanced out in the output matrix yet, but since the notches are engaged in the degrees of freedom during this measurement, that shouldn't be a significant effect.

To get the DRMI sensing matrix measured, I added the SRM's actuator calibration to SensMatDefinitions.py (data from elog 5637).  I also created a new file runDRMI_sens, to be the equivalent of runPRMI_sens.  In the new runDRMI_sens, I reduced the actuation from the oscillator by a factor of 10.  I had several attempts at higher oscillator amplitudes that kept kicking the IFO out of lock.

The DRMI was pretty good, but I wasn't getting ~10s of minutes like Koji was on Friday.  I also wasn't able to engage all of the FM triggers that he was.  The 10-30 Hz seismic BLRMS is a little higher than a usual night, but other than that, seismic looks pretty quiet.

My settings for the night:

LSC input matrix:  +0.1*REFL55Q = MICH, -0.125*REFL11I = PRCL, +1.00*REFL55I = SRCL.

Filter settings:  MICH, PRCL, SRCL all had FM4,5 always on.  MICH had FM2,3 triggered.  PRCL had FM2,3,6 triggered.  SRCL had FM2 triggered.  In particular, engaging FM 6 for MICH or SRCL made some loud low-ish frequency oscillation.  Engaging anything other than FM2 for SRCL kicked the IFO out of lock. 

Gains:  MICH = -0.800, PRCL = +0.050, SRCL = -0.100

Triggering:  All triggered on POP22I, upper = 50, lower = 10 (lower = 25 for SRCL).

FM trigger thresholds: MICH on = 35, off = 2, delay = 2 sec.  PRCL on = 35, off = 2, delay = 0.5 seconds.  SRCL on = 80, off = 25, delay = 5 sec.

Power normalization:  None, for any degree of freedom.

LSC Output matrix:  MICH = -0.267 for PRM, +0.50 for BS.  PRCL = +1.0 for PRM.  SRCL = +1.0 for SRM. 

LSC SUS filters:  BS, PRM, SRM all had FM1,2,3,6 engaged for the BS, PRM and SRM violin filters, as well as the 3rd order harmonic for one of them.

Other notes: 

I tried locking the SRMI, so that I could do the same kind of actuator calibration that Koji did for the PRMI in elog 8816, but was unsuccessful.  I checked optickle, and found that for REFL 55 I&Q locking, MICH and SRCL keep the same signs for SRMI as DRMI.  Also, for both, the optical response is a factor of ~15 lower for SRMI than DRMI, so the gains should be higher by a factor of 15 for both MICH and SRCL.  I think my big problem here is that I don't have anything to trigger on.  There isn't any signal to speak of in the POP PDs, with the PRM misaligned.  Hopefully we'll have AS110 shortly, and that will help.

I updated the IFO Configure restore scripts to our latest versions of locking.  I have also tested them, and restoring the Michelson, PRMI and DRMI all seem to work. (MICH restores to locking with AS55Q.  PRMI restores to locking with REFL165 I&Q.  DRMI restores to the settings noted above in this entry.)  The X and Y arm restores have been working, and I have been using them (semi-)regularly since I announced them in elog 8433 back in April.  Still to-do though:  Add PRCL ASC to the PRMI up script, and make the dither options work for at least the arms and PRM.  (Just need to point the drop down menu options to the new ASS scripts.)

 

 

  9067   Mon Aug 26 20:13:17 2013 ranaConfigurationElectronicsputting together a 110 MHz LSC demod board for AS

Quote:

I have modified one of the spare demod boards that was sitting above the electronics bench (the one which was unlabeled - the others say 33MHz, 55MHz and 165MHz) to be the new AS110 demod board.  In place of the T1 coil, and the C3 and C6 resistors, I have put the commercial splitter PSCQ-2-120+.  In place of U5 (the low pass for the PD input) I have put an SCLF-135+.

OK, but what kind of filter should we be actually using? i.e. what purpose the 135 MHz low pass serve in contrast to a PHP-100+ ?

  9066   Mon Aug 26 19:54:15 2013 manasaUpdateCDSc1als model modified

I had made changes to the c1als model a couple of weeks ago. I had removed all the beat_coarse channels that had existed from pre-phase tracker era.

Also, I forgot to elog about it then. This dawned on me only when I found that c1als isn't working the way it should right now.

mistake-cartoon.gif

  9065   Mon Aug 26 19:31:22 2013 manasaUpdateSUSPRM, ITMY watch dogs

PRM and ITMY were found with their watchdogs shutdown this afternoon (cause unknown). I re-engaged them.

  9064   Mon Aug 26 19:13:38 2013 KojiUpdateLSCLSCoffset script updated

What do you mean???

What is the effect of the anti-whitening filter?

Quote:

You should know that if you use OUT16 channel, the effect of the unwhite filter is not taken into account.

 

  9063   Mon Aug 26 18:59:08 2013 MasayukiUpdateLSCLSCoffset script updated

I made scripts/LSC/LSCoffsets2.py which is the script to zero the dark offset of all the LSC PD.  The list of PDs is same as the list in scripts/LSC/LSCoffsets. New script average all outputs of PDs parallelly, so we can zero the offsets much faster.

You can define the averaging time, and you can choose the channel for getting the dark offset from INMON or OUT16. You should know that if you use OUT16 channel, the effect of the unwhite filter is not taken into account.

Example usage (at scripts/LSC):

   ./LSCoffsets2.py -d 20 --out16

you can find the help by calling this script with option -h or --help

  9062   Mon Aug 26 18:55:18 2013 JenneConfigurationElectronicsputting together a 110 MHz LSC demod board for AS

I have modified one of the spare demod boards that was sitting above the electronics bench (the one which was unlabeled - the others say 33MHz, 55MHz and 165MHz) to be the new AS110 demod board.  In place of the T1 coil, and the C3 and C6 resistors, I have put the commercial splitter PSCQ-2-120+.  In place of U5 (the low pass for the PD input) I have put an SCLF-135+. 

In order to figure out how to make the pinout of the PSCQ match up with the available pads from T1, I first pulled the "AS11" board (it's not something that we use, so it would be less of a tragedy if something happened while I had the board pulled).  However, while the PCB layout is the same, the splitter for the low frequencies (PSCQ-2-51W) has a different pinout than the one I need for the 110MHz.  So, I put AS11 back, and pulled the POP110 board. (After I noted the pinout on POP110, I reinstalled that board.  To get it out, I had to unplug the I and Q outs of POP22, but I have also replugged those in).

For my new AS110 demod board, I copied the pin connections on POP110.  I have made a little diagram, so you can see what pins went where.  The top 2 rectangles are the "before" installation cartoon, and the bottom is the "as installed" cartoon.

AS110_demod_board_modifications.pdf

The one thing that must be noted is that, because of the pinout of the splitter and the constraints of the board layout, the +0 degrees (I-phase) output of the splitter is connected to the Q channel for the rest of the demod board.  This means that the +90 degrees (Q-phase) output of the splitter is connected to the I channel for the rest of the demod board.  This is not noted for POP110, but is true for both:  The I and Q channels of the 110 MHz demod boards are switched.  In practice, we can handle this with our digital phase rotation.

Daytime tomorrow, I will test my new board as Suresh did in elog 4736.  Before we get to use AS110, we need (a) some LO juice from the RF distribution box, and (b) a spot to plug the board in, in the LSC rack.  Meditating on how those are going to happen are also tasks for daytime tomorrow.

  9061   Sun Aug 25 06:07:11 2013 ranaUpdateLSCDRMI Locked with improved lock streatches

 We're ready for using the auto configure.

We can put our scripts for the MICH, PRMI, and DRMI into the IFO CONFIGURE screens for now and then it should be easy to get them into the Guardian once Jamie has the bugs worked out.

This screen can also be used to setup and start the dither alignment for each configuration (once we have one working for DRMI / SRM).

Also, now that the notches/bandstop filters for the violin modes have been move from the SUS into the LSC, we should fix the triggering to engage them a few seconds after the boosts.

  9060   Sat Aug 24 00:11:07 2013 KojiUpdateLSCDRMI Locked with improved lock streatches

Friday night locking

Much more stable DRMI lock was achieved, partly thanks to the Friday-night quiet seismic,
and partly because of the improved servo gain and LF boosts


55MHz thru-put

I wanted to confirm the enhancement of the 110MHz signal at the AS port.

As the AS110 PD is placed in the CCD path, there is nothing visible with PRMI.
The Thorlabs PD was moved to the main AS path. Now the AS110 PD is receiving 50% of the power.
 

With PRMI 110MHz peak was -30dBm (As it was fluctuating, anything more precise number did not make sense)
When the DRMI was locked, the peak was enhanced to 0dBm.

The 2f signal comes from the beat between the sidebands.
Thus the amplitude of the intensity is proportional to the power of the sidebands (assuming the +1 and -1 order sidebands have the same amplitude)
-30dBm -> 0dBm means 31.6 times amplitude of the intensity. Therefore the amplitude transmission of the sidebands is 5.6 times more. (Is this true?)

According to the wiki, the AS port thru-put (i.e. power transmission) for the 55MHz sideband is 0.0026 and 0.43 for PRMI and DRMI respectively.
This corresponds to the amplitude difference of ~13. So we still have only half of the sidebands leaking out from the IFO. This could be attributed
to both the smaller PR gain and SR gain.


Locking setup

Same as the one Jenne used the other day. Later I engaged several additional triggers.
The following is the trigger setting I used

MICH: Delay 2 sec, FM1/FM2/FM3/FM6/FM7

PRCL: Delay 0.5 sec, FM2/FM3/FM6

SRCL: Delay 5 sec, FM1/FM2/FM3/FM6

SRCL FM1 was modified from +3dB to +6dB


Lock stability

Once lock is acquired, it lasts tens of minutes. (see the attached striptool chart.)
Even the lock is lost, it reacquires quickly.

The videos to show the lock acquisition and the in-lock stability are attached below.
The AS port beam is very round. It is not so shaky, but some yaw motion is visible.
The mode at the AS port is defined by the SRM, putting a QPD at the AS port would help to
stabilize the spot.


IFO state upon leaving

I left the 40m with the arms aligned, PRM and SRM slightly misaligned, and LSC setting is for the DRMI locking.


TO DO

- AS110I/Q for triggering

- PRCL/MICH/SRCL normalization

- We should resurrect the IFO config scripts.

- Remove BS->SRCL actuation coupling

- Handing off to 3f signals (preparation for the full lock)

- Improve ALS stability

- SRM ASC: AS QPD for SRM control


Lock Acquisition Video
UL (REFL) / UR (POP)
LL (AS) / LR (PRM Face)

 
In-lock video
UL (REFL) / UR (POP)
LL (AS) / LR (PRM Face)

 

Attachment 1: Screenshot-Untitled_Window.png
Screenshot-Untitled_Window.png
  9059   Fri Aug 23 21:01:38 2013 Alex ColeHowToElectronicsAutomated Photodetector Frequency Response System

 This post describes how to use the Automated Photodetector Frequency Response System.

On the mechanical side, turn on:

-the diode laser (in rack 1Y1)

-the RF Switch (in rack 1Y1)

-the reference PD (under the POY table)

-the AG4395A Network Analyzer

The NA’s RF output should go to the laser’s modulation input, the reference PD’s output should go to the NA’s R input, and the RF Switch Chassis’s output (which is the combination of the two switches’ COM channels using a splitter) should go to the NA’s A input.

Once this is done, navigate into /users/alex.cole and run PDFR.sh. This script collects data for each photodetector under consideration by switching using a python script and communicating with the NA via GPIB. It then sends all the data to RF.m, which fits the functions, plots the latest data against canonical data, and saves the plots to file.

The fitting function, fit.m, also outputs peak frequency to the command line. This function uses PD name data (e.g. ‘REFL33’) to choose an interval with minimal noise to fit.

The main script prompts the user to press enter after each NA sweep to make sure that measurements don’t get interrupted/put out of order by RF switching.

Once you're done, you should turn off the laser, NA, RF Switch, and reference PD.

Troubleshooting

Sometimes, the NA throws up and doesn’t feel like running a particular sweep. If this happens, it’s a good idea to keep the matlab script from trying to analyze this PD’s data. Do this by opening up RF.m and commenting out the calls to ‘fit’ and ‘canonical’ for that PD.

If fit.m complains about a particular set of data, it is often the case that the N/P ratio (where N is order of approximation and P is number of points in the interval) is too high. You can fix this by reducing N or making the PD’s frequency range (chosen in the fnew_idx line) larger.

Choosing a single PD

If you only want to grab the transfer function for one PD, first look up which switch input it belongs to. This information is contained in /users/alex.cole/switchList. To turn the switch to a particular input, type something like:

python rf.py “ch7”

This command uses TCP/IP to tell the switch to look at channel 7. Switch input numbers range from 1 to 16, though not all of them are in use.

Once the switch is looking at the correct input, you can run a sweep and download the data by typing /opt/rtcds/caltech/c1/scripts/general/netgpibdata/NWAG4395A -s 1000000 -e 500000000 -c 499000000 -f [filestem for output] -d [path of directory for output] -i 192.168.113.108 -g 10 -x 15. 

  9058   Fri Aug 23 14:19:28 2013 ranaUpdateSUSViolin filters moved to LSC, from SUS

  Just to rephrase somewhat:

  • We balance the BS & PRM actuators in the LSC Output matrix so that there is no MICH signal going into REFL_I @ 100 Hz.
  • REFL Phase is adjusted by driving PRM and minimizing Q/I to within ~1 deg (Q/I ratio of ~2%)
  • The REFL_I sensing matrix element is ~50x bigger than REFL_Q (in W/m)
  • When we turn ON the violin mode notch in the BS SUS, it changes the MICH drive into a purely PRCL drive at that frequency !!!
  • So, putting notches into the SUS screens is bad since it imbalances the drives.
  9057   Fri Aug 23 01:52:34 2013 JenneUpdateSUSViolin filters moved to LSC, from SUS

[Rana, Jenne]

We were meditating a little bit on what may be the story behind the PRM violin filter situation.  We locked the PRMI, and turned on and off the violin filters.  We noticed, very bizarrely, that when the violin filters were ON, the servos would oscillate.  Weird.  Also, probably because the oscillation was causing us to hit the limit we have in the MICH servo, we rung up a 3rd harmonic of one of the violin modes, which was at 1955 Hz. 

We took a transfer function of the PRCL servo, saw that the UGF was 300 Hz, and lowered it to ~180 Hz.  After later investigations, that high-ish UGF probably wasn't a problem.  Anyhow, we then took MICH servo transfer functions, and saw some very weird stuff. 

At frequencies where we had violin filter notches, we were seeing peaks in the transfer function, which came close to touching, or crossed the 0dB line!  We suspect that this may have something to do with the balancing of the drives to the optics, since we have PRCL driving PRM, but MICH driving BS and PRM.  What we did was move the violin filter notches into the LSC model.  There were already SUS filter banks in the LSC model (right side of the LSC screen).  In preparation for the DRMI, I have put the BS violin notches into the BS, PRM and SRM filter banks, as well as the PRM and SRM filters into all 3 banks.  Right now for PRMI, I have the BS and PRM notches (as well as the Vio3 notch) turned on in both BS and PRM.  All of the violin-related filters are turned off in the LSC filter bank inside the SUS models.  When we did this, the servo oscillations no longer are excited when we turn on the notches, and when we take a new transfer function, there are no longer weird peaks at the notch frequencies.  More meditation needs to be done.

Also, for the violin3 filter, Rana noted that at 1955 Hz, after we confirmed that the REFL 55 phase was set correctly (and we're using REFL 55 I&Q for PRMI locking), the I-phase had a response of 0.36, while the Q-phase had a response of 0.20.  I should be able to think about these numbers, and decide if the vio3 is for the BS or the PRM violin mode.

 MICHloopNotches_23Aug2013.pdf

the above series of Bode plots shows the MICH Open Loop Gain as the REFL55 phase is adjusted (PURPLE, ORANGE) with the notches in the SUS and then (RED) as the notches are moved to the LSC and made the same for all optics.

In other news, I have the parts that Jamie ordered to make a new 110 demod board, so that's one of my daytime activities now, so we can have both POP110 and AS110.

  9056   Thu Aug 22 22:05:36 2013 ranaUpdateGreen LockingGTRY normalized

Meh. 600 counts is too weak.  You should fix the electronics so that the maximized green laser transmission gives more like ~10000 counts.

  9055   Thu Aug 22 21:16:47 2013 ManasaUpdateGreen LockingGTRY normalized

The Y arm green transmission has been measuring in counts all along. I modified the gain in the ALS-TRY filter module to normalise the transmission.

Transmission has been normalised with GTRY = 1 corresponding to 600 counts. 

  9054   Thu Aug 22 20:25:28 2013 MasayukiSummaryGreen LockingY-arm PDH OLTF measurement

[Manasa, Masayuki]
We measured the the openloop transfer function of the PDH green lock of the y-arm.The measurement setup was same as yesterday's measurement.elog 9047

In this measurement, the servo gain was 7 and the source amplitude for the excitation was 1 mV. As you can see in below figure, the measured UGF was 15 kHz and the phase margin was 45 degree.

attatchment1 - OLTF with servo gain of 7

OLTF_PDH_Glock_yarm_7.png

  9053   Thu Aug 22 13:20:54 2013 KojiUpdateLSCDRMI Locked for 1+ minute!!!!!!

Don't go for a hacky solution. We want to climb a staircase step by step.
Prepare an independent 110MHz demod ports.

Quote:

To-do:  Set up the AS OSA.  Also, perhaps temporarily borrow the 110 demod board from POP.  We were triggering on POP22 tonight, and that seemed to work okay. 

 

  9052   Thu Aug 22 13:03:40 2013 JenneUpdateLSCDRMI Locked for 1+ minute!!!!!!

Quote:

  Very nice!!  I was wondering, shouldn't the driving matrix be such that MICH pushes on SRM as well?

 Hmmm, yes, that's a very good point.  I think you're right, and I'll give that a try today.

  9051   Thu Aug 22 10:20:32 2013 kiwamuUpdateLSCDRMI Locked for 1+ minute!!!!!!

Wonderful ! I like the video -- the spatial mode looks pretty clean and much cleaner than what I observed in the old days.

  9050   Thu Aug 22 07:57:57 2013 LisaUpdateLSCDRMI Locked for 1+ minute!!!!!!

  Very nice!!  I was wondering, shouldn't the driving matrix be such that MICH pushes on SRM as well?

  9049   Thu Aug 22 02:40:12 2013 JenneUpdateLSCDRMI Locked for 1+ minute!!!!!!

[Jenne, Koji]

The DRMI has been locked!!  And at least one time, it was for more than one minute!! 

DRMI_First_Lock_1plusMinute_21Aug2013.png

We are not 100% sure yet that it's correctly sideband locked.  The test of this was to put a 50% BS in front of the AS camera (so after the beam has gone to AS55), and send the light over to a PDA10CF Thorlabs PD.  I locked the Michelson on carrier for the alignment of this diode.  Then I strung a cable to the control room, and plugged it into the RF spectrum analyzer.  (First, I had turned off the green beat PD power, so there wasn't any RF stuff on the line that I unplugged).  It's hard to watch the screen and a tv / dataviewer at the same time, so I've taken a video, so that we can see the nicely locked round DRMI beam on the AS camera, and the spectrum analyzer.  My phone is working very hard at uploading the video, but we may have to wait until tomorrow for that.  However, I think that we're locked on the 55MHz sideband. (Also, maybe I'm too tired or excited or something, but how do you make the real cameras take video??)

EDIT:  Video uploaded.  Pause the video at 10 seconds, and you'll see that we've got a strong 110MHz peak!!  Hoooray!  The TV in the upper right side of the video is AS.  You can see as we flash, the peaks go up and down.  When there's no resonance, the 110 peak goes away. (Ex., when I'm PRMI locked on the sideband, there isn't a visible peak).

 

Alignment procedure was as normal:  Lock and align the arms. Misalign ETMs. Check that MICH fringes look good (ASS does a nice enough job that I don't actually lock and align the Michelson anymore).  Restore the PRM.  Lock PRMI.  Tweak PRM alignment to maximize POP110I.  At this point, Koji and I played a little with the PRMI, but when we finished with that, we restored the SRM, and tweaked its alignment by making nice overlap on the AS camera.

Then, we tried some DRMI settings, started seeing some locks, and played a bit with trying to optmize the settings that we have. 

DETAILS:

PRMI settings: 

PRCL ASC is on (with loop triggering).  MICH gain = -0.8, PRCL gain = +0.05.  FM4, FM5 always on, FM2 triggered.  Loop and filter module triggering on POP22I.  No power normalization.  MICH and PRCL locked on REFL55 I&Q, with 1's in the LSC input matrix.  PRCL actuating on PRM with +1, MICH actuating on BS with +0.5, PRM with -0.267. 

I took transfer functions between REFL55 I&Q and REFL11 I&Q, to determine the relative gains and signs.  REFL11I's gain should be -18dB relative to REFL55I, with the opposite sign.  We tried PRMI locking with MICH = 1*REFL55Q and PRCL = -0.125*REFL11I for the input matrix.  Still no power normalization (we haven't used power norm at all today, so I'll quit writing that).

I took transfer functions between REFL55 I&Q and REFL33 I&Q.  REFL33I's gain is -8dB relative to REFL55I, but they have the same sign.  We tried locking PRMI with MICH = 1*REFL55Q and PRCL = +0.6*REFL33I.  Success.

Next up, some Optickle simulations, to help us go in the right direction for DRMI locking.  I checked the signs of the error signals REFL55I (PRM sweep), REFL11I (PRM sweep) and REFL55Q (MICH sweep) in both PRMI and DRMI configurations.  For all of these cases, the signs were the same (i.e. no sign flips needed to happen for DRMI locking, relative to PRMI locking).  I checked the sensing matrices for DRMI and PRMI for those same signals, and took the ratios of the sensing matrix elements.  This gave me the ratio of optical gains for each error signal, in the DRMI case vs. PRMI case, so any servo gain changes should be the inverse of these numbers.  These numbers are all DRMI/PRMI:  REFL55I PRCL response = 0.76, REFL11I PRCL response = 0.99, REFL55Q MICH response = 18.  So, when trying to lock the DRMI, we wanted to keep the gains for PRCL about the same, reduce the servo gain for MICH by a factor of ~20, but keep the same signs for everything.

In doing that, we started seeing some short DRMI locks, so we twiddled some parameters (mostly the elements in the LSC input matrix) a bit.  We eventually settled on:  PRCL = -0.125*REFL11I, MICH = 0.1*REFL55Q, and SRCL = 1.0 * REFL55I.  The output matrix was the same (MICH pushing on BS and PRM, PRCL on PRM), with the addition of a +1 in the SRCL -> SRM element.  For all 3 degrees of freedom (PRCL, MICH, SRCL), FMs 4 and 5 were always on.  For PRCL, FMs 2,3,6 were triggered to come on after 0.5 seconds of delay.  The PRCL FM triggers helped enormously.  I tried several other things, including changing the MICH input matrix element up and down in value, changing the SRCL input matrix element up and down in value, and engaging triggering for a few different filters in the MICH and SRCL degrees of freedom.  However, none of these made things better, and several made things worse.  Most notably, for SRCL, engaging triggering for FMs 2 and 3 kicked the cavities out of lock, which implies that perhaps our gain isn't high enough yet (and thus our UGF isn't very high yet).  I changed FM1 of SRCL to be +3dB of gain (from +10dB), and it would live through that coming on (trigger delayed by 1 sec, then ramping up over 1 second), but within a second after the filter finishing coming on, the cavity would fall out of lock (not violently kicked, just not locked anymore). 

At this point, we were trying to figure out a way to confirm what kind of lock we had.  I checked Optickle again, and we do not expect to see a significant change in POP110I between the PRMI and DRMI cases, so that isn't a useful check.  We dreamed of having our AS110 demod board, or the AS OSA set up, but neither of those was going to happen tonight.  Instead, Koji suggested hooking up the PD, and looking directly at the output. 

To-do:  Set up the AS OSA.  Also, perhaps temporarily borrow the 110 demod board from POP.  We were triggering on POP22 tonight, and that seemed to work okay.

 

 

  9048   Wed Aug 21 23:50:40 2013 KojiUpdateSUSPRM SUS_LSC violin (FM5) set to correct frequency

[Jenne Koji]

It seems that the PRM violin mode freqs shifted from 625-ish to 640Hz.
The peaks rang up because of the servo.

Once the notch freq was shifted to 640Hz, the violin mode started to decay.

ellip("BandStop",4,1,90,636,644) gain(1.12202)

  9047   Wed Aug 21 19:37:25 2013 MasayukiSummaryGreen LockingX-arm PDH OLTF measurement

[Manasa, Masyauki]

Today we measured OLTF of PDH green lock of x-arm again. In the previous measurement the excitation signal was injected at the PDH servo box output(elog 9044), but in this measurement we changed the injection point to the RFPD mixer output (just before the servo input).

We measured the OLTF with the servo gain of 6.5 and source amplitude of 5 mV for all frequency band. The measured UGF was 11 kHz and the phase margin was 48 degree.

Next that measurement, we tried to measure the power spectrum density of the error signal and feedback signal. But the alignment was not so good, so we aligned the green light injection point. Tomorrow we will continue the alignment and will measure the PSD.

attatchment1 - OLTF of PDH green lock with servo gain of 6.5

OLTF_PDH_Glock_6_5_2.png

  9046   Wed Aug 21 19:26:19 2013 ranaUpdateIOOFound the cause of mysterious MC motion

Quote:

Yes, this was not ELOG'd by me, unfortunately. This was the MC tickler which I described to some people in the control room when I turned it on.

As Koji points out, with the MCL path turned off this injects frequency noise and pointing fluctuations into the MC. With the MCL path back on it would have very small effect. After the pumpdown we can turn it back on and have it disabled after lock is acquired. Unfortunately, our LOCKIN modules don't have a ramp available for the excitation and so this will produce some transients (or perhaps we can ezcastep it for now). Eventually, we will modify this CDS part so that we can ramp the sine wave.

 I've written a new TICKLE script using the newly found 'cavget' and 'cavput' programs. They are in the standard epics distribution as extension binaries. They allow multichannel read/write as well as ramping, delays, incremental steps, etc. http://www.aps.anl.gov/epics/tech-talk/2012/msg01465.php.

Running from the command line, they seem to work fine, but I've left it OFF for now. I'll switch it into the MC autolocker at some point soon.

  9045   Wed Aug 21 17:42:03 2013 ranaSummaryGeneral/home/cds nearly full

One of the reasons that our disk is getting full is due to the scripts_archive directory. A backup script runs on op340m and makes a tar.bz2 file of the scripts directory and puts it in scripts_archive every morning at 6 AM.

On Oct 7, 2011, Koji fixed this script to point at our new scripts directory instead of the old /cvs/cds/caltech/scripts directory. Since then, however, no one has fixed the exclude file to NOT back up the junk that's in that directory. Its a 1.6 GB directory so its full of it.

I've deleted a bunch of junk from the scripts directory: this directory is for scripts, not for your personal home movies or junk data files. Put those in your USER directory. Put temporary data files in /tmp/. I've also added a few more patterns to the exclude file so that less .mpg, .png, .pdf, .dat, etc get stored every day. The new daily .tar.bz2 file wil be ~25 MB instead of 770 MB.

(also fixed the backup script to use 'env' to setup the perl environment and removed the hard-coded path to tar)

  9044   Wed Aug 21 00:18:03 2013 MasayukiSummaryGreen LockingX-arm PDH OLTF measurement

[Manasa Masayuki]
Today we measured the openloop transfer function of the PDH green lock of the x-arm.

Edit //manasa// The excitation was given from SR785 source. SR560 was used as the summing node at the PDH servo box output where the loop was broken to measure the OLTF. The SR785 was used to measure the frequency response (CH2/CH1; CH1 A SR560 output and CH2 A PDH servo output) in sweptsine mode.

We measured with two different servo gain. We started with the servo gain of 3 and at that gain the UGF was 1.5 kHz and the phase margin was 50 degree. After that we increase the servo gain to 5.5 and at that gain the UGF was 6.2 kHz and the phase margin was 55 degree. In all the measurement we use the source amplitude of 1.0 mV for all frequencies (from 100 Hz to 100 kHz). We could not increase the gain and also the source amplitude any more because the green was kicked out of lock.

Next work list
1. In the earlier measurements we found the UGF of the PDH green lock of the x-arm as 10 kHz and the phase margin as 45 degree, so we will investigate what has changed from these measurements.elog 4490

2. We will measure the power spectrum of the error signal and the feedback signal.

3. We will calibrate the above signals to compare with ALS out of loop noise.

netgpib was taking forever to transfer data. So the measurements are just photos of the display.

attachment1 - servo gain 3

IMG_1226.JPG

attachment2 - servo gain 5.5

IMG_1228.JPG

  9043   Tue Aug 20 18:42:57 2013 JenneUpdateLSCREFL investigations

I have done the swap in the REFL path.  First, I swapped the positions of REFL11 and REFL55.  Then, I swapped out the 50/50 BS for a 90% reflection BS.  (90% goes to REFL55, 10% goes to REFL11).  I also changed the aluminum dump that was dumping the old REFL165 path into a razor dump.

Before: REFL11 had 4.0mW, REFL55 had 3.1mW.  Now, REFL11 has 0.53mW, and REFL55 has 6.9mW.  REFL165 still has around 61mW of light, and REFL33 has 3.3mW (the things that were changed were after 165 and 33 in the REFL path). 

Now, the DC value of the REFL PDs are:  REFL165 = 10.4V, REFL33 = 110mV, REFL55 = 232mV, REFL11 = 18.6mV. 

As I was finishing aligning the beams onto all of the REFL diodes, Manasa asked for the IFO so she and Masayuki could continue their work on the Xarm, so I'll check the signals acquired a little later.

  9042   Tue Aug 20 16:23:41 2013 ranaSummaryGeneral/home/cds nearly full

/home/cds is >98% full - below are some of the usage numbers:

controls@rosalba:/users/OLD 0$ du -h --max-depth=1
42M    ./katrin
1.5M    ./ben
2.4M    ./sanjit
569M    ./waldman
328M    ./sonia
3.6G    ./lsinger
44M    ./dbusby
105M    ./dbarron
21M    ./manuel
709M    ./yaakov
46M    ./rodionov
240M    ./ishwita
2.7G    ./clara
56M    ./gopal
290M    ./mashaB
87M    ./varvella
5.6M    ./Sascha
2.9G    ./ryan
190M    ./nancy
3.5G    ./john
269M    ./elizabeth.davison
165M    ./jweiner
460K    ./mjones
49M    ./stephanie
52M    ./mohana
56M    ./noriyasu
38M    ./mjenson
76M    ./sballmer
224M    ./kirk
812K    ./bonnie
33M    ./janosch
16M    ./kevin
122M    ./dblair
2.6G    ./mirko
389M    ./keenan
195M    ./tf
150M    ./littlezach
193M    ./jmiller
1.8G    ./ting
131M    ./dmalling
842M    ./sharmila
1.4G    ./caryn
12G    ./rward
4.1M    ./jay
443M    ./emintun
184M    ./katharine
76K    ./nick
804K    ./nicole.ing
14M    ./jenny
542M    ./vsanni
45M    ./peter
7.8G    ./miyakawa
4.8M    ./channa
4.0K    ./frank
9.9G    ./razib
35M    ./amin
361M    ./sharon
62M    ./bram
3.9M    ./volodya
7.9M    ./larisa
301M    ./sasha
33M    ./eric.hendries
18M    ./vuk
101M    ./huan
1.8M    ./sonali
453M    ./megan
43M    ./Royal
5.4G    ./ayaka
19M    ./mott
518M    ./justing
501M    ./avi
173M    ./kakeru
3.9G    ./alberto
41M    ./paul.fulda
59M    ./elena
67G    .

controls@rosalba:/opt/rtcds/userapps 0$ du -h --max-depth=1
1.4G    ./tags
13M    ./trunk.bak
40K    ./.svn
3.0G    ./trunk
174M    ./trunk.bak2
4.2G    ./branches
8.7G    .

linux1:cds>nice du -h --max-depth=1
du: `./llo/chans/daq/archive': Permission denied
du: `./llo/chans/daq/old': Permission denied
707M    ./llo
9.7M    ./mit~
752K    ./raidwebFirmware
462M    ./epics
2.1G    ./tmp
1.5G    ./gds
76M    ./project
9.1G    ./ligo
449G    ./rtcds
3.3G    ./apps
20K    ./.kde
512K    ./cdscfg
1.4M    ./.Trash-controls
5.8M    ./scripts
20K    ./.TemporaryItems
964G    ./caltech
71M    ./bin
16K    ./.Trash-1001
4.5G    ./rtapps
564M    ./src
11M    ./vw
3.8M    ./dvSave
460M    ./lho
1.2G    ./data
1.5T    .

  9041   Tue Aug 20 11:52:20 2013 JenneUpdateLSCREFL investigations

Quote:

As I always tell everyone: Don't use a 10% reflector which produce ghost beams. Use a 90% reflector. 

 Hmmm, yes, I forgot (bad me).  I'll find a 90% refl BS, and swap the positions of REFL11 and REFL55.

  9040   Tue Aug 20 11:41:30 2013 KojiUpdateLSCREFL investigations

As I always tell everyone: Don't use a 10% reflector which produce ghost beams. Use a 90% reflector.

  9039   Tue Aug 20 10:59:15 2013 SteveUpdateGreen LockingXend green layout corrections

Quote:

 Shutter moved, no more clipping.

Pick-off mirror 2" replaced by 1" one. Laseroptik HR 532nm, incident angle 30-45 degrees, AR 532 nm

Green REFL PD moved to 4" close to pick-off mirror. Pd being close to pick-off does not separate multiple reflections on it. I'll replace Laseroptic mirror with Al one. It is not easy to find.

 Hole cut into side wall for doubler oven cable to exit.

 

 

 Beam trap for Pd refl is in place. Cabeling is ti·died up.

 Laseroptic 1" mirror is replaced by Al 1" mirror. Problem remains the same. This diffraction patter has to be coming from the Faraday.

  Atm1, good separation when Pd is far 

  Atm2, bad separation when Pd is close 

Attachment 1: faraway.jpg
faraway.jpg
Attachment 2: closer.jpg
closer.jpg
  9038   Tue Aug 20 01:28:47 2013 JenneUpdateLSCREFL investigations

According to the wiki, REFL 11 has a transimpedance of 4.08kV/A, and REFL 55 has a transimpedance of 615V/A.  This is a ratio of ~6.5 .  My optickle simulations from earlier this evening indicate that, at maximum, there is a ~factor of 2 more signal in REFL 11 than REFL 55.  This is a factor of order 10-15.  Then, REFL 55 has 15dB whitening gain, which is a factor of ~4.  So, this explains why we're seeing so much more digital signal on REFL11 than REFL55.

Tomorrow, I need to replace the 50/50 beam splitter that splits the beam between REFL55 and REFL11 (33 and 165 have already had their light picked off at this point).  I want to put in a 10% reflector, 90% transmission beamsplitter.  Steve, can you please find me one of these, and if we don't have one, order one? This will give us a little more light on 55, and less light on 11, so hopefully we won't be saturating things anymore.

 

  9037   Tue Aug 20 00:19:23 2013 ranaUpdateLSCPRMI / DRMI investigations

While Jenne was plotting, I locked and aligned the MICH with AS55_Q. Then I aligned the PRM and locked PRMI using REFL55_I/Q with triggering on POP22, but no power normalization.

I used this to set the phase for REFL11 and REFL55 (driving PRM at 111.3 Hz and minimizing the Q response using the DTT Sine Response tool). I flipped the sign on REFL11 by 

The REFL11 gain is ~50x larger than REFL55; this is with the 15 dB whitening gain on REFL55 and none for REFL11. What's going on here? The attached PDF shows the two time series with the free swinging PRMI and both phases set to ~ +/- 2 deg. The REFL55 signals have been scaled up by 50x.

So then we went in and looked at the RF signals at the demod boards. To do this we disconnected the RFPD test cables and hooked the RF Mon outputs into the 50 Ohm inputs on a scope. The following PNG images show the scope traces. The REFL11 (yellow) traces are too big!! See how small the REFL55 (green) are. REFL11 is saturating - need to fix.

TEK00000.PNGTEK00001.PNG

TEK00002.PNGTEK00003.PNG

Attachment 1: REFL.pdf
REFL.pdf
Attachment 6: REFL-2.pdf
REFL-2.pdf
  9036   Mon Aug 19 23:08:31 2013 JenneUpdateLSCDRMI sensing signals

Here are a bunch of sensing signals.  The configuration is always DRMI.  Except for the optic noted in the title and the x-axis of any individual plot, other optics are held in their nominal position.  DRMI condition is sidebands resonant in PRCL, 55MHz sideband resonant in SRCL.  Each plot has an error signal, as well as the 2f signals at POP and AS.

 The phases of POP22 and POP110 have been adjusted so that the I signal is maximized when everything is at the nominal positions (sideband resonant for PRMI).  The phase of AS110 has been adjusted so that the I signal is maximized when the DRMI is in the nominal position (f2 resonant in SRC).  The phases of the 1f1, 1f2, 2f1 and 2f2 REFL signals were all adjusted to have max PRCL signal in the I phase.  AS55 was adjusted to have max SRCL signal in the Q phase.

 DRMI_PRM_REFL11I.png

DRMI_PRM_REFL33I.png

DRMI_PRM_REFL55I.png

DRMI_PRM_REFL165I.png

DRMI_MICH_REFL11Q.png

DRMI_MICH_REFL33Q.png

DRMI_MICH_REFL55Q.png

DRMI_MICH_REFL165Q.png

DRMI_SRM_REFL55Q.png

DRMI_SRM_REFL165Q.png

DRMI_SRM_AS55Q.png

 

  9035   Mon Aug 19 19:08:35 2013 KojiUpdateGreen LockingXend green layout corrections

- An Aluminum mirror instead of 2" unknown mirror for the pick-off for the rejected beam from the green faraday isolator (Steve)
=> Replaced. To be reviewed

- Faraday mount replacement. Check what we have for the replacement. (Steve)

- The green REFL PD should be closer to the pick-off mirror. (Steve)
=> Moved. To be reviewed

- A beam dump should be placed for the green REFL PD

- Move the green shutter to the place where the spot is small (Steve)
=> Moved. To be reviewed.

- The pole of the PZT mounting should be replaced with a reasonable one. (Steve with Manasa's supervision)

- Tidying up doubling oven cable. Make a hole on the wall. (Steve)
=> Done. To be reviewed.

- Tidying up the PZT cabling (Steve)

- The optics are dirty. To be drag wiped. (Manasa, Masayuki)

  9034   Mon Aug 19 17:40:32 2013 SteveUpdateGreen LockingXend green layout corrections

 Shutter moved, no more clipping.

Pick-off mirror 2" replaced by 1" one. Laseroptik HR 532nm, incident angle 30-45 degrees, AR 532 nm

Green REFL PD moved to 4" close to pick-off mirror. Pd being close to pick-off does not separate multiple reflections on it. I'll replace Laseroptic mirror with Al one. It is not easy to find.

 Hole cut into side wall for doubler oven cable to exit.

 

 

Attachment 1: beforeC.jpg
beforeC.jpg
Attachment 2: nowC.jpg
nowC.jpg
Attachment 3: stillMultiple.jpg
stillMultiple.jpg
  9033   Mon Aug 19 16:18:56 2013 manasaUpdateGreen LockingXend green aligned

ASX scripts for PZT dither have been fixed appropriately. Script resides in scripts/ASX.

You can run the scripts from the ASX medm screen now.

  9032   Mon Aug 19 15:23:07 2013 KojiUpdateIOOMC mirrors' ASC has non-zero inputs

[Jenne, Koji]

This disturbance in the MC ASC channels were fixed.

This craziness happened ~10pm last night. Was there any action at the time? >> Sunday-night workers? (RXA: No, Nakano-kun and I left before 9:30 PM)

We found that the signals came from c1ioo. However, restarting, recompiling c1ioo and c1mcs didn't help
to clean up this issue. Just in case we cleaned up the corresponding entries in the ipc file /opt/rtcds/caltech/c1/chans/ipc/C1.ipc
and recomplied c1ioo and c1mcs because these are the channels we touched last week to mitigate the timing out issue of c1rfm.

Incidentally, we fell into a strange mode of the RCG: IOPs could not restart. We ended up running "sudo shutdown -r now"
on each machine (except for c1lsc which was not affected by this issue). This solved the issue.

Even now c1oaf could not be running properly. This is not affecting the IFO operation right now, but we need to look into this issue again
in order to utilize OAF.

  9031   Mon Aug 19 14:22:36 2013 ranaUpdateGreen LockingXend green aligned

  9030   Mon Aug 19 11:30:20 2013 JenneUpdateIOOMC mirrors' ASC has non-zero inputs

[Masayuki, Jenne]

When I came in this morning, I noticed that the Mode Cleaner had not been locked for at least the past 8 hours.  We moved the MC SUS sliders until the MC SUSPIT and SUSYAW values for each mirror were back to approximately the place they were the last time the MC was nicely locked (~12 hours ago).  This got the MC flashing TEM00, so we thought we were doing well. 

However, if the servo was enabled, any time the cavity flashed a small-order mode (especially 00), the mirrors would get super kicked.  Not good

We went to investigate, and discovered that the RFPD aux laser was left on again.  We turned that off, however that didn't fix the situation. 

Manasa suggested checking that the WFS were really, really off.  When we looked at the WFS master screen, we noticed that although the WFS servos were off, the MC mirrors' ASC filter banks had non-zero inputs.  We checked, and this is not from the MCASS, nor is it from the MC WFS lockins.  At this point, I have no idea where these signals are coming from.  I have turned off the ASC outputs for all the MC mirrors (which means that we cannot turn on the WFS), and the MC locks fine

So, we need to know where the ASC signals are coming from.  There isn't anything that I can see, from any screen that I can find, that indicates some signals being sent over there.  Has anyone done anything lately?  I know Koji was working on IPC stuff the other day, but the MC was locking fine over the weekend until yesterday afternoon, so I suspect that's not the culprit. 

I have turned off the outputs of the WFS lockins, as part of my turning things off, so if whatever script needs them doesn't enable them, they should be turned back on by hand.

  9029   Mon Aug 19 11:12:54 2013 SteveUpdateVACRGA scan at day 13

 

 

Attachment 1: rgaScan13d.png
rgaScan13d.png
ELOG V3.1.3-