We're having some mysterious lock losses as we move from large CARM offset to less large offset. With the DRMI locked, the ALS starts bringing the arms in and the ALS / IMC lose lock.

Suspecting the recent FSS tunings, we looked at the FSS screen. The FAST gain was down at +5 dB. Also, the EOM Drive readback was up at +3V. The attached plot shows the EOM readback (PC_MON) as the FAST gain is tuned.

I have left it at 22.2 dB, where the EOM drive is minimized. IN mid-April, there are a series of entries from Rick and Peter where the loop is tuned up, but the fast gain is turned down incrementally from 21 to 5 dB. Why so??

Also, it seems like we should aim for a ~250 kHz UGF for the FSS to avoid the peaking at 1.8 MHz where the notch is not getting all of the EOM resonance.

Cataloging the many ways in which we are breaking lock or failing to lock since Friday, we found this one:

Sitting quietly at 10W DC readout, there was a slow ring up of a pitch instability in several ASC signals. Perhaps its time we went back to seriously controlling the ASC in the hard/soft basis instead of the optic basis in which its currently done. The frequency is ~1 Hz and the time constant is ~1 min. It would be great if someone can look at the signs of the fluctuations in the OL and figure out if this was dHard or cHard or whatever.

The DAC for the BS M2 stage can put out 131000 counts, but the RMS is only 500 counts after transitioning into 'state 3' of the coil driver (Acq OFF, LP ON).

Seems like we're not in the best state here. We don't want to reduce the BS range for acquisition.

Should we be putting in an offset to avoid the DAC glitches or has this DAC been improved by some EEPROM upgrades?

Has anyone in DetChar seen BS DAC glitches from ER7?

Evan, Matt, Stefan

- Matt wrote a many - optic ASC relief function, which we added to the DRMI guardian. This saves us some time.

- for the rest we were chasing  random fast lock losses that hit us pretty much anywhere - Prep_TR_CARM, REFL_TRANS just sitting on resonance at low power, and sitting at high power.

- Evan started to systematically go through and check loop,gains.
- He found the digital REFL   CARM loop to be slightly low, increase Tr_REFLAIR_9 gain from -0.5 to -0.8
- ALS diff looked fine.

What I did
- Take a filter that ramps over 3sec (always on)
- edit the foton file top a 1 sec ramp
- start the ramp, but before it finishes - load the new filter.
- The filter module keeps ramping, and never finishes...

- I could reproduce this twice.
- I attached a snap of the still ramping FM1 on LSC-REFLBIAS.

- To fix it, I considered rebooting, but since the I suspected the problem to be a runaway counter, I simply added a filter with 600sec ramp time (long enough to catch the original filter ramp). 10min later (the time it took to write this log) it was fixed...

Evan, Rana, Stefan

After we mostly fixed the CARM_ON_TR lock losses we ran into the REAFL_TRANS ones. There is definitely a loop instability on TR_REFL_TRANS. Be sped up this transition which at least once seemed to help. However we also randomly lost lock at other places, and never made it to low noise. We'll have another systematic approach tomorrow.

MattE, Hong, Kiwamu, Rana

We've made a temporary hookup at EY to get the in-vac, IR, TransMon QPD signals into the new fast 'h1susetmypi'. This is so that we can monitor the amplitude and frequency of the unstable opto-acoustic modes in the interferometer (0910.2716). The only cabling change we've made is to add a breakout board at the AA chassis, so things out to run as before after the EQ rings down.

Cabling Details:

The TransMon QPD cable goes into a Transimpedance/Whitening amplifier (D1001974) with Z = 1000 Ohms. Then there's a 0.4:40 pole:zero stage with a gain of 1 at DC. The output of this board then goes through a whitening chassis and then the output of that box (in the rack near the BSC) goes into the electronics room and into an ISC AA Chassis via a 9-pin dsub. We put the breakout board at the AA side of this cable. We used clip-doodles to go into a SCSI breakout board and via ribbon cable into the ADC for the h1susetmypi. This is a temporary setup to allow us to commission the model software. In this setup, since we're using the whitening filter outputs, we also get the whitening gain and amplificaiton which is used for the QPD servos. Also we do not need to use the PEM patch panels as initially planned.

The transimpedance box has a single pole at 80 kHz. The whitening filter has no poles below 80 kHz. So these should be fast enough to let us see PI modes up to 30 kHz.

We had to use some critical electrical tape to keep the BNC-clip shields from shorting with each other; take care in working near the AA side of this cabling - it may put offsets into the QPDs and disturb the lock acquisition.

Sheila, Stefan

Our first version of this fix had a bug: the linear fit below the sqrt limiter meant that there is a non-zero chance to drive the arm in the wrong direction, resulting in a DRMI lock-loss. We addressed this in the next version of the code with a quadratic fit:
 - The initial limiter is set at l=1e-4. Above it (x>l), we still simply have sqrt(x) for CARM_TR.
 - Below x<-3*l, we have TR_CARM=0
 - Between -3*l<x<l we add the 2nd path f=A*(x-x0) + f0, with
      - f0=-sqrt(l)        = -0.01
      - x0=-3 l            = -3e-4
      - A = 1/(16*l^(3/2)) = 62500
 - The sum of the two paths gives a smooth interpolation. We tested this code and verified that the FE code does what it should.
 - Next we wanted to optimize the threshold limit l:
   - Looking  at past locks, the pk2pk during PREP_TR_CARM in TR_CARM is about 0.1 cts
   - Thus the following parameters might be even better:
      - l=0.01
      - f0=-sqrt(l)        = -0.1
      - x0=-3 l            = -3e-2
      - A = 1/(16*l^(3/2)) = 62.5
 - We installed this as version V2 of this code.
 - Due to the earthquake we have not yet tested this yet.

Evan, Stefan

We implemented the PR3 feed-back in ENGAGE_ASC in the ISC_LOCK guardian:
- We decided to leave the feed-back on PR2 during DRMI. This allows us to absorb the first correction to the initial alignment to PR2.
- We then switch the feed-back to PR3 in ENGAGE_ASC. This locks down PR3 during power-up - we confirmed that the REFL beam no longer moves in that transition.

- Details:
 - We modified the DRMI guardian ENGAGE_DRMI_ASC state to prepare both PR2 and PR3 for feed-back.
 - PR3 gais were set to roughly match PR2
 - The settings on PR3 are:
   -    ezca['SUS-PR3_M3_ISCINF_P_GAIN'] = 2
   -    ezca['SUS-PR3_M3_ISCINF_P_GAIN'] = 5
   -    SUS-PR3_M1_LOCK have an integrator, a -120dB and a gain of 1
 - Also, it now has the flag self.usePR3, which can select feed-back to PR2 (False) or PR3 (True). The rest of the ENGAGE_DRMI_ASC state uses this flag.
 - The default is self.usePR3=False, i.e. it does just the old PR2 engaging.

 - The PRC2 loop is always off during the CARM reduction sequence. It is re-engaged in ENGAGE_ASC with feed-back to PR3 with the following steps:
 - The output of SUS-PR2_M3_ISCINF_P and SUS-PR2_M3_ISCINF_Y is held
 - The ASC-PRC2_P and ASC-PRC2_Y filters are cleared.
 - The output matrix is updated:
   -    asc_outrix_pit['PR3', 'PRC2'] = 1
   -    asc_outrix_yaw['PR3', 'PRC2'] = -1 # required to keep the same sign as PR2
 - And the loops are turned on again.
 - The current loop gain is still low - the step response is on the order of 30sec.
 - ENGAGE_ASC also has the self.usePR3 flag (default is True), so it is still backwards compatible.

 - The whole sequence (engage DRMI on PR2, switch to PR3 in full lock) was tested successfully once before an earthquake hit.

A new H1 model was started this afternoon on h1susey. It is h1susetmypi, which is a copy of the L1 model minus the IPC input receievers and the DAC outputs on the top level. The new model has DCU_ID=127 and runs at 64kHz.

The initial startup failed with a "DAQ too small" error. We boosted the DQ channels from 2kHz to 64kHz (commissioning frame only) and added some EpicsIn parts at the top level to get through this error. We will investigate this further next week.

The new model was added to the DAQ and the DAQ was restarted. I have added it to the CDS ENG overview MEDM screen, I'll add it to the rest later.

A while ago I made a "complete" violin mode table here. Matt and Jeff was curious whether or not the frequencies belong to correct test mass. So, I went through the violin mode damping filters and see which one works and which doesn't. So far I was able to confirm that 24 out of 32 frequencies belong to the correct test masses. The filters were able to damp most of them. Three frequencies got rung up. The rest were still inconclusive (either the damping phases were off by 90 degrees or the test masses were wrong).

Below is the table of the violin mode damping filters used by Guardian and the frequencies they (supposed to) damp:

Both tables are included in the excel file attached below.

Guardian core upgraded to fix "double main" execution bug.

I have just installed a new version of Guardian core:

guardian r1449

It address the "double main" execution bug that was been has been plaguing the system.  See guardian bug 879, ECR 1078.

The new version is in place, but none of the guardian nodes have been restarted yet to pull in the new version.

You can either manually restart the nodes with 'guardctrl restart', or just try rebooting the whole guardian machine.  I might start with the former, to just target the important lock acquisition nodes (ISC_LOCK, etc.), and wait until Tuesday maintenance for a full restart of the Guardian system.

Chris S. Joe D.

The crew installed metal strips on the top of 350 meters of tube enclosure joints this week for a total of 1075 meters of enclosure from the corner station on the X-Arm. 

APOLOGIZES FOR NOT REPORTING FOR THE PAST WEEK

Scott L. Ed P. Rodney H.

This report will cover 7/13-7/17 dates inclusive.

 The crew cleaned a total of 358.7 meters of tube this week. Test results for the week also shown here.

 We added another generator that we had on site to the cleaning operation so the third man could be vacuuming the support tubes and pre-cleaning the egregiously dirty areas of the tube. This has seemed to increase productivity as seen by the almost 72 meter a day average.

Scott L. will be on vacation next week so to hopefully keep up with the current pace I am bringing out another Apollo employee who is very familiar with the site. Mark Layne will be filling in for Scott next week.  
 

Matt found some data from last night that looks pretty good - I'm not sure what the state of the IFO was at this particular time, so I won't say.

The following are a list of lock loss messages in the Guardian log. We've had a bunch of locklosses during the transition from locked to low noise this evening. As you can see there are a few different culprits, but one of the big ones is LOWNOISE_ESD_ETMY. It would be handy if someone can check out these lock losses and home in on what precisely went bad during this transition (e.g. ramping, switching, etc.). Then we can get back to SRCL FF tuning.

2015-07-17 06:47:05.694550  ISC_LOCK  LOWNOISE_ESD_ETMY -> LOCKLOSS

2015-07-17 06:48:22.162260  ISC_LOCK  LOCKING_ARMS_GREEN -> LOCKLOSS

2015-07-17 07:14:34.431170  ISC_LOCK  NOMINAL_LOW_NOISE -> LOCKLOSS

2015-07-17 07:26:40.249110  ISC_LOCK  CARM_10PM -> LOCKLOSS

2015-07-17 07:34:59.720030  ISC_LOCK  PREP_TR_CARM -> LOCKLOSS

2015-07-17 07:42:08.269350  ISC_LOCK  LOCKING_ALS -> LOCKLOSS

2015-07-17 08:02:41.773620  ISC_LOCK  LOWNOISE_ESD_ETMY -> LOCKLOSS

2015-07-17 08:21:58.665420  ISC_LOCK  LOWNOISE_ESD_ETMY -> LOCKLOSS

2015-07-17 08:31:29.035330  ISC_LOCK  REDUCE_CARM_OFFSET_MORE -> LOCKLOSS

2015-07-17 08:48:32.514870  ISC_LOCK  LOWNOISE_ESD_ETMY -> LOCKLOSS

I wrote the script for the OPLEV charge measurements which sets most of the settings and easy-to-use. It works for ~ 2.5 hours.
If you are the last person who leaving the LHO in the night - please, run it!

Instructions:
1. Set ISC_Lock state to DOWN
2. Set both ETMs to "ALIGNED" state
3. Align Optical levers (pitch and yaw) for both arms to 0 +/-.5 urad
4. Run the scripts: scripts directory is /ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/Scripts
run the python files: ./ESD_Night_ETMX.py and the second script in another terminal: ./ESD_Night_ETMY.py

If it works, it:
a) In first ~ 30 seconds sets the channels and can warn about troubles with ESD or Alignment. If it happens - check this system and press 
b) During the measurements it should once a second print "Receiving data for GPS second: 1234567" 
c) After all the measurements it should restore all the settings back.

If it gives the errors but still receive some data - let it work.
If it obviously not work, you can try to run it again. If it does not help - please, restore all settings running ./ESD Restore_Settings.py . 

Due to it is first try, today I will be very thankful if you'll check after running the scripts :
1. L3 Lock:
   Bias Voltage - 0
   Offset - green light
   Ramp time - 5s
2. ESD linearization:    Bypass - ON
3. For ETMY:   turned on Hi-voltage driver.
Just in case: scripts modify only this settings.