40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 191 of 341  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  10006   Fri Jun 6 14:56:09 2014 ericqUpdateelogAaaaaand we're back!

ELOG is back up and running after last Friday's disk-crash-a-thon. SVN is still a work in progress. Jenne and I are now restarting computers and such.

  10011   Mon Jun 9 12:19:17 2014 ericqUpdateCDSComputer status

Quote:

The first nameserver on all of the workstation machines inside of the file /etc/resolv.conf has been changed to be 192.168.113.104, which is Chiara's IP address (it used to be 192.168.113.20, which was linux1).  This change has also been made on the framebuilder, and in the framebuilder's /diskless/root/etc/resolv.conf file, which is what all of the fast front ends look to. 

On the framebuilder, and in the /diskless place for the fast front ends, presumably we must have changed something to point at the new location for the shared drive, but I don't remember how we did that [ERIC, what did we do???]

In all of the fstabs, we're using chiara's IP instead of name, so that if the nameserver part isn't working, we can still get the NFS mounts.

On control room computers, we mount the NFS through /etc/fstab having lines like:

192.168.113.104:/home/cds /cvs/cds nfs rw,bg 0 0
fb:/frames /frames nfs ro,bg 0 0

Then, things like /cvs/cds/foo are locally symlinked to /opt/foo

For the diskless machines, we edited the files in /diskless/root. On FB, /diskless/root/etc/fstab becomes

master:/diskless/root                   /         nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
master:/usr                             /usr      nfs     sync,hard,intr,ro,nolock,rsize=8192,wsize=8192    0 0
master:/home                            /home     nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
none                                    /proc     proc    defaults          0 0
none                                    /var/log        tmpfs   size=100m,rw    0 0
none                                    /var/lib/init.d tmpfs   size=100m,rw    0 0
none                                    /dev/pts        devpts  rw,nosuid,noexec,relatime,gid=5,mode=620        0 0
none                                    /sys            sysfs   defaults        0 0
master:/opt                             /opt      nfs    async,hard,intr,rw,nolock  0 0
192.168.113.104:/home/cds/rtcds         /opt/rtcds      nfs     nolock  0 0
192.168.113.104:/home/cds/rtapps        /opt/rtapps     nfs     nolock  0 0

("master" is defined in /diskless/root/etc/hosts to be 192.168.113.202, which is fb's IP)

and /diskless/root/etc/resolv.conf becomes:

search martian

nameserver 192.168.113.104 #Chiara

 

 

  10049   Tue Jun 17 16:52:40 2014 ericqUpdateComputer Scripts / Programsautolocker confusion

Quote:

the MC autolocker is NOT running alright.

I'm kind of confused by the current auto locker situation. Somebody renamed the script from autolockMCmain40m to AutoLockMC.csh and did not update the crontab with the new filename. 

Furthermore it doesn't seem like  scripto_cron,a script which keeps the auto locker alive, runs ok on ottavia. When I run this on the command line, it claims that the process is already running, and returns some bunk PID that doesn't correspond to any running process. The script has a line stating setenv OSTYPE solaris , so maybe there's something funky going on with it's pgrep-ing or other command parsing.   

Lastly, if I try running AutoLockMC.csh directly on ottavia, I get a bunch of complaints about pmath and pezcabit not being found. 

  10050   Tue Jun 17 17:04:26 2014 ericqUpdateComputer Scripts / ProgramsFB troubles

Quote:

Also, the CDS FE status screen had red lights blinking as if it required an 'mxstream restart'. I did the same and it did not fix the problem. So I tried to restart fb using the usual 'telnet fb 8087'; but could not restart fb that way.

 FB is acting strange. When ssh-ing in, certain commands cause an inescapable hang, which can't be ctrl-c'd out of. Telling it to reboot does nothing. This kind of situation was seen by me before, when we were getting all the front ends back, I eventually hard rebooted it, hoping it was a one time thing. Guess it's not. 

Looking at the dmesg output, daqd seems to be segfault-ing all over the place. This may be related... Here are some examples:

451314.730502] daqd[17339]: segfault at 7ff589ae3b30 ip 00007ff589ae3b30 sp 00007ff49931dfb8 error 15 in libmyriexpress.so[7ff589ae3000+1000]

[530516.313238] daqd[18442] general protection ip:7f3f2ce73a6c sp:7f3e29949d50 error:0

[530516.313250] daqd[18420] general protection ip:7f3f2ce73a6c sp:7f3e2a19fd50 error:0 in libc-2.10.1.so[7f3f2ce3f000+14c000]

[530516.313262]  in libc-2.10.1.so[7f3f2ce3f000+14c000]

[530516.327083] daqd[18412]: segfault at 3b04c9cd0 ip 00007f3f2ce73a6c sp 00007f3e2a4a7d50 error 4 in libc-2.10.1.so[7f3f2ce3f000+14c000]

[537695.364481] daqd[18489]: segfault at 12dbbcae0 ip 00007fa35a3b8a0a sp 00007fa298381af0 error 6 in libmyriexpress.so[7fa35a399000+28000]

[577316.821618] daqd[18758]: segfault at 7f5c4d3e9b30 ip 00007f5c4d3e9b30 sp 00007f5b5cc23fb8 error 15 in libmyriexpress.so[7f5c4d3e9000+1000]

I'm not inclined to go reboot it right now, but not sure how to address these problems...

 

 

  10061   Wed Jun 18 18:00:36 2014 ericqUpdateComputer Scripts / Programscontrol room bashrc change

Some time ago, Rana changed the PS1 prompt codes on the control room computers. However, the exit codes of commands weren't being displayed, and there was some lingering color changing after the line. Hence, I changed it to look like this:

PS1='\[\033[0;35m\]\u'
PS1="$PS1\[\033[0;30m\]@"
PS1="$PS1\[\033[0;33m\]\h"
PS1="$PS1\[\033[0;97m\]|"
PS1="$PS1\[\033[0;92m\]\W"                                                 
PS1="$PS1\[\033[0;31m\] \${?##0}"
PS1="$PS1\[\033[0;97m\]>\[\033[0m\] "

The \${?##0} means: display the exit code if it is not zero (which means success). Thus, it only displays the exit code when its something other than what is expected.

  10066   Wed Jun 18 22:34:44 2014 ericqUpdateIOOcaget frusrtation

Quote:

 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.

This is still happening. Specifically: on all of the control room computers, calls to caget display the result immediately, but then hang for five seconds (consistently five). We had also seen a situation where calls hang indefinitely on ottavia/pianosa, but a reboot "fixes" this.

Some observations:

  • Front end machines and the FB have proper caget/caput response times.
  • Control room machines have some odd ping behavior when targeting frontends/FB; namely the ping times themselves are ok, but each ping line takes quite some time to show up, which made us think that there is odd network routing issue happening with some network switch. 
  • Front ends and FB get epics from /opt/rtapps, whereas control room machines get epics from /ligo/apps, which has different contents. (Is this for Gentoo vs. Ubuntu? I don't really get why this is the case...). This means different environment setting scripts to be called, so maybe the control room machines are misconfigured in some way for the new name server?

I poked around the network settings on all of these machines, but everything seemed reasonable. Nothing was changed. Rossa and Pianosa have their network settings done through some Ubuntu GUI, but I don't know where the settings are written. I had expected their settings to be in /etc/network/interfaces; maybe we should change this to be consistent with other machines, and easier to administrate via the terminal. 

Despite all this, ezcaread is fine.

  10067   Wed Jun 18 22:47:48 2014 ericqUpdateCDSRaspberry pi added to martian network

I set up a raspberry pi on the martian network, to be hooked up to a frequency counter for tracking ALS beatnotes. 

The instructions at https://wiki-40m.ligo.caltech.edu/Martian_Host_Table are outdated, the name server configuration is now at /etc/bind/zones/martian.db, I need to remember to update the wiki soon. 

In any case, the raspberry pi is called "domenica," is found at 192.168.113.107, and has the standard controls user, with /cvs/cds mounted in the same way as the control room machines. 

Once I'm comfortable with the configuration of the pi, I'm going to take an image of the SD card that serves as its hard drive, so that we can just image new cards for future raspberry pis on the martian network if we ever want them. 

  10077   Thu Jun 19 22:04:23 2014 ericqUpdateComputer Scripts / Programscaget/caput now return in reasonable time

I think I've fixed the caget/caput issue. Rana's observation that pinging the IP directly was faster than pinging the hostname set me on a path of googling which informed making the following changes to the DNS setup on chiara (specifically, informed by this thread: http://www.dslreports.com/forum/r11836974-BIND-slow-to-reply-over-LAN-Solved)

/etc/bind/named.conf.local has these lines:

zone "martian" IN {
 type master;
 file "/etc/bind/zones/martian.db";
 };
zone "113.168.192.in-addr.arpa" {
 type master;
 file "/etc/bind/zones/rev.113.168.192.in-addr.arpa";
};

The first zone command links hostnames like c1lsc to an IP like 192.168.113.62, but apparently in the second, we need to do the inverse. So, for each line in martian.db like

c1lsc           A       192.168.113.62

I added a line in rev.113.168.192.in-addr.arpa like so:

62 IN PTR c1lsc.martian

This seems kind of silly, but now if you do the host command from a workstation, it can find the hostname associated with an IP. 

controls@pianosa|~ > host 192.168.113.62
62.113.168.192.in-addr.arpa domain name pointer scipe12.martian.113.168.192.in-addr.arpa.
62.113.168.192.in-addr.arpa domain name pointer c1lsc.martian.113.168.192.in-addr.arpa.

[At this point, note that we have a bunch of duplicate entries in https://wiki-40m.ligo.caltech.edu/Martian_Host_Table  with these scipe## hostnames. What are these for?]


 
Now (edited for brevity):
 
controls@ottavia|~ > ping -c 5 -D c1sus
PING c1sus.martian (192.168.113.85) 56(84) bytes of data.
<SNIP>
--- c1sus.martian ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3997ms
rtt min/avg/max/mdev = 0.051/0.075/0.114/0.028 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.
<SNIP>
--- 192.168.113.85 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
rtt min/avg/max/mdev = 0.052/0.130/0.380/0.127 ms
 
controls@pianosa|~ > time caget C1:LSC-XARM_GAIN
C1:LSC-XARM_GAIN               0.015
real    0m0.039s
 
controls@pianosa|~ > time caput C1:LSC-XARM_GAIN 0.0151
Old : C1:LSC-XARM_GAIN               0.015
New : C1:LSC-XARM_GAIN               0.0151
real    0m0.054s
 
 
 

 

  10080   Fri Jun 20 11:43:30 2014 ericqUpdateComputer Scripts / ProgramsRestarting ELOG

Manasa let me know that the ELOG was down, and that she used the normal restart procedure, but then all entries were gone. 

This is because the ELOG has been moved on nodus, so going to the old place and running the restart script starts up the old dysfunctional ELOG installation. 

The proper place to restart the ELOG is now nodus:/export/home/elog/start-elog.csh

I'm updating the relevant 40m wiki page now. 

  10088   Mon Jun 23 20:58:38 2014 ericqUpdateCDSBootfest 2014!

This afternoon, I wanted to start the nominal alignment/adjustment steps for evening time locking, but got sucked into CDS frustrations. 

Primary symptom: TRX and TRY signals were not making it from C1:SUS-ETMX_TR[X,Y]_OUT to C1:LSC-TR[X,Y]_IN1. Various RFM bits were red on the CDS status page. 

 Secondary symptom: ITMX was randomly getting a good sized kick for no apparent reason. I still don't know what was behind this. 

First fix attempt: run sudo ntpdate -b -s -u pool.ntp.org on c1sus and c1lsc front ends, to see if NTP issues were responsible. No result.

Second fix attempt: Restart c1lsc, c1sus and c1rfm models. No change

Next fix attempt: Restart c1lsc and c1sus frontend machines. c1lsc models come back, c1sus models fail to sync / time out/ dmesg has some weird message about ADC channel hopping. At this point, c1ioo, c1iscey and c1iscex all have their models stop working due to sync problems. 

I then ran the above ntp command on all front ends and the FB, and restarted everyone's models (except c1lsc, who stayed working from here on out) which didn't change anything. I command-line rebooted all front ends (except c1lsc) and the FB (which had some dmesg messages about daqd segfaulting, but daqd issues weren't the problem). Still nothing. 

Finally, Koji came along and relieved me from my agony by hard rebooting all of the front ends; pulling out their power cables and seeing the life in their lights fade away... He did this first with the end station machines (c1iscey and c1iscex), and we saw them come back up perfectly happy, and then c1ioo and c1sus followed. At this point, all models came back; green RFM bits abounding, and TR[X,Y] signals propagating through as desired. 

Then, we tried turning the damping/watchdogs back on, which for some strange reason started shaking the hell out of everyone except the ETMs and ITMX. We restarted c1sus and c1mcs, and then damping worked again. Maybe a bad BURT restore was to blame?

At this point, all models were happy, all optics were damped, mode cleaner + WFS locked happily, but no beams were to be seen in the IFO 

The Yarm green would lock fine though, so tip-tilt alignment is probably to blame. I then left the interferometer to Jenne and Koji. 

  10095   Tue Jun 24 22:46:15 2014 ericqUpdateComputer Scripts / Programsop340m crons

Quote:

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.

 We had fiddled with the scripts/general/scripto_cron script to try and get the MC auto locker working on ottavia, but in doing so broke op340m's reliance on it to run it's cron jobs, like FSSSlowServo.

I've reverted scripto_cron to its original state, and the FSS slow servo starts up again.  

However, scripts like this that we want to always have on seem to be a better fit, to me, for the init system, like we do with daqd and nds on the FB. op340m's inittab looks different than what I'm used to, so I'm not making any changes; this is just a thought. 

MC autolocker is still being ran from an Ottavia GUI terminal; I'll try to get it consistently running on megatron, as suggested in  ELOG10039, now that caget/caput issues seem to be sorted. 

Addendum: I've changed the MC auto locker script to have megatron as its host. Haven't yet gotten it to run automatically; it's running in a detached tmux terminal. I'll finish it up tomorrow. 

  10113   Mon Jun 30 16:55:24 2014 ericqUpdateGeneralIFO (mostly) aligned

IR Alignment of the IFO is recovered! Green alignment could use some attention. 

Arms and PRC hold well, powers are within normal ranges. (TR[X,Y] >.9, POP110I > 400)

Details:

  • Starting from where Koji had brought things (i.e. beams on REFL, AS), I gradually stepped the PRM back to where I had a PRC lock right before the bootfest, using SUSPIT_IN and SUSYAW IN, while stepping the TT pointing (arbitrarily shifting TT1 and TT2) to keep the REFL camera spot centered. 
  • Green was locked fairly well to the Yarm (GTRY = 0.8), so I knew it supported a mode. I misaligned ITMX to keep the Xarm out of the way. 
  • Adjusting TT1 and TT2, I was able to get some light on the POP camera, while keeping REFL spot visible with small adjustments to PRM
  • I set up the PRM to set up some PRM-ITMY retroreflection, and saw tiny flashes in TRY. 
  • From here, I wandered around with the tip-tilts to try and get better arm pointing, while tweaking PRM for the REFL spot and retroflection, and BS for the AS spot. I got this to TRY flashes of ~0.3

Then, Jenne took over, worked some alignment magic, and did the hard part of getting the Yarm locked and ASS'd. 

  • I then took back over and got the Xarm locked and ASS'd.
  • I saved relevant mirror positions, and set up the PRMI, got it locked, saved PRM position. 
  • Jiggled the BS/PRM oplev HeNe power connector, it turns on now, oplevs are working. 
  • Similar to TT1, TT2 gains for PIT and YAW are now 300. Strictly speaking, they don't have to be, but PIT would be very nearly railed, and I changed YAW so that all four gains would be consistent.

Caveats:

Green no longer locks to 00 on the Y-arm, and the X-arm green transmission isn't the best despite PZT fiddling (~.6). Also, when green is locked to the Xarm, I see a distinct circular spot on the GTRY camera, with Y green and PSL green shutters closed. 

While Jenne used Yarm ASS successfully, when I run it now, it slowly pushes things out of alignment, and two of the traces (YARM_ETM_YAW_L_DEMOD_I_OUTPUT, and the same for ITM) have a reasonable constant offset that doesn't move away. 

 

  10116   Tue Jul 1 13:57:33 2014 ericqUpdateComputer Scripts / ProgramsMC Autolocker on Megatron

 Just a quick update on the status of the auto locker:

The auto locker now runs and respawns automatically on megatron, through ubuntu's "upstart" init system, instead of cron. 

  • The autolocker script itself is:/opt/rtcds/caltech/c1/scripts/MC/AutoLockMC.csh
  • The startup script called by the upstart system is: /opt/rtcds/caltech/c1/scripts/MC/AutoLockMC.init
  • The upstart configuration is: /etc/init/MCautolocker.conf
  • The auto locker is started by executing this command on megatron: sudo initctl start MCautolocker

This was pretty simple to set up, once I figured out how to provide the necessary environment variables in AutoLockMC.init 

  10122   Wed Jul 2 15:35:34 2014 ericqUpdateComputer Scripts / ProgramsLocal Chiara backups

Koji has provided a 2TB USB3 external hard drive that will get daily backups of chiara:/home/cds, the idea being that if the internal HD at /dev/sdb1 fails, we can physically open the external up, and swap the hard drive into chiara. 

We're running an rsync job on it right now, which should be done in a few hours. (USB3 is fast!)

I've also written a backup script at scripts/backup/rsync_chiara.backup which keeps its books in scripts/backup/rsync_chiara.backup.log 

I'm adding a entry to the root crontab on chiara to execute the script every day at 7am. 

 

  10236   Fri Jul 18 15:21:12 2014 ericqUpdateComputer Scripts / ProgramsLocal Chiara backups

Quote:

I've also written a backup script at scripts/backup/rsync_chiara.backup which keeps its books in scripts/backup/rsync_chiara.backup.log 

I'm adding a entry to the root crontab on chiara to execute the script every day at 7am. 

 I had some syntax errors in the script that prevented the script from doing the right thing. The backup is now up to date, and the cronjob should work. 

  10247   Mon Jul 21 13:58:33 2014 ericqUpdateIOOMC autolocker acting up

The autolocker claimed it was running and blinking, but not doing anything (i.e. lock bit was not updating and no switches or sliders being touched)

After stopping and starting it a number of times, it began working again, through no real changes of my own. I'm a little mystified as to what the problem was... keep an eye out.

  10248   Mon Jul 21 17:32:43 2014 ericqSummaryLSCArm losses

Quote:

From the last plot:

- Subtracting the offset of 0.0095, the modulation depth were estimated to be 0.20 for 11MHz, 0.25 for 55MHz

- Carrier TEM00 1.0, 1st order 0.01, 2nd order 0.05, 3rd order 0.002, 4th order 0.004

==> mode matching ~93%, dominat higher order is the 2nd order (5%).

Eric: now we have the number for the mode matching. How much did the cavity round-trip loss be using this number?

Using these numbers for both arms (Modulation takes away .2*.25 = 5% power, mode matching takes away 7% after that), I get the following from my data from March:

Xarm loss is 561.19 +/- 14.57 ppm

Yarm loss is 130.67 +/- 18.97 ppm

Obviously, the Xarm number looks very fishy, but its behavior was qualitatively very different when I took the data. ASDC would change from ~0.298 to ~0.306 when the Yarm was locked vs. misaligned, whereas the xarm numbers were .240 to .275. 

In any case, I'll do the measurement again tomorrow, being careful with offsets and alignment; it won't take too long. 

  10253   Tue Jul 22 15:54:19 2014 ericqUpdateSUSITMY Oplev Recentered

 ITMY oplev was nearly clipping in yaw, causing wonky behavior (POY lock popping in and out frequently). I recentered it and the arm is locking fine now. 

  10267   Wed Jul 23 23:43:28 2014 ericqUpdateLSCLocking efforts; Wrath of the Mode Cleaner

 [Koji, ericq]

We were working on getting back into the locking groove tonight.

The POP2F and REFL3F demod angles needed some tuning to lock the PRC reliably. The green alignments were mostly fine, the X end PZT ASS works reasonably well. Suspensions, especially the ITMs, seemed to be drifting a fair deal; today was fairly hot out, I guess.

We only got to the point of attempting the SqrtInv handoff once (which failed because I forgot to check the filter bank offsets). This was because the Mode Cleaner refused to stay locked longer than ~5-10 minutes at a time. We adjusted the MC and FSS servo offsets by the usual means, but this didn't make a difference.

We discussed and decided that the time is right to roll up our sleeves and dig into the MC loop, and try to figure out why these intermittent times of unreliability keep cropping up. We will check out the servo board, and see if we can find the missing phase than Evan observed, as well as characterize the FSS/PZT crossover, and investigate what kind of conditions we may create that cause the PC to saturate.

  10269   Thu Jul 24 13:01:39 2014 ericqUpdateSUSPRM OPLEV!

 Here's a fun fact: since the great computer failure of June2014, the PRM Oplev gains have been ZERO.

oops.png

arrrrggggh

I've restored the gains to their old values, and measured the loop TFs.

PRMOLPIT.pdfPRMOLYAW.pdf

 

 

 

 

  10292   Tue Jul 29 21:34:41 2014 ericqUpdateComputer Scripts / ProgramsSVN bulletin

A heads up to anyone using SVN with computers on the Martian network:

When we moved the svn repository on nodus to /export, we set it up such that the internet-facing svn URL was unchanged. However, it turns out that the martian network machines (i.e. Stuff mounted on the NFS share) were still pointing to the old svn files in /cvs/cds/caltech/svn, and thus not seeing new revisions made in /export/home/svn. If your martian network svn'd files got weird, this is why. 

I'm relocating the root svn URLs on the martian machines' checkouts to point to the nodus https address as I find them, to make them robust against future local movement of the svn files. 

Peoples' user files should be fine, this looks like it'll only really affect things such as scripts and medm screens, etc. 

  10303   Thu Jul 31 09:14:14 2014 ericqUpdateIOOMC stability

 Last night, I poked around to try and see if I could reproduce the sketchy MC behavior by exciting MC2 in a way that may be similar to what we do when using it as a CARM actuator. 

The short of it is that at frequencies under 1k, the MC lock didn't mind MC2 position excitations up to 8000 counts. However around 4-5k, a 1000 count excitation would induce a good deal of low frequency (2-5Hz) activity in the MC trans power, causing it to fluctuate by thousands of counts before unlocking. If I turned the excitation off before the unlock, it would eventually settle back down, but not immediately. 

I was able to reproduce this a handful of times before it decided to stop locking altogether, perhaps because of its random mood swings, or perhaps because this kind of disturbance is related to the mood swings...

  10323   Fri Aug 1 15:32:07 2014 ericqUpdateComputer Scripts / ProgramsElog and svn backups

Koji and Evan have both brought up a good point that we may not be backing up the svn and ELOG properly.

I have modified the rsync.backup script that nodus' cron runs every night that backs up /cvs/cds to what I presume are the tape backups at ldas-cit.ligo.caltech.edu.

Specifically, I added two rsync commands that grab the svn and elog directories from /export/home and copy them to their old locations in /cvs/cds/caltech. This way, the old locations are updated, and the tape backups stay current.

  10326   Sun Aug 3 17:19:32 2014 ericqUpdateGeneralRecovery efforts

[ericq, Jenne]

We both happened to come by today to fix things up.

When I arrived, the PMC was locked to a 01 mode, which I fixed. The PMC transmission is still worryingly low. MC locked happily. 

ETMX was getting odd kicks, the kind where a DC shift would occur suddenly, and then go away a few moments later. I turned off all dynamic coil outputs, and looked at the MON output of the SOS driver with a scope to try and see if the DAC or dewhitening was glitching, but didn't see anything... Meanwhile, Jenne fiddled with the TTs until we got beams on POP and REFL. (EDIT, JCD:  Useful strategies were to put an excitation onto TT2, and move TT1 until the scattered beam in the chamber was moving at the excitation frequency,  Find the edges of TT2 by finding where the scattered light stops seeing the excitation, and center the beam on TT2.  By then, I think I saw the beam on the PRM face camera.  Then, put a temporary camera looking at the face of PR2.  Using TT2 to center here got us the beam on the POP camera.)

We then walked PRM and the TTs around to keep those two camera beams and get the PRM oplev beam back on its QPD. At this point, ITMX was misaligned (by us), and ITMY aligned to get some recycled flashes into the Y-arm. Y-arm was locked to green, and we poked TTs to get better IR flashes. Misaligning PRM, we had Y-Arm flashes of ~0.7. From there, the michelson and then X-arm were roughly aligned. Both arms were seeing flashes of about 0.7, and the MICH fringes on the AS port look nice.

Frustratingly, the SUS->LSC communication for TRY and TRX isn't working, and could not be fixed by any combination of model or front-end restarting... Thus we haven't been able to actually lock the arms and run ASS. THIS IS VERY FRUSTRATING. 

Additionally, at the point where we were getting light back into the Yarm, the ITMX that were seen on Friday were happening again, tripping the watchdog. Also, something in the Yarm cavity is getting intermittently pushed around, as can be seen by the green lock suddenly wandering off. All of these suspension shenanigans seem to be independent of oplev damping. 

It troubles me that this whole situation is fairly similar to the last time we lost the input pointing (ELOG 10088)

In any case, we feel that we have gotten the IFO alignment to a lockable state.

  10329   Mon Aug 4 17:30:00 2014 ericqUpdateGeneralChronic Suspension Problems

TRX and TRY communication were recovered by doing a simultaneous reboot of all of the frontends.

Working with the interferometer has been extremely frustrating today. Having transmission values let us lock and ASS, but that has been less helpful than you would hope.

Saving the ASS offsets has repeatedly resulted in an overall bad change in alignment, moving the TTs and other things off randomly.

ITMX continues to be kicked. ITMY intermittently wanders away. It has not been possible to maintain IFO alignment for a reasonable length of time.

Also, the wall IOO striptool shows the MC2 Trans QPD Yaw having large step-function features. The MC is having an ok duty cycle, but this just may mean that the WFS are able to absorb what is happening to the MC suspensions.

The suspensions are really misbehaving. We need to get to the bottom of this, or else we are going to keep losing time to alignment.

  10339   Wed Aug 6 13:17:21 2014 ericqOmnistructureCDScdsutils: multifarious upgrades

I've checked out cdsutils-274 to /opt/rtcds/cdsutils, and updated the /ligo/apps/ligoapps-user-env.sh to have the newer machines use it by default. This was to gain access to the cdsutils.Step methods for use in the smooth ASS handoffs script. 

  10348   Thu Aug 7 16:47:35 2014 ericqUpdateSUSOplev Checkup

 I noticed some weird behavior on the ETMY oplev that led me to check them all out. 

The short of it is that the ETMY oplev has a pretty small angular range, compared to the displays and other oplevs. I measured how much angular motion each oplev can sense before the beam no longer hits all four quadrants (thus losing the ability to sense).  This could account for some of the additional angular motion of the mirrors... maybe. 

Also, some of the QPD quadrants had offsets as big as 400 counts, thus distorting the zero point. Anyways, here are the angular ranges of each QPD, assuming the current urad/cnt calibrations are valid. 

EMTY

  • P: +- 25urad
  • Y +- 30urad

ITMY

  • P:+-160urad
  • Y:+-172urad

 

BS

  • P:+-43urad
  • Y:+-40urad

 

ITMX

(Note: ITMX's oplev pitch and yaw is almost 30 degrees off of the alignment sliders' pitch/yaw coordinates. Steve tells me this is due to the tight nature of getting the oplev beam to the mirror without clipping.)

  • P:+-110urad
  • Y:+-80urad

 

ETMX

  • P:+-45urad
  • Y:+-85urad

 

PRM

  • P:+-50urad
  • Y:+-45urad

 

SRM

  • P:+-80urad
  • Y:+-80urad

I wrote a script to zero all of the QPD quadrants' offsets (it lives in /scripts/OL) and have used it successfully. The oplev laser must  be off before using it. 

  10351   Fri Aug 8 12:39:19 2014 ericqSummaryIOOMC servo analysis

I have measured the current boosted MC CLG below 100kHz with an SR785. Swept sine only could get me down to 10kHz, but I was able to get down to 5kHz with a noise-injection measurement. 

MCloopAug8.pdf

I am attaching the SR785 outputs, which are in dB and Degrees. Additionally I pruned the areas of bad coherence out of these, and merged them to provide data files for the CLG and OLG in Real,Imaginary format.

Attachment 1: mcLoopAug8.zip
  10354   Fri Aug 8 15:57:29 2014 ericqSummaryIOOMC servo analysis

 I did some further measurements, to try and see what corresponds to what. In the end I performed four measurements:

  1. Closed loop gain measurement on SR785: Source to MC exc, T'd to channel one. Test 2 to channel two.
  2. Open loop gain measurement on SR785: Source to MCexc, Test 2 to channel one, Test 1 to channel two.
  3. Closed loop gain measurement on AG4395: RF Source to MC exc, T'd to R input. Test 2 to A input.
  4. Open loop gain measurement on AG4395: RF Source to MC exc, Test 2 to R input. Test 1 to A input.

I then converted OLGs to CLG and vice-versa with CLG = 1/(1-OLG)

Here are two plots showing the measured and inferred loop TFs for both closed and open. 

OLTFs.pdfCLTFs.pdf

The best agreement seems to be between the directly measured OLGs. Maybe I did something weird with the CLG measurements, or input impedances are distorting things ... 

All data is attached, along with code used to generate the plots. 

Attachment 3: mcLoopAug8.zip
  10365   Mon Aug 11 23:32:54 2014 ericqSummaryIOOMC demod measurement

Here's the magnitude plot of the board TF. As mentioned above, this was done with Marconi+Scope, so we were not able to get the phase of this transfer function. 

MCDemod.pdf

Oddly enough, the bump that I saw is not included in Minicircuit's data on the SCLF-5.

Attachment 2: demodLP.txt
# F(Hz) RMS(mV)
1035 38.6
2031 38.47
4031 38.47
8032 38.38
16030 38.10
32030 38.10
64030 38.16
128000 38.10
256000 38.22
... 12 more lines ...
  10367   Tue Aug 12 02:09:39 2014 ericqUpdateGeneralReasonable alignment restored

I took over the IFO, after Jenne's locking efforts, which included manual alignment, since the ASS was doing bad things. 

For whatever reason, the Yarm ASS TT gains needed to be flipped back to go in the right direction. I've restored the old BURT snap file, and the ASS seems to work for now.  

Furthermore, I added some FMs to the Yarm ASS to be able to ramp down gains, to be done as new offsets are ramped in, so that a smooth offset transition is possible. The new version of the script works reasonably, but could be smoother still... Once I iron this out, I'll do the same change to the Xarm, and update the buttons. 

In any case, I was able to run ASS on both arms; single arm lock maxed out at around 0.85, maybe because we're only getting 0.78 from the PMC and 16k from the MC? I then aligned and locked the PRM, then reentered the oplevs on all of the PRMI optics. Oddly, the ETMs were at single uRads on their oplevs.

With this arm alignment, I was able to get the green TRX to ~0.55, and thus the beatnote to around -25dBm, which is still lower than we'd like. I didn't touch the Y green alignment, though it is pretty bad, at transmission of below 0.2 when "locked" on the 00 mode. 

When I try to lock things, the initial ALS CARM and DARM locking seems to go fine, actuating on the ETMs for both DoFs, but ETMX is getting kicked during the resonance search every time. Maybe improving green alignment / increasing beatnote amplitudes will hopefully help some.

I'm leaving the interferometer with the PRM aligned, so that all optics (except SRM) are near the center of their oplev range. I'm curious as to what their variance will be over the next day; this can inform whether we need to improve the ETMY oplev's angular range or not. 

  10369   Tue Aug 12 14:29:01 2014 ericqUpdateGeneralReasonable alignment restored

I'm leaving the interferometer with the PRM aligned, so that all optics (except SRM) are near the center of their oplev range. I'm curious as to what their variance will be over the next day; this can inform whether we need to improve the ETMY oplev's angular range or not. 

 Here's an 12 hour minute-trend of all of the oplevs. The worst offenders are ITMY pitch and yaw, and ITMX pitch. 

Additionally, ETMY's yaw range is +-30urad, and here we see it wandering by 10 urad in a half day. We probably need more range.  

OLtrend.png

  10370   Tue Aug 12 18:20:13 2014 ericqUpdateIOOFSS box TFs

I made some measurements of the FSS box today, to have TFs for a loop model, but also to see what the difference between the different inputs was. 

As a reminder, the FSS box takes the error signal from the MC servo, does some filtering, and sends out two outputs: one to the laser PZT via KojiBox and Thorlabs HV amplifier, and one to be summed with the PMC modulation signal to the PC. Rana found the schematic at D040105

The MC error signal currently enters via a port called "IN1", but there is also a "Test 1 in," which experiences different filtering. I measured the TFs from each of these inputs to both the FAST and PC outputs. There is also an IN2, that is added after the offset point, but was not able to make a good measurement, for reasons unknown. From these TFs, I inferred the difference between the PC and FAST path, as well as the difference between IN1 and Test 1 in.

Specifically, I plugged the cable that is usually connected to the MC servo output, labelled "TO FSS BOX", into the RF out of the AG4395. I then took a BNC cable from the FAST out, or PC out, and fed it into a mini circuits DC block (BLK-89-S+), and then into input A, after checking on a scope that the signal was roughly zeroed and not too huge. Unbeknownst to me at the time, the PC drive output can be pretty big, and could potentially fry the analyzer's input. Fortunately, I think I avoided this fate. 

FSSbox.pdfFSSfilt.pdf

A ~1.3 MHz bump can be seen here, which would conspire with the bump in the demod board I measured yesterday, to steal even more phase around 1MHz. Maybe we can modify the FSS box to help our gain peaking situation out. 

The data is attached.

RXA: Shazam!

Attachment 3: FSSdata.zip
  10372   Wed Aug 13 03:03:37 2014 ericqUpdateGeneralGreen beatnote troubles

[Jenne, Rana, ericq]

No luck locking tonight, as spent a while trying to figure out the complete absence of the green beatnotes. Long story short, we ended up having to adjust the pointing on the PSL table.

Unrelated to this, we also turned on the noise eater on the PSL laser because why not. 


We hooked the BBPDs directly up to a 300MHz scope to try to see the beat as it happened. We witnessed a very strange intermittent ~800MHz oscillation on the Y BBPD, and weirder still, on both the RF and DC outputs of the PD, and the frequency was independent of the laser temperatures. This is to be investigated in the future, but was not related to the beat note state. 

Some progress was made when we took some components out, and looked at the far field of the PSL-Ygreen overlap, and saw some misalignment, and corrected it. Putting the end laser temperature in the usual area allowed the beat note to be found, with the eventual amplitude of ~-40dBm directly out of the BBPD. The Y green alignment was pretty bad throughout, so this can be improved to bring the beat amplitude up. We should also check and make sure we're well aligned to the SHG with the PSL light. We're leaving the X beat for tomorrow, now knowing that we should be able to get it with careful alignment. 

  10390   Thu Aug 14 18:31:45 2014 ericqUpdateLSCLSC Modeling Update

 Based on the game plan, I have created a slew of updated pretty plots about our signals and loops. 

First: With measured arm losses, when do we start to see REFL DC dip? At what arm buildup powers? 

I updated my MIST model with the arm losses I've measured (Y:130ppm, X:530ppm), and some measured transmissions from the wiki, vs. the design parameters, as I used to have. Here is the DC sweep plot which is now hanging up in the control room. 

dcSweep.pdf

In this plot, I also calculated what MIST thinks the full arm power buildup will be as compared to our single arm locking, and I get something of order 200, rather than the 600 we've tossed around in discussions. Nothing else is very different in this plot from the old version; though the REFLDC dip is a little bit wider. 

Now, here are some radiation-pressure inclusive sensing transfer functions, for the anti-spring case (which in Rob's day was easier to lock for unknown reasons):

carm2TRX.pdfcarm2REFLDC.pdf

carm2REFL11.pdfdarm2AS55Q.pdf


Next: Include new AO path TFs into CM model Look at possibilities for engaging AO path 

With these TFs, and the recently measured+fit new AO TF, here are the open loop gains of the slow, digital, SqrtInv-sensed MCL CARM and fast, analog, REFLDC-sensed AO CARM loops for the region of offsets we've achieved and a little lower. The slow digital loop includes the 1k LP that we have used in the past, in addition to the normal CARM filters. I still need to figure out the right sequence of ( offset reduction / crossover frequency motion / overall gain adjustment ) that gets the coupled cavity resonance solidly within the loop bandwidth. 
 
MCLcarmLoop.pdfAOcarmLoop.pdf

 

  10402   Fri Aug 15 14:35:57 2014 ericqUpdateLSCTRY mystery offset gone

One question answered, but another raised. The offset came from LSC-TRY switching to the ETMY-QPD signal from ETMY-TRY (Hi gain pd). 

BUT WHY

TRYmystery.png

  10404   Fri Aug 15 20:26:37 2014 ericqUpdateGeneralGame plan

Quote:

Q already did the tweak up of the PSL SHG crystal alignment.  HE SHOULD ELOG ABOUT THIS.  What was the final power of green that you got?  Do we have any record of a previous measurement to compare to?

As Jenne mentioned, I did this. 

Specifically, I first tweaked the mirror pointing the IR into the SGH in pitch and yaw to maximize the green power, and then adjusted the little set screws on the side of the SHG to maximize further. Power after the harmonic separator was of order 150uW. On the Y Green BBPD, I got ~48uW, instead of the 40uW Rana, Jenne, and myself saw the other night. 

HOWEVER,

now that I look through old ELOGs, I find some posts by Kiwamu saying the power should be around 650uWand that he was able to get 640uW out. So: I should do this again, systematically, more carefully, etc., etc. (Linked ELOG also states that optimum SHG temperature is alignment dependent...)

 

 

  10405   Fri Aug 15 20:38:17 2014 ericqUpdateGeneralELOG dump

 A few things that I have neglected to ELOG yet:

  • scripts/offsets/LSCoffsets is a new script that uses ezcaservo to set FM offsets of our LSC PDs. It still warns about large changes, and lets you revert. It reads the FM gain to pick the right gain for the ezcaservo call. 

  • MC refl DC was all over the place today, and has recently been "fuzzier" on the wall StripTool than I like. I touched the MC2 pointing a little bit, and the WFS seemed to find a sweet spot where the refl got steady back at around and under 0.5. I then ran "offload WFS" to try and stay there. 

  • Incidentally, the PMC transmission drifted up to 0.81 at some point today. This is weird, since not too long ago, we were not able to reach this level even with careful alignment. This coincided with the MC power being back up to ~17k, and arms locking at around 0.95. 

  • Last week I quickly tried cranking up the x-end green modulation frequency to ~1.3MHz (corresponding to a notch in the PZT AM response), and using a 550k lowpass on the mixer output, instead of a 70k, to try to buy more phase and increase the UGF. It didn't work. I didn't have a way to tune the mixer phase angle, and the mixer output was super noisy, but there were instants where I could convince myself that a mode was briefly locked to the arm... I'm going to do the Right Thing and characterize the loop properly, to figure out how to get at least 10kHz of control bandwidth out of these things. 

  10407   Mon Aug 18 18:33:57 2014 ericqUpdateGreen LockingYarm Green PDH

So far today, I've been working with the Y-end green PDH locking. Using a SR560 to roll off the AG4395A output to take a loop measurement at the servo output, I measured the following OLG, and inferred the CLG from it. The SR560 really helped it getting good coherence without introducing a big offset that changes the optical gain, thus distorting the loop shape, etc. etc. 

yLoop.pdf

You would think this loop looks pretty good, 10k UGF, and 45 degrees of phase margin, gain peaking is sane, and pretty smooth slope. But, the thing still was flipping out of lock while I measured this. 

I suspect shenanigans at >100k. This is motivated by the fact that I've seen some big noise in the error signal around 150k. I don't have a good noise plot right now, because I'm trying to get a scheme going where I stitch together a bunch of 1 decade spectra from the 4395, but the noise floor isn't consistent across each patch (even though the attenuation stays the same, and I confirmed I'm in "noise" mode). I'm working on a loop measurement up there, too, but I haven't been able to get the right filter/amplitude settings yet. 

So, even though this plot is not totally correct (read: wrong and bad), I include it just for the sake of showing the big honking spike of noise at ~150K.  

crap.pdf

 

  10409   Tue Aug 19 18:32:40 2014 ericqUpdateGreen LockingYarm Green PDH

Heading to dinner, going to come back for more green fun, but here's a quick update:

Xarm Peak-to-Peak of the PDH signal in the mixer output is about 70mV when GTRX was about 0.4. The sideband-generating function generator has an output of 2V (forgot to note rms or pp)

Yarm Peak-to-Peak of the PDH signal in the mixer output is about 640uV when GTRX was about 0.71. The sideband-generating function generator has an output of 0.091V (forgot to note rms or pp)

The Yarm signal thus correspondingly has a waaay noisier trace. I would've had scope plots to show here, but the scope freaked out about how large my USB drive capacity was and refused to talk to it >:|

This suggests to me that our modulation depth for the Yarm may be much too small, and may be part of our problems with it. 

  10413   Wed Aug 20 04:09:21 2014 ericqUpdateGreen LockingXarm Green PDH

I've made a whole bunch of measurements on the Xarm green situation.

TL;DRs:

  • GTRX was around 0.55 for all of the measurements tonight. 
  • Based on where I saw gain peaking in the CLG, it looked like UGF was 1-2kHz. I cranked the gain to 10kHz, ~20dB gain peaking followed, making it hard to measure. Currently sitting at 5kHz-ish. 
  • Measured CLG with AG4395A, calibrated for injection point response, inferred OLG. 
  • Took various PSDs, still need to calibrate into physically meaningful units. 

Reasonable amounts of time were spent bending the AG4395 to my will; i.e. figuring out the calibration things Jenne and Rana did, finding the right excitation amplitude and profile that would leave the light steadily locked, and finding the right GPIB incantation for getting spectra in PSD units instead of power units. I'm nearing completion of a newer version of AG4395 scripts that have proper units, and pseudo-log spectra (i.e. logarithmically spaced linear sweeps)


Transfer functions

Here is too many traces on one plot showing parts of the OLTF for the x green PDH. One notable omission is the PD response (note to self:check model and bandwidth). The servo oddly seems to have a notch around 100k. My calibration for the CLG injection may not have been perfect, instead of flattening out at 0dB, I had 2dB residual. I tried to correct for it after the fact, assuming that certain regions were truly flat at 0dB, but I want to revisit it to be thorough. I found some old measurements of the Innolight PZT PM response, which claims to be in rad/V, and have included that on the plot. 

Xbodes.pdf

In the end, the mixer and PZT response make it look like getting over 10kHz bandwidth may be tough. Even finding a good higher modulation frequency to be able to scoot the LP up would leave us with the sharp slope in the PZT phase loss, and could cause bad gain peaking. Maybe it's worth thinking about a faster way of modulating the green light?


Noise Spectra

Tomorrow morning, I'll calibrate all the noise spectra I have into real units. These include:

  • In loop error signal and control signal spectra
  • Mixer output spectrum when PD is dark, and when mixer input is terminated
  • Servo out spectrum when PD is dark, and when servo input is terminated

However, looking at the floors, it occurs to me that I may have left the attenuation on the input too high, in an effort to protect the input the PDH box, which rails all the time when not locked to a 00 mode, sometimes even with the input terminated or open. It's kind of a pain that the agilent makes it really hard to see the data when you're in V/rtHz mode, because I should've caught this while measuring :/

I used a scope to capture a pdh signal happening, which will let me transform the mixer output into cavity motion. The control signal goes to the innolight PZT with a ~1MHz/V factor. Here are the uncalibrated plots, for now. 

scopeSweep.jpg

Xspectra.pdf

 

  10414   Wed Aug 20 15:31:27 2014 ericqUpdateCOCArm Loss Investigations Continue

 [ericq, Gabriele] 

Summary: After today's meeting, Gabriele and I looked into the arm loss situation, to see if we should really believe the losses that had been suggested by my previous measurements. We made some observations that we're not sure how to explain, and we're thinking about other ways to try and estimate the losses to corroborate previous findings. 


We first looked to see if the ASS had some effective offset, leaving the alignment not quite right. Once ASS'd, we twiddled each arm cavity mirror in pitch and yaw to see if we could achieve higher transmission. We could not, so this suggested that ASS works properly. 

We then looked at potential offsets in the Xarm loop. We found that an input offset of 25 counts increased the transmission, but only very slightly. With this offset adjusted, we confirmed the qualitative observation that locking/unlocking the xarm causes a much bigger change in ASDC than doing the same with the harm.

However, we noted that the ASDC data (which is the DC value of the AS55 RFPD) was quite noisy, hovering around 50 counts. Looking at the c1lsc model, we found that we were looking at direct ADC counts, so the signal conditioning was not so great. We went to the LSC rack and stole the SR560 that had been hooked up as a REFLDC offsetter, and used it to give ASDC a gain of 100, and a LP at 100Hz, since we only care about DC values. We then undid the gain in the input FM; and this calmed the trace down a fair bit. The effects due to each arm locking/unlocking was still consistent with previous observations. 


At this point, we looked at the arm transmission and ASDC signals simultaneously. Normally, when misaligning a cavity, one would expect the reflected power to rise and the transmission to fall.

However, we saw that when misalignment the Yarm in yaw in either direction, or the Xarm in one direction, both the IR transmission and ASDC would fall. This initially made us think of clipping effects. 

So, we checked out the AS beam situation on the AP table. On a card, the beam looks round as we could tell, and the beam spot on AS55 was nice and small. (We tweaked its steering a little bit in pitch to put it at the center of the "falling-off" points) The reflection and transmission falling effect remained. 


At this point, we're not really sure what could be causing this effect. After the reflected beams recombine at the BS, the output path is common, so it's strange that this odd effect would be the same for both arms. 

Lastly, we discussed other ways that we may be able to see if the Xarm really has ~500ppm loss. Since its transmission is ~1.4%, Gabriele estimated that we may be able to see a ~300Hz difference in the arm cavity pole frequency between the two arms, based on the modification of the cavity finesse due to loss. Since we don't currently have the AOM set up to inject intensity noise, we talked about using frequency noise injection to measure the arm cavity poles, though this would be coupled with the IMC pole, but this could hopefully be accounted for.

  10415   Wed Aug 20 16:10:43 2014 ericqUpdateGreen LockingXarm Green PDH

A MIST simulation tells me that the green pdh horn-to-horn displacement is about 1.2nm, or ~18kHz. I used this, along with the scope trace attached to the previous post, to calibrate the mixer output at 193419 Hz per V. (EDIT: I was a little too hasty here. What I'm really after is the slope of the zero crossing, which turns out to be almost exactly twice my earlier naïve estimate. See later post for correct spectra)

For the control signal, I assumed a flat Innolight PZT PM response of 1MHz/V. ( Under 10kHz, it is indeed flat, and this is the region where the control signal is above the servo output noise in yesterday's measurements)

Here are all of the same spectra from last night, with the above calibrations. 

XspectraCombined.pdf

 

Going off Jenne's earlier plot, it looks like the in-loop error signal RMS is ten times bigger than the CARM linewidth. 

  10417   Wed Aug 20 21:09:16 2014 ericqUpdateGreen LockingXarm Green PDH

I remeasured all of the noise spectra again today, making sure the input attenuation was as low as it could safely be. I also got a snap of the y green PDH signal; it's fairly larger than I saw the other day, which is good. I used this to calibrate the error signal voltage spectra. 

scopeSweep.jpg

Here are the noise traces for each arm. During these measurements GTRX was about .6, GTRY about 1.0 The Yarm noise doesn't look so good: the error signal is just barely above the mixer+lowpass output noise, and the RMS is plauged by 60Hz lines. (Is this related to what we see in IR TRY sometimes?)

Xspectra.pdfYspectra.pdf

Here are the arms error signals compared directly:

XYcomp.pdf

  10420   Thu Aug 21 19:04:52 2014 ericqConfigurationGreen LockingGain changes on Green Y PDH

I found that the barrel of one the BNC to BNC connectors used for getting the output of the PDH servo box to the laser controller was touching the ETMY chamber. When I held it away, all of the 60Hz harmonics disappeared from the mixer output spectrum; this was pretty repeatable. This inspired me to replace the refl PD and PZT signal cables (which were 2 and 3 cables stitched together, respectively) with 20' long BNCs. I also cleaned up a lot of the routing of signal and power cables in the little rack, and moved the big T->DC Block->Attenuator combo off of the panel mount, because I didn't like how it was wiggling. It and the summing pomona box are sitting on top of the PDH box and function generator, instead of hanging freely.

All of the 60Hz harmonics were banished afterwards, and the green locked happily. 

This required me touching the Y end table, to remove the old cable and its cable ties, and putting the new one in. I don't think I did anything immediately apparently bad; the green and IR transmissions both are within nominal ranges. 

I haven't had luck measuring the CLG yet, which I wanted to do to get and set the UGF before measuring the noises. However, here is a scope trace of the in-lock error signal, which compares quite favorably to the trace posted in the previous post; the scope indicates that the signal has 1/3 of the RMS that it did before I replaced the cables. 

TEK00005.PNG

I hope to measure up the current status after I get back from dinner. 

 

  10430   Tue Aug 26 23:16:49 2014 ericqConfigurationGreen LockingGain changes on Green Y PDH

 Yesterday I measured the spectra and OLTF of the Y-Arm green PDH, after the LO touch-up and 60Hz hunt from last week. I also went to lower frequencies with the SR785, but forgot to take some of the background spectra down there, so I don't have the full breakdown plots yet. Nevertheless, here is the improvement in the PDH error signal:

pdhComparison.pdf

I also measured the OLTF (SR785 injection at the error signal, Auto level ref 5mV at channel 2, 10mV/s source ramping, 50mV max output)

Ytfs.pdf

As you can see, we have tons of phase margin. Flipping the local boost switch had no visible effect on the OLTF; we should change it to something that puts this surplus of phase to good use, and squash the error signal even more. Putting an integrator at 5kHz should still leave about 45 degrees phase margin at 10k. I've started making a LISO model of the PDH board from the DCC drawing, and then I'll inspect the boards individually to make sure I catch the homegrown modifications. 

Data, and code used to generate the plots is attached. 

Attachment 3: newY.zip
  10431   Tue Aug 26 23:46:55 2014 ericqUpdateIMCWFS tuneup

 I decided to see what I could do with the new WFS setup. 

First, I adjusted the WFS digital demod angles. Once I ensured that the static MC alignment and DC alignment onto the WFS was good, I drove MC2 in pitch with the WFS output off. I then did the usual thing of making the Q peak at the excitation frequency go away. Here are the changes:

  • WFS1 Q1: 7 -> -24 (-31)
  • WFS1 Q2: 6.5 -> -9.5 (-16)
  • WFS1 Q3: -6.5 -> -26.5 (-20)
  • WFS1 Q4: 47 -> 30 (-17)
  • WFS2 Q1: -51 -> -39 (-12)
  • WFS2 Q2: -39 -> -21 (-18)
  • WFS2 Q3: -32 -> -20 (-12)
  • WFS2 Q4: -120 -> -108 (-12)

I then drove each MC mirror in pitch and yaw respectively, and measured the TF from excitation to the WFS signal (dB Magnitude, sign):

 

Mirror DoF WFS1 Pitch WFS1 Yaw WFS2 Pitch WFS2 Yaw
MC1 Pit -67.7,+ -81.9,+ -58.9,- -83.7,+
  Yaw -82.5,- -48.7,- -83.7,+ -112.3,-
MC2 Pit -50.4,- -77.1,- -54.2,- -67.9,+
  Yaw -82.1,- -52.9,+ -59.6,- -44.0,-
MC3 Pit -59.7,- -97.3,+ -62.0,+ -83.9,-
  Yaw -78.0,+ -52.9,+ -67.3,+ -51.4,+

 

I looked through some old ELOG's of Suresh's and used similar logic to scripts/MC/WFS/wfsmatrix2.m to generate a new output matrix. (This involves creating a null sensing vector that is orthogonal to the measured ones, and inverting that matrix) 

Old:

Pitch WFS1 WFS2 MC2T   YAW WFS1 WFS2 MC2T
MC1 -1 0.044 0   MC1 -1 -0.294 0
MC2 0.19 1 1   MC2 -0.26 -0.045 -1
MC3 0.5 -0.681 0   MC3 -.9 1 0

 

New:

 

Pitch WFS1 WFS2 MC2T   YAW WFS1 WFS2 MC2T
MC1 0.835 -1 0   MC1 -1 -0.229 0
MC2 -0.948 -0.433 1   MC2 0.317 -1 -1
MC3 -1 0.865 0   MC3 0.743 0.628 0
 

 

I had to flip a gain or two to keep things stable, then measured the WFS error signal spectra to see if this made anything better. The WFS1 spectra look better, but WFS2 not so much. 

newWFSmatrix.pdf

The loops would need a more thorough investigation, but for now, they're at least a little calmer. The MC is stabler than immediately after the upgrade, but there's still room for improvement. 

 

  10433   Wed Aug 27 18:03:47 2014 ericqUpdateGreen LockinguPDH Box Checkup

 Quick post of plots and data; I'll fill in more detail tonight. 

TL;DR: I pulled both green PDH boxes and made LISO models, compared TFs and noise levels. 


Pictures of X and Y boards, respectively

uPDH_X.JPGuPDH_Y.JPG

 


TF comparison to LISO. (Normalized to coincide at 1Hz)

updhTFs.pdf

 


Noise comparison to LISO

updhNoises.pdf

 


To Do:

  • Figure out why TFs were made differently. Check PM response curves of PZTs to see if they are fine, or need tweaking.
  • Make boosts useful. Both are currently integrators with corners under 10Hz, which is already pretty suppressed. 
  • I just noticed that the X board is missing C25, which should be a 1uF cap on the positive power pin of the primary TF stage opamp. This should be inserted. 

All data, EAGLE schematics, LISO source and plots in the attached zip. 

 

Attachment 5: uPDH_Aug27.zip
  10434   Thu Aug 28 01:41:03 2014 ericqUpdateLSCPhase Tracker UGF normalization

We want both the X and Y phase trackers to have the same UGF, so that the X and Y ALS signals are subject to the same phase characteristics and can be nicely decoupled into CARM/DARM. 

I've started implementing a simple normalization scheme that Koji suggested, namely, dividing the I output of the phase tracker by a low passed version of the Q output. (Since the I is servoed to zero, the radius of the error signal in the IQ plane is essentially equal to the Q value) I put some simulink logic into the IQLOCK library part that BEAT[XY]_FINE are instances of to switch the normalization on/off, and to protect from divide-by-zeros. I also exposed the switching and FM on the ALS screen.

UGFnorm.png

I then tried using it, to mediocre results. I put a 10mHz LP in the filter module, found a Y-Arm beat, set the phase tracker gain to give me a 2kHz UGF, and then set the gain of the UGH normalization FM to turn the current average Q to unity. 

I then moved the laser temperature around to get different beatnote locations/amplitudes, hoping that the phase tracker UGF would stay the same when the UGH normalization was on.

It did not.

It did, however, correct it in the right direction... more work will be done with this, to try and make it useful. There's also the unfortunate effect that locking/unlocking the green causes erratic phase tracker output, which messes with the input to the normalizing LP filter, so if one were to leave it switched on, wonky stuff would come out. I don't want to go overboard with triggering shenanigans before I even get it working in the first place, though.  

  10437   Thu Aug 28 17:34:20 2014 ericqUpdateGreen LockinguPDH Box Checkup

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. 

TEK00006.PNG

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)

ELOG V3.1.3-