It wasn't fully mentioned in ELOG 11814.
We checked the PD first and this behavior didn't change after the realignment of the AS55PD.
Yutaro confirmed that this effect is happening in the vacuum chamber.

Dataviewer x axis end is not there.

On ( 2600 days) longer plots it is missing 8 moths and on (100 days) shorther plot it is missing 1 month.

With the same method as reported in elog 11785, I calibrated oplevs for ITMX/ETMX.

RESULTS 

According to this measurement, ratio of the calibration factor derived with this measurement (NEW) and the calibration factor for now (OLD), i.e. NEW/OLD was:   

ETMX_PIT: 4.470

ETMX_YAW: 2.5970

ITMX_PIT: (-)1.1102

ITMX_YAW: 1.8173

NOTE

The calibration factors of the oplevs for ETMY/ITMY are   NOT UPDATED YET. I updated on Dec 11, 2015

Q adjusted the Dataviewer so it is not chopping of data any more. Thanks.

Cold cathode gauge reading of 10 years.

We've been talking about putting in BLRMS filters for several channels - it would be a pain to manually copy over the correct bandpass and lowpass filter coefficients into the newly created filter banks, and so I've set up a script (attached) that can do the job. As template filters, I'vm using the filters rana detailed here. Essentially, what the script does is identify the (empty on creation) block of text for a given filter: e.g. RMS_STS1Z_BP_0p01_0p03 for STS1Z), and appends the template filter coefficients. To test my script, I first backed up the original C1PEM.txt file from /opt/rtcds/caltech/c1/chans, removed all the filter coefficients for the STS1Z BLRMS filters, and then replaced it with one generated using my script. I then loaded the coefficients for all the filters in the C1PEM modules, without any obvious error messages being generated. I also checked that foton could read the new file, and checked tmake sure that sensible filter shapes were seen for some channels. Since this seems to be working, I'm going to start putting in BLRMS blocks into the models tomorrow.

SLOWDC servo was dead. I followed EricQ's instruction.

MC Autolocker got stack somewhere. I had to go to megatron and kill MC Autolocker.

init relaunched the autolocker automatically, and now it started properly.

[gautam, ericq]

Since ETMX seems to have been on good behavior lately, we tried to fire the IFO back up. 

We had a fair amount of trouble locking the DRMI with the arms held off resonance. For reasons yet to be understood, we discovered that the SRCL OLG looks totally bananas. It isn't possible to hold the DRMI for very long with this shape, obviously. 

With the arms misaligned and the DRMI locked on 1F, the loop shape is totally normal. I haven't yet tried 3F locking with the arms misaligned, but this is a logical next step; I just need to look up the old demod angles used for this, since it wasn't quickly possible with the 3F demod angles that are currently set for the DRFPMI. 

Somehow, the controls user account on donatella lost its membership to the sudoers group, which meant doing anything that needs root authentication was impossible. 

I fixed this by booting up from a Linux install USB drive, mounting the HD, and running useradd controls sudo

I disconnected the cable that was connected to CH6 of the whitening filter in 1Y2, then connected POXDC cable to there (CH6). This channel is where POXDC used to connect.

Then I turned on the whitening filter for POXDC and POYDC (C1:LSC-POXDC FM1, C1:LSC-POYDC FM1) and changed the gain of analog whitening filter for POXDC and POYDC from 0 dB to 45 dB and from 0 dB to 39 dB, respectively (C1:LSC-POXDC_WhiteGain, C1:LSC-POYDC_WhiteGain).

I checked how POXDC level changes when the angle of ITMX is varied. ETMX was misaligned.

Then I found that in YAW direction the POXDC level is maximized but it doesnt have plateau, and in PIT direction it is not maximized so that it is at the slope and it doesnt have plateau, as shown in attached figures. These results indicate that the beam size on POX11 is not small enough compared to the size of the diode and it is not centered well.

Summary:

I've made several changes to the C1MCS model and C1PEM model, and have installed BLRMS filters for the MC mirror coils, which are now running. The main idea behind this test was to see how much CPU time was added as a result of setting up IPC channels to take the signals from C1MCS to C1PEM (where the BLRMS filtering happens) - I checked the average CPU time before and after installing the BLRMS filters, and saw that the increase was about 1 usec for 15 IPC channels installed (it increased from ~27usec to 28usec). A direct scaling would suggest that setting up the BLRMS for the vertex optics might push the c1sus model close to timing out - it is at ~50usec right now, and I would need, per optic, 12 IPC channels, and so for the 5 vertex optics, this would suggest that the CPU timing would be ~55usec. I have not committed either of the changed models to the SVN just yet. 

Details:

1. On Eric's suggestion, I edited the C1_SUS_SINGLE_CONTROL library part to tap the signal at the input to the output filters to the coils, as this is what we want the BLRMS of. I essentially added 5 more outputs to this part, one for each of the coils, and they are named ULIn etc to differentiate it from the signal after the output filters. I have not committed the changed library part to the SVN just yet. 
2. I used the cdsIPCx_SHMEM part to pipe the signals from C1MCS to C1PEM - a total of 15 such channels were required for the three IMC mirrors.
3. I added the same cdsIPCx_SHMEM parts to the C1PEM model in the receiving configuration, and connected their outputs to BLRMS blocks. The BLRMS blocks themselves are named as RMS_MC2_UL_COIL_IN and so on.
4. I shutdown the watchdogs to MC1, MC2 and MC3, and restarted the C1PEM and C1MCS models on C1SUS. Yutaro pointed out that on restarting C1MCS, the IMC autolocker was disabled by default - I have enabled it again manually.
5. I was under the impression that each time a BLRMS block is added, a filter bank is automatically added to the C1PEM.txt file in /opt/rtcds/caltech/c1/chans - turns out, it doesn't and my script for copying the template bandpass and lowpass filtes into the .txt files was needlessly complicated. It suffices to change the filter names in the template file, and append the template file to C1PEM.txt using the cat command: i.e. cat template.txt > C1PEM.txt. The computer generated file seems to organize the filters in alphabetical order, and my approach obviously does not do so, but the coefficients are loaded correctlty and the filters seem to be functioning correctly so I don't think this is a problem (I measured the transfer function of one of the filters with DTT, it seems to match up well with the Foton bode plot). 
6. I added a few lines to the script to also turn on the filter switches after loading the filter coefficients.

Next steps:

Now that I have a procedure in place to install the BLRMS filters, we can do so for other channels as well, such as for the coils and Oplevs of the vertex optics, and the remaining PEM channels (SEIS, accelerometers, microphones?). For the vertex optics though, I am not sure if we need to do some rearrangement to the c1sus model to make sure it does not time out...

[ericq, gautam]

While trying to resolve the strange SRCL loop shape seen yesterday (which has been resolved, eric will elog about it later), we got a chance to put in the correct filters to the "CINV" branch in the C1CAL model for MICH, PRCL, and SRCL - so we have some calibrated spectra now (Attachment #1). The procedure followed was as follows:

1. Turn on the LO gain for the relevant channel (we used 50 for MICH and SRCL, 5 for PRCL)
2. Look at the power spectra of the outputs of the "A" and "CINV" filter banks - the former has some calibrated filters in place already (though I believe they have not accounted for everything).
3. Find the peak height at the LO excitation frequency for the two spectra, and calculate their ratio. Use this to install a gain filter in the CINV filter module for that channel. 
4. Look at the spectrum of the output of the "W" filter bank for that channel - the plot attached shows this information.

The final set of gains used were:

MICH: -247 dB

PRCL: -256 dB

SRCL: -212 dB

and the gain-only filters in the CINV filter banks are all called "DRMI1f".

Once we are able to lock the DRFPMI again, we can do the same for CARM and DARM as well...

http://blogs.mathworks.com/loren/2007/12/11/making-pretty-graphs/

Let Loren help you make your Oplev data readable to humans.

I updated the figures. I think it's easier to read now.

In order to be consistent with the naming conventions for the new BLRMS filters, I made a library block that takes all the input signals of interest (i.e. for a generic optic, the coil signals, the local damping shadow sensors, and the Oplev Pitch and Yaw signals - so a total of 12 signals, unused ones can be grounded). The block is called "sus_single_BLRMS". Inside the block, I've put in 12 BLRMS library blocks, with each input signal going to one of them. All the 7 outputs of the BLRMS block are terminated (I got a compiling error if I did not do this). The idea is to identify the optic using this block, e.g. MC2_BLRMS. The BLRMS filters inside are called UL_COIL, UR_COIL etc, so the BLRMS channels will end up being called C1:SUS-MC2_BLRMS_UL_COIL_0p01_0p03 and so on. I tried implementing this in C1PEM, but immediately after compiling and restarting the model, I noticed some strange behaviour in the seismic rainbow STS strip in the control room - this was right after the model was restarted, before I attempted to make any changes to the C1PEM.txt file and add filters. I then manually opened up the filter bank screens for the RMS_STS1Z bandpass and lowpass filters, and saw that the filter switches were OFF - I wonder if this has something to do with these settings not being updated in the SDF tables? So I manually turned them on and cleared the filter hitsory for all 7 low pass and band pass filter banks, but the traces on the seismic striptool did not return to their nominal levels. I manually checked the filter shapes with Foton and they seem alright. Anyways, for now, I've reverted to the C1PEM model before I made any changes, and the seismic strip looks to be back at its normal level - when I recompiled and restarted the model with the changes I made removed, the STS1Z BLRMS bandpass and lowpass filters were ON by default again! I'm not sure what I'm doing wrong here, I will investigate this further. 

To avoid the strange kicking of ETMX, I locked XARM with ITMX actuated instead of ETMX so that I changed elements of C1LSC_OUTPUT_MTRX; before: XARM=ETMX, after: XARM=ITMX.

And I change C1:LSC-XARM_GAIN from 0.007 to 0.022.

With this setup, I ran dither but then error signals of dithering oscillated as shown in the figure below.

Then I found that if C1:ASS-XARM_ETM_PIT_L_DEMOD_SIG_GAIN / C1:ASS-XARM_ETM_YAW_L_DEMOD_SIG_GAIN in C1ASS_LOCKINS_XARM.adl are changed as 0.200 -> 0.100 and 0.200 -> 0.100, respectively, the dithering works well.

But the burt file that is loaded when you let dithering "ON" is not changed, because now I don't know how to update a burt file. So, if you let dithering "ON", the dithering will run with the condition that C1:ASS-XARM_ETM_PIT_L_DEMOD_SIG_GAIN / C1:ASS-XARM_ETM_YAW_L_DEMOD_SIG_GAIN are not 0.100 but 0.200.

As I did for YARM (elog 11779), I measured the relation between offsets added just after the demodulation of the dithering loop of XARM and beam spot shift on ETMX. Defferent from YARM, the beam spot on ITMX DOES change because only BS is used as a steering mirror (TT1&2 are used for the dithering of YARM). Instead, the beam spot on BS DOES NOT change.

This time, I measured by oplevs the angles of both ETMX and ITMX for each value of offset, and using these angles I calculated the shift of the beam spot on ETMX so that I got two independent estimations (one from ETMX oplev, and the other from ITMX oplev) as shown below. The calibration of the oplevs reported in elog 11831 is taken into account. 

The difference of two estimations comes from the error of calibration of oplevs and/or imperfect alignment, I think. 

To focus POX beam on POX11 PD, I added an iris and a lens before POX11 PD as you can see in Attachment 1.

It seemed that the beam is well focused, but the behavior of POXDC has not changed, as shown in Attachments 2 & 3.    

I had noticed for a while that the c1ioo frontend model had much higher variability than any of the other other 16k models, and would run longer than 60us multiple times an hour. This struck me as odd, since all it does is control the WFS loops. (You can see this on the Nov17 Summary page. (But somehow, the CDS tab seems broken since then, and I'm not sure why...))

This has happily now been solved! While poking around the model, I noticed that the MC2 transmission QPD data streams being sent over from c1mcs were using RFM blocks. This seemed weird to me, since I wasn't even aware that c1ioo had an RFM card. Since the c1sus and c1ioo frontends are both on the Dolphin network, I changed them to Dolphin blocks and voila! The cylce time now holds steady at 21usec. 

Update: I think I figured out the problem with the CDS summary pages. Looking at the .err files in /home/40m/public_html/summary/logs on the 40m LDAS account showed that C1:FEC-33_CPU_METER wasn't found in the frame files. Indeed, this channel was commented out in c1/chans/daq/C0EDCU.ini. I enabled it and restarted daqd. Hopefully the CDS tab will come back soon...

[ericq, gautam]

BLRMS filters have been set up for the coil outputs and shadow sensor signals. The signals are sent to the C1PEM model from C1MCS, where I use the library block mentioned in the previous elog to put the filters in place. Some preliminary observations:

1. The entire operation seems to be computationally quite expensive - just for the 3 IMC mirrors, the average CPU time for C1PEM increased from ~50 usec (before any changes were made to C1PEM) to ~105 usec just as a result of installing 420 filter modules with no filter coefficients loaded (3 optics x 10 channels x 14 filter banks) to ~120 usec when all the BP and LP filters for the BLRMS blocks have been loaded and turned on (Attachment #1). Eric suggested that it may be computationally more efficient to do this without using the BLRMS library part - i.e. rather than having so many filter modules, do the RMS-ing using a piece of C code that essentially just implements the same SOS filters that FOTON generates, I will work on setting this up and checking if it makes a difference. The fact that just having empty filter modules in the model almost doubled the computation time suggests that this approach may help, but I have to think about how to implement some of the automatic checks that having a filter bank in place gives us, or if these are strictly necessary at all...
2. While restarting the C1PEM model, we noticed that some of the optics were shaking - looking at the CPU timing signals for all the models on C1SUS revealed that both the C1SUS model and the C1MCS model were geting overclocked when C1PEM was killed (see the sharp spikes in the red and green traces in Attachment #2 - the Y scale in this plot is poor and doesnt put numbers to the overclocking, I will upload a better screenshot that Eric took once I find it). The cause is unknown.
3. Yesterday, I noticed that when C1PEM was restarted, the states of the filter bank switches were not reverted to their states in the SDF tables. They are showing up as changes, but it is unclear why we have to manually revert them. I have also not yet added the states of the newly installed filters (BPs and LPs for the MC BLRMS blocks) to the SDF tables. 

Unrelated to this work: we cleaned up the correspondence between the accelerometer numbers and channels in the C1PEM model. Also, the 3 unused ADC blocks in C1PEM (ADC0, ADC1 and ADC2) are required and cannot be removed as the ADC blocks have to be numbered sequentially and the signals needed in C1PEM come from ADC3 (as we found out when we tried recompiling the model after deleting these blocks).

[yutaro, Koji]

Now, the beam on POX11 PD is well centered and well focused.

We found out why POXDC had behaved as reported in elog 11839. There were a few reasons: the beam was not focused enough, hight of a mirror was not matched to the beam well, path of the light reflected by misaligned SRM was occasionally close to the path of POX beam.

Then, What we did is following:

- changed orientation of SRM slightly

- changed the hight of the mirror whose hight had not matched well, by changing the pedestal (hight of which mirror was changed is shown in Attachment 1.)

- put a lens with f=250 mm (where the lens is located is shown in Attachment 1.)

- refined alignment for the POX beam to hit on the center of POX11 PD.  

As a result, POX DC level behaved as shown in Attachment 2&3 when the orientation of ITMX was varied (Attachment 2: POX DC vs ITMX PIT, Attachment 3: POX DC vs ITMX YAW). 

You can see broad plateau when varied in both PIT and YAW directions, and the beam is at the center of the plateau if ITMX is aligned ideally.

I glanced at the summary pages and noticed that, since Friday around when we first loaded up the new BLRMS parts, daqd has crashing very frequently (few times per hour). 

I'm going to comment out the c1pem lines from the daqd master file for tonight, and see if that helps. 

I added 1 line to one of the ASS scripts, UNFREEZE_DITHER.py like this:

L29>   ez.cawrite('C1:ASS-'+dof+'_GAIN', 0)   

The reason why I added this is: without this line, C1:ASS-'+dof+'_GAIN become larger that 1.0, which is nomial value, if you UNFREEZE DITHER when the dither is already running or C1:ASS-'+dof+'_GAIN is not 0.0.  

Since removing c1pem from the daqd master file, daqd has not crashed. I suppose we're running into the stability issue that motivated us to disable some of the other models (IOPs, RFM, etc.) during the RCG upgrade. 

A question to Jamie: although the new framebuilder prototype still had the same problem with trend writing, can it handle this higher testpoint/DQ channel load?

The new fb1 daqd was also crashing even without the trend writing enabled.  I'm not sure how much that's affected by the load, though, e.g. it might be able to handle the extra load fine but then die because of some other issue not related to the number of channels being acquired.

We should schedule some time this week to work on fb1 some more.

I changed the snapshot file for ASS, /opt/rtcds/caltech/c1/scripts/ASS_DITHER_ON.snap as follows:

L124 >  C1:ASS-XARM_ETM_PIT_GAIN 1 -5.000000000000000e-02

        => C1:ASS-XARM_ETM_PIT_GAIN 1 -1.500000000000000e-02

L128>   C1:ASS-XARM_ETM_YAW_GAIN 1 5.000000000000000e-02

        => C1:ASS-XARM_ETM_YAW_GAIN 1 1.500000000000000e-02

The purpose of this change is to avoid the oscillation when the dithering of X arm is running.

I've done a couple things to try and make nodus a little more secure. Some have worried that nodus may be susceptible to being drafted into a botnet, slowing down our operations. 

1. I configured the ssh server settings to disallow logins as root. Ubuntu doesn't enable the root account by default anyways, but it doesn't hurt.

2. I installed fail2ban. Function: If some IP address fails to authenticate an ssh connection 3 times, it is banned from trying to connect for 10 minutes. This is mostly for thwarting mass brute force attacks. Looking at /var/log/auth.log doesn't indicate any of this kind of thing going on in the past week, at least.

3. I set up and enabled ufw (uncomplicated firewall) to only allow incoming traffic for:

• ssh
• ELOG
• Nodus apache stuff (svn, wikis, etc.)

I don't think there are any other ports we need open, but I could be wrong. Let me know if I broke something you need!

The noise floor of the Rga scan is glitching less today

Summary:

I measured the PZT actuator gain for the Lightwave NPRO at the Y-end to be 3.6 +/- 0.3 MHz/V. This is somewhat lower than the value of 5 MHz/V reported here, but I think is consistent with that measurement. 

Details:

In order to calibrate the Y-axis of my Aux PDH loop noise budget plots, I wanted a measurement of the end laser actuator gain. I proceeded to measure this as follows:

1. Use a function generator to add a DC offset to the error point - I did this by taking the output of the RF mixer -> Input A of an SR560, output of the function generator -> input B of the SR560 (via a 20 Ohm attenuator, and with a 50ohm T-eed to the input for impedance matching), and setting the output to A-B, and feeding that to the "Servo Input" on the PDH box.
2. I then locked the arm to IR, ran the dither to maximize the green transmission, and set up a beat note at ~39 MHz with the help of the analyzer in the control room.
3. Set phase tracker UGF, clear phase history.
4. Vary the DC offset to the error point by using the offset on the function generator. I varied the offset until the green TEM00 lock was lost, in steps of 0.1 V. At each step, I averaged the output of the phase tracker for 15 seconds.
5. Convert the applied DC offset to the DC offset appearing at the servo output using the transfer function of the servo box (DC gain measured to be ~65 dB), taking into account the 20dB attenuator also.

The attached plot shows the measured data. The X-axis is shown after the conversion mentioned in the last bullet point. The error bars are the standard deviations of the averaging at each DC offset. 

To do:

1. The value of the DC gain of the servo, 65 dB, is an approximate one based on a rough measurement I did earlier today. I'll take a TF measurement with an SR785 tomorrow, but I think this shouldn't change the number too much.
2. Upload the noise budget measurements for the Y-end PDH loop.

Glitches are gone. Rga scan is good

I spent this afternoon trying to debug fb1, with very little to show for it.  We're back to running from fb.

The first thing I did was to recompile EPICS from source, so that all the libraries needed by daqd were compiled for the system at hand.  I compiled epics-3.14-12-2_long from source, and installed it at /opt/rtapps/epics on local disk, not on the /opt/rtapps network mount.  I then recompiled daqd against that, and the framecpp, gds, etc from the LSCSoft packages.  So everything has been compiled for this version of the OS.  The compilation goes smoothly.

There are two things that I see while running this new daqd on fb1:

instability with mx_streams

The mx stream connection between the front ends and the daqd is flaky.  Everything will run fine for a while, the spontaneously one or all of the mx_stream processes on the front ends will die.  It appears more likely that all mx_stream processes will die at the same time.  It's unclear if this is some sort of chain reaction thing, or if something in daqd or in the network itself is causing them all to die at the same time.  It is independent of whether or not we're using multiple mx "end points" (i.e. a different one for each front end and separate receiver threads in the daqd) or just a single one (all front ends connecting to a single mx receiver thread in daqd).

Frequently daqd will recover from this.  The monit processes on the front ends restart the mx_stream processes and all will be recovered.  However occaissionally, possibly if the mx_streams do not recover fast enough (which seems to be related to how frequently the receiver threads in daqd can clear themselves), daqd will start to choke and will start spitting out the "empty blocks" messages that are harbirnger of doom:

Aborted 2 send requests due to remote peer 00:30:48:be:11:5d (c1iscex:0) disconnected
00:30:48:d6:11:17 (c1iscey:0) disconnected
mx_wait failed in rcvr eid=005, reqn=182; wait did not complete; status code is Remote endpoint is closed
disconnected from the sender on endpoint 005
mx_wait failed in rcvr eid=001, reqn=24; wait did not complete; status code is Remote endpoint is closed
disconnected from the sender on endpoint 001
[Wed Dec  9 18:40:14 2015] main profiler warning: 1 empty blocks in the buffer
[Wed Dec  9 18:40:15 2015] main profiler warning: 0 empty blocks in the buffer
[Wed Dec  9 18:40:16 2015] main profiler warning: 0 empty blocks in the buffer

My suspicion is that this time of failure is tied to the mx stream failures, so we should be looking at the mx connections and network to solve this problem.

frame writing troubles

There's possibly a separate issue associated with writing the second or minute trend files to disk.  With fair regularity daqd will die soon after it starts to write out the trend frames, producing the similar "empty blocks" messages.

NDS2 and the usual ports so that we can use optimus as a comsol server.

I did additional tests for the strange behavior of ASCD. ETMY, ETMX and ITMY were misaligned so that only light reflected by ITMX went into AS port. I had done similar measurement before with ITMY YAW varied.

Attachment 1 shows how ASDC level changed when ITMX PIT varied.

Attachment 2 shows how ASDC level changed when ITMX YAW varied.

Attachment 3 shows how the power of light measured by a power meter just after the AS view port varied when ITMX YAW varied.

Comparing 1 & 2, we can say that this behavior is not unique to YAW direction.

From 2 & 3, we can say something strange is happening inside the chamber.   

To check if the strange behavior of ASDC is caused by SR2/SR3 or not, I did the following measurement:

ASDC measures the power of the light reflected by ITMX. POXDC measures the power of the light reflected by ITMX and SRM successively. Then I varied the angle of ITMX in YAW direction and compared the behaviors of ASDC and POXDC.

The results are shown in Attachments 1-3.

As you can see in these figures, the strange up-and-down behavior appeared ONLY in ASDC. Therefore, the cause of this behavior exists between AS table and SRM (I had confirmed that the angle of SRM did not affect ASDC).

And this behavior is fringe-like, as can be seen in the figures (there seems to be 3 "peaks" and 2 "valleys"), so the cause could be interference between main path and not good AR reflection at a mirror after SRM before AS table (I suspect a mirror is flipped mistakenly).   

I took PR3 AR reflectivity and calculated PRG (PR3 is flipped and so AR surface is inside PRC).

As shown in attached figure, which shows AR specification of the LaserOptik mirror (PR3 is this mirror), AR reflectivity of PR3 is ~0.5 %. Since resonant light in PRC goes through AR surface of PR3 4 times per round trip, round trip loss due to this is ~2 %. Then I got

PRG = 7.8.    

Can I ask you to make a plot of the power recycling gain as a function of the average arm loss, indicating the current loss value?

Attached is the plot of relation between the average arm round trip loss and power recycling gain. 2 % loss due to PR3 AR reflection is taken into account.

Based on calibration measurement I have done (elog 11785, 11831), I updated calibration factors of oplevs on medm screen as follows. Not to change loop gain oplev servo, I also changed oplev servo gain.

C1:SUS-ETMX_OL_PIT_CALIB, C1:SUS-ETMX_OL_PIT_GAIN

(45.1,16) => (200,3.5)

C1:SUS-ETMX_OL_YAW_CALIB, C1:SUS-ETMX_OL_YAW_GAIN

(85.6,8) => (222,3.0) 

C1:SUS-ETMY_OL_PIT_CALIB, C1:SUS-ETMY_OL_PIT_GAIN

(26,-16) => (140,-3.0) 

C1:SUS-ETMY_OL_YAW_CALIB, C1:SUS-ETMY_OL_YAW_GAIN

(31,-21) => (143,-4.5) 

C1:SUS-ITMX_OL_PIT_CALIB, C1:SUS-ITMX_OL_PIT_GAIN

(110,8) => (122,7.2) 

C1:SUS-ITMX_OL_YAW_CALIB, C1:SUS-ITMX_OL_YAW_GAIN

(81,-11) => (147,-6) 

C1:SUS-ITMY_OL_PIT_CALIB, C1:SUS-ITMY_OL_PIT_GAIN

(159,15) => (239,10) 

C1:SUS-ITMY_OL_YAW_CALIB, C1:SUS-ITMY_OL_YAW_GAIN

(174,-21) => (226,-16) 

Summary:

After the discussions at the Wednesday meeting, I redid this measurement using a sinusoidal excitation summed at the error-point of the PDH servo as opposed to a DC offset. From the data I collected, I measured the actuator gain to be 2.43 +/- 0.04 MHz/V. This is almost half the value we expect, I'm not sure if I'm missing something obvious.

Details:

1. Attachment #1 is a sketch of the measurement setup and points at which signals are measured/calculated. Some important changes:
   • I am now using the channel C1:ALS-Y_ERR_MON_OUT to directly measure the input signal to the servo. In order to get the calibration constant for this channel from counts to volts, I simply hooked up the input to the channel to an oscilloscope and noted the amplitude of the signal seen on the scope in volts. The number I have used is 52uV/count (note that the signal to the ADC is amplified by a factor of 10 by an SR560).
   • I measured the transfer function from the input to the servo (marked "A" in the sketch) to the output of the Pomona box going to the laser PZT (marked "B" on the sketch) using an SR785 - see Attachment #2. This allowed me to convert the amplitude of excitation at A to an amplitude at B, which is what we need, as we want to measure C/B.
2. The measurement itself was done by locking the arms to IR, running ASS to maximize IR transmission, setting up a green beat note, and then measuring the two channels of interest with the excitation to the error-point on. 
3. I was initially trying to use time-series plots to measure these amplitudes - Koji suggested I use the Fourier domain instead, and so I took FFTs of the two channels we are interested in (using a flat-top window with 0.1 Hz BW) and estimated the RMS values at the frequency at which I had injected an excitation. Data+code used is in Attachment #3. In particular, I was integrating the PSD over 1Hz centered at the excitation frequency in order to calculate the RMS power at the excitation frequency - it could be that for C1:ALS-BEATY_FINE_PHASE_OUT_HZ, the spectral leakage into neighbouring bins is more significant than for C1:ALS-Y_ERR_MON_OUT (see Attachment #4)?
4. With the amplitudes thus obtained, I took the ratio C/B (see sketch) to determine the MHz/V actuator gain. I had injected excitations at 5 frequencies (916Hz, 933Hz, 977Hz, 1030Hz and 1067Hz, choses in relatively "quiet" parts of the spectrum of C1:ALS-Y_ERR_MON_OUT with no excitations), and the result reported is the average from these five measurements, while the error is the standard deviation in the 5 measurements.
5. Unrelated to this meaurement - while I had the SR560 hooked up to the input of the PDH box, I inverted the mixer output to the servo input, as I thought I could use this method to estimate the modulation depth. I did so by locking the Y arm green to the sideband TEM00 mode, and comparing the green transmission in this state to that when the Y arm is locked to a carrier TEM00 mode. I averaged C1:ALS-TRY_OUT for 10 seconds in 3 cases: (i) Carrier TEM00, (ii)sideband TEM00, and (iii) shutter closed - from this measurement, I estimate the modulation depth to be 0.209 +/- 0.006 (errors used to calculate the total error were the standard deviations of the measured transmission). 

Next steps:

1. Check that I have not missed out anything obvious in estimating the actuator gain - particularly the spectral leakage bit I mentioned above.
2. If this methodology and measurement is legitimate, repeat for the X end, and complete the noise budgeting for both AUX PDH loops.

Two companies are willing to  make the ruby grooves and the third one is still working on their quote.

The price is ~$100 each. The cost goes down 10% if we  order 50 instead of 30 pieces.

How many should we get ?

Summary:

I've attached the results from my measurements of the noise characteristics of the Y-end auxiliary PDH system.

Details:

The following spectra were measured, in the range DC-1MHz:

1. Analyzer noise floor (measured with input terminated)
2. Green REFL PD dark noise (measured with the Y-end green shutter closed)
3. Mixer noise (measured with input to mixer terminated - measured with an SR560 with a gain of 100)
4. Servo noise (measured with input to servo terminated)
5. In loop error signal (measured with green locked to Y-arm, LSC off - using monitor point on PDH box)
6. In loop control signal (measured with green locked to Y-arm, LSC off - using monitor point on PDH box)

In order to have good spectral resolution, the frequency range was divided into 5 subsections: DC-200Hz, 200Hz-3.4kHz, 3.4kHz-16.2kHz, 10kHz-100kHz, 100kHz-1MHz. The first three are measured using the SR785, while the last two ranges are measured with the Agilent network analyzer. The spectrum of the mixer output with its input terminated was quite close to the analyzer noise floor - hence, this was measured with an S560 preamplifier set to a gain of 100, and subsequently dividing the ASD by 100. To convert the Y-axis from V/rtHz to Hz/rtHz, I used two conversion factors: for the analyzer noise floor, PD dark noise, mixer noise and in-loop error signal, I made an Optickle simulation of a simple FP cavity (all parameters taken from the wiki optics page, except that I put in Yutaro's measured values for the arm loss and a modulation depth of 0.21 which I estimated as detailed here), and played around with the demodulation phase until I got an error signal that had the same qualitative shape as what I observed on an oscilloscope with the arms freely swinging (feedback to the laser PZT disabled). The number I finally used is 45.648 kHz/V (the main horns were 800mV peak-to-peak on an oscilloscope trace, results of the Optickle FP cavity simulation shown in Attachment #2 used to calibrate the X-axis). For the servo noise spectrum and in-loop control signal, I used the value of 2.43 MHz/V as determined here. 

I'm not sure what to make of the strong peaks in the mixer noise spectrum between ~60Hz and 10kHz - some of the more prominent peaks are 60Hz harmonics, but there are several peaks in between as well (these have been confusing me for some time now, they were present even when I made the measurement in this frequency range using the Agilent network analyzer. My plan is to repeat these measurements for the Xend now. 

Here's something to ponder.

Our online MCL feedforward uses perpendicular vertex T240 seismometer signals as input. When designing a feedforward filter, whether FIR Wiener or otherwise, we posit that the PSD of the best linear subtraction one can theoretically achieve is given by the coherence, via Psub = P(1-C). 

If we have more than one witness input, but they are completely uncorrelated, then this extends to Psub = P(1-C1)(1-C2). However, in reality, there are correlations between the witnesses, which would make this an overestimate of how much noise power can be subtracted. 

Now, I present the actual MCL situation. [According to Ignacio's ELOG (11584), the online performance is not far from this offline prediction]

Somehow, we are able to subtract much more noise at ~1Hz than the coherence would lead you to believe. One suspicion of mine is that the noise at 1Hz is quite nonstationary. Using median [C/P]SDs should help with this in principle, but the above was all done with medians, and using the mean is not much different.

Thinking back to one of the metrics that Eve and Koji were talking about this summer, (std(S)/mean(S), where S is the spectrogram of the signal) gives an answer of ~2.3 at that peak at 1.4Hz, which is definitely in the nonstationary regieme, but I don't have much intution into just how severe that value is.

So, what's the point of all this? We generally use coherence as a heuristic to judge whether we should bother attempting any noise subtraction in the first place, so I'm troubled by a circumstance in which there is much more subtraction to be had than coherence leads us to believe. I would like to come up with a way of predicting MISO subtraction results of nonstationary couplings more reliably.

After making sure that the upper UGFs were properly in place, I saved these settings to the SDF files. Thanks Yutaro!

To get C1PEM data back into the frames, I removed the new BLRMS blocks, recompiled, reinstalled, re-enabled it in daqd, restarted.

We still really want more headroom in our framebuilder situation. 

I noticed what I thought was excessive movement of the beam spot on ITMX and ETMX on the control room monitors, and when I checked the CDS FE status overview MEDM screen, I saw that c1scx and c1asx had crashed. I ssh-ed into c1iscex and restarted both models, and then restarted fb as well. However, the DAQ-DCO_C1SCX_STATUS indicator remains red even after restarting fb (see attached screenshot). I am not sure how to fix this so I am leaving it as is for now, and the X arm looks to have settled down.

I have added a new cron job in pcdev1 at CIT using the 40m shared account. This will run the /home/40m/DetectorChar/bin/cleanarchive script one minute past midnight on the first of every month. The script removes GWsumm archive files older than 1 month old.

c1sus and c1ioo were restarted. PMC locked.
 

[ericq,gautam]

Forgot to submit this yesterday...

While we were trying to get the X-arm locked to IR using MC2, frame-builder mysteriously crashed, necessitating us having to go down to the computer and perform a hard reboot (after having closed the PSL shutter and turning all the watchdogs to "shutdown"). All the models restarted by themselves, and everything seems back to normal now..