40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 55 of 341  Not logged in ELOG logo
ID Date Authordown Type Category Subject
  9913   Tue May 6 03:17:15 2014 ranaUpdateLSCfarther into CM

Yes, we still need to do these things, day team. Please tune up the MC loop first, before anything else.


Next steps:

  • Check CM board boosts turn on politely (Transients, TFs)
  • Use fast spectrum analyzer to check MC loop gain out to a few MHz. (The bump in the tens of kHz should be fixed / moved higher)
  • Think about noise performance of, say, REFLDC, ASDC, RF AS signals, etc. in the PRY case, figure out which one to use first. 
  • We may want to first focus on directly locking the arm on an RF signal, figure out gains etc. and then figure out how to do DC->RF handoff nicely, or if high bandwidth DC signal control is even feasible.  

  9923   Wed May 7 17:10:59 2014 ranaUpdateCDScdsutils updated to version 226

 This upgrade from Jamie has given us the new apps (avg, servo, and trigservo). We should figure out if there's a way to integrate Masayuki's work, so that we can have a 'cdsutils demod' function too.

  9924   Wed May 7 22:47:33 2014 ranaUpdateCDScdsutils updated to version 226: not working on pianosa or rossa

 controls@rossa:~ 0$ cdsutils read C1:LSC-DARM_GAIN
Traceback (most recent call last):
  File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
    exec code in run_globals
  File "/ligo/apps/cdsutils-226/lib/python2.6/site-packages/cdsutils/__main__.py", line 57, in <module>
    imp.load_module('__main__', f, pathname, description)
  File "/ligo/apps/cdsutils-226/lib/python2.6/site-packages/cdsutils/read.py", line 32, in <module>
    print ezca.Ezca(prefix).read(rest, as_string=args.as_string)
  File "/ligo/apps/linux-x86_64/cdsutils-226/lib/python2.6/site-packages/ezca/cached.py", line 17, in __call__
    key = (args, tuple(kwargs.viewitems()))
AttributeError: 'dict' object has no attribute 'viewitems'

  9929   Thu May 8 02:03:51 2014 ranaUpdateISSISS: fuse was blown, repaired, loop back on

Back in November, Nic and Evan turned on an SR560 based ISS. It uses the PMC TRANS PD as the error signal and makes an AC coupled loop with 2 SR560's and then it drives the RF amplifier which drives the AOM upstream of the PMC.

This was the saturating SR560 under the PSL table that Steve found this week*. Tonight I found that the +24 V rack fuse for this was blown. I replaced the previous 2A fuse with a new 2A fuse (turned off the +/24 V Sorensens during this operation). I think all of the servo settings are basically the same as before, except that I'm using a gain of 10000 instead of 50000 on the first SR560. It was saturating otherwise. My guess is that the fuse blew many months ago and no one has noticed...

 I checked the out of loop performance in MC_TRANS and in the IFO REFL_DC and there's some high frequency improvement with the loops on.

The main improvement, however, was in lowering the HEPA fan speed. This should only be turned up to Hurricane when you are working on the table. Similarly, those of us trying to lock at night, can't really trust that the HEPA is set to its nominal low setting of 20%. The whole difference in the MC_TRANS from 5-50 Hz is from this however, so we can use this ISS reference .xml as a way to see if the HEPA is up too high.

If we want to do better for RIN from 100-1000 Hz for improving the REFL_DC/CARM noise, we would have to think of how to improve the PMC_TRANS PD RIN.


* Steve gets +1 point for finding this, but then -3 points for not elogging.

Attachment 1: ISS.pdf
  9934   Fri May 9 01:36:28 2014 ranaSummarySUSOptical Lever QPD Sum trends: they're almost all too weak

 We want there to be ~16000 cts of signal per quadrant on the optical levers. I think that most of the QPDs have been modified to have 100k transimpedance resistors.

From the attached 90 day trend, you can see that the ETMX, BS, PRM, and SRM are really low. We should figure out if we need to change the lasers or if the coating reflectivities are just low.

Steve, can you please measure the laser powers with a power meter and then reply to this entry?

Another possibility is that we are just picking a dim beam and a brighter one is available.

Attachment 1: OLtrend.png
  9940   Mon May 12 10:42:01 2014 ranaUpdateSUSsome Arm maintenance

I ran the ASS/ADS for the arms because the X-arm was way out. There was also some problem with its locking due to bad ramps in FM2. I copied over the filters from YARM and then adjusted some of the ramps and thresh trigs in the filter file until the transients in POX got smaller. Basically, you should not really be ramping on Integrators. Secondly, we should do some testing when adjusting the filter parameters.

I hooked up the 4395 to the MC servo board OUT2 so that we can monitor the error point when the PCDRIVE goes nuts.

  9942   Mon May 12 22:42:19 2014 ranaSummarySUSOptical Lever QPD Sum trends: they're almost all too weak

For some reason or another, I decided that we should see if the optical lever servos were injecting too much noise into the test masses. The ITMs are much worse than the ETMs and I am afeared that they might be making the main noise for our arms in the 20-40 Hz region. Jenne is checking up on these feedback loops to see what's up.

To estimate the actuator gains of the mirrors, I turned on 1 count drives from LSC/CAL oscillators into the LSC drives of each test mass at the frequencies shown in the plot with the resulting peaks showing up in in POX/Y with the single arm locks in red. I will leave these going permanently, but with 0.1 count ampltiudes; we need to make it so in the scripts.

Attachment 1: OL-FB.png
Attachment 2: arms_140512.pdf
  9944   Tue May 13 00:46:58 2014 ranaHowToPSLPMC relocking

The PMC runs out of range sometimes due to the daily temperature swing. The voltage swings up after sunset and then starts to swing down before sunrise. So when you relock the PMC at the beginning of the locking night, the mnemonic from the PMC is:

Sun Go Low, Lock Me Voltage Low.

  9949   Tue May 13 17:45:21 2014 ranaUpdateCDS/frames space cleared up, daqd stabilized


 Late last night we were getting some problems with DAQD again. Turned out to be /frames getting full again.

I deleted a bunch of old frame files by hand around 3AM to be able to keep locking quickly and then also ran the wiper script (target/fb/wiper.pl).

controls@pianosa|fb> df -h; date

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda1             440G  9.7G  408G   3% /

none                  7.9G  288K  7.9G   1% /dev

none                  7.9G  464K  7.9G   1% /dev/shm

none                  7.9G  144K  7.9G   1% /var/run

none                  7.9G     0  7.9G   0% /var/lock

none                  7.9G     0  7.9G   0% /lib/init/rw

none                  440G  9.7G  408G   3% /var/lib/ureadahead/debugfs

linux1:/home/cds      1.8T  1.4T  325G  82% /cvs/cds

linux1:/ligo           71G   18G   50G  27% /ligo


                      1.8T  1.4T  325G  82% /opt/rtcds

fb:/frames        13T   12T  559G  96% /frames


                      1.8T  1.4T  325G  82% /users

Tue May 13 17:35:00 PDT 2014

Looking through the directories by hand it seems that the issue may be due to our FB MXstream instabilities. The wiper looks at the disk usage and tries to delete just enough files to keep us below 95% full for the next 24 hours. If, however, some of the channels are not being written because some front ends are not writing their DAQ channels to frames, then it will misestimate the disk size. In particular, if its currently writing small frames and then we restart the mxstream and the per frame file size goes back up to 80 MB, it can make the disk full.

For now, I have modified the wiper.pl script to try to stay below 93%. As you can see by the above output of 'df', it is already above 96% and it still has files to write until the next run of wiper.pl 7 hours from now at. at 6 AM.

IF we assume that its writing a 75MB file every 16 seconds, then it would write 405 GB of frames every day. There is 559 GB free right now so we are OK for now. With 405 GB of usage per day, we have a lookback of ~12TB/405GB ~ 29 days (ignoring the trend files).

  9955   Thu May 15 01:42:07 2014 ranaUpdateCDS/frames space cleared up, daqd stabilized

 Script seems to be working now:

nodus:~>df -h | grep frames

fb:/frames              13T    12T   931G    93%    /frames

  9960   Fri May 16 00:25:53 2014 ranaUpdatePSLPMC realign

 Tonight I noticed that the drop in PMC transmission was ~1V, more than the usual of ~0.5V from the daily drift.

While re-aligning on the table, I noticed that the misalignment was not from either of the steering mirrors; i.e. I has to walk them both to get the alignment back. This implies that the misalignment is generated far upstream. Maybe the the laser itself is moving. We need some updates from Steve's laser misalignment tracker.

  9969   Sun May 18 17:57:54 2014 ranaUpdateLSCETMX transients due to unseated bias cable

 The daytime crew had noticed that there were some ETMX angular shifts happening without any control or intention.

I reseated and strain relieved the bias cable coming into the backplane of the coil driver and now it seems OK.

In the 4-hour-long second trend plot below, the era before 2300 is before reseating. Afterwards, we make a couple adjustments, but so far there has been no un-asked for alignment shifts.

AdS has been run on both arms and offsets saved. Its locked on green/red and the beat frequencies are low and the amplitudes high. 

Sun May 18 23:53:37 2014: still OK...I declare it fixed.


Attachment 1: ETMXbiasCableSeated.pdf
  9975   Tue May 20 15:54:39 2014 ranaSummarySUSETMX oplev qpd board

 This QPD circuit (D980325-C1 ) uses the nice OP497 Quad FET opamp as the transimpedance amplifier. It has a low enough current noise, such that we can increase the resistors (R1-4) up to 100k and still be Johnson noise limited. We should also make sure that the compensation caps (C3-6) are ~2.2 nF so as to not destabilize the opamp. f_low = 1/2/pi/R/C = 730 Hz.

I will do the swap later today unless someone else gets to it first. (note: check for oscillations w/ fast scope probe after installing)

I did these modification tonight. The slideshow of some images is attached. Instead of 100k, I used 97.6k thin film, since this seemed like an oddball size that doesn't get used otherwise. I forgot to measure the dark noise of the quadrants before doing the swap, but comparing the pit/yaw/sum before/after the swap shows that the signal is basically unchanged (since pit/yaw is normalized by SUM), but that the noise is lower by a factor of a few above 100 Hz due to being above ADC noise now. Previously, it was bottoming out at ~10 prad/rHz. Since the signal is unchanged, I guess that the calibration and therefore the loop gain should not have changed either...

And the sum went up by almost 10x as expected from the resistor change.

  10039   Sat Jun 14 18:43:15 2014 ranaUpdateIOOMC Autolocker upgrades

 Somehow the caget/caput commands are really slow. I'm not sure if this is new behavior or not, but after changing values, it takes ~1-2 seconds to move on to the next command.

On op340m, once I ran autolockMCmain40m in the foreground, I could see that there were a lot of error messages that weren't being caught in the log file. On Solaris, the TDS and EZCA binaries work well, but the caget/pu stuff is missing a lot of the new flags and the new CDSUTILS python scripts are not there. So I decided to stop running on there and move over to running the MC autolocker on megatron. I also changes the mcup and mcdown scripts to BASH from CSH. There are still some PERL commands in there from Rob/Matt/Sam, so I also added the proper commands so that the pick up the scripts/general/perlmodules/ directory.

Yes, yes, I know. You would all feel warm in your tummy if we did everything in python because its the best language ever, but how about we lock the interferometer first and then we can rewrite all the last decades worth of scripts?

Looked at the trend from the last time the MCWFS were one (2 weeks ago!) and aligned the MC suspension back to that point. After that the WFS come on fine and MC looks good. I fixed the nameserver/DNS/fstab stuff on megatron, asia, and belladonna.

I've left AutoLockMC.csh (too painful to convert to BASH) running on megatron via an open terminal on pianosa. If it looks OK for the weekend, Q should move the crontab line from op340m over to megatron and then update the Wiki appropriately.

CDSUTILS is also gone from the path on all the workstations, so we need Jamie to tell us by ELOG how to set it up, or else we have to use ezcaread / ezcawrite forever.

  10043   Mon Jun 16 15:32:12 2014 ranaSummaryIOORingdown recap


To do this better:

1) Just step the analog input to the AOM (i.e. no RF switch) and measure the PMC trans output with a fast DC coupled PD. IMC should be unlocked and disable during this part. We want the PMC ringdown to be faster than 1 us.

2) Re-install a fast PD in the MC trans path without disrupting the existing MC trans QPD setup.

3) Measure IMC ringdown and fit the data to find the cavity losses.

4) Think about how to use the Isogai, et. al (2013) technique to better measure the losses, taking into account the mirror transmissions.

  10052   Tue Jun 17 19:39:29 2014 ranaUpdateComputer Scripts / Programsautolocker confusion

I renamed the Autolocker and described it in the elog from this weekend. To run it, you have to run it from the scripts/MC/ directory (as always). I restarted the autolocker on Ottavia with nohup.

> nohup ./AutoLockMC.csh &

To figure out how to get cron to run it, we will have to debug the difference between linux and solaris pgrep, so that's in progress.

  10056   Wed Jun 18 13:29:48 2014 ranaUpdateComputer Scripts / Programsautolocker confusion


 Moral is wrong.

AutoLocker was working fine last night and we observed it to run and do the appropriate mcdown and mcup stuff. Probably something is breaking with it after several hours.

If you have suspicions about the script, best to look through the logs during the first few hours when we had it running yesterday.

  10057   Wed Jun 18 13:39:01 2014 ranaUpdateCDScdsutils reverted to version 238


 After some email consult with Jamie, I got cdsutils working again by reverting to v238. The newest versions are not compatible with our python 2.6 on Ubuntu 10. And our Ubuntu 12 machines do not have NDS2 clients that work yet.

The read/write commands work at the moment, but the NDS based ones don't yet work on pianosa due to some NDSSERVER flag/setup issue maybe, Jamie ??

controls@pianosa|~ > z

usage: cdsutils <cmd> <args>

Advanced LIGO Control Room Utilites

Available commands:

    read         read EPICS channel value

  write        write EPICS channel value

  switch       switch buttons in standard LIGO filter module

  avg          average one or more NDS channels for a specified amount of seconds

  servo        servos channel with a simple integrator (pole at zero)

  trigservo    servos channel with a simple integrator (pole at zero)

  version      print version info and exit

  help         this help

Add '-h' after individual commands for command help.

controls@pianosa|~ > z read C1:LSC-DARM_GAIN


controls@pianosa|~ 2> z avg 3 C1:IOO-MC_F

Error in write(): Connection refused

Error in write(): Connection refused

NDSSERVER variable incorrectly defined, or no NDS servers available.

controls@pianosa|~ 1> echo $NDSSERVER


  10074   Thu Jun 19 16:49:15 2014 ranaUpdateComputer Scripts / Programsautolocker running again

  We've noticed that the caget/caput and cdsutils take a long time to return the command prompt. The following two ping commands indicate that it may be related to routing or our new BIND9 DNS setup on chiara.



controls@ottavia|~ > ping -c 5 -D c1sus


PING c1sus.martian ( 56(84) bytes of data.


[1403221338.383403] 64 bytes from icmp_req=1 ttl=64 time=0.114 ms


[1403221343.386211] 64 bytes from icmp_req=2 ttl=64 time=0.059 ms


[1403221348.387666] 64 bytes from icmp_req=3 ttl=64 time=0.060 ms


[1403221353.389736] 64 bytes from icmp_req=4 ttl=64 time=0.059 ms


[1403221354.390713] 64 bytes from icmp_req=5 ttl=64 time=0.060 ms


--- c1sus.martian ping statistics ---




5 packets transmitted, 5 received, 0% packet loss, time 20007ms


rtt min/avg/max/mdev = 0.059/0.070/0.114/0.023 ms




controls@ottavia|~ > ping -c 5 -D


PING ( 56(84) bytes of data.


[1403221463.737857] 64 bytes from icmp_req=1 ttl=64 time=0.078 ms


[1403221464.737353] 64 bytes from icmp_req=2 ttl=64 time=0.059 ms


[1403221465.737318] 64 bytes from icmp_req=3 ttl=64 time=0.050 ms


[1403221466.737316] 64 bytes from icmp_req=4 ttl=64 time=0.052 ms


[1403221467.737321] 64 bytes from icmp_req=5 ttl=64 time=0.050 ms




--- ping statistics ---


5 packets transmitted, 5 received, 0% packet loss, time 3999ms


rtt min/avg/max/mdev = 0.050/0.057/0.078/0.014 ms

  10084   Fri Jun 20 19:07:44 2014 ranaUpdateComputer Scripts / Programsop340m DNS

I had forgotten to fix the DNS setup on op340m and so our slow, perl, PID loops for the laser were not running well (and that's why the FSS-FAST has been saturating).

I edited /etc/resolv.conf on there and then did /usr/sbin/reboot as super-user.

op340m:~>more /etc/resolv.conf
domain martian
Fri Jun 20 19:06:37 PDT 2014

The FSSSlowServo.pl now seems to be holding the NPRO PZT to ~6 V. I twiddled the PID settings a little bit to make sure nothing was squirrelly. Seems OK. Time constant of the loop is ~1 minute.

As a reminder, op340m runs our autoburt for all the FE machines, VME IOCs, does the watchdog threshold rampdown, and also the RefCav and NPRO temperature control.

  10147   Mon Jul 7 22:07:29 2014 ranaUpdateElectronicsRF cables rerouted

This Red Ladder movement also probably included some bumping of the MC2 stack (be more careful when working in the lab). Around 5 PM today, the MC lost lock.

When I came in later, I found that the MC was flashing the TEM17,9 mode and had been misaligned like this for ~1 hour. I looked through the MC SUS sensor trends and moved MC2 back to its old position to get the locking back. I disabled the WFS, tweaked the TEM00 mode alignment using only MC2 sliders, and then re-enabled WFS. Its been OK for the past 5 hours.

Attachment 1: Untitled.pdf
  10149   Mon Jul 7 23:19:55 2014 ranaUpdatePSLPMC ringdown setup


I moved stuff on the PSL table to accommodate the PMC ringdown setup.

I used the beam that leaks from the steering mirror at the PMC transmission that was dumped to a razor blade dump. I installed a Y1 to steer the beam to the ringdown PD. Power in the beam 75mW. 

 I am guessing that 75 mW will burn / destroy any Thorlabs PD. I hope that mW is supposed to be uW.

  10160   Wed Jul 9 00:59:09 2014 ranaUpdatePSLPMC local oscillator is going wonky


Koushik and Koji try to fix the PMC oscillator issue. So we remove the module from the rack.
This means we don't have the PMC transmission during the work.

 After the ERA-5 was replaced (see Koushik elog) we relocked the PMC.

The new LO level going into the PMC servo card is +11.5 dBm. The LO mon on the PMC card reads 9 dBm and seems so flat I now suspect the monitor circuit.

I also measured the RF drive to the EOM as a function of C1:PSL-PMC_RFADJ on the Phase Shifter screen.

The phase shifter slider gives ~75 deg/V in phase shift of the RF out to the EOM. I tried to optimize the loop gain quickly using the fluctuations in the reflected power. The loop oscillates at high frequency with the slider at 21 dB and also at 9 dB. So I set the gain at +14 dB. Needs to be optimized correctly in the daytime.


Attachment 1: PMC_RFslider.pdf
  10167   Wed Jul 9 19:53:34 2014 ranaUpdatePSLPMC LO monitor trend (5 years)


The first step is

The second uptick (In Nov 14, 2013) is when I removed a 3 dB attenuator from the LO line. Don't know why the decay accelerates after that.

  10172   Thu Jul 10 01:02:13 2014 ranaUpdatePSLmore PMC science

Increased gain and SNR in PMC LO monitor circuit.

  1. R20: 499 -> 50k Ohms (increases gain by 100)
  2. Used Marconi to drive the LO input and readout C1:PSL-PMC_LODET
  3. Fit this function and loaded it into the psl.db file. The old Kalmus way used LOGE, but I wanted to use log10, so I did. The sensor is only useful in a narrow band. Since the signal is so low at low levels, I just fit to the highest 4 points because I was too lazy to do proper weighting. Do as I say, not as I do.

Plot with data and fit attached.

** N.B.: in order to update the calibration without rebooting, I used the following command: z write C1:PSL-PMC_LOCALC.CALC "2.235*LOG(B)+12.265". This allows us to update EPICS CALC records without rebooting the IOC.

Attachment 1: PMCloCal.pdf
  10209   Wed Jul 16 01:18:02 2014 ranaSummaryLSCPython Wavelet peak finding for dramatic ALS - Red Resonance finding speedup

New script called scripts/ALS/findRedResonance.py finds the IR resonance in less than 20 seconds.

  1. Do a ~2 FSR scan of the arm over 10 seconds using the Phase Tracker servo offset ramp. (dt = 10 s)
  2. Load the frame data for the TR_OUT and the Phase Tracker phase. (dt = 2 s)
  3. Use Python (modern) SciPy to find all peaks with moderate SNR (dt = 3 s)
  4. Take the top 3 peaks (all presumably TEM00) and choose the one closest to zero and go there.

The above is the gist of what goes on, but there were several issues to overcome to get the code to run.

  1. None of our workstations have a modern enough Python distro to run either the ipython notebooks or the new SciPy with wavelets, so I installed Anaconda Python in the controls home directory.
  2. In order to get the peak finder function to work well I gave it a range of peak widths to look for. If we change the speed of the ALS scan by more than 3x, we probably have to change the width array in the function.
  3. I've used the find_peaks_cwt function in SciPy. This uses a Ricker ('Mexican Hat') wavelet to find peaks by doing multi-res transforms and looking for ridges in the wavelet space (I think)
  4. To make the code run fast, I downsample from 16 kHz to 1 kHz right at the top. Would be better if we had downsampling in v2 of the getData function.


Attachment 1: findRedResonance.pdf
  10225   Thu Jul 17 01:24:35 2014 ranaUpdateIOOMC / EOM Stability Mystery Solved!

MC loop is near unstable. Common gain reduced. Needs more loop tuning.

We've often seen that the MC gets into a state where it keeps losing lock and the EOM drive shows a large RMS. We've usually been looking at the noise spectrum to diagnose this.

Tonight we finally just measured the OLG. The attached plot shows the loop gain measured with the 4395 on the MC servo board

Although the phase margin is a healthy 45 degrees, its close to instability at 1 MHz. For this plot, I reduced the gain by 3 dB and now the margin is ~7 dB. So usually its pretty close to unstable and at least its always making a noise peak.

That whole TF above a few hundred kHz is weird. We should tune out whatever makes it so flat and also remove the resonance that makes the 1 MHz peak; maybe its from some post mixer low pass?

Anyone interested in helping in the investigation ought to measure the TF of the MC demod board, the MC servo board, and the FSS box.

Silver lining: if we fix this loop shape, we might be able to have a much more stable IMC and IFO.

Attachment 1: MC_OLG.pdf
  10366   Mon Aug 11 23:50:38 2014 ranaConfigurationWikiDokuWikis are back up



It looks like auth is broken on the AIC wiki (though working fine on ATF and Cryo). I did some poking around but can't see how anything we did could have broken it.

I went into local.php and changed $conf['useacl'] = 1; to $conf['useacl'] = 0; and it looks like the auth issue goes away (I've changed it back). This isn't a fix (we want to use access control), but it gives us a clue as to where the problem is.

 There was still some residual permissions issue. This is now bypassed and so the ACL is ON and all seems to be back the way it was. I've tested that I can login and edit the wiki.

Some useless knowledge follows here. Please ignore.

After some hours of reading unhelpful DokuWiki blogs, I just put the backup wiki into the local disk on NODUS and then made a soft link to point to that from /users/public_html/wiki/. So this implies that the new NFS setup on chiara is different enough that it doesn't allow read/write access to the apache user on the NODUS/Solaris machine.

  10375   Wed Aug 13 13:08:24 2014 ranaUpdateIMCCalculation for the input mode cleaner

Can you please give us some more details on how this design was decided upon? What were the design considerations?

It would be nice to have a shorter path length for WFS2. What is the desired spot size on the WFS? How sensitive are they going to be to IMC input alignment? Are we still going to be recentering the WFS all the time?

  10379   Wed Aug 13 22:01:57 2014 ranaUpdateIMCCalculation for the input mode cleaner

Nic, Andres, and I discussed some more about the MC WFS project today. We want to shorten the proposed WFS2 path. Andres is going to explore moving the 2" diameter lens in coming up with layouts. We also want the WFS to face west so that we can see the diode face with an IR viewer easily and dump the reflected beams in the razor dumps.

We wondered about fixing the power levels and optical gain:

  1. What is the MC modulations depth? What would happen if we increase it a little? Does anyone know how to set it? Will this help the MC frequency noise?
  2. What is the max power on the WFS? I guess it should be set so that the power dissipation of the detector is less than 1 W with the MC unlocked. So P_diss = (100 V)*(I_tot), means that we should have less than 10 mA or ~50 mW when the MC is unlocked.
  3. Another consideration is saturation. The RF signals are tiny, but maybe the DC will saturate if we use any more power. The quadrants are saturated when unlocked and ~200 mV locked. According to D990249, the DC gain in the head is 1000 V/A. The measured power levels going into the heads (w/ MC unlocked) are: P_WFS1 = 4.9 mW and P_WFS2 = 7.7 mW. We don't have control of the DC gain, but there is a 10x and 100x switch available inside the demod board (D980233). From these numbers, I figure that we're in the 100x position and so the effective DC gain between photocurrent and the DC readback voltages is 100 kOhm. Therefore, we are in no danger of optical or electronics saturation. And the unlocked photocurrent of ~40/100000=0.4 mA => 0.04 W heat generated in the diode, so we're OK to increase the power level by another factor of 2-4 if we want.
  4.  We noticed that the ADC inputs are moving by ~50 counts out of 65000, so we're doing a really bad job of signal conditioning. This was previously noticed 6 years ago but we failed to follow up on it. Feh.

While checking this out, I converted the McWFS DC offsets script from csh to bash and committed it to the SVN. We need to remove the prefix 'feature' that Jamie has introduced to cdsutils so that we can use C1 again.


  10380   Wed Aug 13 23:08:17 2014 ranaUpdateIOOFSS box TFs

As EQ pointed out recently, we're injecting into the FSS error point just after an RF pi filter, but before the VGA. We wondered what the weird filter impedance was doing to our signal if we inject after it. I used LISO to model this FSS common section and attach the plots.

The first plot shows the TF between the Test 1 input and the AD602 VGA input. This is NOT the input that we are actually using.

The second plot shows the TF between the IN1 port (which we are actually using) and the VGA input.

Neither of them shows the 1 MHz bump that we see in the measurements, so I suspect that the board has been modified...the hunt continues. We've got to pop the top of the TTFSS and take photos and measure from IN1 to VGA input.

** FSScomm.fil is now in the LISO SVN. The following command line will run it with two different cases and cat the PDF files into one. If you use an auto-refresh PDF viewer like Okular or Mac Preview, its a nicer display than the usual GNUplot window:

./mfil FSScomm.fil; sleep 1; pdftk FSScomm_run*.pdf cat output FSScomm.pdf

Attachment 1: FSScomm.pdf
FSScomm.pdf FSScomm.pdf
  10381   Wed Aug 13 23:58:49 2014 ranaHowToComputer Scripts / ProgramsHP8591E spectrum analyzer remote scan


The script for running continuous scans on HP 8591E spectrum analyzer is located at scripts/general/netgpibdata/HP8591E_contdScan.py

There was no such script in the directory when I looked today, but I found one called HP8591E. Of course, it didn't run because it hadn't been tested from the scripts directory and pointed to some /users/nichin/ stuff.

I modified a couple of lines and then committed it and the default .YML parameter file to the SVN. It runs and produces plots continuously from the scripts directory.

*** also, as you can see, we have mostly recovered the green beat amplitudes after yesterday's FLL attack on the ALS ***

Attachment 1: HP8591E_View.pdf
  10391   Thu Aug 14 19:23:25 2014 ranaHowToIOOHow do I set the FSS offset to make the PZT voltage start at the right place?

 When the IMC locks, we want the FAST OUT of the TTFSS box to be close to zero volts. We also want the control signal from the MC Servo board to be close to 0 V. How to set this up?

With the IMC locked, we just servo the FSS input offset to minimize the MC board output :

ezcaservo -r C1:IOO-MC_FAST_MON -g 0.1 -t 10 C1:PSL-FSS_INOFFSET

I would have used "CDSUTILS", but that seems to have some sort of ridiculous bug where we can't have prefixes on channel names, even on the command line. 

  10393   Thu Aug 14 20:52:36 2014 ranaUpdateWikiViolin Mode table added to Wiki

Mech Resonance Wiki

I've updated the wiki by trawling the elog for violin entries. Please keep it up to date so that we can make violin notches.


  10397   Thu Aug 14 23:19:49 2014 ranaSummaryLSCETM Violin fundamental filters moved to LSC

 We used to do violin mode and test mass body mode notches in the SUS-LSC filter modules. Now we want them balanced in the LSC and triggered by the LSC, so they're in the filter modules which go from the the LSC output matrix to the SUS.


Today, we were getting ETM violin mode ringups while doing ALS hunt and so we moved the bandstops into the LSC. I also changed the bandstop from a wide one which missed the ETMX mode to a double bandstop which gets both the ETMX and the ETMY mode. See attached image of the Bode mag.


  10421   Thu Aug 21 22:10:52 2014 ranaSummaryComputer Scripts / Programsnetwork movements

 To help development of the data visualization project, we've assigned the .101 and .102 IP to DataVis. This is being used by the iMac in the control room via port 8 of the CDS switch near the Blue Plataeu Tournant.

We tried using one of the free ports, but Jamie realized that we had to use one of the already assigned ones due to some 'Smart' switch management software. So for the moment, please leave the iMac alone so that Bill can use it.

  10438   Fri Aug 29 17:28:07 2014 ranaUpdateGreen LockinguPDH Box Checkup


 I've been having trouble locking the X - green for the past few hours. Has there been some configuration change down there that anyone knows about?

I'm thinking that perhaps I need to replace the SHG crystal or perhaps remove the PZT alignment mirrors perhaps. Another possibility is that the NPRO down there is going bad. I'll start swapping the Y-end NPRO for the X-end one and see if that makes things better.

  10443   Wed Sep 3 00:17:22 2014 ranaUpdateGreen LockinguPDH Box Checkup

What monitor point is being plotted here? Or is it a scope probe output?

If this saturation is in the uPDH-X but not in the uPDH-Y, then just replace the VGA chip. Because these things have fixed attenuation inside, they often can't go the rails even when the chip is new.

In any case, we need to make a fix to get this box on the air in a fixed state before tomorrow evening.


I had noticed in the past, that the digital control signal monitor for the X end would saturate well before the ADC should saturate (C1:ALS-X_SLOW_SERVO_IN1, which is from the "output mon" BNC on the box). It turns out that there is some odd saturation happening inside the box itself.

In this scope trace, the servo input is being driven with a 0.02Vpp, 0.1Hz sine wave, gain knob at 1.0. This is bad. 


Evan and I poked around the board, and discover that for some reason currently unknown to us, the variable gain amplifier (AD8336) can't reach its negative rail, despite the +-12V arriving safely at its power supply pins. 

I also realized that the LF356 in the integrator stage in this box had been replaced with a LT1792 by Kiwamu in ELOG 4373. I've updated my schematic, and will upload both boxes' schematics to the DCC page Jenne created for them. (D1400293 and D1400294)


  10445   Wed Sep 3 14:07:18 2014 ranaConfigurationGeneralnetgpibdata is working again now


I gave the IPs to the bridges. According lines of /etc/hosts in linux1 were updated. WET54G1 WET54G2

 I was going through some old Koji elogs to check them for correctness (as I do weekly). I noticed that back in Dec 2013, he made the above illegal modification of IP numbers. was actually the IP for farfalla. Maybe that's why they were conflicting and farfalla not working and Q observing/imagining wireless GPIB dropouts?

I used the Wiki instructions to update the 2 bind9 files with a new number for farfalla ( which was previously the number for the long dead op240m. Farfalla is restarted and sort of working. 

  10455   Fri Sep 5 00:56:00 2014 ranaSummaryOptical LeversITM OLs recentered: violations found

I re-centered the ITMX & ITMY Optical lever beams today since they were off. First I aligned the beam into the vacuum so that it went through the center of the on table optics and then tweaked the receiver optics alignment.

There are several bad practices on these which probably makes them drift:

  • plastic bases on some lens mounts
  • some lens mounts are fastened with a single dog instead of two
  • there is no need to use dogs on mounts that have screw holes. Just put the mount so that 2 screws with washers can be used. The placement for these is not so critical.
  • Use less steering mirrors! The ITMY OL path has 5 optics the beam enters the vacuum!!!

According to the datasheets, the laser has a beam diameter of 0.6 mm and a divergence angle of 1.3/2 mrad. So we can just calculate the right lens positions next time and not have to experiment with the whole visible laser lens kit.

For next Wednesday's cleanup, someone should volunteer to make the mounts more stable for the ITMs.

  10456   Fri Sep 5 03:36:00 2014 ranaUpdateComputer Scripts / Programsmartian wireless tweak

 I changed the Martian wireless router to use channel 10 instead of something random (as it was). Using the Android app 'Wifi Analyzer' we could see that the usual channels are dominated by FlumeLab and Caltech Beaver.

The range from 9-13 looked clean so we put it up there. Also, the signal strength drops from -45 to -70 dBm as we walk from the BS down to the ends. We need to tweak the router position and orientation to give us another 10 dB so that we can reliably run the laptops at the ends.

  10463   Sat Sep 6 01:48:54 2014 ranaUpdateGreen Lockingnew X Green PDH measurements


Does this matter? Is there something in my simulation that I can correct that would give a more accurate calibration? 

Data, plots, code, attached. 

 What modulation depth are you using for the simulation? I have never seen a real measurement of that in our elog for the end-PDH systems.

I also disbelieve your RMS calculations. It looks like in the 1.5-0.5 Hz band we're picking up 50 kHz of frequency noise even though the 1 Hz peak is only 80 Hz/rHz, even though math says  "80 * sqrt(1) = 80".

Take a look at:




  10465   Sun Sep 7 17:06:38 2014 ranaUpdateGreen Lockingnew X Green PDH measurements

600 Hz seems ~OK. From the measured reflectivities for 532 nm, the green Finesse = 108. So the green cavity pole should be 18.3 kHz given an arm length of 37.8 m. 

600 Hz of green frequency noise means that we would get 38 pm RMS of arm mirror motion. We should assumed a peak/RMS factor of 10, so this would allow us to get to ~0.4 nm CARM offset.

However, its better than that. What we really care about for ALS is the amount of this green frequency noise which is put onto the arm. With an ALS feedback bandwidth of 100 Hz, my eyeball estimate say that the contribution from green PDH error will be ~100 Hz RMS, since we don't care too much about the 10 kHz stuff. So this seems good enough for now; let's figure out what's up with PDH-Y and get back to locking.

  10469   Mon Sep 8 11:34:47 2014 ranaUpdateComputer Scripts / Programspreparing vac system to reboot

FYI: in that rack, the +15V pulls ~0.5 A more than -15V usually. I think this is due to some RF amplifiers which are powered by this (e.g. the AOM that Manasa set up). The Sorensen's can source ~30A in principle, so we should make sure to set the current limit appropriately so as to not overheat them when there is a short.

Was this power supply not fused for all of its connections? I remember that this was connected to at least one un-fused connection in the past year.

  10483   Wed Sep 10 02:35:55 2014 ranaUpdateCDSOTTAVIA lost network connection


Today the network connection of OTTAVIA was sporadic.

Then in the evening OTTAVIA lost completely it. I tried jiggle the cables to recover it, but in vain.

We wonder if the network card (on-board one) has an issue.

 I would also suspect IP conflicts; I had temporarily put the iMac on the Ottavia IP wire a few weeks ago. Hopefully its not back on there.

  10507   Mon Sep 15 18:55:51 2014 ranaUpdateDAQ40m frames onto the cluster

 Dan Kozak is rsync transferring /frames from NODUS over to the LDAS grid. He's doing this without a BW limit, but even so its going to take a couple weeks. If nodus seems pokey or the net connection to the outside world is too tight, then please let me and him know so that he can throttle the pipe a little.

  10565   Sun Oct 5 10:09:49 2014 ranaUpdateIOOIMC WFS measurements

It seems clever, but I wonder why use DTT and command line perl, instead of using the FE lockins or just demod the offline data or all of the other sensing matrix scripts made for the LSC (at 40m) or ASC (at LLO) ?

  10593   Fri Oct 10 00:20:37 2014 ranaUpdateLSCCARM W/N TFs


 Assuming that these Watts/Newtons TFs are correct, I've modeled the resulting open loop gain for CARM. The goal is to design a loop that is stable under a wide range of offsets and also has enough low frequency gain.

The attached PDF shows this. I used a CARM OLG Simulink model:


I've replaced the 'armTF' block with a digital gain of zero. After measuring the open loop gain of all but this piece, I multiply that 'OLG' with the W/N that Jenne extracted from Optickle for CARM->TR (not sqrtInv)

I plot the resulting estimate of the actual OLG in the following plot. Since the CARM-RSE peak is moving down, we use the LP filter that Den installed for us several months ago. To account for the radiation pressure spring, we use some low frequency boosts but not the crazy FM4 filter.

As you can see, the loop is stable from 500 to 200 pm, but then goes unstable around 110 pm. I expect that we will want to do some fancy shaping there or switch from TRX+TRY into something else.

This assumes we have filters 0, 1, 3, 5, and 7 on in the CARM filter bank - still need to add the digital AA/AI to make the loop phase lag a little more accruate, but I think this is looking promising.


Attachment 2: carm.pdf
  10604   Mon Oct 13 21:59:47 2014 ranaUpdateComputer Scripts / ProgramsWhich side of optical spring are we on? (No progress)


 Since no one was here, I started the Ubuntu 10 - 12 upgrade on Rossa. It didn't run at first because it wanted to remove 'update-manager-kde' even though it was on the blacklist. I removed it from the command line and now its running. Allegra, OTOH, refuses to upgrade. Someone please ask Diego to wipe it and then install Ubuntu 12 LTS on there in the morning...its a good way to learn the Martian CDS setup.

  10608   Wed Oct 15 02:59:04 2014 ranaUpdateLSCCARM W/N TFs

 In my previous elog in this thread, I showed the CARM OLG given some new digital filters and the varying CARM plant (spring side, not anti-spring). Jenne has subsequently produced the TFs for all of the rest of the CARM offsets.

These attached plots for several CARM offsets show that the anti-spring side is much more stable than the spring side and so we should use that. Annecadotedally, we think that positive CARM offsets are more stable when going to arm powers of > 10, so perhaps this means that +CARM = -SPRING.

The first PDF shows the spring OLGs and the 2nd one shows the antispring OLGs. I have put in some gain changes to keep the UGF approximately the same as the offset is changed.

The PDF thumbnails will become visible once Q and Diego install the new nodus.

 UPDATE OCt 16: this is all wrong! bad conversion of filters within the invbilinear.m function.

Attachment 1: spring.pdf
Attachment 2: antispring.pdf
ELOG V3.1.3-