I've added states to the summary pages to only show data for times at which one certain channel is above a specified threshold. So far, I've incorporated states for the IOO tab to show when the mode cleaner is locked.

You can see these changes implemented in the IOO tab of my personal summary pages for June 30: https://ldas-jobs.ligo.caltech.edu/~eve.chase/summary/day/20150630/ioo/.

I've written a description of how to add states to summary pages here: https://wiki-40m.ligo.caltech.edu/DailySummaryHelp#How_to_Define_and_Implement_States.

The attached table shows the amplitude of the green beat note when the end laser was in various states. We can increase the beat note amplitude dramatically by switching to a different states.

State 1
C1:GCX-GRN_REFL_DC:             638 counts
C1:GCV-XARM_BEAT_DC: (PSL blocked)    950 avg counts (zero = -794 counts)
amplitude of beat note:            -23dBm (after PD + amps) (f ~ 30 MHz)?
C1:GCX-SLOW_SERVO2_OUT:            318 counts

State 2
C1:GCX-GRN_REFL_DC:             180 counts
C1:GCV-XARM_BEAT_DC: (PSL blocked)    1270 avg counts (zero = -794 counts)
C1:GCV-XARM_BEAT_DC: (PSL unblocked)    1700 avg counts (zero = -794 counts)
amplitude of beat note:            -7dBm (after PD + amps) f = 60MHz
amplitude of beat note:            0dBm (after PD + amps) f = 30MHz
C1:GCX-SLOW_SERVO2_OUT:            290 counts

State 3
C1:GCX-GRN_REFL_DC:             220 counts
C1:GCV-XARM_BEAT_DC: (PSL blocked)    1120 avg counts (zero = -794 counts)
C1:GCV-XARM_BEAT_DC: (PSL unblocked)    1520 avg counts (zero = -794 counts)
amplitude of beat note:            0dBm (after PD + amps) f = 15MHz
C1:GCX-SLOW_SERVO2_OUT:            305 counts

PSL temp = ??
C1:PSL-FSS_SLOWM = -3.524
 

There is an effort to switch to an all-digital system for the GigE camera feeds similar to the one running at LLO, which uses Joe Betzwieser's custom SnapPy package to interface with the cameras in Python and aggregate their feeds into a fancy GUI. Joe's code is a SWIG-wrapping of the commercial camera-driver API, Pylon, from Basler. The wrapping allows the low-level camera driver methods to be called from within Python, and their feeds are forwarded to a gstreamer stream also initiated from within Python. The problem is that his wrapping (and the underlying Pylon software itself) is only runnable on an older version of Ubuntu. Efforts to run his software on newer distributions at the 40m have failed.

I'm working on a fix to essentially rewrite his high-level SnapPy code (generators of GUIs, etc.) to use the newest version of Pylon (pylon5) to interface at a low level with the cameras. I discovered that since the last attempt to digitize the camera system, Basler has released their own official version of a Python wrapping for Pylon on github (PyPylon).

Progress so far:

• I've installed from source the newest version of Pylon, pylon5.0.12 on the SL7 machine (rossa). I chose that machine because LIGO is migrating to Scientific Linux, but I think this will also work for any distribution.
• I've installed from source the the newest, official Python wrapping of the Basler Pylon software, pypylon.
• I've tested the pypylon package and confirmed it can run our cameras.

The next and final step is to modify Joe's SnapPy package to import pypylon instead of his custom wrapping of an older version of the camera software, and update all of the Pylon calls to use the new methods. I'll hopefully get back to this early next week.

[Jenne, TaraV]

We had a look this morning at the status of the seismometer array, so that we can get it all put together. While we were looking at the Guralp at the Yend, we noticed that it was pointing the wrong way.  The North-South nubbins were pointed East-West, so X and Y coming out of the seismometer were backward.

To fix the Yend's Guralp, we powered off the Guralp readout box, rotated the seismometer, re-leveled it, and then turned the power back on.  Now X from the seismometer lines up with the X data channel, and similarly for Y.

The Yend Guralp has all of the cabling needed, and is installed on the granite slab.  This seismometer doesn't need any more work for now.  When we get around to it, we'll need to do some kind of thermal insulation, but other than that, it's good to go.

The Xend will also have a Guralp (Zach still has it in the Gyro lab for now).  We have the long cable that should go from the readout box to the slab that we'll need to put into the cable tray.  The short cable from the slab's plate to the seismometer is already in place.  For this seismometer, we should just need to plop the instrument in place and lay the cable in the overhead cable trays.  We should also remove the now obsolete STS-2 cable while we're doing that.  So, the Xend seismometer station doesn't need too much work.

The corner station will need more work.  Zach made for us the long cable, although he still has it in the Gyro lab, so when we get the seismometer and cable back, we'll need to lay that cable in the overhead trays.  The short cable from the slab's plate to the seismometer does not exist yet.  We want to make sure that we can feed the finished cable and connector through the hole in the slab, and then we'll solder it up out here on the EE bench.  I think this is how Den was doing things.  If not, we'll have to do the soldering in-situ, which we don't want.  So, for the corner station, we need to make the short cable, lay the long cable, get the T-240 back from Zach and put it on the slab, re-install the readout box that Zach has, etc, etc.  We should also make sure that the spaghetti pot fits on the slab, underneath the piece of metal that's sticking out over the slab.  We think that it's the same amount of clearance that the Yend pot has, so it should be okay, but we'll check.  The O-ring seems to be sitting on the MC2 chamber, so we should remember that. 

Neither the Xend nor the corner station had the yellow dog clamps, so we'll have to figure out where Den / Steve have hidden them. 

 EDIT:  We have checked, and the Guralp connector, which is larger than the Trillium connector, fits through the hole in the slab (with some disassembly), so we can solder together the short cable out here on the EE bench, and install it separately.  Eeeeexxxxxcelllent.

A few machines have still not been changed over, including a few laptops, mafalda, ottavia, and c0rga.

All the front ends have been changed over.

fb40m died during a reboot and was replaced with a spare Sun blade 1000 that Larry had.  We had to swap in our old hard drive and memory.

All the front ends, belladonna, aldabella, and the control room machines have been switched over. Nodus was changed over after we realized we hosed the elog and svn by switching linux1's IP.

At this point, 90% of the machines seem to be working, although c0daqawg seems to be having some issues with its startup.cmd code.

After Joe left:

1. Turned on op440m and returned him his keyboard and mouse.
2. Damped MC2.
3. Opened PSL shutter - locked PMC, FSS,
4. Started StripTool displays on op540m.
5. op340m doesn't respond to ping from anyone.
6. started FSS  SLOW and RCPID scripts on op540 - need to kill and restart on op430m.
7. ASS wouldn't come up - it doesn't know who linux1 is.
8. MC autolocker wouldn't run on op540m because of a perl module issue, started it on op440m - it needs to be killed and restarted on op430m.
9. probably mafalda, linux2, and op430m need some attention - they are all in the same rack.

As of 7:18 PM, the MC is locked and the PSL seems normal + all suspensions are damped and the ELOG is back up as well as the SVN.

5) op340m has had its hosts table and other network files updated.  I also removed its outdated hosts.deny file which was causing some issues with ssh.

6) On op340m I started FSSSlowServo, with "nohup ./FSSSlowServo", after killing it on op540m.

I also kill RCthermalPID.pl, and started with "nohup ./RCthermalPID.pl" on op540m.

7) c1ass is fixed now.  There was a typo in the resolv.conf file (namerserver -> nameserver) which has been fixed.  It is now using the DNS server running on linux1 for all its host name needs.

8) I killed the autlockMCmain40m process running on op440m, modified the script to run on op340m, logged into op340m, went to /cvs/cds/caltech/scripts/MC and ran nohup ./autolockMCmain40m

9) Linux2 does not look like it has not been connected for awhile and its wasn't connected when we started the IP change over yesterday.  Is it supposed to still be in use?  If so, I can hook it up fairly easily.  op340m, as noted earlier, has been switched over.  Mafalda has been switched over.

10) c0rga has now been switched over. 

11) aldabella, the vacuum laptop has had its starting environment variables tweaked (in the /home/controls/.cshrc file) so that it looks on the 192.168.113 network instead of the 131.215.113.  This should mean Steve will not have any more trouble starting up his vacuum control screen.

12) Ottavia has been switched over.

13) At this time, only the GPIB devices and a few laptops remain to get switched over.

The trend data hasn't been synced with LDAS since Jul 27 5AM local.

40m:

controls@nodus|minute > pwd
/frames/trend/minute
controls@nodus|minute > ls -l 11222 | tail
total 590432
-rw-r--r-- 1 controls controls 35758781 Jul 29 11:59 C-M-1122228000-3600.gwf
-rw-r--r-- 1 controls controls 35501472 Jul 29 12:59 C-M-1122231600-3600.gwf
-rw-r--r-- 1 controls controls 35296271 Jul 29 13:59 C-M-1122235200-3600.gwf
-rw-r--r-- 1 controls controls 35459901 Jul 29 14:59 C-M-1122238800-3600.gwf
-rw-r--r-- 1 controls controls 35550346 Jul 29 15:59 C-M-1122242400-3600.gwf
-rw-r--r-- 1 controls controls 35699944 Jul 29 16:59 C-M-1122246000-3600.gwf
-rw-r--r-- 1 controls controls 35549480 Jul 29 17:59 C-M-1122249600-3600.gwf
-rw-r--r-- 1 controls controls 35481070 Jul 29 18:59 C-M-1122253200-3600.gwf
-rw-r--r-- 1 controls controls 35518238 Jul 29 19:59 C-M-1122256800-3600.gwf
-rw-r--r-- 1 controls controls 35514930 Jul 29 20:59 C-M-1122260400-3600.gwf
 

LDAS Minute trend:

[koji.arai@ldas-pcdev3 C-M-11]$ pwd
/archive/frames/trend/minute-trend/40m/C-M-11
[koji.arai@ldas-pcdev3 C-M-11]$ ls -l | tail
-rw-r--r-- 1 1001 1001 35488497 Jul 26 19:59 C-M-1121997600-3600.gwf
-rw-r--r-- 1 1001 1001 35477333 Jul 26 21:00 C-M-1122001200-3600.gwf
-rw-r--r-- 1 1001 1001 35498259 Jul 26 21:59 C-M-1122004800-3600.gwf
-rw-r--r-- 1 1001 1001 35509729 Jul 26 22:59 C-M-1122008400-3600.gwf
-rw-r--r-- 1 1001 1001 35472432 Jul 26 23:59 C-M-1122012000-3600.gwf
-rw-r--r-- 1 1001 1001 35472230 Jul 27 00:59 C-M-1122015600-3600.gwf
-rw-r--r-- 1 1001 1001 35468199 Jul 27 01:59 C-M-1122019200-3600.gwf
-rw-r--r-- 1 1001 1001 35461729 Jul 27 02:59 C-M-1122022800-3600.gwf
-rw-r--r-- 1 1001 1001 35486755 Jul 27 03:59 C-M-1122026400-3600.gwf
-rw-r--r-- 1 1001 1001 35467084 Jul 27 04:59 C-M-1122030000-3600.gwf
 

Today it was synced at 5AM but that was all.

40m:

controls@nodus|minute > pwd
/frames/trend/minute
controls@nodus|minute > ls -l 11222|tail
-rw-r--r-- 1 controls controls 35521183 Jul 29 21:59 C-M-1122264000-3600.gwf
-rw-r--r-- 1 controls controls 35509281 Jul 29 22:59 C-M-1122267600-3600.gwf
-rw-r--r-- 1 controls controls 35511705 Jul 29 23:59 C-M-1122271200-3600.gwf
-rw-r--r-- 1 controls controls 35809690 Jul 30 00:59 C-M-1122274800-3600.gwf
-rw-r--r-- 1 controls controls 35752082 Jul 30 01:59 C-M-1122278400-3600.gwf
-rw-r--r-- 1 controls controls 35927246 Jul 30 02:59 C-M-1122282000-3600.gwf
-rw-r--r-- 1 controls controls 35775843 Jul 30 03:59 C-M-1122285600-3600.gwf
-rw-r--r-- 1 controls controls 35648583 Jul 30 04:59 C-M-1122289200-3600.gwf
-rw-r--r-- 1 controls controls 35643898 Jul 30 05:59 C-M-1122292800-3600.gwf
-rw-r--r-- 1 controls controls 35704049 Jul 30 06:59 C-M-1122296400-3600.gwf
controls@nodus|minute > ls -l 11223|tail
total 139616
-rw-r--r-- 1 controls controls 35696854 Jul 30 08:02 C-M-1122300000-3600.gwf
-rw-r--r-- 1 controls controls 35675136 Jul 30 08:59 C-M-1122303600-3600.gwf
-rw-r--r-- 1 controls controls 35701754 Jul 30 09:59 C-M-1122307200-3600.gwf
-rw-r--r-- 1 controls controls 35718038 Jul 30 10:59 C-M-1122310800-3600.gwf

LDAS Minute trend:

[koji.arai@ldas-pcdev3 C-M-11]$ pwd
/archive/frames/trend/minute-trend/40m/C-M-11
[koji.arai@ldas-pcdev3 C-M-11]$ ls -l |tail
-rw-r--r-- 1 1001 1001 35518238 Jul 29 19:59 C-M-1122256800-3600.gwf
-rw-r--r-- 1 1001 1001 35514930 Jul 29 20:59 C-M-1122260400-3600.gwf
-rw-r--r-- 1 1001 1001 35521183 Jul 29 21:59 C-M-1122264000-3600.gwf
-rw-r--r-- 1 1001 1001 35509281 Jul 29 22:59 C-M-1122267600-3600.gwf
-rw-r--r-- 1 1001 1001 35511705 Jul 29 23:59 C-M-1122271200-3600.gwf
-rw-r--r-- 1 1001 1001 35809690 Jul 30 00:59 C-M-1122274800-3600.gwf
-rw-r--r-- 1 1001 1001 35752082 Jul 30 01:59 C-M-1122278400-3600.gwf
-rw-r--r-- 1 1001 1001 35927246 Jul 30 02:59 C-M-1122282000-3600.gwf
-rw-r--r-- 1 1001 1001 35775843 Jul 30 03:59 C-M-1122285600-3600.gwf
-rw-r--r-- 1 1001 1001 35648583 Jul 30 04:59 C-M-1122289200-3600.gwf

Yesterday, I uploaded some EAGLE schematic files and a LISO source file for the green PDH servo electronics to the 40m LISO git repository. In doing so, I realized that the DCC document for the X box (D1400293) was not updated at the end of the electronics work we did in Aug/Sep 2014. This is entirely my fault. 

The Y box document (D1400294) is currently accurate. 

The missing information is that, as I posted In ELOG 10457, I ended up destroying our original X box, and replaced it with a spare from the ATF. It was restuffed to match the Y end box pretty much exactly. We will update the X circuit DCC page with an accurate schematic and photo. 

Gautam tells me that he and Rana were looking at the outdated schematic and thinking about improvements, but at least some of this was already done back in 2014 (specifically, the resistors used to specify the AD8336 preamp gain were changed).

I've uploaded reasonably high-resolution photographs of the uPDH box for the X-end and Y-end on their respective wiki pages. I've uploaded two photos for each box, one of the circuit board (I checked that these photos are clear enough that we can zoom in and read off component values if necessary), and one of the box with the peripherals not integrated into the circuit board (i.e. the minicircuits mixer ZAD-8+ and the little Pomona box that is an LP filter for the output from the mixer). Since I pulled the boxes out, I thought it might not be a bad idea to measure the TFs of these Pomona boxes and make sure nothing weird is going on, I'll put up some plots later. 

Rana and I discussed some things to look at earlier today:

• Check the voltages at test-points 1,7 and 9, and make sure they are as expected
• Change the gain of the pre-amp from x2 to x4 - as Eric mentioned in the previous elog, these had already been swapped out. Right now a 600 ohm and 200 ohm resistor pair are being used, so the preamp gain is x4, which should be okay as per the datasheet of the AD8336 VGA amplifier (although the "recommended" resistor pairing is 301 ohm and 100 ohm, but I don't think this is critical?
• Track down the reason for the difference in Gain settings at the X and Y ends - typically, the X-end PDH box "Gain" knob is set to 10, while that for the Y-end is set to ~4. The fact that the PZT actuator gain for the Y-end is ~5 times larger than for the X-end doesn't seem to account for all of this. As per the attached plot, the difference in gain between the ends is ~35 dB, which is a factor of 50!

I also did a quick check of the behaviour of the Servo Gain potentiometer by checking the resistance at various positions of the knob - we had suspected that the potentiometer may be logarithmic, but I found that it was in fact linear. I'll put up a plot of the gain as a function of the Servo Gain knob position soon,(plot added) along with results from the other checks.

While disassembling the setup at the X-end to get the PDH box out, I noticed that the signal from the LO is going to the mixer through a Pomona box (no such Pomona box is used at the Y-end). I opened it up and found that it contains just a pair of capacitors in parallel, so it's a phase shifter?. The LO signal also goes through an attenuator. The mixer in both boxes is a ZAD-8+, so why is this part of the setup different?

Both PDH boxes are not hooked up at the moment, I will restore the setups at both ends after running a few more checks on the boxes...

The new nodus machine is being brought to life; until installation is finished and everything is fine, the old nodus will be unharmed. For future reference:

New Nodus hardware:

Case: SuperMicro SC825MTQ-R700U

M/B: SuperMicro X8DTU-F

CPU: 2x Intel Xeon X5650

RAM: 3x Kingston KVR1333D3S8R9S (2GB)

         3x Samsung M393B5673EH1-CH9 (2GB)

           Total 12 GB

HDD: Seagate ST3400832AS (400GB)

Current software situation and current issues :

1) Ubuntu Server 12.04.5 is installed and updated

2) The usual 'controls' user is present, with UID=1001 and GID=1001

3) Packages installed: nfs-common, rpcbind, ntp, dokuwiki, apache2, php5, openssh-server, elog-2.8.0-2 [from source], make, gcc, libssl-dev [dependencies for elog], subversion

4) Network: interface eth0 is set up (static IP and configuration in /etc/network/interfaces); eth1 is recognized and added, but not configured yet

5) DNS: configuration is in /etc/resolvconf/resolv.conf.d/base (since /etc/resolv.conf is overwritten by the resolvconf program using the 'base' database)

6) ntp is installed and (presumably) configured, but ntpd misbehaves (namely, all the servers are found, but a 

tail /var/log/syslog

shows that no actual synchronization is performed, and the daemon keeps

Listening on routing socket on fd #22 for interface updates

7) dokuwiki apache2 php subversion elog are installed but not configured yet (I need info about their current state, configuration and whereabouts)

8) I copied and merged the old nodus' .bashrc and .cshrc into new nodus' .bashrc, need to know if something has to be added

9) backup frames, backup user dirs and 40m public_html are not set yet, as in #7

Is there something missing?

If there is something missing from here (ligo/cds software, smartmontools/hddtemp and similar, or anything else) tell me and I'll set them up.

[Diego, Steve]

We ran a Cat 6+ Ethernet cable from the 1X7 rack (where the new nodus is located) to the fast GC switch in the control room rack; now I will learn how to setup the 'outside world' network, iptables, and the like.

I remind that the current hardware/software status is posted in elog 10697 ; if additions or corrections are needed, let me know.

After I check a couple of things, we can use the new nodus (which is currently known in the martian network as rosalba) as a local test to see that everything is working. After that (and, mostly, after I'll have the network working), we will sync the data from the old nodus to the new one and make the switch.

[Diego, EricQ]

Update: work is almost completed; the old nodus is still online, as I don't feel confident to make the switch and leave it on its own for the weekend. However, the new nodus is online with the IP address 131.215.114.87, so everyone can check that everything works. From my tests I can say that:

• ntp is working
• wikis are working:
  
  • AGWD wiki : http://131.215.114.87:30889/wiki/doku.php
  • AIC wiki     : http://131.215.114.87:30889/wiki/doku.php?id=aic_wiki
  • ATF wiki    : http://131.215.114.87:30889/ATFWiki/doku.php
  • Cryo wiki   :  http://131.215.114.87:30889/CryoWiki/doku.php
• public_html is working : http://131.215.114.87:30888/public_html/
• svn is working
• svn/apache ugly web interface is working : http://131.215.114.87:30889/svn/
• new fancy websvn web interface is working : http://131.215.114.87:30889/websvn/
• backup is not working: it will as soon the new nodus will replace the old one, so that I'm sure everything is writing stuff in the same place;
  
• SSL is not working (yet);

After everything will be in place, I will save every reasonably important configuration file of nodus into the svn.

I remind that every change made while accessing the 131.215.114.87 machine will be purged during the sync&switch

 Nodus (solaris) is dead, long live Nodus (ubuntu).

Diego and I are smoothing out the Kinks as they appear, but the ELOG is running smoothly on our new machine. 

SVN is working, but your checkouts may complain because they expect https, and we haven't turned SSL on yet...

 [Diego, EricQ]

SSL, https and backups are now working too!

A backup of nodus's configuration (with some explaining) will be done soon.

 Nodus should be visible again from outside the Caltech Network; I added some basic configuration for postfix and smartmontools; configuration files and instructions for everything are in the svn in the nodus_config folder

Turns out the elog version 2.8.0 uses a different encryption method than 2.7.5.  This mean the encrypted passwords stored in the elogd.cfg don't work with the new code.  elogd includes functionality to generate encrypted passwords, but unfortunately I don't know the administration passwords for some of the logbooks.  So I'm going to leave 2.7.5 running until I can get those added properly to the 2.8.0 cfg file.

After the MZ-removal work:

- I found that the input steering (IM1) was right handed. This was different from the CAD layout. This was the main reason why the MC trans was kicked by the mount.
- Removed the mount from the post and converted it to a keft handed.
- Align IM1 so that we can get TEM00 lock. Align IM1 further.

- After the IM1 was optimized for the TEM00, move the periscope mirrors to have best alignment.

- Checked the beam spot positions. They looks quite good (MC2 is not the matter now).

C1:SUS-MC1_ULPIT_GAIN = 0.998053
C1:SUS-MC1_ULYAW_GAIN = 0.992942
C1:SUS-MC2_ULPIT_GAIN = 1.00856
C1:SUS-MC2_ULYAW_GAIN = 1.04443
C1:SUS-MC3_ULPIT_GAIN = 0.99868
C1:SUS-MC3_ULYAW_GAIN = 1.00041

From the work that Anchal has completed for diagnolizing the YAW ouput matrix, a step response was taken of this new matrix using our previous methodolgies and the following results:

The step response can be seen plotted in attachment 1. The off diagonal terms of this new matrix sum to 1.24, which is a large decrease from the current matrix and the matrices that were tested from our previous step responses. 

Tomohiro and I are now currently working futher to configure the UGF's for YAW given this new output matrix.

UPDATE:

Tomohiro and I have completed testing the YAW Sensor outputs with broadband noise injection and have confirmed that gains currently set on each filter module (which is 1.0 for WFS1, WFS2, and MC Trans) provides us with adequate UGF's. As seen bellow in attachment 2-3, WFS1 and WFS2 have UGF's between 2 and 3 Hz. MC Trans can be seen in attachment 4 and has been confirmed to have a UGF around 0.1 Hz.

Finally, attachment 5 displays the off diagnolized sums and uncertainties for each of our previous step response results and the newest result (labeled "new") for Anchal's OUTPUT YAW matrix. The first graph in blue displays the overall sum and uncertainty related to each step response taken. Then in the following 3 plots, the sum's and uncertaintes for each sensor are displayed individually for each step response test.

For reference:

New: corresponds to Anchal's YAW OUPUT MATRIX

D0: refers to the previously implemented matrix, prior to any testint or updates

D1: refers to the matrix that was computed based off of the first test Tomohiro and I performed

D2: refers to the matrix computed as a secondary result from D1. This matrix was thought to provide a lower off diagonal sum, but did not.

This thoroughly displays our results such that the newly computed matrix from Anchal is much more diagnolized then that of the step response matrices Tomohiro and I have computed.

Tomohiro, Anchal and I completed the following processs for acquiring a new Output Yaw matrix for the "C1IOO_WFS_OUTMATRIX".

To did this by following the same process in 17493 but instead of adding our offsets in the WFS1, WFS2 and MC Trans filter banks, offsets were added at the end of the feedback loop at the optics, MC1, MC2 and MC3 YAW.

Optimal offset values were found such that the offset change did not disrupt the output WFS transmission signal by more than about a one thousand counts. Each limit was set to come close to this limit.

Our final offset values were:

The step response was than observed in Diaggui, but the entire 800 s run was unable to be viewed at once. We then utilized our python script from the previous step response data that we took to develop the following:

The measured response from stepping the optics was:

*The values in this matrix represent the number of counts/offset count. Thus all ovalues found from the step response were divided by the number of counts on each offset.

To find the new yaw matrix, we then take the inverse of the step response output matrix to get:

The results from the step response may also be seen graphically in attachment 1. The first plot shows all 3 response signals. Then each following plot shows the individual signals and the step responses overlayed for each one.

The plots also include horizontal lines that represent the average for the stepped signals and the average of the signal at rest along with shading for their associated uncertainties.

This was then tested in C1IOO_WFS_BASIS Yaw matrix, and at first did not work well. The WFS1 Yaw output would rail toward the limits. To fix this, the sign of the gain was flipped (from 0.5 to -0.5) which seemed to solve this issue.

This was then transmitted to the matrix to give:

This did not solve all issues, the overall ouput signals from the WFS filters still seemed to have large fluctuations. I then began adjusting the gains of the WFS1, WFS2 and MC Trans yaw output filters and achieved much steadier signals.

The following table describes the current best gain valuse for our Yaw matrix:

The results from our found matrix and gain changes can be seen on the left of attachement 2 that displays the ouputs on the Error Signal Monitor. The original output yaw matrix signals can be seen on the right hand side. There is work to still be done on adressing these issues, but overall this may be improved by some additional changes in the gains on each channel.

Summary

• We compared the new output matrix with old one by the step response test.
• We focused on the off-diagonal components of the step response result to compare the output matrix.
• We found that the old one is relatively good to WFS1/2 and MC2_TRANS whereas the new one is useful only to WFS1.
• Also we found that the new output matrix made from the sensing matrix was not significantly better than the original one.

Purpose

Alex, Anchal, and I did the experiment to find out the better output matrix. We got the new output matrix from the step response test in 40m/17500, so we checked whether the output matrix is good or not.

Theory

We used the following method to check the output matrix. In the previous step response test, we applied the step offset to ``ExciteIn'' points, and measure the step response at ``SensOut'' points. These points are defined in Attatchment 4. From the test, we got the matrix . Thus, we derived the new output matrix  from taking the inverse of , . If the new output matrix is well derived, the matrix can diagonalize the product of  and , , where  is the identity matrix.  can be measured by the step response test from ``SensIn'' to ``SensOut.'' Therefore we checked the output matrix by measuring . We call the measured matrix  as a sensing matrix.

To evaluate that  is diagonalized, we computed the sum of the absolute values of the off-diagonal components in 

Note that each column of the matrix was normalized by its diagonal component.

We tried to find out the better output matrix as the following method. We created new output matrix  from , and did the same step response test with . Then we got the new sensing matrix . We computed the sum of the absolute values of the off-diagonal components in , . We can get the relation  if  is better than . Therefore we compared  with .

Note: If  and  have the relation , the output matrix  will get better and better.

We also did the step response test with , which is defined as the output matrix now used. Then we compare  with .

Method

Before doing each step response test, we did the following processes:

• MC WFS relief for 60 secs with closed loops,
• turn off the WFS servo,
• turn off all the filters (WFS1/2: FM3, 4, 6; MC2-TRANS: FM1, 3, 4, 6),
• change the output matrix,
• set all the gain as unity,
• adjust each step offset.

We used the python script, toggleWFSoffsets.py, for testing the step response. The script is stored in /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/. The time appling each step offset is set as 120 secs.  are specifically the following matrix:

Note:  is different from [-0.188, -0.009, ...] in 40m/17500 because the previous calculation had a mistake.

The step response data is analyzed for making plot and calculating  and  by the python script, /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/IOO_WFS_YAW_RESPONSE_TEST_100323.ipynb. 

Result

The step response results for  are represented in Attachment 1, 2, 3, respectively. In each plot, upper left shows all the data for WFS1 (solid green), WFS2 (solid blue), and MC2_TRANS (solid brown). Also upper right, lower left, and lower right shows the result of WFS1, WFS2, and MC2_TRANS, respectively. The plots except for the upper left have the applied step offset drawed by dashed line. The three step offsets were applied in the order of WFS1 (dashed green in the upper right), WFS2 (dashed blue in the lower left), and MC2_TRANS (dashed brown in the lower right). The high-frequency components of all the plots are removed with a second-order Butterworth low-pass filter and then plotted. Dotted line and its surrounding area show the mean value for each step response or existing offset without the step offset, and its standard deviation, respectively.

We summarize each plot:

The matrix of  is written from Attachment 1:

Focusing on each column in  and the plot, only the step response for WFS1 is well diagonalized. The result of  is . Note that all the sign of the step offset in Attachment 1 is negative because we set each gain of the filter as -1.

The matrix of  is written from Attachment 2:

The output matrix  has worse normalization to WFS1 than  from comparing  with .  also gets worse value than : .

The matrix of  is written from Attachment 3:

Although  has relatively better normalization to WFS1 and 2 than , it is characterized by a large overall error.  has minimum value with relatively large uncertainty: .

Discussion

We compare each value , which is plotted in the left of Attachment 5. From the figure, we can find  and  agree within the margin of error, and  is significantly smaller than  and . Also we compare  focusing on WFS1 column shown in the right of Attachment 5.  have almost the same value, and  has slightly larger value than other. This result shows  is relatively good to WFS1/2 and MC2_TRANS whereas  is useful only to WFS1.

Summary

• We do the step responce test on WFS 1, 2 and MC2_TRANS YAW for correcting the output matrix.
• We add each offset value to each YAW actuator in IMC, and measure the time-series of the signals.
• From the input offset value and the output values, we get the values in the output matrix.

Purpose

The purpose of the measurement is to correct the values in the output matrix between YAW actuator and YAW signals of WFS and MC2_TRANS.

Method

Alex, Anchal, and I did the following measurement. The method follows to the previous measurement held by Anchal in 40m/17311. Before we did the experiment, we took these actions.

• We reliefed MC SUS ASC Input values to zero
• We made the overall WFS gain to zero in C1IOO_WFS_MASTER window.
• We turned off (0; 0.8) FM3 filter of servo section in WFS1, 2_YAW and MC2_TRANS_YAW.
• We checked the ramp time is set as 2 s.

We set every offset value by monitoring the change in WFS and MC2 YAW signals due to the offset. The monitoring points are WFS1_IY_DQ, WFS2_IY_DQ, and MC_TRANS_Y_DQ. We got the offset values as listed. We also monitored TRANS_SUMFILT_OUTPUT because we check the transmitted light changes.

We used the python script toggleWFSoffsets.py to add the offset separately. The script is in /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/. The averaging time is set as 120 s to reduce the influence of the dominant fluctuation by factor of 1/100. The dominant fluctuation has the frequency around 1 Hz.

For obtaining the time-series datas and caluclating the mean values of the changed WFS and MC2 YAW signals due to every offset, we created new python script named IOO_WFS_YAW_STEP_RESPONSE_TEST.py, which is saved in /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/. The script uses the getdata function in cdsutils to get time-series data referring to GPS time.

We picked out a portion of the datas for step responce results. The selected time is [20 s, 120 s], [260 s, 360 s], and [500 s, 600 s]. Each time datas are averaged. The datas also have background offset, so the datas of time [140 s, 240 s], [380 s, 480 s], and [620 s, 720 s] are used to calculate the average of the background offset. The step responce results are obtained by the differential between the averaged datas in the picked out time and that of the background offset. And the results are normalized by the offset values.

The results make the matrix from injection points to measured points. The injection points are WFS1, 2_YAW and MC2_TRANS_YAW, thus the matrix is not the output matrix from the injection points to MC1, 2, 3_YAW. We get new output matrix by multiplying the inversed result matrix and the current output matrix.

Result

The Attachment 1 plots the time-series datas. For visibility and less file size, the figure is drawn with a reduced number of samples filtered by 2nd order Butterworth filter. We referenced to /measurements/AWS/YARM_WFS_DC_Sensitng_Matrix_New.ipynb to draw the figure. 

The new output matrix is written here.

• Current matrix

• New matrix

We temporarily replaced the new matrix from the current one. The loop was still stable and the matrix worked well. To know whether the matrix properly works or not, we will test the same step response to the new matrix. We will confirm that the measured matrix is diagonalized.

this measured Yaw matrix seems very different from the previous one. How can they really both be stable?

The following steps summarize the steps to setting up and interacting with a GigE camera.

Launching the PylonViewerApp:

1. Open a new terminal using Ctrl + Alt + T on the keyboard.
2. Launch the app using the command pylon.

Using setup python scripts to interact with the GigE (a summary of the steps listed here and here)

1. Connect the GigE camera to the ethernet cable and record its IP address. If the IP address is not printed on the GigE, launch the PylonViewerApp and navigate to the "Tools" dropdown menu and select "pylon IP configurator" to be presented with a list of all connected cameras and their IP addresses.
2. To simply observe the camera feed, open a new terminal and run the following commands:
   1. cd /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon
   2. python camera_server.py -c C1-CAM-ETMX.ini  (only one config file is present currently and more will be added as more cameras are set up. The "Camera IP" in the  .ini file must match that determined in step 1). This starts the camera server.
3. Open a new tab (Ctrl + Shift + T on the keyboard) in the terminal. You should still be in the same directory as navigated to in step 2.1. Run the following command.
   1. python camera_client.py -c C1-CAM-ETMX.ini
4. This should bring up a feed from the camera. Close at will.
5. To record a video file, repeat steps 1 and 2. Open a new tab as described in step 3. Then run the following command:
   1. python camera_client_movie.py -c C1-CAM-ETMX.ini
6. Enter the full path to the file where you wish to save the movie in the prompt that appears. Use ./your_file_name_here.avi to save the the video in the working directory. Press Ctrl + C to stop recording. The recording can be played by navigating to the location where the recording is stored and running vlc your_file_name_here.avi.
7. To adjust the exposure setting of the camera, open a new terminal and run the command sitemap . This should bring up the medm display in Attachment #1. Click on the Video/Lights button highlighted in red and select GigE. Adjust the exposure value in the next window using the slider before starting the server in step 1. Adjusting the slider once the server is started causes the program to freeze. Also set the Snapshot channel C1:CAM-ETMX_SNAP to off as mentioned in elog 14037.

Upcoming updates:

1. Automatic script to run the above steps.
2. Pre-determining the time duration of the recorded video.
3. Obtaining snapshots.

Figured out how to get/grab frames by looking at the pypylon documenation as that turned out to be easier than modifying Jon's code. Still not sure about how to modify the exposure time (other than using the pylon app, the only technique I know so far is to adjust the exposure manually on the medm screen and then run the scripts as described in the previous elog). I will figure that out tomorrow and make a script suitable for Kruthi's usage (obtain a bunch of images with different exposure times). I will also try and integrate the video saving and streaming code into this and have a neat little script set up asap.

caget/caput probably does the job.

Thanks! It does indeed do the trick! With that I was able to

1. Obtain current exposure value using the terminal command caget C1:CAM-ETMX_EXP
2. Set exposure value using the terminal command caput C1:CAM-ETMX_EXP <desired_exposure_value>

Further, a quick look at the camera server code in /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/camera_server.py revealed that the script expects the details of "Number of Snapshots" in "Camera Settings" in the configuration file i.e in C1-CAM-ETMX.ini at ( /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/C1-CAM-ETMX.ini) which wasn't present before. Adding this parameter to the config file allows one to take a snapshot using the medm screen. Infact, unlike as described in this elog, I was able to start the server and client as described in elog 14649, and then obtain snapshots using the terminal command  caput C1:CAM-ETMX_SNAP 1.

[Koji, Milind]

Today I ran into the following errors:

1. Inability to access the EPICS channels using the commands caget and caput and thus the generation of a blank medm screen (error in Attachment #1) when simultaneously running the code in camera_server.py (/opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/camera_server.py).
2. Inability to run camera_server.py code with an active medm screen with a "... failed to read <EPICS channel>" error.

Therefore, Koji and I took a look at it and putting our faith in Gautam's hunch from elog 13023, we walked down to rack 1Y1 and keyed it. Following this, all the functionality previously described was restored! Koji then took a look at all the channels handled by this machine and bestowed upon me the permission to key the crate should I lose control of the GigE again.

Steps to take snapshots using GigE at different exposures [Instructions for Kruthi]:

1. Setup C1-CAM-ETMX.ini (/opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/C1-CAM-ETMX.ini) appropriately. The parameter Number of Snapshots determines how many snapshots will be taken at any given exposure. Set Name Overlay, Time Overlay, Calculation Overlay, Calculations (if using very low values of exposure) and Auto Exposure to False. Ensure that that the IP address of the Camera in use and that in the configuration file match.
2. Launch a server using the following commands (as described in elog 14649)
   1. cd /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon
   2. python camera_server.py -c C1-CAM-ETMX.ini
3. Open another terminal in the same directory and then run the following command
   1. python exposure_variation.py --minval <minval> --maxval <maxval> --step <step> where
      1. minval: lower bound of range of exposure values, defaults to 150
      2. maxval: upper bound of range of exposure values, defaults to 100000
      3. step: step size of variation in the range [minval, maxval], defaults to 2000

The python script takes in the above parameters and then takes snapshots by setting the exposure to values starting at minval and going upto maxval incrementing by step at each turn. This uses a simple for loop and is nothing elaborate.

A few unrelated updates:

1. On a sidenote, I installed Sublime Text editor on rossa following the instructions at this site (check install using yum section). Further, I have also installed miniconda but did not set it up fully as I was in a rush and did not want to disturb any previously set up environment variables.
2. I have cloned Gabriele's repository and am trying to get it to work on my system. As Gautam has pointed out that the end goal is to get stuff working on the lab machines, I will sharea .yml file with the necessary environment details upon completion.
3. I will upload details of how I am going to construct the two learning tasks that Rana, Gautam and I discussed in a day or two including details of the use of simulation data for training data in the absence of real data (until Kruthi is done setting up the GigE) which Gautam suggested I do to speed things up.

As directed by Gautam, I have set up one script- interact.py (at /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/interact.py) to perform the following two tasks:

1. View the GigE feed for a fixed period of time.
2. Record the GigE feed for a fixed amount of time.

Steps to view GigE feed for a fixed amount of time:

1. Run the following commands in the terminal to navigate to the concerned directory and then view the feed
   1. cd /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon
   2. python interact.py --path_to_config <path_config> --mode 0 --view_time <viewing_time>, where
      1. path_config: full path to configuration file, defaults to /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/C1-CAM-ETMX.ini if --path_to_config is not used
      2. viewing_time: time in seconds for which the feed is to be displayed. The server is closed  after this time and the window freezes and can be manually closed.
   3. Exiting the feed in between: The script terminates automatically after the specified time. To terminate the feed in between, close the window manually using the x icon the top right. This makes sure that the server is correctly closed. If closed using the Ctrl-C command in the terminal, the server is left running and any attempt to unwittingly set up another results in an error (see Attachment #1). In this case, the server and client processes needs to be identified manually and killed. I have used the following steps
      1. ps -eaf | grep server, then identify the PID for the python camera_server.py process
      2. kill PID
      3. similarly for the client file

Steps to record the GigE feed for a fixed amount of time:

I tried to look for elegant solutions that wouldn't require editing the code that Jon wrote and stumbled upon this useful bit of information but ended up deciding that it was just easier to change the camera_client_movie.py (/opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/camera_client_movie.py). It can still be run as previously described, where video recording is terminated by using Ctrl-C. Steps to record for a fixed period of time are

1. cd /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon
2. python interact.py --path_to_config <path_config> --mode 1 --save_time <recording_time> --file_name filename, where\
   1. path_config: full path to configuration file, defaults to /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/C1-CAM-ETMX.ini if --path_to_config is not used
   2. recording_time: time in seconds for which the feed is to be saved. No video is displayed during this time.
   3. filename: full path to the file where the video is to be saved. Overwrites any existing files.

I'll make aliases for these to make the whole process more user friendly. I'm halting this for now and will discuss what else needs to be done once Gautam gets back.

Regarding the autolocker: I spoke to Aaron today and as he is in tomorrow, I'll ask him about the burt files and the ideal configuration.

I'm also starting with GANs now.

Today, Rana had me key the PSL crate.

1. Locating the rack: the crate is 1X1. This link provides details of the locations and functions of the racks.
2. Keying the crate: the key is located at the bottom of the rack (in this case). Keying it requires one to turn the key through 90 degrees (anti clockwise facing the rack) and back to to the original position.

Locking the PMC:

1. Accessing the medm screen for the PMC: open a new terminal and use the command sitemap. This should open up the sitemap medm screen. Click on the PSL button and then select C1PSL_PMC from the dropdown that is produced. This opens up a medm screen similar to that in Attachment #1.
2. The correct toggling: The keying of the crate sometimes scrambles the settings on the medm screen. Rana and I performed extensive toggling of the buttons and concluded that the combination in Attachment #1 ought to be the correct one.
3. Locking the PMC: The state of the PMC was deduced by observing CH01 on monitor 7. When not locked, there is no observable bright spot. At this point the "Input Offset (V)" slider is set to zero and the "Servo Gain Adjust (dB)" slider is set to minimum. To obtain lock, complete step 2 and then move the "DC Output Adjust (V)"  slider (at the bottom left on the screen) around rapidly while looking for a bright spot. On observing such a spot on the monitor, release the slider and quickly increase the "Servo Gain Adjust (dB)" slider to around 15 dB. Higher gain values produce a bright spot on CH02 as well which vanishes (almost) on decreasing the gain to the aforementioned value.

[Jenne, EricQ, Manasa]

We are still not able to get the beam to go to the interferometer, which is super frustrating. 

We tried using cameras and viewers to look into several ports, however all we can see is the face of MMT1, which I  posted a still of last night.  I have a camera looking at the back of the PRM, in hopes that we could see the beam on PRM, but no luck.  The thought was that the lever arm between TT2 and PRM is so short that as long as TT2 is reasonably in the center of its range, it doesn't need to be precise.  However, it seems that no matter how much I move TT1, I am not able to get a nice beam spot on PRM.  Part of this is that we have to be close enough to the right alignment to hit MMT1, MMT2 and TT2. 

Anyhow, we're frustrated, and I'm not sure what our next step is.  I would very much prefer it if we didn't have to open any chambers, but I don't currently have any new ideas on how to see the spot on MMT2 or TT2.

Procedure

1. Aligned X-arm to IR.
2. Aligned green to the X-arm.
3. PSL green and X-green aligned to the X-green beat PD.
4. Scanned X-green laser temperature (sweep X slow servo offset through the whole range)

I did not succeed in finding the beat note; but noticed something I cannot explain.
With green very stably aligned to the X-arm, GTRX reads 3000 counts. But when the laser temperature is changed and the green unlocks and locks to the X-arm, it locks with GTRX counts over 5000. GTRX stays at 5000 counts as long as the temperature is changing but settles down to 3000 (over a time lapse of tens of seconds) when let to stay at any specific temperature.

To get to the bottom of the RFAM mystery, we've got to resurrect the StochMon to trend the RFAM after the IMC.

We will put an 1811 on the MC_TRANS or IP_POS beam (the 1811 has an input noise of 2.5 pW/rHz).

Then the Stochmon has an input pre-amp, some crappy filters, and then Wenzel RMS->DC converters. We will replace the hand-made filters with the following ones from Mini-Circuits which happen to match our modulation frequencies perfectly:

11 MHz     SBP-10.7+

55 MHz     SBP-60+

29.5 MHz   SBP-30+

The Stochmon had a four-way splitter, four hand-made filters and four mini-circuits ZX47-60-S+ Power Detectors.

Using the filters from our stock I have replaced the hand-made filters with the ones mentioned in Rana's elog.   The power supply solders to the ZX47-60-S+ Power Detectors were weak and came off during reassembly. And some of the handmade short SMA cables broke off at the neck.  So I changed the power supply cables and replaced all the short SMA cables with elbows.  I also removed one of the Power Detectors since there were four in the box and we need only three now.

The power supply connector on the box is illegal.  The current lab standard for  {+15, 0 , -15}  uses that connector.  So we are going to change it as soon as possible.  We need to identify a good {0, 5} lab standard and stock them.

The following were removed from the box:

The box now looks like this:

Steps remaining in installation of Stochmon:

1) Install the Newfocus 1811 PD at the IPPOS by diverting some of the power in that path

2) Connect the outputs of the Stochmon to ADC inputs in 1X2 rack.

I added the StochMon calibrated channels to the data trend by including the following channel names in the C0EDCU.ini file:

[C1:IOO-RFAMPD_33MHZ_CAL]
[C1:IOO-RFAMPD_133MHZ_CAL]
[C1:IOO-RFAMPD_166MHZ_CAL]
[C1:IOO-RFAMPD_199MHZ_CAL]

Before saving the changes I committed C0EDCU.ini to the svn.

Then I restarted the frame builder so now the new channels can be monitored and trended.

I also removed two of the AM stabilizers from the 1Y2 rack. The other one, which is currently running th MC modulations, is still in the rack, and there it is going to remain together with its distribution box.

I stored both AM stabilizers and the Stochmon box inside the RF cabinet down the East arm.

Now stochmon for 11MHz and 55MHz is running. The calibration / noise measurement are going to be post later...

Here is a 48 hours trend of the RFAM monitor (a.k.a StochMon):

The upper plot is the DC output from the StochMon PD and the lower plot shows the calibrated RIN (Relative Intensity) at each modulation frequency.

I have downloaded minutes trends of StochMon for 48 hours staring from 6:00AM of Nov/24.

I followed Koji's calibration formula (#6009) to get the actual peak value (half of the peak-peak value) of the RF outputs and then divided them by the DC output to make them RIN.

It looks the RINs are hovering at ~ 4 x 10^-4 and fluctuate from 1x10^-4 to 1x10^-3. Those numbers agree with what we saw before (#5616)

So it seems the StochMon is working fine.

Update of the stochmon status

[Attachment 1: Circuit diagram]

- The new stochmon has a low noise amplifier (MAR-6SM) inside.
The RFAM signal from the PD has the power of -60~-50dBm, which is almost at the bottom of the sensitivity for the power detector.

- The band pass filters were doubled.

- I've suffered from some RF coupling from the power line as the power detector is quite sensitive to it.
The situation has been largely improved by the EMI filters in the power supply path, although the problem is still present.
The worst remaining problem is that we can not close the aluminum lid as it cause a huge sprious coupling.

[Attachment 2: Calibration result]

- The outputs were calibarted with Marconi. They showed the signals linear to dBm for the input powers between -70dBm and -10dBm.

- The calibration result was fitted with the empirical fit function. The function and the results are shown in the attachment.

[Attachment 3: Detection limit]

- The attached figure shows the power spectrum of the PD output. This measurement gives us the amount of the RF power given from the PD noise when there is no RF signal.

11MHz out passband noise: −72.7dBm ===> V11 = 2.0483
30MHz out passband noise: −64.6dBm ===> V30 = 1.9333
55MHz out passband noise: −71.2dBm ===> V55 = 2.0272

- Now 11MHz and 55MHz outputs seem indicating the power correctly, but the 29.5MHz output never provides useful information.
It is a constant value independent from the state of the incident beam. Strangely this problem disappears if the marconi is used
for the RF source. Thus this issue is not seen in the calibration measurement.

- So far, 11MHz, 29.5MHz, 55MHz, and DC outputs appear in the channels C1:IOO-RFAMPD_33MHZ, C1:IOO-RFAMPD_133MHZ, C1:IOO-RFAMPD_166MHZ, and C1:IOO-RFAMPD_199MHZ.
They will be renamed.

 New RFAM mon calibration