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

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.

  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.

 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.

 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.

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

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.

 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 ?

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?

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.

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.

 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.

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.

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)

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.

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.

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.

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.

http://www.lawsome.net/no-throwing-rotten-tomatoes-a-repealed-kentucky-law/

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)

 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.

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)

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~
4c4
< 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).

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.

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

 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.

 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'

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.

 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.

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.

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.

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.

 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

linux1:/home/cds/rtcds

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

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

linux1:/home/cds/caltech/users

                      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).

 Script seems to be working now:

nodus:~>df -h | grep frames

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

 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.

 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.

 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.

 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.

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.

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.

 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.

 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

0.0

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

fb

  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 (192.168.113.85) 56(84) bytes of data.

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

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

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

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

[1403221354.390713] 64 bytes from 192.168.113.85: 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 192.168.113.85

PING 192.168.113.85 (192.168.113.85) 56(84) bytes of data.

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

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

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

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

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

--- 192.168.113.85 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

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
nameserver 192.168.113.104
nameserver 131.215.125.1
nameserver 131.215.139.100
nameserver 131.215.9.49
op340m:~>date
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.

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.

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

 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.

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.

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.

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.