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:

• In-vacuum pre-amp: this has 2 poles at 16 kHz (these will remain, since in HAM6)
• Whitening board: 1 pole at 14 kHz; 1 pole at 18 kHz. These will be eliminated in the new chain.
• Anti-alias filter: 3rd order Butterworth low-pass at 10 kHz. These will be eliminated in the new chain.

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

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.

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

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:

• HAM oplevs sums don't change
• ETM sums drop ~3%
• ITM sums drop ~1%  (which is small compared to overall DC drift of the sum value)

Attached is an example of a lockloss from Nov.

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

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).

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

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.

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%

TITLE: 06/28 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY: Commissioners working hard. Hit 40+Mpc for a bit.

Nutsinee, Jim, Dave:

The HWS code crashed at 07:50 PDT this morning, Nutsinee tried to restart at 11:46 PDT, but it failed. We found that the 1TB raid is 100% full (has data back to December 2014). We are contacting Aidan to see how to proceed.

BTW: the /data file system on h1hwsmsr is NFS mounted at the end stations, so no HWS camera information is being recorded at the moment.