We installed the boot disk Keith provided into a new boot server called x1boot1. Thats to Keith's extensive prep work, the install was very quick. We moved the fast front end computer x1susey from the 2.6 boot server over to the new 3.0.8 server. Next tasks are to rebuild the models on this machine.

x1susey ~ # uname -a

Linux x1susey 3.0.8 #3 SMP Wed Mar 9 16:13:18 CST 2016 x86_64 Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz GenuineIntel GNU/Linux

We did a little bit of ASC work today.  

First, while Kiwamu was running a TCS test I started a script to automate phasing of the WFS.  It uses the lockin, first runs a servo to set the phase of the lockin demod, then servos to minimize some signal.  We have it set up right now to phase the refl WFS to minimize the PR2 pit signal in Q for both REFL 9 and 45, and to minimize the SRM pit signal in AS 36 Q.  There is some code for exciting DHARD, but we need to test amplitudes, phases and gains for this.  The current version of the script does its job although it is painfully slow, and is checked into the svn under asc/h1/scripts  THe resulting phases are in the attached screenshot. 

We saw that the instability in CHARD pit was becasue somehow the LP9 got turned on again, this is now off and CHARD seems fine.  

We tried powering up, were fine at 10 Watts.  We had an instability in PRC1 and PRC2 yaw at 13 Watts.  I reduced the Q on the complex zeros at 1.1 Hz for PRC2Y, which gives us slightly better phase and gain near the point where we seem to be unstable. Attached is a screenshot of the OLG measured with white noise at both 2 Watts and 10Watts, we might need to do a swept sign to get a good measurement around 1 Hz. 

After about 10 minutes at 12 Watts, we had the usual fluctuations in the recycling gain.  So the high bandwidth PRC2 loops haven't totally solved the problem. 

For the record, these are angle settings that give approximately good CO2 powers tonight, and the powers to aim for from Kiwamu's note:

We have twice had the rotation stage for CO2 Y go to an angle that was wrong by a lot (sending a few watts to the test mass for a few seconds).

I'm leaving the IFO locked at 10Watts. 

TITLE: 03/26 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC

STATE of H1: Planned Engineering

INCOMING OPERATOR: None

SHIFT SUMMARY:' Large tour group in the control room. Got a chance to really talk at length with some guests about my job and a little bit about various subsystems with a camera guided tour around the LVEA. Completed the last ofthe Sat Amp modifications. Did a little bit of re-locking for Sheila. She's going to be working on DRMI/TCS relationships for the remainder of the night.

LOG:

23:21 Chandra back from CP3 refill

00:15 Terra and Nutsinee to EY to do some signal injections

0:46 Terra and Nutsinee back

Michael, Krishna

This morning, we repositioned the EX_BRS-1 damper turn-table and restarted EX_BRS-1 software. The system worked normally and started to damp the balance but was unable to damp it all the way to small amplitudes (< ~50 counts/nrad). The reason seemed to be that the turn-table vibrations were driving up the beam-balance (see here). Looks like the foam sheets under the turn-table aren't effective at vibration damping any more. Later, Hugh handed us some soft polymer damping pads which we'll try out tomorrow. In the meantime, I've disabled the damper but the tilt data is available.

At EY, Carlos helped us to get the autocollimator software (in C#) working on the BRS-2 Beckhoff computer. We then proceeded with the vacuum can assembly and then aligned the autocollimator and adjusted the beam-balance position to get clear images on the CCD. By the end of the day, the angle data of the beam-balance was visible on the Beckhoff computer.

Plan for tomorrow:

1. Try out other vibration damping pads under the BRS-1 turn-table. Also try out some BRS-1 code changes to improve the software live-time, which crashes once in ~two weeks.

2. Continue BRS-2 vacuum can assembly. If possible, start pumping the vacuum can.

3. Hook up the SEI-Interfacing beckhoff modules.

This is a quick summary of today's TCS joy. I ran another differential lensing test today. I went to the other side of the differential lensing (CO2X goes higher power).

The highest cavity pole was 352 Hz in this test.

• CO2 X 500 mW --> 700 mW --> 500 mW
• CO2 Y 230 mW --> 80 mW --> 230 mW

This time, I also took many measurements of the intensity and frequency noise couplings periodically throughout the test using Evan's automated measurement script (20470). I will analyze and post them later. The second attachment is trend of some relevant channels.

In today's HAM6 vent meeting people asked if the shutter was working at all. It still works.

The first attachment shows that the shutter closed (green trace) last night when the IFO lost lock. Brown is the tirigger voltage, and the trigger threshold is 2V.

Red is the OMC DCPD, blue is the DC of ASAIR_A, vertical lines indicate where the shutter triggered.

Due to some strange timing problem of Ethercat signals transported to EPICS that was reported in alog 17445, you cannot compare the timing of the green and the brown trace with red and blue, so the trigger timing on this plot is just a guesstimate obtained as follows:

1. Trigger voltage (brown) is produced in ASC AS_C interface box by adding all four segments in analog, and the analog output is directly plugged into the shutter box. This voltage is just AS power, so is supposed to be proportional to ASAIR_A_LF (blue).
2. Before the IFO lost lock, trigger voltage was 0.12Volts, ASAIR_A_LF was about 1200 counts, so the equivalent trigger threshold for ASAIR_A_LF would be 20000 counts where the shutter should have triggered.

The second plot shows that the shutter has been firing all the time for recent 100 days.

One thing that is strange is that the LSC-ASAIR_C_LF_OUT_DQ is recorded on the frame at 16kHz but the input is grounded in the frontend. If my memory is correct Dan Hoak wanted to record the trigger voltage at 16kHz, and my guess is that ASAIR_C_LF was supposed to be used for this because it's not used, but nobody implemented it.

15:03 UTC Krishna and Michael to end X to look at BRS
15:04 UTC Jeff B. to LVEA near HAM6 to make clearance measurements for upcoming vent
15:23 UTC Neither DRMI or PRMI locking. Starting initial alignment.
15:26 UTC Filiberto and Manny to end Y to pull cables for BRS and BPG402 vacuum gauges
16:10 UTC Initial alignment done
16:15 UTC Sheila testing script
16:23 UTC Sheila done. Starting locking.
16:29 UTC Krishna and Michael done at end X. Krishna, Michael and Carlos to end Y.
16:44 UTC Jeff B. to LVEA to change dust monitor settings
Fire department here and gone
17:50 UTC Filiberto, Manny and Leslie back from end Y. Filiberto to mid Y to retrieve something for Dick.
18:05 UTC TJ adding bounce/roll guardian node
18:05 UTC Chandra and possibly Carlos to LVEA. Chandra to read vacuum pressures and disconnect pump cart.
18:32 UTC Filiberto back from mid Y
19:04 UTC Brynley looking for equipment in LVEA
19:25 UTC Brynley back
19:25 UTC Kiwamu running measurement
19:37 UTC Chandra done
20:33 UTC Carlos to end Y to setup remote desktop on BRS computer
21:04 UTC Terra and Brynley back from looking at end station electronics racks
22:21 UTC Chandra walking to CP3 to do overfill

TITLE: 03/25 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: Patrick
CURRENT ENVIRONMENT:
    Wind: 11mph Gusts, 5mph 5min avg
    Primary useism: 0.63 μm/s
    Secondary useism: 0.41 μm/s 
QUICK SUMMARY:

1530 - 1600 hrs. local -> To and from Y-mid 

Exhaust check valve bypass opened, LN2 at exhaust after 2:16 mins with LLCV bypass open 1/2 turn 

Next CP3 over-fill to be Sun. before 4:00 pm hrs. local 

I disconnected G32964 sm pump cart from the X-beam manifold and capped the 2nd valve with a blank 2-3/4" CFF and Cu gasket (small IP is still connected). The cart remains in that location, but free to use elsewhere. Note, there are no pressure gauges on it.

Pressures falling:

HAM 7/8:   8e-6 Torr (yesterday=2e-5 Torr)
HAM 9:      6e-6 Torr (yesterday=3e-5 Torr)
HAM 11/12:  5e-6 Torr (yesterday=4e-5 Torr)

Continue to monitor pressures to detect any potential outer oring leaks.

In preparation for designing ASC filters for increasing the laser power, I've looked at what we're actually using right now.  The filters that we are turning on during the "noise tunings" state is giving us 15dB of gain peaking in the pitch loop around 10 Hz.  Since the DHARD Yaw loop isn't so carefully tuned, it has much more phase margin, and so doesn't have egregious gain peaking.

I just noticed the noise tunings filter and its effect for the DHARD loops today. I didn't measure high enough frequencies to see the problem when I was measuring loops back in alog 25368.

Right now, I'm working on designing filters for DHARD Pit for power-up (almost done), designing filters for DHARD Yaw so that we have only a single UGF even at current powers (just starting), and doing similar work for the CHARD loops (not started).

We're working to get the calculations for the SUSpoint motion in the IFO basis installed
see ECR E1600028 ,
FRS issue 4694 : https://services.ligo-la.caltech.edu/FRS/show_bug.cgi?id=4694
and totally-out-of-date Tech doc T1500610 

here is an updated white-board drawing showing what we want to do.
It is weird because:
1) ISI models are not attached to the RFM network, so we need to pipe the data to another model first and PEM has lots of extra time
2) We really want 2 channels, but both are pretty slow, so Joe B made us a multiplexer to save RFM data.


-- email chain here so I don't lose it --


From: Jeff Kissel 
Subject: Re: SEI RFM channels from end to corner.
Date: March 24, 2016 at 4:34:30 PM PDT
To: David Barker 
Cc: Joseph Betzwieser , jim warner , Dave Barker , "Vern Sandberg" , Keith Thorne , Hugh Radkins , Joe Betzweiser , Rolf Bork , Brian Lantz 

Hey Dave,
	Yup, next Tuesday for removal.

Cheers,
Jeff Kissel


On Mar 24, 2016, at 3:42 PM, David Barker  wrote:

Hi Jeff,

yep, I’ll confirm with Daniel if we can get rid of the sender-with-no-receiver RFM channels.

Are we planning on giving this a try next Tuesday, and if so on one or both arms?

cheers,

Dave



On Mar 24, 2016, at 15:34, Jeff Kissel  wrote:

Hey Joe,
	Thanks for putting this together. 

Hey Brian,
 	Are we definitely going this MUX route to save on transmission channels?

Hey Dave,
	Side statement: we should also clean up all of the RFM channels you’ve identified as unused here

in the end station ALS, ISC, and corner station OAF models too.

Cheers,
Jeff Kissel
Controls Engineer


On Mar 24, 2016, at 2:06 PM, Joseph Betzwieser  wrote:

Hi,

Just want to provide an update on the MUX code.  In the prior e-mail I had indicated I had not done full testing of all functions.  I have now done so on the LLO test stand, and after some minor copy/paste bug fixes in the 4 and 8 channel versions, all currently coded functions are working as expected.

This includes functions for combing 2, 4, and 8 channels together and then demuxing them at the end, assuming the same data rate throughout.  In addition, there is a demux function for a 2 channel input which can handle a 4x data rate change from slower to faster (i.e. 4 kHz to 16 kHz).

If/When needs change, its fairly simple to copy the current functions and change them to different data rates or number of channels.
Again, links to code are at:

https://redoubt.ligo-wa.caltech.edu/websvn/filedetails.php?repname=cds_user_apps&path=%2Ftrunk%2Fcds%2Fcommon%2Fsrc%2FLOW_FREQ_MUX.c

https://redoubt.ligo-wa.caltech.edu/websvn/filedetails.php?repname=cds_user_apps&path=%2Ftrunk%2Fcds%2Fcommon%2Fsrc%2FLOW_FREQ_DEMUX.c

I am to use these in the code we are planning to push next Tuesday for the ISI RFM communication to the corner.

Cheers,
Joe


On Wed, Mar 23, 2016 at 1:03 PM, Joseph Betzwieser  wrote:
I forgot to attach the pdf.

Here it is.

Joe

On Wed, Mar 23, 2016 at 12:22 PM, Joseph Betzwieser  wrote:
Hi,

Based on the discussions I had with Brian Lantz, I've put together a very simple diagram this morning describing what I think is what we should do for the RFM communication.  I don't remember the exact channel names (and there may have only been 1 channel going from the corner to the end), but I think the attached pdf is generally correct.  At the vary least its a discussion starting point.

I'm working under the assumption that the IPC problems are on the reading end (i.e. each RFM read takes 1-2 microseconds), so that sending is not an issue.  Given Brian Lantz wants to read out channels into OAF, that read in can't be avoided, although we can condense it down to 1 channel per end via Muxing.

I've written a number of user C functions in /opt/rtcds/userapps/release/cds/common/src/LOW_FREQ_MUX.c and LOW_FREQ_DEMUX.c

Links to code are:

https://redoubt.ligo-wa.caltech.edu/websvn/filedetails.php?repname=cds_user_apps&path=%2Ftrunk%2Fcds%2Fcommon%2Fsrc%2FLOW_FREQ_MUX.c

https://redoubt.ligo-wa.caltech.edu/websvn/filedetails.php?repname=cds_user_apps&path=%2Ftrunk%2Fcds%2Fcommon%2Fsrc%2FLOW_FREQ_DEMUX.c

The idea is you take data from 2 different channels, one on an even cycle, then one on the odd cycle.  In this way you can transmit two 8 kHz channels over one 16 kHz channel, for example.  

I've tested some but not all of these functions, so the principle seems to work fine.  You will need to add low pass filters before and after to clean up the data transmitted.

Joe

On Mar 22, 2016 6:49 PM, "David Barker"  wrote:
Hi Brian,

sounds good, let’s plan on trying this on H1 next Tuesday and discuss the details tomorrow.

Dave


> On Mar 22, 2016, at 16:41, Brian Thomas Lantz  wrote:
>
> Dave,
> I’d like to install that RFM sender into Hanford next Tuesday so we can get the suspension point motion from each end to the corner at LHO.
> Can we discuss briefly at the CDS call on Wed?
> Joe B has a suggestion for plumbing, since the SEI models are not attached to the RFM network.
>
> Thanks
> -Brian
>

Preliminary conclusion: the DARM cavity pole seems to be a strong function of the differential lensing. I was able to change it from 357 Hz to 220 Hz (!!!)

I will post more details tomorrow.

The cavity pole measurement is not valid until t=80 min. and also in the time band approximately between 230 and 250 min. The interferometer was locked on the DC readout with ASC fully engaged, The PSL power stayed at 2 W throughout the measurement.

Learning this behavior, I would like to do the followings in the next test:

• Go further to the positive side of the differential lensing (ITMX's lensing goes larger than ITMY) to see if we can recover a high cavity pole.
• Search for optimum points for frequency and intensity noise couplings.

By the way the second attachment is trend of various channels during the test.

Dave B rebooted the H1HWSMSR machine yesterday. Unfortunately, an investigation of the HWSX images shows that they are still glitching for an unknown reason.