I studied the eigenfrequencies of a mirror mount designed with COMSOL.

I imposed fixed constraints for the base screws and for the screw connecting the base with the pedestal. Note that the central screw is connected to the base only for a small thickness, and the pedestal touches the base only with a thin annulus. This is in way to make a better model of the actual stress.

Shown in fig. 2 is the lowest eigenfrequency of the mount.

I' going to change the base and study the way the eigenfrequency vary, in way to find the configuration which minimizes the lowest eigenfrequency.

TP3 turbo pump's dry-foreline pump was replaced.

How to do it:

The pump should be replaced when it's performance  <1.0 - 1.3 Torr

Set up valve configuration as shown at Atm1: close in this order VAEE, VASV, VABS, VASV, VASE, VA6 and V5,

Turn TP3 off at it's controller in the rack. Wait till is stops, so you can read 760 Torr at TP3 foreline gauge

Disconnect intake, exhaust vacuum seals and replace pump. Reconnect vacuum fitting and start it up.

Confirm operational details on the front of the controller: 50 K_RPM, 0.2A and <100 mTorr

Reset valves in reverse order

PS: the average life of the tip seal on the Varian SSH-110 dry-pump is about 1 year

      This pump " ser LP1007L556 " seal  made new record of 668 days: thanks to Bob Taylor who is replacing these seals

How to calculate the accumulated round-trip Gouy phase (and namely the transverse mode spacing) of a general cavity
only from the round-trip ABCD matrix

T1300189

We have calibrated the overall actuators of each suspension independent of the optical levers. So, we know how much we are 
moving the optic in POS in real units as a result of the dither we inject for the lockin measurement. The amount the oplev beam 
appears to move if there is only POS motion is
d/cos(theta)
where theta is the oplev's angle of incidence and d is the distance the optic has moved in POS.  None of the of the steering mirrors in the 
oplev path matter. 

I propose that I will add an option in the lockin path to subtract away the apparent angle from the oplev output just before the signal 
goes into the lockin module.  Then we will be balancing the actuators based on only the actual angular motion.

The success of this technique depends on how well we know our actuator calibration and the oplev angle of incidence. This also 
assumes that the oplev beam is centered on the optic, so we don't have beam displacement from A2L of the oplev beam, which then 
makes another apparent angular motion.  I suspect that we are close enough that we won't have to worry about this effect.

I started poking around at what we want for new SUS MEDM screens.  Rana and I decided we'd start with the ASC TIPTILT screens:

It's missing some things (like SIDE OSEMS) but it should provide a good starting point.

I copied the entire <userapps>/asc/common/medm/asctt directory to a new directory in our sus area:

controls@rossa:/opt/rtcds/userapps/release 0$ cp -a asc/common/medm/asctt sus/c1/medm/new

I then removed all the useless file name prefixes.  We still need to go through and sed out all the ASC stuff in the MEDM files themselves.

It makes heavy use of macro substitution, which is good (it's what we're using now).  So once we clean up all the channel names, we should just be able to swap out the pointers in our overview screens to the new screens (or rename things).  In the mean time, during development, you can run:

controls@rossa:/opt/rtcds/userapps/release 0$ medm -x -macro "IFO=C1,ifo=c1,OPTIC=ITMX" sus/c1/medm/new/OVERVIEW.adl 

This post pertains to the fiber-coupled diode laser mounted in rack 1Y1.

To turn the laser on, first turn the power supply's key (red) to the clockwise. Then make sure that the laser is in "current" mode by checking that the LED next to "I" in the "Laser Mode" box in lit up. If the light is not on, press the button to the right of the "I" light until it is. Now press the output button (green). This is like removing the safety for the laser. Then turn the dial (blue) until you have your desired current. Presently, the current limit is set to around 92 mA.

To turn the laser off, dial the current back down to 0mA and turn the key (red) counterclockwise.

We can not leave cables connected like this. This is a burned toast award.

 This post describes how to use the Automated Photodetector Frequency Response System.

On the mechanical side, turn on:

-the diode laser (in rack 1Y1)

-the RF Switch (in rack 1Y1)

-the reference PD (under the POY table)

-the AG4395A Network Analyzer

The NA’s RF output should go to the laser’s modulation input, the reference PD’s output should go to the NA’s R input, and the RF Switch Chassis’s output (which is the combination of the two switches’ COM channels using a splitter) should go to the NA’s A input.

Once this is done, navigate into /users/alex.cole and run PDFR.sh. This script collects data for each photodetector under consideration by switching using a python script and communicating with the NA via GPIB. It then sends all the data to RF.m, which fits the functions, plots the latest data against canonical data, and saves the plots to file.

The fitting function, fit.m, also outputs peak frequency to the command line. This function uses PD name data (e.g. ‘REFL33’) to choose an interval with minimal noise to fit.

The main script prompts the user to press enter after each NA sweep to make sure that measurements don’t get interrupted/put out of order by RF switching.

Once you're done, you should turn off the laser, NA, RF Switch, and reference PD.

Troubleshooting

Sometimes, the NA throws up and doesn’t feel like running a particular sweep. If this happens, it’s a good idea to keep the matlab script from trying to analyze this PD’s data. Do this by opening up RF.m and commenting out the calls to ‘fit’ and ‘canonical’ for that PD.

If fit.m complains about a particular set of data, it is often the case that the N/P ratio (where N is order of approximation and P is number of points in the interval) is too high. You can fix this by reducing N or making the PD’s frequency range (chosen in the fnew_idx line) larger.

Choosing a single PD

If you only want to grab the transfer function for one PD, first look up which switch input it belongs to. This information is contained in /users/alex.cole/switchList. To turn the switch to a particular input, type something like:

python rf.py “ch7”

This command uses TCP/IP to tell the switch to look at channel 7. Switch input numbers range from 1 to 16, though not all of them are in use.

Once the switch is looking at the correct input, you can run a sweep and download the data by typing /opt/rtcds/caltech/c1/scripts/general/netgpibdata/NWAG4395A -s 1000000 -e 500000000 -c 499000000 -f [filestem for output] -d [path of directory for output] -i 192.168.113.108 -g 10 -x 15. 

 http://youtu.be/pEd7ru24Vx0

 B grade Nobel is awarded.

                                  If cables could dream?

This skill should be  mandatory for LIGOX graduates.

In moving now to full IFO locking, there are a number of sub-states to diagnose:

1. PRMI + 1 arm

• Measure sensing matrix as arm is scanned into resonance. Compare time series of sensing matrix elements with New LoopTickle simulation. But first, we need more than 1 LOCKIN screen in the LSC! That will allow us to measure all of the elements of simulataneously.
  
• Measure 3f PRMI noise spectra as a function of arm position. Look for trouble.

1. DRMI + 1 arm

• Same as PRMI above.
• Want to find why this is unstable sometimes. Make stable for t > 10 minutes.
• Maybe add some QPD->ASC for SRC angular control, but how? Will this still work after the arms are resonant or will it be swamped by carrier contrast defect? Will Berlusconi ruin all of the Italian gelateria? Only time can tell...

1. FPMI (non optically recombined) for ALS diagnosis
2. PRFPMI (iLIGO configuration)

• this ought to be easier than DRFPMI
• will let us tell if our ALS is good enough to handle the coupled cavity pole

1. DRFPMI (aLIGO style)

Which to do first and in what order?

I vote on PRMI+1arm -> PRFPMI

Step by step procedure for stabilizing arms using ALS servo:

The procedure is the same for both the arms. 

0. Check that the ALS arm servos are turned OFF and not sending any signals to the ETM suspensions. 

1. Find the beat note by varying the laser temperature (moving the slider for SLOW_SERVO2_OFFSET).
Tip: It is easier to have the arms locked using IR PDH while searching for the beat note. Also check the stability of the MC. Unstable MC will cause the PSL temperature to drift and thereby affect the beat frequency.

2. Once you have the beat note, check if the beat amplitude is ~ -15 to -20 dBm. If the amplitude is small, then the alignment needs to be fixed (either the green input pointing at the end tables or the PSL green alignment). This is important because the UGF of the phase tracking loop (should be above 1KHz) changes with the amplitude of the beat note.
Also the beat frequency should be < 100 MHz; preferably below 80 MHz.

3. Disable IR PDH locking if you had used it while searching for the beat note. 

4. Press CLEAR HISTORY button for the phase tracker servo. Check if the phase tracking loop is stable (phase tracker servo output counts should not be ramping up). If the phase tracker is not stable, check the servo gain and phase margin of the loop.

5. Turn OFF all filters in the ALS arm servo filter module except for FM5 (phase compensation filter). With ALS arm servo gain set to zero, enable the arm servo and allow ALS control signals to be sent to the ETM suspensions.

5. Open dtt and look at the power spectrum of the ALS error signal (C1:ALS-BEAT?_FINE_PHASE_OUT_HZ). 

6. Set ALS arm servo gain +/- 0.1 to check the sign of the servo gain. Wrong sign of gain will make the loop unstable (beat note moving all over the frequency range on the spectrum analyzer). If this happens, set the gain to zero immediately and clear history of phase tracker servo. If you have set the correct sign for gain, the servo will stabilize the beat note frequency right away. 

7. Once you know the correct sign of the servo gain, increase the gain in steps while simultaneously looking at the power spectrum of error signal on dtt (it is convenient to set dtt measurements to low bandwidth and exponential measurement settings). Increase the gain until you can see a slight bump close to the UGF of the ALS servo (>100Hz). 
There have been times when this servo gain was in a few hundreds; but right now it varies from +/- 10-20 for both the arms. So we are stepping up gain in steps of +/- 2.

8. Enable filters (FM2, FM3, FM6, FM7, FM8). Wait to see the rms noise of the error signal go down (a few seconds).

9. Enable boost filter (FM10). There also exists a weaker boost filter (FM4) which we don't use any more. 

Note:

1. Beat frequency changes affect both the servo gain and sign of gain. So if you lose stability of ALS servo at any point, you should go through all the steps again.

2. At any point if the ALS arm servo becomes unstable (which can happen if the MC loses lock or if the beat frequency was too high ), change the servo gain to zero immediately. Turn OFF all the filters except for FM5 (if they were enabled) and reset phase tracker servo (CLEAR HISTORY button in the phase tracker filter module). Masayuki has written the down script that does all this. The script will detect arm servo loop instability by continuously looking at the feedback signal. Details about the script can be found here. 

Here is a cheat sheet that can give you an idea of the SLOW SERVO2 offset range to scan in order to find the beat note:

PSL temperature  X offset   Y offset
31.58                     5278       -10890
31.52                     5140       (not recorded)
31.45                     4810       (not recorded)
31.33                     4640       -10440
31.28                     4500       -10340
            

The command to get the data from spectrum analyzer right now

From command line, put ./netgpibdata -i 192.168.113.108 -d AG4395A -a 17 -f meas01

(EDIT JCD:  You must first be in the correct folder:  /opt/rtcds/caltech/c1/scripts/general/netgpibdata/)

(EDIT JCD again: "meas01" in the command line instruction will be the name of the filename.  Also, the output file meas01.dat has a comment in the first line that must be deleted before you can plot the data.  This sucks, and we should write a script to strip that line, then make nice plots.)

Please take notice that although IP address of AG4395A is same as written in the help of netgpibdata, the GPIB address is not same. It's 17.

How to use  'scope from control room.

Open the browser. Put the IP adress of 'scope (192.168.113.25) into adrress bar of the browser. If it's on the network, below screen will open.

You can control 'scope, get the data, and so on from control room.

Please take notice that Google Chrome cannot connect the 'scope. So you have to use the Firefox or other browser.

FYI, you can trick out matplotlib by creating a matplotlibrc config file. This allows you to set defaults for plot size, trace color, fonts, grids, etc., analogous to what is achieved in ATF:1840 for Matlab.

Note also that matplotlib supports LaTeX by default (if you have LaTeX installed), which means, for example, that you can include true square roots on your spectral densities:

plt.ylabel('Voltage spectral density (V/$\\sqrt{\\mathrm{Hz}}$)')

Since the backslash is used for escape characters in python, you must escape LaTeX backslashes.

For maximum effect, you can set the following lines in your matplotlibrc file:

text.usetex = True

text.latex.preamble = \usepackage{txfonts}

Then all text and mathematics in your plot will be sent through LaTeX for processing and will appear in Times.

Also, why is the conversion from watts to volts V = 50 * sqrt(W) and not V = sqrt(50 * W)?

 We have tried to ssh into c1iscey yesterday morning. It just did not work. We have just tried it again (now) and it did work.

Lesson learned: always shut down the computer from a TERMINAL Do not turn it off by the manual power switch.

Here is how to measure the PRC length with a set of distance measurements in the optical setup. 

We need to take distance measurements between reference points on each mirror suspension. For the large ones (SOS) that are used for BS, PRM and ITMs, the reference points are the corners of the second rectangular base: not the one directly in contact with the optical bench (since the chamfers make difficult to define a clear corner), but the rectangular one just above it. For the small suspensions (TT) the points are directly the corners of the base plates.

From the mechanical drawings of the two kind of suspensions I got the distances between the mirror centers and the reference corners. The mirror is not centered in the base, so it is a good idea to cross check if the numbers are correct with some measurements on the dummy suspensions.

I assumed the dimensions of the mirrors, as well as the beam incidence angles are known and we don't need to measure them again. Small errors in the angles should have small impact on the results.

I wrote a MATLAB script that takes as input the measured distances and produce the optical path lengths. The script also produce a drawing of the setup as reconstructed, showing the measurement points, the mirrors, the reference base plates,  and the beam path. Here is an example output, that can be used to understand which are the five distances to be measured. I used dummy measured distances to produce it.

In red the beam path in vacuum and in magenta the beam path in the substrate. The mirrors are the blue rectangles inside the reference bases which are in black. The thick lines are the HR faces. The green points are the measurement points and the green lines the distances to be measured. The names on the measurement lines are those used in the MATLAB script. 

The MATLAB scripts are attached to this elog. The main file is survey_v2.m, which contains all the parameters and the measured values. Update it with the real numbers and run it to get the results, including the graphic output. The other files are auxiliary functions to create the graphics. I checked many times the code and the computations, but I can't be sure that there are no errors, since there's no way to check if the output is correct... The plot is produced in a way which is somehow independent from the computations, so if it makes sense this gives at least a self consistency test. 

This path does not look correct to me.  Maybe it's because this is supposed to represent "optical path lengths" as opposed to actual physical location of optics, but I think locations should be checked.  For instance, PRM looks like it's floating in mid-air between the BS and ITMX chambers, and PR2 is not located behind ITMX.  Actually, come to think of it, it might just be that ITMX (or the ITMs in general) is in the wrong place?

Here is a similar diagram I produced when building a Finesse model of the 40m, based on the CAD drawing that Manasa is maintaining:

I know the drawing is wrong. I put random distances, not realistic ones, and I did not try to get something close to reality. Once we put the measured distances, the drawing should (hopefully) be correct.

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

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

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

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

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

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

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

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

Sun Go Low, Lock Me Voltage Low.

#!/bin/bash   ### this is a comment  PATH=$PATH:/home/user/path    echo "How cool is this?" 

EDIT: it looks like the code highlighting is sort of broken :-(.

 Here is the logic that I have been using to calculate the transimpedence of PDs. Please let me know if you think anything is wrong.

The RF multiplexer is configured as shown in the figure. It is now effectively a 15x1 RF mux.

To select a required channel:

Run the script as shown below 

/opt/rtcds/caltech/c1/scripts/general/rfMux.py

>python rfMux.py ch11

For channel 10 to 16, you can just enter the required channel number and it is routed to the output.

For channel 1 to 8, you only need to input the required channel number as above. No need to run the code again to select ch9 after selecting ch1-8

How the NI-8100 controller works:

Whenever any channel of one switch is selected, the output of the other switch is set to its ch0 (ch1 and ch9 in the figure).

So selecting ch1-8 will automatically select ch9 as output for the other switch. IF you send a command to select ch9 afterwards, the first switch will be automatically set to ch1 and not stay on what you had selected before.

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

Give the file HP8591E_param.yml as an argument when running the script. This contains the sweep parameters: Start and stop frequencies along with the place where the plot is stored as a PDF.

The default PDF is located on the Desktop and is named HP8591E_View.pdf     Open this using okular and then run the script.  (Okular pdf viewer automatically reloads the PDF as and when a new one is created)

What the script does:

1) Set the start and stop frequencies as given in the .yml file

2) Take a data trace and plot it in a PDF.

3) Repeat taking traces and update the PDF. Untill Ctrl+C is pressed (PDF refresh rate: approximately every 3 seconds )

4) Exit smoothly after the keyboard interrupt.

Other details:

This spectrum analyzer is connected to a GPIB - Ethernet controller that is configured as santuzza.martian (192.168.113.109)

I have currently stolen the wireless modem from the spectrum analyzer inside the lab (vanna.martian) and using it for this one. *poker face*

To improve:

Get the plot to show where the two biggest peaks are located. Currently it recognizes only the biggest one.

Possibly have makers on the two peaks.

PFA a sample pdf

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

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

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

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

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

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

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

Attached is an example script showing how to access 40m data remotely. The only two nonstandard python modules you need are the nds2 client module and astropy (used for time conversion). For mac users, both of these are available via macports (nds2-client and, e.g. py27-astropy). Otherwise, check out their websites:

https://www.lsc-group.phys.uwm.edu/daswg/projects/nds-client.html

https://github.com/astropy/astropy

Have fun!

 I hereby confess to having a secret script.  But it is secret no longer!

It's a "goLock" script, and it is now in the path from any terminal.  It kills any open medm sessions (to clean up desktops), and then opens a palette of screens that I find useful.  It also starts up the CARM and DARM ALS watch scripts, and the toggle shutter scripts.  It then leaves the terminal in .../scripts/PRFPMI/ , which is where the carm_cm_up.sh script that we've been using lives.

I also made tonight a "goHome" script, but all that one does so far is set the LSC mode to OFF.  The other thing that this could / should do is restore all optics so we don't have hysteresis problems.

Also, also, my "new" misalign / restore scripts had a bug, in that they were always switching oplevs for the PRM, no matter what optic was requested.  This sometimes caused the PRM oplev to be engaged while the optic was misaligned, so the PRM would get rung up.  This has been fixed.

• Suppose you have a dtt template name test.xml
• The file test.dtt
  
  open
restore test.xml
run -w
save test2.xml
quit
 
• Run diag < test.dtt
• The result is saved in test2.xml

Following this entry, I have made the same change in the controls account on rossa:

In the ~/.grace/gracerc file (create one if it doesn't exist), put in a line which reads:

PAGE LAYOUT FREE

Now we can scale our dataviewer live and playback plots by stretching the window with our mouse. The attached screenshot shows how I filled up one of the vertical monitors with a DV window for arm locking.

I have adapted one of Evan's python scripts into an ipython notebook for calculating our PRMI sensing matrix - the work is ~half done.

The script gets the data from the various PD channels (like REFL33_I) and demdoulates it at the modulation frequencies. At the moment its using just the sensing channels, but with the recent addition of the SUS-LSC_OUT_DQ channels, we can demod the actuation channels as well and not have to hand code the exc amplitudes and the basolute phase. Please ignore the phase for the moment.

The attached PDF shows the demod (including lowpass) outputs for a 2 minute stretch of PRMI locked on f2. Next step is to average these numbers and make the radar plots with the error bars. The script is scripts/LSC/SensingMatrix/PRMIsensMat.ipynb and is in the SVN now.

** along the way, I noticed that the reason this notebook hasn't been working since last night is that someone sadly installed a new anaconda python distro today  without telling anyone by ELOG. This new distro didn't have all the packages of the previous one. I've updated it with astropy and uncertainties packages.

I've fixed the Radar plot making part, so that's now included too. The radial direction is linear, so you can see from the smearing of the blobs that the uncertainty is represented in the graphics due to each measurement being a small semi-transparent dot. Next, we'll put the output of the statistics on the plot: mean, std, and kurtosis.

If it all possible, don't use links to your home directory. Its not robust. It would be like if you clicked on your Google Music and it told you to ask me to sing that song to you. Imagine that on auto-repeat next time your fancy-bone itches.

I have set up new summary pages for the 40m: http://www.ligo.caltech.edu/~misi/summary/
This website shows plots (time series, spectra, spectrograms, Rayleigh statistics) of relevant channels and is updated with new data every 30 min.

The content and structure of the pages is determined by configuration files stored in nodus:/users/public_html/gwsumm-ini/ . The code looks at all files in that directory matching c1*.ini. You can look at the c1hoft.ini file to see how this works. Besides, a quick guide to the format can be found here http://www.ligo.caltech.edu/~misi/iniguide.pdf

Please look at the pages and edit the config files to make them useful to you. The files are under version control, so don’t worry about breaking anything.

Do let me know if you have any questions (or leave a comment in the pages).

How to get your own web page running on Nodus

1. On any martian machine, put your stuff in /users/public_html/$MYPAGE/
2. On Nodus, run: ln -s /users/public_html/$MYPAGE /export/home/
3. Your site is now available at https://nodus.ligo.caltech.edu:30889/$MYPAGE/
4. If you want to allow straight up directory listing to the entire internet, on Nodus run: sudoedit /etc/sites-available/nodus, and add the following lines towards the bottom:

Also, EQ gave us a better (and not pwd protected) URL for the summary pages. Please replace your previous links with this new one:

https://nodus.ligo.caltech.edu:30889/detcharsummary/

Like Steve pointed out, the summary pages show that the y-arm transmission drifts a lot when locked. The OL summary page shows that this is all due to ITMY yaw.

Could be either that they coil driver / DAC is bad or that the suspension is poorly built. We need to dig into ITMY OL trends over long term to see if this is new or now.

Also, weather station needs a reboot. And does anyone know what the MC_F calibration is?

I have created a wiki page with introductory info about the summary page configuration: https://wiki-40m.ligo.caltech.edu/Daily summary help

We can also use that to collect tips for editing the configuration files, etc.

The CDSUTILS package has a feature where it substitutes in a C1 or H1 or L1 prefix depending upon what site you are at. The idea is that this should make code portable between LLO and LHO.

Here at the 40m, we have no need to do that, so its better for us to be able to copy and paste channel names directly from MEDM or whatever without having to remove the "C1:" from all over the place.

the way to do this on the command line is (in bash) to type:

export IFO=''

To make this easier on us, I have implemented this in our shared .bashrc so that its always the case. This might break some scripts which have been adapted to use the weird CDSUTILS convention, so beware and fix appropriately.

This makes things act weird:

controls@pianosa|MC 1> z avg 1 "C1:LSC-TRY_OUT"
IFO environment variable not specified.

Too weird. I undid me changes. We'll have to make the C1: stuff work inside each python script.

LLO Operator Tips:

koji.arai@cr9:/opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignment$ cat autostart_strips.sh 
 

#!/bin/bash

# Baffle window setup 1500x480

StripTool -xrm 'StripTool.StripGraph.geometry:1500x470+0+24' /opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignment/baffle_pd.stp &
sleep 1

# DC signals setup

StripTool -xrm 'StripTool.StripGraph.geometry:1500x470+0+470' /opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignment/dc_signals.stp &
sleep 1

# WFS prx mich sry setup

StripTool -xrm 'StripTool.StripGraph.geometry:1500x470+0-24' /opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignment/wfs_prx_mich_sry.stp &
sleep 1

exit

In order to do online static IIR Wiener filtering one needs to do the following,

1) Get data for FIR Wiener filter witnesses and target.

2) Measure the transfer function (needs to be highly coherent, ~ 0.95 for all points) from the actuactor to the control signal of interest (ie. from MC2_OUT to MC_L).

3) Invert the actuator transfer function.

4) Use Vectfit or (LISO) to find a ZPK model for the actuator transfer and inverse transfer functions.

5) Prefilter your witness data with the actuator transfer function, to take into account the actuator to control transfer function when designing the offline Wiener FIR filter.

6) Calculate the frequency response for each witness from the FIR coefficients.

7) Vectfit the frequency reponses to a ZPK model, this is the FIR to IIR Wiener conversion step.

8) Now, either, divide the IIR transfer function by the actuator transfer function or more preferably, multiply by the inverse transfer function.

9) Use Quack to make SOS model of the IIR Wiener filter and inverse transfer function product that goes into foton for online implementation.

10) Load it into the system.

The block diagram below summarizes the steps above.

Frustrated by the single pixel width of the windows and how hard that makes it to drag things around, I explored StackExchange:

which showed how there is a .xml file which can be edited to increase this. I've changed the border size to 4 pixels on Rossa - its nice.

Herein, I will describe the current settings and procedures used to achieve the DRFPMI lock, cobbled together from scripts, burts and such. 

Initial Alignment

1. With arms POX/POY locked, run dither alignment servos. Set transmon QPD offsets here
2. Restore "PRMI Carrier" configuration, run BS and PRM dither alignment servos simultaneously. (Note: this sacrifices some X arm alignment for better dark port alignment. In practice no appreciable loss of TRX is observed)
3. Misalign PRM, align SRM and tune SRM alignment by eye while looking at AS camera. 
4. Restore POX/POY arm lock, lock green to arms, check that powers are high enough and align if neccesary.

Initial Configuration

CARM, DARM

For CARM and DARM, the A channels are used for the ALS signals, whereas the B channels are used for blending the RF signals. 

ALS

• BEATX and BEATY, I and Q channels: +0dB Whitening Gain, Whitening Filters ON
• Green beatnotes somewhere between 20-80MHz, following sign convention of temperature slider UP makes beat freq go UP.  Check spectrum of PHASE_OUT_HZ vs references in ALS_outOfLoop_Ref.xml. The locking script automatically sets the correct phase tracker gain, so no need to adjust manually.
• CARM_A = -1.0 x ALSX + 1.0 x ALSY, G=1.0
• DARM_A = 1.0 x ALSX + 1.0 x ALSY, G=1.0

RF

• CM Board: REFL11 I daugher board output -> IN1, IN1 Enabled, -32dB input gain, 0.0V offset, all boosts off, AO polarity positive, AO gain +0dB
• MC Board: IN2 disabled, -32dB input gain
• CM_SLOW: +0dB Whitening Gain, Whitening ON, LSC-CM_SLOW_GAIN = -5e-4 (Though, it would be good to reallocate this gain to the input matrix element)
• CARM_B = 1.0 x CM_SLOW, FM4 FM10 ON, G=0 (FM4 = LP700 for AO crossover stability, FM10 = 120:5k for coupled cavity pole compensation)
• AS55: +9dB Whitening Gain, Whitening filters manual, Demod angle -37.0
• DARM_B = -1e-4 x AS55 Q, G=0

DRMI 3F

For the DRMI, the A channels are used for the 1F signals, whereas the B channels are used for the 3F signals. The settings for transitioning to 1F after locking the DRFPMI have not yet been determined. 

These settings are currently saved in the DRMI configurator, but the demod angles are set for DRFPMI lock, so the settings don't reliably work for misaligned arms. 

• REFL33: +30dB Whitening Gain, Whitening filters trigger on DRMI lock, Demod angle: 136.0
• REFL165: +24dB Whitening Gain, Whitening filters trigger on DRMI lock, Demod angle: -111.0
• POP22: +15dB Whitening Gain, Whitening filters OFF, Demod angle: -114.0
• AS110: +36dB Whitening Gain, Whitening filters OFF, Demod angle: -116.0
• POPDC: +0dB Whitening Gain, Whitening filters OFF (used as a supplemental trigger signal when CARM and DARM are buzzing and POP22 fluctuates wildly)
• MICH_B = 6.0 x REFL165Q, offset = 15.0
• PRCL_B = 5.0 x REFL33I, offset = 45.0
• SRCL_B = -0.6 x REFL165I + 0.24 x REFL33 I, offset=0

The REFL33 element in SRCL_B is to reduce the PRCL coupling, was found empirically by tuning the relative gains with the arms misaligned and looking at excitation line heights. The offsets were found by locking the DRMI on 1F signals with arms misaligned, and taking the average value of these 3F error signals.  

Servo filter configuration

The CARM and DARM ALS settings are largely scripted by scripts/ALS/Transition_IR_ALS.py, which takes you from arms POX/POY locked to CARM and DARM ALS locked. The DRMI settings are usually restored from the IFO_CONFIGURE screen. 

• CARM: FM[1, 2, 3, 5, 6] , G=4.5, Trigger forced on, no FM triggers, output limit 8k
• DARM: FM[1, 2, 3, 5, 6] , G=4.5, Trigger forced on, no FM triggers, output limit 8k
• MICH: FM[4, 5], G= -0.03, Trigger POP22 I x 1.0 [50, 10], FM[2, 3, 7] triggered [50, 10], output limit 20k
• PRCL: FM[4, 5], G= -0.003, Trigger POP22 I x 1.0 [50, 10], FM[1, 2, 8, 9] triggered [50, 10], output limit 8k
• SRCL: FM[4, 5], G= -0.4, Trigger AS110 Q x 1.0 [500, 100], FM[2, 7, 9] triggered [500, 100], output limit 15k

Actuation Output matrix

• MC2 = -1.0 x CARM
• ETMX = -1.0 x DARM
• ETMY = 1.0 x DARM
• BS = 0.5 x MICH
• PRM = 1.0 x PRCL - 0.2655 MICH
• SRM = 1.0 x SRCL + 0.25 MICH (The mich compensation is very roughly estimated)

Locking Procedure

When arms are POX/POY locked, and the green beatnotes are appropriately configured, calling scripts/DRFPMI/carm_cm_up.sh initiates the following sequence of events:

• Turn ON MC length feedforward and PRC angle feedforward
• Set ALS phase tracker UGFs by looking at I and Q magnitudes
• Set LSC-ALSX and LSC-ALSY offsets by averaging, ramp CARM+DARM gains up, XARM+YARM gains down, engage CARM+DARM boosts, now ALS locked
• Move CARM away from resonance, offset = -4.0 (DRMI locks quicker on this side for whatever reason)
• Restore PRM, SRM alignment. Set DRMI A FM gains to 0, B FM gains to 1.0. Enable LSC outputs for BS, PRM, SRM
• When DRMI has locked, add POPDC trigger elements to DRMI signals and transition SRCL triggering to POP22I. NB: In the c1lsc model, the POPDC signal incident on the trigger matrix has an abs() operator applied to it first. 
  • MICH Trig = 1.0 x POP22 I + 0.5 x POPDC, [50, 10]
  • PRCL Trig = 1.0 x POP22 I + 0.5 x POPDC, [50, 10]
  • SRCL Trig = 10.0 x POP22 I + 5 x POPDC, [500, 100]
• Reduce POX, POY whitening gains from their nominal +45dB to +0dB, so there aren't railing channels making noise in the whitening chassis and ADCs
• DC couple ITM oplevs (average spot position, set FM offset, turn on DC boost filter, let settle)
• With an 8 second ramp, reduce CARM offset to 0 counts. 
• MANUALLY adjust CARM_A and DARM_A offsets to where CARM_B_IN and DARM_B_IN are seen to fluctuate symetrically around their zero crossing.
  • Note: Last week, this adjustment tended to be roughly the same from lock to lock, unlike the PRFPMI which generally didn't need much adjustment. Also, by jumping from CARM offset of -0.4 to 0.4, it could be seen that the zero crossing in  CARM_B aka CM_SLOW aka REFL11 had some offset, so CARM_B_OFFSET was set to 0.005, but this may change. 

When CARM and DARM are buzzing around true zero, powers maximized:

• CARM and DARM FM1 (18,18:1,1 boosts) OFF
• CARM_B_GAIN 0.0 -> 1.0, FM7 ON (20:0 boost)
• DARM_B_GAIN 0.0 -> 0.015, FM7 ON (20:0 boost) 
• MC servo board IN2 ENABLE, IN2 gain -32dB -> -16dB
• Turn ALL MC2 violin filters OFF (smoothen out AO crossover)
• If stable, CM board IN1 gain -32dB -> -10dB (This is the overall CARM gain, the arm powers stabilize within the last few dB of this transition)
• CARM_A_GAIN 1.0 -> 0.7
• CARM_A FM9 ON (LP1k), sleep, FM 1 ON (1:20 deboost), sleep, FM 2 ON (1:20 deboost), HOLD OUPUT, CARM now RF only
• DARM_B_GAIN 0.015 -> 0.02, sleep, DARM_A_GAIN 1.0 -> 0.0 (This may not be the ideal final DARM_B gain, UGF hasn't been checked yet)

IFO is now RF only!

• Turn on transmon QPD servos.
• Adjust comm/diff QPD servo offsets to correct any problems evident on AS/REFL cameras. This usually brings powers from ~100-120 to ~130-140. 

This is as far as we've taken the DRFPMI so far, but the CARM bandwidth is still only at a few kHz. Based on PRFPMI locking, the next steps will be:

• CM BOARD +12dB or so additional IN1 gain, more AO gain may be needed to get crossover to final position of ~100Hz
• MC2 viollin filters back on
• CM boost(s) on
• AS55 whitening on
• Transition DRMI to 1F

Today image capture did not work again, though it had worked 3 days before. I also found that red indicator light on the front pannel of SENSORAY was not turned on, which had been turned on 3 days before (you can find SENSORAY on the floor near Pianosa). Possible reason that it did not work again was I restarted Pianosa last night. Anyway, it works now. Here I report what I did to make it work.

I ran thes commands in shell, following the instruction of the manual of SENSORAY 2253 (Page 5; link or you can find the manual in /users/sensoray; I put it there). 

> cd /users/sensoray/sdk_2253_1.2.2_linux

> make all

> sudo make install

> modprobe s2253

Then the red light got turned on, and image capture worked.

If you recieve an error like "No such file or directory: /dev/video0" at the beginning of the error message when you run image capture scripts from the medm screen, or if you notice that the red indicator light of SENSORAY is not on, this procedure could help you. 

Do we need "make" everytime? Do you mean just running "modprobe" didn't work?

I don't know if just running "modprobe" will work or not, because I didn't try it...  When the same problem happens again, we can try just running "modprobe" first.