Displaying reports 56281-56300 of 83529.Go to page Start 2811 2812 2813 2814 2815 2816 2817 2818 2819 End
Reports until 13:03, Tuesday 28 June 2016
H1 SUS (CDS, SUS)
vernon.sandberg@LIGO.ORG - posted 13:03, Tuesday 28 June 2016 - last comment - 14:23, Tuesday 28 June 2016(28013)
SR2 Top OSEM/Satellite Box Noise Hunting

SR2 Top Satellite Box OSEM Photodiode Oscilloscope Traces

The oscilloscope traces attached show a comparison of the time domain signals between SR2 Top OSEM Photodiode A and SR2 OSEM Photodiode B, as seen from connector J2 "Analog Rack". (We use the satellite box signal and connector naming conventions as shown on D1400098-v1.)  OSEM Photodiode A was from the SR2 Top OSEM, the suspect channel.  In the images, the upper trace, labeled "1", is from OSEM Photodiode B, satellite box connector J2 pin 2.  The lower trace, labeled "2", is from OSEM Photodiode A, satellite box connector J2 pin 1, the noisey channel under investigation.

Two x10 probes were used.  The vertical scale factors for images 1 and 2 are 0.200 V/div.  The vertical scale factor for image 3 is 0.050 V/div.

Image 1 shows the satellite box as found, all cables connected. Photodiode A shows significantly more noise.

Image 2 shows the photodiode signals with the "Vacuum Tank" cable, connector J1, disconnected. All quiet.

Image 3 shows the photodiode signals with the "Vacuum Tank" cable reconnected to J1.  Both photodiode signals now have the same amplitudes. (Note the more sensitive scale factor for image 3.)

An intermitant? A poorly seated connector? Pickup from the SEI CPS 25kHz?  Betsy reported that the noise spectrum did not change!


 

Images attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 14:23, Tuesday 28 June 2016 (28017)

After the above investigation, FIl also powered off the HAM CPS clock synchronizing fanout.  The spectra still showed the noise while this was off, although it may have been a little bit reduced.  Then, Fil reseated the SAT AMP cable at the feedthru of the chamber which has these channels on it.  After reseating the noise was still there.  So, we've now tried multiple power switched cable reseating with no luck.  Our next tries will be to power cycle the h1sush34 computer (the only one not done today!) and lock closer at the CPS clock sync.

 

So to recap, there are a few channels which show a "bouncy" type noise spectrum (based on Andy L. tool plots, which I'll ask him to rerun soon) which appeared before or after the power outage:

PR2 M1 T2

PR2 M3 LL

PR2 M3 UL

SR2 M1 T1

SR2 M1 T3

SR2 M1 LF

 

A scan through all other OSEMs do not show any other OSEMs with this specific noise shape.  Attached is the spectra of the still present SR2 noise from today (bottom pane) with some other healthier channels (upper pane).

 

Continuation of alog 27893.

Images attached to this comment
H1 ISC
daniel.sigg@LIGO.ORG - posted 12:36, Tuesday 28 June 2016 - last comment - 11:45, Thursday 30 June 2016(28010)
Hardware Modifications for OMC PI Mode Monitoring

(Richard M, Fil C, Ed M, Daniel S)

ECR E1600192.

Split Whitening Chassis S/N S1101627:

AA Chassis S/N S1102788 & S1202201:

The attached plots show the transfer functions of

  1. whitening chassis: OMC DCPD_A: same as before
  2. whitening chassis: OMC PI DCPD_A: modified
  3. whitening chassis: OMC DCPD_B: same as before
  4. whitening chassis: OMC PI DCPD_B: modified
  5. AA chassis: channel 15
  6. AA chassis: channel 16
Non-image files attached to this report
Comments related to this report
filiberto.clara@LIGO.ORG - 14:59, Tuesday 28 June 2016 (28019)

Whitening chassis S1101603 was removed from ICS-R5 U18. New chassis S1101627 was reinstalled with modifications listed above. New unit is the split variant.

carl.blair@LIGO.ORG - 17:59, Tuesday 28 June 2016 (28030)

[Kiwamu, Carl]

First indications are that the DCPD HF channels are behaving as expected.  With the OMC locked on an RF sideband the DCPD A is compared to the new DCPD HF A.  The transfer function between them at low frequency has a 'f' relation which transistion fto f^3 at 10kHz as expected from the AC coupling change and the removal of 2 poles at 10kHz.  Coherence is lost at about 20kHz.  

Images attached to this comment
carl.blair@LIGO.ORG - 01:25, Wednesday 29 June 2016 (28046)

I have changed the whitening gain of the AHF DCPD path (A and B) to 15dB.  This pushed the noise floor in the 15-29kHz region to a factor ~2 above what I guess is ADC noise.  In the attached plots the original DCPD can be seen to reach a common noise floor with the AHF DCPD path with no whitening gain at about 17kHz.  Turning the whitening gain up we can get some coherence with the shot noise of the DCPD through original electronics. 
A forest of new peaks is visible, mainly in the 17-29kHz region.  There are 80 peaks in teh 25-26kHz band.  I stepped the ETMX ring heater at 7:01 up by 0.5W and down again at teh end of lock at 7:22.  This may give some mode identificatiion data.

Images attached to this comment
richard.mccarthy@LIGO.ORG - 11:45, Thursday 30 June 2016 (28085)
This morning we removed the Twin T notch on the AA board by removing C3, C4, C5, C10, C11 leaving in the 100 Ohm resistors in place.
Non-image files attached to this comment
H1 ISC
peter.fritschel@LIGO.ORG - posted 11:32, Tuesday 28 June 2016 - last comment - 11:47, Wednesday 29 June 2016(28009)
Monitoring PI Modes with the OMC DCPDs

The OMC DCPDs have proven to be useful for monitoring the test mass acoustic modes around 15 kHz, but there is a lot of low-pass filtering in the readout chain that render them less useful for monitoring higher frequency acoustic modes. This is now being changed with modifications to the electronics that will provide separate, faster channels for PI monitoring:

The attached plot shows the magnitude response of the low-pass filtering in the previous case, and with the poles removed from the whitening and AA channels. It is no wonder that no PI modes have been seen above the 15-16 kHz grouping, as there is 40 dB of relative attenuation already at 25 kHz.

I also attach a 1kHz - 10 MHz transfer function of the in-vacuum DCPD readout that Koji measured at Caltech:

https://nodus.ligo.caltech.edu:8081/OMC_Lab/235

Images attached to this report
Comments related to this report
peter.fritschel@LIGO.ORG - 11:47, Wednesday 29 June 2016 (28057)

Here are the transfer functions with the AA notch included. I had forgotten that the notch is a passive twin-T type, which by design has a Q = 1/4, so it is quite wide and should be taken into account. In future the AA notches should also be removed.

Images attached to this comment
H1 PEM (PEM)
vincent.roma@LIGO.ORG - posted 11:11, Tuesday 28 June 2016 (28008)
Removed Sensors from Infrasound Mics for Upgrades

The infrasound mics have already been upgraded at LLO but today I removed the sensors at LHO.  I removed the sensors from the microphones in the CS, at EX, and at EY.  This meant unscrewing the bottom of the instrument box and pulling out some of the equipment.  As far as I could tell everything went as planned and the equipment will now be sent away for upgrades.

H1 CDS
james.batch@LIGO.ORG - posted 10:54, Tuesday 28 June 2016 (28007)
Replacement of 18bit DAC successful for h1susb123, h1sush2a
WP 5954

All of the 18bit DAC cards in h1susb123 and h1sush2a now successfully pass the autocal on both power up and restart of the IOP models.  Results shown below:

h1susb123 - power up
[   61.694760] h1iopsusb123: DAC AUTOCAL SUCCESS in 5344 milliseconds
[   67.057232] h1iopsusb123: DAC AUTOCAL SUCCESS in 5340 milliseconds
[   72.850938] h1iopsusb123: DAC AUTOCAL SUCCESS in 5344 milliseconds
[   78.213461] h1iopsusb123: DAC AUTOCAL SUCCESS in 5345 milliseconds
[   85.247010] h1iopsusb123: DAC AUTOCAL SUCCESS in 6571 milliseconds
[   90.610149] h1iopsusb123: DAC AUTOCAL SUCCESS in 5344 milliseconds
[   95.973497] h1iopsusb123: DAC AUTOCAL SUCCESS in 5345 milliseconds
[  101.336018] h1iopsusb123: DAC AUTOCAL SUCCESS in 5340 milliseconds
h1susb123 - IOP model restart
[  911.921930] h1iopsusb123: DAC AUTOCAL SUCCESS in 5344 milliseconds
[  917.282286] h1iopsusb123: DAC AUTOCAL SUCCESS in 5345 milliseconds
[  923.070351] h1iopsusb123: DAC AUTOCAL SUCCESS in 5341 milliseconds
[  928.430617] h1iopsusb123: DAC AUTOCAL SUCCESS in 5344 milliseconds
[  935.453979] h1iopsusb123: DAC AUTOCAL SUCCESS in 6576 milliseconds
[  940.814416] h1iopsusb123: DAC AUTOCAL SUCCESS in 5345 milliseconds
[  946.174750] h1iopsusb123: DAC AUTOCAL SUCCESS in 5345 milliseconds
[  951.535191] h1iopsusb123: DAC AUTOCAL SUCCESS in 5341 milliseconds

h1sush2a - power up
[   48.086815] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds
[   53.450158] h1iopsush2a: DAC AUTOCAL SUCCESS in 5345 milliseconds
[   60.479701] h1iopsush2a: DAC AUTOCAL SUCCESS in 6576 milliseconds
[   65.843077] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds
[   71.640028] h1iopsush2a: DAC AUTOCAL SUCCESS in 5345 milliseconds
[   77.001396] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds
[   82.364713] h1iopsush2a: DAC AUTOCAL SUCCESS in 5345 milliseconds
h1sush2a - IOP model restart
[ 1252.909059] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds
[ 1258.269410] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds
[ 1265.292831] h1iopsush2a: DAC AUTOCAL SUCCESS in 6572 milliseconds
[ 1270.653176] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds
[ 1276.441059] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds
[ 1281.801414] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds
[ 1287.161817] h1iopsush2a: DAC AUTOCAL SUCCESS in 5345 milliseconds
H1 AOS
corey.gray@LIGO.ORG - posted 10:35, Tuesday 28 June 2016 - last comment - 10:52, Tuesday 28 June 2016(28005)
Test Mass & HAM Oplevs vs Locklosses

Last week, Rana was inquiring about how locklosses affect oplev sums. 

Took a random sample of locklosses from O1 and came up with fairly consistent results for after a lockloss, so here's the nitty gritty:

Attached is an example of a lockloss from Nov.

Non-image files attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 10:52, Tuesday 28 June 2016 (28006)

There's a DCC document and even a tool to look at these things.

https://dcc.ligo.org/LIGO-T1600085

H1 PSL (PSL)
peter.king@LIGO.ORG - posted 09:00, Tuesday 28 June 2016 - last comment - 15:15, Tuesday 28 June 2016(28003)
PSL cooling
We adjusted the pressure on the pwrmtr water circuit from its nominal 5 bar to 4.5 bar.  The flow rate to the
laser heads decreased somewhat.  Put the pressure back to ~5 bar to set the flow rate in the circuit to be
over 1.25 l/min.

    In doing so, the other flow rates seemed to behave as expected.  We will monitoring the flow rates and
pressures over the the next few days to see if anything settles out/down.






Jeff, Peter
Comments related to this report
sheila.dwyer@LIGO.ORG - 15:15, Tuesday 28 June 2016 (28020)

Have been monitoring the PSL chiller trends during the day. The attached plot is for an 8 hour period. The spikes at 06:50 (PT) are when Peter and I varied the pressures regulators. The pressures and flows have flattened out, which is good. The head flows have also flattened out, which is also good. The head temperatures have been moving around a bit (by 0.1 degree). It appears that varying these pressures regulators may have stabilized the pressure and flows. Will check again in the morning to see if these trends hold.   

Images attached to this comment
H1 PSL (PSL)
peter.king@LIGO.ORG - posted 08:56, Tuesday 28 June 2016 (28002)
DC block
Measured ~18 mV, 20 ohms between the table surface and the chassis of the ISS AOM.  Installed DC block.
Measured the same afterwards, so I removed the DC block.

This clearly does not work as well as the one on the FSS AOM (for whatever reason).
LHO VE
john.worden@LIGO.ORG - posted 08:53, Tuesday 28 June 2016 - last comment - 13:33, Tuesday 28 June 2016(28001)
New PID control at End Y CP7

I have set the level setpoint to 90% to exercise the new PID control.

Comments related to this report
john.worden@LIGO.ORG - 12:06, Tuesday 28 June 2016 (28011)

Here is the response.

Looks good Patrick!

Images attached to this comment
john.worden@LIGO.ORG - 13:33, Tuesday 28 June 2016 (28015)

Restored setpoint to 92%.

LHO VE
kyle.ryan@LIGO.ORG - posted 07:03, Tuesday 28 June 2016 - last comment - 08:17, Tuesday 28 June 2016(27998)
CP5 level control amis
Found that the PI output for CP5 was 0% even though the pump level is at 83% -> I switched CP5 to manual control with LLCV %open of 90% -> The other vacuum group members have been experimenting with CP5 of late so I'll "stay out of the kitchen" and let them continue/investigate.
Comments related to this report
kyle.ryan@LIGO.ORG - 07:35, Tuesday 28 June 2016 (27999)
Changing to 35% while transfer line cools -> Need to do stuff in other room and will monitor exhaust pressure sporadically. 
john.worden@LIGO.ORG - 08:17, Tuesday 28 June 2016 (28000)

Back to PID at  08:00 as the PID output had risen to 90%.

H1 ISC (ISC)
lisa.barsotti@LIGO.ORG - posted 00:08, Tuesday 28 June 2016 - last comment - 09:12, Tuesday 28 June 2016(27990)
40W towards low noise, more PI damping tests
Jenne, Carl, Sheila, TJ, Stefan, Lisa

We have a quite reliable locking sequence to 40W at this point (recycling gain ~28.5, same SOFT offset strategy as over the week-end with one set of offsets engaged before power up, one at 40W; SRM alignment done by end), so tonight we started going back to low noise while doing PI testing.

Here is the list of things we successfully did; we still need to modify the ISC LOCK code to be compatible with some of those (note that we are still on POPX, so the POP beam diverter is open):
  • Coil driver switched to low noise
  • ASC cut-offs: JLP35 for DHARD (P/Y) and CHARD (P)
  • Modified CHARD-Y 35 Hz cut-off (the new one is called "modcut"), because the current one had gain peaking between 20 and 30 Hz that was preventing us from switching ESD Y to low noise; CHARD-Y gain also lowered by 40% (from -0.7 to -0.4)
  • ESD Y switched to low noise
  • ISS3 loop off, ISS 2 ON (instructions from Kiwamu; Jenny had to reduce the actuation delay from 0.2 to 0.1 to engage the second loop)
  • OMC whitening on
  • MICH feed-forward: the -15.9 nominal gain seemed ok
  • Nominal SRCL tuning: LP 80, gain reduced by a factor of 2, feed-forward engaged with nominal gain -1
  • REFL and AS beam diverters closed (POP open as we are still on POPX)
  • ESD X in state 2 (tested bias off -- no impact on the noise)
  • ITMY ESD state switched to 2
  • Jenne realized that the OMC ASC output had railed --we switched to QPDs and stayed on QPDs for the rest of the lock, but awe were already transitioned back to high noise at that point..
The best spectrum we have achieved was at June 28, 6:00 - 6:10 UTC (with the OMC alignment railed) . Below 60 Hz we still have a lot of ASC noise, and that was expected, but there was a clear excess of noise also at 100 Hz that we didn't expect to be there. For the records, sensMon claimed 40 Mpc. We run out of time because of the 15542.6 ETMY PI, accidentally driven up while trying to damp the 15542. We lost lock at June 28, 6:35 UTC, after about 2 hours at 40W. Some notes: * we systematically lose recycling gain when we increase the power, we go from 35 at 2 W to 29 at 40W. Attempts to improve the recycling gain by changing the alignment offsets of most loops failed; * because of the lower recycling gain, the shot noise improvement at high frequency that we expect is ~30%
Comments related to this report
stefan.ballmer@LIGO.ORG - 00:14, Tuesday 28 June 2016 (27993)

Plot 1: Noise spectrum for tonight. Below 60Hz is due to ASC, and can still be addressed.

Plot 2: Auxiliary loops noise. Note the increased coupling of the mechanical resonances just below 60Hz. I suspect that we still are not quite centered in the recycling cavity.

Plot 3: Aux loop coherences

Images attached to this comment
sheila.dwyer@LIGO.ORG - 00:30, Tuesday 28 June 2016 (27994)

After this lock broke Carl and I turned on the ITM ring heaters to 0.5 Watts each, and left the end stations at 1.5 Watts each.  Carl thinks that this will help with PI, and this will also set us up to try some common TCS tuning tomorow.

jenne.driggers@LIGO.ORG - 00:49, Tuesday 28 June 2016 (27995)

Some of the things that Lisa mentioned are now in the guardian.

  • Coil drivers:  Used regular guard state
  • ASC cutoffs:  created new guard state just before ESD ETMY to do this
  • ESD ETMY to low noise: used regular guard state
  • ISS 3rd loop off, 2nd loop on: actuation delay changed in guardian, everything else was already in EngageIssSecondLoop
  • OMC whitening on:  Used guardian state in OMC lock (well, we did it by hand by copying the lines of code.  But the guardian will work)
  • MICH FF: Nominal state is in guardian NoiseTunings
  • SRCL FF: In NoiseTunings state
  • SRCL loop: gain and low pass in NoiseTunings
  • POP beam diverter commented out of CloseBeamDiverters state - can now just use guardian state
  • ESD ETMX to state 2:  Need to add this to guardian, in NoiseTunings (first make sure bias is off - may want to move this earlier, in case already using PI damping)
  • ITMY ESD:  They aren't changed in the guardian away from state 2, so they should be fine.

Attached is a screenshot of when (in PSL power terms) the OMC ASC rails.

Images attached to this comment
sheila.dwyer@LIGO.ORG - 03:03, Tuesday 28 June 2016 (27996)

For the first almost 3 hours of this lock we were toggling the gain of CSOFT P by 20 dB every 10 seconds because of a logic problem in the guardian.  Should be fixed now.

Images attached to this comment
carl.blair@LIGO.ORG - 03:50, Tuesday 28 June 2016 (27997)

Filters for PI damping have been broadened to 10Hz as the phase change over 0.5Hz for some of the filters being used was greater than 200 degrees.  
These 10Hz wide filters may be problematic for the 15541.9 and 15542.6Hz modes.  I have tested damping these modes at low amplitudes with the 10Hz wide filters and to damp, however as we reached 3 hours into this lock the 15541.9 and 15542.6 were slowly pushing their way up, the filters I have put in have about 60 degrees phase shift for 1Hz change in frequency. 
I tested iwave on this pair of modes, it tracks the largest mode very well, however once damped to a level lower than the next highest mode it runs off and tracks that mode.  This meant two iwave blocks running one on each etm pi model generally pushed their test mass with the largest amplitude mode.  I was using tau of 10.
We have a SUS_PI guardian now.  The gaurdian has 4 states managed by ISC_LOCK.  IFO_DOWN, OMC_TRACKING,  PI_DAMPING and ETMX_PI_DAMPING.  The tracking state just turns on tracking for long term testing.  The damping states turn on the bandpass damping chains with settings that have been tested today and very low gains for the settings in Terra's PI wiki. I will update the wiki tomorrow with some new settings.
The 0.5W increase in the ITM ring heaters should push the optical mode to lower frequencies, as we see PI in the 15540Hz group of modes close to the end of the RoC thermal transient (1.5-2hour in a 2-3hour transient) I am hoping this will be enough to make these instabilites a little less agressive.  I have been doing some testing of the 15kHz mode in anticipation that this TCS change will make these modes ring up more at the beginning of lock.
Before leaving I stepped the ETMY Ring heater by 0.5W total to test the idea that we can push the 15542Hz modes appart with a little heating.

 

kiwamu.izumi@LIGO.ORG - 09:12, Tuesday 28 June 2016 (28004)

The ITM ring heaters that Sheila activated seemed to have introduced a substrate lensing of about 8 uD on each optic according to the TCS simulator. The ITMX HWS saw the consistent amount of change in the substrate lensing (~ 18 uD due to the round trip lensing which gives an extra factor of two). After the ring heaters were activated, the power recycling on average was higher than the previous 41 W stretch by 1%; this could be because the last lock stretch with the ring heaters was with a slightly lower PSL power of 39 W. I attach trend of the relevant channels.

Images attached to this comment
H1 ISC
kiwamu.izumi@LIGO.ORG - posted 13:46, Monday 27 June 2016 - last comment - 12:11, Tuesday 28 June 2016(27982)
modifications on omcpi and susetmpi models; ready for tomorrow's maintenance

Daniel, Ross, Carl, Kiwamu,

WP#: 5957

We made two modifications on the h1omspi, h1susetmxpi and h1susetmypi models as follows.

We are ready for tomorrow's model restart during the maintenance period.

 


[I and Q signals to science frame]

Since all the I and Q down sampled signals have been already recorded in commissioning frame, we just added a star symbol to each channel name in the DQ text field in the simulink models. In total, 24 channels (8 channels from each model) will newly go to science frame at 2 kHz.

[New DCPD signals]

We decided to do a quick hack on the OMC whitening board so that we don't suffer from the two 10 kHz poles (technically, 14 and 18 kHz from the differential receiver stage, see alog 21131) to obtain a better signal to noise ratio. Some more details of this quick hack will be reported by Daniel and Stefan later. In the mean time, we have edited the h1omcpi model so that it is capable of handling these two signals. In the first attachment it shows the two new ADC inputs (adc_0_14 and adc_0_15) which then go to a subblock called PI_DCPD. One can choose whether the normal DCPD is used for the PI error signal or the new signals by the two choice blocks that are behind the PI_DCPD block.

Once we become able to damp the PI modes using the new DCPD signals, we should get rid of the old DCPD signals. But for commissioning purpose, we are leaving the normal DCPDs available for now.

Also, we added these two new signals to commissioning frame at the full sampling rate at 64 kHz. So, in total, we now have four 64 kHz DQ channels, which should be reduced to 2 or 1 channels as we complete the commissioning at some point in future. The new DQ channels have the names as PI_DCPD_64KHZ_A(B)HF. Note that in order to save the test points for the normal DCPD signals, we pulled them out of a subblock and placed them at the top level as seen in the first attachment.

In the PI_DCPD subblock, we have placed controlled-IIR-fitlers so that they can be synchronized with the analog board settings as have been done in the LSC and ASC models. See the second attachment.

All the changes are checked into the SVN repo. We made sure that they compiled without errrors.

Images attached to this report
Comments related to this report
daniel.sigg@LIGO.ORG - 12:11, Tuesday 28 June 2016 (28012)

The addtion of two new DAQ channels for OMC PI monitoring also required a change to the TwinCAT code to enable the whitening switching.

Displaying reports 56281-56300 of 83529.Go to page Start 2811 2812 2813 2814 2815 2816 2817 2818 2819 End