40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 54 of 341  Not logged in ELOG logo
ID Date Authordown Type Category Subject
  9292   Fri Oct 25 19:56:58 2013 ranaUpdatePSLlaser drift monitor set up


 I went to re-align the beam into the PMC just now. I also tapped all the components between the laser and the PMC; nothing seems suspicious or loose.

The only problem was that someone (probably Steve or Valera) had closed down the iris just downstream of the AOM to ~1-2 mm diameter. This is much too tight! Don't leave irises closed down after aligning. An iris is not to b used as a beam dump. Getting it within a factor of 5-10 of the beam size will certainly make extra noise from clipping/scattering. After opening the iris, the reflected beam onto the PMC REFL camera is notably changed.

Not sure if this will have any effect on our worsening transmission drift, but let's see over the weekend.

I took pictures of this clipping as well as the beam position on Steve's new Retro Position Sensor, but I can't find the cable for the Olympus 570UZ. Steve, please buy a couple more USB data cables of this particular kind so that we don't have to hunt so much if one of the cryo (?) people borrows a cable.

Attachment shows PMC power levels before and after alignment. After alignment, you can see spikes from where I was tapping the mounts in the beamline. We ought to replace the U-100 mount ahead of the AOM with a Polanski

EDIT: Cryo team returns cable - receives punishments. Picture added.

  9297   Sat Oct 26 22:48:55 2013 ranaUpdateCDSNew/old CDS laptop for X-End

  I made the Yoichi laptop into a CDS laptop called 'asia' a few months ago. Somehow I mistakenly gave it the IP address of our little Acer laptop which is called 'farfalla'. This makes farfalla's network not work. I put the old Dell Aldabella by the PMC where farfalla was and am now upgrading farfalla from CentOS to Ubuntu 10.04 LTS 32-bit. I have updated the hostable on linux1 to give farfalla the 230 IP address and let 'asia' keep 225.

  9299   Sun Oct 27 03:41:06 2013 ranaUpdateSUSETMX violin mode

  I thought it would be enough to notch the fundamental and the first harmonic, but sometime tonight the 2nd harmonic at 1892.88 Hz also got rung up.

I made a "Violin3" stopband filter for it and measured its Q using the ole DTT heterodyne secret handshake. Seems much too high to me - it would be nice if someone else would look at this plot and estimate the Q from it.

Turned the PSL HEPA switch back ON - I think its been off for at least a week. I turned the HEPA's variac to 20 after finishing the alignment on the table.

  9301   Sun Oct 27 23:26:44 2013 ranaUpdatePEMSeismometer status

 It would be nice if we could use the existing seismometer cable and place a 2-terminal temperature sensor within the stainless-steel can. A device like the AD590/592 can drive current over a long cable run without pickup issues since its a current source. Inside of the seismometer breakout box we should make a circuit to scale the signal to be close to zero at 25 C and have a slope of 1 V/deg. There are example circuits in the application note - we can just make them on a piece of vector board and glue to the inside of the breakout box (where we connect to the regulated power).

  9311   Tue Oct 29 22:33:57 2013 ranaUpdateSUSETMY sensors compared to ETMX


I've stopped the process of c1tst again to make it get better. At 9:20, I also went and opened the front rack door (the back one was already open). One reason its hot may be that the exhaust vents on the top of c1iscey are blocked by one of the custom multi-pin adaptor boxes. In the morning, we should drop the computer down by 1 or 2 notches in the rack so that it can air cool itself better. Make sure to poweroff the computer from the terminal before moving it though.

 After some torture Masayuki admitted that he and Steve ignored this elog and just turned off the power button. He blames Steve entirely.

to keep from damaging our computers and our data, NEVER DO THAT.


  9346   Tue Nov 5 16:47:19 2013 ranaFrogsLSCillegal power supply about to expire

 Is this your illegally installed HP bench power supply?


If so, or if not but you care about the signal that passes through these amplifiers, I suggest you remove this temporary power supply and wire the power from the rack power supplies through the fuse blocks and possibly use a voltage regulator.

In 24 hours, that power supply will be disconnected and the wires snipped if they are still there.

  9351   Tue Nov 5 19:55:12 2013 ranaUpdateSUSoplev XY-plots reflect new calibration

I used the same OSEM SUSPIT/YAW method as before to calibrate the ETMY optical lever signals. They were off by a factor of ~10.

ETMY Pitch     300  /  26    (old/new)     urad/counts

ETMY Yaw       300  /  31    (old/new)     urad/counts

These should be redone with the Kakeru / Ottaway arm cavity power technique if we want to get better than ~30% accuracy.

  9364   Mon Nov 11 12:19:36 2013 ranaUpdateCDSFE Web view was fixed


FE Web view was broken for a long time. It was fixed now.

The problem was that path names were not fixed when we moved the models from the old local place to the SVN structure.

The auto updating script (/cvs/cds/rtcds/caltech/c1/scripts/AutoUpdate/update_webview.cron) is running on Mafalda.

Link to the web view: https://nodus.ligo.caltech.edu:30889/FE/

 Seems partially broken again. Not updating for most of the FE. I've commented out the cron lines for this as well as the mostly broken MEDM Snapshots job. I'm in the process of adding them to the megatron cron (since that machine is at least running 64 bit Ubuntu 12, instead of 32-bit CentOS)

  9366   Tue Nov 12 15:04:35 2013 ranaUpdateCDSFE Web view was fixed


 Seems partially broken again. Not updating for most of the FE. I've commented out the cron lines for this as well as the mostly broken MEDM Snapshots job. I'm in the process of adding them to the megatron cron (since that machine is at least running 64 bit Ubuntu 12, instead of 32-bit CentOS)


Seems to now be working. I made several fixes to the scripts to get it working again:

  1. changed TCSH scripts to BASH. Used /usr/bin/env to find bash.
  2. fixed stdout and stderr redirection so that we could see all error messages.
  3. made the PERL scripts executable. most of the PERL errors are not being logged yet.
  4. fixed paths for the MEDM screens to point to the right directories.
  5. the screen cap only works on screens which pop open on the left monitor, so I edited the screens so that they open up there by default.
  6. moved the CRON jobs from mafalda over to megatron. Mafalda no longer is running any crons.
  7. op540m used to run the 3 projector StripTool displays and have its screen dumped for this web page. Now zita is doing it, but I don't know how to make zita dump her screen.
  9368   Tue Nov 12 21:50:01 2013 ranaUpdate zita network configured


 I installed 'nfs-client' on zita (the StripTool terminal). It now has mounted all the shared disks, but still can't do StripTool since its a 32-bit machine and our StripTool is 64.

  9369   Tue Nov 12 23:05:06 2013 ranaUpdatePEMthump noise from particle counter

The particle counter is back on the IOOC location on a piece of FOAM
It needs this isolation, so when the pump is running, it's not shaking things.
The counter was counting for 6 sec and it was on holding for 20 mins.
Now I set the counter for 20 sec so it is easy to recognise it's signal and it holds for 2min only.
This will set the alarm handler in action.

Atm1: 40 mins plot
PEM-ACC_MC2_x,y,z up to 13 mins: pcounter at MC2 table, clamped, counting for 20s and holds for 2 mins
PEM-ACC_MC2_x,y,z from 13 to 26 mins: pcounter at MC2 table, not clamped, seated on 2" foam, counting 20s and holds for 2 mins
PEM-ACC_MC1_x,y,z from 26 to 40 mins: pcounter at MC1_IOOC location, not clamped, seated on 2" foam, counting 20s and holds for 2 mins

Rana won the bet

This noise source from 2008 is back. Somehow the particle counter snuck back up to the top of the BS chamber. Bad, noisy particle counter. Let's move it away from out sensitive optics and put it on the wall next to the router or maybe on some toolbox. Not on optics tables, chambers, or near them.
  9377   Wed Nov 13 18:37:19 2013 ranaConfigurationElectronicsDAC available in c1lsc IO chassis for DAFI

The first picture shows that there is indeed a DAC next to the ADC in the LSC IO chassis. The second picture shows how there are two cables, each one carrying 8 channels of DAC. The third one shows how these come out of the coil drivers to handle the Tip/Tilt mirrors which point the beam from the IMC into the PRC. It should be the case that the second Dewhitening filter board can give us access to the next 8 channels for use in driving an audio signal into the control room or an ISS excitation.

  9381   Thu Nov 14 00:33:37 2013 ranaConfigurationPSLPMC LO is dying...

Back in 2009, Jenne replaced the PMC board mixer with a Level 13 one. Today I noticed that the LO level on the PMC screen was showing a LO level of ~5-10 dBm and fluctuating a lot. I think that it is related to the well known failure of the Mini-Circuits ERA-5SM amplifier which is on the D000419-A schematic (PMC Frequency Reference Card). The Hanford one was dying for 12 years and we found it in late 2008. If we don't have any in the blue bin, we should ask Steve to order 10 of them.

The attached trend shows 2000 days of hour trend of the PMC LODET channel. The big break in 2009 is when Jenne changed the mixer and then attenuated the input by 3 dB. The slow decay since then is the dying amplifier I guess.

Since the LOCALC channel was not in the trend, I added it to the C0EDCU file tonight and restarted the FB DAQD process. Its now in the dataviewer list.

I went out and took out the 3 dB attenuator between the LO card and the PMC Mixer. The LO monitor now reads 14.9 dBm (??!!). The SRA-3MH mixer data sheet claims that the mixer works fine with an LO between 10 and 16 dBm, so I'll leave it as is. After we get the ERA-5, lets fix the LODET monitor by upping its gain and recalibrating the channel.

  9383   Thu Nov 14 02:55:26 2013 ranaUpdateSUSPRM motion correlated to intracavity power


Some more words about the ISS -> OSEM measurement:

The calibration of the OSEMs have been done so that these channels are each in units of microns. The SIDE channel has the lower noise floor because Valera increased the analog gain by 5x some time ago and compensated with lower digital gain.

The peak heights in the plot are:

UL   0.85

LL   0.78

UR   0.61

LR   0.45

S    0.27

So that tells us that the coupling is not uniform, but mostly coming in from the left side (which side is the the SIDE OSEM on?).

Jenne and I discussed what to do to mitigate this in the loops. Before we vent to fix the scattering (by putting some covers around the OSEMs perhaps), we want to try to tailor the OSEM damping loops to reduce their strength and increase the strength of the OL loops at the frequencies where we saw the bulk of the instability last time.

Jenne is optimizing OL loops now, and I'm working on OSEM tweaking. My aim is to lower the overall loop gains by ~3-5x and compensate that by putting in some low Q, resonant gain at the pendulum modes as we did for eLIGO. We did it here at the 40m several years ago, but had some troubles due to some resulting instability in the MC WFS loops.


In parallel, Steve is brainstorming some OSEM shields and I am asking around LIGO for some AC OSEM Satellite modules.

  9431   Sat Nov 30 23:50:28 2013 ranaUpdateIOOmode cleaner not locking


 I used our procedure from this entry to set the IMC board offset as well as the FSS board offset.

I found this afternoon that the MC was having trouble locking: the PC path was railing as soon as the boost was engaged. Could be that there's some misalignment on the PSL which has led to some RAM having to be canceled by this new offset. Let's see if its stable for awhile.

 I felt in my bones that the MC was in trouble so I came by and noticed that it hadn't locked for a couple hours. The FSS SLOW was at -1.6V, but putting it back to zero didn't fix things. I adjusted the FSS error point offset to +1 and that took the FSS_FAST off of the +10 V rail. Relocked and seems OK.

We need to plan to make the M Evans mod to the FSS box to make the PC drive less angry.

Last 40 days of MC Alignment trends  show that the recent MC WFS tuning / offseting worked out OK. MC REFL seems low and flat.

  9472   Sat Dec 14 11:56:54 2013 ranaUpdateLSCcommon mode servo



 It seems to me that current design of the common mode servo is already fine. Attached plots show common mode open and closed loop transfer function.

 These seem like pretty terrible loop shapes. Can you give us a plot with the breakdown of several of the TFs and some .m file?

We should be able to estimate the noise coming out of the MC using the single arm and then make a guess for the CM loop gain requirement. There's no reason to keep the old Boost shapes; those were used in the old MC configuration which had a RefCav. In addition to minimizing the EOM range, we should also minimize the AO signal as Koji has pointed out. In practice, I've seen that using ~300 Hz of offset makes no harm with 4 kHz MC pole.

  9476   Sun Dec 15 20:37:41 2013 ranaSummaryTreasureThere is a Wagonga in the container that Steve does not believe in

From Linda and Bram:

  9481   Tue Dec 17 14:06:59 2013 ranaUpdateLSCNew Broadband PD for POP 22/110

 I looked at the BBPD design so that we could make a POP22/110. It looks like it will be easy (I hope).

 The first attachment shows the schematic with the RF notch modified to handle 55 MHz. As long as the capacitor in this notch can be kept to below 20 pF, it doesn't degrade the noise so much,

The second attachment shows the TF and input referred noise. We ought to be able to get 20 pA/rHz at the input to the first RF amplifier.

The LISO files are in the svn under liso/examples/aLIGO_BBPD/,

Later, if we have to notch more than just 55 MHz, we can add a notch between the 2 RF amplifiers as Koji has done for the REFL165.

  9486   Wed Dec 18 11:32:34 2013 ranaUpdateLSCXend QPD schematic investigation


 Since we use the TransMon QPD for triggering the high/low gain switching we need to run with the whitening OFF during lock acquisition and the turn it on after we have the arms locked with ALS. This should be put into the up/down scripts.

  9517   Fri Jan 3 15:19:39 2014 ranaSummaryPSLPSL pointing monitoring

 This is a 10-minute trend of the last 60 days of the pointing of the PSL beam.

The main fluctuation seems to be at the ~30 day time scale (not 24 hour) and its all in the vertical direction; the horizontal drift is ~10x less (as long as we believe there is no calibration error).

So what's causing all of this vertical shift? And why is there not just as much horizontal??

  9518   Fri Jan 3 18:21:45 2014 ranaSummaryPSLPSL pointing monitoring


 I went to the PSL table to re-align the input pointing to the IMC. After trying to optimize the pointing into the PMC and not succeeding I also then touched the wrong mirror and messed up our IOO QPD reference pointing.

The IMC is locking again, but I'll have to fix the pointing on Monday.

  9525   Tue Jan 7 11:11:36 2014 ranaUpdateIOOMC drift


 NOT drift. The sudden steps are certainly the result of being kicked. The slow drift at the end of the day might be a slow strain relaxation.

It pays to be careful and not put too much weight or impulsive forces on the chambers or tables.

  9543   Thu Jan 9 17:21:45 2014 ranaUpdateGeneralIFO plan, IPANG telescope


For the IPANG telescope design, we are in the 'beyond the Rayleigh range' regime. So using a single lens to make the beam small is not a great idea. I

Can you please explain this? I don't understand what exactly is the issue or 'great idea'.

I think we should be OK with just a single lens in the vacuum. But what we need is the ray tracing analysis to show what the effect will be on the IPANG readout.

  9546   Fri Jan 10 15:31:07 2014 ranaSummaryLSCEffect of PRC length mismatch on error signals


 Its very doubtful that the MC yaw drift matters for the IFO. That's just a qualitative correlation; the numbers don't hang together.

  9578   Mon Jan 27 17:49:46 2014 ranaHowToComputer Scripts / Programssendmail started on nodus: fixing SwiftMail on Dokuwiki

Since the recent filesystem fracas, the new accounts could not be created on nodus / dokuwiki (for the controls workshop, for example).

I started sendmail on nodus using the command:   sudo /etc/init.d/sendmail start

and the SwiftMail plugin on there is now sending out the confirmation emails again. This will happen each time we reboot nodus, so let's replace it.

  9603   Wed Feb 5 18:36:56 2014 ranaFrogselogMicroSoft BingBot is attacking us

 The ELOG was frozen, with this in the .log file:   

GET /40m/?id=1279&select=1&rsort=Type HTTP/1.1

Cache-Control: no-cache

Connection: Keep-Alive

Pragma: no-cache

Accept: */*

Accept-Encoding: gzip, deflate

From: bingbot(at)microsoft.com

Host: nodus.ligo.caltech.edu

User-Agent: Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)

  (hopefully there's a way to hide from the Bing Bot like we did from the Google bot)


  9620   Mon Feb 10 19:56:10 2014 ranaUpdateASCPRM ASC better, but not great yet

Ignoring the OSEM damping loops, the oplev servo loops make it so that the POP ASC loops do not see a simple pendulum plant, but instead see the closed loop response. Since the filter in the OL bank is proportional to f, this means that the open loop gain (OLG):


Which means that the CLG that the ASC sees is going to dip below unity in the band where the OL is on. For example, if the OL loop has a UGF of 5 Hz, it also has a lower UGF of ~0.15 Hz, which means that the ASC needs to know about this modified plant in this band.

For i/eLIGO, we dealt with this in this way: anti-OL in iLIGO

  9667   Mon Feb 24 23:43:10 2014 ranaSummaryGeneralToDo

1) Fixup REFL165: remove ND filters, get box for PD, dump diode reflections, put less light on diode, change DC transimpedance (?), max power dissipation on BBPD < 0.5 W w/ 25 V bias. Perhaps replace OP27 with TLE2027.

2) Make plan for fixing fiber layout up and down the arms. Need tubing for the whole run. Don't make it cheesy. Two fibers per arm.

3) Fix LSC model to allow user switching of whitening. Get back to working on AutoLock scripts (not Guardian).

4) Manasa, Q, Jenne, tune Oplev servos Tuesday morning/afternoon.

5) Reconnect the other seismometers (Steve, Jenne). For real.

6) Balance PRMI coils at high frequency.

  9682   Thu Feb 27 22:25:29 2014 ranaUpdateSUSOplev Tuning Party - round 1 commentary

  in order to Win in Loop Tuning, you must draw a cartoon of the cost function on the whiteboard before starting. Some qualitative considerations from our Workshop:

  1. We want to use the oplev servo to reduce the motion of the mirror in the frequency band where the Oplev is quieter than the mirror, w.r.t. inertial space.
  2. We can estimate the true mirror motion by some simple stack / pendulum model and compare it to the Oplev noise (not the dark noise). There are several contributions to the mirror angular motion due to the cross-coupling in the stacks and pendula.
  3. Below ~0.2 Hz, we think that the oplev is not the right reference, but this is not quantitative yet.
  4. The high frequency noise in the OPLEV ERROR is definitely electronics + shot noise.
  5. We cannot increase the gain of the loop without posting some loop measurements (Bode + steps). Also have to post estimates of how much PRCL noise is being introduced by the Oplev feedback. Oplev feedback should make less length noise than what we have from seismic.

Give us a cost function in the elog and then keep tuning.

  9688   Mon Mar 3 23:16:06 2014 ranaUpdateLSCY Arm Loop Shape found to be weird: changed now

 I was getting the Y Arm ready for Eric Q's loss measurements and so I looked at the noise and loop shape. The loop shape was strange:


You can see that the gain margin is too low at high frequencies. That's why we have >15 dB of gain peaking. Way too much! I think this is from Masayuki and Manasa increasing the phase margin at some point in the past. I lowered the gain by 3 dB from 0.1 to 0.07 and now the awful gain peaking is less. But what about the low frequency gain? Is there enough?



I calibrated the OUT channel with 14 nm/count (1/f^2) with a Q = 10 pole pair at 1 Hz. The error signal is done to cross over at 180 Hz. It looks like the resonant gain at 25 Hz is a little too much and the in-loop RMS is 10 pm. Jenne says the linewidth is ~1 nm, so this seems sort of OK. Except that the LIGO-I DARM RMS had to be <0.1 pm for ~the same linewidth. Do we need to do better before trying to bring the arms into resonance?

I've remove FM1 and FM8. I put the RollRG of FM8 into the BounceRG and renamed it BounceRoll. Also changed the Y-arm restore so that RollRG and the 5,5:0,0 are no longer triggered automatically since the double integrator was overkill and we already have a 1:0 in FM2. I also lowered the peak gain for the roll mode RG from 30 to 10 dB because it was also overkill. We've gained a few more degrees at the UGF.

  9700   Thu Mar 6 17:34:03 2014 ranaUpdateSUSOplev Tuning - Cartoon cost function



 In addition, we have to make sure to not let the suspension DACs saturate and make sure that the impulse response time of the OL servo is short; otherwise the lock acquisition kicks or bumps can make it wiggle for too long.

  9734   Mon Mar 17 20:44:42 2014 ranaUpdateSUS4.4M local earthquake
  9744   Sun Mar 23 14:20:07 2014 ranaHowToLSCBLRMS screens

 We should make screens like this for the LSC signals, errors, ALS, etc.

  9759   Fri Mar 28 20:23:02 2014 ranaSummaryIOOMC2 moved

I aligned MC2 suspension by 0.01 in pit and yaw to align the MC better to the PSL beam. Then I turned the WFS back on. The beams are not centered on the WFS heads.

Nic and Gabriele ought to send their SURF some example code (in April) for how to start redesigning the WFS telescopes so that we can order some optics in early June.

I've also turned on the MC2 TRANS path to gather some data over the weekend on how well or bad it works. Please turn it off on Monday.

  9789   Tue Apr 8 19:10:39 2014 ranaUpdateLSCarm length measurements

 Since we don't have an arm length precision measurement (i.e. better than centimeters), why not just do as Koji suggests and use the ALS to get the frequency spacing between a few red FSR and then we have the measurement solid ?

  9805   Sun Apr 13 13:03:34 2014 ranaUpdateLSC 

That's a very smooth DARM transition - its good news that the dALS signals don't have a huge offset w.r.t the real error signal.

It would be interesting to see if the MICH can be locked and stay locked which CARM is ramped in. We would want to hold it with the Q phase of the CARM PD once its on.

May not be a milestone, but its cool anyway. 

+2 points.

Will also be cool to see how soon the CM servo can be switched on in the acquisition sequence. Maybe ALS_COMM -> CM board, gets mixed with TRXY for low frequencies in the intermediate stage before final RF?

  9835   Mon Apr 21 22:32:33 2014 ranaConfigurationGeneralnetgpibdata is working again now

Not working again. I tried the commands in Koji's elog as well as the ones from my notes, but the AG 4395 hooked up to the yellow box named crocetta doesn't work. It gets to the stage of opening the data files and hangs. I tried it with many variations on pianosa and rossa. Also tried power cycling the analyzer and the Prologix and the bridge.

While hooked up to the MC error point I set the modulation frequency from 137 to 133 Hz to minimize the 3 MHz peak as usual.

  9837   Mon Apr 21 23:33:57 2014 ranaSummaryGreen LockingHP 8591E reads low by 140 Hz out of 10 MHz

To check the basolute frequency stability of the old monochrome HP 8591E RF Spectrum analyzer that we're using for the ALS beat readout, I hooked its 10 MHz reference output (from its rear panel) into the A channel of the SRS SR620 frequency counter. The SR620 is locked to the FS 720 Rubidium clock via the 10 MHz connections in their rear panels.

So, we can assume that this is a good absolute readout. It reads 9.999860.7 +/- 0.3 Hz. So its 139.1-139.4 Hz lower than 10 MHz. The +/- 0.3 is just a slow drift that I see over the course of 10 minutes.

So, let's say that the analyzer is low by 10 ppm, so the arm length estimates are short by ~0.4 mm. A negligible correction, so there's no need to use atomic clocks to measure our arm lengths.

  9842   Tue Apr 22 22:49:10 2014 ranaUpdateLSCTRY 60Hz noise


 The detectors and electronics on this table are not properly isolated. To reduce the 60 Hz and ground loops, photodiodes and shutter must be isolated by using plastic spacers as we usually do elsewhere - this table just seems to have a few oversights.

Steve can start assembling all of the pieces to do this in the morning and then we can start the swapping after the meeting.

The high gain Transmon cable should be a regular BNC. There's no need for 4-pin LEMO in this usage, so the best move is to modify the board and replace the 4-pin LEMO connector with an isolated panel mount BNC female.

The AC adapter for this diode (and all of the detectors on the table) should get their power from a power strip which gets plugged into the rack with the whitening boards. The SHG oven, the Uniblitz shutter, and any cameras can get their power from another power strip if needed/wanted.

  9851   Thu Apr 24 22:39:14 2014 ranaConfigurationGeneralnetgpibdata is working again now


Not working again. I tried the commands in Koji's elog as well as the ones from my notes, but the AG 4395 hooked up to the yellow box named crocetta doesn't work. It gets to the stage of opening the data files and hangs. I tried it with many variations on pianosa and rossa. Also tried power cycling the analyzer and the Prologix and the bridge.

While hooked up to the MC error point I set the modulation frequency from 137 to 133 Hz to minimize the 3 MHz peak as usual.

Started working tonight. Don't know if anyone did anything to the Martian network or not, so its a mystery...

I also modified the script and SVN'd it. It now correctly takes your plot wants and adjust the linear/log of the axes accordingly

./SPAG4395A.py -i crocetta -A -v 4 --att=0 --start=1kHz --end=10MHz --bw=1kHz --plot --semiy

and also saves the plot as out.pdf

In the attached image I show the MC board TP1A output. The two peaks around 3.7 Mhz are the sideband beats we speak of. The lower one is proportional to the MC length/frequency mistmatch.

  9856   Fri Apr 25 22:20:01 2014 ranaUpdateIOOcsh/tcsh hackery combatted

To make the mcwfson/off scripts work from rossa (and not just Jamie's pet machine) I swapped the sh-bang line at the top of the script to use 'env bash' instead of 'env csh' in the case of mcwfsoff and 'env tcsh' in the case of mcwfson.

The script was failing to work due to $OSTYPE being defined for pianosa csh/tcsh, but not on rossa.

During debugging I also bypassed the ezcawrapper for ezcaswitch so that now when ezcaswitch is called, it directly runs the binary and not the script which calls the binary with numerous retries. In the future, all new scripts will be rewritten to use cdsutils, but until then beware of ezcaswitch failures.

WFS scripts checked into the SVN.

This was all in an effort to get Koji to allow me to upgrade pianosa to ubuntu 12 so that I can have ipython notebook on there.

Objections to upgrading pianosa? (chiara and megatron are already running ubuntu 12)

  9857   Fri Apr 25 23:08:57 2014 ranaSummaryIOOMC2_TRANS QPD Servo re-re-engaged again

We turned on the MC2_TRANS paths for both PIT/YAW tonight.

I turned off the BLP200 and turned on the RLP7 (RLP always are better than BLP). G_PIT = -0.111, G_YAW = 0.111. On Monday, let's let Steve look at the trends and determine if this centering servo is bad or good.

  9871   Mon Apr 28 20:31:38 2014 ranaSummaryIOOMC2_TRANS QPD Servo trend

This is a 4-day trend. I don't see any difference here which is significant. My guess is that the MC_TRANS servo gain is so low that its not really doing anything.

I'll turn it on periodically this week and then on Monday people can look at the trend again to see if they can identify when the servo is ON and when its OFF.

  9884   Wed Apr 30 21:16:42 2014 ranaUpdateLSCMC2 Strad


I found the YARM LSC feedback going to MC2 and the MC2 violin mode (at 644.69 Hz) rung up. The existing notch was just a second order Twin-T style notch (so not a good idea) and also not turned on, since it was in the FM4 spot of LSC-MC2 and the vio triggers are ganged between all mirrors and don't touch FM4.

I copied the PRM vio bandstop into FM2 of this bank, deleted the old notch, and tuned the bandstop frequencies a little to get the violin peak into one of the zeros of the elliptic bandstop. Attached are the Y-arm / MCF spectrum with the mode rung up as well as the new filter's TF compared with the old notch.

P.S. I installed http://en.wikipedia.org/wiki/Midnight_Commander on pianosa.

  9885   Wed Apr 30 21:31:25 2014 ranaHowToIOOMystery Alignment again

Looks like there was some mysterious MC alignment shift around 5:30 PM today, but no elog.....?? Now things are drifting much more than this morning or yesterday. Who did what and why???

I think I'll blame Jamie since he just got back and did some computer fiber voodoo today.


  9886   Wed Apr 30 21:57:07 2014 ranaSummaryIOOMC2_TRANS QPD Servo now on for real


During a lull in Koji vs. The Arm, I switched on the MC2_TRANSQPD feedback path to check out its UGF. In the past months, when its been on, it has had a gain of ~0.03 - 0.1.

Today, I found that with the gain turned up to 11, it has a ~1 minute step response time (as you see in the above Strip chart). So its had a UGF of ~2 hours or so during the times when we thought it might be doing bad or good or magic.

I leave it on now to see if it behaves well over the next days. Let's see if Steve thinks its good or not based on his trend monitoring.

** also touched up the PMC pointing (using the PMC REFL image / please never align the beam into the PMC without this camera image)

  9894   Thu May 1 17:00:05 2014 ranaUpdateLSCYarm locking with CM board

 I think that's about halfway there. Since this needs to be a precise comparison, we cannot use so many approximations.

We've got to include the digital AA and AI filters as well as the true, measured, time delay in the system. Also the measured/fitted TF of the CM board with the 79:1.6k filter engaged. We want an overall phase accuracy between Jenne's measured TF from last night and this model (i.e. on the same plot with the residual plotted).

Is there a cavity pole in the model? Should be at ~1.6 kHz.

  9896   Fri May 2 01:01:28 2014 ranaUpdateCDSc1ioo dolphin fiber nicely routed

This C1IOO business seems to be wiping out the MC2_TRANS QPD servo settings each day.   What kind of BURT is being done to recover our settings after each of these activities?

(also we had to do mxstream restart on c1sus twice so far tonight -- not unusual, just keeping track)

  9897   Fri May 2 01:58:52 2014 ranaConfigurationComputer Scripts / ProgramsupdateDB configured to index NFS during CRON daily

I wanted to use locate to find some files today, but found that it doesn't index any of our NFS mounted files (i.e. the whole /cvs/cds/ and /opt/rtcds/ ).

So I went into /etc/updatedb.conf and edited it like so, so that it no longer ignores NFS type file systems:

controls@rossa:/etc 0$ diff updatedb.conf updatedb.conf~
< PRUNEFS="nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre_lite tmpfs usbfs udf fuse.glusterfs fuse.sshfs ecryptfs fusesmb devtmpfs"
> PRUNEFS="NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre_lite tmpfs usbfs udf fuse.glusterfs fuse.sshfs ecryptfs fusesmb devtmpfs"

The CRON.daily on ROSSA only should run each morning at 6:25 (under the ionice class 3 protocol as usual). If this seems OK after a week or so, we can do the same for the other CDS workstations (remembering to adjust their cron.daily times so that not every one hammers the NFS at the same time).

  9899   Fri May 2 03:51:29 2014 ranaUpdateLSCfarther into CM

Rana, Q

After some more matlab loopology (see Qlog), we turned on the AO path successfully. The key was to turn on the 300:80 filter in the MCL path so that it could cross stably with the AO. Then we ramp up the AO gain via the newly AC coupled AO path into the MC servo board.

The POY11 signal looks nice and smooth. For the final smoothness after the overall common gain is ramped up, I turned on a FM7 pole at 300 Hz so that the MC path would keep falling like 1/f^2 and not interfere with the AO path around 1 kHz.

There's not enough gain yet to be able to turn on the Boost. PCDRIVE is ~3 V. Earlier tonight we were seeing the EOM saturation effect maybe, but we re-allocated the gain more to the front end and its all fine now. I think we can get another ~10-15 dB of gain by using the POY whitening gain slider + the CM AO slider. Then we can get the Boost on and take some TFs with the SR785 (as long GPIB allows).

Good Settings:

CM REFL1 = +31 dB, AO = +16 dB, MC IN2 = +16 dB. SUS-MC2_LSC = FM6, FM& ON


** Everything has been pretty stable tonight except some occasional MC/EOM locking oscillations. This means that its been easy to keep trying some different CM steps since the Y-Arm relocks using MCL within seconds.

ELOG V3.1.3-