Displaying reports 46461-46480 of 88171.Go to page Start 2320 2321 2322 2323 2324 2325 2326 2327 2328 End
Reports until 14:06, Wednesday 18 July 2018
H1 AOS
craig.cahillane@LIGO.ORG - posted 14:06, Wednesday 18 July 2018 - last comment - 18:06, Wednesday 18 July 2018(42957)
ALS X PDH and PLL Spectra
I went down to X end and repeated the ALS measurements done for Y end.

ALS X green visibility is 30%.  Free swinging PDH peaks give ~750 mVpp demodulated reflection response.  
With a cavity pole of 275 Hz, we roughly calibrated the PDH error signal with 2*cavityPole/PDHvolts = 733 Hz/V.

Plot 1
PLL UGF is 27 kHz
PDH UGH is 8 kHz

Plot 2
PLL error spectrum

Plot 3
PDH error spectrum

Plot 4
Estimated transmission frequency noise from PDH error spectrum with arm pole applied.
In loop ALS X Transmission Frequency Noise RMS is 1 Hz.

Now that ALS COMM is locking, we will get an out-of-loop measurement of ALS frequency noise soon.
Images attached to this report
Comments related to this report
craig.cahillane@LIGO.ORG - 18:06, Wednesday 18 July 2018 (42963)
Took a quick look at ALS COMM PLL output to estimate what kind of frequency noise we're seeing.

The channel H1:ALS-C_COMM_PLL_CTRL_OUT_DQ is already calibrated into micrometers.  I uncalibrated it back to Hz for the plot below.

ALS COMM RMS = 25.8 Hz = 183 pm
Images attached to this comment
Non-image files attached to this comment
H1 CDS
david.barker@LIGO.ORG - posted 13:34, Wednesday 18 July 2018 - last comment - 10:37, Thursday 19 July 2018(42955)
model build environment upgraded to RCG-3.2.2

I have installed advLigoRTS-3.2.3 and created a corresponding build area for this release ( /opt/rtcds/lho/h1/rtbuild-3.2.3 ) I have made the necessary release symbolic link changes.

I compiled the SUS QUAD models using RCG-3.2.3 in preparation for their upgrade to permit additional violin mode damping filters to be added.

Comments related to this report
david.barker@LIGO.ORG - 10:37, Thursday 19 July 2018 (42974)

typo: title should read RCG-3.2.3

H1 PSL (PSL)
peter.king@LIGO.ORG - posted 12:22, Wednesday 18 July 2018 (42953)
ISS tuning
Did some characterisation measurements of the first loop power stabilisation.  All measurements
were taken with the reference level set to -2.00.

    SCRN0001.jpg shows the free running and stabilised power noise as measured with an out of
loop photodiode.  A large peak appears around 70 kHz to 100 kHz when the integrator is engaged
(SCRN0002.jpg).  These measurements were taken with the offset slider set to 10.00.  Clearly
there are a number of peaks that should not be there.  Not sure what they are caused by at the
moment but they may have something to do with the pre-modecleaner.

    SCRN0003.jpg shows the free running and suppressed power noise for lower frequencies when
the gain slider is at 15 dB.  Increasing the gain slider to 18 dB causes the loop to rail.  This
is partly alleviated by reducing the offset to 8.00.

    SCRN0004.jpg and SCRN0005.jpg show the open loop transfer function with the integrator on
and off, when the gain slider is set to 13 dB and an offset of 8.00.

    In addition, it seems that the number of 60 Hz related peaks in the power noise spectrum has
been reduced by the replacement of the AOM driver power cord (alog 42939).

    pn.png shows the power noise from 100 kHz down to 10 Hz.

    The power stabilisation works.  Need to track down the source of the peaks in the spectrum.
Images attached to this report
LHO VE
kyle.ryan@LIGO.ORG - posted 11:55, Wednesday 18 July 2018 (42954)
~1130 hrs. local ->Spun down X-end turbo and scroll (left energized for rotor levitation until fully stopped - hours more)

Also, shut off the X-end instrument air compressors

H1 PSL
jeffrey.bartlett@LIGO.ORG - posted 09:02, Wednesday 18 July 2018 (42952)
PSL Chiller Checks
   Both chiller water levels are OK. No water added. The filters remain the same, as well. 

   The diode chiller filter is clean and clear. The crystal chiller filter is slightly yellowed, perhaps due to instillation of the bypass valve in the chiller room. No change in color since last inspection.  

   Closing FAMIS task #7270.   
H1 General
jeffrey.bartlett@LIGO.ORG - posted 07:58, Wednesday 18 July 2018 (42951)
Ops Day Shift Transition
Ops Shift Transition: 07/18/2018, Day Shift 15:00 – 23:00 (08:00 -16:00) - UTC (PT)
State of H1: Unlocked for commissioning 
Intent Bit: Commissioning
Weather: RED Flag warning in place until 20:00. Hot and windy today – Temps to 100f plus with winds a Light to Moderate breeze. Gust into the 20s.    
Primary 0.03 – 0.1Hz:
Secondary 0.1 – 0.3Hz:
Outgoing Operator: N/A
Quick Summary: Alignment and mode matching on going in PSL enclosure. Arms are open for commissioning. LVEA is Laser Hazard.
H1 AOS (DetChar)
ronaldas.macas@LIGO.ORG - posted 04:07, Wednesday 18 July 2018 (42950)
Final live noise budget update

Sheila, Ronaldas

The code is ready to use for commissioning/O3, just need to update transfer functions/constants that have changed since O2. Final example plots for noise budget of 4th of July, 2017, are attached.

G1801257 contains:
1) various plots
2) journal club presentation
3) technical document

Code can be found on git.ligo.org

Things that have been added/changed during the fellowship:
1) restructured noise budget software used for noise budget estimation at Hanford
2) updated and/or added new noises to the noise budget
    a) residual gas noise
    b) osem noise
    c) noise projection from bullseye sensor coherence
    d) quadratic response of DC readout
    e) actuator DAC noise
    f) sensing noise calibration

aLog references: 418594194942264

If there are any questions, let me (ronaldas.macas@ligo.org) or Sheila know. 
 

Images attached to this report
H1 ISC (ISC)
craig.cahillane@LIGO.ORG - posted 19:39, Tuesday 17 July 2018 (42948)
RefCav FSS Transfer Functions
Today we looked at Hanford's RefCav FSS OLG.

Results

The RefCav UGF is ~300 kHz.  The raw data is posted in OLGTF.txt, but the magnitude has to be scaled up by 9.65 dB to account for the inverting op amp between IN1 and IN2, as shown in the LHO TTFSS box schematic (DCC S1107453).

Unlike Livingston, our FSS is still important for our frequency noise suppression.  More to come on the frequency noise budget for the IMC and RefCav.

The TP10 measurement is also posted.  This is a measurement taken from TEST2 to TP10 in the TTFSS schematic, essentially probing the Fast (PZT) path, hitting the common gain and fast gain sliders, two poles, and a notch at 242 kHz.  

We hope to get a proper crossover frequency measurement soon.
Non-image files attached to this report
H1 ISC
sheila.dwyer@LIGO.ORG - posted 19:25, Tuesday 17 July 2018 (42949)
green locking + alignment progress

Jenne, Sheila, Craig, Georgia, Keita

Both green arms are locking well now.  

The main problem we were having with the Y arm yesterday seems to have been that the second boost was not engaged.  Once this was engaged we could run the WFS, we added 50 dB of gain to DOF2 for the Yarm.  We were able to engage the slow feedback for both arms with no problems now that the suspension bug is fixed. The only thing we still need to do for the green arm alignment is set the camera offsets since the cameras have been moved. 

Craig got measurements of the ugfs and spectra for the X arm green locking which he will post. 

We were able to lock + align the input beam to the X arm with no problems, MICH alignment was also easy. After these two steps the Y arm locked with IR and was well aligned.  

 

H1 ISC
georgia.mansell@LIGO.ORG - posted 17:38, Tuesday 17 July 2018 (42946)
ALS Y Green WFS phasing tweaked up

[Sheila, Georgia]

After Ed/Corey/Sheila locked the y-arm in green, Sheila and I went out to end-y to check the phasing of the green WFS (A and B), as mentioned in the to-do list in alog-42925.

We injected a 31 Hz sine wave from the SR785 into the excitation port of the common-ALS-laser-to-Y-arm PDH servo board. While the arm was locked we saw this signal in I and Q quadratures, and tuned the phasing quadrant-by-quadrant to minimise the signal in Q. Both sensors did not require a dramatic re-phasing, i.e. they were still close to optimal.

We have left the SR785 hooked up to the excitation channel for now.

LHO General
corey.gray@LIGO.ORG - posted 16:20, Tuesday 17 July 2018 (42927)
DAY Operator Summary

TITLE: 07/17 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY:

LOG:

H1 SEI (CDS, GRD)
thomas.shaffer@LIGO.ORG - posted 16:03, Tuesday 17 July 2018 - last comment - 13:50, Friday 20 July 2018(42944)
HAM2/3 GS13 Gain Switching Investigation

WP7713

History: HAM2 and HAM3 cannot switch the GS13s to high gain via Guardian without a trip of the chamber. All other HAM chambers, except HAM1 of course, do not have this issue. A python script that is called from the "commands" medm screen is a bit more reliable to do this switching, but still not robust. A few years back Hugh and I had a look into this and noted that Guardian would take a much longer time to do the actual switching (alog 24130). The script back then was a perl script but has since been converted and preforms the same.

Current: Today I started by getting more data to maybe get some clues at to what is going on. I started out by bringing the ISI_HAM3 Guardian to Isolated with the GS13 gain switching turned on. I recorded times and the outcome. As this would trip, it would automatically bring back the gains and then I would do the whole process again but switch the GS13 gains with the python script. Below is a table of most of the times I ran through the states and switched with Guardian or with python script (unfortunately, there are a few tests that I did not record due to having too many windows open and getting lost or distracted by other control room activities):

HAM3

Method and direction UTC Time Length of Transition (sec) Outcome Notes
GRD to High gain 16:10:20 1.56 Tripped  
GRD to Low gain 16:10:30 1.52 Trip recovery  
Script to High 16:15:52 0.26 Success  
Script to Low 16:16:44 0.26 Tripped  
GRD to High 18:28:51 1.53 Tripped Added wait=False kwarg, no change in time, seemed like it didn't work.
GRD to Low 18:29:00 1.54 Trip recovery Still with wait=False, but changed back after this.
Script to High 18:35:00 0.26 Success  

HAM4

Method and direction UTC Time Length of Transition (sec) Outcome Notes
GRD to Low 16:54:15 1.54 Success  
GRD to High 16:56:48 1.52 Success  
Script to Low 16:58:10 0.26 Success  
Script to High 16:59:00 0.26 Success  

So though Guardian is obviously unreliable, the script also does not work perfectly for HAM3. the times that the HAM3 and HAM4 Guardian nodes take to make the switch is the same, so I don't see the longer time being the problem.

What GRD does different

The python script uses the epics caput method to quickly loop through the 6 degrees of freedom and places the mask values in the appropriate channel to turn on or off FM 4 & 5. Guardian similarly loops through each dof, but for each one it will check that the value was actually written before moving on to the next dof. In particular it uses the LIGOFilterManager class to do the switching, which has the key word (optional) argument to not wait for a write confirmation before moving on. When I changed this kwarg to be wait=False, I did not see a change. Perhaps if I can figure out why the kwarg isn't working, then it may be a solution to the longer times, but it still doesn't solve the original issue.

Other items worth noting

Conclusion

Inconclusive so far, more investigation will be needed.

Comments related to this report
jeffrey.kissel@LIGO.ORG - 16:42, Tuesday 17 July 2018 (42945)CDS, GRD, SEI
This investigation is associated with FRS Ticket 11049.
jim.warner@LIGO.ORG - 15:53, Thursday 19 July 2018 (42979)

I wrote a matlab script to get 10 second timeseries for the suggestion BIO channels for all of the time TJ listed (the timeseries start 5 seconds before the times on TJ's table, the longest transitions are ~1.5 seconds), they don't show anything, I'm attaching a plot for one of the HAM4 times. Maybe there's some other channels that show what the BIO is doing? 

I was off a day, helps if you look at the right data. With the right dates, HAM3 guardian switching the GS13s to high gain looks a bit different than HAM4. HAM4 (first image) is nice and regular between each switch, HAM3 (second image) the bio switches are not so regular. Not sure what this means, other than HAM3 bio behavior is different than HAM4. Huh.

Images attached to this comment
jim.warner@LIGO.ORG - 10:30, Friday 20 July 2018 (42992)

Adding plots of HAM3 & HAM4 guardian switching gs13 gains to high including the watchdog state. HAM3 trips in the middle of the long pause after switching the gain the H2 seismometer, before switching the H3 gain. The HAM4 switches are closer together, more regular and don't trip the ISI.

Images attached to this comment
hugh.radkins@LIGO.ORG - 11:16, Friday 20 July 2018 (42993)

Richard just told me that the Out channel is the request from the BIO Out to the interface chassis and the BIO In is the response back from the chassis after making the switch.  SO the BIO Out should lead the BIO In, a little.

jim.warner@LIGO.ORG - 13:50, Friday 20 July 2018 (42998)

Adding plots of the python script gain switch for both chambers. Tried to make these plots a little more readable, and included the whitening BO channel. For the script based switching, it seems like HAM3 & HAM4 look much more similar than the guardian switching. First two plots are HAM3 & HAM4 using the script to put the gs13s in high gain without tripping. The last plot shows HAM3 switch to low, which tripped the ISI.

One weird thing not immediately obvious on these plots is that when the script is used to switch the gains to high on both chambers, H1 is switched first, then all the other gs13s. But when the script is used to switch the gains to low, H1 & H2 are switched, then the remaining seismometers.

Images attached to this comment
H1 SUS
jenne.driggers@LIGO.ORG - posted 15:51, Tuesday 17 July 2018 - last comment - 16:01, Tuesday 17 July 2018(42942)
L2, L3 stages of quads not actuating after reboots today
I am finding that I am unable to actuate the L2 or L3 stages of ITMX or ETMX.  I have not yet checked the Yarm quads as others are using them right now.  But, all 4 quad models were rebooted today as a fix for ticket https://services.ligo-la.caltech.edu/FRS/show_bug.cgi?id=11066.  

The BIO settings look fine.  Putting an offset in one of the coil output filter banks sends signal through the MASTER_OUT channel to the DAC, and from the IOP CDS screen, it looks like the DAC is in fact sending the signal out.  But, the current monitors don't see a response, and the optic doesn't actually move.  I can actuate on the upper 2 stages of the quads just fine.

This has been filed as FRS 11099.  DaveB isn't sure what could cause this, so JeffK is currently in the CER to see if there is anything obviously wrong with the ITM coil drivers. 

Comments related to this report
jenne.driggers@LIGO.ORG - 16:01, Tuesday 17 July 2018 (42943)

Just kidding.  After looking at it again with Jeff, there isn't a problem.  The current monitor responses are just really a lot smaller than I had thought I remembered, and 21Hz is too high a frequency to see in the optical levers, even if I drive near max range on the lowest stage of the ETM.

Anyhow, not a fault.

H1 AOS (SEI)
michael.ross@LIGO.ORG - posted 15:04, Tuesday 17 July 2018 (42941)
BRS Software Changes

While here for the day, I added email alerts to both BRSs within the C# code to help diagnose the rare crashes that we've seen (FRS 11052). Additionally, I removed a DC offset for large amplitude damping in the BRS TwinCAT damping code that we determined to be not necessary.

H1 SUS (SUS)
corey.gray@LIGO.ORG - posted 15:03, Tuesday 17 July 2018 (42936)
ETMx/y Charge Measurements Attempt...

(Corey G, Jeff K, Georgia M) 

During Maintenance Day, I went through the procedure for the charge measurement.  Jeff had to fix the python scripts (due to some recent name changes for binary IO, I believe).  I then ran the measurement for both ETMs at the same time.  Data for the files are at:

I had trouble getting the ESD_Analyse matlab file to run.  Georgia was looking into this to see if the data is good.  

Here are the original Slider Values (which I returned to after the measurement):

ETMx:

ETMy:

 

H1 ISC (ISC)
nolan.king@LIGO.ORG - posted 14:34, Tuesday 17 July 2018 (42940)
ISC Rack 1 - 71 MHz BALUN diagnosis/replacement.
Nolan, Marc, Dick

Replaced ISC Rack R1 71 MHz balun with modified balun. The first plot reflects the baseline noise measured using the previously used test lead, and the noise spectrum after replacement. Signal strength is attenuated by aprx 44 dBm. The second plot reflects the phase shift through the replacement balun. At 71 MHz the change in phase shift is apx 23 deg phase shift. An N-SMA adapter has replaced the original male N-type connector, and a copper end plate has replaced the PCB end cap. The transformer is moved and a UMCC connector is placed on the board. A coax (RG-174) SMA-UMCC line replaces the unshielded lines originally in the Balun. Capacitors are added to the female end of the balun (apx 300 uF). Attachments 3 and 4 reflect the noise change as measured from an antenna placed in the rack ( apx 10 dB change in radiated Noise). For pictures of modified balun and test lead refer to ISC Rack 1 - 118 MHz BALUN Alog entry. 
Images attached to this report
H1 PSL (PSL)
peter.king@LIGO.ORG - posted 12:46, Tuesday 17 July 2018 - last comment - 12:51, Tuesday 17 July 2018(42938)
ISS AOM driver power
With the ISS AOM driver disconnected, the output of the 24V power strip was -25.39V and
+23.83V.  The driver only uses the +24V power form.  A new, larger gauge power cable was
pulled in.  +24.8V was measured at the business end of the cable.



  Fil / Richard / Peter
Comments related to this report
peter.king@LIGO.ORG - 12:51, Tuesday 17 July 2018 (42939)
Turned on the AOM driver and aligned the AOM.  Saw the diffracted beam.  Took some
diffracted power versus applied offset slider data.  At the moment we are diffracting
~1.6W.

    The ISS still needs a reasonable amount of tweaking and adjustment.





  Jason / Peter
H1 AOS
daniel.vander-hyde@LIGO.ORG - posted 10:17, Tuesday 17 July 2018 - last comment - 18:23, Tuesday 17 July 2018(42932)
CO2X on-table alignment

TVo, Danny

Currently CO2X is not very well aligned on the FLIR as well as the central and annular masks before it (see attached images). TVo and I plan on centering this soon. Hopefully this helps center CO2X on the CP as well. 

Images attached to this report
Comments related to this report
thomas.vo@LIGO.ORG - 18:23, Tuesday 17 July 2018 (42947)

We aligned the CO2X beam onto the FLIR but the central and annular masks still need to be aligned to the beam. 

Images attached to this comment
Displaying reports 46461-46480 of 88171.Go to page Start 2320 2321 2322 2323 2324 2325 2326 2327 2328 End