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
>

BRS installation continues at end Y
Possible TCS and ASC work over the weekend
Landscapers will be spraying for weeds over the weekend
There will be a preliminary planning meeting at 10 am for the upcoming vent

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.

Kiwamu, Nutsinee

------------------------------------------------------------------------------------------------------------------------------

Code added to line 115 - line 136

First test checks if the number of "peaks" measured by the HWS code makes sense. If below 800 -- not enough return SLED beam. If above 4096 (12 bit), something's wrong.

Second test checks if HWS code time stamp is correct compared to the actual GPS time. If |dt| > 15 seconds then the code must have stopped running.

------------------------------------------------------------------------------------------------------------------------------

@SYSDIAG.register_test
def TCS_HWS():
    #Make sure # of pixels are good
    pkcnts_X = ezca['TCS-ITMX_HWS_TOP100_PV']
    pkcnts_Y = ezca['TCS-ITMY_HWS_TOP100_PV']
    #If below 800 -- not enough return SLED light
    #If above 4096 -- above theoretical number (12 bit) -- something's wrong
    if not (pkcnts_X > 800) and (pkcnts_X < 4096):
       yield "HWSX Peak Counts BAD!!"
    if not (pkcnts_Y > 800) and (pkcnts_Y < 4096):
       yield "HWSY Peak Counts BAD!!"
    #Check if HWS GPS time agrees with current GPS time
    a = subprocess.Popen(['tconvert','now'], stdout = subprocess.PIPE)
    gpstime, err = a.communicate()
    gpsfloat = float(gpstime.strip(' '))
    #Fetch HWS GPS time
    liveGPS_X = ezca['TCS-ITMX_HWS_LIVE_ACQUISITION_GPSTIME']
    liveGPS_Y = ezca['TCS-ITMY_HWS_LIVE_ACQUISITION_GPSTIME']
    if np.abs(gpsfloat - liveGPS_X) > 15 :
    yield "HWSX Code Stopped Running"
    if np.abs(gpsfloat - liveGPS_Y) > 15:
    yield "HWSY Code Stopped Running"
 

Michael, Hugh, Krishna

A lot of progress was made with the installation of BRS-2 today. In the morning, we cleared out a space on the VEA floor. We had to slightly reposition the SEI ground seismometer (STS2) and the PEM Guralp seismometer. We then cleaned the BRS-2 vacuum can, foam box and other parts and moved them in. Upon opening the vacuum can, we noticed that the epoxy (TorrSeal) on one of the capacitor plates had come off, likely during the drive. We found a suitable alternative (Loctite 1c) and reattached the capacitor plate.

We the proceeded with the assembly. The beam-balance was pulled out, the flexures were carefully attached and the beam-balance was then reinserted into the can and suspended from the flexures. We did a crude adjustment of the horizontal center of mass. The vacuum can was then partially closed up and the autocollimator attached to it. We then had to realign the optics to get the reflections from the reference mirror and the main mirror algined well. Tomorrow we will continue with autocollimator adjustments to get good reflection patterns on the CCD.

In the meantime, Jim B and Carlos installed the BRS-2 Beckhoff computer at End Y. Also, Filiberto and Peter laid out the GiGE, Ethercat and Fiber-Optic (For the autocollimator light source) cables going from the VEA to the computer room.

Plan for tomorrow:

1. Get the C# code to read the CCD data and start measuring the tilt signal. At this point, the instrument is still in air, so will have excess noise and drifts.

2. Hook up the electronics for the capacitive control and the DACs for writing out the signals. Once the cables to go from these to the SEI Frontends is complete, the tilt data will be accessible to SEI.

3. Close up the rest of the vacuum can.

Added 686 channels. Removed 526 channels. See attached.
All channels are now connected.

14:59 UTC Karen and Christina to end Y
15:07 UTC Jeff B. to LVEA to check on dust monitors and cleanrooms
15:13 UTC Corey checking chillers
15:17 UTC Corey done
15:18 UTC Filiberto installing electronics outside of ISCT1
15:33 UTC Not making it past CHECK_IR. Starting initial alignment.
15:38 UTC Y arm intermittently losing lock on green. Going to 45 Mhz blends on both DOFs at end X and end Y per high microseisem.
15:42 UTC John and Chandra to LVEA to work on vacuum
15:42 UTC Filiberto done
15:48 UTC Hugh, Krishna and Michael starting BRS install at end Y, opening rollup doors (WP 5789)
15:53 UTC Adjusting PR3 to improve COMM beatnote. Y arm still intermittently losing lock on green.
15:55 UTC Jeff B. done
15:59 UTC Can't seem to improve COMM beatnote above 3.8 with PR3. Moving on.
16:24 UTC Done initial alignment.
16:31 UTC Y arm VCO is hitting low limit?
16:40 UTC Jeff B. to HAM6 and beer garden
16:42 UTC Setting end Y ISI blends back to 90 mHz per people walking around in VEA
16:49 UTC Jeff B. done
17:03 UTC Jeff B. to end X and end Y, briefly in VEA at each
17:09 UTC John and Chandra done
17:16 UTC Truck to pickup item from Christina at gate, directed to LSB
17:16 UTC Jason to optics lab to look for part
17:36 UTC Jason back
17:48 UTC Jeff B. back
17:55 UTC Betsy to cleaning area
17:56 UTC Nutsinee to LVEA to look in cabinets
18:11 UTC Nutsinee done
18:13 UTC Terra and Nutsinee to end Y
18:24 UTC Filiberto to end Y to check on cabling requirements
18:41 UTC Filiberto, Hugh, Krishna and Michael back
18:43 UTC Putting IFO_LOCK to down
18:53 UTC Terra and Nutsinee back, did nothing
19:07 UTC Dave, Jim and Carlos to end Y to install BRS computer
19:38 UTC DAQ restart
19:39 UTC Filiberto to end Y to pull cables for BRS
20:14 UTC Filiberto and Peter to end Y
21:58 UTC Kiwamu attempting to lock
21:59 UTC Brynley to electronics bay to look at LEDs
22:05 UTC Brynley back
22:40 UTC Carlos changing vlan for DMT switch in MSR
22:49 UTC Dave shutting down fw0
22:55 UTC Kiwamu giving up on locking. Will lock simple Michelson to measure contrast defect.

Jim B., Carlos, Dave:
Installation of BRS computer at end Y
New PI model on LSC frontend, h1omcpi
Updates to susitmpi, susetmxpi, susetmypi
DAQ restart to add h1omcpi model

Daniel, Terra, Jim, Dave WP5790

A new model was installed on the final core of the h1lsc0 front end machine. Its name is h1omcpi, dcuid=9, rate = 64kHz.

A PI_MASTER.mdl file change was also made.

The new h1omcpi model was installed and started. The h1susitmpi, h1susetmxpi and h1susetmypi models were rebuild and restarted. The DAQ was restarted.

Unfortunately this precipitated an instability in h1fw0 which we are investigating.

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

Following the grouting of the HAM5&6 HEPI piers, and in light of JeffK's work untangling my designs (in LHO alog 26002), I wanted to review the design of the HAM 4/5 S0-1 feedforward. To do this I took a new set of measurements for HAM's 4 and 5 so I could see how similar the different transfer functions were. The measurements I took were: the transmissibility from the FF L4Cs on St0 to the St1 GS13s with the ISI in both damped and isolated states, and the actuator to GS13 tfs in both the isolated and damped states. I got all 24 measurments for HAM4, but I only got the all of the Z measurements for HAM5, so I looked at that dof filter design.

Jumping straight to the punchline (first plot, calibrated ground and GS13 spectra for HAM4) I have a new Z FF filter that does a lot better and makes more sense, installed on HAMs 4&5, and I'm working on similar redesigns for the remaining dofs. The two traces to really look at are brown and light blue, the GS13 measured displacement with the old and new FF filters. Compared to dark blue (FF off), the old FF filter mostly improved motion between 20 and 30 hz and only worked well with a gain of .5, something I couldn't explain when I installed it. The new filter works better from a few hz to almost 60 hz.

The second plot is the transmissibilties for HAM 4 (blue) and 5 (green) in both damped (solid) and isolated(dashed) states. The damped states are very similar, though I'm not sure why there is a gain difference. The Isolated tf's are more different, but probably it's probably due to some differences in the feedback loops, I should probably take a look at that.

The third plot is the stiffness tf, color key is the same, HAM 4 (blue) and 5 (green) in both damped (solid) and isolated(dashed) states. Again the damped states are similar, the isolated measurments are a little more different. Importantly, the differences are consistent with the transmissibility measurements, which means the filter design ends up looking the same between the chambers, as shown in my next plot.

The fourth plot is the ideal filter design for HAMs 4&5. This is done following the process outlined in JeffK's 26002 alog, where the ideal filter is roughly speaking the transmissibility over the stiffness. One of the other things I wanted to look at was  what state the ISI needed to be in when designing the filter, as I thought that I had found in the past that the ISI needed to be isolated for both the transmissibility measurment and the stiffness measurement. It looks like it doesn't much matter as far as the final filter design is concerned. The isolated design is a little different at a few hz, though it's hard to see because the data is crappy. The data is much cleaner with the damped transfer functions. UGF's for this loop are on the order of 35hz, so feedback is not doing a lot at 10 hz, that probably explains why the isolated and damped filters end up looking the same, and why they differ more at lower frequency. Also nice to see that the filters for HAM 4 & 5 should be the same, regardless of the either ISI's state. The cleaner data for the damped configuration is a strong argument for using that configuration for my future redesigns.

The fifth plot is a comparison of the HAM4 ideal filters(blue and green), the old filter (red), and the new filter (black). You can see that the black line matches green and blue very well between 10 and ~40 hz, but red only matches well in phase right at about 25 hz. This explains why the old filter only did well at 20-30hz. The gain mismatch at 25hz also explains why the old filter needed a gain of .5 to work. The new filter works well from a few hz up to almost 60 hz, with a gain of 1.

I still have my data and the script that I used for the orginal design, Jeff rehashes it in his log. I still don't understand the differences, what I screwed up originally. I think the approach used both times was the same, but I clearly did something wrong the first time around. I'm in the process of repeating this for the other dofs.

The last plot is HAM5, comparing the old FF filter to the new. Red, blue green are with the new filter, brown, pink and light blue are with the old filter.